一个电信运营商客户的核心交易系统，临时表空间大量被占用，临时表空间被撑到了600GB。这样的问题复杂吗？取决于很多因素，不过今天所要讲的案例，并不复杂，如果我们对临时表空间在何种情况下使用有足够了解。 首先，我们要去检查是什么会话占用了临时表空间，具体占用了多少，临时段的具体类型是什么。正如我们要想知道这个月的花费过大，去分析原因时就要去看是哪些开销过大、开销了多少金额、开销的用途等。

    在Oracle数据库的世界里，统计信息显得是那么重要，所以在升级系统时，我们考虑的一个重要问题是，在新的系统上采用何种统计信息收集策略，或者至少要保证上线的时候不能因为统计信息问题而导致系统性能异常。

    在Oracle数据库中，SQL解析有几种： 硬解析，过多的硬解析在系统中产生shared pool latch和library cache liatch争用，消耗过多的shared pool，使得系统不具有可伸缩性。 软解析，过多的软解析仍然可能会导致系统问题，特别是如果有少量的SQL高并发地进行软解析，会产生library cache latch或者是share方式的mutex争用。 软软解析，其实这也也属于软解析，与普通的软解析不同的是，软软解析的SQL会在会话的cached cursor中命中。 一次解析，多次执行，这是解析次数最少的方式，也是系统最具有可扩展性的方式。

    是不是我们的数据库，加上一套成熟可靠的备份软件（比如NBU、DP、TSM等），以及购置了可靠的大容量的带库就足够了？或者下面一个案例能够给我们一些启示。案例来自于一个老客户，一套重要系统的Oracle RAC数据库，由于硬件问题，一个包含关键业务数据的文件被离线（在归档模式下，写文件出错会导致文件被置为离线状态，而不是库宕掉）。在尝试recover datafile的时候，提示缺少一个归档日志。归档日志已经被备到带库上，本地磁盘上已经没有了这个归档日志文件。这套库是用TSM备份的，使用rman还原归档日志，称找不到这个归档日志。

    在编译《Oracle Core——Essential Internals for DBAs and Developers》这本书的第6章时，这章有提到进程在查找空闲缓冲区时，会从REPL_AUX链（即辅助LRU链）开始扫描，在扫描的过程中发现有dirty buffer，则会将该buffer从REPL_AUX链取下再链到WRITE_MAIN链上。这里提到的REPL_AUX链，主要用于链接那些能够马上复用的buffer（缓冲区），比如一致性读块，很少访问的块，大表全表扫描的块。而进程在查找可用的空闲或可复用的缓冲区时，会从REPL_AUX链开始查找，如果REPL_AUX链上如果有可用的缓冲区，那么进程就能很快获取到缓冲区以便用于存储从磁盘读入的块。那在REPL_AUX链上会不会有脏块呢？如果没有，那么进程在扫描REPL_AUX时会更快更简单。而答案是”在REPL_AUX链上是会存在脏块“的。

    有一条SQL，这个表上建billing_nbr和start_date的复合索引，这条SQL就能很快执行完（实际上最后也建了索引）。但是这里我们要探讨的是，为什么这么一条简单的SQL语句，执行了超过1小时还没有结果。MOBILE_CALL_1204_OLD这张表的大小约为12GB，以系统的IO能力，正常情况下不会执行这么长的时间。简单地看了一下，系统的CPU以及IO压力都不高。假设单进程全表扫描表，每秒扫描50MB大小（这实际上是一个很保守的扫描速度了），那么只需要245秒就可以完成扫描。

    网络防火墙会切断长时间空闲的TCP连接，这个空闲时间具体多长可以在防火墙内部进行设置。防火墙切断连接之后，会有下面的可能： 切断连接之前，连接对应的Oracle会话正在执行一个耗时特别长的SQL，比如存储过程而在此过程中没有任何数据输出到客户端，这样当SQL执行完成之后，向客户端返回结果时，如果TCP连接已经被防火墙中断，这时候显然会出现错误，连接中断，那么会话也就会中断。但是客户端还不知道，会一直处于等待服务器返回结果的状态。 切断连接之前，Oracle会话一直处于空闲状态，在防火墙中断之后，客户端向Oracle服务器提交SQL时，由于TCP连接已经中断，这时客户端侦测到连接中断，那么客户端就会报ORA-3113/ORA-3114这类错误，然后会话中断。但是在Oracle服务器端，会话一直在处于等待客户端消息的状态。

    客户一套运行在Oracle 10.2.0.5 RAC上的系统，间歇性地出现性能问题。其性能现象为前台反映性能缓慢，从系统上看CPU利用率大幅增加，load增加。这种性能问题通常在出现几分钟后自动恢复正常。

    提起Oracle数据库的Hint，几乎每一个DBA都知道这一强大工具。在Oracle中，Hint可以用来改变SQL的执行计划、固定SQL的执行计划。Oracle数据库内部的很多特性也依赖于Hint，比如Outline、Profile等。但是在日常工作中，很多开发人员或DBA，对Hint的使用仍然存在一些错误的方式。下面将列举主要的2种。（本文不讨论Hint的滥用即过度使用问题）。 1. NOLOGGING的不正确使用。很多人知道，在进行数据处理时，如果不产生日志或只产生少量的日志，将会有明显的、甚至是巨大的效率提升。

    ORA-01555错误是一种在Oracle数据库中很常见的错误。尤其在Oracle 8i及之前的版本最多。从9i开始的undo自动管理，至现在的10g、11g中的undo auto tuning，使得ORA-01555的错误越来越少。但是这个错误，仍然不可避免。而出现ORA-01555错误，通常有2种情况： SQL语句执行时间太长，或者UNDO表空间过小，或者事务量过大，或者过于频繁的提交，导致执行SQL过程中进行一致性读时，SQL执行后修改的前镜像（即UNDO数据）在UNDO表空间中已经被覆盖，不能构造一致性读块。 SQL语句执行过程中，访问到的块，在进行延迟块清除时，不能确定该块的事务提交时间与SQL执行开始时间的先后次序。 第1种情况，是最常见的。解决的办法无非就是增加UNDO表空间大小，优化出错的SQL，或者避免频繁地提交。而第2种情况则是比第1种情况少很多。

    ORA-04031这个错误，几乎每一个专业的DBA都遇到过。这是一个相当严重的错误，Oracle进程在向SGA申请内存时，如果申请失败，则会报这个错误。大部分情况下是在向SGA中的shared pool申请内存时失败，而少有向large pool等池中申请内存失败。