作為對象關系型數據庫的傑出代表，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#’，但這並不是解決問題的根本方法，
