今日群内人才济济,探讨此问题。场景描述:rm -rf 某些oracle数据库文件,例:控制文件。导致数据库异常。此类问题,在去年12月份,一同事曾误删,致使他不得不重装了数据库。
1、文件描述符
使用文件描述符恢复数据库的前提,数据库不能关闭、数据库不剔除数据文件
2、文件删除后
仍然可以通过基本查询,看到数据。 由于文件描述符的存在,让数据文件没有被真正删除,还以某种方式存在于系统中,支持 dbwr 查询。
Check Point 是 Oracle 内部控制的一件大事。 经过 check point , Oracle 要保证所有数据文件、控制文件 SCN 信息保持一致,和日志文件在恢复时间点( RBA+SCN )达成一致。这个过程就强制回去访问到数据文件,结果文件丢失被发现。
注意:如果放任不管, Oracle 自动的 incremental checkpoint 也会有类似的效果。同时,周期性的 Global Check 也会发现“文件丢失了”
ps -ef | grep dbw
查看dbwr进程
根据进程id号查看文件id lsof -p id
查看文件状态
select online_status from dba_data_files where file_id=id实际进程id;
若已被剔除文件体系,则已经无法采用文件描述符恢复,且数据库日志会有以下内容:
ORA-01171: datafile 11 going offline due to error advancing checkpoint
若可以查询到id号,lsof -p id ,则可以去 目录 /proc/进程编号/fd 中找到所有的文件符
cp fd号码 /pathname/xxx.dbf 拷贝出此删除文件
alter database datafile 11 offline
恢复数据库文件
recover datafile 11;
alter database datafile 11 online;
使用 rman 中的 recovery advisor 工具,来判断错误是否存在。
rman nocatalog
列出错误:
list failure;
当出现以下结果时,证明恢复成功。
no failures found that match specification
1、文件描述符
使用文件描述符恢复数据库的前提,数据库不能关闭、数据库不剔除数据文件
2、文件删除后
仍然可以通过基本查询,看到数据。 由于文件描述符的存在,让数据文件没有被真正删除,还以某种方式存在于系统中,支持 dbwr 查询。
Check Point 是 Oracle 内部控制的一件大事。 经过 check point , Oracle 要保证所有数据文件、控制文件 SCN 信息保持一致,和日志文件在恢复时间点( RBA+SCN )达成一致。这个过程就强制回去访问到数据文件,结果文件丢失被发现。
注意:如果放任不管, Oracle 自动的 incremental checkpoint 也会有类似的效果。同时,周期性的 Global Check 也会发现“文件丢失了”
ps -ef | grep dbw
查看dbwr进程
根据进程id号查看文件id lsof -p id
查看文件状态
select online_status from dba_data_files where file_id=id实际进程id;
若已被剔除文件体系,则已经无法采用文件描述符恢复,且数据库日志会有以下内容:
ORA-01171: datafile 11 going offline due to error advancing checkpoint
若可以查询到id号,lsof -p id ,则可以去 目录 /proc/进程编号/fd 中找到所有的文件符
cp fd号码 /pathname/xxx.dbf 拷贝出此删除文件
alter database datafile 11 offline
恢复数据库文件
recover datafile 11;
alter database datafile 11 online;
使用 rman 中的 recovery advisor 工具,来判断错误是否存在。
rman nocatalog
列出错误:
list failure;
当出现以下结果时,证明恢复成功。
no failures found that match specification