当前位置：文档库 › Oracle 10g 物理Dataguard日常操作维护

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

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

分类：Oracle Dataguard2013-01-05 18:23 2033人阅读评论(0) 收藏举报[javascript]view plaincopy

1. 3.3进程日志的监控操作

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_HISTOR

Y 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_LO

https://www.wendangku.net/doc/d416331822.html, 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 standbyh ost '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 destinatio n 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_r edo05.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_r edo05.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

https://www.wendangku.net/doc/d416331822.html,er-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

https://www.wendangku.net/doc/d416331822.html,pleted: 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

https://www.wendangku.net/doc/d416331822.html,pleted: 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

https://www.wendangku.net/doc/d416331822.html,e 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

https://www.wendangku.net/doc/d416331822.html,pleted: 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

https://www.wendangku.net/doc/d416331822.html,er-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

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 sessio n;

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 SH UTDOWN;

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

https://www.wendangku.net/doc/d416331822.html,e 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

https://www.wendangku.net/doc/d416331822.html,pleted: alter database commit to switchover to PHYSICAL STANDBY WITH SESS ION 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

Oracle_dataguard__11G_配置与维护手册

1．判断DataGuard是否安装 select * from v$option where parameter = 'Oracle Data Guard'; 2.网络配置 192.168.1.10（orcl）------------------------------------192.168.1.20(dg) 3.监听配置主库 [oracle@node1 ~]$cd/u01/app/product/11.2.0/db_1/network/admin [oracle@node1 admin]$cat listener.ora LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = node1)(PORT = 1521)) ) ) [oracle@node1 admin]$cat tnsnames.ora ORCL= (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = node1)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = orcl) ) ) DG = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = node2)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = dg)

) ) 备库 [oracle@node1 admin]$cat listener.ora LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = node2)(PORT = 1521)) ) ) [oracle@node1 admin]$cat tnsnames.ora ORCL= (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = node1)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = orcl) ) ) DG = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = node2)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = dg) ) ) 4.主库前期准备设置强制写日志 SQL> select FORCE_LOGGING fromv$database; NO SQL>alter databaseforce logging; SQL>select FORCE_LOGGING from v$database; YES

数据库日常维护工作

数据库日常维护工作是系统管理员的重要职责。其内容主要包括以下几个部分：一、备份系统数据 SYBASE 系统的备份与恢复机制保证了在系统失败时重新获取数据的可能性。SQL Server 提供了两种不同类型的恢复机制：一类是系统自动完成的恢复，这种措施在每次系统启动时都自动进行，保证了在系统瘫痪前完成的事务都写到数据库设备上，而未完成的事务都被回退；另一类是人工完成的恢复，这是通过 DUMP 和 LOAD 命令来执行人工备份和恢复工作。因此定期备份事务日志和数据库是一项十分重要的日常维护工作。 1、备份数据库每一个数据库都应在创建之后卸出，从而提供一个装入基点。在此之后按排定的时间周期表卸出。比如每周五卸出数据库。对一般数据库系统卸出数据库周期建议为每周一次。除了按计划周期卸出数据库之外，还需在每次运行没有日志的操作后卸出数据库。例如：·每次强制地运行了 DUMP TRAN WITH NO_LOG （因为数据库的磁盘空溢出）； ·每次用 sp_dboption 允许 select into/bulkcopy 做快速拷贝，或用 SELECT INTO 命令创建一个永久性的表，或使用了 WRITETEXT 命令。卸出数据库的命令为： DUMP DATABASE database_name TO dump_device database_name 是要卸出的数据库名称，dump_device 是卸出设备的名称。用系统过程 sp_helpdevice 可以获得设备的信息。下面一条命令用来卸出数据库 my_db ： DUMP DATABASE my_db TO db_bk_dev 2、备份事务日志如果事务日志与数据库放在同一个设备上，则事务日志不应与数据库分开备份。master 数据库和小于 4M 的用户数据库就是这种情况。一般数据库系统的数据库和日志分别放在不同的设备上，因此，可以用 DUMP TRAN 命令单独备份日志。备份事务日志的周期直接影响数据的恢复程度，因此建议每天备份。备份事务日志的命令格式为： DUMP TRANsaction database_name [TO dump_device] [WITH TRUNCATE_ONL Y|WITH NO_LOG|WITH NO_TRUNCA TE] 其中 database_name 是要备份事务的数据库名称，dump_device 是备份设备名称，仅当包含了 WITH TRUNCA TE_ONL Y 或 WITH NO_LOG 子句时，才可以备份到设备。注意：如果总是用 DUMP DA TEBASE （备份数据库及其日志），而不用 DUMP TRAN ，事务日志将不会刷新，而变得非常庞大。

