1、DG环境的日常巡检
1.1、主库环境检查
1.1.1、主库实例启动状态检查
操作命令：
SQL> select instance_name,status from v$instance;
操作结果：
INSTANCE_NAME STATUS
--------------------------- ------------------------
cs02 OPEN
操作说明： 如果主库在对外提供服务，那其实例状态应一定是OPEN的。
1.1.2、主库启动模式检查
操作命令：
SQL> select name,open_mode from v$database;
操作结果：
NAME OPEN_MODE
------------------ --------------------------
CS02 READ WRITE
操作说明： 如果主库在对外提供服务，那其数据库状态应一定是READ WRITE的。
1.1.3、主库DG环境的保护模式检查
操作位置：主库 操作命令：
SQL> select database_role, protection_mode, protection_level from v$database;
操作结果：
DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL
-------------------------- -------------------------------------- ---------------------
PRIMARY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
1.1.4、主库用于控制日志同步的参数检查
操作命令：
SQL> show parameter log_archive_dest_2;
操作结果：
NAME TYPE VALUE
-------------------------------- ----------- ----------------------------------------------
log_archive_dest_2 string service=cs01 valid_for=(online_logfiles,primary_role) db_unique_name=cs01
操作说明：
通过该参数设置的网络服务名，主库能够找到该DG环境当中的备库，通过将主库的归档日志同步到备库;查询结果并没有看到lgwr/arch、sync/async、affirm/noaffirm的参数设置，说明当前主库没有对这三个参数进行设置，当前使用的是默认设置，即：arch、async、noaffirm的设置。
1.1.5、主库查看是否开启强制日志功能
操作命令：
SQL> select name,force_logging from v$database;
操作结果：
NAME FOR
--------- --------
CS02 YES
操作说明：
DG环境下主库要求必须开启强制日志功能，如果发现状态是NO，需要手动执行下面的命令开启该功能。
SQL> alter database force logging;
1.1.6、主库上查看设置的归档日志路径是否可用
操作命令：
SQL> col dest_name for a30
SQL> col error for a30
SQL> select dest_name,status,error from v$archive_dest;
操作结果：
DEST_NAME STATUS ERROR
---------------------------------- --------------- ------------------------------ LOG_ARCHIVE_DEST_1 VALID LOG_ARCHIVE_DEST_2 VALID LOG_ARCHIVE_DEST_3 INACTIVE
操作说明：
该视图用户查看本地和远程的归档日志路径是否可用，如果远程的归档日志路径不可用，在ERROR列会有相应报错。
1.1.7、主库上查询归档日志的应用情况
操作命令：
SQL> set pagesize 50; SQL> col name for a50
SQL> select name,SEQUENCE#,APPLIED from v$archived_log order by sequence#;
操作结果：
NAME SEQUENCE# APPLIED
-------------------------------------------------------------- ----------------- -----
/u01/app/oracle/arch/1_5_886855721.dbf 5 NO
cs01 5 YES
/u01/app/oracle/arch/1_6_886855721.dbf 6 NO
cs01 6 YES
/u01/app/oracle/arch/1_7_886855721.dbf 7 NO
cs01 7 YES
操作说明：
该视图记录了归档日志的应用情况，由查询结果可以看出，主库上的该视图会同时记录主库和同步到备库的归档日志的应用情况。视图中显示归档到本地路径的归档日志的名字使用的是绝对路径，并且应用状态为NO，而同步到远端备库上的归档日志名字统一都为cs01，并且应用状态显示为YES。这说明同步到备库上的归档日志都已经被应用了。
1.1.8、主库上查看DG环境进程的状态
操作命令：
SQL> select process,status from v$managed_standby;
操作结果：
PROCESS STATUS
------------- ------------
ARCH CLOSING
ARCH CLOSING
ARCH CLOSING
ARCH CLOSING
LNS WRITING
操作说明：
ARCH进程： 用于主库上复制redo log，从而生成归档日志，当前状态为CLOSING表示该进程目前正在复 制redo log，我们在参数文件中设置了该进程的数量上限是4个。
LNS进程： 用于在主库上将主库的归档日志同步到备库上，将归档日志投递给备库上的RFS进程。
1.1.9、主库上查看DG的状态信息
操作命令：
SQL> col message for a100
SQL> select message_num,message from v$dataguard_status;
1.1.10、主库SWITCH OVER角色和状态的检查
操作命令：
SQL> select name,database_role,switchover_status from v$database;
操作结果：
NAME DATABASE_ROLE SWITCHOVER_STATUS
------------------ ------------------------- --------------------------------
CS02 PRIMARY TO STANDBY
操作说明：
如果主库的切换状态显示为SESSION ACTIVED状态也是正常的。
1.2、备库环境检查
1.2.1、备库实例的启动状态检查
操作命令：
SQL> select instance_name,status from v$instance;
操作结果：
INSTANCE_NAME STATUS
--------------------------- ------------------------
cs01 MOUNTED
操作说明：
一般备库会被启动到MOUNT状态，不过根据具体需要，在确认备库没的应用归档日志进程没有启动的前提下也可以将其启动到OPEN状态，执行命令：alter database open;
1.2.2、备库启动模式检查
操作命令：
SQL> select name,open_mode from v$database;
操作结果：
NAME OPEN_MODE
------------------ --------------------------
CS01 READ ONLY
操作说明：
发现是read only模式，说明备库当前并没有开启归档日志应用进程，这个时候我们可以手动开启该进程，执行下面的命令：
SQL> alter database recover managed standby database disconnect from session;
如果发现当前数据库的打开模式是read only with apply我们也可以手工关闭归档应用程序，执行下面的命令：
SQL> alter database recover managed standby database cancel;
重新查看备库的启动模式，执行下面的命令：
SQL> select name,open_mode from v$database;
操作结果：
NAME OPEN_MODE
------------------ ----------------------------------
CS01 READ ONLY WITH APPLY
1.2.3、备库DG环境的保护模式检查
执行命令：
SQL> select database_role, protection_mode, protection_level from v$database;
SQL> set linesize 160
查询结果：
DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL
--------------------------- ---------------------------------------- --------------------
PHYSICAL STANDBY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
1.2.4、备库用于控制日志同步的参数检查
操作命令：
SQL> show parameter log_archive_dest_2
操作结果：
NAME TYPE VALUE
-------------------------------- ----------- ----------------------------------------------
log_archive_dest_2 string service=cs02 valid_for=(online_logfiles,primary_role) db_unique_name=cs02
1.2.5、备库上查看同步过来的归档日志的应用情况
操作命令：
SQL> set pagesize 50 SQL> col name for a50
SQL> select name,SEQUENCE#,APPLIED from v$archived_log order by sequence#;
操作结果：
NAME SEQUENCE# APPLIED
-------------------------------------------------------------- ------------------ ---------
/u01/app/oracle/arch/1_5_886855721.dbf 5 YES
/u01/app/oracle/arch/1_6_886855721.dbf 6 YES
/u01/app/oracle/arch/1_7_886855721.dbf 7 YES
操作说明：
如果发现备库归档日志的编号不连续，则需要到主库去对照主库的归档日志编号，找到主库上已经归档但却没有同步到备库上的那些归档日志手动拷贝过来，并将其注册到备库内，注册归档日志的命令如下所示：
SQL> alter database register physical logfile '/opt/arch/归档文件名’
然后再重新开启备库的应用归档日志进程，执行下面的命令即可：
SQL> alter database recover automatic standby database;
1.2.6、备库上查看归档日志有没有裂缝(同操作2.5部分类似)
操作命令：
SQL> select * from v$archive_gap;
操作说明：
如果DG环境日志同步正常，则不会查到任何记录，如果查出结果，则说明目前的DG环境归档日志有裂缝，需要执行2.5部分的操作去解决。
1.2.7、备库上查看DG环境特有进程的状态
操作命令：
SQL> select process,status from v$managed_standby;
操作结果：
PROCESS STATUS
------------------ ------------------------
ARCH CLOSING
ARCH CLOSING
ARCH CONNECTED
ARCH CLOSING
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
MRP0 WAIT_FOR_LOG
操作说明：
FRS进程： 用于备库接收从主库LNS进程或ARCH进程投递过来的归档日志。
ARCH： 用于复制从主库上同步过来的归档日志。
MRP0： 用于应用归档日志。
1.2.8、备库上查看DG环境的状态信息
操作命令：
SQL> col message for a100
SQL> select message_num,message from v$dataguard_status;
1.2.9、备库SWITCH OVER角色和状态的检查
操作命令：
SQL> select name,database_role,switchover_status from v$database;
操作结果：
NAME DATABASE_ROLE SWITCHOVER_STATUS
------------------ ------------------------- --------------------------------
CS02 PHYSICAL STANDBY NOT ALLOWED
操作说明：
如果主库的切换状态显示为TO PRIMARY状态也是正常的。
重要说明：
对于Data Guard环境的日常运维工作，其核心就在于确保主库上的日志能通正常同步到备库上，并能够被备库及时的应用。这些信息在主备数据库的告警日志中都会有所体现，所有要经常关注主库和备库的告警日志的内容。做到发现报错，及时处理，将会对数据库运行造成不良影响的因素消灭在萌芽状态...
2、DG环境的启动与关闭
2.1、DG环境的关闭
2.1.1、检查DG环境主备库的日志使用情况
操作位置：主库&备库
操作命令：
SQL> archive log list;
操作结果：
主库与备库当前使用的日志编号相同
2.1.2、停主库的监听程序
操作命令：
[oracle@cs02 ~]$ lsnrctl stop
2.1.3、停备库的监听程序
操作命令：
[oracle@cs01 ~]$ lsnrctl stop
2.1.4、关闭主数据库
操作命令：
SQL> shutdown immediate;
2.1.5、查看备库的开启模式
操作命令：
SQL> select open_mode from v$database;
如果发现当前数据库是read only with apply模式，则需要执行下面命令关闭归档日志应用程序，如果发现是read only模式则直接关闭数据库即可。正常情况下备库应该时刻处于应用归档日志的模式。
2.1.6、关闭备数据库的归档应用程序
操作命令：
SQL> alter database recover managed standby database cancel;
2.1.7、关闭备数据库
操作命令：
SQL> shutdown immediate;
这样，整个Data Guard环境就算是完整的关闭掉了...
2.2、DG环境的启动
2.2.1、启动DG环境的主库
操作命令：
[oracle@cs02 ~]$ sqlplus / as sysdba
SQL> startup;
SQL> select status from v$instance;
2.2.2、启动主库的监听程序
操作命令：
[oracle@cs02 ~]$ lsnrctl status
[oracle@cs02 ~]$ lsnrctl start
2.2.3、启动DG环境的备库到mount或open状态
操作命令：
[oracle@cs01 ~]$ sqlplus / as sysdba
SQL> startup;
或 SQL> startup mount;
2.2.4、启动备库的监听程序
操作命令：
[oracle@cs01 ~]$ lsnrctl status
[oracle@cs01 ~]$ lsnrctl start
2.2.5、主库切换归档日志
操作命令：
SQL> alter system archive log current;
2.2.6、查看备库是否有新应用过来的日志
操作命令：
SQL> select sequence#,applied from v$archived_log;
2.2.7、备库上开启归档日志应用进程
操作命令：
SQL> alter database recover managed standby database disconnect from session;
2.2.8、主库与备库验证当前redo log
操作位置：主库&备库
操作命令：
SQL> archive log list;
如果此时发现主库与备库当前使用的redo日志的编号一致则说明重启的DG环境一切正常。
这样，这个Data Guard环境就算是去正常的启动了...
3、DG环境的主备切换-SWITCHOVER
3.1、SWITCHOVER切换的特点
一般SWITCHOVER切换都是计划中的切换，特点是在切换后，不会丢失任何的数据，而且这个过程是可逆的，整个DATA GUARD环境不会被破坏，原来DATA GUARD环境中的所有物理和逻辑STANDBY都可以继续工作。
3.2、SWITCHOVER切换的注意事项
1)确认主库和从库间网络连接通畅；
2)确认没有活动的会话连接在数据库中；
3)PRIMARY数据库处于打开的状态，STANDBY数据库处于MOUNT状态；
4)确保STANDBY数据库处于ARCHIVELOG模式；
5)如果设置了REDO应用的延迟，那么将这个设置去掉；
6)确保配置了主库和从库的初始化参数，使得切换完成后，DATA GUARD机制可以顺利的运行。
3.3、SWITCHOVER的切换操作流程
3.3.1、主库与备库运行状态确认
在执行主备SWITCH OVER之前，需要首先确认主库与备库的实例以及数据库的启动状态，确保主库与备库满足下面的要求：
数据库 实例启动状态 数据库启动模式
主库-CS02 open read write
备库-CS01 mount/open mount with apply/read only with apply
可以通过如下命令进行查看：
SQL> select status from v$instance;
SQL> select open_mode from v$database;
3.3.2、查看switchover之前主库的角色和状态
SQL> select name,database_role,switchover_status from v$database;
操作结果：
NAME DATABASE_ROLE SWITCHOVER_STATUS
--------- ----------------------- --------------------------------
CS02 PRIMARY SESSIONS ACTIVE
操作说明：
1)如果是第一次做主备的SWITCH OVER操作，那么主库的SWITCHOVER_STATUS状态会是SESSIONS ACTIVE状 态。表示当前主库还有活动的会话连接，属于正常的主库准备切换之前的状态。
2)如果之前已经做过主备的SWITCH OVER操作，那么主库的SWITCHOVER_STATUS状态会是TO_STANDBY状态， 表明当前主库已经准备好随时切换成备库了。
3.3.3、查看switchover之前备库的角色和状态
操作命令：
SQL> select name,database_role,switchover_status from v$database;
NAME DATABASE_ROLE SWITCHOVER_STATUS
--------- ---------------------------- --------------------------------
CS02 PHYSICAL STANDBY TO PRIMARY
操作说明：
1)如果是第一次做主库的SWITCH OVER操作，那么备库的SWITCHOVER_STATUS状态会是TO_PRIMARY状态。 表明备库已经随时可以切换成主库了。
2)如果之前已经做过主备的SWITCH OVER操作，在主库没有发出要做主备切换的操作之前(即：执行主库切成备库的那条命令)，备库的SWITCHOVER_STATUS状态会是NOT ALLOWED，属于正常状态。
3.3.4、将主库切换成备库
操作命令：
SQL> alter database commit to switchover to physical standby with session shutdown;
操作说明： 此时主库会被自动关闭掉。
3.3.5、将备库启动到mount状态
1)关闭备库的归档日志应用进程
SQL> alter database recover managed standby database cancel;
2)关闭备库并启动到mount状态
SQL> shutdown immediate;
SQL> startup mount;
3)查看备库的角色状态
SQL> select name,database_role,switchover_status from v$database;
备注：
如果之前查看备库的切换状态是NOT ALLOWED，那么由于现在在主库上已经做了切换到备库的操作，该操 作的信息已经发送到了备库上，所以备库此时的切换状态会变成TO PRIMARY。
3.3.6、主库启动到mount状态
1)主库启动到nomount状态
SQL> startup nomount;
2)主库以备库的身份启动到mount状态
SQL> alter database mount standby database;
3)主库以备库的身份开启归档日志应用进程
SQL> alter database recover managed standby database disconnect from session;
4)查看主库现在在DG环境中的角色
SQL> select name,database_role,switchover_status from v$database;
NAME DATABASE_ROLE SWITCHOVER_STATUS
------------------ -------------------------------- ---------------------------------------CS02 PHYSICAL STANDBY TO PRIMARY
至此，主库的切换相关操作已经完成，主库角色已经切换成了备库，切换状态变成了TO PRIMARY。
3.3.7、备库切换成主库
1)备库开启归档日志应用进程
SQL> alter database recover managed standby database disconnect from session;
2)查看备库当前在DG环境中的角色
SQL> select name,database_role,switchover_status from v$database;
NAME DATABASE_ROLE SWITCHOVER_STATUS
--------- --------------------------- --------------------------------
CS02 PHYSICAL STANDBY TO PRIMARY
备注：
在开启应用归档日志进程之前，备库的切换状是NOT ALLOWED。在开启了归档日志应用进程之后，发现现在备库的角色状态变成了TO PRIMARY
3)备库切换成主库
SQL> alter database commit to switchover to primary;
4)切换后重新查看备库在DG环境中的角色和状态
SQL> select name,database_role,switchover_status from v$database;
NAME DATABASE_ROLE SWITCHOVER_STATUS
------------ ------------------------- -------------------------------
CS02 PRIMARY NOT ALLOWED
4)关闭备库
SQL> shutdown immediate;
5)启动备库
SQL> startup;
备注： 查看当前备库的SWITCH OVER状态，这个时候可能会出现RESOLVABLE GAP的状态
6)切换备库的redo log
SQL> alter system switch logfile;
备注： 查看当前备库的SWITCH OVER状态，这个时候可能会出现RESOLVABLE GAP的状态，再等一会就好了。
7)查看备库当前的切换状态
SQL> select name,database_role,switchover_status from v$database;
NAME DATABASE_ROLE SWITCHOVER_STATUS
--------- ------------------------ --------------------------------
CS02 PRIMARY SESSIONS ACTIVE
发现备库已经成功切换成主库了，并且数据库中存在活动的会话...
3.3.8、检查切换后主库与备库的日志编号
操作位置：主库&备库
操作命令：
SQL> archive log list;
如果确认切换之后主库与备库的当前日志编号一致，则说明主备切换完成。可以在主库上做切换日志操作，做进一步的验证。
操作命令：
SQL> alter system switch logfile;
如果切换日志之后主备两端的日志编号依旧一致则说明本次主备的SWITCH OVER顺利完成。
至此，我们的主备SWITCH OVER操作就算是顺利的完成了...
403
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
