如何理解primary数据库standby

网友投稿 450 2023-12-28 15:06:42

如何理解primary数据库standby

这期内容当中小编将会给大家带来有关如何理解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 open

3). 从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能够降低并行读取的次数,加快整个恢复时间。

上述就是小编为大家分享的如何理解primary数据库standby了,如果刚好有类似的疑惑,不妨参照上述分析进行理解。如果想知道更多相关知识,欢迎关注行业资讯频道。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:tempfile报错重建的示例分析
下一篇:DML DDL 都报ORA-00600: [kntgMvLogObjn]的解决办法
相关文章