【DG】DG日常维护

第一部分 日常维护

一 正确打开主库和备库

1 主库:

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER DATABASE OPEN;

2 备库:

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

二 正确关闭顺序

1 备库:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL>SHUTDOWN IMMEDIATE;

2 主库

SQL>SHUTDOWN IMMEDIATE; ---先于standby执行

三 备库Read-Only模式打开

当前主库正常OPEN状态

备库处于日志传送状态.

1 在备库停止日志传送

SQL> alter database recover managed standby database cancel;

2 备库Read-only模式打开

SQL> alter database open read only;

3 备库回到日志传送模式

SQL>alter database recover managed standby database disconnect from session;

Media recovery complete.

SQL> select status from v$instance;

STATUS

------------

MOUNTED

四 日志传送状态监控

1 主库察看当前日志状况

SQL> select sequence#,status from v$log;

SEQUENCE# STATUS

---------- ----------------

51 ACTIVE

52 CURRENT

50 INACTIVE

2 备库察看RFS(Remote File Service)接收日志情况和MRP应用日志同步主库情况

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS

--------- ------------ ---------- ---------- ---------- ----------

ARCH CONNECTED 0 0 0 0

ARCH CONNECTED 0 0 0 0

RFS RECEIVING 0 0 0 0

MRP0 WAIT_FOR_LOG 1 52 0 0

RFS RECEIVING 0 0 0 0

可以看到备库MPR0正等待SEQUENCE#为52的redo.

3 察看备库是否和主库同步

SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ#  FROM V$ARCHIVE_DEST_STATUS;

ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ#

---------------- ------------- --------------- ------------

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

1 51 1 50

可以看到备库已经将SEQUENCE#51的日志归档,已经将SEQUENCE#50的redo应用到备库.

由于已经将SEQUENCE#51的日志归档,所以SEQUENCE#51以前的数据不会丢失.

4 察看备库已经归档的redo

SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#,NEXT_CHANGE# FROM V$ARCHIVED_LOG;

REGISTR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#

------- ------- ---------- ---------- ------------- ------------

SRMN SRMN 1 37 572907 573346

RFS ARCH 1 38 573346 573538

RFS ARCH 1 39 573538 573623

RFS ARCH 1 40 573623 573627

RFS ARCH 1 41 573627 574326

RFS ARCH 1 42 574326 574480

RFS ARCH 1 43 574480 590971

RFS ARCH 1 44 590971 593948

RFS FGRD 1 45 593948 595131

RFS FGRD 1 46 595131 595471

FGRD FGRD 1 46 595131 595471

REGISTR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#

------- ------- ---------- ---------- ------------- ------------

RFS ARCH 1 47 595471 595731

RFS ARCH 1 48 595731 601476

RFS ARCH 1 49 601476 601532

RFS ARCH 1 50 601532 606932

RFS ARCH 1 51 606932 607256

5 察看备库已经应用的redo

SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$LOG_HISTORY;

THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#

---------- ---------- ------------- ------------

1 1 366852 368222

1 2 368222 369590

1 3 369590 371071

1 4 371071 372388

1 5 372388 376781

1 6 376781 397744

1 7 397744 407738

1 8 407738 413035

1 9 413035 413037

1 10 413037 413039

1 11 413039 413098

THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#

---------- ---------- ------------- ------------

1 12 413098 428161

1 13 428161 444373

1 14 444373 457815

1 15 457815 463016

1 16 463016 476931

1 17 476931 492919

1 18 492919 505086

1 19 505086 520683

1 20 520683 530241

1 21 530241 545619

1 22 545619 549203

THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#

---------- ---------- ------------- ------------

1 23 549203 552403

1 24 552403 553230

1 25 553230 553398

1 26 553398 553695

1 27 553695 554327

1 28 554327 557569

1 29 557569 561279

1 30 561279 561385

1 31 561385 566069

1 32 566069 566825

1 33 566825 570683

THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#

---------- ---------- ------------- ------------

1 34 570683 571627

1 35 571627 571867

1 36 571867 572907

1 37 572907 573346

1 38 573346 573538

1 39 573538 573623

1 40 573623 573627

