Oracle DG manages primary library events that affect physical standby

In most cases, modifications to the primary database will be propagated to the physical standby database and applied without the need for additional operations on the physical standby side, except that, depending on the actual configuration, some operations are not propagated to the standby end. But the dissemination of the past, but not the correct implementation, the most common is the table space and log file management operations, the following through an example to illustrate one by one.

1. Create a table space or data file

The initialization parameter standby_file_management is used to control whether the primary database is automatically added to the physical standby database by adding a table space or a data file change. This parameter has two values:

Auto: If the parameter value is set to auto, the table space creation operations performed by the primary database are also propagated to the physical standby database for execution.

MANUAL: If set to MANUAL or not set any value (the default is MANUAL), you need to manually copy the newly created data file to the physical standby server.

Note: The Standby_file_management parameter refers specifically to the primary database-side table space or data file creation, if the data file is replicated from another database (for example, through TTS transfer tablespace), regardless of the Standby_file_ The management parameter values must be manually copied to the standby database, and the control files for the physical standby database are rebuilt.

2, delete the table space

When you delete a tablespace from the primary database, it affects the data files and tablespaces of the physical standby database, and the initialization parameter Standby_file_management property value setting determines whether the event requires DBA intervention.

When Standby_file_management is set to Auto.

sql> ALTER SYSTEM SET Standby_file_management=auto;

System altered.

To perform an operation to delete a tablespace on the primary database side:

Sql> DROP tablespace TEST including CONTENTS and datafiles;

Tablespace dropped.

Note: including the datafiles clause, Oracle will automatically delete the corresponding physical file when the tablespace is deleted.

The initialization parameter standby_file_managment is set to auto, and the physical standby is handled well without the manual intervention of the DBA for Tablespace and data file operations.

When the Standby_file_management parameter is set to manual, even if the DBA adds a including datafiles clause when performing a delete operation on the primary database side, The standby database will still only remove tablespaces and data files from the data dictionary, and the physical files involved in the tablespace will still need to be deleted manually.

For the file system, we can set the initialization parameter standby_file_managment to auto, but for raw devices, this parameter can only be set to manual.

3. Renaming data files

If the primary database renames one or more data files, the modification does not automatically propagate to the standby database. Even if set the initialization parameter standby_file_management equal to auto also not, want to let standby data file and primary keep consistent, only manual operation.

Here is a sample demonstration of the following steps:

First offline The tablespace that contains the data file you want to rename:

sql> ALTER tablespace Scott_tbs OFFLINE;

Tablespace altered.

Then manually modify the data file name. There are a lot of ways to use the Rename command from the operating system directly (the MV command is available under the Linux platform):

sql> HOST RENAME f:/oracle/oradata/test/scott_tbs01.dbf scott01.dbf

Back to the column page: http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/

Modify the data file path in the data dictionary by command, and then the online table space:

sql> ALTER tablespace Scott_tbs RENAME datafile

2 ' f:/oracle/oradata/test/scott_tbs01.dbf ' to

3 ' f:/oracle/oradata/test/scott01.dbf ';

Tablespace altered.

sql> ALTER tablespace Scott_tbs ONLINE;

Tablespace altered.

Sql> SELECT NAME from V$datafile;

NAME

--------------------------------------------------

f:/oracle/oradata/test/scott01. Dbf

To switch logs:

sql> ALTER SYSTEM SWITCH LOGFILE;

System altered.

To view the current data file path on the physical standby side:

Sql> SELECT NAME from V$datafile;

NAME

--------------------------------------------------

L:/oradata/jsspdg/scott_tbs01. Dbf

The data file on the standby database is still the original path and has not been modified, so only the DBA can intervene in manual modification. The steps are as follows:

First Pause Redo Application:

sql> ALTER database RECOVER MANAGED STANDBY database CANCEL;

Database altered.

To rename a data file manually:

sql> HOST REN l:/oradata/test/scott_tbs01.dbf scott01.dbf

Then modify the path of the data file in the data dictionary:

sql> ALTER DATABASE RENAME FILE

2 ' l:/oradata/test/scott_tbs01. DBF ' to

3 ' l:/oradata/test/scott01. DBF ';

Database altered.

Finally, the redo application of the standby database can be restarted:

sql> ALTER database RECOVER MANAGED STANDBY database DISCONNECT from session;

Database altered.

4. Add or remove redologs files

Database tuning is highly likely to involve resetting the log file size or increasing the deletion of log groups, which can also be propagated to the physical standby database if the Standby_file_management parameter value is set to Auto. In general, however, you can ignore the setting of the Standby_file_management parameter, because regardless of whether the operation of the primary to the log group or log file is propagated to the physical standby database, the physical standby database is not affected. But if you don't pay attention to the relationship, the impact can be far-reaching.

It is usually recommended that when you add or remove online redologs from the primary database, you must remember to manually synchronize the relevant settings in the related physical standby database, and also consider the relationship between standby redologs and online redologs. That is to ensure that standby redologs than the online redologs to at least one more group.

Note that it is important to set the Standby_file_management to manual before standby the database, and if the log files of the physical standby database are different from the primary database path, the initialization parameters should be log_file _name_convert the settings for automatic conversion.

5, the application of the cross open Resetlogs

In some cases, when the primary database is opened in resetlogs mode, it will not affect the configuration of the data guard, standby the database without human involvement, automatically apply the open resetlogs operation, Continue to receive and apply the log generated after the primary database open resetlogs.

Of course, this is conditional, not all cases can be so intelligent. We know that after the execution of the ALTER DATABASE OPEN Resetlogs statement, the incarnation of the database is reset, that is, the sequence ordinal of its standby database is also set from the beginning. Of course, the physical standby database does not pay attention to this, it is only faithfully followed the footsteps of the primary database, step-by-step implementation of the primary database has been done, so when it received new redo data, it will automatically apply this part of the redo data.

Normally this logic is fine, but after primary has executed the open resetlogs, it is restored to the state before the open Resetlogs by backup. Depending on the specific configuration of the physical standby (how the configuration determines whether the physical standby is likely to return to the state before the Open resetlogs), the situation can be much more complicated.

The graph shows the effect of primary database Resetlogs operation on standby

Author: 51cto Blog Oracle Little Bastard