【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

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

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

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

[oracle@db_gurid admin]$ crontab -l

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

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

[oracle@db_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

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

[oracle@db_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

About Me

...............................................................................................................................

● 本文整理自网络

● 本文在itpub（http://blog.itpub.net/26736162）、博客园（http://www.cnblogs.com/lhrbest）和个人微信公众号（xiaomaimiaolhr）上有同步更新

● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/

● 本文博客园地址：http://www.cnblogs.com/lhrbest

● 本文pdf版及小麦苗云盘地址：http://blog.itpub.net/26736162/viewspace-1624453/

● 数据库笔试面试题库及解答：http://blog.itpub.net/26736162/viewspace-2134706/

● QQ群：230161599 微信群：私聊

● 联系我请加QQ好友(646634621)，注明添加缘由

● 于 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成

● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解

● 版权所有，欢迎分享本文，转载请保留出处

...............................................................................................................................

拿起手机使用微信客户端扫描下边的左边图片来关注小麦苗的微信公众号：xiaomaimiaolhr，扫描右边的二维码加入小麦苗的QQ群，学习最实用的数据库技术。

时间： 2024-09-23 22:59:30

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

浅谈网站日常维护工作哪些是关键

对于网站维护者而言平时需做哪些事,相信广大的站长朋友们都十分的清楚,但哪些工作才是日常网站维护工作当中最为关键的呢?下面A5站长网SEO诊断优化团队就来和广大的站长朋友们浅谈下究竟网站日常维护工作哪些才是关键? 稳定新鲜的内容更新内容这项工作永远都会是网站维护者工作的重点所在,无论是什么类型的网站,网站都需要更新内容,没有内容的支撑,网站就别提发展,想要网站有生机,就要每天有规律的写些新鲜的内容,进行网站更新,网站只有有新内容的增加,才能吸引搜索引擎蜘蛛和用户的访问,否则,搜索引擎蜘蛛每次来你

专题站日常维护与优化注意事项

对于网站的日常维护与优化站长们是再熟悉不过了,每天基本上都在做同样的事,有时可能还会觉得烦,然而,那又有什么办法呢?谁让我们选择了这个行业,爱上了这个行业呢?虽然站长们对专题站的日常维护已经很熟悉了,但A5 SEO诊断优化小组还是就这个问题来和大家浅谈一下,希望对刚入行的新手站长们有所帮助. 1.内容更新 A.定时定量更新内容如,第一次是早上九点到十点每天更新一篇文章,以后最好也这个时间每天更新一篇. B.从长尾关键词入手写文章可以在百度知道,相关搜索找一些相关长尾关键词进行扩展写文章.当然

Oracle DBA数据库日常维护完全手册

在Oracle数据库运行期间,DBA应该对数据库的运行日志及表空间的使用情况进行监控,及早发现数据库中存在的问题. 一.Oracle警告日志文件监控 Oracle在运行过程中,会在警告日志文件(alert_SID.log)中记录数据库的一些运行情况: ●数据库的启动.关闭,启动时的非缺省参数: ●数据库的重做日志切换情况,记录每次切换的时间,及如果因为检查点(checkpoint)操作没有执行完成造成不能切换,会记录不能切换的原因: ●对数据库进行的某些操作,如创建或删除表空间.增加数据文件:

sybase数据库日常维护

数据库日常维护工作是系统管理员的重要职责.其内容主要包括以下几个部分:一.备份系统数据SYBASE 系统的备份与恢复机制保证了在系统失败时重新获取数据的可能性.SQL Server 提供了两种不同类型的恢复机制:一类是系统自动完成的恢复,这种措施在每次系统启动时都自动进行,保证了在系统瘫痪前完成的事务都写到数据库设备上,而未完成的事务都被回退:另一类是人工完成的恢复,这是通过 DUMP 和 LOAD 命令来执行人工备份和恢复工作.因此定期备份事务日志和数据库是一项十分重要的日常维护工作. 1.备

Sybase数据库轻松日常维护

数据库日常维护工作是系统管理员的重要职责.其内容主要包括以下几个部分: 一.备份系统数据 Sybase系统的备份与恢复机制保证了在系统失败时重新获取数据的可能性.SQL Server 提供了两种不同类型的恢复机制:一类是系统自动完成的恢复,这种措施在每次系统启动时都自动进行,保证了在系统瘫痪前完成的事务都写到数据库设备上,而未完成的事务都被回退:另一类是人工完成的恢复,这是通过 DUMP 和 LOAD 命令来执行人工备份和恢复工作.因此定期备份事务日志和数据库是一项十分重要的日常维护工作. 1.

Nginx的日常维护

在完成对nginx.conf文件的配置后,就可以启动服务了,Nginx自身提供了一些用于日常维护的命令,下面进行详细的介绍. 1.Nginx基本信息检查 (1)检查Nginx配置文件的正确性 Nginx提供的配置文件调试功能非常有用,可以快速定位配置文件存在的问题.执行如下命令检测配置文件的正确性: /opt/nginx/sbin/nginx –t 或者 /opt/nginx/sbin/nginx -t -c /opt/nginx/conf/nginx.conf 其中,"-t"参数用于

如何进行计算机主板日常维护

计算机主板的日常维护主要应该做到的是防尘和防潮,CPU.内存条.显示卡等重要部件都是插在主机板上,如果灰尘过多的话,就有可能使主板与各部件之间接触不良,产生这样那样的未知故障,给你的工作和娱乐带来很大麻烦;如果环境太潮湿的话,主板很容易变形而产生接触不良等故障,影响你的正常使用.另外,在组装计算机时,固定主板的螺丝不要拧得太紧,各个螺丝都应该用同样的力度,如果拧得太紧的话也容易使主板产生形变. 一般不打开机箱,我们不太能够接触到它,我所碰到最多的就是有些人在不知道的情况或者为了省事,常常在开

如何自己动手进行鼠标键盘的日常维护

一.鼠标的日常维护比起计算机的其它硬件设备,鼠标的价格确实是比较便宜.但是一旦出了毛病,可能更多的人都会掏腰包再买一个.其实鼠标的维护并不难,只要在使用时能加以注意就好.即使有了问题,你也不妨给自己一个动手的机会,这样即能省钱又能练手,何乐而不为呢. 1.机械式鼠标机械鼠标在使用了一段时间后,橡胶球带入的粘性灰尘附着在传动轴上,会造成传动轴传动不均甚至被卡住,导致灵敏度降低,控制起来不会象刚买时那样方便灵活.这时候,你只需要将鼠标翻过来,摘下塑料圆盖,取出橡胶球,用沾有无水酒精的棉球清洗

显示器的日常维护

具体的维护方法如下: 1.液晶显示器 1)液晶显示器比较薄,占用的空间小省电,对眼睛刺激较小,缺点是显示的图像画面较暗; 显示器 2)显示器上有两条线,线比较粗两头有一个圆疙瘩的是信号线,接头是梯形的,颜色是蓝色,另外一条是电源线,是三相插头; 3)显示器的开关一般在屏幕右下角,最大的一个就是,另外几个是调节亮度对比度的; 4)在桌面点右键-属性-设置,进入显示器的分辨率,一般系统会自动调节,有1200×800.1024×768等,刷新率一般是60或75; 5)分辨率越大,屏幕显示的内容也越