软件系统运维手册(完整资料).doc

【最新整理，下载后即可编辑】系统运维手册 1、目的 (3) 2、适用范围 (3) 3、服务器及数据库概述 (3) 3.1 服务器概述 (3) 3.2 数据库概述 (3) 4、系统服务程序的详细说明 (4) 4.1系统服务程序的构成 (4)

4.2 系统服务程序的启动、关闭及维护管理 (4) 4.2.1 dhcp主服务 (4) 4.2.2 dhcp从服务 (5) 4.2.3 web管理模块 (5) 5、服务器硬件维护（略） (6) 6、windows 2003系统的日常维护 (6) 6.1 定期检查磁盘空间 (6) 6.2 维护系统注册表 (7) 6.3 定期备份系统注册表 ..................................................................... 7 6.4清理system路径下的无用的dll文件 (7) 7、备份策略 (8) 7.1 备份方式 (8) 7.2 备份计划 (8) 7.3 常见故障恢复 (8) 9、数据库的日常维护 (11) 9.1 检查数据库的基本状况 (11) 9.2 检查数据库日志文件 (11) 9.4监控数据库表空间的使用情况（字典管理表空间） (11) 9.4.1 判断是否需要碎片整理 (11) 10、命令解释 (12) 1、目的楚天行消费卡管理系统运营支撑系统使用的服务器中，服

务器均采用windows xp操作系统,数据库版本为：sql server 2000，随着业务的开展，sql server 数据库中存储的数据量也不断增大，这样操作系统和数据库的日常维护就显得十分重要。本手册详细描述了程序模块，windows xp操作系统，负载平衡及sql server 数据库等日常检查的主要步骤，指导现场工程师对其进行监控和维护。 2、适用范围使用者为网e通宽带网络运营支撑系统维护工程师 3、服务器及数据库概述 3.1 服务器概述服务器数量：4台，基本信息如下： 3.2 数据库概述数据库软件分别安装在主服务器上。 4、系统服务程序的详细说明 4.1系统服务程序的构成 DHCP主程序：

OracleDataguard操作手册20160912

Oracaledataguard操作手册第一.dataguard的好处：它是在主节点与备用节点间通过日志同步来保证数据的同步，可以实现数据库的快速切换与灾难性恢复，提供了灾难保护并防止数据丢失。Data Guard只是在软件上对数据库进行设置，并不需要额外购买任何组件。用户能够在对主数据库影响很小的情况下，实现主备数据库的同步。而主备机之间的数据差异只限于在线日志部分，因此可以被用作数据容灾解决方案。第二.选用什么DG模式？ DG有三种模式，最大保护(Maximum protection)，最大性能(Maximum performance)，最大可用性(Maximum availability)，默认的就是最大性能模式。再实际的应用种使用最大性能模式比较多。三种保护模式：可以在V$DATABASE中查看到DataGuard的保护模式 SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;

第三.物理standby还是逻辑standby？ 1,物理stand by直接从primary接受archived log,然后直接做恢复，效率较高，因为是使用最底层的块级别上的复制。逻辑stand by是把primary接收过来的archived log解析为sql语句，然后做同步，效率较低，因为是执行SQL语句。 2,Physical standby的APPLY节点为MOUNT状态，Logical standby节点为OPEN状态，可分担primary上部分的查询和报表服务。 3,Physical standby可以实现与Primary来回switchover；logical standby切为Primary ，不能再切回来。 4，Physical standby可以切换为Logical standby ,但是logical 不能转换为Physical。综合以上采取：物理standby模式，效率高，数据完整性好。第四.如何创建物理standby？见附件一：ORACLE 11G 搭建DATAGUARD步骤大概步骤如下：首先：配置主库 1.1设置数据库强制归档 1.2添加STANDBY日志文件 1.3修改参数文件 1.4修改监听配置文件 1.5修改TNS配置文件 1.6重启监听服务 1.7启动数据库，配置DG模式:最大可用性模式或者最大性能模式 1.8备份数据库其次：配置备库。

