练习3:完全数据库恢复
我们要实现恢复到出数据库出问题的时间点,必须先把数据库设置成归档模式。在接下的步骤中首先将设置数据库为归档模式,然后生成归档日志文件,最后在数据库崩溃的时候,利用归档日志文件把数据库恢复到发生问题的时间点。
步骤一:配置数据库归档模式
首先说明一下什么叫归档,归档就是把联机重做日志文件复制到归档重做日志文件的过程叫归档。下面我们通过v$database视图,查看PRACTICE数据库是否处于归档模式下:
数据库标示符(dbid)是数据库创建时Oracle分配的一个唯一编号,从log_mode查询的结果可以看出PRACTICE数据库并没有处于归档模式,因此数据库切换到下一个重做日志文件时,Oracle将覆盖前一个重做日志中的事务,联机重做日志文件中的重做变化信息一旦被覆盖,就不能被使用。
在设置归档模式之前,我们先熟悉并设置三个相关的参数:
-
Archive Destination(归档目的地址) 动态参数,通过在参数文件中加入如下行,告知数据库把归档重做日志文件存放在什么位置:
ALTER SYSTEM SET log_archive_dest=” D:\oracle\PRACTICE\ARCHIVE”; ,归档文件可以被拷贝到多个目录中(最多5个)。 -
Archive Format(归档文件名格式)静态参数,在参数文件中可以指定归档文件的命名约定,默认格式ARC%S_%R.%T,可以通过
ALTER SYSTEM SET log_archive_format=”ARC%S_%R.%T” SCOPE=SPFIlE; 设置,每当联机重做日志切换时,就产生一个新的序号。 - Archive Start(归档启动)在Oracle 10g该参数被废除,在配置参数文件中将不需设置,该参数只要在数据库启动设置,这个值将持续到下一次修改,这个过程中无论发生多上次重启都没关系。这就避免了Oracle10g之前,启动时调整该参数值,而没有修改参数文件的值,下次启动时又恢复至未修改的状态。
修改完毕后,关闭数据库,以MOUNT方式启动,
2 SQL > STARTUP MOUNT;
3 SQL > ALTER DATABASE ARCHIVELOG;
打开数据库后,每次当前日志文件切换时,都会在归档目的路径下生成一个文件。下面我们运行一些命令来验证参数设置是否起作用了,可以查看视图v$archive_dest中的内容,检查归档路径是否正确。
如果状态为(Valid)意味着正确初始化目的路径,下面使用显示参数命令(show parameter),来查看任何一项参数设置:
2 SQL > SHOW PARAMETER log_archive_format
另一个用于查看归档信息的SQL*Plus命令是归档日志列举命令(archive log list):
在参数文件设置已经起作用,打开数据库
当前数据库活动不多,很难填满当前联机重做日志文件,可以使用ALTER SYSTEM命令进行手工切换日志文件。
步骤二:运行备份脚本
利用练习1的脚本进行数据库备份,具体步骤参见练习1步骤三。Oracle推荐在数据库设置为ARCHIVE LOG模式后进行完整的数据库备份,使用整体一致的数据库备份和所有归档日志文件的拷贝,能够把数据库恢复到任何时间点上。
步骤三:生成重做日志
在TINA.DATE_LOG插入行,生成数据库活动记录,然后强制进行日志切换,在后续的步骤将需要至少一个归档日志文件。执行强制日志文件时,会在警告日志文件中看到如下内容
步骤四:删除一个数据文件
关闭数据库,然后删除USERS01.DBF文件,当打开数据库时,看到如下信息:
步骤五:还原丢失的数据文件
我们以SHUTDOWN ABORT关闭数据库(后续的练习中将会讲述数据库打开时恢复),然后启动数据库,提示步骤四的出错信息,我们查看v$recover_file内容:
从步骤二所做的备份目录下复制USERS01.DBF文件到当前数据库文件路径,此时再查看v$recover_file视图,该错误项不存在,change#列有一个数据值。该数值与v$datafile视图中对应所有文件的检查点变化数值进行比较,将会看到v$datafile视图中SCN要比v$recover_file中的数值大,除非对应所有联机数据文件的SCN与数据文件头部以及控制文件相同,否则无法打开数据库。
步骤六:恢复还原的数据文件
为了使所有的数据文件拥有一直的SCN号,需要应用归档重做日志文件,使用如下命令:
使用该命令,Oracle确定哪个数据文件被恢复以及需要哪个重做日志文件。当恢复成功,系统将提示成功:Media recovery complete。
以下说明非必要,但有助于确认归档重做日志文件范围,使用如下语句查看历史归档和当前联机重做日志信息
2 SQL > SELECT * FROM v$log;
完成恢复后,查看v$recover_file的内容,没有任何返回行,表明USERS01.DBF所需的重做信息均已被采用,打开数据库,如下图显示:
步骤七:确认数据库已恢复
检查TINA.DATE_LOG中的数据最新的日期/时间值,应该在删除数据文件之前,如果存在则表示,成功地进行一次完全数据库恢复!
练习4:不完全数据库恢复
所谓不完全恢复是把数据库回退到某一时间点,在恢复的过程中使用部分(而非所有的)归档重做日志文件。在如下情况需要进行不完全数据恢复:
- 由于失误而删除数据库对象
- 丢失部分或全部联机重做日志
- 在恢复过程中丢失了一个已归档的重做日志
- 错误地删除表空间
当使用不完全恢复数据库时,通过以RESETLOGS选项打开数据库,一旦数据库打开被忽略的重做信息就不能再使用。重置日志文件创建数据库的一个新实体,数据库的SCN号将以新的日志序列流开始,其实的日志序号为1。
在下面的练习中,删除TS4DROP表空间(因为删除表空间会向告警日志写入一条消息,可以通过该消息定位恢复时间点),然后恢复数据库到误操作发生前的时间点。
步骤一:删除表空间
这里将设置一个不完全恢复的环境,最好的方法先在TINA.DATE_LOG表中插入一笔三十年后的数据,并进行至少3次强制日志切换,然后删除PRACTICE数据库中的TS4DROP表空间,这样恢复中将使用已归档的日志,而不是联机日志。
2 SQL > SELECT create_date FROM tina.date_log;
为删除TS4DROP表空间,使用如下命令:
2 SQL > ALTER SYSTEM SWITCH LOGFILE;
执行命令后查看v$tablespace视图,TS4DROP表控件已经被删除
步骤二:确认恢复时间点
在实际工作中,DBA可能并不知道事故发生的准确时间,由于本练习是删除表空间,可以从告警日志定位发生问题的时间点,而对于对象变动,如:删除表需要使用LogMiner找出更精确的时间(将在后续的练习介绍)。
在告警日志文件中,找出删除表空间的记录:
记录显示在2010-01-12 07:48:03时间执行了删除表空间命令,该命令在1秒内执行完毕,在该命令之前,告警日志发生了一次日志切换。对应当前日志序号为28,可以使用如下语句查看日志序号28的相关信息:
由此我们得知在2010-1-12 07:48:03执行了一次删除表空间的操作,当前的重做日志序号为28,其变更号从518720开始,这些信息对于不完全恢复是关键的,因为通过这些信息我们可以将不完全恢复进行到某一时间点、某一数据库更改号或者某一特定的日志文件上。
步骤三:还原数据文件和控制文件
在进行不完全恢复需关闭数据库,从练习3中复制所有数据库文件和控制文件到当前数据库所在位置,注意的是当前联机重做日志需保留,因为可能需要联机重做日志文件中的重做信息,将数据库恢复到表空间被删除之前的时间点。
步骤四:不完全恢复数据库
使用ALTER DATABASE命令恢复数据库,有恢复到某一特定的时间、更改号或重做日志文件三种方式:
- 基于时间的恢复 通过指定时间参数可以把数据库恢复到制定时间点,日期必须符合yyyy-MM-dd HH24:mi:ss格式的字符。
SQL> ALTER DATABASE RECOVER AUTOMATIC UNTIL TIME '2010-01-12 07:48:02'; - 基于变化的恢复 指定一个SCN值用于恢复,该方法是三种方法最为准确
SQL> ALTER DATABASE RECOVER AUTOMATIC UNTIL SCN 518720; - 基于取消的恢复 使用CANCEL关键字,执行不完全数据库恢复。重做日志是一个接一个应用直到对应时间点的那个重做日志文件。
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
以MOUNT启动数据库,使用基于时间的恢复(需要注意是恢复的时间,比删除表空间提前一点,这里是提前一秒为2010-01-12 07:48:02),具体命令如下:
步骤五:以重置日志选项打开数据库
完成不完全恢复后,必须重新设置联机重做日志,当使用RESETLOGS选项打开数据库时,所有数据库文件都获得一个新的RESETLOGS SCN和时间戳。为了打开数据库并重新设置日志,可以使用如下命令:
执行后联机重做日志文件被还原,每个数据文件头被更新,控制文件而被更新,所有这些工作完成后,数据库打开。
可以看到日志文件再次开始计数。
步骤六:确认数据库恢复
恢复完成后,可以查看v$tablespace视图来查看数据库中是否包括TS4DROP表空间;检查TINA.DATE_LOG表看是否存在删除表空间前插入那笔三十年之后的记录,丢失了删除表空间后插入该表的数据。
如果结果和你想象的一样,恭喜你成功地进行了不完全恢复!