作为对象关系型数据库的杰出代表，Oracle无疑是最具实力的。无论是在数据库的规模，多媒体数据类型的支持，SQL操作复制的并行性还是在安全服务方面，Oracle均比SYBASE、Informix强许多，加上其最新版本Oracle8.0.4更是增强了这方面的特性，而且还引入了一些新的特性，比如：数据分区(Data Partitioning)、对象关系技术(Object Relational Technology)、唯索引表(Index only tables)、连接管理器(Connection Manager)[NET8特性]、高级队列(Advanced Quening)等，所以有一种说法：Oracle8是适用于如Peoplesoft，SAP和Baan等封装式应用系统最好的数据库引擎。
虽然Oracle8有许多的优点，但正如微软的WINDOWS系统也会死机一样，任何再好的软件也有他的缺陷，一个优秀的软件不可能就是十全十美，他只是避免了大多数常见的或者可能被考虑到的问题，而一些不容易被发现却非常致命的问题往往会被疏忽掉。Oracle8也同样存在着不安全的因素，许多正在想尽快升级到Oracle8的Oracle7.1、Oracle7.2、Oracle7.3用户不能不考虑到这个因素。当然，这个不安全因素并不是一下子就发现的，而是我们在对一个非常庞大的表进行管理时发现的，这种隐患在使用Oracle创建的小型或者中型数据库中可能不会出现或根本无法发现，因为Oracle8独有的特性已经将这种隐患降低到最低的程度，你大可放心你的数据库系统的安全。
问题
我们安装的Oracle8数据库是工作于主机-终端方式下的，系统主机采用的是四台HP-9000小型机、1.5G的内存。建库初期时设定的最大事务数是按Oracle8的默认取值[这也是Oracle7的默认取值]取的：块值为2K，事务数为32（对于一个要处理非常庞大的数据库时，一般我们设定的块值要大于2K，至少应为4K或者16K，当然这还与主机的CPU能力和I/0能力值有关），并在建库时没有进行分区建表，这也许就为以后数据库出问题留下了隐患。由于日访问数据库的用户非常多，而且对同一表操作的用户数量太大，致使那个表经常被锁住，不断有用户抱怨他们进不了系统，主机发送的数据包太慢，经常报ORA-600的错误。起初我们以为是系统网络问题，但这种可能性比较小，因为我们发现系统CPU峰值经常在90%多，空闲很小，数据库资源太忙，同时有十多个人锁住一个大表进行操作，自然一部分用户就无法进入系统，对此我们写了如下的SQL语句对锁表用户进行监控：
|
也许有的人会问为什么不用如下的SQL语句进行查询：
|
以上两个SQL语句都会查询返回当前被锁住的用户列表，但第二个SQL语句由于加入了sql_text从而使这个查询变得非常的慢长，特别是在有许多用户同时对数据库进行操作时，建议不用，第一个SQL 语句会在很短的时间内查询出是谁在锁表，从而有利于对数据库的管理，一但有用户进入不了，我们就马上杀死其锁进程[SID，SERIAL#]，SQL语句如下：ALTER SYSTEM KILL SESSION ‘SID，SERIAL#’，但这并不是解决问题的根本方法，只能暂时缓解一下；另外我们还发现回滚段时常有“online”与“offline”的现象，于是我们又考虑是否是回滚段引起的问题：因为我们一但对大的回滚段进行操作，马上就会有用户反映无法进入。我们知道回退段的大小直接依赖于数据库的活动状态，而每一个EXTENTS都应具有相同的值（Oracle的推荐）[INITIAL EXTENTS的值可以从2K（32）、4K（69）、8K（142）、16K、32K等列表中选择]，这将保证你删掉一个区的时候，你可以重新使用它的空间而不会造成浪费，另外MINEXTENTS应设为20，这将不会使回退段扩展另一个EXTENT时用到正在被活动的事务所使用的空间，因而我们就可以据此来确定回退段大小，查出数据库正常运行时所需回滚段的尺寸,为此我们重新设置了回退段的OPTIMAL参数[事实是OPTIMAL的值并不足引起数据库出错]，增大了OPTIMAL的值，使用命令SET TRANSACTION USE ROLLBACK SEGMENT为系统指定了一个大的回退段[注意OPTIMAL参数要足够大以使ORACLE不需经常回缩和重新分配EXTENTS，如果设得小于最小覆盖值，性能将由于额外的段重设置而下降，对于一个要执行长查询的系统，OPTIMAL应设成足够大以避免ORA-1555，“Smapshot too old”的错误，而对于运行小的事务，OPTIMAL应设得小一些，使回退段足够小以便放于内存中，这将提高系统性能。]，但我们发现这样做后，ORA-600的错误依然出现，而且锁表越来越严重；我们又考虑暂时锁住这个表，不让用户进入，先把用户的锁进程全部杀完再看，由于一开始就采用了主机-终端的工作方式，因而根本就无法清除得完，除非断掉外部的所有网络连接，但那样无疑是重启数据库，最终我们选择了重启数据库。
重启数据库后系统资源一下子得以释放，用户明显感觉速度上来了，能够保证正常使用，就在我们认为系统可能是因为长期没有DOWN机，用户登录数过多造成数据库死锁的时候，一个非常严重的问题出现了，那个表中的一个数据无法进行UPDATE，一UPDATE就报ORACLE内部代码错误，当时我们并没在意，但是不久，我们又发现另一表中编号有重复的现象，根据ORACLE8的数据唯索引表性，这种现象应该根本不会存在，因为我们在这个表中只建立了唯一索引，于是我们电话询问ORACLE公司的技术工程师，也许ORACLE的技术工程师们也是第一次遇到这种问题，他们的回答是数据字典太老，数据索引坏掉，建议重建索引，并把问题向亚太反映。在ORACLE公司的技术工程师的指导下，我们重建了该表，并重新建立了索引，在重建索引过程中，开始几次都不成功，而且无法DROP掉先前的表，经过仔细的查找，我们发现ORACLE8中的确有索引重复的现象，一个表中有两条重复的索引，直接导致数据库HANG，不能访问，但查看系统状态、进程、LISTENER却都正常，从日志文件来看，文件过小（7MB），CHECK POINT频繁，影响到了系统的性能，通过以上调整后，数据库问题暂时缓解了，可以做UPDATE，但是ORACLE的内部代码错误却依然存在，只是暂时还不会影响到我们对数据库的使用，而回滚段开始出现“online rollback segment”的问题，更加令人不解的是数据库居然出现了自动DOWN机的现象，于是我们再次询问ORACLE公司的技术工程师，他们的答复是ORACLE已经注意到了ORACLE8.0.4版本的一些问题，他们将会给数据库打PATCH，希望能够解决到这些问题，但是考虑到给数据库打一个PATCH，将会把所有的数据都要EXPORT出来，这将是一个非常危险的操作，而且所有主机上的程序都要重新编译一到，没有一个星期的时间是无法做好的，而那是根本不可能的事情，因而我们现在还在等待ORACLE公司一个更好的解决办法。
说明
以上问题可能是ORACLE的一个BUG，但任何软件都有它不完善的一面，否则又何必出什么补丁了，有了补丁肯定会比没有补丁强，但是我们在设计一个系统时也一定要考虑到以下的一些方面：
1、 主机系统的CPU能力与I/0能力：HP偏重于I/0能力，CPU能力不强，你的数据库就应该尽量避免让CPU占用率太大；DEC偏重于CPU能力，I/0能力不强，你的数据库就可以考虑适当增大某些占用CPU参数的设置；SUN的CPU能力与I/0能力差不多，你的数据库就应该考虑平衡参数，过大过小都不好。
2、 增大日志文件的SIZE，至少一会低于8MB，日志文件过小会导致CHECK POINT频繁，从而影响到系统的性能。
3、 回滚段最好保持一个比较合理的值，对一些较大的回滚段可适当增加MINEXTENTS，并设置OPTIMAL，保证一般事物处理无需经常动态分配空间与及时回收空间。
4、 要充分利用CPU系统资源及提高CPU的命中率，可适当增大log_simultaneous_copies,db_block_latches,db_writes的设置。
5、 适当增加db_block_buffer与share_poll_size的SIZE，以提高BUFFER值，增加内存，尽快提高BUFF及SQL的命中率。
6、 主机-终端方式尽管可以便于数据维持，但主机-终端方式却造成主机负荷太重，建议采用客户-服务端方式建系统。
