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

作為對象關系型數據庫的杰出代表，oracle無疑是最具實力的。無論是在數據庫的規(guī)模，多媒體數據類型的支持，sql操作復制的并行性還是在安全服務方面，oracle均比sybase、informix強許多，加上其最新版本oracle8.0.4更是增強了這方面的特性，而且還引入了一些新的特性，比如：數據分區(qū)(data partitioning)、對象關系技術(object relational technology)、唯索引表(index only tables)、連接管理器(connection manager)[net8特性]、高級隊列(advanced quening)等，所以有一種說法：oracle8是適用于如peoplesoft，sap和baan等封裝式應用系統(tǒng)最好的數據庫引擎。

---- 雖然oracle8有許多的優(yōu)點，但正如微軟的windows系統(tǒng)也會死機一樣，任何再好的軟件也有他的缺陷，一個優(yōu)秀的軟件不可能就是十全十美，他只是避免了大多數常見的或者可能被考慮到的問題，而一些不容易被發(fā)現卻非常致命的問題往往會被疏忽掉。oracle8也同樣存在著不安全的因素，許多正在想盡快升級到oracle8的oracle7.1、oracle7.2、oracle7.3用戶不能不考慮到這個因素。當然，這個不安全因素并不是一下子就發(fā)現的，而是我們在對一個非常龐大的表進行管理時發(fā)現的，這種隱患在使用oracle創(chuàng)建的小型或者中型數據庫中可能不會出現或根本無法發(fā)現，因為oracle8獨有的特性已經將這種隱患降低到最低的程度，你大可放心你的數據庫系統(tǒng)的安全。