Oracle数据库日常维护工作

文档编号
Oracle 数据库日常维护工作
凌群电脑有限公司凌群电脑有限公司 2004 年 12 月 15 日

数据库日常维护工作》《Oracle 数据库日常维护工作》
目
1.1 1.2 1.3 1.4 1.5 1.6
录
1. DBA 日常维护工作 ..................................................................................................................... 3 检查已经打开的所有实例 .................................................................................................... 3 检查最新的警告日志 ............................................................................................................ 7 检查数据库备份是否正确 .................................................................................................... 8 检查备份到磁带中的文件是否正确 .................................................................................... 9 检查数据库的性能是否合理，系统资源是否充足 ............................................................ 9 仔细阅读 ORACLE 标准文档 ............................................................................................... 10
2.晚间维护工作晚间维护工作.............................................................................................................................. 10 晚间维护工作 2.1 收集相关表的统计数据 ....................................................................................................... 10 3.每周维护工作每周维护工作.............................................................................................................................. 10 每周维护工作 3.1 检查异常的对象................................................................................................................... 10 3.1.1 检查现有的 NEXT_EXTENT 情况：............................................................................ 10 3.1.2 检查已有的 EXTENTS： .............................................................................................. 11 3.1.3 查看哪些表没有主键 .................................................................................................... 11 3.1.4 查找哪些主键是没有发挥作用的 ................................................................................ 12 3.1.5 所有作索引的主键都应是唯一的 ................................................................................ 12 3.2 检查是否有不安全的问题 ................................................................................................... 12 3.3 检查是否有错误 SQL*NET 日志 ....................................................................................... 13 3.4 归档当前告警日志 ............................................................................................................... 13 3.5 访问供应商站点................................................................................................................... 13 4.月维护工作月维护工作.................................................................................................................................. 13 月维护工作 4.1 检查是否有异常的空间增长 ............................................................................................... 13 4.2 回顾以前数据库性能优化的调整 ....................................................................................... 14 4.3 检查 IO 瓶颈 ........................................................................................................................ 14 4.4 检查碎片的问题（8I 系统） ............................................................................................... 15
2

DataGuard 日常维护

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 四日志传送状态监控

Oracle数据库日常维护手册

Oracle数据库日常维护手册在Oracle数据库运行期间，DBA应该对数据库的运行日志及表空间的使用情况进行监控，及早发现数据库中存在的问题。一、Oracle警告日志文件监控 Oracle在运行过程中，会在警告日志文件(alert_SID.log)中记录数据库的一些运行情况: ●数据库的启动、关闭，启动时的非缺省参数; ●数据库的重做日志切换情况，记录每次切换的时间，及如果因为检查点(checkpoint)操作没有执行完成造成不能切换，会记录不能切换的原因; ●对数据库进行的某些操作，如创建或删除表空间、增加数据文件; ●数据库发生的错误，如表空间不够、出现坏块、数据库内部错误(ORA-600) DBA应该定期检查日志文件，根据日志中发现的问题及时进行处理问题处理启动参数不对检查初始化参数文件因为检查点操作或归档操作没有完成造成重做日志不能切换如果经常发生这样的情况，可以考虑增加重做日志文件组;想办法提高检查点或归档操作的效率; 有人未经授权删除了表空间检查数据库的安全问题，是否密码太简单;如有必要，撤消某些用户的系统权限出现坏块检查是否是硬件问题(如磁盘本生有坏块)，如果不是，检查是那个数据库对象出现了坏块，对这个对象进行重建表空间不够增加数据文件到相应的表空间出现ORA-600根据日志文件的内容查看相应的TRC文件，如果是Oracle的bug，要及时打上相应的补丁二、数据库表空间使用情况监控(字典管理表空间)

