备份和恢复问题以及失败类型

与备份和恢复相关的服务级别协议的三个方面是：MTBF（平均无故障时间）  MTTR （平均恢复时间）和数据丢失
作为DBA目标就是增加MTBF减少MTTR和数据丢失
失败类型：
1.语句失败
数据错误，权限错误，空间错误，逻辑错误
空间管理问题是一个常见问题。包括：由于表空间已满而无法扩张某个段；耗尽撤销表空间；运行使用磁盘排序的查询或使用临时表时临时空间不足；某个用户达到配额；某个对象达到其最大区间限制。
如果将数据文件设置为自动扩展或者启用可恢复的空间分配，那么可能减轻空间问题的影响。
如果某个语句失败，则此语句将回滚，其他任何DML语句将保持完好，而且不会提交。
2.用户进程失败
用户并非注销的异常退出；终端的重新启动，导致地址违规的程序。
PMON后台进程通过定时轮询所有服务器进程来确定会话的状态。如果某个服务器进程报告丢失了与某用户进程的联系，此时PMON进程会解决这个问题。如果指定的会话位于某个事务的中部，那么PMON进程
会首先回滚这个事物并释放该会话的所有锁定，然后终止该服务器进程，同时将PGA释放回操作系统。
如果会话异常终止，系统将自动回滚处于活动状态的事务。
3.网络故障
侦听器  网络接口卡 路由
一个侦听器每次只能为一个联接请求提供服务，并且需要在适当的时间内启动一个服务器进程并且将该服务器进程连接到某个用户进程。如果数据库同时接收到大量的连接请求，那么用户在尝试连接数据库时
可能会收到错误消息。配置多个侦听器（每个侦听器位于一个不同的地址/端口组合上）可以避免这个问题。
4用户错误
闪回查询，闪回删除，闪回数据库和完全恢复
5.介质失败
控制文件，联机重做日志应当始终通过多路复用技术进行保护。
数据文件无法被多路复用。一旦某个文件被损坏，那么唯一的选择是从备份中还原这个数据文件。所谓还原文件，就是从其备份位置提取文件，然后将其放回预想位置。此后对文件进行恢复。已还原的备份处于过期
状态，而“恢复”意味着通过应用从联机和归档的重做日志中提取的变更将数据文件恢复至受损之时的状态。
恢复需要使用归档的重做日志。归档的重做日志是在每次日志切换后生成的联机重做日志文件副本。
为了应对介质失败，我们必须生成控制文件，联机重做日志文件以及归档的重做日志文件的多个多路复用副本，此外还必须对控制文件，数据文件，以及归档日志文件进行备份。
多路复用并才能不能保护数据文件，数据文件必须通过硬件冗余受到保护。硬件冗余指常用的raid系统或oracle自己的ASM。
6.实例失败
实例失败后，数据库完全可能丢失已提交的事物和存储未提交的事物。这就是所谓的受损或不一致数据库。
导致这种情况的原因是服务器进程在内存中进行工作，这些进程更新了数据库缓冲区缓存内的数据块与撤销块。最后，DBWn进程将更改后的数据块写至数据文件。
DBWn进程用于选择脏脏缓冲区进行写操作的算法考虑了性能问题，从而首先写入最不活跃的数据块，毕竟对每秒仲都在发生变化的数据块进行频繁的写操作是不可取的。不过，这意味着在任意给定的时刻，完全可能
存在尚未写至数据文件的已提交事务以及已被写至事务文件的未提交事务，也就是说，commit命令与数据文件的写操作不存在任何联系。当然，被应用于数据块和撤销块的所有变更都已经存在于重做日志文件中。

LGWR进程实际上会采用一种非常积极的算法进行写操作。LGWR进程尽可能实时地进行写操作，并且在执行commit命令时确实会完成实时写操作。这正是实例恢复的关键。实例失败后oracle数据库将受到损坏，但是
在磁盘上的重做日志流中始终存在着修正损害所需的足够信息。
 

