一、DG常见运维命令及常见问题解决方法
DG库启动、关闭标准操作
Dataguard关闭
1)、先取消日志应用
alter database recover managed standby database cancel;复制
2）、正常关闭DG库
shutdown immediate;复制
Dataguard开启
1)、数据库先启动到nomount状态
startup nomount;复制
2)、然后数据库在启动到standby mount状态
alter database mount standby database;复制
3、最后开启日志应用
alter database recover managed standby database disconnect from session using current logfile;复制
DG监听、TNS配置及说明
1、 监听、TNS配置路径
$ORACLE_HOME/network/admin复制
2、 监听配置
SID_LIST_oradb =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = oradb)
(ORACLE_HOME = $ORACLE_HOME)
(SID_NAME = oradb)
)
)
oradb =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ip )(PORT = 1521))
)复制
3、 TNS配置
oradb_primary =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = primary_ip)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = oradb)
)
)
oradb_standby =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby_ip)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = oradb)
)
)复制
DG归档文件系统使用率100%解决办法
1、 查看归档目录
例如：/oradb/db_dg_arc/oradb
2、 查询归档目录使用情况
AIX (df -g) HPUX (bdf) Linux (df -h)
3、 手动清理归档日志步骤
（1）、登陆数据库实例查询最新日志应用号
select PROCESS,STATUS,SEQUENCE#,BLOCKS from V$MANAGED_STANDBY;复制
用SEQUENCE#去和主库对 MRP0为日志应用进程 RFS为日志传输进程
PROCESS STATUS SEQUENCE# BLOCKS
--------- ------------ ---------- ----------
ARCH CLOSING 116489 1063
ARCH CONNECTED 0 0
ARCH CLOSING 116491 200
ARCH CLOSING 116490 1642
MRP0 APPLYING_LOG 116492 4194304复制
（2）、查看是否部署了删除归档日志脚本，如果存在，手工执行脚本删除过期日志
（3）如果删除脚本不存在，首先手工删除部分应用过的日志，再部署自动删除归档日志脚本
DG GAP问题分析解决办法
1、 查询GAP
SQL> select PROCESS,STATUS,SEQUENCE#,BLOCKS from V$MANAGED_STANDBY;
PROCESS STATUS SEQUENCE# BLOCKS
--------- ------------ ---------- ----------
ARCH CLOSING 511899 1971
ARCH CLOSING 511892 308
ARCH CLOSING 511895 1399
ARCH CLOSING 511887 1404
ARCH CONNECTED 0 0
ARCH CLOSING 511900 1591
MRP0 WAIT_FOR_GAP 511901 0
RFS IDLE 0 0复制
2、 GAP原因分析
归档空间满，日志无法传输 网络延迟导致日志传输速度慢 DG监听没有启动导致日志无法传输 DG本身日志缺失 DG库宕机故障
3、 常规GAP解决办法
DG备库GAP恢复操作过程：
在主库查找所缺日志的备份片
select 'catalog device type '|| '''SBT_TAPE''' ||' backuppiece ''/'||HANDLE||''';' from
(select distinct a.HANDLE from v$backup_piece_details a, v$backup_archivelog_details b
where set_count = id2 and b.thread#=1 and b.SEQUENCE# >缺失的sequence号 and b.SEQUENCE#<缺失的sequence号) ;复制
2)、在DG库上注册备份集
rman target /
configure CHANNEL device type 'SBT_TAPE' PARMS 'ENV=(NB_ORA_CLIENT=主机名)';
catalog device type 'SBT_TAPE' backuppiece '/al_XXXXXXXXXXXXXXXXX';复制
3)、注册完了 第一个配置的参数清除下
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' CLEAR;复制
使用oracle用户rman target
RMAN>catalog start with '归档路径';复制
3)检查日志是否开始应用
DG库ORA-01111错误处理
1、 问题描述：主库添加数据文件，DG库同步时发现无法同步添加导致报错
2、 问题原因：
1） DG库standby_file_management参数没有设置为auto
2） DG库对应文件系统剩余空间不足以添加数据文件
3、解决办法：
如果主备文件系统剩余空间不一致，先清理目标目录的历史文件（如归档日志、dmp包等）
alter system set standby_file_management=manual;
alter database create datafile '/u01/oracle/product/db11gr2/dbs/UNNAMED00070' as '/oradb/datafile/oradb/oradb.dbf';
alter system set standby_file_management=auto;复制
打开应用：
alter database recover managed standby database parallel 4 disconnect from session;复制
DG库上归档出现ORA-03113错误
SQL> select dest_name,status,error from v$archive_dest;
DEST_NAME STATUS ERROR
------------------------------ --------------------------------------
LOG_ARCHIVE_DEST_1 VALID
LOG_ARCHIVE_DEST_2 ERROR ORA-03113: end-of-file on communication channel复制
解决办法：在主库执行
SQL> alter system set log_archive_dest_state_2= enable;复制
这个命令式手动触发主库区尝试连接备库。
其实这种情况下，只要保证主备库之间的网络和配置是正确的。dataguard会自动恢复这个错误。这个周期默认是300秒，
也可以在log_archive_dest_1的参数中添加reopen参数指定这个主备库之间失败后继续尝试的周期
ORA-01031: insufficient privileges错误
SQL> select dest_name,status,error from v$archive_dest;
DEST_NAME STATUS ERROR
---------------------- -----------------------------------------------
LOG_ARCHIVE_DEST_1 VALID
LOG_ARCHIVE_DEST_2 ERROR ORA-01031: insufficient Privileges复制
解决办法：统一主备库的数据库密码文件，或者重建密码文件，sys密码设置成一样。
然后在主库执行
SQL> alter system set log_archive_dest_state_2= enable;复制
ORA-16191: Primary log shipping client not logged on standby
SQL> select dest_name,status,error from v$archive_dest;
DEST_NAME STATUS ERROR
------------------------------ -----------
LOG_ARCHIVE_DEST_1 VALID
LOG_ARCHIVE_DEST_2 ERROR ORA-16191: Primary log shipping client not logged on standby复制
解决办法：统一主备库的数据库密码文件，或者重建密码文件，sys密码设置成一样。
然后在主库执行
SQL> alter system set log_archive_dest_state_1= enable;复制
关闭ADG环境步骤：
主库shutdown——备库取消应用归档日志——关闭备库——关闭主库和备库的lsnrctl监听。
1：主库上：SQL> shutdown immediate
2：备库上：SQL> alter database recover managed standby database cancel;
3：备库上：SQL> shutdown immediate
4：主库和备库：
[oracle@apollo ~]$ lsnrctl stop
[oracle@neptune ~]$ lsnrctl stop
启动ADG环境步骤：
启动主库和备库lsnrctl监听——启动备库——启动主库——切换主库日志
1：主库和备库：
[oracle@apollo ~]$ lsnrctl start
[oracle@neptune ~]$ lsnrctl start
2：启动备库：
SQL> startup nomount
SQL> alter database mount standby database;
SQL> alter database open;
SQL> alter database recover managed standby database using current logfile disconnect from session;
3：启动主库：
SQL> startup
4：切换主库日志
SQL> alter system switch logfile;
备库将开始应用主库传输过来的归档日志。
注意事项
建议在主备库的涉及到名称地方都统一用小写字母，避免在配置过程出现莫名的错误。 如果在主库执行alter database clear unarchived logfile或alter database open resetlogs，则dataguard要重建。 在连续恢复模式下工作之前，需要保证之前所有的归档日志己经应用到备用库上。因为在连续恢复模式的情况下，oracle不会应用之前的归档日志，而只会应用后面陆续到来的归档日志。 新建表、表空间、datafile都能通过日志应用到备库，但新建一个临时表空间和rename datafile均不能应用到备库上。 出现归档日志gap时，需要找出相应的归档日志，然后将这些归档日志copy到备用节点的log_archive_dest目录下面。然后ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE; 应当实时查看standby库的alert文件，就能清晰明了地知道主备更新的情况。这也是排错的重要方法。
二、physical standby switchover 切换
2.1 准备工作
1、从primary上确认redo transport 没有错误
使用SYS用户执行如下查询，确认GAP_STATUS为NO_GAP:
SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
STATUS GAP_STATUS
--------- ------------------------
VALID NO GAP复制
结果为NO GAP表示主库和备库的日志是同步的，激活备库不会有数据库损失。
2、确认primary和standby上都存在temp表空间文件
在primary和standby上分别执行如下查询，确认temp文件都存在：
SQL> select name from v$tempfile;
ON Primary:
NAME
--------------------------------------------------------------------------------
/data/prod/temp01.dbf
ON Standby:
SQL> select name from v$tempfile;
NAME
--------------------------------------------------------------------------------
/data/prod/temp01.dbf复制
3、停止所有应用服务器
按照正常步骤停止所有应用服务。
应用服务停止完成之后，确保primary上面已经没有LOCAL=NO的进程存在（可以使用ps -ef | grep 'LOCAL=NO' 查询确认）
已经没有活动连接之后，主库才可以切换到standby角色。
4、确认PROD可以转变为standby角色
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
TO STANDBY复制
注：如果发现SWITCHOVER_STATUS
的值为SESSIONS ACTIVE
，则需要停止数据库除当前操作的sqlplus会话之外的的所有会话，等待状态变为TO STANDBY；
当前连接到数据库的前台会话可以用下面sql查询
select sid, serial#, machine, process from gv$session where type <> 'BACKGROUND';复制
如果发现SWITCHOVER_STATUS的值不为TO STANDBY ，则需要查明原因，至最终变为to standby状态。
2.2 切换操作
整个切换过程的步骤可以概括为：
将主库上的数据库（DB_UNIQUE_NAME为PROD）转为standby角色 将备库上的数据库（DB_UNIQUE_NAME为PRODDG）的转为primary角色
1、将主库服务器上的数据库（DB_UNIQUE_NAME为PROD）转为standby角色
在主库服务器上，执行如下操作将数据库转换为standby角色
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
Database altered.
SQL> startup mount;复制
2、确认备库服务器上的数据库（DB_UNIQUE_NAME为PRODDG）可转为Primary角色
在备库上，执行如下查询，确认DATABASE_ROLE为PHYSICAL STANDBY，SWITCHOVER_STATUS为TO_PRIMARY：
SQL> select DATABASE_ROLE from v$database;
DATABASE_ROLE
----------------
PHYSICAL STANDBY
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
TO PRIMARY复制
注：
SWITCHOVER_STATUS值为TO_PRIMARY时，表示角色可以转为primary SWITCHOVER_STATUS值为NOT ALLOWED时，表示还不能转换为primary角色，原因可能是primary还没有转换为standby，或者standby的日志同步出现问题。如果从alert日志中判断日志是正常同步的，NO ALLOWED一般为正常状态。
3、将备库服务器上的数据库（DB_UNIQUE_NAME为PRODDG）转为Primary角色
在备库服务器上，执行如下操作将其转换为primary角色：
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
Database altered.
SQL> alter database open;
Database altered.复制
4、在主库服务器上的数据（DB_UNIQUE_NAME为PROD）上开始redo apply
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> alter database open read only;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
SQL> select open_mode from v$database;复制
5、修改应用服务器hosts文件，连接到Standby 数据库上
6、启动应用服务器
按照顺序，启动应用服务器各服务
登陆进行验证
参考文档
http://blog.itpub.net/69950231/viewspace-2660485/
评论
0 点赞