Oracle（RAC）数据库调优和事故分析应关注的技术点

Oracle 11g Audit

Oracle审计（Audit）功能用于监视用户所执行的数据库操作，审计记录可存在数据字典表（称为审计记录：存储在system表空间中的 SYS.AUD$ 表中，可通过视图 dba_audit_trail 查看）
或操作系统审计记录（默认位置为 $ORACLE_BASE/admin/$ORACLE_SID/adump/ ）中。

而不管是否打开数据库的审计功能，以下这些操作Oracle系统都会强制记录：

用管理员权限连接Instance；
启动数据库；
关闭数据库。
注意：Oracle 10g默认是不开启审计的，而Oracle 11g默认是开启审计的！一般上市公司的核心数据都被要求开启审计功能。
审计数据/日志被写满是会导致Oracle RAC无法服务的！因此对于 Oracle 11g 要重点关注审计功能，如果没有必要就赶紧关闭吧。

Oracle 10g ASM

在海量数据库环境中，DBA可能会花费很多的时间来做磁盘管理。比如一个表空间将占满整个磁盘，DBA就需要再添加一块磁盘到操作系统中，然后再在新的磁盘上创建新的数据文件。如果是单个磁盘这倒不是很繁琐，问题是如果原先我们使用的是RAID或者说是LVM，那么现在大量的数据仍然是分布在以前的那些磁盘上，如果我们想让这些数据均匀地分布在以前的磁盘和新增加的磁盘上，就可能就要耗费一天甚至几天的时间来做原先数据的导出导入。
如果有一种方法，能实现我们就把一块磁盘加到系统里，然后告诉Oracle我们要用这块盘了，剩下的工作全部由Oracle来完成，该是多好的一件事情！
Oracle10g 已经提供了这个功能，这就是自动存储管理，即ASM（自动存储管理，Automatic Storage Management）。Oracle10g 的ASM不但帮助DBA从繁琐的磁盘空间管理中解脱出来，而且更值得关注的是ASM同时提供了条带和镜像的功能，而这些功能原先需要通过单独地配置RAID来实现。
ASM 提供了专门为 Oracle 数据库文件建立的文件系统与卷管理器的垂直整合功能。ASM 在所有可用的资源中分布 I/O 负载，以便在免除手动 I/O 调节需要（通过分散数据库文件来避免热点）的同时优化性能。ASM 帮助 DBA 管理动态数据库环境，让 DBA 能够在扩大数据库规模的情况下，无需关闭数据库以调整存储分配。
ASM 允许DBA 定义一个存储器组（称作磁盘组）。然后，由 Oracle 内核管理该存储器组上的文件命名与数据库文件的放置。DBA 可利用全新的 SQL 命令（create diskgroup, alter diskgroup 与 drop diskgroup）来改变存储分配——添加或删除磁盘。用户也可通过使用企业管理器（EM）和数据库配置助理（DBCA）来管理磁盘组。
ASM 通过自动重新平衡来促进非侵入性存储配置的改变。它在所有可用的存储器中分配数据库文件，以便优化性能和资源利用率。
ASM 是一种能力，它通过实现手动存储器的自动化来节省 DBA 的时间，使其能够以更高的效率管理更大、更多的数据库。
确保正确配置你的ASM功能并开启它。

Oracle System Global Area （SGA）

当启动 Oracle 数据库时，系统会先在内存内规划一个固定区域，用来储存用户需要的数据，以及Oracle运行时必备的系统信息。我们称此区域为系统全局区（System Global Area），简称SGA。
SGA 有几个重要区域，它们是：
Database Buffer Cache - 数据库缓冲区
Redo Log Buffer - 重做日志缓冲区
Shared Pool - 共享区
Java pool, Large pool ...
确保分配给你的数据库足够的SGA空间。

Oracle SGA ulimit