1 41 573627 574326

1 42 574326 574480

1 43 574480 590971

1 44 590971 593948

THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#

---------- ---------- ------------- ------------

1 45 593948 595131

1 46 595131 595471

1 47 595471 595731

1 48 595731 601476

1 49 601476 601532

1 50 601532 606932

1 51 606932 607256

可以看到备库已经将SEQUENCE#为51的归档文件应用到备库.

6 察看备库接收,应用redo数据过程.

SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;

MESSAGE

--------------------------------------------------------------------------------

ARC0: Archival started

ARC0: Becoming the ‘no FAL‘ ARCH

ARC0: Becoming the ‘no SRL‘ ARCH

ARC1: Archival started

ARC1: Becoming the heartbeat ARCH

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[1]: Assigned to RFS process 19740

RFS[1]: Identified database type as ‘physical standby‘

Primary database is in MAXIMUM PERFORMANCE mode

Attempt to start background Managed Standby Recovery process

MESSAGE

--------------------------------------------------------------------------------

MRP0: Background Managed Standby Recovery process started

Managed Standby Recovery not using Real Time Apply

Clearing online redo logfile 7 /oraguard/redo1/redo_7_1.log

Clearing online redo logfile 7 complete

Media Recovery Waiting for thread 1 sequence 47

RFS[1]: No standby redo logfiles created

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[2]: Assigned to RFS process 19746

RFS[2]: Identified database type as ‘physical standby‘

Primary database is in MAXIMUM PERFORMANCE mode

MESSAGE

--------------------------------------------------------------------------------

Committing creation of archivelog ‘/arch/1_47_552308270.arc‘

Media Recovery Log /arch/1_47_552308270.arc

Media Recovery Waiting for thread 1 sequence 48

MRP0: Background Media Recovery cancelled with status 16037

MRP0: Background Media Recovery process shutdown

Managed Standby Recovery Canceled

Attempt to start background Managed Standby Recovery process

MRP0: Background Managed Standby Recovery process started

Managed Standby Recovery not using Real Time Apply

Media Recovery Waiting for thread 1 sequence 48

RFS[1]: No standby redo logfiles created

MESSAGE

--------------------------------------------------------------------------------

Committing creation of archivelog ‘/arch/1_48_552308270.arc‘

Media Recovery Log /arch/1_48_552308270.arc

Media Recovery Waiting for thread 1 sequence 49

RFS[1]: No standby redo logfiles created

Committing creation of archivelog ‘/arch/1_49_552308270.arc‘

Media Recovery Log /arch/1_49_552308270.arc

Media Recovery Waiting for thread 1 sequence 50

RFS[1]: No standby redo logfiles created

Committing creation of archivelog ‘/arch/1_50_552308270.arc‘

Media Recovery Log /arch/1_50_552308270.arc

Media Recovery Waiting for thread 1 sequence 51

MESSAGE

--------------------------------------------------------------------------------

RFS[1]: No standby redo logfiles created

Committing creation of archivelog ‘/arch/1_51_552308270.arc‘

Media Recovery Log /arch/1_51_552308270.arc

Media Recovery Waiting for thread 1 sequence 52

可以看到RFS接收到sequence#为51的归档文件并存至备库归档目录/arch/1_51_552308270.arc.

Oracle自动应用文件/arch/1_51_552308270.arc进行备库与主库同步

Oracle继续等待主库sequence 52的归档文件

五 备库归档目录维护

1 找到备库归档目录

SQL> show parameter log_archive_dest_1

NAME TYPE

------------------------------------ --------------------------------

VALUE

------------------------------

log_archive_dest_1 string

LOCATION=/arch

VALID_FOR=(ALL_LOGFILES,ALL_RO

LES)

DB_UNIQUE_NAME=ora2

log_archive_dest_10 string

2 维护策略

每周2,4,7删除已经应用的归档文件

具体参见附录二

第二部分 主库正常切换

一 人工干预主库正常切换

1 在主库端检验数据库可切换状态

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS

-----------------

TO STANDBY

1 row selected

SWITCHOVER_STATUS:TO STANDBY表示可以正常切换.