数据库运行了一段时间后，由于不断的在表空间上创建和删除对象，会在表空间上产生大量的碎片，DBA应该及时了解表空间的碎片和可用空间情况，以决定是否要对碎片进行整理或为表空间增加数据文件。 select tablespace_name, count(*) chunks , max(bytes/1024/1024) max_chunk from dba_free_space group by tablespace_name; 个人收集整理上面的SQL列出了数据库中每个表空间的空闲块情况,如下所示: TABLESPACE_NAME CHUNKS MAX_CHUNK -------------------- ---------- ---------- INDX 1 57.9921875 RBS 3 490.992188 RMAN_TS 1 16.515625 SYSTEM 1 207.296875 TEMP 20 70.8046875 TOOLS 1 11.8359375 USERS 67 71.3671875个人收集整理其中，CHUNKS列表示表空间中有多少可用的空闲块(每个空闲块是由一些连续的Oracle 数据块组成)，如果这样的空闲块过多，比如平均到每个数据文件上超过了100个，那么该表空间的碎片状况就比较严重了，可以尝试用以下的SQL命令进行表空间相邻碎片的接合: alter tablespace 表空间名 coalesce; 然后再执行查看表空间碎片的SQL语句，看表空间的碎片有没有减少。如果没有效果，并且表空间的碎片已经严重影响到了数据库的运行，则考虑对该表空间进行重建。 MAX_CHUNK列的结果是表空间上最大的可用块大小，如果该表空间上的对象所需分配的空间(NEXT值)大于可用块的大小的话，就会提示ORA-1652、ORA-1653、ORA-1654的错误信息，DBA应该及时对表空间的空间进行扩充，以避免这些错误发生。对表空间的扩充对表空间的数据文件大小进行扩展，或向表空间增加数据文件，具体操作见“存储管理”部份。三、查看数据库的连接情况

Oracle 11g DataGuard 配置详细说明

Oracle 11g DataGuard 配置详细说明 1．判断DataGuard是否安装 select * from v$option where parameter = 'Oracle Data Guard'; 2. 数据库环境说明主库配置：IP：192.168.228.133(Oracle11g1)，数据库名：db1,监听服务名：db1pri,网络服务名：pri 从库配置：IP：192.168.229.134(Oracle11g2)，数据库名：db1,监听服务名：db1dg ,网络服务名：dg 数据库程序安装路径：/oracleapp/oinstall/oracle/product/11.2.0/dbhome_1/dbs 数据库存放路径：/oracledata/db1 3.监听配置在做oracle dataguard主从库配置时候，一定要配置静态监听，否则可能出现监听服务解析错误，不能连接的问题，监听配置如下：主库配置如下： [oracle@Oracle11g1 admin]$ pwd /oracleapp/oinstall/oracle/product/11.2.0/dbhome_1/network/admin [oracle@Oracle11g1 admin]$ cat listener.ora # listener.ora Network Configuration File: /oracleapp/oinstall/oracle/product/1.2.0/dbhome_1/network/admin/listener.ora # Generated by Oracle configuration tools. WU = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = Oracle11g2)(PORT = 1521)) ) ) SID_LIST_WU = (SID_LIST =

ORACLE数据库日常维护与管理手册

全球眼?（MEGAEYES）网络图像管理系统2.0 ORACLE日常维护与管理手册北京互信互通信息技术有限公司 2004-08-08

目录全球眼?（MEGAEYES）网络图像管理系统2.0 (1) 1引言 (3) 1.1 目的 (3) 1.2 范围 (3) 1.3 参考资料 (3) 2日常维护与管理说明 (3) 2.1 运行环境 (3) 2.1.1硬件环境 (3) 2.1.2软件环境 (3) 2.2 数据库日常维护 (4) 2.2.1数据库初始设置 (4) 2.2.2每日工作内容 (5) 2.2.3每周工作内容 (6) 2.2.4每月工作内容 (7)

