DG的日常维护保养有哪些?

分类:编程技术 时间:2024-02-20 16:00 浏览:0 评论:0
0
本文与大家分享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 >立即关闭; --- 在备库之前执行

三个备库以只读方式打开

当前主库se 处于正常 OPEN 状态

备库处于日志传输状态。

1 停止备库日志传输

SQL> alterdatabaserecover ManagedStandby database cancel;

2 备库只读模式开启

SQL> alter database open read only;

3 备库返回日志传送模式

SQL>更改数据库恢复托管备用数据库与会话断开连接;

p>

介质恢复完成。

SQL> 从 v$instance 选择状态;< /p>

STATUS

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

MOUNTED

四路日志传输状态监控

1 主库检查当前日志状态

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

SEQUENCE# STATUS

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

51 活跃

52 当前

50 INACTIVE

2 检查备库RFS(远程文件服务)接收日志状态和MRP应用日志同步主库情况

SQL> SELECT PROCESS, STATUS, THREAD#、SEQUENCE#、BLOCK#、来自 V$MANAGED_STANDBY 的块;

进程状态线程#SEQUENCE#BLOCK#BLOCKS

--------- --- --------- ---------- ---------- - --------- ----------< /p>

ARCH 已连接 0 0 0 0

ARCH 已连接 0 0 0 0

RFS 接收 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

p>

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的数据已经应用到备库。

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

4检查备用数据库的归档重做

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

< p>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

注册创建者线程#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 检查备库应用的重做

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

线程#序列#FIRST_CHANGE#NEXT_CHANGE#

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

1 1 366852 368222

1 2 368222 369590

1 3 369590 371071< /p>

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

线程#序列#FIRST_CHANGE# NEXT_CHANGE#

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

1 12 413098 428161

1 13 428161 444373

1 14 444373 457815

1 15 457815 463016

1 15 457815 463016

p>

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

线程#序列#FIRST_CHANGE#NEXT_CHANGE#

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

1 23 549203 552403

1 24 552403 553230

1 25 553230 553398

1 26 553398 553695

1 27 553695 554327

< p>1 28 554327 557569

1 29 557569 561279

1 30 561279 561385

1 31 561385 566069

1 32 566069 566825

1 33 566825 570683

线程#序列#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< /p>

线程#序列#FIRST_CHANGE#NEXT_CHANGE#

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

1 45 593948 595131

1 46 595131 595471

1 47 595471 595731

1 48595731 601476

1 49 601476 601532

1 50 601532 606932

1 51 606932 607256

可以看到备库已经改变了SEQUENCE #将51的归档文件应用到备库。

6检查备库接收情况,使用redo数据流程。

SQL> 从 V$DATAGUARD_STATUS 中选择消息;

< p>消息

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

ARC0:归档开始

ARC0:成为“无 FAL”ARCH

ARC0:成为“无 SRL”ARCH

ARC0:成为“无 SRL”ARCH

p>

ARC1:归档已开始

ARC1:成为心跳ARCH

重做运输客户端以公共方式连接

--连接的用户有效

RFS[1]:分配给 RFS 进程 19740

RFS[1]:将数据库类型识别为“物理备用”

主数据库处于 MAXIMUM PERFORMANCE 模式< /p>

尝试启动后台托管备用恢复进程

MESSAGE

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

MRP0:后台托管备用恢复进程已启动

托管备用恢复不使用实时应用

清除联机重做日志文件 7 /oraguard/ redo1/redo_7_1.log

清除联机重做日志文件 7 已完成

媒体恢复等待线程 1 序列 47

RFS[1]:未创建备用重做日志文件

重做运输客户端以 PUBLIC 方式连接

--连接的用户有效

RFS[2]:分配给 RFS 进程 19746

RFS[2]: 识别数据库类型为“物理备用”

主数据库处于 MAXIMUM PERFORMANCE 模式

MESSAGE

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

提交创建归档日志“/arch/1_47_552308270.arc”

媒体恢复日志 /arch/1_47_552308270.arc

媒体恢复等待线程 1 序列 48

MRP0:后台媒体恢复已取消,状态为 16037

MRP0:高建群ound 媒体恢复进程关闭

托管备用恢复已取消

尝试启动后台托管备用恢复进程

MRP0:后台托管备用恢复进程已启动

托管备用恢复不使用实时应用

介质恢复正在等待线程 1 序列 48

RFS[1]:未创建备用重做日志文件

留言

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

提交创建归档日志'/ arch/1_48_552308270.arc'

介质恢复日志 /arch/1_48_552308270.arc

介质恢复正在等待线程 1 序列 49

RFS[1]:否已创建备用重做日志文件

