Primary Database Changes That Require Manual Intervention at a Physical Standby

Primary Database Changes That Require Manual Intervention at a Physical Standby

>>>>DG中对主库做的某些改变，不会在备库被自动应用，需要我们手动干预

Most structural changes made to a primary database are automatically propagated through redo data to a physical standby database. Table 9-1 lists primary database structural and configuration changes which require manual intervention at a physical standby database. >>>>DG中对于主库的大多数结构变化，会被在备库上被自动应用。下面的表9-1中给我们列出了，哪些主库的结构和配置的变化，需要我们对备库作手动干预

Table 9-1 Primary Database Changes That Require Manual Intervention at a Physical Standby

Reference	Primary Database Change	Action Required on Physical Standby Database
Section 9.3.1	Add a datafile or create a tablespace	No action is required if the STANDBY_FILE_MANAGEMENT database initialization parameter is set to AUTO. If this parameter is set to MANUAL, the new datafile must be copied to the physical standby database.
Section 9.3.2	Drop or delete a tablespace or datafile	Delete datafile from primary and physical standby database after the redo data containing the DROP or DELETE command is applied to the physical standby.
Section 9.3.3	Use transportable tablespaces	Move tablespace between the primary and the physical standby database.
Section 9.3.4	Rename a datafile	Rename the datafile on the physical standby database.
Section 9.3.5	Add or drop a redo log file group	Evaluate the configuration of the redo log and standby redo log on the physical standby database and adjust as necessary.
Section 9.3.6	Perform a DML or DDL operation using theNOLOGGING or UNRECOVERABLE clause	Copy the datafile containing the unlogged changes to the physical standby database.
Section 9.3.7	Grant or revoke administrative privileges or change the password of a user who has administrative privileges	If the REMOTE_LOGIN_PASSWORDFILE initialization parameter is set to SHARED orEXCLUSIVE, replace the password file on the physical standby database with a fresh copy of the password file from the primary database.
Section 9.3.8	Reset the TDE master encryption key	Replace the database encryption wallet on the physical standby database with a fresh copy of the database encryption wallet from the primary database.
Chapter 14	Change initialization parameters	Evaluate whether a corresponding change must be made to the initialization parameters on the physical standby database.

9.3.1 Adding a Datafile or Creating a Tablespace

The STANDBY_FILE_MANAGEMENT database initialization parameter controls whether the addition of a datafile to the primary database is automatically propagated to a physical standby databases. >>>>主库添加数据库或创建表空间的操作是否会在备库上自动被应用，由备库上的STANDBY_FILE_MANAGEMENT参数决定

• If the STANDBY_FILE_MANAGEMENT parameter on the physical standby database is set to AUTO, any new datafiles created on the primary database are automatically created on the physical standby database.  >>>>如果备库上STANDBY_FILE_MANAGEMENT参数值设置为AUTO，那么主库上任何增加新的数据文件的操作都会在备库上被自动应用。

• If the STANDBY_FILE_MANAGEMENT database parameter on the physical standby database is set to MANUAL, a new datafile must be manually copied from the primary database to the physical standby databases after it is added to the primary database. >>>>如果备库上STANDBY_FILE_MANAGEMENT参数设置为MANUAL，那么在主库完成数据文件添加后，需要把主库新增的数据文件手动的拷贝到备库

Note that if an existing datafile from another database is copied to a primary database, that it must also be copied to the standby database and that the standby control file must be re-created, regardless of the setting of STANDBY_FILE_MANAGEMENT parameter. >>>>如果备库上STANDBY_FILE_MANAGEMENT参数设置为MANUAL，那么在主库完成数据文件添加后，需要把主库新增的数据文件手动的拷贝到备库

9.3.1.1 Using the STANDBY_FILE_MANAGEMENT Parameter with Raw Devices >>>>如果数据文件放在裸设备上，下面说的要特别注意

Note:

Do not use the following procedure with databases that use Oracle Managed Files. Also, if the raw device path names are not the same on the primary and standby servers, use the  DB_FILE_NAME_CONVERT database initialization parameter to convert the path names. >>>>下面所描述的处理步骤对OMF并不适用.如果主备库的裸设备名称不一致，需要使用初始化参数db_file_name_convert来进行转换。如果备库使用的是文件系统，并且备库上STANDBY_FILE_MANAGEMENT设置为AUTO，那么不论主库是新增还是删除数据文件的动作，都会在备库被自动应用。如果备库使用的是裸设备的话，虽然STANDBY_FILE_MANAGEMENT参数依然会起作用，但是一些必要的手动干预还是需要的。这里说的手动干预包括确保新建数据文件的日志在备库被应用之前，备库上已经存在了相应的裸设备。