1引言 1.1目的对于重要的商业系统来说，数据库系统的正常运行是保证商业应用平稳运行的关键。但是数据库在运行过程中可能会因为种种原因发生问题。这时，数据库的管理与日常维护工作将变得尤为重要。为了指导数据库管理员做好日常维护工作，保证数据库系统的正常运行，特制定本文档。当然，数据库的日常维护是复杂和繁琐的，本文仅涉及一些常见的数据库日常维护的内容，在实际工作中，数据库管理员还需要做更多的工作。 1.2范围本文档使用的人员：数据库维护管理人员和相关人员。本文档涉及内容：oracle数据库的日常维护与管理解决方案。 1.3参考资料中国电信网络视频监控技术（暂行）规范 2日常维护与管理说明 2.1运行环境程序的运行环境包括硬件运行环境和软件运行环境。 2.1.1硬件环境 ◆CPU类型：Intel及其兼容系列CPU ◆内存容量：剩余内存要达2G以上 ◆硬盘容量：剩余硬盘容量要达1G以上 ◆网卡类型：100M网卡 2.1.2软件环境 ◆操作系统：RedHat Linux AS 3.0 ◆数据库：Oracle9i Database Release 2 (9.2.0.4.0) for Linux x86

Oracle DataGuard容灾解决方案教学文案

Oracle DataGuard容灾解决方案

目录一. 需求分析 (3) 二. 解决方案 (3) 2.1 拓扑架构 (3) 2.2 方案特点 (4) 2.3 方案优势 (4) 2.4 产品介绍 (5) 三. Oracle维保服务 (8) 四. 方案报价 (10)

一. 需求分析用户现有两台服务器，windows2008平台，一台运行oracle 11g r2，一台运行用友NC 6.3。现在通过每天备份的方式保证安全。用户希望在他的另一个机房（裸光纤互联）中搭建容灾平台。因此本方案针对以上现状，提出Oracle DataGuard容灾解决方案，这样主数据库在遇到极端状况时，可以及时切换到备库，保证业务的连续性。二. 解决方案 2.1 拓扑架构 Dataguard可以实现远程数据容灾,利用该功能也可实现高可用性。数据容灾是指建立一个异地的数据系统，该系统是本地关键应用数据的一个实时复制。在本地数据及整个应用系统出现灾难时，系统至少在或本地异地保存有一份可用的关键业务的数据,基于该功能,结合客户实际情况我方推荐使用其作为保证系统可靠运行的一种解决方案,由于两台机器的数据一致性以及低延迟,完全可以胜任,在主机出现故障时,切换至备机运行。

2.2 方案特点 ?对现有的环境改动小，能最大限度的减少对现有应用系统的影响。 ?能满足客户对海量数据的管理要求。 ?可以实现远距离容灾，对网络要求低，低延时，快速业务切换。 ?同步或异步日志传输； ?低成本的投入。 2.3 方案优势灾难恢复和高可用性—Data Guard 提供了一个高效和全面的灾难恢复和高可用性解决方案。易于管理的转换和故障切换功能允许主数据库和备用数据库之间的角色转换，从而使主数据库因计划的和计划外的中断所导致的停机时间减到最少。完善的数据保护—使用备用数据库，Data Guard 可保证即使遇到不可预见的灾难也不会丢失数据。备用数据库提供了防止数据损坏和用户错误的安全保护。主数据库上的存储器级物理损坏不会传播到备用数据库上。同样，导致主数据库永久损坏的逻辑损坏或用户错误也能够得到解决。最后，在将重做数据应用到备用数据库时会对其进行验证。有效利用系统资源—备用数据库表使用从主数据库接收到的重做数据进行更新，并且可用于诸如备份操作、报表、合计和查询等其它任务，从而减少执行这些任务所必需的主数据库工作负载，节省宝贵的CPU 和I/O 周期。使用逻辑备用数据库，用户可以在模式中不从主数据库进行更新的表上执行数据处理操作。逻辑备用数据库可以在从主数据库中对表进行更新时保持打开，并可同时对表进行只读访问。最后，可以在维护的表上创建额外索引和物化视图，以获得更好的查询性能和适应特定的业务要求。灵活的数据保护功能，从而在可用性与性能要求之间取得平衡—Oracle Data Guard 提供了最大保护、最高可用性和最高性能等模式，来帮助企业在系统性能要求和数据保护之间取得平衡。自动间隔检测及其解决方案—如果主数据库与一个或更多个备用数据库之间的连接丢失（例如，由于网络问题），则在主数据库上生成的重做数据将无

