数据库备份恢复

二、数据库备份恢复
1.数据库恢复过程
即便是与数据库 有关 的 所有 文件 全部 损坏 或 丢失，
在 备份 存在 的 前提下（ 某些文件甚至可以没有备份），
可按 如下 步骤 恢复：
（1）用操作系统命令或通过重新安装 Oracle数据库软件将$ORACLE_HOME还原。
（2恢复 密码 文件。
（3恢复 参数 文件。
（4恢复 控制 文件。
（5恢复 在 线 日志。
（6恢复 关键 数据 文件。
（7恢复 普通 数据 文件。
此外，为了 简化 还原 和 恢复 操作，Oracle 强烈推荐使用恢复编录。
绝大多数 功能可以通过 Oracle 提供的图形界面工具（ DBConsole 或 Grid Control）调用。

2.数据恢复顾问
数据恢复顾问可以自动诊断，自动恢复数据库。
Rman>list failure;
Rman>advise failure;
Rman>repair failure;

3.闪回技术
(1)闪回查询，查询指定时间的数据
select * from xg.misywt01
as of timestamp to_timestamp(‘20210108 09:40:00’,‘yyyymmdd hh24:mi:ss’)
(2)闪回事务查询
首先数据库打开最小补充日志
Sql>alter database add supplemental log data;

首先查询该事务的xid
Select versions_xid, versions_startscn,djh,sl,je
From a1.t2
Versions between timestamp minvalue and maxvalue
Where djh=1
Order by 2 nulls first;

VERSIONS_XID VERSIONS_STARTSCN DJH SL JE
0200160007040000 2591366 1 10 100
使用事务号，查询撤销undosql

select undo_sql
from flashback_transaction_query
where xid=’0200160007040000’

(3)闪回删除
Sql>flashback table t1 to before drop;
4.日志挖掘
日志挖掘准备
begin
dbms_logmnr.start_logmnr(
starttime=>to_date(‘2021-05-31 01:01:00’,‘yyyy-mm-dd hh24:mi:ss’),
endtime=>to_date(‘2021-06-01 12:01:00’,‘yyyy-mm-dd hh24:mi:ss’),
options=>
dbms_logmnr.dict_from_redo_logs+
dbms_logmnr.continuous_mine);
end;
/

查询挖掘内容
select xid,sql_redo,sql_undo from v$logmnr_contents where seg_name=’T1’;
5.讨论：“拿什么保护你，我的数据库”各种容灾方案讨论
容灾方案是我们DBA必须考虑的问题，也是一个企业数据库的重中之重。现在五花八门的容灾产品很多，这次请大家讨论一下容灾的话题，以供我们在制定容灾计划时参考：

我先来，介绍一下阿里的容灾方案。
阿里所有核心库，都要求有两套DG。一套是实时的，或准实时的，基本上是实时恢复。9i的库，就产生一个归档，向备库传一个，马上恢复。
另一套DG是延时恢复，一般要求延时6个小时之上。
实时DG用来应对主库存储故障。
延时DG应对逻辑故障。

vage大师归来 顶一个
我们这边生产用的CA，都是存储级别的容灾，以前公司用过DG
存储级别的贵，效率高点。不过据说存储级别的复制，发生块断裂的机会比较大。DG免费，配置也简单点。由于具体实施不是我搞的，也没遇到啥大问题。

一般应该是RMAN+DG+DUMP吧

我觉得这样 应该是 保护数据库 最好的以及最基本的方式，请各位大神点评，谢谢！！！

我接触过的方案比较简单点，不过还比较实用：
一般UPS保证电源可用
RAC保证主机硬件和OS高可用
DG保证数据高可用
RAID+磁盘镜像保证磁盘数据安全
备库的RMAN+磁带保证数据安全
远端备份处理异地容灾

6.错误删除数据库的数据文件
2006-01-12 意外删除数据文件的恢复 恢复数据库cpwl

2006-01-12上午11：00，在物流正常工作的情况下，我删除了数据库cpwl中用户cpwl2004，并且删除了底层的数据文件cpwl2004_dataXX.dbf
结果导致物流数据库cpwl宕库，无法启动数据库。

环境：oracle817 sco unix713
错误：数据库宕库，且无法启动，情动的时候出现如下错误
ORA-01157: cannot identify/lock data file 13 - see DBWR trace file
ORA-01110: data file 13: ‘/home/oracle/oradata/cpwl/cpwl2004_data01.dbf’

原因：删除数据库cpwl中用户cpwl2004后，没有删除表空间cpwl2004_data就直接删除了底层的数据文件cpwl2004_data01.dbf，
cpwl2004_data02.dbf，cpwl2004_data03.dbf，导致物流数据库cpwl宕机，无法启动。
更严重的问题是在当前工作的数据库上执行操作！！！

解决方法：在mount状态下，删除数据文件
startup mount
alter database datafile ‘/home/oracle/oradata/cpwl/cpwl2004_data01.dbf’ offline drop;
alter database datafile ‘/home/oracle/oradata/cpwl/cpwl2004_data02.dbf’ offline drop;
alter database datafile ‘/home/oracle/oradata/cpwl/cpwl2004_data03.dbf’ offline drop;
alter database open

如果是oracle10g，语句中多加了一个for。
alter database datafile ‘/home/oracle/oradata/cpwl/cpwl2004_data01.dbf’ offline for drop;

删除表空间
DROP TABLESPACE cpwl2004_data INCLUDING CONTENTS CASCADE CONSTRAINTS;

小结
这是一个严重的违反工作流程的操作，以后在工作的数据库上不允许做任何操作，包括硬件和软件。
所有数据库级别的工作，一定要等到所有工作完成以后，并且数据备份完成以后，才可以做！！！

数据库维护工作，正常的流程是

• 所有业务工作已经完成
• 数据备份已经完成
• 执行数据库维护工作

删除历史用户的步骤

• 取消只读
• 删除用户
• 删除表空间
• 宕库
• 删除数据文件
• 启动数据库
• 测试

7.Ora-01122,ora-01110,ora-01207数据库无法启动
问题：Oracle8i，非归档模式，数据库无法启动，windows系统
处理方法：

alter database nomount;

alter database mount;

show parameter _co

alter database open; resetlogs;

recover database using backup controlfile until cancel;

1、加隐含参数
_allow_resetlogs_corruption = true

#.undo_management=MANUAL
#.undo_tablespace=‘UNDOTBS1’
*._corrupted_rollback_segments=(_SYSSMU1${,}_{S}YSSMU2$,_SYSSMU3${,}_{S}YSSMU4$,_SYSSMU5${,}_{S}YSSMU6$,_SYSSMU7${,}_{S}YSSMU8$,_SYSSMU9${,}_{S}YSSMU10$)

2、启动数据库mount;

svrmgrl

connect internal/oracle

startup nomount;

SVRMGR> alter database mount;
语句已处理。
SVRMGR> recover database;
完成介质的恢复。
SVRMGR> alter database open;

当你认为无法恢复的时候，查查百度，不要轻易放弃。