By setting the STANDBY_FILE_MANAGEMENT parameter to AUTO whenever new datafiles are added or dropped on the primary database, corresponding changes are made in the standby database without manual intervention. This is true as long as the standby database is using a file system. If the standby database is using raw devices for datafiles, then the STANDBY_FILE_MANAGEMENT parameter will continue to work, but manual intervention is needed. This manual intervention involves ensuring the raw devices exist before Redo Apply applies the redo data that will create the new datafile.On the primary database, create a new tablespace where the datafiles reside in a raw device. At the same time, create the same raw device on the standby database. For example:

SQL> CREATE TABLESPACE MTS2 DATAFILE '/dev/raw/raw100' size 1m; >>>>主库在新建了一个表空间MTS2，数据文件放在裸设备上
Tablespace created.
 
SQL> ALTER SYSTEM SWITCH LOGFILE; 
System altered.

The standby database automatically adds the datafile because the raw devices exist. The standby alert log shows the following: >>>>如果备库上对应的裸设备已经存在，主库添加的数据文件会在备库上被自动创建(当然备库上STANDBY_FILE_MANAGEMENT参数需要设置为AUTO)。备库的alert日志中会出现如下信息

Fri Apr  8 09:49:31 2005
Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1_mf_1_7_15ffgt0z_.arc
Recovery created file /dev/raw/raw100
Successfully added datafile 6 to media recovery
Datafile #6: '/dev/raw/raw100'
Media Recovery Waiting for thread 1 sequence 8 (in transit)

However, if the raw device was created on the primary system but not on the standby, then Redo Apply will stop due to file-creation errors. For example, issue the following statements on the primary database: >>>>然而如果主库有裸设备而备库缺没有相应的裸设备，那么备库的恢复管理会因为文件创建失败而停止，下面是示例：

SQL> CREATE TABLESPACE MTS3 DATAFILE '/dev/raw/raw101' size 1m; >>>>主库在新建了一个表空间MTS3，数据文件放在裸设备上
Tablespace created.
 
SQL> ALTER SYSTEM SWITCH LOGFILE; >>>>主库切换日志文件
System altered.

The standby system does not have the /dev/raw/raw101 raw device created. The standby alert log shows the following messages when recovering the archive: >>>>如果备库系统上没有/dev/raw/raw101 这个裸设备，那么我们会在备库的alert日志中看到如下信息：

Fri Apr  8 10:00:22 2005
Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1_mf_1_8_15ffjrov_.arc
File #7 added to control file as 'UNNAMED00007'.
Originally created as:
'/dev/raw/raw101'
Recovery was unable to create the file as:
'/dev/raw/raw101'
MRP0: Background Media Recovery terminated with error 1274
Fri Apr  8 10:00:22 2005
Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc:
ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created
ORA-01119: error in creating database file '/dev/raw/raw101'
ORA-27041: unable to open file
Linux Error: 13: Permission denied
Additional information: 1
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Fri Apr  8 10:00:22 2005
Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc:
ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created
ORA-01119: error in creating database file '/dev/raw/raw101'
ORA-27041: unable to open file
Linux Error: 13: Permission denied
Additional information: 1
Fri Apr  8 10:00:22 2005
MTS; MRP0: Background Media Recovery process shutdown
ARCH: Connecting to console port...

9.3.1.2 Recovering from Errors

To correct the problems described in Section 9.3.1.1, perform the following steps: >>>>下面的方法，可以用来解决9.3.1.1所描述的问题

1. Create the raw device on the standby database and assign permissions to the Oracle user. >>>>在备库上创建相应的裸设备，并未oracle用户授权使用裸设备

2. Query the V$DATAFILE view. For example:

   SQL> SELECT NAME FROM V$DATAFILE; >>>>被库中查询v$DATAFILE
   
   NAME -------------------------------------------------------------------------------
   /u01/MILLER/MTS/system01.dbf
   /u01/MILLER/MTS/undotbs01.dbf
   /u01/MILLER/MTS/sysaux01.dbf
   /u01/MILLER/MTS/users01.dbf
   /u01/MILLER/MTS/mts.dbf
   /dev/raw/raw100
   /u01/app/oracle/product/10.1.0/dbs/UNNAMED00007
   
   SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL; >>>>修改备库STANDBY_FILE_MANAGEMENT参数为MANUAL
   
   SQL> ALTER DATABASE CREATE DATAFILE -
   > '/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007' -
   >  AS -
   > '/dev/raw/raw101'; >>>>备库中重建7号数据文件(alter database create datafile '....' as '...';)
   

