作為對(duì)象關(guān)系型數(shù)據(jù)庫(kù)的杰出代表，Oracle無(wú)疑是最具實(shí)力的。無(wú)論是在數(shù)據(jù)庫(kù)的規(guī)模，多媒體數(shù)據(jù)類型的支持，SQL操作復(fù)制的并行性還是在安全服務(wù)方面，Oracle均比SYBASE、Informix強(qiáng)許多，加上其最新版本Oracle8.0.4更是增強(qiáng)了這方面的特性，而且還引入了一些新的特性，比如：數(shù)據(jù)分區(qū)(Data Partitioning)、對(duì)象關(guān)系技術(shù)(Object Relational Technology)、唯索引表(Index only tables)、連接管理器(Connection Manager)[NET8特性]、高級(jí)隊(duì)列(Advanced Quening)等，所以有一種說法：Oracle8是適用于如Peoplesoft，SAP和Baan等封裝式應(yīng)用系統(tǒng)最好的數(shù)據(jù)庫(kù)引擎。

　　---- 雖然Oracle8有許多的優(yōu)點(diǎn)，但正如微軟的WINDOWS系統(tǒng)也會(huì)死機(jī)一樣，任何再好的軟件也有他的缺陷，一個(gè)優(yōu)秀的軟件不可能就是十全十美，他只是避免了大多數(shù)常見的或者可能被考慮到的問題，而一些不容易被發(fā)現(xiàn)卻非常致命的問題往往會(huì)被疏忽掉。Oracle8也同樣存在著不安全的因素，許多正在想盡快升級(jí)到Oracle8的Oracle7.1、Oracle7.2、Oracle7.3用戶不能不考慮到這個(gè)因素。當(dāng)然，這個(gè)不安全因素并不是一下子就發(fā)現(xiàn)的，而是我們?cè)趯?duì)一個(gè)非常龐大的表進(jìn)行管理時(shí)發(fā)現(xiàn)的，這種隱患在使用Oracle創(chuàng)建的小型或者中型數(shù)據(jù)庫(kù)中可能不會(huì)出現(xiàn)或根本無(wú)法發(fā)現(xiàn)，因?yàn)镺racle8獨(dú)有的特性已經(jīng)將這種隱患降低到最低的程度，你大可放心你的php?/%CA%FD%BE%DD%BF%E2%CF%B5%CD%B3' target='_blank'>數(shù)據(jù)庫(kù)系統(tǒng)的安全。

　　---- 我們安裝的Oracle8數(shù)據(jù)庫(kù)是工作于主機(jī)-終端方式下的，系統(tǒng)主機(jī)采用的是四臺(tái)HP-9000小型機(jī)、1.5G的內(nèi)存。建庫(kù)初期時(shí)設(shè)定的最大事務(wù)數(shù)是按Oracle8的默認(rèn)取值[這也是Oracle7的默認(rèn)取值]取的：塊值為2K，事務(wù)數(shù)為32（對(duì)于一個(gè)要處理非常龐大的數(shù)據(jù)庫(kù)時(shí)，一般我們?cè)O(shè)定的塊值要大于2K，至少應(yīng)為4K或者16K，當(dāng)然這還與主機(jī)的CPU能力和I/0能力值有關(guān)），并在建庫(kù)時(shí)沒有進(jìn)行分區(qū)建表，這也許就為以后數(shù)據(jù)庫(kù)出問題留下了隱患。由于日訪問數(shù)據(jù)庫(kù)的用戶非常多，而且對(duì)同一表操作的用戶數(shù)量太大，致使那個(gè)表經(jīng)常被鎖住，不斷有用戶抱怨他們進(jìn)不了系統(tǒng)，主機(jī)發(fā)送的數(shù)據(jù)包太慢，經(jīng)常報(bào)ORA-600的錯(cuò)誤。起初我們以為是系統(tǒng)網(wǎng)絡(luò)問題，但這種可能性比較小，因?yàn)槲覀儼l(fā)現(xiàn)系統(tǒng)CPU峰值經(jīng)常在90%多，空閑很小，數(shù)據(jù)庫(kù)資源太忙，同時(shí)有十多個(gè)人鎖住一個(gè)大表進(jìn)行操作，自然一部分用戶就無(wú)法進(jìn)入系統(tǒng)，對(duì)此我們寫了如下的SQL語(yǔ)句對(duì)鎖表用戶進(jìn)行監(jiān)控：

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;

　　---- 也許有的人會(huì)問為什么不用如下的SQL語(yǔ)句進(jìn)行查詢：

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;

　　---- 以上兩個(gè)SQL語(yǔ)句都會(huì)查詢返回當(dāng)前被鎖住的用戶列表，但第二個(gè)SQL語(yǔ)句由于加入了sql_text從而使這個(gè)查詢變得非常的慢長(zhǎng)，特別是在有許多用戶同時(shí)對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作時(shí)，建議不用，第一個(gè)SQL 語(yǔ)句會(huì)在很短的時(shí)間內(nèi)查詢出是誰(shuí)在鎖表，從而有利于對(duì)數(shù)據(jù)庫(kù)的管理，一但有用戶進(jìn)入不了，我們就馬上殺死其鎖進(jìn)程[SID，SERIAL#]，SQL語(yǔ)句如下：ALTER SYSTEM KILL SESSION ‘SID，SERIAL#’，但這并不是解決問題的根本方法，只能暫時(shí)緩解一下；另外我們還發(fā)現(xiàn)回滾段時(shí)常有“online”與“offline”的現(xiàn)象，于是我們又考慮是否是回滾段引起的問題：因?yàn)槲覀円坏珜?duì)大的回滾段進(jìn)行操作，馬上就會(huì)有用戶反映無(wú)法進(jìn)入。我們知道回退段的大小直接依賴于數(shù)據(jù)庫(kù)的活動(dòng)狀態(tài)，而每一個(gè)EXTENTS都應(yīng)具有相同的值（Oracle的推薦）[IN