oracle运行失败的类型

1.语句失败

一条SQL语句可能会由于多种原因而失败。虽然很多原因不属于DBA的管理范围，但是DBA必须时刻准备修正这些错误。在某条SQL语句失败时，执行这条语句的服务器进程会检测问题并回滚该语句。试图更新许多记录的一条SQL语句可能在执行过程中失败，那么在失败前更新的所有记录都将通过撤销操作被回滚至变更前的状态。上述操作过程是自动的。如果这条语句是某个多语句事务的组成部分，那么已经成功运行的所有语句保持结果不变，但是不进行提交。在理想情况下，编程人员应当在代码中包含能够确定和管理任何问题的异常子句，但事实上总是存在错误处理程序无法确定和解决的一些问题。

无效数据是语句失败的常见原因，这种情况通常是由于违反了格式或约束所造成的。编写规范的用户程序能够避免格式问题（例如试图在一个数值字段中插入字符数据），但是在使用来自第三方系统的数据处理批量作业时经常会出现这种问题。oracle自己会尝试通过自动的类型强制转换将数据类型转换为可以处理的类型，从而解决格式问题，不过这种做法的效率非常低，而且我们也不应当对其产生依赖。虽然oracle能够检测约束违反，但是无法解决这些问题。显而易见，无效数据导致的问题并不是DBA的过错，然而DBA必须与用户一起处理问题，从而使数据正确有效，并且还必须与编程人员一起尝试自动进行这些处理。

与DBA不相关的第二类语句失败是应用程序中的逻辑错误。编程人员开发的代码在某些环境下数据库无法执行，死锁就是这样一个例子：在“运气不佳”的两个会话正好同时在同一行上执行相同的操作前，代码可以正确运行。死锁不是数据库错误，而是由于编程人员编写的码允许出现不可能情况所导致的错误。

空间管理问题是一个常见问题，同时又是不应当出现的问题。一名出类拔萃的DBA能够主动的监视空间使用情况，并且能够在出现问题之前执行适当的操作。与空间相关的语句失败的原因包括：由于表空间已满而无法扩展某个段；耗尽撤销空间；运行使用磁盘排序的查询时或使 代 用临时表时临时空间不足；某个用户达到配额；某个对象达到其最大区间限制。Database Control包含了撤销顾问程序、段顾问程序、Automatic Database Diagnostic Monitor以及警报机制，它们能够帮助在出现与空间相关的问题之前找到这些问题。如果将数据文件设置为自动扩展或者启用可恢复的空间分配，那么可能减轻空间问题的影响。不过在理想情况下，应当永远不存在空间问题。

SQL语句还可能因为缺少权限而失败。例如，在表中进行选择或执行一小段代码。分析一条SQL语句时，服务器进程会检查执行该语句的用户是否具有必须的权限。这种错误表明当前的安全结构不适合 ，此时DBA应当授予适当的系统权限和对象权限。

注意：如果某个语句失败，则此语句将回滚。其他任何DML语句将保持完好，而且不会提交。

2.用户进程失败

用户进程可能由于多种原因而失败，这些原因包括：用户并非注销的异常退出；终端的重新启动；导致地址违规的程序。无论是上述哪一种原因，结果都是相同的。PMON后台进程通过定时轮询所有的服务器进程来确定会话的状态。如果某个服务器进程报告失去了与其用户进程的联系，此时PMON进程会解决这个问题。如果指定的会话位于某个事务的中部，那么PMON进程会首先回滚这个事务并释放该会话的所有锁定，然后终止该服务器进程，同时将PGA释放回操作 系 统。

注意：如果会话异常终止，系统将自动回滚处于活动状态的事务。

3.网络故障 

在于网络管理员共同协作的情况下，DBA应当能够通过配置Oracle Net来杜绝单点故 障。此时，需要考虑的三个方面为：侦听器、网络接口卡以及路由。

虽然数据库侦听器不大可能崩溃，但是一个侦听器能够完成的工作量是有限的。一个侦听器每次只能为一个连接请求提供服务，并且需要在适当的时间内启动一个服务器进程并且将该服务器进程连接到某个用户进程。如果数据库同时接收到大量的连接请求，那么用户在尝试连接数据库时可能会收到错误信息。配置多个侦听器（每个侦听器位于一个不同的地址/端口组合上）可以避免这个问题。

在操作系统和硬件层次，网络接口也可能失败。在理想情况下，针对冗余和性能问题，服务器应当具有两个或两个以上的网络接口卡，那么，将它们连接到物理上分离的子网是非常理想的。随后，通过在TNS_NAMES.ORA条目的ADDRESS_LIST区域列出多个地址，在客户端配置连接时间容错。这样，用户进程就可以尝试一系列路由，直到找到有效的路由为止。

提示：单实例数据库只在连接时进行网络容错，连接之后的网络失败会破坏当前连接的会话，从而必须重新连接这些会话。在RAC环境中，会话可以在发生故障时转移到另一个不同的实例上，而用户可能根本没有发现。

4.用户错误