3. In the standby alert log you should see information similar to the following:  >>>>执行完重建数据文件命令后，可以在备库的alert日志文件中，查看到如下信息：

   Fri Apr  8 10:09:30 2005
   alter database create datafile
   '/dev/raw/raw101' as '/dev/raw/raw101'
   
   Fri Apr  8 10:09:30 2005
   Completed: alter database create datafile
   '/dev/raw/raw101' a
   

4. On the standby database, set STANDBY_FILE_MANAGEMENT to AUTO and restart Redo Apply:

   SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO; >>>>把备库的STANDBY_FILE_MANAGEMENT参数改回AUTO
   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; >>>>启动备库恢复管理
   

At this point Redo Apply uses the new raw device datafile and recovery continues.

9.3.2 Dropping Tablespaces and Deleting Datafiles >>>>删除表空间和删除数据文件

When a tablespace is dropped or a datafile is deleted from a primary database, the corresponding datafile(s) must be deleted from the physical standby database. The following example shows how to drop a tablespace:

SQL> DROP TABLESPACE tbs_4; >>>>主库删除表空间tbs_4
SQL> ALTER SYSTEM SWITCH LOGFILE; >>>>主库切换日志

To verify that deleted datafiles are no longer part of the database, query the V$DATAFILE view.  >>>>查看视图v$datafile确认数据文件是否被删除(注意此时文件在操作系统层面还是存在的)

Delete the corresponding datafile on the standby system after the redo data that contains the previous changes is applied to the standby database. For example:  >>>>当包含删除动作的日志在备库被应用以后，使用操作系统命令 rm删除对应的文件,如下所示：

% rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf

On the primary database, after ensuring the standby database applied the redo information for the dropped tablespace, you can remove the datafile for the tablespace. For example:  >>>>当确认备库已经应用了主库dropped tablespace相关日志以后，在主库使用rm命令删除该tablespace所包含的数据文件

% rm /disk1/oracle/oradata/payroll/tbs_4.dbf 

9.3.2.1 Using DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES >>>>使用including contents and datafiles删除表空间