問題
---- 我們安裝的oracle8數據庫是工作于主機-終端方式下的，系統(tǒng)主機采用的是四臺hp-9000小型機、1.5g的內存。建庫初期時設定的最大事務數是按oracle8的默認取值[這也是oracle7的默認取值]取的：塊值為2k，事務數為32（對于一個要處理非常龐大的數據庫時，一般我們設定的塊值要大于2k，至少應為4k或者16k，當然這還與主機的cpu能力和i/0能力值有關），并在建庫時沒有進行分區(qū)建表，這也許就為以后數據庫出問題留下了隱患。由于日訪問數據庫的用戶非常多，而且對同一表操作的用戶數量太大，致使那個表經常被鎖住，不斷有用戶抱怨他們進不了系統(tǒng)，主機發(fā)送的數據包太慢，經常報ora-600的錯誤。起初我們以為是系統(tǒng)網絡問題，但這種可能性比較小，因為我們發(fā)現系統(tǒng)cpu峰值經常在90%多，空閑很小，數據庫資源太忙，同時有十多個人鎖住一個大表進行操作，自然一部分用戶就無法進入系統(tǒng)，對此我們寫了如下的sql語句對鎖表用戶進行監(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;

---- 也許有的人會問為什么不用如下的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#’，但這并不是解決問題的根本方法，只能暫時緩解一下；另外我們還發(fā)現回滾段時常有“online”與“offline”的現象，于是我們又考慮是否是回滾段引起的問題：因為我們一但對大的回滾段進行操作，馬上就會有用戶反映無法進入。我們知道回退段的大小直接依賴于數據庫的活動狀態(tài)，而每一個extents都應具有相同的值（oracle的推薦）[initial extents的值可以從2k（32）、4k（69）、8k（142）、16k、32k等列表中選擇]，這將保證你刪掉一個區(qū)的時候，你可以重新使用它的空間而不會造成浪費，另外minextents應設為20，這將不會使回退段擴展另一個extent時用到正在被活動的事務所使用的空間，因而我們就可以據此來確定回退段大小，查出數據庫正常運行時所需回滾段的尺寸,為此我們重新設置了回退段的optimal參數[事實是optimal的值并不足引起數據庫出錯]，增大了optimal的值，使用命令set transaction use rollback segment為系統(tǒng)指定了一個大的回退段[注意optimal參數要足夠大以使oracle不需經常回縮和重新分配extents，如果設得小于最小覆蓋值，性能將由于額外的段重設置而下降，對于一個要執(zhí)行長查詢的系統(tǒng)，optimal應設成足夠大以避免ora-1555，“smapshot too old”的錯誤，而對于運行小的事務，optimal應設得小一些，使回退段足夠小以便放于內存中，這將提高系統(tǒng)性能。]，但我們發(fā)現這樣做后，ora-600的錯誤依然出現，而且鎖表越來越嚴重；我們又考慮暫時鎖住這個表，不讓用戶進入，先把用戶的鎖進程全部殺完再看，由于一開始就采用了主機-終端的工作方式，因而根本就無法清除得完，除非斷掉外部的所有網絡連接，但那樣無疑是重啟數據庫，最終我們選擇了重啟數據庫。
---- 重啟數據庫后系統(tǒng)資源一下子得以釋放，用戶明顯感覺速度上來了，能夠保證正常使用，就在我們認為系統(tǒng)可能是因為長期沒有down機，用戶登錄數過多造成數據庫死鎖的時候，一個非常嚴重的問題出現了，那個表中的一個數據無法進行update，一update就報oracle內部代碼錯誤，當時我們并沒在意，但是不久，我們又發(fā)現另一表中編號有重復的現象，根據oracle8的數據唯索引表性，這種現象應該根本不會存在，因為我們在這個表中只建立了唯一索引，于是我們電話詢問oracle公司的技術工程師，也許oracle的技術工程師們也是第一次遇到這種問題，他們的回答是數據字典太老，數據索引壞掉，建議重建索引，并把問題向亞太反映。在oracle公司的技術工程師的指導下，我們重建了該表，并重新建立了索引，在重建索引過程中，開始幾次都不成功，而且無法drop掉先前的表，經過仔細的查找，我們發(fā)現oracle8中的確有索引重復的現象，一個表中有兩條重復的索引，直接導致數據庫hang，不能訪問，但查看系統(tǒng)狀態(tài)、進程、listener卻都正常，從日志文件來看，文件過小（7mb），check point頻繁，影響到了系統(tǒng)的性能，通過以上調整后，數據庫問題暫時緩解了，可以做update，但是oracle的內部代碼錯誤卻依然存在，只是暫時還不會影響到我們對數據庫的使用，而回滾段開始出現“online rollback segment”的問題，更加令人不解的是數據庫居然出現了自動down機的現象，于是我們再次詢問oracle公司的技術工程師，他們的答復是oracle已經注意到了oracle8.0.4版本的一些問題，他們將會給數據庫打patch，希望能夠解決到這些問題，但是考慮到給數據庫打一個patch，將會把所有的數據都要export出來，這將是一個非常危險的操作，而且所有主機上的程序都要重新編譯一到，沒有一個星期的時間是無法做好的，而那是根本不可能的事情，因而我們現在還在等待oracle公司一個更好的解決辦法。

說明
---- 以上問題可能是oracle的一個bug，但任何軟件都有它不完善的一面，否則又何必出什么補丁了，有了補丁肯定會比沒有補丁強，但是我們在設計一個系統(tǒng)時也一定要考慮到以下的一些方面：
---- 1、 主機系統(tǒng)的cpu能力與i/0能力：hp偏重于i/0能力，cpu能力不強，你的數據庫就應該盡量避免讓cpu占用率太大；dec偏重于cpu能力，i/0能力不強，你的數據庫就可以考慮適當增大某些占用cpu參數的設置；sun的cpu能力與i/0能力差不多，你的數據庫就應該考慮平衡參數，過大過小都不好。

---- 2、 增大日志文件的size，至少一會低于8mb，日志文件過小會導致check point頻繁，從而影響到系統(tǒng)的性能。

---- 3、 回滾段最好保持一個比較合理的值，對一些較大的回滾段可適當增加minextents，并設置optimal，保證一般事物處理無需經常動態(tài)分配空間與及時回收空間。

---- 4、 要充分利用cpu系統(tǒng)資源及提高cpu的命中率，可適當增大log_simultaneous_copies,db_block_latches,db_writes的設置。

---- 5、 適當增加db_block_buffer與share_poll_size的size，以提高buffer值，增加內存，盡快提高buff及sql的命中率。

---- 6、 主機-終端方式盡管可以便于數據維持，但主機-終端方式卻造成主機負荷太重，建議采用客戶-服務端方式建系統(tǒng)。