搭建完了ORACLE 11G dataguard后，也做了角色切换的实验，有switchover已经failover，感觉受益颇多，而后继续研究了下dataguard的一些高级管理功能，所谓冰山一角，ORACLE果然博大精深，总结记录如下：
1，ORACLE 11G dataguard的高级管理
1.1、READ ONLY/WRITE模式打开物理STANDBY
一般standby都是可以设置为mount状态的，于物理standby 可以有效分担primary 数据库压力，提升资源利用，实际上说的就是这个。以read only 或read write 模式打开物理standby，你可以转移一些查询任何，备份之类的操作到standby数据库，以这种方式来分担一些primary 的压力。下面我们来演示一下，如何切换standby 数据库的打开模式，其实，非常简单。例如，以Read-only 模式打开物理standby：
这里分两种情况
1) standby 数据库处于shutdown 状态，直接startup 即可，直接打开到open状态。之后查询，确保db的状态是如下：
SQL> select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ WRITE PRIMARY
SQL>
2).standby 数据库处于redo 应用状态。
首先取消redo 应用：
alter database recover managed standby database cancel;
然后再打开数据库
alter database open;
之后查询，确保db的状态是如下：
SQL> select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ WRITE PRIMARY
SQL>
提示：open 的时候不需要附加read only 子句，oracle 会根据控制文件判断是否是物理standby，从而自动启动到read only 模式，直接startup 也是同理。
1.2，如果想从open 状态再切换回redo 应用状态，并不需要shutdown，直接启用redo 应用即可，例如：
SQL> select status from v$instance;
STATUS
------------
OPEN
SQL> alter database recover managed standby database disconnect from session;
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL>
由于只读打开时就不能应用，虽然我们能够查询，但是查询的结果确是与primary 不同步的，这点大大降低了物理standby 做报表服务分担主库压力的可能性，对于
这点，我们有两个解决方案：
（1）：改用逻辑standby，由于逻辑standby 是打开状态下的实时应用，因此数据同步应该是ok的（只要primary 的数据类型和操作逻辑standby 都能被支持），当然逻辑standby 有逻辑standby 的问题。
（2）：standby打开read only模式下，可以边接收边应用。 alter database recover managed standby database using current logfile disconnect ;
2，影响standby的primary数据库事件
alter database enable|disable thread语句；(主要针对rac 环境，目前基本已废弃，因为ENABLE|DISABLE INSTANCE 子句完全能够实现类似功能)
修改表空间状态（例如read-write到read-only，online到offline）
创建修改删除表空间或者数据文件（如果初始化参数standby_file_management被设置为auto的话）
2.1，primary上修改删除数据文件或者表空间
初始化参数STANDBY_FILE_MANAGEMENT 可以控制是否自动将primary 数据库增加删除表空间、数据文件的改动继承到standby。
1）：改用逻辑standby，由于逻辑standby
2）：如果设置为manual，则需要手工复制新创建的数据文件到standby 服务器。
下面分别通过示例演示STANDBY_FILE_MANAGEMENT 参数值为AUTO/MANUAL 值时增加及删除数据文件时的情形：
3，standby_file_management设置为auto，增加以及删除表空间和数据文件
先去standby库上查看下standby_file的值
SQL> show parameter standby_file;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL>
3.1，添加表空间测试
去primary库上添加新的tablespace
create tablespace mytest datafile ‘/home/oradata/powerdes/mytest01.dbf‘ size 20m autoextend on next 50m;
SQL> create tablespace mytest datafile ‘/home/oradata/powerdes/mytest01.dbf‘ size 20m autoextend on next 50m;
Tablespace created.
SQL>
查看刚才添加的表空间的数据文件
select name from v$datafile where name like ‘%mytest%‘;
SQL> select name from v$datafile where name like ‘%mytest%‘;
NAME
--------------------------------------------------------------------------------
/home/oradata/powerdes/mytest01.dbf
SQL>
切换日志 alter system switch logfile;
SQL> alter system switch logfile;
System altered.
SQL>
去standby上验证mytest表空间以及数据文件是否已经自动传输到了
查看数据文件：select open_mode,database_role from v$database;
SQL> select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ ONLY WITH APPLY PHYSICAL STANDBY
SQL> select name from v$datafile where name like ‘%mytest%‘;
NAME
--------------------------------------------------------------------------------
/home/oradata/powerdes/mytest01.dbf
SQL>
查看表空间：select * from v$tablespace where name like ‘%MYTEST%‘;
SQL> select * from v$tablespace where name like ‘%MYTEST%‘;
TS# NAME INC BIG FLA ENC
---------- ------------------------------ --- --- --- ---
16 MYTEST YES NO YES
SQL>
3.2，删除表空间测试
在primary上测试：drop tablespace mytest including contents and datafiles;
SQL> drop tablespace mytest including contents and datafiles;
Tablespace dropped.
SQL>
在primary上验证已经删除
SQL> select name from v$datafile where name like ‘%mytest%‘;
no rows selected
SQL>
切换日志：alter system switch logfile;
SQL> alter system switch logfile;
System altered.
SQL>
在standby上验证表空间也已经删除完成
SQL> select name from v$datafile where name like ‘%mytest%‘;
no rows selected
SQL>
总结是：对于初始化参数STANDBY_FILE_MANAGMENT 设置为auto 的话，对于表空间和数据文件的操作完全无须dba 手工干预，primary 和standby 都能很好的处理。
4，STANDBY_FILE_MANAGEMENT设置为MANUAL，增加及删除表空间和数据文件
因为一直是auto模式，这里为了做实验，需要将其设置为manual，设置命令是：alter system set standby_file_management=‘MANUAL‘ scope=both;
在primary和standby上都做如下操作
SQL> alter system set standby_file_management=‘MANUAL‘ scope=both;
System altered.
SQL>
4.1，增加新的表空间
create tablespace mytmp datafile ‘/home/oradata/powerdes/mytmp01.dbf‘ size 20m autoextend on next 10m;
SQL> create tablespace mytmp datafile ‘/home/oradata/powerdes/mytmp01.dbf‘ size 20m autoextend on next 10m;
Tablespace created.
SQL> SQL>
检查刚创建的表空间
select name from v$datafile where name like ‘%mytmp%‘;
SQL> select name from v$datafile where name like ‘%mytmp%‘;
NAME
--------------------------------------------------------------------------------
/home/oradata/powerdes/mytmp01.dbf
SQL>
切换日志：alter system switch logfile;
SQL> alter system switch logfile;
System altered.
SQL>
检查standby库表空间，已经存在了：
select name from v$tablespace where name like ‘%MYTMP%‘;
SQL> select name from v$tablespace where name like ‘%MYTMP%‘;
NAME
------------------------------
MYTMP
SQL>
检查standby库数据文件，不存在：
SQL> select name from v$datafile where name like ‘%mytmp%‘;
no rows selected
SQL>
奇怪，没有存在mytmp数据文件，去检查下redo日志有没有应用，primary和standby都一样，如下所示：
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 60
Next log sequence to archive 0
Current log sequence 61
SQL>
再去检查standby是否redo应用启动了，也是启用了，如下所示：
SQL> select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ ONLY PHYSICAL STANDBY
SQL>
都正常啊，那就再去检查下最新创建的那个数据文件
primary库上：select * from(select to_char(CREATION_TIME,‘yyyy-mm-dd hh24:mi:ss‘),name from v$datafile order by CREATION_TIME desc)a where rownum<3;
SQL> select * from(select to_char(CREATION_TIME,‘yyyy-mm-dd hh24:mi:ss‘),name from v$datafile order by CREATION_TIME desc)a where rownum<3;
TO_CHAR(CREATION_TI
-------------------
NAME
--------------------------------------------------------------------------------
2015-02-12 16:00:26
/home/oradata/powerdes/mytmp01.dbf
2015-02-10 18:09:38
/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/D:ORACLEORASERVERORADATAPOWERDESP
LCRM01.DBF
SQL>
standby库上：
SQL> select * from(select to_char(CREATION_TIME,‘yyyy-mm-dd hh24:mi:ss‘),name from v$datafile order by CREATION_TIME desc)a where rownum<3;
TO_CHAR(CREATION_TI
-------------------
NAME
--------------------------------------------------------------------------------
2015-02-12 16:00:26
/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED00011
2015-02-10 18:09:38
/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/D:ORACLEORASERVERORADATAPOWERDESP
LCRM01.DBF
SQL>
发现在同一时刻2015-02-12 16:00:26primary和standby都创建了一个数据文件，primary就是我们创建知道的mytmp表空间所属的数据文件，那么standby库呢？有一个UNNAMED00011未知的数据文件，这段时间没有人操作standby库，这意味着这个UNNAMED00011就是从primary及时同步过来的表空间，只是因为不是auto所以给起了个临时的名字而已。手工修改其与primary数据库保持一致，如下(注意执行命令之后手工复制数据文件到standby)：
在standby库上执行：alter database create datafile ‘/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED00011‘ as ‘/home/oradata/powerdes/mytmp01.dbf‘;
SQL> alter database create datafile ‘/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED00011‘ as ‘/home/oradata/powerdes/mytmp01.dbf‘;
Database altered.
SQL>
再去检查standby库上检查，mytmp数据文件已经存在了，如下所示：
SQL> select name from v$datafile where name like ‘%mytmp%‘;
NAME
--------------------------------------------------------------------------------
/home/oradata/powerdes/mytmp01.dbf
SQL>
4.3，删除表空间测试
在primary上操作：drop tablespace mytmp including contents and datafiles;
SQL> drop tablespace mytmp including contents and datafiles;
Tablespace dropped.
SQL>
检查mytmp没有记录，已经删除了
SQL> select name from v$datafile where name like ‘%mytmp%‘;
no rows selected
SQL>
再去standby库上检查
SQL> select name from v$datafile where name like ‘%mytmp%‘;
NAME
--------------------------------------------------------------------------------
/home/oradata/powerdes/mytmp01.dbf
SQL>
看到standby库上mytmp还在，所以需要我们人工手动处理
alter database recover managed standby database disconnect from session;
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL>
再去检查，执行，就看不到mytmp的记录了。
SQL> select name from v$datafile where name like ‘%mytmp%‘;
no rows selected
SQL>
你在primary 数据库执行删除时加上了including 子句，在standby 数据库仍然只会将表空间和数据文件从数据字典中删除，你还需要手工删除表空间涉及的数据文件。
结论是：初始化参数STANDBY_FILE_MANAGMENT 设置为manual 的话，对于表空间和数据文件的操作必须有dba手工介入，所以比较麻烦；在oracle数据库选择文件系统的时候，可以把dg的standby_file_managment设置成auto，这对于表空间数据文件的维护比较方便一些。但是如果你选择的是裸设备的话，就必须将dg的standby_file_managment设置成manual。
5，重命名数据文件
如果重命名了一个或者多个数据文件的话，这项修改并不会自动传输到standby上面去，需要手动操作，不管standby_file_managment是auto或者manual；
将一个数据文件离线测试
以下在primary库上操作：
alter tablespace plcrm offline;
SQL> alter tablespace plcrm offline;
Tablespace altered.
SQL>
然后手工将数据文件改名：
[[email protected] powerdes]$ mv plcrm01.dbf plcrm01_rename.dbf
通过命令修改数据字典中的数据文件路径，并online 表空间
alter tablespace plcrm rename datafile ‘/home/oradata/powerdes/plcrm01.dbf‘ to ‘/home/oradata/powerdes/plcrm01_rename.dbf‘;
SQL> alter tablespace plcrm rename datafile ‘/home/oradata/powerdes/plcrm01.dbf‘ to ‘/home/oradata/powerdes/plcrm01_rename.dbf‘;
Tablespace altered.
SQL> alter tablespace plcrm online;
Tablespace altered.
SQL>
检查新的数据文件名：select name from v$datafile where name like ‘%rename%‘;
SQL> select name from v$datafile where name like ‘%rename%‘;
NAME
--------------------------------------------------------------------------------
/home/oradata/powerdes/plcrm01_rename.dbf
SQL>
以下在standby上操作：
暂停redo 应用，并shutdown
SQL> alter database recover managed standby database cancel;
Database altered.
离线表空间：alter tablespace plcrm offline;
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
然后手工方式对数据文件进行改名：
[[email protected] powerdes]$ mv plcrm01.dbf plcrm01_rename.dbf
然后重启oracle实例：
SQL> startup mount
ORACLE instance started.
Total System Global Area 3373858816 bytes
Fixed Size 2218032 bytes
Variable Size 1845495760 bytes
Database Buffers 1509949440 bytes
Redo Buffers 16195584 bytes
Database mounted.
SQL>
数据文件重新命名：
SQL> alter database rename file ‘/home/oradata/powerdes/plcrm01.dbf‘ to ‘/home/oradata/powerdes/plcrm01_rename.dbf‘;
Database altered.
SQL>
重新启动redo应用：
alter database recover managed standby database disconnect from session;
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL>
再去primary切换日志：
SQL> alter system switch logfile;
System altered.
SQL>
最后去standby上验证
检查新的数据文件名：select name from v$datafile where name like ‘%rename%‘;
SQL> select name from v$datafile where name like ‘%rename%‘;
NAME
--------------------------------------------------------------------------------
/home/oradata/powerdes/plcrm01_rename.dbf
SQL>
名字已经切换过来了，OK。
6，添加或删除Online redo logs
数据库调优的时会涉及到重置日志文件大小或者增加删除日志组等操作，这种操作不会传输到standby库，也不会影响到standby的运行，但是有需要注意的地方是：
比如，我们假设我们的一台primary 数据库拥有5 组online redo 文件，standby 数据库拥有2 组，当你执行switch over 之后，新的primary 执行归档的频率会比standby 高的多，因此，当你在primary 数据库增加或移除online redologs 时，一定记的手工同步一相standby 数据库中相关的设置。
standby redologs 与online redologs 之间的关系，即保证standby redologs 比online redologs 要至少多一组。
操作的过程很简单(总不会复杂过添加删除数据文件)，需要注意的就是在standby做操作前务必将STANDBY_FILE_MANAGEMENT 设置为MANUAL。
----------------------------------------------------------------------------------------------------------------
<版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!>
原博客地址： http://blog.itpub.net/26230597/viewspace-1432708/
原作者：黄杉 (mchdba)
----------------------------------------------------------------------------------------------------------------