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