首页 > 数据库 > Oracle > 正文

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

2019-11-02 15:33:34
字体:
来源:转载
供稿:网友

 作为对象关系型数据库的杰出代表,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独有的特性已经将这种隐患降低到最低的程度,你大可放心你的php?/%CA%FD%BE%DD%BF%E2%CF%B5%CD%B3' target='_blank'>数据库系统的安全。

  ---- 我们安装的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的推荐)[IN

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表