You can issue the SQL DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES statement on the primary database to delete the datafiles on both the primary and standby databases. To use this statement, the STANDBY_FILE_MANAGEMENT initialization parameter must be set to AUTO. For example, to drop the tablespace at the primary site:  >>>>你可以在DG的主库上使用 drop tablespace tbs_4 including contents and datafiles;命令去同时删除主库和备库上的表空间和数据文件(不需要再手动rm文件)，当然使用该命令时STANDBY_FILE_MANAGEMENT参数必须设为AUTO(如果设置为manual，那么drop tablespace能在备库成功执行，但是相应的数据文件不会自动删除，需要rm删除)。(如果是使用alter tablespace tablespace_name drop datafile file_nam/file#;命令删除主库的某个数据文件，无论STANDBY_FILE_MANAGEMENT设置为何值，备库的相应数据文件也会被自动删除，无需手动干预)
下面演示在主库上如此删除表空间：

SQL> DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES tbs_4;
SQL> ALTER SYSTEM SWITCH LOGFILE;

9.3.3 Using Transportable Tablespaces with a Physical Standby Database

You can use the Oracle transportable tablespaces feature to move a subset of an Oracle database and plug it in to another Oracle database, essentially moving tablespaces between the databases.  >>>>你可以使用transportable tablespaces把某个数据库的一部分(一个或几个表空间)导入到另一个数据库中

To move or copy a set of tablespaces into a primary database when a physical standby is being used, perform the following steps:  >>>>下面是使用transportable tablespace功能向DG的主库中导入数据时的步骤：

1. Generate a transportable tablespace set that consists of datafiles for the set of tablespaces being transported and an export file containing structural information for the set of tablespaces.  >>>>导出需要传输的表空间的结构信息

2. Transport the tablespace set:

   1. Copy the datafiles and the export file to the primary database.  >>>>复制需要传输的表空间的数据文件和导出的结构信息到DG的主库。

   2. Copy the datafiles to the standby database.  >>>>复制需要传输的表空间的数据文件到备库。

   The data files must have the same path name on the primary and standby databases unless the DB_FILE_NAME_CONVERT database initialization parameter has been configured. If DB_FILE_NAME_CONVERT has not been configured and the path names of the data files are not the same on the primary and standby databases, issue the ALTER DATABASE RENAME FILE statement to rename the data files. Do this after Redo Apply has failed to apply the redo generated by plugging the tablespace into the primary database. The STANDBY_FILE_MANAGEMENT initialization parameter must be set to MANUAL before renaming the data files, and should be reset to the previous value after renaming the data files.  >>>>除非备库上DB_FILE_NAME_CONVERT参数被正确配置，否则需要主库和备库的数据文件存放路径是相同的。如果主备库的数据文件存放路径不同，并且DB_FILE_NAME_CONVERT参数也未配置，在主库上传输表空间操作所产生的日志已经在备库上应用以后，对备库上不正确的数据文件进行重命名(alter database rename file),当然再进行重命名之操作之前，需要先把备库的STANDBY_FILE_MANAGEMENT参数改为MANUAL，记得在重命名完成后把备库的STANDBY_FILE_MANAGEMENT参数值改回来。

3. Plug in the tablespace.

   Invoke the Data Pump utility to plug the set of tablespaces into the primary database. Redo data will be generated and applied at the standby site to plug the tablespace into the standby database.  >>>>通过调用数据泵把需要导入的表空间加入到DG的主库。备库上会应用主库产生的日志，把相应的表空间加入备库。(传输表空间这里就不重点介绍了，后面有机会再介绍)

For more information about transportable tablespaces, see Oracle Database Administrator's Guide.

9.3.4 Renaming a Datafile in the Primary Database

When you rename one or more datafiles in the primary database, the change is not propagated to the standby database. Therefore, if you want to rename the same datafiles on the standby database, you must manually make the equivalent modifications on the standby database because the modifications are not performed automatically, even if the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO.  >>>>DG中对主库数据文件的rename操作不会被传播到备库。因此如果你对主库上某个数据文件做了rename，那么你需要手动的在备库上作相应的修改，即使备库上STANDBY_FILE_MANAGEMENT参数被设置为auto。

The following steps describe how to rename a datafile in the primary database and manually propagate the changes to the standby database.  >>>>下面是rename主库数据文件，及手动rename备库数据文件的步骤

1. To rename the datafile in the primary database, take the tablespace offline:  >>>>在主库把需要rename的数据文件表空间rename(如果只offline某些数据文件的话，在online数据文件之前需要先recover datafile file#)

   SQL> ALTER TABLESPACE tbs_4 OFFLINE;
   

2. Exit from the SQL prompt and issue an operating system command, such as the following UNIX mv command, to rename the datafile on the primary system:  >>>>表空间offline以后，在操作系统层面使用mv 对数据文件进行重命名：

   % mv /disk1/oracle/oradata/payroll/tbs_4.dbf 
   /disk1/oracle/oradata/payroll/tbs_x.dbf
   

3. Rename the datafile in the primary database and bring the tablespace back online:  >>>>在主库使用alter tablespace xxxx rename datafile 'xxx' to 'xxx';对数据文件进行重命名，并把表空间online

   SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE -
   > '/disk1/oracle/oradata/payroll/tbs_4.dbf' -
   >  TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
   
   SQL> ALTER TABLESPACE tbs_4 ONLINE;
   

4. Connect to the standby database and stop Redo Apply:

   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;  >>>>停备库的恢复管理
   

5. Shut down the standby database:

   SQL> SHUTDOWN;  >>>>停备库实例
   

6. Rename the datafile at the standby site using an operating system command, such as the UNIX mv command:  >>>>在操作系统层面使用mv命令对数据文件进行重命名

   % mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
   

7. Start and mount the standby database:  >>>>启动备库到mount状态

   SQL> STARTUP MOUNT;
   

8. Rename the datafile in the standby control file. Note that the STANDBY_FILE_MANAGEMENT database initialization parameter must be set to MANUALin order to rename a datafile. This parameter can be reset to its previous value after renaming a datafile.    >>>>使用 alter database rename file 'xxx' to 'xxx';命令对备库数据文件进行重命名

   SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf' -
   > TO '/disk1/oracle/oradata/payroll/tbs_x.dbf'; >>>>因为备库处于mount状态所以不能像主库一样使用 alter tablespace xxx rename datafile命令
   

9. On the standby database, restart Redo Apply:

   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
   > DISCONNECT FROM SESSION; >>>>恢复数据库恢复管理
   

If you do not rename the corresponding datafile at the standby system, and then try to refresh the standby database control file, the standby database will attempt to use the renamed datafile, but it will not find it. Consequently, you will see error messages similar to the following in the alert log:  >>>>如果在主库对数据文件进行了rename操作以后，没有手动的在备库对相应的数据文件进行rename操作，那么在备库用到相应数据文件时会在alert日志中出现如下错误(如果不使用相应的数据文件，不会触发该错误)

ORA-00283: recovery session canceled due to errors
ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file
ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'

9.3.5 Add or Drop a Redo Log File Group

The configuration of the redo log and standby redo log on a physical standby database should be reevaluated and adjusted as necessary after adding or dropping a log file group on the primary database.  >>>>如果你对DG中主库的日志组做了变更，那么需要重新评估一下备库的redo log和standby redo log是否需要作出合适的调整(当然备库的调整也是需要手动完成的，主库操对日志文件的变动作不会被传到备库)

Take the following steps to add or drop a log file group or standby log file group on a physical standby database:  >>>>下面是备库添加或者删除redo 日志组和 standby 日志组的方法：

1. Stop Redo Apply.  >>>>首先停备库恢复管理(alter database recover managed standby database cancel;)

2. If the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO, change the value to MANUAL.  >>>>修改备库STANDBY_FILE_MANAGEMENT参数为manual

3. Add or drop a log file group. >>>>添加日志组ALTER DATABASE ADD LOGFILE THREAD 1 group 7('/data01/onlinelog/redo07a.log','/data02/egapdb/redo07b.log') SIZE 200M;
   删除日志组 ALTER DATABASE DROP LOGFILE GROUP 1;

   Note:

   An online logfile group must always be manually cleared before it can be dropped from a physical standby database. For example:

   ALTER DATABASE CLEAR LOGFILE GROUP 3;
   

   An online logfile group that has a status of CURRENT or CLEARING_CURRENT cannot be dropped from a physical standby database. An online logfile group that has this status can be dropped after a role transition. >>>>注意：
   删除备库上的online 日志组前要先手动的cleared日志组。例如：
   ALTER DATABASE CLEAR LOGFILE GROUP 3;
   日志状态为current和clearing_current的日志组不能在备库上删除，这样的日志可以在主备库角色转换以后再删除。(个人认为可以在主库执行alter system archive log current;进行日志状态切换，备库的日志状态也会跟着变化，把备库current日志变为clearing后进行删除)

4. Restore the STANDBY_FILE_MANAGEMENT initialization parameter and the Redo Apply options to their original states.  >>>>修改备库的STANDBY_FILE_MANAGEMENT参数为auto

5. Restart Redo Apply.  >>>>数据备库恢复管理(alter database recover managed standby database using current logfile disconnect;)

9.3.6 NOLOGGING or Unrecoverable Operations

When you perform a DML or DDL operation using the NOLOGGING or UNRECOVERABLE clause, the standby database is invalidated and may require substantial DBA administrative activities to repair. You can specify the SQL ALTER DATABASE or SQL ALTER TABLESPACE statement with the FORCELOGGING clause to override the NOLOGGING setting. However, this statement will not repair an already invalidated database.  >>>>这里主要讲nologging模式的dml和unrecoverable模式的ddl语句，会造成备库失败。但是这个不需要担心，因为安装官方文档的要求，在搭建DG的时候就需要设置主库被的force logging模式，这样就可以避免这类错误的发生

See Section 13.4 for information about recovering after the NOLOGGING clause is used.

9.3.7 Refresh the Password File

If the REMOTE_LOGIN_PASSWORDFILE database initialization parameter is set to SHARED or EXCLUSIVE, the password file on a physical standby database must be replaced with a fresh copy from the primary database after granting or revoking administrative privileges or changing the password of a user with administrative privileges.  >>>>如果备库的REMOTE_LOGIN_PASSWORDFILE设置为SHARED或者EXCLUSIVE，那么在主库上授予或者收回某个用户sysdba权限以及修改具有dba权限用户的密码后需要用主库的密码文件覆盖备库的密码文件。

Failure to refresh the password file on the physical standby database may cause authentication of redo transport sessions or connections as SYSDBA or SYSOPER to the physical standby database to fail.  >>>>如果在上面所说的情况下，没有用主库的密码文件替换备库的密码文件，那么可能会导致日志传输及登陆备库时发生认证失败(自己试验验证了一下，授予或者收回普通用户的sysdba权限不会导致日志传输失败。如果修改主库的sys用户的密码在主库或者备库实例重启后，日志传输会出现问题。没有重启之前因为连接已经建立所以依然能正常传输日志)

9.3.8 Reset the TDE Master Encryption Key

The database encryption wallet on a physical standby database must be replaced with a fresh copy of the database encryption wallet from the primary database whenever the TDE master encryption key is reset on the primary database.

Failure to refresh the database encryption wallet on the physical standby database will prevent access to encrypted columns on the physical standby database that are modified after the master encryption key is reset on the primary database.

##出自

http://docs.oracle.com/cd/E11882_01/server.112/e41134/manage_ps.htm#SBYDB4784