您的位置:首页 > 其它

11g Data Guard为什么要将standby_file_management设置为auto

2016-03-31 15:45 429 查看
我们在搭建DataGuard的时候,会将参数standby_file_management设置为auto,备库管理可以带来很多方便;该参数的另一个选项manual,则需要手动进行copy。

文档内容如下:

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.

■ 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.

■ 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是与Primary进行实时同步,主备库数据文件目录一致;而后对该参数进行修改,设置为manual,具体步骤如下:

主库创建数据文件

Primary:

SQL> create tablespace test DATAFILE '/u01/app/oracle/oradata/king/test.dbf' size 1M;

Tablespace created.

Standby:

SQL> show parameter standby

NAME TYPE
VALUE
------------------------------------ ----------- ------------------------------
standby_archive_dest
string ?/dbs/arch
standby_file_management
string MANUAL

实时同步的情况下,备库下对该对象查询

发现文件被默认创建在了$ORACLE_HOME/dbs下,但是该目录下该物理文件是不存在的

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/king/system01.dbf
/u01/app/oracle/oradata/king/sysaux01.dbf
/u01/app/oracle/oradata/king/undotbs01.dbf
/u01/app/oracle/oradata/king/users01.dbf
/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00005

查看日志,无法进行恢复

无法继续进行media recovery,日志报错信息:

Tue Dec 29 22:53:57 2015
MRP0 started with pid=28, OS id=6860
MRP0: Background Managed Standby Recovery process started (king)
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
MRP0: Background Media Recovery terminated with error 1111
Errors in file /u01/app/oracle/diag/rdbms/kinged/king/trace/king_mrp0_6860.trc:
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00005'
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00005'
Managed Standby Recovery not using Real Time Apply
MRP0: Background Media Recovery process shutdown (king)
Completed: ALTER DATABASE RECOVER managed standby database using current logfile disconnect from session

手动添加该文件

SQL> alter database create datafile '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00005' as '/u01/app/oracle/oradata/king/test.dbf';

Database altered.

备库再次查看文件

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/king/system01.dbf
/u01/app/oracle/oradata/king/sysaux01.dbf
/u01/app/oracle/oradata/king/undotbs01.dbf
/u01/app/oracle/oradata/king/users01.dbf
/u01/app/oracle/oradata/king/test.dbf

总结:

如果设置为auto,主库增删文件会相应地自动在备库做出修改(结合convert参数);
如果设置为manual,当在primary删除表空间或数据文件,执行drop tablespace .. including contents and datafiles,
standby 只是在控制文件中将该文件删除,还需要手动将物理文件删除
如下:

Wed Dec 30 01:48:53 2015
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=BOTH;
Wed Dec 30 01:49:07 2015
Recovery deleting file #5:'/u01/app/oracle/oradata/king/test.dbf' from controlfile.
Recovery dropped tablespace 'TEST'
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: