阅读量:10
接着上篇，由于无法搭建dg，业务方让把现在的主库数据克隆一份到之前准备的从库服务器。由于两个服务器目录结构都是一样的，又有足够停机时间，直接停了主库服务将物理文件传到从服务器对应位置，startup即可，真是比其他恢复方法简单很多。
对应之前有主从关系的DB，若想将其中一台或几台迁移至其他服务器，也可以使用冷备份恢复的方法，恢复之后仅需修改监听配置即可保留原先的主从关系，不需重新配置。另外也顺便搜集了一下各种情况下的冷备份与恢复，以防万一。
一、 冷备份
1. 查询物理文件位置
--参数文件（密码文件一般与参数文件位置相同，也要备份）
show parameter pfile;
--控制文件
select name from v$controlfile;
--数据文件
select name from v$datafile;
--重做日志文件
select member from v$logfile;
--临时文件
select name from v$tempfile;2. 关闭数据库
shutdown immediate3.复制所有文件到目标位置
若用于数据克隆或者迁移，目标服务器目录结构最好与源服务器一模一样，将各个文件复制回对应位置，后面会非常省事。
4. 启动数据库
startup二、 冷恢复
具体恢复方法视实际场景而定，主要有以下几种：
① 原库为非归档模式
② 原库为归档模式
A. 希望恢复到备份时间点
B. 希望恢复到最近时间点
C.希望恢复到指定时间点
① 目录结构与原服务器完全相同
② 目录结构与原服务器不完全相同（越不同越复杂，在原库恢复可能也有这个问题，这里一并讨论了）
下面分别来讨论以上情况：
1.在原库恢复（非归档模式）
其实这是最简单的恢复方式，但由于没有归档，只能恢复到备份时间点，若备份后有过修改，修改会全部丢失。
shutdown immediate
mv走前面备份过的文件（不要删，万一备份的文件有问题原来的文件又删了就哭了）
将备份文件cp回原先对应位置
startup正常应该能直接起来，如果起不来，看看alert文件是不是那么衰备份文件有问题了。。。
2.在原库恢复（归档模式）
A. 希望恢复到备份时间点
这个其实跟上面的恢复步骤是一样的，这里不再多说了。
B. 希望恢复到最近时间点
首先备份之后到崩溃时的归档和redo日志必须还在，否则只能执行不完全恢复。
若只是数据文件丢失或损坏，控制文件还在
shutdown immediate
mv走损坏的数据文件
将备份文件cp回原先对应位置
startup mount
--若控制文件未丢失，直接执行
recover database;
-- 应用完日志后open db
alter database open;若控制文件全部丢失，或控制文件与数据文件都丢失
shutdown immediate
mv走损坏的控制文件
将备份文件cp回原先对应位置
startup mount
--使用冷备的控制文件恢复时，执行以下命令告诉oracle不要以冷备的控制文件中的scn作为恢复终点
recover database using backup controlfile;
--会提示Specify log: {=suggested | filename | AUTO | CANCEL}，一般选AUTO；注意AUTO不会自动应用redo日志，需在归档日志应用完后输入redo日志路径，让其应用
-- 应用完日志后open db
alter database open resetlogs;C. 希望恢复到最近时间点
与完全恢复类似，只是在recover时指定要恢复到的时间和SCN。例如数据文件丢失或损坏
shutdown immediate
mv走损坏的控制文件
将备份文件cp回原先对应位置
startup mount
recover database until time '2019-11-04 12:33:08';
-- 应用完日志后open db
alter database open resetlogs;3. 异机恢复
① 目录结构与原服务器完全相同
将各文件拷贝到对应位置，startup起库即可。
② 目录结构与原服务器不完全相同
A. 若控制文件位置不同，修改参数文件中control_file参数后再用新参数文件启动
B. 若数据文件或redo日志位置不同，startup mount，使用alter database rename file '旧文件名' to '新文件名';重命名文件后再open数据库。