Linux 系统中的 ulimit 指令，对资源限制和系统性能优化提供了一条便捷的途径。用户的 shell 启动脚本、应用程序启动脚本以及直接在控制台输入命令都可以通过该指令限制系统资源的使用，包括所创建的内核文件的大小、进程数据块的大小、Shell 进程创建文件的大小、内存锁住的大小、常驻内存集的大小、打开文件描述符的数量、分配堆栈的最大大小、CPU时间、单个用户的最大线程数、Shell 进程所能使用的最大虚拟内存等方面……显而易见，ulimit 对我们在 Linux 平台的应用和开发工作是非常实用的。
但是，对于Oracle SGA来说，我们要消除对它的限制。
例如：64位 Linux+Oracle 10g r2 设置 lock_sga 参数后，Oracle无法启动。Linux系统设置 ulimit -l unlimited 即可解决问题。

Oracle RAC Failover

Oracle RAC 高可用性的基础就是 Failover（故障转移）。它使得RAC集群中任何一个节点的故障都不会影响用户的使用，连接到故障节点的用户会被自动转移到健康节点，并且从用户感受而言是感受不到这种切换。
Oracle RAC（10g为例） 的 Failover 可以分为3种：

Client-Side Connect time Failover

即，如果用户端 tnsname 中配置了多个地址，用户发起连接请求时，会先尝试连接地址表中的第一个地址，如果这个连接尝试失败，则继续尝试使用第二个地址，直至连接成功或者遍历了所有的地址。
特点：只在建立连接那一时刻起作用，也就是说，Client-Side Connect time Failover 只在发起连接时才会去感知节点故障，如果节点没有反应，则自动尝试地址列表中的下一个地址。一旦连接建立之后，节点出现故障都不会做处理，从客户端的表现就是会话断开了，用户程序必须重新建立连接。并且，故障转移集群的配置是写死在客户端的。
很明显，一般不在生产环境下使用Client-Side Connect time Failover。

TAF - Transparent Application Failover

现在大部分应用程序都使用数据库连接池，即在启动时就建立若干到数据库的长连接，应用程序在其整个生命周期内重用这些连接。 而 Client-Side Connet Time Failover 的工作方式在这种情况下对应用程序的可用性没有太大帮助。
所以从 Oracle 8.1.5 版本引入了新的 Failover 机制——TAF。 所谓TAF，就是连接建立以后，应用系统运行过程中，如果某个实例发生故障，连接到这个实例上的用户会被自动迁移到其他的健康实例上。对于应用程序而言，这个迁移过程是透明的，不需要用户的介入，当然，这种透明要是有引导的，因为用户的未提交事务会回滚。相对于 Client-Side Connect Time Failover 的用户程序中断、抛出连接错误、重启应用程序，TAF 这种方式在提高 HA 上有很大的进步。
传统的 TAF 故障集群仍然需要在客户端配置，这在大量应用程序存在的情况下，对于服务端变化的修改成本是比较高的。
Service-Side TAF

Service-Side TAF 可以看作是 TAF 的一种变种，首先Service-Side TAF 也是 TAF，所有 TAF 的特点它都有，其次这种 TAF 是在服务器上配置的，而不像传统TAF是在客户端配置的。
Client-Side TAF 是在客户端修改 tnsnames.ora 文件来配置的，如果有很多客户端使用这个数据库，那么每次服务端调整都需要把所有的客户端应用程序更改一遍，既低效又容易出错。而 Service-Side TAF 通过服务端，在数据库里保存 FAIL_MODE 的配置，把所有的 TAF 配置保存在数据字典中，从而省去了客户端的配置工作，因此客户端的 tns 文件就不需要任何 TAF 的配置选项了。
当然 Service-Side TAF 的客户端需要指向一个RAC VPS，以保证对数据库集群的轮询。

Oracle DB Console

提供Web应用界面，实时监控 Oracle RAC 应用实例的方方面面，例如：服务器资源、性能表现以及执行计划、行级锁等运行细节。