歡迎您光臨本站 註冊首頁

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

←手機掃碼閱讀     火星人 @ 2014-03-12 , reply:0
  作為對象關係型資料庫的傑出代表,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公司一個更好的解決辦法。

說明
---- 以上問題可能是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、 主機-終端方式儘管可以便於數據維持,但主機-終端方式卻造成主機負荷太重,建議採用客戶-服務端方式建系統。


[火星人 ] Oracle8的不安全因素及幾點說明已經有645次圍觀

http://coctec.com/docs/linux/show-post-74195.html