如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE,表示当前有会话处于ACTIVE状态

2 开始主库正常切换

如果SWITCHOVER_STATUS的值为TO STANDBY 则:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE 则:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

成功运行这个命令后，主库被修改为备库

3 重启先前的主库

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

4 在备库验证可切换状态

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS

-----------------

TO_PRIMARY

1 row selected

5 将目标备库转换为主库

如果SWITCHOVER_STATUS的值为TO STANDBY 则:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE 则:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

成功运行这个命令后，备库被修改为主库

6 重启目标备库

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP;

7 先前主库启动日志传送进程

SQL> alter database recover managed standby database disconnect;

总结: 这样主库的一次正常切换完成.切换后的状态,原先的主库变为备库,原先的备库变为主库.

二 通过运行脚本实现主库正常切换

1 主库切换为备库

在主库上运行脚本

/admin/dataGuard/switchover/primary_to_standby.sh

2 备库切换为主库

在备库上运行脚本

/admin/dataGuard/switchover/standby_to_primary.sh

脚本1成功运行后,再运行脚本2,不能同时运行两个脚本.

经过这次切换后原来的主库变为备库,原先的备库变为主数据并且OPEN对应用提供服务.

3 复原最初状态

在原备库上运行脚本

/admin/dataGuard/switchover/primary_to_standby.sh

成功完成后

在原主库上运行脚本

/admin/dataGuard/switchover/standby_to_primary.sh

第三部分 主库灾难切换

一 人工干预主库灾难切换

二 通过运行脚本实现主库灾难切换

SQL>alter database recover managed standby database cancel;

SQL>shutdown immediate

SQL>startup mount

SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

SQL>alter database recover managed standby database finish;

-- switch

SQL>alter database commit to switchover to primary with session shutdown;

-- open

SQL>shutdown immediate

SQL>startup

附:

一 有选择察看redo传送与应用情况

select message from v$dataguard_status

where message_num>&message_num;

二 备库归档目录维护脚本

在crontab 中定制每日执行removeCommand.sh即可。

流程:每日11:50PM执行removeCommand.sh

假设今日2019-04-05 则删除04-04和04-03两日已应用归档日志.保留今日已应用归档日志

[[email protected]_gurid admin]$ crontab -l

50 23 * * * sh /oraguard/admin/removeCommand.sh>>removeArch.log

##################

[[email protected]_gurid admin]$ cat removeCommand.sh

#!/bin/sh

export ORACLE_BASE=/ora10g/app

export ORACLE_HOME=$ORACLE_BASE/product/10.1.0/db_1

export ORACLE_SID=ora2

cd /oraguard/admin

$ORACLE_HOME/bin/sqlplus /nolog<<EOF

conn / as sysdba

@/oraguard/admin/removeArch.sql

EOF

chmod +x /oraguard/admin/removeArch.sh

/oraguard/admin/removeArch.sh>>removeArch2.log

##################

[[email protected]_gurid admin]$ cat removeArch.sql

set feed off

set heading off

set echo off

spool removeArch.sh

select ‘rm ‘||name from v$archived_log where applied=‘YES‘ and completion_time>trunc(sysdate-3) and completion_time<trunc(sysdate);

spool off

原文地址：https://www.cnblogs.com/jimoyu/p/12164945.html

时间： 2024-10-15 22:58:04

【DG】DG日常维护的相关文章

MHA 日常维护命令集

MHA 日常维护命令集 1.查看ssh登陆是否成功 masterha_check_ssh --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf 2.查看复制是否建立好 masterha_check_repl --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf 3.启动mha noh

Nginx日常维护操作（3）

一.简明nginx常用命令 1. 启动 Nginx /sbin/nginx service nginx start 2. 停止 Nginx /sbin/nginx -s stop /sbin/nginx -s quit -s都是采用向 Nginx 发送信号的方式. 3. Nginx 重载配置 /sbin/nginx -s reload 上述是采用向 Nginx 发送信号的方式,或者使用service nginx reload 4. 指定配置文件 /sbin/nginx -c /usr/local

mha日常维护命令