软件维护手册

软件维护手册主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。 1 引言 1.1 编写目的阐明编写手册的目的并指明读者对象。 1.2 项目背景说明项目的提出者、开发者、用户和使用场所。 1.3 定义列出报告中所用到的专门术语的定义和缩写词的原意。 1.4 参考资料列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，及保密级别，可包括：用户操作手册；与本项目有关的其他文档。

2 系统说明 2.1 系统用途说明系统具备的功能，输入和输出。 2.2 安全保密说明系统安全保密方面的考虑。 2.3 总体说明说明系统的总体功能，对系统、子系统和作业做出综合性的介绍，并用图表的方式给出系统主要部分的内部关系。 2.4 程序说明说明系统中每一程序、分程序的细节和特性。 2.4.1 程序 1 的说明 ? 功能：说明程序的功能。 ? 方法：说明实现方法。 ? 输入：说明程序的输入、媒体、运行数据记录、运行开始时使用的输入数据的类型和存放单元、与程序初始化有关的入口要求。 ? 处理：处理特点和目的，如：用图表说明程序的运行的逻辑流程；程序主要转移条件；对程序的约束条件；程序结束时的出口要求；与下一个程序的通信与联结（运行、控制）；由该程序产生并茶馆处理程序段使用的输出数据类型和存放单元；程序运行存储量、类型及存储位置等。 ? 输出：程序的输出。 ? 接口：本程序与本系统其他部分的接口。 ?表格：说明程序内部的各种表、项的细节和特性。对每张表的说明至少包括：表的

标识符；使用目的；使用此表的其他程序；逻辑划分，如块或部，不包括表项；表的基本结构；设计安排，包括表的控制信息。表目结构细节、使用中的特有性质及各表项的标识、位置、用途、类型、编码表示。 ? 特有的运行性质：说明在用户操作手册中没有提到的运行性质。 2.4.2 程序 2 的说明与程序1 的说明相同。以后的其他各程序的说明相同。

DATAGUARD配置参数详细解释

DATAGUARD配置参数详细解释 DB_NAME 只需注意DataGuard的主备各节点instance使用相同的db_name即可。推荐与service_name一致。 DB_UNIQUE_NAME Primary与Standby端数据库的唯一名字，设定后不可再更改。注意: 如果主备db_unique_name不一样，需要与LOG_ARCHIVE_CONFIG配合使用 db_unique_name并未规定需要与数据库service_name一致，可以自定义任意名称。 LOG_ARCHIVE_CONFIG 列出主备库上的DB_UNIQUE_NAME 参数。默认情况下，定义该参数能确保主备库数据库能够互相识别对方Primary与Standby端的db_unique_name不一致时如在主备库db_unique_name不一致的情况下未配置LOG_ARCHIVE_CONFIG则会出现如下报错 ORA-16057: DGID from server not in Data Guard configuration 原因:主库没有设置参数log_archive_config 解决方法*.log_archive_config='dg_config=( Primary, Standby)' alter system set log_archive_config='dg_config=( Primary, Standby)' scope=both; Primary与Standby端的db_unique_name一致时

