Actions Required on a Standby Database After Changes to a 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. The following describe how to rename a datafile in the primary database and manually propagate the changes to the standby database. If you do not want the standby database to have the same physical structure as the primary database, then these steps are not required.
Rename the datafile in the standby control file. Note that the STANDBY_FILE_MANAGEMENT initialization parameter must be set to MANUAL.
1. rename datafile at Primary
2. rename datafuke at standby at mount mode
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf'
2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
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:
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'
--------------------------------------------------------------------------------
Caution: Whenever you add an online redo log file to the primary database, you must add a corresponding standby redo log file to the standby database.
--------------------------------------------------------------------------------
For example, if the primary database has 10 online redo log files and the standby database has 2, and then you switch over to the standby database so that it functions as the new primary database, the new primary database is forced to archive more frequently than the original primary database. Consequently, when you add or drop an online redo log file at the primary site, it is important that you synchronize the changes in the standby database by following these steps:
If Redo Apply is running, you must cancel Redo Apply before you can change the log files.
If the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO, change the value to MANUAL.
Add or drop an online redo log file:
To add an online redo log file, use a SQL statement such as this:
SQL> ALTER DATABASE ADD LOGFILE
'/disk1/oracle/oradata/payroll/prmy3.log' SIZE 100M;
To drop an online redo log file, use a SQL statement such as this:
SQL> ALTER DATABASE DROP LOGFILE
'/disk1/oracle/oradata/payroll/prmy3.log';
Repeat the statement you used in Step 3 on each standby database. Restore the STANDBY_FILE_MANAGEMENT initialization parameter and the Redo Apply options to their original states.
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.To move or copy a set of tablespaces when a physical standby is being used, perform the following steps:
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.
Transport the tablespace set:
Copy the datafiles and the export file to the primary database.
Copy the datafiles to the standby database.
The datafiles must be to the directory defined by the DB_FILE_NAME_CONVERT initialization parameter. If DB_FILE_NAME_CONVERT is not defined, then issue the ALTER DATABASE RENAME FILE statement to modify the standby control file after the redo data containing the transportable tablespace was applied and failed. The STANDBY_FILE_MANAGEMENT initialization parameter must be set to AUTO.
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
If you perform an unrecoverable operation (such as a direct path load), you will see a performance improvement on the primary database; but there is no corresponding recovery process performance improvement on the standby database, and you will have to move the data manually to the standby database
When the archived redo log file is copied to the standby site and applied to the physical standby database, a portion of the datafile is unusable and is marked as being unrecoverable. When you either fail over to the physical standby database, or open the standby database for read-only access, and attempt to read the range of blocks that are marked as UNRECOVERABLE, you will see error messages similar to the following:
ORA-01578: ORACLE data block corrupted (file # 1, block # 2521)
ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option
To recover after the NOLOGGING clause is specified, you need to copy the datafile that contains the unjournaled data from the primary site to the physical standby site. Perform the following steps:
Step 1 Determine which datafiles should be copied.
Follow these steps:
Query the primary database:
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
NAME UNRECOVERABLE
----------------------------------------------------- -------------
/oracle/dbs/tbs_1.dbf 5216
/oracle/dbs/tbs_2.dbf 0
/oracle/dbs/tbs_3.dbf 0
/oracle/dbs/tbs_4.dbf 0
4 rows selected.
Query the standby database:
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
NAME UNRECOVERABLE
----------------------------------------------------- -------------
/oracle/dbs/stdby/tbs_1.dbf 5186
/oracle/dbs/stdby/tbs_2.dbf 0
/oracle/dbs/stdby/tbs_3.dbf 0
/oracle/dbs/stdby/tbs_4.dbf 0
4 rows selected.
Compare the query results of the primary and standby databases.
Compare the value of the UNRECOVERABLE_CHANGE# column in both query results. If the value of the UNRECOVERABLE_CHANGE# column in the primary database is greater than the same column in the standby database, then the datafile needs to be copied from the primary site to the standby site.
In this example, the value of the UNRECOVERABLE_CHANGE# in the primary database for the tbs_1.dbf datafile is greater, so you need to copy the tbs_1.dbf datafile to the standby site.
Step 2 On the primary site, back up the datafile you need to copy to the standby site.
Issue the following SQL statements:
SQL> ALTER TABLESPACE system BEGIN BACKUP;
% cp tbs_1.dbf /backup
SQL> ALTER TABLESPACE system END BACKUP;
Step 3 On the standby database, restart Redo Apply.
Issue the following SQL statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
You might get the following error messages (possibly in the alert log) when you try to restart Redo Apply:
ORA-00308: cannot open archived log 'standby1'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'
If you get the ORA-00308 error and Redo Apply does not terminate automatically, you can cancel recovery by issuing the following statement from another terminal window:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
These error messages are returned when one or more log files in the archive gap have not been successfully applied. If you receive these errors, manually resolve the gaps, and repeat Step 3. See Section 5.8.4 for information about manually resolving an archive gap.
Determining If a Backup Is Required After Unrecoverable Operations
If you performed unrecoverable operations on your primary database, determine if a new backup operation is required by following these steps:
Query the V$DATAFILE view on the primary database to determine the system change number (SCN) or the time at which the Oracle database generated the most recent invalidated redo data.
Issue the following SQL statement on the primary database to determine if you need to perform another backup:
SELECT UNRECOVERABLE_CHANGE#,
TO_CHAR(UNRECOVERABLE_TIME, 'mm-dd-yyyy hh:mi:ss')
FROM V$DATAFILE;
If the query in the previous step reports an unrecoverable time for a datafile that is more recent than the time when the datafile was last backed up, then make another backup of the datafile in question.
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. The following describe how to rename a datafile in the primary database and manually propagate the changes to the standby database. If you do not want the standby database to have the same physical structure as the primary database, then these steps are not required.
Rename the datafile in the standby control file. Note that the STANDBY_FILE_MANAGEMENT initialization parameter must be set to MANUAL.
1. rename datafile at Primary
2. rename datafuke at standby at mount mode
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf'
2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
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:
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'
Adding or Dropping Online Redo Log Files
Changing the size and number of the online redo log files is sometimes done to tune the database. You can add online redo log file groups or members to the primary database without affecting the standby database. Similarly, you can drop log file groups or members from the primary database without affecting your standby database. However, these changes do affect the performance of the standby database after switchover.
--------------------------------------------------------------------------------
Caution: Whenever you add an online redo log file to the primary database, you must add a corresponding standby redo log file to the standby database.
--------------------------------------------------------------------------------
For example, if the primary database has 10 online redo log files and the standby database has 2, and then you switch over to the standby database so that it functions as the new primary database, the new primary database is forced to archive more frequently than the original primary database. Consequently, when you add or drop an online redo log file at the primary site, it is important that you synchronize the changes in the standby database by following these steps:
If Redo Apply is running, you must cancel Redo Apply before you can change the log files.
If the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO, change the value to MANUAL.
Add or drop an online redo log file:
To add an online redo log file, use a SQL statement such as this:
SQL> ALTER DATABASE ADD LOGFILE
'/disk1/oracle/oradata/payroll/prmy3.log' SIZE 100M;
To drop an online redo log file, use a SQL statement such as this:
SQL> ALTER DATABASE DROP LOGFILE
'/disk1/oracle/oradata/payroll/prmy3.log';
Repeat the statement you used in Step 3 on each standby database. Restore the STANDBY_FILE_MANAGEMENT initialization parameter and the Redo Apply options to their original states.
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.To move or copy a set of tablespaces when a physical standby is being used, perform the following steps:
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.
Transport the tablespace set:
Copy the datafiles and the export file to the primary database.
Copy the datafiles to the standby database.
The datafiles must be to the directory defined by the DB_FILE_NAME_CONVERT initialization parameter. If DB_FILE_NAME_CONVERT is not defined, then issue the ALTER DATABASE RENAME FILE statement to modify the standby control file after the redo data containing the transportable tablespace was applied and failed. The STANDBY_FILE_MANAGEMENT initialization parameter must be set to AUTO.
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
Altering the Primary Database Control
FileUsing the SQL CREATE CONTROLFILE statement with the RESETLOGS option on your primary database will force the primary database to reset the online redo log file the next time the primary database is opened, thereby invalidating the standby database.
If you invalidated the control file for the standby database, re-create the file. If you invalidated the standby database, you must re-create the standby database.NOLOGGING or Unrecoverable Operations
When you perform a DML or DDL operation using the NOLOGGING or UNRECOVERABLE clause, the standby database is invalidated and might 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.If you perform an unrecoverable operation (such as a direct path load), you will see a performance improvement on the primary database; but there is no corresponding recovery process performance improvement on the standby database, and you will have to move the data manually to the standby database
When the archived redo log file is copied to the standby site and applied to the physical standby database, a portion of the datafile is unusable and is marked as being unrecoverable. When you either fail over to the physical standby database, or open the standby database for read-only access, and attempt to read the range of blocks that are marked as UNRECOVERABLE, you will see error messages similar to the following:
ORA-01578: ORACLE data block corrupted (file # 1, block # 2521)
ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option
To recover after the NOLOGGING clause is specified, you need to copy the datafile that contains the unjournaled data from the primary site to the physical standby site. Perform the following steps:
Step 1 Determine which datafiles should be copied.
Follow these steps:
Query the primary database:
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
NAME UNRECOVERABLE
----------------------------------------------------- -------------
/oracle/dbs/tbs_1.dbf 5216
/oracle/dbs/tbs_2.dbf 0
/oracle/dbs/tbs_3.dbf 0
/oracle/dbs/tbs_4.dbf 0
4 rows selected.
Query the standby database:
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
NAME UNRECOVERABLE
----------------------------------------------------- -------------
/oracle/dbs/stdby/tbs_1.dbf 5186
/oracle/dbs/stdby/tbs_2.dbf 0
/oracle/dbs/stdby/tbs_3.dbf 0
/oracle/dbs/stdby/tbs_4.dbf 0
4 rows selected.
Compare the query results of the primary and standby databases.
Compare the value of the UNRECOVERABLE_CHANGE# column in both query results. If the value of the UNRECOVERABLE_CHANGE# column in the primary database is greater than the same column in the standby database, then the datafile needs to be copied from the primary site to the standby site.
In this example, the value of the UNRECOVERABLE_CHANGE# in the primary database for the tbs_1.dbf datafile is greater, so you need to copy the tbs_1.dbf datafile to the standby site.
Step 2 On the primary site, back up the datafile you need to copy to the standby site.
Issue the following SQL statements:
SQL> ALTER TABLESPACE system BEGIN BACKUP;
% cp tbs_1.dbf /backup
SQL> ALTER TABLESPACE system END BACKUP;
Step 3 On the standby database, restart Redo Apply.
Issue the following SQL statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
You might get the following error messages (possibly in the alert log) when you try to restart Redo Apply:
ORA-00308: cannot open archived log 'standby1'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'
If you get the ORA-00308 error and Redo Apply does not terminate automatically, you can cancel recovery by issuing the following statement from another terminal window:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
These error messages are returned when one or more log files in the archive gap have not been successfully applied. If you receive these errors, manually resolve the gaps, and repeat Step 3. See Section 5.8.4 for information about manually resolving an archive gap.
Determining If a Backup Is Required After Unrecoverable Operations
If you performed unrecoverable operations on your primary database, determine if a new backup operation is required by following these steps:
Query the V$DATAFILE view on the primary database to determine the system change number (SCN) or the time at which the Oracle database generated the most recent invalidated redo data.
Issue the following SQL statement on the primary database to determine if you need to perform another backup:
SELECT UNRECOVERABLE_CHANGE#,
TO_CHAR(UNRECOVERABLE_TIME, 'mm-dd-yyyy hh:mi:ss')
FROM V$DATAFILE;
If the query in the previous step reports an unrecoverable time for a datafile that is more recent than the time when the datafile was last backed up, then make another backup of the datafile in question.
Posts
