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_PROCESSFROM 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、 主機-終端方式儘管可以便於資料維持，但主機-終端方式卻造成主機負荷太重，建議採用客戶-服務端方式建系統。 責任編輯 趙毅 zhaoyi#51cto.com TEL:（010）68476636-8001 給力(0票)動心(0票)廢話(0票)專業(0票)標題党(0票)路過(0票) 原文：Oracle8的不安全因素及幾點說明 返回網路安全首頁