实例恢复
如果数据库损坏--即包含未提交数据或丢失已提交数据，那么oracle会检测到这种状况，并且能够通过执行实例恢复来删除损坏。
实例恢复不仅可以重新构成在崩溃时未被保存至数据文件的任何已提交事务，而且可以回滚已被写至数据文件的任何未提交事物。这种恢复时完全自动的，我们无法随意停止实例恢复过程。
恢复机制：实例恢复只不过是使用联机重做日志文件的内容将数据库缓冲区缓存重新构建至崩溃之前的状态。
怎样才能调用实例恢复呢？使用startup命令
首先，在数据库过度到加载模式时，SMON进程会读取控制文件，随后在数据库过渡到打开模式时，SMON进程会查看所有数据文件和联机重做日志文件的文件头，此时，如果已经出现了实例失败，由于文件头
没有全部同步，因此SMON进程会发现实例失败，从而进入实例恢复例程，而数据库只能在前滚阶段结束之后才能被真正打开。


调整实例恢复
实例恢复能够保证不造成损坏，但是数据库能够打开之前需要耗费大量的时间来完成实例恢复的前滚操作。这个时间取决于两个因素：需要读取的重做数，以及应用重做需要在数据文件上完成的读写操作数。
检查点保证了在某个特定的时间，DBWn进程已将构成一个特定系统更改号的所有数据变更都写入数据文件。在一个实例崩溃事件中，只有SMON进程需要重演从上一个检查点位置开始生成的重做。无论是否提交
在这个检查点位置之前多有的全部变更都已写入数据文件。因此，显然不需要使用重做来重新构造在该检查点位置之前已提交的事物。此外，在这个检查点之前未提交事务所左的变更也会被写入数据文件，因此也不
需要重新构造该检查点位置之前的撤销数据，回滚需要使用的这些数据已经存在与磁盘上的撤销段内了。
检查点位置越金，实例恢复就越快。如果检查点位置是最近的，那么不需要前滚，此时可以立即打开实例并直接进入回滚阶段，不过，实现这种操作的代价很大。为了前移检查点位置，DBWn进程必须将变化的数据块写至磁盘，过多的磁盘I/O会削弱数据库性能。但是另一方面，如果不频繁使用DBWN进程，那么在实例崩溃之后，SMON就必须处理千兆字节的重做以及在数据文件上执行数百万次的读写操作，实例失败后的MTTR可能会延长数小时。
fast_start_mttr_target这个参数使得对实例恢复时间的控制变得十分容易。
设置fast_start_mttr_target参数值越小，DBWn进程将会更努力地藏时最小化检查点位置与实际时间的间隔。不过需要注意的是，这只是个目标，如果设置了一个不切实际的较小值，那么DBWn物理如何也不可能达到要求。
MTTR顾问程序，这个顾问程序可以让您确定实例失败后需要的恢复时间，此外，从V$INSTANCE_rECOVER视图也能获得这些信息。
如果将fast_Start_mttr_target设置为非零值，将产生两个效果。首先它设置了恢复目标，也产生了次生效应：启用检查点自动调整机制，检查点自动调整机制检查有关计算机使用情况的统计信息。如磁盘I/O速率和CPU使用情况，如果发现能力有剩余，它将利用此能力写出数据库缓冲区缓存的其他脏缓冲区，从而前移检查点位置。这样一来，即使将fast_Start_mttr_target参数设置为较大的值，时间恢复数据也完全可能大大减少。
如果将fast_start_mttr_target 设置为非零值，将启用检查点自动调整。
检查点位置由DBWn自动前移。这个过程称为增量检查点。
除此之外还有完整检查点和局部检查点。
如果将所有脏缓冲区都写入磁盘，就会出现完整检查点。
只有两种情况才会执行完整检查点：1有序关闭2dba要求这么做
当使用normal,immediate,transactional选项关闭数据库时，都会执行检查点：在关闭和卸载数据库之前。DBWn会将所有脏缓冲区刷新到磁盘中。这意味着，在次打开数据库时，不需要执行任何恢复操作。
alter system checkpoint;

为了保证数据库最大可恢复性，必须多路复用控制文件，必须多路复用联机重做日志，必须以归档日志模式运行数据库，并多路复用归档日志文件，最后作常规备份。
多路复用控制文件