LOG_ARCHIVE_DEST_1 本地归档路径。Primary与Standby需要定义各自的online redo log的归档地址，以系统实际的存放路径为准。格式如下： Primary Site: *.LOG_ARCHIVE_DEST_1='LOCATION=/arch/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) ' Standby Site: *.LOG_ARCHIVE_DEST_1='LOCATION=/stdby/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) ' 注意：在LOG_ARCHIVE_DEST_n设置DB_UNIQUE_NAME表示该参数在DB_UNIQUE_NAME指定的数据库上生效，设置为本地的db_unique_name。以priamry端为例，格式如下： *.LOG_ARCHIVE_DEST_1='LOCATION=/archivelog/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=Primary' 这样配置的意义为：在数据库Primary上log_archive_dest_1对主备库上的联机日志都有效，这里的 db_unique_name可以省略 LOG_ARCHIVE_DEST_2 该参数仅当数据库角色为primary时生效，指定primary归档redo log到该参数定义的standby database上。 log_archive_dest_2可以说是dataguard上最重要的参数之一，它定义了redo log的传输方式(sync or async)以及传输目标(即standby apply node)，直接决定了dataguard的数据保护级别。格式如下： Primary Site: *.LOG_ARCHIVE_DEST_2='SERVICE=DR2 lgwr async VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) ' Standby Site: (switch over后生效) *.LOG_ARCHIVE_DEST_2='SERVICE=DR1 lgwr async VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) ' 注意： LOG_ARCHIVE_DEST_2参数里定义的service值，比如DR1，是tnsnames.ora文件里定义的Oracle Net名称。

日常运维管理制度

日常运维管理制度 1.运维保障机制 (1)建立硬件、网络、系统、应用及业务软件日常维护流程机制； (2)建立故障应急处理流程机制； (3)建立备份恢复保障机制； (4)建立安全保障管理机制； (5)建立版本管理机制，管理平台生产环境运行的软件版本；以上机制应形成文档，作为日常遵循规范，按要求执行。 2．硬件维护能力需对硬件设备具备7*24小时不间断的支持、响应能力，原则上每日对硬件设备至少健康检查一次并记录；定期对网络环境进行检查。我公司服务器部署在移动云上定期通过命令进行硬件检测，内存、硬盘、I/O的使用情进行查询并进行登记，每台服务器运行的软件对硬件性能使用情况检测，对于服务器我们进行系统备份、软件，每日对网络使用情况进行观察，针对突发异常流量进行分析。

3. 故障处理响应及要求设备（系统）出现故障时，根据不同的故障级别提供相应的服务响应，响应方式及要求如下： 4．具备应急预案针对部署国家平台节点服务器我们实施系统备份、软件重要数据实时备份，主机备份是提供的保留某个时间点上的主机系统数据状态

的服务。基于主机备份可以随时生成或删除备份，并基于已备份进行主机的恢复，实现已有应用和主机数据的快速复用，如系统出现事故无法使用将进行系统恢复并把最近一次备份的数据进行恢复。对于突发情况建立应急服务流程，主要是针对可能发生的各种意外情况设计应急的方案，以控制和规避突发事件带来的集中性风险，从而降低设备集中性风险所造成的损失，制定以下流程图：

为保证服务实施的质量能够稳定并不断有所提升，保障客户需求能够得到有效满足，保障服务实施团队为客户提供统一、标准化的服务支持，并为客户设立专门的技术服务专员，对进行全程跟踪，提升服务实施专业性，制定服务流程：

运维手册_数据库_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、目的 (3) 2、适用围 (3) 3、服务器及数据库概述 (3) 3.1 服务器概述 (3) 3.2 数据库概述 (3) 4、系统服务程序的详细说明 (3) 4.1系统服务程序的构成 (3) 4.2 系统服务程序的启动、关闭及维护管理 (4) 4.2.1 dhcp主服务 (4) 4.2.2 dhcp从服务 (5) 4.2.3 web管理模块 (5) 5、服务器硬件维护（略） (6) 6、windows 2003系统的日常维护 (6) 6.1 定期检查磁盘空间 (6) 6.2 维护系统注册表 (7) 6.3 定期备份系统注册表 (7) 6.4清理system路径下的无用的dll文件 (7) 7、备份策略 (8) 7.1 备份方式 (8) 7.2 备份计划 (8) 7.3 常见故障恢复 (8) 9、数据库的日常维护 (11) 9.1 检查数据库的基本状况 (11) 9.2 检查数据库日志文件 (11) 9.4监控数据库表空间的使用情况（字典管理表空间） (11) 9.4.1 判断是否需要碎片整理 (11) 10、命令解释 (12)

