下载文档原格式
医院服务器网络系统日常维护手册1、硬件检查检查服务器、存储、交换机等硬件设备是否有亮警告黄灯或故障红灯（特别注意硬盘指示灯）。
2、检查系统日志是否报错右击桌面我的电脑管理系统工具事件查看器，注意有元红色打叉图标（特别注意系统类型所列的打红）。
3、检查RMAN备份是否正常完成RMAN备份一般存在E盘或F盘的RMAN目录下（如果不清楚RMAN备份路径可以在控制面板的任务计划打到RMAN备份的任务，右击属性即可查看），目录下是否存在后缀名为BAK的文件，打开full_log.txt文件查看内容，正常情况下应有“备份集已完成，经过时间：xx:xx:xx”、“完成backup于xx（日）-xx（月）-xx（年）”、“恢复管理器完成。
”等信息。
4、检查数据库日志是否报错数据库日志一般存放在当前服务器R:\ORACLE\ADMIN\HOSPITAL\BDUMP\ALERT_HOSPITAL.LOG中，检查的重点是看下当天的实时归档有没备份成功，数据库是否有报错误。
在发生错误的情况下，必须记录下错误代码，以便查明问题。
5、检查磁盘空间是否充足，定期备份或删除归档日志文件（归档日志一般存在ARCHIVE 文件夹内）先检查rman备份是否正常，如果当天备份正常，将一周前的所有归档文件迁移出服务器另外备份或直接删除。
6、定期检查数据库表空间状态使用oracle管理工具DBA Studio或Enterprise manager console登录系统，查看表空间使用率，超过95%的表空间就应该手工扩大表空间容量。
表空产容量扩大方法：增加新的数据库文件或扩大原数据文件大小。
32位系统还要检查单个数据文件是否接近4G大小，如果接近也应增加新的数据文件。
7、检查远程备份是否正常（没有远程备份不必检查）检查远程备份计算机与服务器相同备份路径是否存在后缀名为BAK的相同文件（由任务计划在晚上自动拷贝备份文件）。
8、检查DATAGUARD容灾是否正常（没有此容灾时不必检查）在做DATAGUARD容灾服务器的桌面上有日常检查批处理文件夹，检查新的归档日志文件是否应用到容灾库中，并检查归档文件夹内的归档文件是否为最新的归档。
文档标识文件状态：[] 草稿[√] 正式发布[ ] 正在修改Oracle RAC+DataGuard运维手册版本：1.0.0编制周光晖2015年01月20审核批准年月日生效日期：年月日修订历史记录日期版本修订说明作者目录第一章引言 (3)**. 编写目的 (3)**. 定义、首字母缩写词和缩略语 (4)第二章......................................................................................................... D ATA G UARD状态查询4**. 检查主备库的D ATA G UARD状态信息 (4)**. 检查进程 (4)**. 检查归档状态 (4)**. 检查最后应用的日志S EQUENCE (5)**. 查看是否使用实时应用 (5)**. 检查GAP (5)**. 检查保护模式 (5)**. 相关视图 (6)第三章................................................................................................................... SWITCHOVER 6**. 确认主库状态是否支持切换操作 (6)**. 执行主库转换 (7)**. 关闭并MOUNT新备库 (7)**. 确认老备库状态 (7)**. 切换目标备库为主库 (7)**. 打开新主库 (8)**. 启动新备库的日志应用 (8)**. 开启新备库的ADG (8)第一章引言1.1. 编写目的本文档描述了Oracle 11gR2 RAC+ADG操作手册。
包含RAC DOWN机测试，日常查询状态，启停RAC等指令同时包含oracle 11g R2 ACTIVE DATAGUARD 的日常维护指令。
1.2. 定义、首字母缩写词和缩略语第二章DataGuard状态查询2.1. 检查主备库的DataGuard状态信息SQL> Alter session set nls_date_format ='‘YYYY-MM-DD HH24:MISS';SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;使用V$DATAGUARD_STATUS结合alert日志信息，判断DataGuard使用过程中的错误信息，查看当前日志应用的状态。
DATAGUARD实施和维护总结1、DATAGUARD原理STANDBY一旦创建，DATAGUARD就会通过将主数据库的REDO传递给STANDBY数据库，然后在STANDBY中应用REDO实现数据库的同步。
有两种类型的STANDBY：物理STANDBY和逻辑STANDBY物理STANDBY提供与主数据库完全一样的拷贝（块到块），数据库SCHEMA，包括索引都是一样的。
它是直接应用REDO实现同步的。
逻辑STANDBY则不是这样，在逻辑STANDBY中，逻辑信息是相同的，但物理组织和数据结构可以不同，它和主库保持同步的方法是将接收的REDO转换成SQL语句，然后在STANDBY上执行SQL语句。
逻辑STANDBY除灾难恢复外还有其它用途，比如用于用户进行查询和报表。
DATAGUARD包含三个服务（日志传输、日志应用和角色转换）日志传输服务控制REDO数据的传输（传输日志，实施数据库保护模式）--------------STANDBY上通过起用RFS进程接收REDO数据。
日志应用服务则一方面自动应用日志，另一方面自动检测STANDBY缺少的REDO，并从主数据库或其它STANDBY 中自动查询出丢失的REDO。
DATAGUARD的几种保护模式：最大保护，最大可用，最大性能最大保护是指除非REDO在至少一个STANDBY中可用，否则事务不能提交。
如果在某个STANDBY中不可用，则主数据库的操作被停止。
最大可用是指如果STANDBY不可用，主数据库仍然可以处理事务，只是在问题被纠正后，STANDBY和主数据库进行再同步。
这样的一个问题是：当再同步之前有必要FAILOVER时，有些数据可能会丢失。
最大性能是指主数据库的提交操作不等待STANDBY。
物理STANDBY可能的模式：只读模式（OPEN READONLY）和恢复模式（MANANGED RECOVERY）2、物理DATAGUARD实施主数据库的准备工作：FORCE LOGGING，ENABLE ARCHIVING，一个本地归档目的地。
课课家教育-Oracle11g DataGuard容灾实施与维护实战视频课程课程目标：本套Oracle视频教程学完能够完成dataguard单机对单机的物理standby搭建,dataguard的日常维护,三种保护模式的切换,以及主备互换,故障failove切换等技能适合人群：oracle爱好者,想提高ORACLE高级技能.DataGuard技术是Oracle的一个重要容灾产品,在实际企业环境中使用相当广泛,本套Oracle视频教程培训学完能掌握：1、熟悉Oracle数据库容灾项目的实施与基本维护2、掌握Oracle Dataguard架构与基本概述3、熟悉Oracle Dataguard主库配置4、熟悉Oracle Dataguard备库配置5、熟悉Dataguard三种保护模式转换6、熟悉Dataguard物理standby和逻辑standby区别7、掌握Dataguard实时应用8、掌握Dataguard主备互换9、掌握dataguard故障切换failover目录第1节01-第1课-DataGuard概述及环境规划第2节第2课-DataGuard主库配置-100:13:48第3节第3课-DataGuard主库配置-200:18:03第4节第4课-DataGuard备库配置-100:04:45第5节第5课-DataGuard备库配置-200:09:03第6节第6课-使用RMAN Duplicate技术创建物理standby-1 00:10:27第7节第7课-使用RMAN Duplicate技术创建物理standby-2 00:07:11第8节第8课-添加Standby日志00:02:41第9节第9课-查询DataGuard状态00:03:31第10节第10课-开启同步00:02:50第11节第11课-数据同步测试-100:05:01第12节第12课-数据同步测试-200:03:20第13节第13课-DataGuard配置参数总结00:07:28第14节第14课-DataGuard日常维护-100:08:33第15节第15课-DataGuard日常维护-200:08:15第16节第16课-DataGuard三种保护模式00:03:36第17节第17课-SYNC-ASYNC-AFFIRM-NOAFFIRM参数00:04:35第18节第18课-DataGuard三种保护模式转换00:03:35第19节第19课-主备互换00:09:44第20节第20课-Failover切换00:05:09课程网址：/course-4226.html。
数据库服务器日常维护工作
1、服务器维护：
（1）定期观察服务器情况，发现异常及时通知信息管理处，信息管理处指派维护人员，维护人员到位后，帮忙输入密码进入系统，同时进行维护时须在场监督。
（2）病毒防范，发现病毒及时通告信息管理处并进行杀毒。
（3）管理好服务器管理员各种账号和密码，防范别人拷贝和浏览有关HR系统数据库中相关保密内容。
（4）管理服务器共享内容，不要随意共享服务器内容。
（5）机房需要进行停电时、网络调整等，配合信息管理处，如：关机、重启服务器等工作。
2、数据库维护：
（1）备份数据库：系统将设置自动备份数据（数据库和数据库日志），只需定期（每周一次）拷贝备份数据到其他存储设备（如：刻录CD，个人计算机、磁带等）；
观察硬盘容量，如发现硬盘空间不够时，清理掉已经备份出来的备份数据。
（2）数据库出现异常时，如数据库坏了，需要恢复数据库，信息管理处指派技术人员，技术人员到位后，帮忙输入密码进入数据库，同时进行数据库恢复必须在
场监督，禁止防范技术人员拷贝和浏览不要求内容。
（3）数据库出现其它异常问题时，技术人员到位后，帮忙输入密码进入系统，同时技术人员进行数据库修复时必须在场监督。
3、定期更改服务器的用户密码和远程控制软件的密码。
服务器放置
服务器放置在机房（机房具有UPS、网络保证等）；服务器管理员可以通过远程控制软件进行管理。
双机备份,dg,rac的区别Data Guard是Oracle的远程复制技术，它有物理和逻辑之分，但是总的来说，它需要在异地有一套独立的系统，这是两套硬件配置可以不同的系统，但是这两套系统的软件结构保持一致，包括软件的版本，目录存储结构，以及数据的同步（其实也不是实时同步的），这两套系统之间只要网络是通的就可以了，是一种异地容灾的解决方案。
而对于RAC，则是本地的高可用集群，每个节点用来分担不用或相同的应用，以解决运算效率低下，单节点故障这样的问题，它是几台硬件相同或不相同的服务器，加一个SAN（共享的存储区域）来构成的。
Data Guard由两个多两个以上的独立的数据库构成，他们各自有各自的存储，Oracle 负责他们之间的切换和数据同步双机热备由两台计算机和一个共享存储设备构成，通过第三方软件（HA Rose等）实现切换，不需要做数据同步建议应用RAC+Dataguard，RAC保证可用性，Dataguard在RAC组独立磁盘上和另外一台主机上，保证可靠性。
双机就是人们所说的双机热备,数据库放在共享设备上，同一时刻只能有一台主机接管，另一台待用，这种方式只能保护实例，不能保护db，而且备机长期处于闲置，对资源是一种极大的浪费！如果原本是双机，建议转换为RAC规划好应用，DML操作从一个节点跑，查询操作从另一个节点跑，通常不需要太多调优就可以利用闲置的另外一台机器了RAC服务器共用一套存储,同时提供服务,没有主备之分.宕一个其它的可以继续服务.双机热备,共用一套存储,一个提供服务一个备份,主机宕了切换到备份服务器提供服务. data guard完全两套系统,存储是单独的,用日志同步.RAC：实例层冗余DG：数据库层冗余热备：仅仅只是数据冗余个人理解：RAC：实例冗余，而且还可以做到数据库的loadbalance。
DG：多份数据，所以能做到数据冗余，但是只有主节点提供服务。
热备：与RAC最大的差异可能就是RAC有多个实例，一个数据库。
DATAGUARD实施和维护总结1、DATAGUARD原理STANDBY一旦创建，DATAGUARD就会通过将主数据库的REDO传递给STANDBY数据库，然后在STANDBY中应用REDO实现数据库的同步。
有两种类型的STANDBY：物理STANDBY和逻辑STANDBY物理STANDBY提供与主数据库完全一样的拷贝（块到块），数据库SCHEMA，包括索引都是一样的。
它是直接应用REDO实现同步的。
逻辑STANDBY则不是这样，在逻辑STANDBY中，逻辑信息是相同的，但物理组织和数据结构可以不同，它和主库保持同步的方法是将接收的REDO转换成SQL语句，然后在STANDBY上执行SQL语句。
逻辑STANDBY除灾难恢复外还有其它用途，比如用于用户进行查询和报表。
DATAGUARD包含三个服务（日志传输、日志应用和角色转换）日志传输服务控制REDO数据的传输（传输日志，实施数据库保护模式）--------------STANDBY上通过起用RFS进程接收REDO数据。
日志应用服务则一方面自动应用日志，另一方面自动检测STANDBY缺少的REDO，并从主数据库或其它STANDBY中自动查询出丢失的REDO。
DATAGUARD的几种保护模式：最大保护，最大可用，最大性能最大保护是指除非REDO在至少一个STANDBY中可用，否则事务不能提交。
如果在某个STANDBY中不可用，则主数据库的操作被停止。
最大可用是指如果STANDBY不可用，主数据库仍然可以处理事务，只是在问题被纠正后，STANDBY和主数据库进行再同步。
这样的一个问题是：当再同步之前有必要FAILOVER时，有些数据可能会丢失。
最大性能是指主数据库的提交操作不等待STANDBY。
物理STANDBY可能的模式：只读模式（OPEN READONLY）和恢复模式（MANANGED RECOVERY）2、物理DATAGUARD实施主数据库的准备工作：FORCE LOGGING，ENABLE ARCHIVING，一个本地归档目的地。
Oracle数据库日常运行维护方案2019年3月1项目背景及目标1.1 项目背景XXX信息化建设经过多年的发展和完善，已经建立成熟的网络环境及业务及管理的各类应用系统，目前在线运行的PC 近XX台，近年来建设的XX业务管理等若干应用信息系统多数是基于Oracle数据库系统的应用。
这些Oracle 数据库产品的标准服务都已经过了服务期。
而各系统随着数据量的逐年增加，陆续出现了性能问题，有必要进行数据库系统的升级及性能优化，以确保应用系统的正常运行，为XXX提供更好的信息服务。
1.2 项目目标➢尽早发现性能瓶颈，及时调整，保障数据库稳定高效工作；对各个系统数据库进行补丁升级服务，安装补丁前需要对补丁的可行性及风险即你想那个分析，并制定升级计划和应急回退计划。
同时要做好系统备份准备及详细的测试工作，确保系统的稳定性、安全性，保障系统业务数据的安全；➢数据库架构的合理化；➢提升应用系统性能，完成各系统数据库的性能调优工作，包括：外部资源调优、行的重新安排调优、SQL 性能调优、表格和索引存储参数设置调优等。
➢各业务持续性得到有效的保证。
2需求分析通过对xxx 技术要求进行详实的分析以及xxx信息系统建设的了解，各应用系统的Oracle产品日常运行维护项目主要从如下几个方面进行：1、由于 xxx 有些系统软件建设的较早，目前存在不同版本的数据库共存的现象，包括：Oralce8、Oracle9I、Oracle10g以及Oracle11g等。
而 Oracle9I 版本之前的数据库 SQL 编程语句还不是业界通用的标准化的语句，它与后面版本的 SQL 编程语句有很大的差别，所以在这方面的性能优化需要做好充分备份的准备。
2、正是由于这些系统建设的较早，基于当时的实际情况，应用系统或数据库都还存在一些不足，针对这些情况软件开发商都开发出相应的补丁提供给用户进行升级以防范风险。
所以在对各个系统数据库进行补丁升级服务之前，需要对补丁的可行性、安全性及风险进行充分的测试和分析。
DataGuard 日常维护数据库采用Oracle 10g版本.Dataguard采用最大性能模式.第一部分日常维护一正确打开主库和备库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;三备库Read-Only模式打开当前主库正常OPEN状态备库处于日志传送状态.1 在备库停止日志传送SQL> recover managed standby database cancel;2 备库Read-only模式打开SQL> alter database open read only;3 备库回到日志传送模式SQL> 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 ACTIVE52 CURRENT50 INACTIVE2 备库察看RFS(Remote File Service)接收日志情况和MRP应用日志同步主库情况SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS2 FROM V$MANAGED_STANDBY;PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS--------- ------------ ---------- ---------- ---------- ----------ARCH CONNECTED 0 0 0 0ARCH CONNECTED 0 0 0 0RFS RECEIVING 0 0 0 0MRP0 WAIT_FOR_LOG 1 52 0 0RFS RECEIVING 0 0 0 0可以看到备库MPR0正等待SEQUENCE#为52的redo.3 察看备库是否和主库同步SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#,APPLIED_THREAD#, APPLIED_SEQ#2 FROM V$ARCHIVE_DEST_STATUS;ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD#APPLIED_SEQ#---------------- ------------- --------------- ------------0 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 01 51 1 50可以看到备库已经将SEQUENCE#51的日志归档,已经将SEQUENCE#50的redo应用到备库.由于已经将SEQUENCE#51的日志归档,所以SEQUENCE#51以前的数据不会丢失.4 察看备库已经归档的redoSQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#,FIRST_CHANGE#,2 NEXT_CHANGE# FROM V$ARCHIVED_LOG;REGISTR CREATOR THREAD# SEQUENCE# FIRST_CHANGE#NEXT_CHANGE#------- ------- ---------- ---------- ------------- ------------SRMN SRMN 1 37 572907 573346RFS ARCH 1 38 573346 573538RFS ARCH 1 39 573538 573623RFS ARCH 1 40 573623 573627RFS ARCH 1 41 573627 574326RFS ARCH 1 42 574326 574480RFS ARCH 1 49 601476 601532RFS ARCH 1 50 601532 606932RFS ARCH 1 51 606932 6072565 察看备库已经应用的redoSQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#,NEXT_CHANGE#2 FROM V$LOG_HISTORY;THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#---------- ---------- ------------- ------------1 1 366852 3682221 2 368222 3695901 3 369590 3710711 4 371071 3723881 5 372388 3767811 6 376781 3977441 7 397744 4077381 8 407738 4130351 9 413035 4130371 50 601532 6069321 51 606932 607256可以看到备库已经将SEQUENCE#为51的归档文件应用到备库.6 察看备库接收,应用redo数据过程.SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;MESSAGE-------------------------------------------------------------------------------- ARC0: Archival startedARC0: Becoming the 'no FAL' ARCHARC0: Becoming the 'no SRL' ARCHARC1: Archival startedARC1: Becoming the heartbeat ARCHRedo Shipping Client Connected as PUBLIC-- Connected User is ValidRFS[1]: Assigned to RFS process 19740RFS[1]: Identified database type as 'physical standby'Primary database is in MAXIMUM PERFORMANCE mode Attempt to start background Managed Standby Recovery processMESSAGE-------------------------------------------------------------------------------- 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 completeMedia Recovery Waiting for thread 1 sequence 47RFS[1]: No standby redo logfiles createdRedo Shipping Client Connected as PUBLIC-- Connected User is ValidRFS[2]: Assigned to RFS process 19746RFS[2]: Identified database type as 'physical standby'Primary database is in MAXIMUM PERFORMANCE modeMESSAGE-------------------------------------------------------------------------------- Committing creation of archivelog '/arch/1_47_552308270.arc' Media Recovery Log /arch/1_47_552308270.arcMedia Recovery Waiting for thread 1 sequence 48MRP0: Background Media Recovery cancelled with status 16037 MRP0: Background Media Recovery process shutdown Managed Standby Recovery CanceledAttempt to start background Managed Standby Recovery process MRP0: Background Managed Standby Recovery process started Managed Standby Recovery not using Real Time ApplyMedia Recovery Waiting for thread 1 sequence 48RFS[1]: No standby redo logfiles createdMESSAGE-------------------------------------------------------------------------------- Committing creation of archivelog '/arch/1_48_552308270.arc'Media Recovery Log /arch/1_48_552308270.arcMedia Recovery Waiting for thread 1 sequence 49RFS[1]: No standby redo logfiles createdCommitting creation of archivelog '/arch/1_49_552308270.arc'Media Recovery Log /arch/1_49_552308270.arcMedia Recovery Waiting for thread 1 sequence 50RFS[1]: No standby redo logfiles createdCommitting creation of archivelog '/arch/1_50_552308270.arc'Media Recovery Log /arch/1_50_552308270.arcMedia Recovery Waiting for thread 1 sequence 51MESSAGE--------------------------------------------------------------------------------RFS[1]: No standby redo logfiles createdCommitting creation of archivelog '/arch/1_51_552308270.arc'Media Recovery Log /arch/1_51_552308270.arcMedia 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_1NAME TYPE------------------------------------ --------------------------------VALUE------------------------------log_archive_dest_1 stringLOCATION=/archVALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=ora2log_archive_dest_10 string2 维护策略每周2,4,7删除已经应用的归档文件具体参见附录二第二部分主库正常切换一人工干预主库正常切换1 在主库端检验数据库可切换状态SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS-----------------TO STANDBY1 row selectedSWITCHOVER_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_PRIMARY1 row selected5 将目标备库转换为主库如果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.sh2 备库切换为主库在备库上运行脚本/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 immediateSQL>startup mountSQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;SQL>alter database recover managed standby database finish;-- switchSQL>alter database commit to switchover to primary with session shutdown; -- openSQL>shutdown immediateSQL>startup附:一有选择察看redo传送与应用情况select message from v$dataguard_statuswhere message_num>&message_num;二备库归档目录维护脚本在crontab 中定制每日执行removeCommand.sh即可。