mha日常维护命令 http://m.blog.chinaunix.net/uid-28437434-id-3959021.html?/13033.shtml 1.查看ssh登陆是否成功masterha_check_ssh --conf=/etc/masterha/app1.cnf 2.查看复制是否建立好masterha_check_repl --conf=/etc/masterha/app1.cnf 3.启动mhanohup masterha_manager --conf=/etc/maste

数据库日常维护-CheckList_01历史Agent Job执行情况检查

检查Agent Job中日常维护作业或业务作业是否成功,如每天的备份.碎片整理.索引维护.历史备份文件清除等,可利用SSMS工具,通过CDC下面设置好的DB Server List,运行下面脚本一次,便可以查询完成所有JOB历史运行情况. --SQL -- 参数定义 DECLARE @PreviousDate datetime DECLARE @Year VARCHAR(4) DECLARE @Month VARCHAR(2) DECLARE @MonthPre VARCHAR(2) DECLA

联想教育应用使用说明（7.6版本）——第3章 联想教育应用的日常维护与使用

第3章联想教育应用的日常维护与使用 注意: 1.建议机房管理员不要开放Windows的administrator权限给使用者,以避免使用者破坏联想服务分区. 2.建议机房管理员在计算机正常使用过程中,通过CMOS设置屏蔽硬盘以外的可启动设备,并设置BIOS密码,以免使用者破坏联想服务分区. 3.被保护分区的可用空间就是该分区的可用缓存区,请您确保有足够缓存区以保证软件的正常运行.硬盘保护驱动程序安装完成后,在Windows下将提供给您一个缓存区状态监控工具,您可以随时查看,必要时进行清理. 在图

第三篇——第二部分——第五文 配置SQL Server镜像——域环境SQL Server镜像日常维护

本文接上面两篇搭建镜像的文章: 第三篇--第二部分--第三文 配置SQL Server镜像--域环境:http://blog.csdn.net/dba_huangzj/article/details/28904503第三篇--第二部分--第四文 配置SQL Server镜像--非域环境:http://blog.csdn.net/dba_huangzj/article/details/27652857 在搭建的过程中,可能你会遇到比较多的问题,下面介绍一些常见的问题及解决方案,另外把主要精力放到对

WAS日常维护中的重启时机——总结

本笔记会不断更新,用来记录一下在WAS日常维护中的重启时机问题. 在做WAS的维护过程中,生产环境要求最大可能的不要有中断,所以重启的时机其实是一个非常值得记住的东西,有的时候因为没有重启或者重启的java进程不正确而导致大量的时间浪费也是非常正常的.谨以此文记录一下我个人的经验总结: JDBC: 1)创建数据源.数据Provider的时候:一定需要重启! 如果创建的时候选择的scope是Cell,那就需要重启DMGR:如果scope是Node,那就需要重启对应的Nodeagent:如果scop

自动清粪机的日常维护

自动清粪机在日常使用中很容易出现问题,特别是在脏了以后,也不易清洁,今天润生养殖设备就在这里为大家简单介绍下自动清粪机的日常维护方法. 1. 当自动清粪机清粪带跑偏接近头端被动滚筒边沿10mm时,可以通过拧紧涨紧杆上的螺栓调节,当清粪带往回移动三分之一的时候,要适当的放松螺栓,以防止清粪带回跑过头. 2. 当清粪带跑偏挨近被动滚筒边沿时,可以放开涨紧链条,将清粪带用手移动到被动滚筒的中间,再将涨紧链条安装在链轮上,然后用管钳拧紧六棱轴至能不动为止,最后上紧涨紧杆上的螺栓. 3. 如果自动清粪机出

数据库监控和日常维护项目

序号 设备类型 内容/参数 参数类型 备注 1 操作系统层次  系统日志 状态  检查日志的err或warning  进程数 性能参数  检查系统进程数是否相对稳定  系统CPU利用率 性能参数  参考值 Idle > 50%  系统内存利用率 性能参数  参考值 free > 10%  系统IO请求数/秒 性能参数  参考值 < 4000  系统IO请求量/稍 性能参数  参考值 < 100M  网络流量 性能参数  空间使用率 性能参数  参考值 free > 10% 2