正在提交创建归档日志“/arch/1_49_552308270.arc”

介质恢复日志/arch/1_49_552308270.arc

介质恢复正在等待线程 1 序列 50

RFS[1]:未创建备用重做日志文件

正在提交创建归档日志“/arch/1_50_552308270.arc”

介质恢复日志/arch/1_50_552308270.arc

媒体恢复等待线程 1 序列 51

MESSAGE

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

RFS[1]:未创建备用重做日志文件

正在提交创建归档日志'/arch/1_51_552308270.arc '

Media Recovery Log /arch/1_51_552308270.arc

Media Recovery Waiting for thread 1 sequence 52

可以看到RFS收到了带有序列的归档文件# 51并保存到备库归档目录/arch/1_51_552308270.arc。

Oracle自动应用文件/arch/1_51_552308270.arc来同步备库和主库

< p>Oracle继续等待主数据库归档文件的序列52

五、备份数据库归档目录维护

1查找备份数据库归档目录

SQL > 显示参数 log_archive_dest_1

名称类型

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

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

log_archive_dest_1 字符串

LOCATION=/arch

VALID_FOR=(ALL_LOGFILES,ALL_RO

LES)

< p>DB_UNIQUE_NAME=ora2

log_archive_dest_10字符串

2维护策略

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

具体参见附录2

第二部分:主库正常切换


手动后主库正常切换干预

1检查主库端数据库的可切换状态

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS

< p>-----------------

TO STANDBY

已选择 1 行

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> 从 V$DATABASE 中选择 SWITCHOVER_STATUS;

SWITCHOVER_STATUS

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

TO_PRIMARY< /p>

选择 1 行

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;< /p>

成功后执行此命令,备库变更为主库

6 重启目标备库

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP;

7 主数据库之前启动了日志传输过程

SQL> alter database recovery Managed Standby Database Disconnect;

总结:这样,主数据库一次正常切换就完成了。切换后,原主库变为备库,原备库变为主库。

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

< p >1 主库切换到备库

在主库上运行脚本

/admin/dataGuard/switchover/primary_to_standby.sh

2将备库切换为主库

在备库上运行脚本

/admin/dataGuard/switchover/standby_to_primary.sh

脚本1运行成功后,再次运行脚本2。二脚本不能同时运行。

切换后,原主库变为备库,原备库变为主数据,OPEN为应用提供服务。

< p> 3 恢复原始状态

在原备库上运行脚本

/admin/dataGuard/switchover/primary_to_standby.sh

成功完成后< /p>

在原主库上运行脚本

/admin/dataGuard/switchover/standby_to_primary.sh

第三部分主库灾难切换

手动干预主库灾难切换

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

SQL>alter database Recovery Managed Standby Database Cancel;

SQL>立即关闭

SQL>启动挂载

SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

SQL>alter database 恢复托管备用数据库finish;

--切换

SQL>alter 数据库提交切换到主数据库并关闭会话;

-- 打开

SQL>立即关闭

SQL>启动

附件:

选择后查看重做传输和应用程序状态

从v$dataguard_status中选择消息

where message_num>&message_num;

第二备用归档目录维护脚本

只需在crontab中自定义每天执行removeCommand.sh即可。

流程:每天晚上11:50执行removeCommand.sh

假设今天是2005年4月5日,删除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

导出 ORACLE_BASE=/ora10g/app

导出 ORACLE_HOME=$ORACLE_BASE/product/10.1.0/db_1

导出 ORACLE_SID=ora2< /p>

cd /oraguard/admin

$ORACLE_HOME/bin/sqlplus /nolog<

conn / as sysdba

@/oraguard/ admin/removeArch.sql

EOF

chmod +x /oraguard/ admin/removeArch.sh

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

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

[oracle@ db_gurid admin]$ cat removeArch.sql

关闭提要

关闭标题

关闭回显

设置回显

设置关闭

设置回显

p>

spool removeArch.sh

从 v$archived_log 中选择 'rm '||name,其中 Applied='YES' 且completion_time>trunc(sysdate-3) 和completion_time

spool off

以上就是DG的日常维护是怎样的。小编相信有些知识点在我们日常工作中可能会看到或者用到。希望您能从本文中了解更多信息。更多详情请关注行业资讯频道。

1. 本站所有资源来源于用户上传或网络,仅作为参考研究使用,如有侵权请邮件联系站长!
2. 本站积分货币获取途径以及用途的解读,想在本站混的好,请务必认真阅读!
3. 本站强烈打击盗版/破解等有损他人权益和违法作为,请各位会员支持正版!
4. 编程技术 > DG的日常维护保养有哪些?

用户评论