To prevent possible problems, you must be aware of events on the primary database that affect a standby database and learn how to respond to them. This section describes these events and the recommended responses to these events.
In some cases, the events or changes that occur on a primary database are automatically propagated through redo data to the standby database and thus require no extra action on the standby database. In other cases, you might need to perform maintenance tasks on the standby database.
Table 8-1 indicates whether or not a change made on the primary database requires additional intervention by the database administrator (DBA) to be propagated to the standby database. It also briefly describes how to respond to these events. Detailed descriptions of the responses are described in the section references provided.
The following events are automatically administered by redo transport services and Redo Apply, and therefore require no intervention by the database administrator:
A SQL ALTER DATABASE statement is issued with the ENABLE THREAD or DISABLE THREAD clause.
The status of a tablespace changes (changes to read/write or read-only, placed online or taken offline).
A datafile is added or tablespace is created when the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO.
Table 8-1 Actions Required on a Standby Database After Changes to a Primary Database
Section 8.3.1
Add a datafile or create a tablespace
添加文件或創建表空間
If you did not set the STANDBY_FILE_MANAGEMENT initialization parameter to AUTO, you must copy the new datafile to the standby database.
如果STANDBY_FILE_MANAGEMENT初始化參數沒有設置為AUTO，那麼你必須將新的數據文件拷貝到備庫
Section 8.3.2
Drop or delete a tablespace or datafile
刪除表空間或數據文件
Delete datafiles from primary and standby databases after the archived redo log file containing the DROP or DELETE command was applied.
從主庫刪除數據文件，備庫機會應用包含DROP或者DELETE命令的歸檔重做日志來應用
Section 8.3.3
Use transportable tablespaces
使用傳輸表空間
Move tablespaces between the primary and standby databases.
在主備庫之間移動表空間
Section 8.3.4
Rename a datafile
重命名一個數據文件
Rename the datafile on the standby database.
在備庫重命令數據文件
Section 8.3.5
Add or drop redo log files
添加或刪除重做日志文件愛你
Synchronize changes on the standby database.
在備庫上同步改變
Section 8.3.6
Perform a DML or DDL operation using the NOLOGGING or UNRECOVERABLE clause
使用NOLOGGING 或者UNRECOVERABLE 執行DML或者DDL操作，
Send the datafile containing the unlogged changes to the standby database.
向備庫發送包含沒有日志記錄的文件
Chapter 13
Change initialization parameters
改變初始化參數
Dynamically change the standby parameters or shut down the standby database and update the initialization parameter file.
動態的改變備用的參數或者關閉備庫，再更新初始化參數文件
The initialization parameter, STANDBY_FILE_MANAGEMENT, enables you to control whether or not adding a datafile to the primary database is automatically propagated to the standby database, as follows:
STANDBY_FILE_MANAGEMENT初始化參數文件，能使用控制是否在添加數據文件到主庫自動傳播到備庫，如下：
If you set the STANDBY_FILE_MANAGEMENT initialization parameter in the standby database server parameter file (SPFILE) to AUTO, any new datafiles created on the primary database are automatically created on the standby database as well.
如果STANDBY_FILE_MANAGEMENT這個初始化參數文件在備庫中的spfile是AUTO，那麼任何在主庫上新創建的數據文件會自動的在備庫創建。
If you do not specify the STANDBY_FILE_MANAGEMENT initialization parameter or if you set it to MANUAL, then you must manually copy the new datafile to the standby database when you add a datafile to the primary database.
如果STANDBY_FILE_MANAGEMENT沒有設置或者設置為MANUAL，那麼當你在主庫添加數據文件時，你必須手動拷貝新的數據文件到備庫
Note that if you copy an existing datafile from another database to the primary database, then you must also copy the new datafile to the standby database and re-create the standby control file, regardless of the setting of STANDBY_FILE_MANAGEMENT initialization parameter.
注意，如果你從另一個數據庫已存在的數據文件拷貝到到主庫，那麼你必須也要拷貝到倒庫，然後重新創建備用控制文件，除非你設置了STANDBY_FILE_MANAGEMENT 初始化參數。
The following sections provide examples of adding a datafile to the primary and standby databases when the STANDBY_FILE_MANAGEMENTinitialization parameter is set to AUTO and MANUAL, respectively.
按以下提供的例子來添加一個數據文件到主庫，備庫的STANDBY_FILE_MANAGEMENT分別設置為AUTO和MANUAL。
The following example shows the steps required to add a new datafile to the primary and standby databases when the STANDBY_FILE_MANAGEMENTinitialization parameter is set to AUTO.
以下的例子給出了主庫添加一個數據文件，備庫的STANDBY_FILE_MANAGEMENT為AUTO時的步驟。
Add a new tablespace to the primary database:
1.添加一個新的表空間到主庫：
SQL> CREATE TABLESPACE new_ts DATAFILE '/disk1/oracle/oradata/payroll/t_db2.dbf' 2> SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED;Archive the current online redo log file so the redo data will be transmitted to and applied on the standby database:
歸檔當前現在重做日志，這樣，重做日志會傳輸到備庫，並且備庫會應用傳輸過來的日志：
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;Verify the new datafile was added to the primary database:
3.驗證新的數據文件被添加到主庫：
SQL> SELECT NAME FROM V$DATAFILE; NAME ---------------------------------------------------------------------- /disk1/oracle/oradata/payroll/t_db1.dbf /disk1/oracle/oradata/payroll/t_db2.dbfVerify the new datafile was added to the standby database:
驗證信的數據文件被添加到備庫：
SQL> SELECT NAME FROM V$DATAFILE; NAME ---------------------------------------------------------------------- /disk1/oracle/oradata/payroll/s2t_db1.dbf /disk1/oracle/oradata/payroll/s2t_db2.dbfThis section shows how to add a new datafile to the primary and standby database when the STANDBY_FILE_MANAGEMENT initialization parameter is set to MANUAL. You must set the STANDBY_FILE_MANAGEMENT initialization parameter to MANUAL when the standby datafiles reside on raw devices. This section also describes how to recover from errors after they have occurred.
這個部分展示的是添加一個新的數據文件到主庫，而備庫的STANDBY_FILE_MANAGEMENT參數設置為MAUNAL，當備庫的數據文件放在裸設備時，你必須將STANDBY_FILE_MANAGEMENT初始化參數設置為MANUAL。這部分也描述怎麼恢復遇到的錯誤。
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 initialization parameter to convert the path names. 數據庫在OMF管理時不要使用以下的步驟，同樣，如果裸設備路徑不跟主庫和備庫的一樣，使用DB_FILE_NAME_CONVERT初始化參數來轉換路徑的名稱。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 initialization parameter will continue to work, but manual intervention is needed. This manual intervention involves ensuring the raw devices exist before log apply services on the standby database recover 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:
STANDBY_FILE_MANAGEMENT設置為AUTO，無論什麼時候在主庫上添加或刪掉新的數據文件，備庫不用人工干預相應的改變即可發生在備庫。這是針對於備庫為文件系統才行的。如果備庫使用裸設備來放數據文件，那麼 STANDBY_FILE_MANAGEMENT參數將繼續工作，但是手動干預是必須的。這個手動干預包括確定裸設備是否存在在備庫上日志應用服務恢復創建新的數據文件的重做日志。在主庫上，在裸設備上創建一個新的表空間，同時，在備庫創建相同的裸設備，例如：
SQL> CREATE TABLESPACE MTS2 DATAFILE '/dev/raw/raw100' size 1m; Tablespace created. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered.The standby database automatically adds the datafile as the raw devices exist. The standby alert log shows the following:
備庫自動添加數據文件到以存在的裸設備，備用告警之日如下：
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 the MRP process will shut down due to file-creation errors. For example, issue the following statements on the primary database:
然而，如果在主庫上創建了裸設備而沒有在備庫上創建裸設備，那麼MRP進程會因為文件創建錯誤而關閉，例如，在主庫上發出以下語句：
SQL> CREATE TABLESPACE MTS3 DATAFILE '/dev/raw/raw101' size 1m; Tablespace created. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered.The standby system does not have the /Dave/raw/raw101 raw device created. The standby alert log shows the following messages when recovering the archive:
備用系統沒有創建/dev/raw/raw101這個裸設備，備用告警日志如下：
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...To correct the problems described in Section 8.3.1.2.1, perform the following steps:
修改上節提到的錯誤，執行以下步驟：
Create the raw device on the standby database and assign permissions to the Oracle user.
在備庫上創建裸設備，賦予oracle用戶權限
Query the V$DATAFILE view. For example:
SQL> SELECT NAME FROM 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; SQL> ALTER DATABASE CREATE DATAFILE 2 '/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007' 3 AS 4 '/dev/raw/raw101';In the standby alert log you should see information similar to the following:
在備用告警日志裡你應該會看見以下相似的信息：
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' aOn the standby database, set STANDBY_FILE_MANAGEMENT to AUTO and restart Redo Apply:
在備庫，設置STANDBY_FILE_MANAGEMENT 為AUTO，然後重新啟用重做應用：
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO; SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT;At this point Redo Apply uses the new raw device datafile and recovery continues.
在這一點，重做應用使用新的裸設備上的數據文件並繼續恢復。
