Oracle表空间和数据文件里面，Temp表空间和文件是比较特殊的。除了Temp表空间对应的临时段（temp segment）是由Oracle自动进行管理之外，稀疏文件的特性也是我们需要注意的一个方面。
常规情况下，我们创建一个数据文件，即使使用OMF特性，也需要指定初始文件大小。创建数据文件之后，磁盘空间被明确的占用，我们从操作系统层面是可以看到空间的。但是，对于临时表空间文件而言，新创建出的文件也许只能看到操作系统层面的文件大小，但是却没有空间占用。我们称这个特性为“稀疏文件”。
从实现层面，稀疏文件意味着更少的redo log生成。那么，在DG环境下，Temp文件的特性和普通文件有什么差异呢？下面我们通过一系列的实验来证明。
--------------------------------------分割线 --------------------------------------
相关参考:
Oracle Data Guard 重要配置参数
基于同一主机配置 Oracle 11g Data Guard
探索Oracle之11g DataGuard
Oracle Data Guard （RAC+DG) 归档删除策略及脚本
Oracle Data Guard 的角色转换
Oracle Data Guard的日志FAL gap问题
Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法
--------------------------------------分割线 --------------------------------------
1、实验环境介绍
我们在Oracle 11gR2环境下的Dataguard中进行测试。具体版本为11.2.0.4。当前Primary情况如下：
--Primary名称ora11g
SQL> select DATABASE_ROLE, open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PRIMARY READ WRITE
当前数据库中只有一个临时文件，对应表空间TEMP。
SQL> select file_name, tablespace_name from dba_temp_files;
FILE_NAME TABLESPACE_NAME
------------------------------------------------------------ ------------------------------
/u01/app/oradata/ORA11G/datafile/o1_mf_temp_9mnjxpk4_.tmp TEMP
对Dataguard而言，最重要的文件管理参数为standby_file_management。如果保持为AUTO，就可以保证数据文件同步创建。
SQL> show parameter standby_file
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
Standby端情况也比较简单，处在mount状态。文件自动创建管理。
SQL> select DATABASE_ROLE, open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY MOUNTED
SQL> select name, file# from v$tempfile;
NAME FILE#
-------------------------------------------------------------------------------- ----------
/u01/app/oradata/ORA11GSY/datafile/o1_mf_temp_9pcqbdd6_.tmp 1
SQL> show parameter standby_file
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
2、Primary端临时表空间操作
我们首先实验在Primary端进行表空间操作。
（primary）
SQL> alter tablespace temp add tempfile size 100m autoextend off;
Tablespace altered
SQL> select file_name, tablespace_name from dba_temp_files;
FILE_NAME TABLESPACE_NAME
------------------------------------------------------------ ------------------------------
/u01/app/oradata/ORA11G/datafile/o1_mf_temp_9mnjxpk4_.tmp TEMP
/u01/app/oradata/ORA11G/datafile/o1_mf_temp_9pm3ct62_.tmp TEMP
SQL> alter system switch logfile;
System altered
切换之后，正常redo log信息应该已经传递到standby端。Standby端启动redo apply过程，查看临时文件是否创建。
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered
SQL> select name, file# from v$tempfile;
NAME FILE#
-------------------------------------------------------------------------------- ----------
/u01/app/oradata/ORA11GSY/datafile/o1_mf_temp_9pcqbdd6_.tmp 1
启动redo apply之后，standby端依然只有一个临时文件，也就是说明临时文件没有联动的传递过来。至此，Primary和Standby文件结构出现差异。
此时是否可以在standby端直接添加文件呢？mount状态下，是拒绝的。
SQL> alter tablespace temp add tempfile size 100m autoextend off;
altertablespace temp add tempfile size 100m autoextend off
ORA-01109: 数据库未打开
与数据文件对应的临时表空间，如果我们在Primary端进行创建时，会不会联动创建呢？
（主库）
SQL> create temporary tablespace temp1 tempfile size 10m autoextend off
2 extent management local uniform size 1m;
Tablespace created
SQL> select file_name, tablespace_name from dba_temp_files;
FILE_NAME TABLESPACE_NAME
------------------------------------------------------------ ------------------------------
/u01/app/oradata/ORA11G/datafile/o1_mf_temp_9mnjxpk4_.tmp TEMP
/u01/app/oradata/ORA11G/datafile/o1_mf_temp_9pm3ct62_.tmp TEMP
/u01/app/oradata/ORA11G/datafile/o1_mf_temp1_9pm3mv8b_.tmp TEMP1
此时再观察Standby端，TEMP1表空间也没有连带的传导到standby端。
SQL> select name, file# from v$tempfile;
NAME FILE#
-------------------------------------------------------------------------------- ----------
/u01/app/oradata/ORA11GSY/datafile/o1_mf_temp_9pcqbdd6_.tmp 1
结论：当我们Standby端处在mount状态（Read Only也相同），Primary端涉及到的临时表空间创建维护、临时文件创建的操作是不会传导到standby端的。处在mount状态的standby端也不能进行文件手工创建动作。
更多详情见请继续阅读下一页的精彩内容：