《手工管理的备份恢复.ppt》由会员分享，可在线阅读，更多相关《手工管理的备份恢复.ppt（152页珍藏版）》请在三一办公上搜索。
1、备份恢复1、备份物理备份：对数据文件、控制文件、归档日志文件的备份逻辑备份：对数据库内部逻辑对象的备份（exp、expdp）2、恢复数据库数据损坏的情况下。使用备份将受损的数据恢复回来的过程备份是一切数据安全手段的底线,备份数据库里发生的所有事务都记录在联机重做日志文件中，联机重做日志文件是循环覆盖使用。联机重做日志文件主要的作用是实例崩溃恢复Oracle有两种运行模式归档模式非归档模式归档模式就是将所有的联机重做日志文件在循环覆盖以前进行归档，保留一份副本，非归档是默认的运行模式归档模式决定了备份模式,冷备份1、如果数据库是非归档模式，那么只能使用冷备份1、数据库正常关闭，使用操作系统复制命
2、令，备份所有的控制文件、数据文件数据库正常关闭，会触发完全检查点信息，所有脏内存块都写入到了数据文件中，联机重做日志文件没有什么意义要备份所有的数据文件、控制文件，不需要联机重做日志文件2、如果使用的是abort关闭数据库，或者实例崩溃关闭，需要备份联机重做日志文件关键是要获取所有的数据文件和控制文件的位置,热备份1、数据库需要处于归档模式2、数据库打开的状态下，可以进行表空间、数据文件的备份3、归档对数据库的性能还是有一定影响的4、归档可以不丢失任何数据,归档模式,归档模式,启用了自动归档,归档模式中，对联机日志文件的归档分为两种模式手工方式和自动归档联机日志文件A写满以后，切换到B，手工归
3、档模式需要手工的发出命令才能归档，如果不发出命令，A不会被归档，同时A也不能被覆盖，这样切换回来需要覆盖A的时候，整个数据库被挂起除非测试，不要将生产数据库设置在手工归档模式,自动归档模式中，当LGWR在将重做日志写入当前联机重做日志文件中，发现写满时，于是切换到另一个新的联机重做日志文件，进行日志切换，同时触发归档进程（ARCn），将当前已经写满的联机日志文件进行归档其中的n表示我们启动了多个归档进程，oracle 10g中n从1到30,启动6个归档进程。,归档日志文件的存放位置,默认归档到这个目录里面。,默认存放在这个目录里面。,恢复区和新设置的归档区都是空的。,日志归档到了我们设置的目录
4、中。只有一份归档。注意，我们还可以将日志归档到另外一个服务器上。作为一个灾备的概念，但是需要要测试归档的性能。,归档的一些参数,只有在将联机日志成功归档到这个目录以后，该日志文件才能够被覆盖。Reopen表示一旦不能够成功到目的地，则每隔一段时间（默认300秒）尝试一次，下面的语句设置时间间隔是600秒。,归档到三个目的地，文件的名字都一样。,我们设置了三个归档目录，两个是强制的，一个是可选的如果最少归档的数目少于mandatory，那么没有什么意义。我们设置为3，表示至少归档三个目的地，就相当于设置了三个强制。,我们将第三个目的地给删除。,发现也能够成功的归档。,发现还是能够正常的归档，也就
5、是最少成功备份参数没有起作用。所以我们还是要依靠强制来实现多路径。,多次执行，当要覆盖第一个没有归档成功的日志文件的时候，数据库挂起,重新建立了这个目录。即使数据库被挂起，还是可以登陆，还是可以进行操作。,连续的操作以后，发现数据库挂起。,大约过了10分钟以后，因为reopen的原因，系统正常的归档以后，操作继续进行。,归档出现问题以后，最好的解决办法就是抓紧时间将归档目的地修复好。,另外一种解决方式就是将这个目录设置为defer。问题马上解决。但是要注意不能少于这个参数。,表示dest2目录不可用。,所有目录都删除以后怎么办？,使用defer的办法是没有用的。只能恢复目录了。因为总是需要归档
6、到一个地方去。,将标识为enable的修复。,重新指定了一个归档目录，问题快速解决。,解决思路1、首先将min_suceed设置成12、重新建立一个归档目录3、将以前所有的归档目录设置成为defer,生成的归档日志文件的文件名？,%s：日志序列号%S：固定长度的日志序列号，不足位在左边补0%t：日志线程号,%T：固定长度的日志线程号，不足位在左边补0%a：激活ID%d：数据库名%r：resetlogs生成的ID,默认为%t_%s_%r.dbf,热备份数据库1、可以备份某个表空间所有的数据文件，也可以备份某个表空间下的某个数据文件，整个的备份过程中，表空间是可用的,将日志进行归档，然后备份到另外
7、一个介质上。恢复的时候，备份的数据文件要能够使用，至少要求在begin backup和end backup之间所有的归档日志，否则备份的介质没有任何意义。对每一个表空间，都重复上面的操作。1、开始备份2、备份文件3、结束备份4、归档日志、备份归档日志,热备份原理1、Oracle的数据块大小是操作系统块大小的整数倍，直接复制数据文件到备份介质的过程中，由于数据库一直可用，数据块中不断地有数据进进出出，使用操作系统命令复制数据文件时，是基于操作系统块进行复制的，也就是说复制一个操作系统块的时候，首先锁定这个块，复制完成以后，解锁这个块，这样这个块在复制前和复制后是一致的。但是对于一个Oracle数
8、据库来说，一个块要分成几次进行复制，可能在复制一个操作系统数据块的时候，另外一个操作系统数据块被改变了，导致oracle数据块在复制到备份介质以后，前一半是没有改动过的，后一半是改动过的，数据块的状态就不一致，数据块就能够使用，备份也就不能够使用，这叫做分离数据块现象（split blocks）2、oracle在数据块的头部和尾部各存了一个版本号，通过这个来确认这个数据块是否是分离数据块，oracle修改过一个数据块以后，将这个数据块的版本号在头部和尾部各存放了一份3、为了修复分离数据块现象，我们在备份某个表空间的时候，首先进行begin backup，通知数据库开始备份，在没有end bac
9、kup命令之前，只要是进程修改了被备份的表空间所包含的数据块中的某条记录，oracle就会把该数据块中所包含的所有的数据行的数据生成重做记录，记录到日志文件中,4、通过发出begin backup以后，第一次修改数据块中的数据行之前，在联机重做日志文件中记录数据块的修改前的数据，这样在热备份恢复的时候，一旦发现某个数据块被分离，则会利用日志文件里的记录的数据对整个数据块进行恢复5、备份表空间中的所有的被修改过的数据块的所有数据行都被保存在了联机重做日志文件中，而不是只记录被修改的数据行的记录，因此在热备份过程中，会发现生成的联机重做日志文件的量比较大，这取决于业务的繁忙程度，例如DML量比较大
10、，那么产生的日志会非常的多6、发出begin backup命令以后，oracle会对被备份的表空间所对应的数据文件触发文件级别的检查点进程，将内存中属于该表空间的所有脏数据块写入数据文件，检查点结束以后，数据文件头部（第一个和第一个数据块）的检查点SCN和日志序列号都不在变化，直至发出end backup，数据文件头部的SCN和日志序列号才被更新7、在热备份的过程中，数据文件头部的SCN和日志序列号被冻结，但是数据文件本身还是最新的，和正常一样的更新和使用，DML更新了某个表，这些更新都会被写入到数据文件中去8、冻结数据文件头部的SCN号和日志序列号，是为了将来使用热备份进行恢复的时候，能够知
11、道应该从哪里开始应用重做记录，也就是备份的数据文件头部所记录的SCN和日志序列号，定位到日志文件中，从日志文件中找到开始的SCN，向后应用所有的日志文件9、end backup以后，所有的数据文件的头部SCN和日志序列号推进到最新，因为数据文件本身就是最新的,知道那个表空间正处于热备份状态？,在备份的过程中，数据库意外的崩溃，重新启动，出现了一个意外的情况，我们下面继续解决。1、实例没有启动，因此不能修改参数，只能生成pfile，修改后再倒入到spfile,修改pfile,系统提示一个数据文件损坏，我们怀疑可能是这个数据文件正在备份过程中实例崩溃。,果然是因为数据库备份过程中实例崩溃,轻松解决
12、。,备份控制文件只要在数据库结构发生变化以后，例如增加、删除、重命名数据文件或日志文件以后，都应该备份控制文件。两种方式备份控制文件1、二进制备份,2、SQL命令方式,备份到了这个文件中，里面是控制文件的重建语句。,文件部分内容。,初始化参数文件和密码文件也需要备份，只要复制即可。,介质恢复1、还原restore使用备份的文件替换损坏或丢失的文件，该阶段使用操作系统命令完成2、恢复recovery将归档的日志文件以及联机重做日志文件里的重做记录应用到还原出来的文件上，该阶段在SQLPLUS的recover命令完成打开数据库的时候，数据文件、控制文件、联机重做日志文件必须同步，如果不同步，需要进
13、行恢复，恢复成功以后才能打开数据库一致性是基于检查点SCN和日志序列号而言控制文件里记录了三种重要的检查点SCN号1、系统检查点SCN当检查点进程启动时，会将检查点结束时间的SCN号记录在控制文件中（SCN是一个以时间为参数的函数值），该检查点是全局范围内的，当发生文件级别的检查点（比如将某个表空间设置为begin backup而引起的检查点）时，则不会更新该系统检查点SCN,数据文件检查点当检查点进程启动时，包括全局范围的（例如发生日志切换）以及文件级别的（将表空间设置为只读、begin backup、或将某个数据文件设置为offline）检查点，这时会在控制文件里面记录每个数据文件上所发生
14、的检查点SCN（将数据文件设置为正常离线、只读时，将表空间设置为begin backup时，触发文件级别的检查点，并将该检查点更新控制文件和数据文件头部以后，就不再变化）,这个文件的检查点明显的高于其余文件，因为我们刚才执行一个begin backup命令，触发了一个文件检查点。,结束SCN每个数据文件都会有一个结束SCN，在数据库正常运行期间，只要是在线的、可读写的数据文件，其终止SCN都为空正常关闭数据库时，或者将数据文件正常离线、或只读时，都会由于触发了检查点进程，从而在控制文件里记录每个数据文件上的结束时 的SCN号,Begin backup不能设置数据文件的结束SCN,通过设置数据文
15、件的只读可以让结束SCN记录到数据文件中。,正常关闭数据库，每个数据文件的结束SCN都是一致的（只读、离线的除外）,数据库启动以后，数据文件的结束SCN都变成空。,在每个数据文件的头部，也记录了检查点SCN，该检查点SCN与控制文件中记录的数据文件的检查点SCN是一致的。也就是说，全局范围和数据文件级别的检查点，不仅会将检查点SCN记录在控制文件中，还会记录在数据文件的头部。,数据库正常关闭时，会触发一个完全检查点，并用该检查点结束时的SCN号更新以上4个检查点SCN（除了离线和只读的），下次数据库启动的时候，会比较这四个检查点SCN，如果他们相同，说明数据库是一致的，可以正常打开如果数据库非
16、正常关闭，例如掉电导致数据库没有进行完全检查点就关掉了，每个在线、读写的数据文件的终止SCN仍然为空，下次数据库启动的时候，发现在线和读写的数据文件的终止SCN为空，则SMON进程会进行实例恢复如果备份的数据文件覆盖当前的数据文件，则数据库会发现记录在控制文件里面的数据文件的检查点SCN号与从备份中还原的数据文件的头部记录的检查点SCN不一致，控制文件中的SCN比较新，备份中还原的数据文件头部的SCN比较旧，控制文件的SCN大于数据文件头部的SCN，数据库不能打开，要求对还原的数据文件进行恢复，应用重做记录，从而将该数据文件头部的SCN提升到控制文件里记录的SCN号,如果我们将备份的控制文件覆
17、盖当前的控制文件，这时控制文件比较旧，而数据文件则是当前最新的的数据文件，因此数据库会发现控制文件里面的SCN小于数据文件头部记录的SCN，于是进行恢复启动数据库的时候，如果发现控制文件里记录的数据文件检查点SCN与数据文件头部记录的SCN相同，但是在每个在线的以及可读写的数据文件之间，他们的检查点SCN不同，那么会要求进行介质恢复，例如begin backup后，实例崩溃，重启数据库时就会发生这种情况，必须发出end backup命令才能打开数据库。,完全恢复将数据库恢复到最新状态非归档模式归档模式非归档模式下面的完全恢复1、在非归档模式下面，如果出现介质的损坏，则必须使用一个在关闭状态下面
18、所做的备份进行恢复2、即使只丢失了一个数据文件，也必须还原所有的数据文件3、关闭数据库，还原所有的控制文件、数据文件，如果备份了联机重做，也可以还原，不还原联机重做日志文件也是可以的4、所用的备份，必须是在同一个时间点上做的备份,非归档模式的还原分为两种情况1、备份时，同时备份了联机重做日志文件关闭数据库，使用最近的备份，通过操作系统命令进行复制，将数据文件、控制文件、联机重做日志文件复制到这些文件所在的目录2、备份时，没有备份联机重做日志文件关闭数据库从最近的备份中，还原所有的数据文件和控制文件启动数据库，会报告找不到联机重做日志文件或者联机重做日志文件不匹配的错误消息recover dat
19、abase until cancel using backup controlfile；提示输入日志信息时，输入cancelalter database open resetlogs；最大的问题，丢失自上次备份以来所有的数据,我们下面来做一个还原（没有备份reodlog的还原）,建立了一个新的数据库。,将三类文件的位置和名字找出来，一个都不能少。,将所有数据文件、控制文件备份出来，不能漏掉任何的一个。,删除一个数据文件后，数据库启动时报错，数据文件丢失，看一下数据库的模式是非归档，只能进行完全恢复。,刚才做的恢复就相当于是备份了联机重做日志文件的恢复操作。非常的简单。,没有恢复联机重做日志文件
20、。恢复了所有的数据文件和控制文件。,提示日志文件比控制文件更新。,非归档模式下面下的完全恢复,归档模式下的完全恢复在归档模式下面，如果控制文件和联机重做日志文件都没有损坏，而只是数据文件损坏，并且只要存在备份以及自从该备份以来所有的归档日志文件，就能够把数据库完全恢复到发生介质损坏的那个时间点上，通过recover命令实现恢复操作如果所有控制文件损坏，或者整个联机重做日志文件丢失，或者自从上次备份以来丢失了某个归档日志文件，则需要进行不完全恢复因此对于控制文件、联机重做日志文件、归档日志文件，一定要注意保存好,归档模式下面的完全恢复分为三个阶段数据库级别数据文件级别表空间级别如果恢复整个数据库
21、，则需要将数据库启动到mount状态如果恢复某个数据文件或者恢复某个表空间，则可以在数据库打开状态下进行,当发出recover命令时，oracle会从所有被还原的数据文件头中选择一个最小的检查点SCN号以及日志序列号，从该日志序列号所指定的日志文件开始，向后依次开始应用所有的重做记录，直到每个数据文件头部的检查点SCN达到控制文件中所记录的数据文件检查点SCN为止，所有日志文件的序列号必须连贯，不能中断。在恢复数据文件的时候，必须以独占的方式锁定被恢复的数据文件数据文件联机或者正在被恢复，都不能进行恢复好处1、只需要恢复受损的数据文件2、如果不是system或者undo表空间损坏，那么可以在数
22、据库打开的情况下进行恢复,两个重要的视图v$recover_file：哪些数据文件需要恢复v$recovery_log：为了完全恢复受损的数据文件，需要哪些日志文件三种恢复方式1、recover database，关闭数据库使用如果系统表空间或者undo表空间所有数据文件损坏2、recover tablespace 非系统表空间、undo表空间损坏时建议使用这种方式需要首先将受损的表空间离线3、recover datafile 同上面的命令都是在数据库打开和关闭的时候使用,在恢复数据的过程中，会使用到数据文件、控制文件、联机重做日志文件、归档日志文件前三者都是联机的，后者是脱机的，因此在应用到
23、归档日志文件的时候，数据库往往会提示输入归档日志的目录，一般来说，我们可能将归档日志备份到另外一个位置，然后删除当前位置的归档日志，但是通常不去改变他的名字。如果我们将要恢复的归档日志放在了一个不同的位置，我们在恢复的时候，可以手工的指定位置，也可以通过设置下面的参数，让系统在我们指定的目录里面自动寻找因为归档日志很多，我们在应用的时候，不希望都去指定，希望将归档日志都放在一个目录里面，通过指定参数，让oracle在恢复的时候，自动的去寻找归档日志，自动的去应用。,将数据库改成归档模式。,数据库进行恢复，自动寻找归档日志的方法有三种前提：将需要的归档日志集中存放在一个目录里面，然后设置了正确的
24、dest路径1、,2、恢复时提示我们输入日志文件的路径，输入auto即可，oracle会自动搜索日志文件进行应用,3、sqlrecover automatic datafile 4，直接自动进行恢复,完全恢复的四种方法1、数据库打开状态，系统表空间和undo表空间未损坏，其他表空间损坏,清空buffer cahche,系统提示数据文件损坏。,突然发现在归档模式下面没有备份数据库。只能恢复数据库到冷备时刻。,将冷备的控制文件、数据文件都拷贝到指定目录。,启动报错。提示联机重做日志文件有问题，因为我们在冷备的时候没有备份联机重做日志文件。,数据库恢复，但只是恢复到上次冷备的时刻。,数据库还是非归档
25、模式。,设置为归档,将所有的备份删除。,对users表空间进行了备份。,在users表空间上进行了操作。,模拟了日志的归档。,对日志文件进行了归档的备份。,故障出现。,将表空间offline,将所有归档日志所在的目录改成归档目录。我们也可以采用这样的方式，不改变归档目录，但是将所有的需要的归档日志拷贝到归档目录中，总之就是将归档日志放在数据库能够找到的地方,数据文件头部的SCN，当初发出begin backup命令时，数据文件头部的SCN,控制文件中记录的数据文件的检查点SCN，出问题时的SCN是454751，offline时的检查点是455656.,因为备份已经恢复、归档已经设置，联机和控制
26、文件都没有问题。,2、数据库处于关闭状态，系统表空间和undo表空间损坏。,日常的操作,备份system数据库,要使用自动恢复，就需要设置好归档日志所在的目录。,模拟故障。,只启动到mount,数据库正在运行，undo表空间损坏。,没有报错，使用的应该是system的回滚段，因为用户是sys。,改变用户后马上报错。,重建失败。,只能进行恢复。,重新进行模拟上面的故障,对四个表空间进行了备份。,模拟一个故障,报错，提示undotbs1错误,备份拷贝回来。,恢复undo表空间不能在数据库打开状态下进行。,关闭数据库,将undo在线。,问题解决。,数据库在打开的情况下，system表空间崩溃。,恢复
27、备份文件,System自动联机。,Undo和system表空间的损坏都需要重启数据库进行修复。,数据库关闭，非system和undo表空间损坏,运行中突然掉电，一个数据文件损坏,还原备份文件。,只要是控制文件、联机重做日志文件没有损坏、归档日志全，数据文件有备份，恢复就非常的简单。不管你是什么故障。,数据文件没有备份，具有自创建该数据文件以来所有的归档日志文件创建了一个数据文件，就需要立即进行备份，如果该文件丢失，又没有备份，该如何处理，只能从归档日志中进行恢复。,添加了一个数据文件给users表空间，给表test15分配extent的时候，手工指定使用user02.dbf文件。,数据文件出现
28、故障。,创建该文件的SCN,将5号文件离线是的SCN,因为该文件被删除，所以文件头部的SCN是0因为没有备份该文件，所以重建该文件。,文件的SCN是当时文件创建时的SCN。,不完全恢复的场合1、进行完全恢复的时候，在应用归档日志的过程中，丢失了其中一个或者多个归档日志文件，因此我们只能将数据库不完全恢复到丢失的最早的那个归档日志文件为止2、丢失了整个联机重做日志文件组，而该联机重做日志文件还没有完成归档3、用户误删除了表里的数据，或误删除了表，或误删除了某个重要的用户，要恢复被误删除的数据，可以通过不完全恢复，将数据库恢复到误操作之前的时间点4、当前控制文件全部丢失，并使用了备份的控制文件进行
29、恢复，这时进行的不完全恢复，但是只要所有的归档日志、联机重做日志文件都在，仍然能够恢复所有的数据不完全恢复有下面的两个前提1、具有所有数据文件的备份，并且该备份是在要恢复到的时间点之前做的，例如要恢复到11：00点，那么备份就需要是11：00之前做的2、具有从备份完成的时间点开始，到要恢复的时间点之间的所有归档文件,三种类型的不完全恢复1、基于时间点的不完全恢复（time-based），恢复到指定的，历史上的某个时间点为止recover database until time yyyy-mm-dd hh24:mi:ss;2、基于撤销的不完全恢复（cancel-based），恢复到我们输入can
30、cel命令时为止，这通常用于丢失联机重做日志文件或归档日志文件，当恢复到丢失的日志文件的时候，只能输入cancel命令，表示恢复到此为止recover database until cancel3、基于SCN号的不完全恢复（change-based），恢复到我们指定的、历史上的某个SCN，从本质上来说，这与基于时间的不完全恢复一样，除非我们能够确定要恢复到SCN号，否则建议使用基于时间点的恢复recover database until cancel scn 建议在进行不完全恢复之前，将整个数据库进行冷备份，备份所有的数据文件、控制文件、联机重做日志文件，万一恢复失败，我们还能够将现场彻底还原
31、到进行不完全恢复之前的状态或者至少归档当前的联机日志文件、备份当前控制文件alter system archive log currentalter database backup controlfile to,不完全恢复之前，应该检查alter.ora，可能从中找出误操作的一些有关时间和SCN方面的信息不完全恢复的步骤1、关闭数据库，可以使用shutdown abort2、从备份中还原所有的数据文件，整个数据库所有数据文件都恢复，因为SCN要整体推进到要恢复的时间点上，数据库要能够打开，所有数据文件头部记录的SCN号要一致3、将数据库启动到mount状态4、选择一种不完全恢复类型（time、
32、cancel、change）5、以resetlogs选项打开数据库，一旦使用了resetlogs选项打开数据库，则说明以后所有的重做记录不再需要，同时，数据库的日志序列号从1开始,在oracle 10g数据库之前，如果我们以resetlogs方式打开数据库以后，没有做数据库的全备份，一旦再次发生介质损坏，导致数据文件的丢失，那么我们只能使用发出resetlogs之前的所做的备份进行恢复，最多只能恢复到发出resetlogs时这个时间点上，从而导致以resetlogs选项打开数据库以后，所有的数据变化丢失因此，一旦resetlog打开数据库以后，第一个工作就是全备整个的数据库到了Oracle10
33、g之后，应用日志的算法有了改变，我们能够做到利用发出resetlogs之前做的备份，发出resetlogs之前的归档日志文件，发出resetlogs之后的归档日志、当前的联机重做日志文件，将数据库恢复到发出resetlogs之后介质损坏的那个时间点上,备份,Resetlogs打开数据库,重做记录不再需要，日志序列号从1开始,10g之前,Oracle 10g之前，对数据库进行不完全恢复，需要对数据文件的状态进行查看v$datafile1、确认所有的必要的数据文件都是在线的2、只有使用了normal选项进行表空间离线的表空间、或只读表空间所对应的数据文件可以不需要在线的3、如果不完全恢复期间，数据
34、文件是离线的，那么他将不能够被恢复4、如果表空间使用immediate进行了离线，同时，在使用resetlogs选项进行打开数据库以后，该数据文件仍然处于离线状态，那么该表空间需要被舍弃，并且重新创建，因为该文件需要使用resetlogs以前的日志进行介质恢复,恢复后的数据文件,使用日志进行不完全恢复,日志应用到此为止，使用resetlogs打开数据库,这段日志不需要再应用了,从日志序列号1开始记录新的日志，这些日志是有用的,使用resetlogs打开数据库以后，从resetlogs以后的一段重做记录确认不再使用了，打开数据库以后，操作正常进行，产生新的日志，对于现在这个数据库来说，新产生的日
35、志是有意义的，从日志序列号1开始，resetlogs以前的日志不能够应用现在的数据库中了，现在的数据库已经不认识了，因为我们又从1开始了，以前的1已经不认识了。,使用normal选项使某个数据文件离线，离线以前，oracle会发出文件级别的检查点，从而唤醒DBWn将内存中属于该文件的所有脏数据块写入数据文件，并且控制文件中检查点SCN与数据文件一致。即便是在不完全恢复期间该数据文件仍然保持离线状态的话，也可以在不完全恢复成功以后，再将该文件在线，由于该文件不需要介质恢复，所以oracle可以直接将数据文件头的SCN修改成当前SCN关键是在数据文件online的时候，控制文件中记录的SCN和数据
36、文件头部的SCN是一致的，那么说明数据文件不需要进行介质恢复，因此可以直接online,执行依次checkpoint，对数据文件头部和控制文件中的SCN和结束SCN进行了更新。,控制文件中记录的数据文件的检查点信息数据文件头部的检查点一定是540159，而数据文件offline时的系统检查点分别是540282和540285，下一次数据文件online的时候，需要执行介质恢复。,备份数据文件,数据文件immediate offline,Resetlogs打开数据库的点,文件在这个点online,重做记录一直到这个点,请问这个点的数据文件能够online吗？,对新添加的数据文件进行了备份。对tem
37、p表空间没有进行备份。,默认的永久表空间不能删除。,正在操作中，DBA做了一个错误的操作，将表空间删除了。我们需要将数据恢复到出问题的那个时刻。需要进行不完全恢复。,表空间被删除以后，继续进行正常操作，产生了一些数据。,通过查看备份，我们确认所有数据文件都有备份，不是同一个时刻，而且temp没有备份，所有归档还都在。,通过日志，发现12：29：40发生了误删除，我们恢复到提前一秒钟,备份当前所有的数据文件、控制文件、联机重做日志文件,恢复所有的数据文件这些数据文件都不是同一个时刻备份的。但都是出事前备份的。,发现已经没有6号文件了。,发现6号数据文件还是没有回来。,6号数据文件回来了。,发现6
38、号数据文件的名字不对。,对文件名字进行修改。,数据文件需要校正。,数据回来了，但是因为是不完全恢复，还是丢失了部分数据。,基于SCN的恢复和基于时间的恢复一样，只不过基于SCN的恢复更加精确。前提都是1、控制文件没有损坏、联机文件没有损坏、归档日志文件没有损坏我们有意识的将数据库恢复到过去的某个点，例如为了恢复误删除对于联机重做日志文件和归档日志文件的丢失，我们通常使用基于cancel的不完全恢复，下面的实验就是删除联机重做日志文件后的恢复,2号日志文件组为当前的联机重做日志文件组，将它删除,数据库在进行正常的操作,Current日志文件组被删除。,关闭数据库,备份所有的数据文件、联机重做日志
39、文件、控制文件,还原所有的数据文件，这些数据文件是在不同的时期备份的,启动到mount状态，打开控制文件。,当恢复到SCN564007的时候，系统报错，而这个文件正是我们删除的联机重做日志文件。,使用auto,再次执行，输入cancel，打开数据库。,SCN564007以后的所有的数据库的改变都会丢失。因此丢失联机重做日志文件是一件很可怕的事情。特别是丢失当前正在使用的联机日志文件组。,联机日志文件自动回来了。但是丢失了数据。,丢失所有控制文件时的恢复，可以使用两种方法1、使用以前备份的控制文件2、创建新的控制文件使用以前备份的控制文件1、创建表t21、t22，以便使用备份的控制文件进行完全恢
40、复以后仍然存在,删除所有控制文件。,关闭数据库,备份整个数据库,将备份的控制文件恢复到相应位置，不要恢复数据文件,提示找不到控制文件,修改pfile，在dbs目录下面，注意名字和创建日期。,发现控制文件中的SCN比数据文件头部的SCN要旧。,系统使用完了归档日志文件，要使用联机重做日志文件，因为使用的是以前的控制文件，因此无法知道哪一个是当前最新的联机日志文件，所有的归档用完以后，只会使用一个联机重做日志文件，这个联机重做日志文件就是shutdown时的current log，因为非current都进行了归档。日志组中在一个时刻只有current没有归档。,联机日志组一共有三个。,我们尝试着使
41、用第一个日志组进行恢复。很幸运，如果Oracle报错，我们尝试第二个，总有一个是成功的。,打开数据库。,数据都在，丢失控制文件，只要数据文件备份、归档日志、联机重做日志文件都在，数据就不会丢失。,创建新的控制文件进行恢复，如果我们每次修改数据库结构时候，都将控制文件内容转储成为跟踪文件，并把其中的创建控制文件的SQL命令保存起来，那么当控制文件丢失的时候，我们也能够通过重建控制文件的方式，来恢复数据库。,将里面的建立控制文件的脚本粘贴出来。,VI这个文件以后，首先set number，找到前面需要删除的行数。发现是246行，使用246dd删除。,类似上面的结果。,模拟一些操作。,删除控制文件。
42、,关闭数据库，对数据库进行全备份。,将数据库启动到nomount,控制文件建立成功。,数据库自动进入mount状态。,重建控制文件以后，所有的SCN信息都丢失了。,控制文件中的系统SCN从current日志文件中的firstchange取得。,数据文件SCN从数据文件头部取得。,数据都没有丢失。,上面建立控制文件的时候，没有包含临时表空间。,使用以前备份的控制文件，在丢失当前联机重做日志文件的情况下，进行不完全恢复,确认表位于这个当前的联机日志文件中,删除了联机重做日志文件和控制文件。,关闭数据库、备份数据库。,不完全恢复，需要控制文件和数据文件,恢复直接完成，如果报错，那么重新执行一次上面的
43、命令，但是在输入的时候，输入cancel，不进行恢复，只是为了完成media recovery colplete。,显然数据丢失。,联机重做日志文件被重建,创建新的控制文件，在丢失当前联机重做日志文件的情况下，进行不完全恢复。1、系统的checkpoint会从redo log的current的first_change中取2、文件SCN会从数据文件头部中取我们此前做过trace文件的创建，数据库的结构没有发生变化，因此可以继续使用。,关闭数据库，进行数据库的全备份1、使用的是非abort模式关闭2、备份数据库,在SQL中执行这一段代码,控制文件的文件SCN取自数据文件头部的SCN,因为联机重做日志文件不存在，因此系统SCN变成了0，需要归档日志来提升。,模拟了一种非常糟糕的情况1、掉电、联机日志和控制文件都损坏,1、关闭数据库（abort），对数据库进行全备,省略，建立控制文件。,因为使用的是abort，出现上面的错误。,通过修改参数，强制打开数据库。,在pfile里面添加上面的三行。,数据库虽然打开，但是使用的是强制打开，因此存在数据库的不一致性。需要马上进行数据库的export全库导出，重建该数据库。,使用alter database open resetlogs打开数据库。,报了一个错误。,实验掉电、控制文件和联机重做日志文件全部都损坏归档日志还在、数据文件有备份。,
