Standy 数据库的建立步骤.doc

Standy 数据库的建立步骤一、创建： 1.在primary database(archive mode): 对数据文件做冷备份或热备份; 生成standby database 的控制文件: alter database create standby controlfile as .; 对当前的redo log 做archive:alter system archive log current; 将这些文件传到standby database所在主机上; 2.在standby database: mount standby database: startup nomount; alter database mount standby database; 将standby database 置于recover状态: recover from location standby database;然后Oracle会提示你需要哪个log 文件，如果提示名字无误的话，可以输入回车或auto来执行恢复，如果输入auto，当Oracle找不到所需的log时，会结束恢复。 8i 提供了一种managed recovery方法: recover managed standby database timeout 60; 这时，Oracle的恢复进程会等在那儿，只能用CTRL+C中断，或用另外的session来中断。而不是做为一个后台进程运行（和我想的不一样），如果不用timeout，则它会每15秒检查一下是否有新的archived log（是在控制文件中检查），如果用了timeout那超时后，恢复就结束了。二、维护 1.更新standby database的控制文件： 当在primary database使用了CREATE CONTROLFILE命令后(修改log group，instance，数据文件数目)，要通过以下骤更新standby database 的控制文件: 在primary database中： alter database create standby controlfile as .; alter system archive log current; 中止standby database的恢复操作: cancel recovery; shutdown immediate;将生成的控制文件和archive log传到standby database主机的适当目录下，重新开始恢复操作: startup nomount; alter database mount standby database; recover standby database;2.standby database恢复的取消： recover cancel; 如果是managed 方式恢复: recover managed standby database cancel; 如果是在另一个session中取消恢复操作：alter database recover managed standby database cancel;3.在primary database中增加了数据文件 1.当在standby database应用包含对新增的数据文件的操作时，Oracle会提示ORA-283、1670、1157、1110 错，并停止恢复操作，执行：alter database create datafile . as . ; 继续恢复； 注意：新加入的文件在v$datafile中的status为recover，这是正常的，在激活后会变为online。4.在primary中执行了nologgin或unrecoverable操作检查primary database中unrecoverable 操作的时间是否是在备份之后(或比较primary和standby的unrecoverable_change#，primary的不应大于standby的)，如果是，则需要重做相应的数据文件的备份并创建standby 控制文件： SELECT name, unrecoverable_change#, to_char(unrecoverable_time, mm-dd-yyyy hh:mi:ss) FROM v$datafile; 建议：如果使用standby , 就不要用unrecoverable操作，在建立standby之前，要检查表空间的logging属性，另，Oracle 8.1.6有个bug，alter index rebuild 缺省就是nologging。如果是index是nologging的话，重建index可以避免将来激活standby database后的ORA-1578、1110、26040错。 (However, when the redo log file is transferred to the standby site and applied to the standby database, a portion of the datafile is unusable and marked as being unrecoverable.) 如果用imp/exp的话，若exp时index的属性是nologging，那么只能解决进行imp的database的ORA-1578、1110、26040错，该数据库的standby在应用了所有archive log后，仍有该问题。三、切换 1.正常激活standby database： 如果没有mount standby database，则mount上: alter database mount standby database exclusice; 激活standby database: alter database activate standby database; 关闭 standb database: shutdown database immediate; 有条件的话，做个备份； 启动数据库； 这样，Oracle会修改standby 的控制文件，重置log序列，所以没有办法用原来primary的数据文件和现在的primary的控制文件来创建新的standby database了。 2.primary 和standby 的切换: 关闭primary database（随便什么方式）； 在standby database: 应用完所有的archive log； CANCEL恢复操作； 关闭数据库； 将primary database的控制文件和online redo log拷贝至standby database的相应目录；/*/Previous revisions of the graceful switchover and switchback paper stressed that the production controlfile and the online redo logs need to be copied to the standby database; however we have found problems with controlfile transaction count mismatches between data file headers and controlfiles (bug 1034927). Oracle now recommends creating a create controlfile with noresetlogs option script from the production database and copying the script to the standby database before switchover occurs. The alter database backup controlfile to trace noresetlogs command must be executed on the production database instead of the standby database (bug 1034871).详见：Graceful Switchover and Switchback Oracle standby database/*/ 如果primary和standby的文件名不一样，则： startup mount; (用primary的控制文件) alter database rename file primary_name.f to standby_name.f; 恢复数据库: recover database; 打开数据库: alter database open; 这时原来的standby database就成了primary database，接下来要让原来的primary database成为standby database(不是用全部重建standby的方法，因为这时数据库的log序列没有被重置) 在新的primary database上创建standby database的控制文件并archive 当前的log(同正常的standby database 创建): alter database create standby controlfile as .; alter system archive log current; 在原来的primary database: 将新的primary database生成的控制文件和archive log拷贝到相应的目录（在成功打开新的primary database之后，可以删除原primary database的控制文件和online log）；在用新primary database生成的控制文件和archive log之前，不能开启数据库，否则，要重建standby(要对新的primary database做数据库的全备份） 如果数据文件和log文件的名字不同，则在initSID.ora中加入： db_file_name_convert = (primary_dir_name,standby_dir_name); log_file_name_convert = (primary_dir_name,standby_dir_name); mount 数据库并开始恢复： startup nomount; alter database mount standby database; recover standby database; 现在已经完成了primary和standby的切换。基于同样的道理，如果有一个primary和二个（多个也行）standby，在激活了一个standby之后，在新的primary database 上创建standby 控制文件和archive log，传到另一个standby databse上，然后mount并recover，这样这个standby就成了新的primary的standby，而不需通过做全备份的方式重建。四、standby 恢复的性能调整RECOVERY_PARALLELISM可以增加，在8i中缺省是0，即是串行恢复，可以设为CPU或磁盘的数目；DB_BLOCK_BUFFERS 增加也会提高恢复的速度五、远程archive和自动恢复 在primary database上配置: 1.initSID.ora中 log_archive_dest_1 = location=/app/arch mandatory log_archive_dest_2 = mandatory service=8istby reopen=30 log_archive_dest_state_1=enable log_archive_dest_state_2=enable 其中，reopen指明发生错误时，多少秒后重试； 2.primary database 的tnsnames.ora 8istby.world = /* 8istby.world is my Net8 alias */ (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=poseidon)(PORT=6001) /*standby db host */ (ADDRESS=(PROTOCOL=tcp)(HOST=poseidon)(PORT=6002) /*failover lsnr */ (CONNECT_DATA = (SID = crash) (GLOBAL_NAME = crash.world) /* crash.world = standby database SID */ 在standby database上: 1.配置相应的listener(略) 2.根据需要配置以下参数: STANDBY_ARCHIVE_DEST /app/arch/oracle_archive LOG_ARCHIVE_DEST_1 /app/arch/oracle_archive LOG_ARCHIVE_FORMAT stdby_%t_%s DB_FILE_NAME_CONVERT (/vobs/oracle/dbs,/fs2/oracle/stdby) 3.mount数据库并开始恢复： startup nomount; alter database mount standby database; recover managed standby database; 这样Oracle会自动进程恢复，恢复进程会每15秒在standby的控制文件中检查新的archive log。 在primary database开始传archive log之前，standby database 的listener要启动，并且数据库要处于mount状态。 每个primary ARCH进程会在standby database上创建一个RFS进程。如果RFS进程翘了或连接中断，会在重新连接时重建一个RFS进程。primary database上的ARCH和RFS通过Net8进程通讯。 RFS会在standby database的standby_archive_dest目录下生成archive log； 如果archive成功，会在standby database的控制文件中更新archive信息。注意事项： 1.在remote archive创建之前生成的archive log要手工传，以下方法用来找到需手工reover的log file： 在standby database中:SELECT thread#, MIN(sequence#)-1 HighGap# FROM ( SELECT a.thread#, a.sequence# FROM ( SELECT * FROM v$archived_log ) a, ( SELECT thread#, MAX(next_change#) gap1 FROM v$log_history GROUP BY thread# ) b WHERE a.thread# = b.thread# AND a.next_change# gap1 ) GROUP BY thread#) high,( SELECT thread#, MIN(sequence#) LowGap# FROM ( SELECT thread#, sequence# FROM v$log_history, v$datafile WHERE checkpoint_change# = next_change# AND checkpoint_change# = first_change# ) GROUP BY thread#) lowWHERE low.thread# = high.thread#; THREAD# LowGap# HighGap# - - - 1 90 92在primary database中:SELECT name FROM v$archived_log WHERE thread#=1 AND sequence#=90;/vobs/oracle/dbs/r_1_90.arc /vobs/oracle/dbs/r_1_91.arc /vobs/oracle/dbs/r_1_92.arc 将上述log手工应用到standby database。 2.如果发生错误，或remote archive太慢，可以禁止remote archive: alter system set log_archive_state_n= defer 也可以: alter system set log_archive_dest_n =null_string | LOCATION=pathname | SERVICE=servicename MANDATORY | OPTIONAL REOPEN=retry_time_in_seconds3.managed recovery 在816 for Sun上有bug(1794024)一个被激活的standby的standby，不能进行managed recovery（不能等待，一发现文件不存在就退出，而且不是看控制文件，TMD，折腾了我一天），不过远程archive正常，也更新了控制文件。 4.如果要重启standby，会在primary的alert.log中出现：Tue Jun 19 17:00:56 2001ARC0: Beginning to archive log# 3 seq# 39ARC0: RFS network connection lost at host csstandbyARC0: Error 3113 creating standby archivelog file at host csstandbyARC0: Error 3113 creating archivelog file csstandby可以用：alter system set log_archive_dest_state_2=enable;来解决，这样会重新初始化远程传送的进程，但中间失败的日志要手工重传。 但最好的办法是在重启standby之前，在primary上： alter system archive log stop; 重启standby及listener(不重启listener也成) 在primary上： alter system archive log start; (这个千万不能忘)5.有了这么“可爱”的managedstandby，只能自己写脚本完成recovery了。（自动恢复、删除)六、standby database在read only下执行磁盘排序 创建一个由tempfile组成的LOCALLY MANAGED 表空间 在primary database: CREATE TEMPORARY TABLESPACE tbspaceName TEMPFILEfilename SIZE integer M/KEXTENT MANAGEMENT LOCAL UNIFORM SIZE integer M/K; ALTER USER username TEMPORARY TABLESPACE tbspaceName; alter system archive log current; 在standby database: recover standby database; /*使在primary database的修改在standby中生效*/ alter database open read only; alter tablespace tbspaceName add tempfile filename size m/k;七、其它 1.standby database的数据文件用来恢复primary database 从8.0.4开始，当standby 的控制文件的transaction counter增加后，不会更新datafile的头部，这就保证了standby database 头部中的控制文件的transaction count总是小于primary database的transaction count。所以，用standby的数据文件来恢复primary不会因为这个原因而失败。2.用dbv查出了corrupt block的处理 dbv file=stand_1.dbf logfile=/tmp/stand_1.log block_size=8192以下是在一standby database中的检查结果log文件:DBVERIFY: Release 8.1.6.3.0 - Production on Thu Jun 14 16:04:45 2001(c) Copyright 1999 Oracle Corporation. All rights reserved.DBVERIFY - Verification starting : FILE = pin00.dbfBlock Checking: DBA = 25358227, Block Type =Found block already marked corruptedBlock Checking: DBA = 25358228, Block Type =Found block already marked corrupted.Block Checking: DBA = 25358360, Block Type =Found block already marked corruptedDBVERIFY - Verification completeTotal Pages Examined : 256000Total Pages Processed (Data) : 210020Total Pages Failing (Data) : 0Total Pages Processed (Index): 23689Total Pages Failing (Index): 0Total Pages Processed (Other): 543Total Pages Empty : 21748Total Pages Marked Corrupt : 0(奇怪为什么是0)Total Pages Influx : 0可以使用dbms_utility来根据DBA获得file#和block#:select dbms_utility.DATA_BLOCK_ADDRESS_FILE(25358227), /* file# */ dbms_utility.DATA_BLOCK_ADDRESS_BLOCK(25358227) /* block# */from dual然后，可以查出该blcok属于哪个对象(在primary database中查):select owner,segment_name,segment_type,tablespace_name from dba_extentswhere block#_you_get between block_id and block_id+blocks - 1 and file_id= file#_you_get有点奇怪的是：有时候查出来的segment并没有corrupt，有待验证。3.在primary中改变文件大小不用在standby中做任何改动，但该文件在v$datafile中的status会变为recover。一、创建： 1.在primary database(archive mode): 对数据文件做冷备份或热备份; 生成standby database 的控制文件: alter database create standby controlfile as .; 对当前的redo log 做archive:alter system archive log current; 将这些文件传到standby database所在主机上; 2.在standby database: mount standby database: startup nomount; alter database mount standby database; 将standby database 置于recover状态: recover from location standby database;然后Oracle会提示你需要哪个log 文件，如果提示名字无误的话，可以输入回车或auto来执行恢复，如果输入auto，当Oracle找不到所需的log时，会结束恢复。 8i 提供了一种managed recovery方法: recover managed standby database timeout 60; 这时，Oracle的恢复进程会等在那儿，只能用CTRL+C中断，或用另外的session来中断。而不是做为一个后台进程运行（和我想的不一样），如果不用timeout，则它会每15秒检查一下是否有新的archived log（是在控制文件中检查），如果用了timeout那超时后，恢复就结束了。二、维护 1.更新standby database的控制文件： 当在primary database使用了CREATE CONTROLFILE命令后(修改log group，instance，数据文件数目)，要通过以下骤更新standby database 的控制文件: 在primary database中： alter database create standby controlfile as .; alter system archive log current; 中止standby database的恢复操作: cancel recovery; shutdown immediate;将生成的控制文件和archive log传到standby database主机的适当目录下，重新开始恢复操作: startup nomount; alter database mount standby database; recover standby database;2.standby database恢复的取消： recover cancel; 如果是managed 方式恢复: recover managed standby database cancel; 如果是在另一个session中取消恢复操作：alter database recover managed standby database cancel;3.在primary database中增加了数据文件 1.当在standby database应用包含对新增的数据文件的操作时，Oracle会提示ORA-283、1670、1157、1110 错，并停止恢复操作，执行：alter database create datafile . as . ; 继续恢复； 注意：新加入的文件在v$datafile中的status为recover，这是正常的，在激活后会变为online。4.在primary中执行了nologgin或unrecoverable操作检查primary database中unrecoverable 操作的时间是否是在备份之后(或比较primary和standby的unrecoverable_change#，primary的不应大于standby的)，如果是，则需要重做相应的数据文件的备份并创建standby 控制文件： SELECT name, unrecoverable_change#, to_char(unrecoverable_time, mm-dd-yyyy hh:mi:ss) FROM v$datafile; 建议：如果使用standby , 就不要用unrecoverable操作，在建立standby之前，要检查表空间的logging属性，另，Oracle 8.1.6有个bug，alter index rebuild 缺省就是nologging。如果是index是nologging的话，重建index可以避免将来激活standby database后的ORA-1578、1110、26040错。 (However, when the redo log file is transferred to the standby site and applied to the standby database, a portion of the datafile is unusable and marked as being unrecoverable.) 如果用imp/exp的话，若exp时index的属性是nologging，那么只能解决进行imp的database的ORA-1578、1110、26040错，该数据库的standby在应用了所有archive log后，仍有该问题。三、切换 1.正常激活standby database： 如果没有mount standby database，则mount上: alter database mount standby database exclusice; 激活standby database: alter database activate standby database; 关闭 standb database: shutdown database immediate; 有条件的话，做个备份； 启动数据库； 这样，Oracle会修改standby 的控制文件，重置log序列，所以没有办法用原来primary的数据文件和现在的primary的控制文件来创建新的standby database了。 2.primary 和standby 的切换: 关闭primary database（随便什么方式）； 在standby database: 应用完所有的archive log； CANCEL恢复操作； 关闭数据库； 将primary database的控制文件和online redo log拷贝至standby database的相应目录；/*/Previous revisions of the graceful switchover and switchback paper stressed that the production controlfile and the online redo logs need to be copied to the standby database; however we have found problems with controlfile transaction count mismatches between data file headers and controlfiles (bug 1034927). Oracle now recommends creating a create controlfile with noresetlogs option script from the production database and copying the script to the standby database before switchover occurs. The alter database backup controlfile to trace noresetlogs command must be executed on the production database instead of the standby database (bug 1034871).详见：Graceful Switchover and Switchback Oracle standby database/*/ 如果primary和standby的文件名不一样，则： startup mount; (用primary的控制文件) alter database rename file primary_name.f to standby_name.f; 恢复数据库: recover database; 打开数据库: alter database open; 这时原来的standby database就成了primary database，接下来要让原来的primary database成为standby database(不是用全部重建standby的方法，因为这时数据库的log序列没有被重置) 在新的primary database上创建standby database的控制文件并archive 当前的log(同正常的standby database 创建): alter database create standby controlfile as .; alter system archive log current; 在原来的primary database: 将新的primary database生成的控制文件和archive log拷贝到相应的目录（在成功打开新的primary database之后，可以删除原primary database的控制文件和online log）；在用新primary database生成的控制文件和archive log之前，不能开启数据库，否则，要重建standby(要对新的primary database做数据库的全备份） 如果数据文件和log文件的名字不同，则在initSID.ora中加入： db_file_name_convert = (primary_dir_name,standby_dir_name); log_file_name_convert = (primary_dir_name,standby_dir_name); mount 数据库并开始恢复： startup nomount; alter database mount standby database; recover standby database; 现在已经完成了primary和standby的切换。基于同样的道理，如果有一个primary和二个（多个也行）standby，在激活了一个standby之后，在新的primary database 上创建standby 控制文件和archive log，传到另一个standby databse上，然后mount并recover，这样这个standby就成了新的primary的standby，而不需通过做全备份的方式重建。四、standby 恢复的性能调整RECOVERY_PARALLELISM可以增加，在8i中缺省是0，即是串行恢复，可以设为CPU或磁盘的数目；DB_BLOCK_BUFFERS 增加也会提高恢复的速度五、远程archive和自动恢复 在primary database上配置: 1.initSID.ora中 log_archive_dest_1 = location=/app/arch mandatory log_archive_dest_2 = mandatory service=8istby reopen=30 log_archive_dest_state_1=enable log_archive_dest_state_2=enable 其中，reopen指明发生错误时，多少秒后重试； 2.primary database 的tnsnames.ora 8istby.world = /* 8istby.world is my N