Oracle8的不安全因素及几点说明

oracle8的不安全因素及几点说明

作为对象关系型数据库的杰出代表，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语句对锁表用户进行监控：
select object_id,session_id,serial#,
oracle_usename,os_user_name,s_process
from v$locked_object 1,
v$session s where 1.session_id=s.sid;

---- 也许有的人会问为什么不用如下的sql语句进行查询：
select a.username,a.sid,a.serial#,b.id1,
c.sql_text from v$session a,
v$lock b,v$sqltext c where a.lockwait=b.kaddr and
a. sql_address=c.address and a.sql_hash_value=c.hash_value;

---- 以上两个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、 主机-终端方式尽管可以便于数据维持，但主机-终端方式却造成主机负荷太重，建议采用客户-服务端方式建系统。