SStandy 数据库的建立步骤
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#
) low
WHERE low.thread# = high.thread#;
THREAD# LowGap# HighGap#
---------------- ------------- ----------------
1 90
92
在primary database中:
SELECT name FROM v$archived_log
WHERE thread#=1 AND sequence#<=92 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_seconds]]
3.managed recovery 在816 for Sun上有bug(1794024)
一个被激活的standby的standby，不能进行managed recovery(不能等待，一发现文件不存在就退出，而且不是看控制文件，TMD，折腾了我一天)，不过远程archive正常，也更新了控制文件。
4.如果要重启standby，会在primary的alert.log中出现:
Tue Jun 19 17:00:56 2001
ARC0: Beginning to archive log# 3 seq# 39 ARC0: RFS network connection lost at host 'csstandby'
ARC0: Error 3113 creating standby archivelog file at host 'csstandby'
ARC0: 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.有了这么“可爱”的managed standby，只能自己写脚本完成recovery了。(自动恢复、删除)
六、standby database在read only下执行磁盘排序
创建一个由tempfile组成的LOCALLY MANAGED 表空间
在primary database:
CREATE TEMPORARY TABLESPACE tbspaceName TEMPFILE’filename’ SIZE
integer [M/K]EXTENT 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.dbf Block Checking: DBA = 25358227, Block Type = Found block already marked corrupted
Block Checking: DBA = 25358228, Block Type = Found block already marked corrupted
.....
Block Checking: DBA = 25358360, Block Type = Found block already marked corrupted
DBVERIFY - Verification complete
Total Pages Examined : 256000
Total Pages Processed (Data) : 210020 Total Pages Failing (Data) : 0
Total Pages Processed (Index): 23689
Total Pages Failing (Index): 0
Total Pages Processed (Other): 543
Total Pages Empty : 21748
Total 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_extents
where 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 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#
) low
WHERE low.thread# = high.thread#;
THREAD# LowGap# HighGap#
---------------- ------------- ----------------
1 90
92
在primary database中:
SELECT name FROM v$archived_log
WHERE thread#=1 AND sequence#<=92 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_seconds]]
3.managed recovery 在816 for Sun上有bug(1794024)
一个被激活的standby的standby，不能进行managed recovery(不能
等待，一发现文件不存在就退出，而且不是看控制文件，TMD，折腾了我一天)，
不过远程archive正常，也更新了控制文件。
4.如果要重启standby，会在primary的alert.log中出现:
Tue Jun 19 17:00:56 2001
ARC0: Beginning to archive log# 3 seq# 39 ARC0: RFS network connection lost at host 'csstandby' ARC0: Error 3113 creating standby archivelog file at host 'csstandby'
ARC0: 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.有了这么“可爱”的managed standby，只能自己写脚本完成recovery了。(自动恢复、删除)
六、standby database在read only下执行磁盘排序
创建一个由tempfile组成的LOCALLY MANAGED 表空间
在primary database:
CREATE TEMPORARY TABLESPACE tbspaceName
TEMPFILE’filename’ SIZE
integer [M/K]EXTENT 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.dbf
Block Checking: DBA = 25358227, Block Type = Found block already marked corrupted Block Checking: DBA = 25358228, Block Type = Found block already marked corrupted .....
Block Checking: DBA = 25358360, Block Type = Found block already marked corrupted
DBVERIFY - Verification complete
Total Pages Examined : 256000
Total Pages Processed (Data) : 210020 Total Pages Failing (Data) : 0
Total Pages Processed (Index): 23689 Total Pages Failing (Index): 0
Total Pages Processed (Other): 543 Total Pages Empty : 21748
Total 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_extents
where block#_you_get between block_id and block_id+blocks - 1
and file_id= file#_you_get
segmentcorrupt 有点奇怪的是:有时候查出来的并没有，有待验证。
3.在primary中改变文件大小
不用在standby中做任何改动，但该文件在v$datafile中的status会变为
"recover"。
浙公网安备 33021202002483