长久以来，用户错误无疑是管理中最严重的错误。就oracle而言，其所关心的是事务。ACID测试中表示“持久性（Durability）”的“D”规定，一旦事务被提交，那么其他所有用户都必须能够立即看到所发生的变更，并且这些变更绝对不可逆。不过至少对于DML错误来说，用户在提交之前发现错误时仍然有机会回滚的语句。但是，对于DDL语句来说，用户无法回滚错误的语句。例如，如果某个编程人员实际上登录了产品数据库但认定自己登录的是测试数据库，并且该编程人员删除了一个表，那么就会在DROP TABLE命令内嵌入COMMIT命令。此时，这个表被删除，而且用户无法回滚DDL语句。

提示：请记住，COMMIT被内置到DDL语句中。

5.介质失败 

介质失败意味着磁盘受到损坏，因此磁盘上存储的文件也会受到损坏。这个问题不是DBA造成的，但是有时需要DBA来解决。需要指出的是，无论任何文件被损坏，都不应当是损失数据的理由。“介质失败”类别中包含了一种特殊的用户错误，即系统或数据库管理员意外的删除了文件。

当某个磁盘被损坏时，如果磁盘子系统自身没有通过RAID进行保护，那么在磁盘上存储的一个或多个文件也将受损。数据库由控制文件、联机重做日志以及数据文件这三种文件类型组成。控制文件和联机重做日志应当始终通过多路复用技术进行保护。如果在不同的磁盘上存在控制文件的多个副本，那么即使某个副本被损坏，我们仍然能够获得可用的控制文件副本。同样的，每个联机重做日志存在多个副本也意味着不会损失任何一个联机重做日志。数据文件无法被多路复用（除了在硬件层面使用RAID的情况），因此，一旦某个数据文件被损坏，那么唯一的选择是从备份中还原这个数据文件。所谓还原文件，就是从其备份位置提取文件，然后将其放回预想的位置。此后对文件进行恢复。已还原的备份处于过期状态，而“恢复”意味着通过应用从联机和归档的重做日志中提取的变更将数据文件恢复到受损之时的状态。

恢复需要使用归档的重做日志。归档的重做日志是在每次日志切换后生成的联机重做日志的副本。从备份中还原某个数据文件后，应用于数据文件并使其更新的变更会按照时间的先后顺序（从进行备份之后生成的归档日志开始）提取出来。显然，因为丢失归档日志会使恢复进程失败，所以必须注意归档日志的管理。归档日志最初创建在磁盘上，由于会像控制文件和联机日志文件一样遭受磁盘损坏的影响，因此也应当被多路复用，也就是要做不同设备上创建两个或者多个副本。

为了应对介质失败，我们必须生成控制文件、联机重做日志文件、以及归档的重做日志文件的多个多路复用的副本，此外还必须对控制文件、数据文件以及归档日志文件进行备份。不必备份重做日志，事实上，重做日志再被复制至归档日志时会进行备份。多路复用并不能保护数据文件，数据文件必须通过硬件冗余受到保护。硬件冗余指常用的RAID系统或oracle自己的Automatic Storage management(ASM)。

6.实例失败

实例失败是实例的无序关闭，通常称为崩溃（crash）。断电、关闭或重启服务器以及许多至关重要的硬件问题都会导致实例失败。在一个oracle后台进程可能失败的某些情况下，也会触发即时的实例失败。从功能上看，无论何种原因，实例失败的结果都与执行SHUTDOWN ABORT命令的结果相同。您可能已经了解到这样的情况：人们在执行SHUTDOWN ABORT命令时会谈论“数据库崩溃”的问题。

实例失败后，数据库完全可能丢失已提交的事务和存储未提交的事务。这就是所谓的受损或不一致数据库。导致这种情况的原因是服务器进程在内存中进行工作，这些进程更新了数据库缓冲区缓存内的（而不是磁盘上）数据块与撤销块。最后，DBWn进程将更改后的数据块写至数据文件。DBWn进程用于选择脏缓冲区进行写操作的算法，考虑了性能问题，从而首先写入最不活跃的数据块，毕竟对每秒钟都在变换的数据块进行频繁的写操作时不可取的。不过，这意味着在任意给定的时刻，完全可能存在尚未写至数据文件的已提交事务以及已被写至事务文件的未提交事务，也就是说，COMMIT命令与数据文件的写操作不存在任何联系。当然，被应用于数据块和撤销块的所有变更都已经存在于重做日志中。

详细描述下提交处理过程：执行COMMIT命令时，LGWR进程会将日志缓冲区的内容写至当前的联机重做日志文件。DBWn进程与COMMIT命令毫无关系。因此，考虑到性能因素，DBWn进程写入的内容尽可能少，频率尽可能低，这意味着数据库总是过期的。不过，LGWR进程实际上会采用一种非常积极的算法进行写操作。LGWR进程尽可能实时的进行写操作，并且在执行COMMIT命令时确实会完成实时写操作。这正是实例恢复的关键。实例失败后oracle数据库将受到损坏，但是在磁盘上的重做日志流中始终存在着修正损害的足够信息。