1、目的楚天行消费卡管理系统运营支撑系统使用的服务器中，服务器均采用windows xp操作系统,数据库版本为：sql server 2000，随着业务的开展， sql server 数据库中存储的数据量也不断增大，这样操作系统和数据库的日常维护就显得十分重要。本手册详细描述了程序模块，windows xp操作系统，负载平衡及sql server 数据库等日常检查的主要步骤，指导现场工程师对其进行监控和维护。 2、适用围使用者为网e通宽带网络运营支撑系统维护工程师 3、服务器及数据库概述 3.1 服务器概述 3.2 数据库概述数据库软件分别安装在主服务器上。 4、系统服务程序的详细说明 4.1系统服务程序的构成

ORACLE数据库日常维护与管理手册

全球眼（MEGAEYES网络图像管理系统2.0 ORACLE S常维护与管理手册北京互信互通信息技术有限公司 2004-08-08 目录

1 引言 1.1 目的对于重要的商业系统来说，数据库系统的正常运行是保证商业应用平稳运行的关键。但是数据库在运行过程中可能会因为种种原因发生问题。这时，数据库的管理与日常维护工作将变得尤为重要。为了指导数据库管理员做好日常维护工作，保证数据库系统的正常运行，特制定本文档。当然，数据库的日常维护是复杂和繁琐的，本文仅涉及一些常见的数据库日常维护的内容，在实际工作中，数据库管理员还需要做更多的工作。 1.2 范围本文档使用的人员:数据库维护管理人员和相关人员。本文档涉及内容: oracle 数据库的日常维护与管理解决方案。 1.3 参考资料中国电信网络视频监控技术（暂行）规范 2 日常维护与管理说明 2.1 运行环境程序的运行环境包括硬件运行环境和软件运行环境。 2.1.1 硬件环境 Intel 及其兼容系列 CPU 剩余内存要达2G 以上剩余硬盘容量要达 1G 以上 100 M 网卡 2.1.2 软件环境 CPU 类型: 内存容量：硬盘容量: 网卡类型:

: RedHatLinuxAS3.0 Oracle9iDatabaseRelease2forLinuxx86 2.2数据库日常维护数据库的日常维护工作主要包括管理员每日的工作内容，每周的工作内容以及每月的工作内容。 2.2.1数据库初始设置基于数据安全性的考虑，需要对数据库进行如下的初始设置。 1数据库设为归档模式 1）以管理员身份连接数据库 SQL>>connectsys/sys@数据库例程 SIDassysdba 2）察看数据库是否处于存档模式 SQL>>archiveloglist 说明：该命令会提示以下信息，注意灰色部分显示的状态。 DatabaselogmodeNoArchiveMode AutomaticarchivalDisabled Archivedest in ati on Oldest on li nelogseque nce31 Curren tlogseque nce33 3）如果处于非归档模式则设为归档模式 SQL>>shutdow nimmediate; SQL>>start upmount; SQL>>alterdatabaseachivelog; 4）如果处于非自动归档状态则设为自动归档 SQL>>altersystemsetlog_archive_start=TRUESC OP E=s pfile; 5重新启动数据库 SQL>>shutdow nimmediate; SQL>>startu p; 2控制文件设置每一个数据库都必须有一个控制档。它是一个小型二进制档案，用来描述 Oracle9i 实体结构。主要是储存数据库名称，数据库建立时间，资料文件名称与所在位置，重置日志文件名称与所在位置，目前的日志序列码（logsequeneenumber ），检查点信息。因此开启Oracle9i 数据库时一定要读取控制文件才能取得所有数据库实体档案相关信息。一旦控制文件不幸毁损，数据库便无法顺利开启。也因为如此，控制档的管理与维护工作显得格外重要。通常的设置建议为：每个数据库最好拥有两个以上控制档，并各自存放在不同磁盘上。系统默认有三个控制文件 controlOl.ctI ， control02.ctl ， con trol03.ctl 。如果需要增加更多的控制文件，最简单的方式就是先将既有控制文件复制到目的位置，然后将控制文件名称加入起始参数档的 CONTROLFILE 之中（）。同理，如果想更改控制档名称，也可以先将控制文件复制到目的位置后予以更名，再更新操作系统：数据库：