共计 6528 个字符，预计需要花费 17 分钟才能阅读完成。
这期内容当中丸趣 TV 小编将会给大家带来有关如何理解 primary 数据库 standby，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
一、Read only/write 模式打开物理 standby
以 read only 或 read write 模式打开物理 standby, 可以转移一些查询，备份之类的操作到 standby 数据库，以分担一些 primary 的压力。
1). standby 数据库处于 shutdown 状态
直接 startup 即可
2). standby 数据库处于 redo 应用状态
首先取消 redo 应用：
SQL alter database recover managed standby database cancel; SQL alter database open3). 从 open 状态再切换回 redo 应用，并不需要 shutdown, 只需启用 redo 应用即可
SQL alter database recover managed standby database disconnect from session;由于只读打开时就不能应用，虽然我们能够查询，但是查询的结果确是与 primary 不同步的，这点大大降低了物理 standby 做报表服务分担主库压力的可能性，对于这点呢，我们有两个解决方案:
a. 改用逻辑 standby b. 使用 oracle 11G
二、管理影响 standby 的 primary 数据库事件
某些情况下，primary 数据库的某些改动会自动通过 redo 数据传播到 standby 数据库，因此不需要在 standby 数据库做额外的操作，而某些情况，则需要手工调整。
下列事件会由 redo 传输服务及 redo 应用自动处理，不需要 dba 的干预：
ALTER DATABASE ENABLE|DISABLE THREAD 语句
修改表空间状态(例如 read-write 到 read-only, online 到 offline)
创建修改删除表空间或数据文件（前提条件：参数 STANDBY_FILE_MANAGEMENT 设置为 AUTO）
以下事情则需要 dba 手工干预：
1. 添加、修改、删除数据文件或表空间
Standby_file_management 设置为 manual
不过需要注意一点，如果数据文件是从其它数据库复制而来，则不管 Standby_file_management 参数值如何设置，都必须同时复制到 standby 数据库，并注意要修改 standby 数据库的控件文件。
2. 重命名数据文件
如果 primary 数据库重命名了一个或多个数据文件，该项不修改并不会自动传播到 standby 数据库，不管 standby_file_management 它是 auto 还是 manual。
A. SQL alter tablespace webtbs offline; — primary 数据库操作
B. 手工数据文件改名(操作系统) — primary 数据库操作
C. SQL alter tablespace webtbs rename datafile
webtbs01.dbf to tbsweb01.dbf
SQL alter tablespace webtbs online;
D. 暂停 redo 应用，并 shutdown –standby 数据库操作
SQL alter database recover managed standby database cancel;
SQL shutdown immediate
E. 手工将数据文件改名 — standby 数据库操作
F. 重启 standby, 修改数据文件路径(数据字典) –standby 数据库操作
SQL startup mount
SQL alter database rename file
webtbs01.dbf to tbsweb01.dbf
G. 重新启动 redo 应用
SQL alter database recover managed standby database disconnect from session;
H. 切换日志 — primary 数据库操作
SQL alter system switch logfile;
3. 添加或删除 online redo logs
三、对 open resetlogs 的 primary 数据库 standby 的恢复
四、监控 primary/standby 数据库
1. 与恢复进度相关的 v$ 视图应用
A). 查看进程的活动状况 — v$managed_standby
B). 确认 redo 应用进度 — v$archive_dest_status
C). 检查归档文件路径及创建信息 — v$archived_log
D). 查询归档历史 — v$log_history
E). 查询备库上 gap 问题 –v$archived_gap，显示有关备用数据库上存档空缺的信息。这个视图可以用来找出当前存档的差距，阻碍目前恢复化身的恢复
1.1、查看进程的活动状态
SQL select process,status,thread#,sequence# from v$managed_standby order by 3,1;
PROCESS STATUS THREAD# SEQUENCE#
——— ———— ———- ———-
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 0 0
ARCH CLOSING 1 13411
ARCH CLOSING 1 13412
RFS IDLE 1 13413
ARCH CLOSING 2 8849
ARCH CLOSING 2 4101
MRP0 APPLYING_LOG 2 8850
RFS IDLE 2 8850
这里，process 就是进程名，包括 ARCH, RFS, MRP0 等，对应英文解释如下：
Type of the process whose information is being reported:
RFS – Remote file server—- 接收进程
MRP0 – Detached recovery server process—- 恢复进程
MR(fg) – Foreground recovery session
ARCH – Archiver process
FGRD
LGWR
RFS(FAL)
RFS(NEXP)
LNS – Network server process
CLIENT_PROCESS 对应 Primary 数据库中的进程如 ARCH\LGWR 等
SEQUENCE#：归档序号
STATUS 当前进程状态
重要的是 status 字段，表示当前的进程状态，中文解释如下：
ALLOCATED: 正在准备但还未连接主库
ATTACHED: 正在连接到主库
CONNECTED: 已经连接到主库
IDLE: 空闲
ERROR：失败的进程，需要关注
RECEIVING: 归档日志接收中
OPENING: 归档日志处理中
CLOSING: 归档日志处理完，正在收尾中
WRITING: 进程在将 REDO 数据写向归档文件中
WAIT_FOR_LOG: 等待新的 REDO 归档数据中
WAIT_FOR_GAP: 归档有中断，正在等待中断的那部分 REDO 数据.
APPLYING_LOG: 正在应用 REDO 归档数据到备库
1.2 查看 REDO 应用进度
SELECT DEST_NAME,ARCHIVED_THREAD#,ARCHIVED_SEQ#,APPLIED_THREAD#,APPLIED_SEQ#,DB_UNIQUE_NAME,STATUS FROM V$ARCHIVE_DEST_STATUS
–WHERE STATUS= VALID
DEST_NAME ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# DB_UNIQUE_NAME STATUS
————————- —————- ————- ————— ———— —————————— ———
LOG_ARCHIVE_DEST_1 0 0 0 0 cuuo VALID
LOG_ARCHIVE_DEST_2 0 0 0 0 cuug VALID
LOG_ARCHIVE_DEST_3 0 0 0 0 NONE INACTIVE
LOG_ARCHIVE_DEST_4 0 0 0 0 NONE INACTIVE
LOG_ARCHIVE_DEST_5 0 0 0 0 NONE INACTIVE
LOG_ARCHIVE_DEST_6 0 0 0 0 NONE INACTIVE
LOG_ARCHIVE_DEST_7 0 0 0 0 NONE INACTIVE
LOG_ARCHIVE_DEST_8 0 0 0 0 NONE INACTIVE
LOG_ARCHIVE_DEST_9 0 0 0 0 NONE INACTIVE
LOG_ARCHIVE_DEST_10 0 0 0 0 NONE INACTIVE
STANDBY_ARCHIVE_DEST 0 0 0 0 NONE VALID
11 rows selected.
1.3 查看归档文件的路径及创建信息
15:24:30 SELECT NAME,CREATOR,THREAD#,SEQUENCE#,APPLIED,ARCHIVED,COMPLETION_TIME FROM V$ARCHIVED_LOG;
NAME CREATOR THREAD# SEQUENCE# APP ARC COMPLETIO
—————————————————- ——- ———- ———- — — ———
/u01/app/oracle/oradata/cuuo/arch2_91_787689201.dbf ARCH 1 91 YES YES 04-JUL-12
/u01/app/oracle/oradata/cuuo/arch2_92_787689201.dbf LGWR 1 92 YES YES 04-JUL-12
/u01/app/oracle/oradata/cuuo/arch2_93_787689201.dbf LGWR 1 93 YES YES 04-JUL-12
/u01/app/oracle/oradata/cuuo/arch2_94_787689201.dbf LGWR 1 94 YES YES 04-JUL-12
1.4 查看归档历史
SELECT FIRST_TIME,FIRST_CHANGE#,NEXT_CHANGE#,SEQUENCE# FROM V$LOG_HISTORY;
1.5 查看物理 STANDBY 数据库未接收的日志文件
– 从 primary 数据库获取
select local.thread#,local.sequence# from
(select thread#,sequence# from v$archived_log where dest_id=1) local
where local.sequence# not in
(select sequence# from v$archived_log where dest_id=2 and thread# = local.thread#);
2 监控日志应用服务
2.1 查询当前数据的基本信息（V$DATABASE) 数据库角色、保护模式、保护级别
SELECT DATABASE_ROLE,DB_UNIQUE_NAME,OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS FROM V$DATABASE;
查询 failover 后快速启动的信息：
SELECT FS_FAILOVER_STATUS,FS_FAILOVER_CURRENT_TARGET,FS_FAILOVER_THRESHOLD,FS_FAILOVER_OBSERVER_PRESENT FROM V$DATABASE;
2.2 查询 REDO 应用和 REDO 传输服务的活动状态
SELECT PROCESS,STATUS,THREAD#,SEQUENCE#,BLOCK#,BLOCKS FROM V$MANAGED_STANDBY;
2.3 查看 REDO 应用模式（物理 STANDBY 数据库）
SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;
RECOVERY_MODE
———————–
MANAGED
– 如果开启了实时应用，此处显示的状态应该为 MANAGED REAL TIME APPLY
2.4 DATAGUARD 事件监控
2.4.1 ALERT LOG
2.4.2 查询 V$DATAGUARD_STATUS 视图
16:03:17 SELECT SEVERITY,DEST_ID,MESSAGE_NUM,ERROR_CODE,CALLOUT,MESSAGE FROM V$DATAGUARD_STATUS;
SEVERITY DEST_ID MESSAGE_NUM ERROR_CODE CAL MESSAGE
————- ———- ———– ———- — —————————————-
Informational 0 1 0 NO ARC0: Archival started
Informational 0 2 0 NO ARC1: Archival started
Informational 0 3 0 NO ARC0: Becoming the no FAL ARCH
Informational 0 4 0 NO ARC0: Becoming the no SRL ARCH
Informational 0 5 0 NO ARC1: Becoming the heartbeat ARCH
Control 0 6 0 YES Media Recovery Start: Managed Standby Recovery
Informational 0 7 0 NO Managed Standby Recovery not using Real Time Apply
3. 与 log 应用相关的 v$ 视图应用
A). 查询当前数据的基本信息 — v$database
B). 检查应用模式 –v$archive_dest_status
C). Data guard 事件 — v$dataguard_status
五、调整物理 standby log 应用频率
调整应用频率说白了就是调整 IO 读取能力
5.1 设置 RECOVER 并行度
在介质恢复或 REDO 应用期间都需要读取 redo log，默认都是串行恢复，
可以在 RECOVER 的时候加上 PARALLEL 子句来指定并行度。
RECOVER STANDBY DATABASE PARALLEL 2;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 2 DISCONNECT FROM SESSION;
5.2 加快 REDO 应用频率
修改 DB_BLOCK_CHECKING=FALSE 能够提高 2 倍的应用效率，设置为 FALSE 只适合物理 STANDBY 数据库，不适合 primary 数据库。
5.5 设置 parallel_execution_message_size
如果打开了并行恢复，适当加大 parallel_execution_message_size 大小也可以提升性能，不过需要注意的事
增加该参数会占用更多的内存。
5.5 优化磁盘 I /O
恢复期间最大的性能瓶颈是 I / O 读写，某些情况下将 DISK_ASYNCH_IO 设置为 TRUE 即使用本地异步 I / O 能够降低并行读取的次数，加快整个恢复时间。
上述就是丸趣 TV 小编为大家分享的如何理解 primary 数据库 standby 了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。
