程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> Oracle數據庫 >> 關於Oracle數據庫 >> Oracle的不安全因素及幾點說明

Oracle的不安全因素及幾點說明

編輯:關於Oracle數據庫

     作為對象關系型數據庫的傑出代表,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公司一個更好的解決辦法。

    1. 上一頁:
    2. 下一頁:
    Copyright © 程式師世界 All Rights Reserved