ITPub博客
首页 博客 专栏 学院 社区 IT新媒体评选
发博

首页 > 数据库 > Oracle > Oracle 10g 物理Dataguard日常操作维护（二）

Oracle 10g 物理Dataguard日常操作维护（二）

Oracle 作者：gangade 时间：2017-02-06 16:14:14 0 删除 编辑
转发自：http://blog.csdn.net/evils798/article/details/8470072   小魔   
转发请注明此出处！

[javascript] view plain copy
  1. 3.3进程日志的监控操作  
  2.   
  3. 3.3.1 查看备库进程状态  
  4. SQL>select process,client_process,sequence#,status from v$managed_standby  
  5. PROCESS   CLIENT_P  SEQUENCE#    STATUS  
  6. ---------       --------     ---------- -      -----------  
  7. ARCH      ARCH            153       CLOSING  
  8. ARCH      ARCH            154       CLOSING  
  9. ARCH      ARCH            155       CLOSING  
  10. ARCH      ARCH            156       CLOSING  
  11. ARCH      ARCH            157       CLOSING  
  12. MRP0      N/A               158       WAIT_FOR_LOG  
  13. RFS       UNKNOWN           0       IDLE  
  14. RFS       UNKNOWN           0       IDLE  
  15. RFS       LGWR             158       IDLE  
  16. RFS       ARCH              0         IDLE  
  17.   
  18.   
  19. （1）PROCESS：进程名称，如ARCH、RFS、MRP0等。  
  20. （2）CLIENT_P：对应的Primary数据库中的进程，如ARCH、LGWR等。  
  21. （3）SEQUENCE#：归档序号。  
  22. （4）STATUS：进程的当前状态，值较多，常见的有：  
  23. 1）ALLOCATED：正准备连接Primary数据库。  
  24. 2）ATTACHED：正在连接Primary数据库。  
  25. 3）CONNECTED：已连接至Primary数据库。  
  26. 4）IDLE：空闲中。  
  27. 5）RECEIVING：归档文件接收中。  
  28. 6）OPENING：归档文件处理中。  
  29. 7）CLOSING：归档文件处理完，收尾中。  
  30. 8）WRITING：REDO数据库写向归档文件中。  
  31. 9）WAIT_FOR_LOG：等待新的REDO数据中。  
  32. 10）WAIT_FOR_GAP：归档有中断，正等待中断的那部分REDO数据。  
  33. 11）APPLYING_LOG：应用REDO数据中。  
  34. 通过上述查询可以得知Primary开了两个归档进程，使用ARCH同步传输方式与物理Standby通信，已经接收完序号为157的日志，正等待序号为158的日志  
  35.   
  36.   
  37. 3.3.2 查看物理Standby数据库未接收的日志文件  
  38.   
  39. 这种查询从Primary端获取。日志文件的发送是通过LOG_ARHIVE_DEST_N参数来控制，因此我们只需要对比本地生成的归档和远端生成的归档间差异即可。例如：  
  40.   
  41. SQL>  SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM  (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG    WHERE DEST_ID=1) LOCAL   
  42.  WHERE LOCAL.SEQUENCE# NOT IN   (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND    THREAD# = LOCAL.THREAD#);  
  43.   
  44.    THREAD#  SEQUENCE#  
  45. ---------- ----------  
  46.          1         53  
  47.          1         54  
  48.          1         55  
  49.          1         56  
  50.          1         57  
  51.          1         58  
  52.          1         59  
  53.          1         60  
  54.          1         61  
  55.          1         62  
  56.  DEST_ID=N，N其实就是LOG_ARCHIVE_DEST_N参数中的那个N。  
  57.   
  58.   
  59. 3.3.3查询standby 最后应用的归档文件  
  60.   
  61. SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG"  FROM V$LOG_HISTORY GROUP BY THREAD#;    
  62.   
  63.    THREAD#    LAST_APPLIED_LOG  
  64. ----------              ----------------  
  65.          1              157  
  66.   
  67. 3.3.4 或者查询归档日志应用情况  
  68.   
  69. SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;   
  70.   
  71.    THREAD#  SEQUENCE# APP  
  72. ---------- ---------- ---  
  73.          1         67 YES  
  74.          1         85 YES  
  75.          1         70 YES  
  76.          1         69 YES  
  77. 3.3.5检查归档文件路径和创建信息  
  78. 物理Standby数据库端可以通过查询V$ARCHIVED_LOG视图，获取归档文件的一些附加信息，如文件创建时间、创建进程、归档序号、是否被应用等，例如：  
  79. SQL>SELECT NAME,CREATOR,SEQUENCE#,APPLIED,COMPLETION_TIME FROM V$ARCHIVED_LOG  
  80. NAME                              CREATOR  SEQUENCE# APP COMPLETION_TIM  
  81. ---------------------------------------- ------- ---------- --- --------------  
  82. /sywdg/arch1/1_144_758642906.dbf         ARCH           144 YES 28-8月 -11  
  83. /sywdg/arch1/1_143_758642906.dbf         ARCH           143 YES 28-8月 -11  
  84. /sywdg/arch1/1_147_758642906.dbf         ARCH           147 YES 28-8月 -11  
  85. /sywdg/arch1/1_148_758642906.dbf         ARCH           148 YES 28-8月 -11  
  86. /sywdg/arch1/1_150_758642906.dbf         ARCH           150 YES 28-8月 -11  
  87. /sywdg/arch1/1_149_758642906.dbf         ARCH           149 YES 28-8月 -11  
  88. /sywdg/arch1/1_151_758642906.dbf         ARCH           151 YES 28-8月 -11  
  89. /sywdg/arch1/1_152_758642906.dbf         ARCH           152 YES 28-8月 -11  
  90. /sywdg/arch1/1_153_758642906.dbf         ARCH           153 YES 28-8月 -11  
  91. /sywdg/arch1/1_154_758642906.dbf         ARCH           154 YES 28-8月 -11  
  92. /sywdg/arch1/1_155_758642906.dbf         ARCH           155 YES 28-8月 -11  
  93.   
  94.   
  95.   
  96. 3.3.6．Data Guard事件（V$DATAGUARD_STATUS）  
  97. 该视图显示那些被自动触发写入Alert.log或服务器Trace文件的事件。不查服务器查询Alert.log时，可以临时访问本视图查看一些与Data Guard相关的信息，例如：  
  98.   
  99. SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;    
  100.   
  101. MESSAGE  
  102. ----------------------------------------------------------------------------------------------------  
  103. Media Recovery Waiting for thread 1 sequence 148  
  104. Redo Shipping Client Connected as PUBLIC  
  105. -- Connected User is Valid  
  106. RFS[1]: Assigned to RFS process 1617  
  107. RFS[1]: Identified database type as 'physical standby'  
  108. Redo Shipping Client Connected as PUBLIC  
  109. -- Connected User is Valid  
  110. RFS[2]: Assigned to RFS process 1619  
  111. RFS[2]: Identified database type as 'physical standby'  
  112. Media Recovery Log /sywdg/arch1/1_148_758642906.dbf  
  113. Media Recovery Waiting for thread 1 sequence 149  
  114.   
  115.   
  116.   
  117.   
  118. 3.4 LGWR SYNC模式下日志同步测试  
  119.   
  120. 1.主库执行 查询a表  
  121.   
  122. SQL> select * from a;  
  123.   
  124.          I  
  125. ----------  
  126.          1  
  127.          1  
  128.          1  
  129.          1  
  130.          1  
  131.          1  
  132.          1  
  133.   
  134. 已选择7行。  
  135.   
  136. 2.此时备库以 read only 模式打开，现在对standby 进行查询  
  137.   
  138. SQL> select * from a;  
  139.   
  140.          I  
  141. ----------  
  142.          1  
  143.          1  
  144.          1  
  145.          1  
  146.          1  
  147.          1  
  148.          1  
  149.   
  150. 已选择7行。  
  151. 3.主库备库的数据是一样的，现在把standby备库继续进行日志恢复模式，来接收主库的redo信息  
  152. 在备库上执行  
  153.   
  154. SQL> alter database recover managed standby database disconnect from session;  
  155.   
  156. 数据库已更改。  
  157.   
  158. 4.查询备库的运行模式  
  159.   
  160. SQL> select protection_mode,protection_level from v$database;  
  161.   
  162. PROTECTION_MODE      PROTECTION_LEVEL  
  163. -------------------- --------------------  
  164. MAXIMUM AVAILABILITY MAXIMUM AVAILABILIT  
  165.   
  166. 说明：备库是运行在最大可用模式，当dataguard 处于最大可用模式时，如果主库与备库之间没有通信（例如网络断开），主库与备库自动切换值最大性能模式，此时主库上的redolog无法正常传输到备库，当主库上redo在经过日志切换后会被写至主库的归档文件中，当主库与备库正常通信后，主库会强行进行current online redo归档转换，并且通过LNS传输redo信息，在备库oracle利用RFS接收主库redo信息来real time apply进行恢复，因此保持主库与备库的数据一致性  
  167.   
  168. 5.现在断开备库网络  
  169.   
  170. [root@DB_standby ~]# service network  stop  
  171. 正在关闭接口 eth0：                                        [确定]  
  172. 关闭环回接口：                                             [确定]  
  173.   
  174. 此时主库的redo信息无法正常传送到备库  
  175.   
  176. 6.在主库上执行delete 操作并提交  
  177.   
  178. SQL> delete from a where rownum<7;  
  179.   
  180. 已删除6行。  
  181.   
  182. SQL> select * from a;  
  183.   
  184.          I  
  185. ----------  
  186.          1  
  187.   
  188. SQL> commit;  
  189.   
  190. 提交完成。  
  191.   
  192. 7.在主库上进行日志切换，将当前redolog归档  
  193.   
  194. SQL> alter system switch logfile;  
  195.   
  196. SQL> alter system switch logfile;  
  197.   
  198. 系统已更改。  
  199.   
  200. SQL> alter system switch logfile;  
  201.   
  202. 系统已更改。  
  203.   
  204. SQL> select protection_mode,protection_level from v$database;  
  205.   
  206. PROTECTION_MODE      PROTECTION_LEVEL  
  207. -------------------- --------------------  
  208. MAXIMUM AVAILABILITY RESYNCHRONIZATION  
  209.   
  210. 由于主库与备库无法正常通信，保护级别变成了待同步模式，此时查看主库归档日志，发现日志213至219无法传递至备库  
  211.   
  212. Current log# 1 seq# 213 mem# 0: /u01/app/oracle/oradata/syw01/redo01.log  
  213. Mon Aug 29 21:41:09 2011  
  214. ORA-16198: LGWR received timedout error from KSR  
  215. LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16198)  
  216. LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned  
  217. Mon Aug 29 21:41:09 2011  
  218. Errors in file /u01/app/oracle/admin/syw01/bdump/syw01_lgwr_4966.trc:  
  219. ORA-16198: 远程归档期间内部通道上超时  
  220. LGWR: Network asynch I/O wait error 16198 log 1 service 'syw'  
  221. Mon Aug 29 21:41:09 2011  
  222. Errors in file /u01/app/oracle/admin/syw01/bdump/syw01_lgwr_4966.trc:  
  223. ORA-16198: 远程归档期间内部通道上超时  
  224. LGWR: Error 16198 closing archivelog file 'syw'  
  225. LGWR: Error 16198 disconnecting from destination LOG_ARCHIVE_DEST_2 standbyhost 'syw'  
  226. Thread 1 advanced to log sequence 214  
  227.   Current log# 2 seq# 214 mem# 0: /u01/app/oracle/oradata/syw01/redo02.log  
  228. Mon Aug 29 21:42:31 2011  
  229. Thread 1 advanced to log sequence 215  
  230.   Current log# 3 seq# 215 mem# 0: /u01/app/oracle/oradata/syw01/redo03.log  
  231. Thread 1 cannot allocate new log, sequence 216  
  232. Checkpoint not complete  
  233.   Current log# 3 seq# 215 mem# 0: /u01/app/oracle/oradata/syw01/redo03.log  
  234. Thread 1 advanced to log sequence 216  
  235.   Current log# 1 seq# 216 mem# 0: /u01/app/oracle/oradata/syw01/redo01.log  
  236. Mon Aug 29 21:42:49 2011  
  237. Thread 1 cannot allocate new log, sequence 217  
  238. Checkpoint not complete  
  239.   Current log# 1 seq# 216 mem# 0: /u01/app/oracle/oradata/syw01/redo01.log  
  240.   
  241.  Thread 1 advanced to log sequence 217  
  242.   Current log# 2 seq# 217 mem# 0: /u01/app/oracle/oradata/syw01/redo02.log  
  243. Mon Aug 29 21:45:32 2011  
  244. Thread 1 advanced to log sequence 218  
  245.   Current log# 3 seq# 218 mem# 0: /u01/app/oracle/oradata/syw01/redo03.log  
  246. Mon Aug 29 21:46:36 2011  
  247. ARCH: Possible network disconnect with primary database  
  248. LNSb started with pid=21, OS id=15612  
  249. Mon Aug 29 21:46:57 2011  
  250. LGWR: Standby redo logfile selected to archive thread 1 sequence 219  
  251. LGWR: Standby redo logfile selected for thread 1 sequence 219 for destination LOG_ARCHIVE_DEST_2  
  252. Thread 1 advanced to log sequence 219  
  253.   Current log# 1 seq# 219 mem# 0: /u01/app/oracle/oradata/syw01/redo01.l  
  254.   
  255. 说明：由于我在主库上执行了删除操作，此时主库上a表只有1行数据，  
  256. 现在验证：在主库与备库正常通信后，主库的归档日志可以自动传输到备库并且被备库应用  
  257. 使得备库的a表中数据与主库一样  
  258.   
  259. 8.启动备库网络服务  
  260.   
  261. [root@DB_standby ~]# service network  start  
  262. 弹出环回接口：                                             [确定]  
  263. 弹出界面 eth0：                                            [确定]  
  264. 查看备库警告日志  
  265.   
  266. -- Connected User is Valid  
  267. RFS[16]: Assigned to RFS process 13763  
  268. RFS[16]: Identified database type as 'physical standby'  
  269. Mon Aug 29 21:46:58 2011  
  270. RFS[12]: Archived Log: '/sywdg/arch1/1_214_758642906.dbf'  
  271. Mon Aug 29 21:46:59 2011  
  272. RFS[16]: Successfully opened standby log 5: '/u01/app/oracle/oradata/stdby_redo05.log'  
  273. Mon Aug 29 21:47:00 2011  
  274. RFS[11]: Archived Log: '/sywdg/arch1/1_217_758642906.dbf'  
  275. Mon Aug 29 21:47:14 2011  
  276. RFS[14]: Archived Log: '/sywdg/arch1/1_213_758642906.dbf'  
  277. Mon Aug 29 21:47:16 2011  
  278. Media Recovery Log /sywdg/arch1/1_213_758642906.dbf  
  279. Mon Aug 29 21:47:26 2011  
  280. RFS[13]: Archived Log: '/sywdg/arch1/1_215_758642906.dbf'  
  281. Mon Aug 29 21:47:40 2011  
  282. Media Recovery Log /sywdg/arch1/1_214_758642906.dbf  
  283. Mon Aug 29 21:47:40 2011  
  284. Primary database is in MAXIMUM AVAILABILITY mode  
  285. Changing standby controlfile to MAXIMUM AVAILABILITY level  
  286. RFS[15]: Successfully opened standby log 5: '/u01/app/oracle/oradata/stdby_redo05.log'  
  287. Mon Aug 29 21:47:41 2011  
  288. Media Recovery Log /sywdg/arch1/1_215_758642906.dbf  
  289. Media Recovery Log /sywdg/arch1/1_216_758642906.dbf  
  290. Media Recovery Log /sywdg/arch1/1_217_758642906.dbf  
  291. Media Recovery Log /sywdg/arch1/1_218_758642906.dbf  
  292. Media Recovery Log /sywdg/arch1/1_219_758642906.dbf  
  293.   
  294.   
  295. 主库上的归档日志自动传到备库，并且恢复成功，现在只要验证备库的a表是否与主库a表一致  
  296.   
  297. 9.以只读方式打开备库  
  298.   
  299. SQL> alter database recover managed standby database cancel;  
  300.   
  301. 数据库已更改。  
  302.   
  303. SQL> alter database open;  
  304.   
  305. 数据库已更改。  
  306.   
  307. SQL> select * from a;  
  308.   
  309.          I  
  310. ----------  
  311.          1  
  312.   
  313. 10.经查询 备库与主库的a表一致，在主库进行删除a表数据后，备库通过主库之后传来的归档日志以oracle内部机制，应用当前归档日志保持与主库数据同步  
  314.   
  315. 3.5 以read write方式打开物理standby  
  316.    
  317. 使用DG中还原点和数据库闪回的组合功能，物理备库可以临时为开发，报表或测试目的以读/写模式打开，然后闪回在过去的一个点恢复物理备用数据库。闪回数据库时，Data Guard备库与主数据库将自动同步，而不需要从主数据库的备份副本重新创建物理备库。  
  318.   
  319. 通过下面演示操作将在real-time apply状态的物理备库以读写模式打开  
  320. 3.5.1 在备库上设置闪回区大小及其路径  
  321.   
  322. SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=2G;      
  323. 系统已更改。  
  324. SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/arch/oradata';  
  325. 如果不指定闪回路径则oracle将用默认的FRA  
  326.   
  327. 3.5.2 在备库上停止standbyd备库的实时应用并创建还原点  
  328. SQL> alter database  recover managed standby database cancel;  
  329. 数据库已更改。  
  330. SQL> CREATE RESTORE POINT  before_app GUARANTEE FLASHBACK DATABASE;  
  331. 还原点已创建。  
  332.   
  333. 3.5.3.在主库上归档主库的当前日志，并将备库的归档目的地设置为defer  
  334.   
  335. SQL> alter system archive log current;  
  336. 系统已更改。  
  337. SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;  
  338. 系统已更改。  
  339.   
  340.   
  341. 3.5.4 激活物理备库，在备库上执行  
  342.   
  343. SQL> alter database activate standby database;  
  344. 数据库已更改。  
  345. SQL> startup mount force;  
  346. ORACLE 例程已经启动。  
  347. Total System Global Area  285212672 bytes  
  348. Fixed Size                  2020224 bytes  
  349. Variable Size              96472192 bytes  
  350. Database Buffers          184549376 bytes  
  351. Redo Buffers                2170880 bytes  
  352. 数据库装载完毕。  
  353.   
  354. 3.5.5将备库设置为最大性能模式并以读写模式打开备库.  
  355.   
  356. SQL> alter database set standby database to maximize performance;  
  357. 数据库已更改。  
  358.   
  359. SQL> alter database open ;  
  360. 数据库已更改。  
  361.   
  362.   
  363. 此时在备库警告日志会显示当前闪回区大小及使用率和数据库实例状态，日志传送信息，可以发现主库归档日不会传至备库  
  364.   
  365. LOGSTDBY: Validation complete  
  366. Wed Aug 31 11:06:59 2011  
  367. db_recovery_file_dest_size of 2048 MB is 5.03% used. This is a  
  368. user-specified limit on the amount of space that will be used by this  
  369. database for recovery-related files, and does not reflect the amount of  
  370. space available in the underlying filesystem or ASM diskgroup.  
  371. Wed Aug 31 11:07:09 2011  
  372. Completed: alter database open  
  373. Errors in file /u01/app/oracle/admin/syw/bdump/syw_arc2_29307.trc:  
  374. ORA-16009: 远程归档日志目标必须为备用数据库  
  375. Wed Aug 31 11:12:23 2011  
  376. PING[ARC2]: Heartbeat failed to connect to standby 'syw01'. Error is 16009.  
  377. Wed Aug 31 11:13:24 2011  
  378. Shutting down archive processes  
  379. Wed Aug 31 11:13:29 2011  
  380. ARCH shutting down  
  381. ARC5: Archival stopped  
  382.   
  383. 3.5.6.备库读写测试  
  384.   
  385. 查看备库读写模式，此时备库是以读写模式打开  
  386.   
  387.   
  388. SQL> select open_mode from v$database;  
  389.   
  390. OPEN_MODE  
  391. ----------  
  392. READ WRITE  
  393.   
  394. 在备库上执行DML， DDL操作来验证备库  
  395.   
  396. SQL> create table flash_test (i int);  
  397.   
  398. 表已创建。  
  399.   
  400. SQL> insert into flash_test values(1);  
  401.   
  402. 已创建 1 行。  
  403.   
  404. SQL> commit;  
  405.   
  406. 提交完成。  
  407.   
  408. SQL> alter system switch logfile;  
  409.   
  410. 系统已更改  
  411.   
  412.   
  413. 经过commit,和日志切换之后，在备库上进行查询，此时备库已有数据可以查询，证明切换备库读写模式成功  
  414.   
  415. SQL> select * from flash_test;  
  416.   
  417.          I  
  418. ----------  
  419.          1  
  420.   
  421.   
  422. 同时在主库上执行DML,DDL操作，将为之后的同步验证做准备  
  423.   
  424. SQL> create table test_primary (i int);  
  425.   
  426. 表已创建。  
  427.   
  428. SQL> insert into test_primary values(1);  
  429.   
  430. 已创建 1 行。  
  431.   
  432. SQL> commit;  
  433.   
  434. 提交完成。  
  435.   
  436. SQL> alter system switch logfile;  
  437.   
  438. 系统已更改。  
  439.   
  440.   
  441. SQL> select * from  test_primary;  
  442.   
  443.          I  
  444. ----------  
  445.          1  
  446.   
  447. 在主库上可以做正常查询和和其他操作，此时不会对备库有任何影响，主库的警告日志会提示设置正确的备库归档目的地  
  448.   
  449. RFS[43]: Assigned to RFS process 5598  
  450. RFS[43]: Database mount ID mismatch [0x152e1eba:0x152b137a]  
  451. RFS[43]: Not using real application clusters  
  452. Wed Aug 31 13:27:59 2011  
  453. Errors in file /u01/app/oracle/admin/syw01/udump/syw01_rfs_5598.trc:  
  454. ORA-16009: 远程归档日志目标必须为备用数据库  
  455. Redo Shipping Client Connected as PUBLIC  
  456. -- Connected User is Valid  
  457. RFS[44]: Assigned to RFS process 5775  
  458. RFS[44]: Database mount ID mismatch [0x152e1eba:0x152b137a]  
  459. RFS[44]: Not using real application clusters  
  460. Wed Aug 31 13:32:59 2011  
  461. Errors in file /u01/app/oracle/admin/syw01/udump/syw01_rfs_5775.trc:  
  462. ORA-16009: 远程归档日志目标必须为备用数据库  
  463.   
  464.   
  465. 接下来将standby 切回至实时应用模式，在备库执行  
  466.   
  467. SQL> STARTUP MOUNT FORCE;  
  468. ORACLE 例程已经启动。  
  469. Total System Global Area  285212672 bytes  
  470. Fixed Size                  2020224 bytes  
  471. Variable Size             100666496 bytes  
  472. Database Buffers          180355072 bytes  
  473. Redo Buffers                2170880 bytes  
  474. 数据库装载完毕。  
  475.   
  476. 在备库开始执行闪回  
  477.   
  478. SQL> flashback database to restore point before_app;  
  479. 闪回完成。  
  480. SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;  
  481. 数据库已更改  
  482.   
  483. 备库警告日志出现如下提示，备库转化完成  
  484.   
  485. Wed Aug 31 14:17:05 2011  
  486. flashback database to restore point before_app  
  487. Wed Aug 31 14:17:06 2011  
  488. Flashback Restore Start  
  489. Wed Aug 31 14:17:41 2011  
  490. Flashback Restore Complete  
  491. Completed: flashback database to restore point before_app  
  492. ALTER DATABASE CONVERT TO PHYSICAL STANDBY  
  493. Wed Aug 31 14:20:42 2011  
  494. ALTER DATABASE CONVERT TO PHYSICAL STANDBY (syw)  
  495. Wed Aug 31 14:20:42 2011  
  496. The primary database controlfile was created using the  
  497. 'MAXLOGFILES 16' clause.  
  498. There is space for up to 13 standby redo logfiles  
  499. Use the following SQL commands on the standby database to create  
  500. standby redo logfiles that match the primary database:  
  501. ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;  
  502. ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;  
  503. ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;  
  504. ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;  
  505. Setting recovery target incarnation to 2  
  506. Completed: ALTER DATABASE CONVERT TO PHYSICAL STANDBY  
  507.   
  508.   
  509. 在备库上再次执行STARTUP MOUNT FORCE;  
  510.   
  511. SQL> STARTUP MOUNT FORCE;  
  512. ORACLE 例程已经启动。  
  513. Total System Global Area  285212672 bytes  
  514. Fixed Size                  2020224 bytes  
  515. Variable Size             100666496 bytes  
  516. Database Buffers          180355072 bytes  
  517. Redo Buffers                2170880 bytes  
  518. 数据库装载完毕。  
  519.   
  520. 现在开始与主库进行同步操作，在备库上执行  
  521.   
  522. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;  
  523. 数据库已更改。  
  524.   
  525. 在主库上执行如下命令来开启standby的日志传输目的地，以保证日志能给正常传到备库  
  526.   
  527. SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;  
  528. 系统已更改。  
  529.   
  530.   
  531. 观察备库的alert警告日志  
  532.   
  533. -- Connected User is Valid  
  534. RFS[1]: Assigned to RFS process 3828  
  535. RFS[1]: Identified database type as 'physical standby'  
  536. RFS LogMiner: Client disabled from further notification  
  537. Clearing online redo logfile 3 complete  
  538. Media Recovery Log /sywdg/arch1/1_240_758642906.dbf  
  539. Wed Aug 31 14:28:02 2011  
  540. db_recovery_file_dest_size of 2048 MB is 5.96% used. This is a  
  541. user-specified limit on the amount of space that will be used by this  
  542. database for recovery-related files, and does not reflect the amount of  
  543. space available in the underlying filesystem or ASM diskgroup.  
  544. Wed Aug 31 14:28:15 2011  
  545. Media Recovery Log /sywdg/arch1/1_241_758642906.dbf  
  546. Media Recovery Waiting for thread 1 sequence 242  
  547. Fetching gap sequence in thread 1, gap sequence 242-242  
  548. Wed Aug 31 14:28:28 2011  
  549. Redo Shipping Client Connected as PUBLIC  
  550. 3.5.7 验证standby备库同步  
  551.   
  552. 说明：在standby切换至读写模式时，主库与备库之间redo信息无法传输，此时主库上有DDL，DML操作，其中创建了表test_primary，并对其进行insert操作，因此备库无法通过主库redo信息来进行实时应用与主库进行数据同步，当把standby备库由读写模式切换至时时应用模式时，备库应该通过stanby redo log 实时应用来保持与主库数据一致  
  553.   
  554. 在主库上执行查询操作  
  555.   
  556.   
  557. SQL> select * from test_primary;  
  558.   
  559.          I  
  560. ----------  
  561.          1  
  562.   
  563.   
  564. 在备库上执行  
  565.   
  566.   
  567. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel;  
  568.   
  569. 数据库已更改。  
  570.   
  571. SQL> alter database open;  
  572.   
  573. 数据库已更改。  
  574.   
  575. SQL> select * from test_primary;  
  576.   
  577.          I  
  578. ----------  
  579.          1  
  580.   
  581.   
  582. 主库与备库此时数据已经一致                                                                                                                                                                                                                                                                                           3.6  DATAGUARD 备份恢复  
  583. 3.6.1 DATAGUARD的备份  
  584. 通常可以为了减轻主库的负担，可以用rman备份备库，登录备库  
  585. [oracle@DB_standby arch1]$ rman nocatalog target sys/oracle@syw01  
  586. 恢复管理器: Release 10.2.0.1.0 - Production on 星期日 8月 23 15:25:12 2011  
  587. Copyright (c) 1982, 2005, Oracle.  All rights reserved.  
  588. 已连接到目标数据库: SYW (DBID=353353625, 未打开)  
  589. 使用目标数据库控制文件替代恢复目录，对备库执行备份，运行如下备份脚本  
  590.   
  591.   
  592. RMAN>run {  
  593. allocate channel d1 device type disk;  
  594. backup as compressed backupset  
  595. incremental level=0  
  596. format='/sywdg/dgbak/inc0_stb_%d_%U'  
  597. tag='inc0_stb'  
  598. channel=d1  
  599. database;  
  600. backup as compressed backupset  
  601. format='/sywdg/dgbak/arch_stb_%d_%U'  
  602. tag='arch_stb'  
  603. channel=d1  
  604. archivelog all delete input;  
  605. }  
  606.                
  607.   
  608.   
  609. 分配的通道: d1  
  610. 通道 d1: sid=148 devtype=DISK  
  611.   
  612.   
  613. 启动 backup 于 23-8月 -11  
  614. 通道 d1: 启动压缩的增量级别 0 数据文件备份集  
  615. 通道 d1: 正在指定备份集中的数据文件  
  616. 输入数据文件 fno=00007 name=/u01/app/oracle/oradata/syw01/tbs_syw01.ora  
  617. 输入数据文件 fno=00001 name=/u01/app/oracle/oradata/syw01/system01.dbf  
  618. 输入数据文件 fno=00004 name=/u01/app/oracle/oradata/syw01/users01.dbf  
  619. 输入数据文件 fno=00006 name=/u01/app/oracle/oradata/syw01/tbs_cms.ora  
  620. 输入数据文件 fno=00003 name=/u01/app/oracle/oradata/syw01/sysaux01.dbf  
  621. 输入数据文件 fno=00005 name=/u01/app/oracle/oradata/syw01/TBS_IDX_SYW.ora  
  622. 输入数据文件 fno=00002 name=/u01/app/oracle/oradata/syw01/undotbs01.dbf  
  623. 输入数据文件 fno=00008 name=/u01/t.dbf  
  624. 通道 d1: 正在启动段 1 于 23-8月 -11  
  625. 通道 d1: 已完成段 1 于 23-8月 -11  
  626. 段句柄=/sywdg/dgbak/inc0_stb_SYW_1hml4v4e_1_1 标记=INC0_STB 注释=NONE  
  627. 通道 d1: 备份集已完成, 经过时间:00:02:36  
  628. 通道 d1: 启动压缩的增量级别 0 数据文件备份集  
  629. 通道 d1: 正在指定备份集中的数据文件  
  630. 备份集中包括当前控制文件  
  631. 在备份集中包含当前的 SPFILE  
  632. 段句柄=/sywdg/dgbak/inc0_stb_SYW_1iml4v9b_1_1 标记=INC0_STB 注释=NONE  
  633. 通道 d1: 备份集已完成, 经过时间:00:00:02  
  634. 完成 backup 于 23-8月 -11  
  635. 启动 backup 于 23-8月 -11  
  636. 通道 d1: 启动压缩的归档日志备份集  
  637. 通道 d1: 正在指定备份集中的存档日志  
  638. 输入存档日志线程 =1 序列 =158 记录 ID=103 时间戳=760378683  
  639. 输入存档日志线程 =1 序列 =159 记录 ID=102 时间戳=760378653  
  640. 输入存档日志线程 =1 序列 =160 记录 ID=104 时间戳=760378687  
  641. 输入存档日志线程 =1 序列 =161 记录 ID=105 时间戳=760380176  
  642. 输入存档日志线程 =1 序列 =162 记录 ID=106 时间戳=760380266  
  643. 输入存档日志线程 =1 序列 =163 记录 ID=107 时间戳=760380288  
  644. 输入存档日志线程 =1 序列 =164 记录 ID=108 时间戳=760380707  
  645. 输入存档日志线程 =1 序列 =165 记录 ID=109 时间戳=760380713  
  646. 通道 d1: 正在启动段 1 于 28-8月 -11  
  647. 通道 d1: 已完成段 1 于 28-8月 -11  
  648. 段句柄=/sywdg/dgbak/arch_stb_SYW_1jml4v9h_1_1 标记=ARCH_STB 注释=NONE  
  649. 通道 d1: 备份集已完成, 经过时间:00:00:02  
  650. 通道 d1: 正在删除存档日志  
  651. 存档日志文件名 =/sywdg/arch1/1_158_758642906.dbf 记录 ID=103 时间戳 =760378683  
  652. 存档日志文件名 =/sywdg/arch1/1_159_758642906.dbf 记录 ID=102 时间戳 =760378653  
  653. 存档日志文件名 =/sywdg/arch1/1_160_758642906.dbf 记录 ID=104 时间戳 =760378687  
  654. 存档日志文件名 =/sywdg/arch1/1_161_758642906.dbf 记录 ID=105 时间戳 =760380176  
  655. 存档日志文件名 =/sywdg/arch1/1_162_758642906.dbf 记录 ID=106 时间戳 =760380266  
  656. 存档日志文件名 =/sywdg/arch1/1_163_758642906.dbf 记录 ID=107 时间戳 =760380288  
  657. 存档日志文件名 =/sywdg/arch1/1_164_758642906.dbf 记录 ID=108 时间戳 =760380707  
  658. 存档日志文件名 =/sywdg/arch1/1_165_758642906.dbf 记录 ID=109 时间戳 =760380713  
  659. 完成 backup 于 28-8月 -11  
  660. 释放的通道: d1  
  661. 3.6.2 Standby RMAN备份排错  
  662. Rman对standby 进行备份时，长出现如下报错信息  
  663.   
  664. 通道 d1: 备份集已完成, 经过时间:00:00:03  
  665. 完成 backup 于 23-8月 -11  
  666. RMAN-08132: 警告: 无法更新恢复区可回收文件列表  
  667. 释放的通道: d1  
  668. MAN-00571: ===========================================================  
  669. RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============  
  670. RMAN-00571: ===========================================================  
  671. RMAN-03009: REFAF 命令 (default 通道上, 在 08/23/2011 16:44:53 上) 失败  
  672. ORA-00604: 递归 SQL 级别 1 出现错误  
  673. ORA-01219: 数据库未打开: 仅允许在固定表/视图中查询  
  674.                                                                                                                                                          这是一个oracle的一个bug,需要对standby进行如下丢该  
  675. SQL> alter system set  optimizer_secure_view_merging=FALSE;  
  676. 系统已更改。  
  677. SQL> shutdown  immediate   
  678. startup mount  
  679. SQL> ORACLE 例程已经启动。  
  680. Total System Global Area  285212672 bytes  
  681. Fixed Size                  2020224 bytes  
  682. Variable Size             100666496 bytes  
  683. Database Buffers          180355072 bytes  
  684. Redo Buffers                2170880 bytes  
  685. 数据库装载完毕。  
  686. SQL>   
  687. 数据库已更改。  
  688.   
  689.   
  690. SQL> alter database  recover managed standby database disconnect from session;  
  691.  在进行备份 就不会报错  
  692.   
  693. 3.7 dataguard  switchover切换  
  694.   
  695. 从原Primary数据库端的操作开始，到新Primary数据库端的操作结束，一定要注意操作步骤的先后， 检查初始化参数，Primary端和要切换的Standby端都需要进行。检查是否支持switchover操作。执行本步操作时登录到Primary数据库，然后在查询V$DATABASE视图的SWITCHOVER_STATUS列，例如：  
  696.   
  697.   
  698. 主库执行  
  699. SQL> select protection_mode,protection_level from v$database;  
  700.   
  701. PROTECTION_MODE       PROTECTION_LEVEL  
  702. --------------------              --------------------  
  703. MAXIMUM AVAILABILITY   MAXIMUM AVAILABILITY  
  704.   
  705. SQL> select switchover_status from v$database;  
  706. SWITCHOVER_STATUS  
  707. --------------------  
  708. SESSIONS ACTIVE  
  709. 如果该列值为TO STANDBY则表示Primary数据库支持转换为Standby角色，否则你就需要重新检查一下Data Guard配置，如看看LOG_ARCHIVE_DEST_n之类参数值是否正确有效等。  
  710. 还有一种情况是SWITCHOVER_STATUS列显示为SESSIONS ACTIVE，说明当前有人仍在连接Primary数据库（比如你以as SYSDBA方式通过网络服务名连接的话，就会可能导致该列状态为SESSIONS ACTIVE），出现这种情况不代表不能进行转换， 建议首先查询V$SESSION视图，查看当前的连接用户，并根据实际情况决定是否能够中止这些会话连接。  
  711.   
  712.   
  713. 此时，在备库上查看switchover_status参数   
  714. SQL> select switchover_status from v$database;  
  715.   
  716. SWITCHOVER_STATUS  
  717. --------------------  
  718. NOT ALLOWED  
  719.   
  720. A 如果switchover_status为TO_PRIMARY 说明标记恢复可以直接转换为primary库  
  721. SQL>alter database commit to switchover to primary  
  722. B 如果switchover_status为SESSION ACTIVE 就应该断开活动会话  
  723. SQL>alter database commit to switchover to primary with session shutdown;  
  724. C 如果switchover_status为NOT ALLOWED 说明切换标记还没收到，此时不能  
  725. 执行转换  
  726.   
  727. 启动switchover首先将Primary数据库转换为Standby角色，可用下列语句：  
  728.   
  729. SQL> alter database commit to switchover to PHYSICAL STANDBY WITH SESSION SHUTDOWN;  
  730.   
  731. WITH SESSION SHUTDOWN的子句，专门用来处理前步操作中仍有用户在连接的情况，如果附加了该子句，Primary数据库执行switchover，就会自动断开仍在连接该实例的无关会话。语句执行完毕后，Primary数据库将会转换为Standby数据库，也就是说这会儿整个Data Guard配置中群备无主了。另外在执行上述SQL语句时会自动备份当前的控制文件到trace文件。  
  732. 警告日志出现如下信息  
  733.   
  734. Successful close of redo thread 1  
  735. Sat Aug 27 14:44:38 2011  
  736. ARCH: Noswitch archival of thread 1, sequence 123  
  737. ARCH: End-Of-Redo Branch archival of thread 1 sequence 123  
  738. ARCH: Archiving is disabled due to current logfile archival  
  739. Clearing standby activation ID 353325209 (0x150f5099)  
  740. The primary database controlfile was created using the  
  741. 'MAXLOGFILES 16' clause.  
  742. There is space for up to 13 standby redo logfiles  
  743. Use the following SQL commands on the standby database to create  
  744. standby redo logfiles that match the primary database:  
  745. ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;  
  746. ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;  
  747. ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;  
  748. ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;  
  749. Archivelog for thread 1 sequence 123 required for standby recovery  
  750. MRP0 started with pid=13, OS id=14412  
  751. Sat Aug 27 14:44:39 2011  
  752.   
  753. Sat Aug 27 14:44:51 2011  
  754. Media Recovery Log /sywdg/arch1/1_123_758642906.dbf  
  755. Identified End-Of-Redo for thread 1 sequence 123  
  756. overy process shutdown (syw)  
  757. Sat Aug 27 14:44:52 2011  
  758. idle dispatcher 'D000' terminated, pid = (14, 2)  
  759. Sat Aug 27 14:44:53 2011  
  760. Switchover: Complete - Database shutdown required (syw)  
  761. Sat Aug 27 14:44:53 2011  
  762. Completed: alter database commit to switchover to PHYSICAL STANDBY WITH SESSION SHUTDOWN  
  763.   
  764. 重新启动到MOUNT状态（原Primary数据库操作）。首先SHUTDOWN原Primary数据库，然后启动到MOUNT状态：  
  765.   
  766. SQL> shutdown immediate  
  767. ORA-01507: 未装载数据库  
  768. ORACLE 例程已经关闭。  
  769. SQL> startup nomount  
  770. ORACLE 例程已经启动。  
  771. Total System Global Area  285212672 bytes  
  772. Fixed Size                  2020224 bytes  
  773. Variable Size             104860800 bytes  
  774. Database Buffers          176160768 bytes  
  775. Redo Buffers                2170880 bytes  
  776. SQL> alter database mount;  
  777. 数据库已更改。  
  778. SQL> select status from v$instance;  
  779. STATUS  
  780. ------------  
  781. MOUNTED  
  782.   
  783. 此时原Primary数据库就是以Standby身份在运行了。待原Primary切换为Standby角色之后，检查原Standby数据库SWITCHOVER_STATUS列  
  784.   
  785. SQL> select switchover_status from v$database;  
  786.   
  787.   
  788. SWITCHOVER_STATUS  
  789. --------------------  
  790. TO PRIMARY  
  791.   
  792.     此时原Standby数据库SWITCHOVER_STATUS列值应该是TO PRIMARY，除此之外，如果当前级有用户连接到Standby数据库，也有可能显示成SESSIONS ACTIVE，建议首先断开这些连接后再进行后续操作。另外还有可能显示为SWITCHOVER PENDING，这说明当前Standby数据库没有启动REDO应用，重新执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION命令即可。  
  793. 转换角色到Primary（原Standby数据库操作）。通过下列语句转换Standby数据库为Primary角色：原物理Standby可以处于MOUNT模式或OPEN READ ONLY模式，但不能处于OPEN READ WRITE模式。执行上述语句时同样支持WITH SESSION SHUTDOWN子句，以自动断开当前非必须的会话连接。  
  794.   
  795. SQL> alter database commit to switchover to primary;  
  796. SQL> alter database open;  
  797. SQL> select open_mode from v$database;  
  798.   
  799. OPEN_MODE  
  800. ----------  
  801. READ WRITE  
  802.   
  803. 3.8 灾难切换物理Standby的failover  
  804.   
  805.     failover之后，原Primary数据库默认不再是该Data Guard配置的一部分。  
  806. 在多数情况下，其他逻辑/物理Standby数据库不直接参与failover的过程，因此这些数据库并不需要做任何操作。在某些情况下，新的Primary数据库配置之后，需要重新创建同一Data Guard配置中其他所有的Standby数据库。在执行failover之前，尽可能将原Primary数据库的可用REDO文件（含联机重做日志文件和归档日志文件）都复制到Standby数据库。如果待转换角色的Standby处于MAXIMUM PROTECTION模式，需要你首先将其切换为Maximum Performance模式，转换Standby数据库到Maximize Performance模式执行下列SQL即可：  
  807.   
  808. SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;   
  809.   
  810.     等待Standby数据库转换为新的Primary之后，可以再随意更改数据库的保护模式。  
  811. Maximum Protection模式需要确保绝无数据丢失，因此其对于提交事务对应的REDO数据一致性要求非常高，另外，如果处于Maximum Protection模式的Primary数据库仍然与Standby数据库有数据传输，此时用ALTER DATABASE语句更改Standby数据库保护模式会失败，这也是由Maximum Protection模式特性决定的。  
  812. 一般情况下failover都是表示Primary数据库瘫痪，因此这种类型的切换基本上不需要Primary数据库做什么操作。所以下列步骤中如果有提到Primary数据库执行的，只是建议如果Primary还可以用，那就执行一下，即使它能用你不执行，也没关系，不影响Standby数据库的角色切换，只是会丢些数据。  
  813.     如果待转换角色的Standby处于Maximum Protection或Maximum Availability模式的话，归档日志应该是连续存在的，这种情况下你可以直接从第3步执行，否则建议你按照操作步骤从第1步开始执行。  
  814. 此时 待转换的Standby服务器，要通过下列操作，再将其转换成Primary数据库，   
  815. 1．<span style="white-space:pre">    检查归档文件是否连续  
  816.   
  817. 查询待转换Standby数据库的V$ARCHIVE_GAP视图，确认归档文件是否连接：  
  818. SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM     
  819. V$ARCHIVE_GAP;    
  820. no rows selected   
  821. <span style="white-space:pre">            
  822. 如果有返回的记录，按照列出的记录号复制对应的归档文件到待转换的Standby服务器。这一步非常重要，必须确保所有已生成的归档文件均已存在于Standby服务器，不然可能会因数据不一致造成转换时报错。  
  823.   
  824.   
  825. 文件复制过来后，在standby上通过下列命令将其加入数据字典：  
  826.   
  827. SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';   
  828. 2．检查归档文件是否完整  
  829. 分别在Primary和Standby数据库执行下列语句：  
  830. SQL> SELECT DISTINCT THREAD#,MAX(SEQUENCE#)     
  831. <span style="white-space:pre">  OVER(PARTITION BY THREAD#) A FROM V$ARCHIVED_LOG;   
  832.   
  833. 用该语句取得当前数据库各线程已归档文件最大序号，如果Primary与Standby最大序号不相同，必须将多出的序号对应的归档文件复制到待转换的Standby服务器。   
  834.   
  835. 3．启动failover  
  836. 在standby备库执行下列语句：  
  837.   
  838. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;    
  839. <span style="white-space:pre">  Database altered.   
  840. FORCE关键字将会停止当前活动的RFS进程，以便立刻执行failover。  
  841. 剩下的步骤就与前面switchover很相似了。  
  842.   
  843. 4．切换物理Standby角色为Primary  
  844. 执行下列语句：  
  845.   
  846.   
  847. SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;    
  848. <span style="white-space:pre">  Database altered.   
  849.   
  850. 5．启动新的Primary数据库  
  851. 如果当前数据库已MOUNT，直接OPEN即可，如果处于READ ONLY模式，需要首先SHUTDOWN IMMEDIATE，然后再执行STARTUP。这里直接用ALTER DATABASE OPEN命令打开数据库：  
  852.   
  853. SQL> ALTER DATABASE OPEN;    
  854. Database altered.   
  855.   
  856.   
  857. 角色转换工作完成。剩下的是补救措施（针对原Primary数据库），由于此时Primary数据库已经不再是Data Guard配置的一部分，我们需要做的就是尝试看看能否恢复原Primary数据库，将其改造为Standby服务器。具体操作方式可以分为二类：①重建；②备份恢复  

来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31414383/viewspace-2133123/ ，如需转载，请注明出处，否则将追究法律责任。

0
0
上一篇： oracle Data Guard MRP启动和关闭
下一篇： dmesg命令处理故障和查看系统信息详解
请登录后发表评论 登录
全部评论
gangade

注册时间：2016-11-24

  • 博文量
    25
  • 访问量
    23623

最新文章

支持我们 作者招募 用户协议 FAQ Contact Us

北京盛拓优讯信息技术有限公司. 版权所有  京ICP备16024965号-8 北京市公安局海淀分局网监中心备案编号：11010802021510 niuxiaotong@pcpop.com 17352615567 未成年人举报专区

广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员

违法和不良信息举报电话:18101376593