?
本文檔使用 PHP中文網(wǎng)手冊(cè) 發(fā)布
Oracle8的不安全因素及幾點(diǎn)說(shuō)明 |
|
作為對(duì)象關(guān)系型數(shù)據(jù)庫(kù)的杰出代表，Oracle無(wú)疑是最具實(shí)力的。無(wú)論是在數(shù)據(jù)庫(kù)的規(guī)模，多媒體數(shù)據(jù)類(lèi)型的支持，SQL操作復(fù)制的并行性還是在安全服務(wù)方面，Oracle均比SYBASE、Informix強(qiáng)許多，加上其最新版本Oracle8.0.4更是增強(qiáng)了這方面的特性，而且還引入了一些新的特性，比如：數(shù)據(jù)分區(qū)(Data Partitioning)、對(duì)象關(guān)系技術(shù)(Object Relational Technology)、唯索引表(Index only tables)、連接管理器(Connection Manager)[NET8特性]、高級(jí)隊(duì)列(Advanced Quening)等，所以有一種說(shuō)法：Oracle8是適用于如Peoplesoft，SAP和Baan等封裝式應(yīng)用系統(tǒng)最好的數(shù)據(jù)庫(kù)引擎。 雖然Oracle8有許多的優(yōu)點(diǎn)，但正如微軟的WINDOWS系統(tǒng)也會(huì)死機(jī)一樣，任何再好的軟件也有他的缺陷，一個(gè)優(yōu)秀的軟件不可能就是十全十美，他只是避免了大多數(shù)常見(jiàn)的或者可能被考慮到的問(wèn)題，而一些不容易被發(fā)現(xiàn)卻非常致命的問(wèn)題往往會(huì)被疏忽掉。Oracle8也同樣存在著不安全的因素，許多正在想盡快升級(jí)到Oracle8的Oracle7.1、Oracle7.2、Oracle7.3用戶(hù)不能不考慮到這個(gè)因素。當(dāng)然，這個(gè)不安全因素并不是一下子就發(fā)現(xiàn)的，而是我們?cè)趯?duì)一個(gè)非常龐大的表進(jìn)行管理時(shí)發(fā)現(xiàn)的，這種隱患在使用Oracle創(chuàng)建的小型或者中型數(shù)據(jù)庫(kù)中可能不會(huì)出現(xiàn)或根本無(wú)法發(fā)現(xiàn)，因?yàn)镺racle8獨(dú)有的特性已經(jīng)將這種隱患降低到最低的程度，你大可放心你的數(shù)據(jù)庫(kù)系統(tǒng)的安全。
我們安裝的Oracle8數(shù)據(jù)庫(kù)是工作于主機(jī)-終端方式下的，系統(tǒng)主機(jī)采用的是四臺(tái)HP-9000小型機(jī)、1.5G的內(nèi)存。建庫(kù)初期時(shí)設(shè)定的最大事務(wù)數(shù)是按Oracle8的默認(rèn)取值[這也是Oracle7的默認(rèn)取值]取的：塊值為2K，事務(wù)數(shù)為32（對(duì)于一個(gè)要處理非常龐大的數(shù)據(jù)庫(kù)時(shí)，一般我們?cè)O(shè)定的塊值要大于2K，至少應(yīng)為4K或者16K，當(dāng)然這還與主機(jī)的CPU能力和I/0能力值有關(guān)），并在建庫(kù)時(shí)沒(méi)有進(jìn)行分區(qū)建表，這也許就為以后數(shù)據(jù)庫(kù)出問(wèn)題留下了隱患。由于日訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的用戶(hù)非常多，而且對(duì)同一表操作的用戶(hù)數(shù)量太大，致使那個(gè)表經(jīng)常被鎖住，不斷有用戶(hù)抱怨他們進(jìn)不了系統(tǒng)，主機(jī)發(fā)送的數(shù)據(jù)包太慢，經(jīng)常報(bào)ORA-600的錯(cuò)誤。起初我們以為是系統(tǒng)網(wǎng)絡(luò)問(wèn)題，但這種可能性比較小，因?yàn)槲覀儼l(fā)現(xiàn)系統(tǒng)CPU峰值經(jīng)常在90%多，空閑很小，數(shù)據(jù)庫(kù)資源太忙，同時(shí)有十多個(gè)人鎖住一個(gè)大表進(jìn)行操作，自然一部分用戶(hù)就無(wú)法進(jìn)入系統(tǒng)，對(duì)此我們寫(xiě)了如下的SQL語(yǔ)句對(duì)鎖表用戶(hù)進(jìn)行監(jiān)控：
SELECT OBJECT_ID,SESSION_ID,SERIAL#, 也許有的人會(huì)問(wèn)為什么不用如下的SQL語(yǔ)句進(jìn)行查詢(xún)： SELECT a.username,a.sid,a.serial#,b.id1, 以上兩個(gè)SQL語(yǔ)句都會(huì)查詢(xún)返回當(dāng)前被鎖住的用戶(hù)列表，但第二個(gè)SQL語(yǔ)句由于加入了sql_text從而使這個(gè)查詢(xún)變得非常的慢長(zhǎng)，特別是在有許多用戶(hù)同時(shí)對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作時(shí)，建議不用，第一個(gè)SQL 語(yǔ)句會(huì)在很短的時(shí)間內(nèi)查詢(xún)出是誰(shuí)在鎖表，從而有利于對(duì)數(shù)據(jù)庫(kù)的管理，一但有用戶(hù)進(jìn)入不了，我們就馬上殺死其鎖進(jìn)程[SID，SERIAL#]，SQL語(yǔ)句如下：ALTER SYSTEM KILL SESSION ‘SID，SERIAL#’，但這并不是解決問(wèn)題的根本方法，只能暫時(shí)緩解一下；另外我們還發(fā)現(xiàn)回滾段時(shí)常有“online”與“offline”的現(xiàn)象，于是我們又考慮是否是回滾段引起的問(wèn)題：因?yàn)槲覀円坏珜?duì)大的回滾段進(jìn)行操作，馬上就會(huì)有用戶(hù)反映無(wú)法進(jìn)入。我們知道回退段的大小直接依賴(lài)于數(shù)據(jù)庫(kù)的活動(dòng)狀態(tài)，而每一個(gè)EXTENTS都應(yīng)具有相同的值（Oracle的推薦）[INITIAL EXTENTS的值可以從2K（32）、4K（69）、8K（142）、16K、32K等列表中選擇]，這將保證你刪掉一個(gè)區(qū)的時(shí)候，你可以重新使用它的空間而不會(huì)造成浪費(fèi)，另外MINEXTENTS應(yīng)設(shè)為20，這將不會(huì)使回退段擴(kuò)展另一個(gè)EXTENT時(shí)用到正在被活動(dòng)的事務(wù)所使用的空間，因而我們就可以據(jù)此來(lái)確定回退段大小，查出數(shù)據(jù)庫(kù)正常運(yùn)行時(shí)所需回滾段的尺寸,為此我們重新設(shè)置了回退段的OPTIMAL參數(shù)[事實(shí)是OPTIMAL的值并不足引起數(shù)據(jù)庫(kù)出錯(cuò)]，增大了OPTIMAL的值，使用命令SET TRANSACTION USE ROLLBACK SEGMENT為系統(tǒng)指定了一個(gè)大的回退段[注意OPTIMAL參數(shù)要足夠大以使ORACLE不需經(jīng)常回縮和重新分配EXTENTS，如果設(shè)得小于最小覆蓋值，性能將由于額外的段重設(shè)置而下降，對(duì)于一個(gè)要執(zhí)行長(zhǎng)查詢(xún)的系統(tǒng)，OPTIMAL應(yīng)設(shè)成足夠大以避免ORA-1555，“Smapshot too old”的錯(cuò)誤，而對(duì)于運(yùn)行小的事務(wù)，OPTIMAL應(yīng)設(shè)得小一些，使回退段足夠小以便放于內(nèi)存中，這將提高系統(tǒng)性能。]，但我們發(fā)現(xiàn)這樣做后，ORA-600的錯(cuò)誤依然出現(xiàn)，而且鎖表越來(lái)越嚴(yán)重；我們又考慮暫時(shí)鎖住這個(gè)表，不讓用戶(hù)進(jìn)入，先把用戶(hù)的鎖進(jìn)程全部殺完再看，由于一開(kāi)始就采用了主機(jī)-終端的工作方式，因而根本就無(wú)法清除得完，除非斷掉外部的所有網(wǎng)絡(luò)連接，但那樣無(wú)疑是重啟數(shù)據(jù)庫(kù)，最終我們選擇了重啟數(shù)據(jù)庫(kù)。 重啟數(shù)據(jù)庫(kù)后系統(tǒng)資源一下子得以釋放，用戶(hù)明顯感覺(jué)速度上來(lái)了，能夠保證正常使用，就在我們認(rèn)為系統(tǒng)可能是因?yàn)殚L(zhǎng)期沒(méi)有DOWN機(jī)，用戶(hù)登錄數(shù)過(guò)多造成數(shù)據(jù)庫(kù)死鎖的時(shí)候，一個(gè)非常嚴(yán)重的問(wèn)題出現(xiàn)了，那個(gè)表中的一個(gè)數(shù)據(jù)無(wú)法進(jìn)行UPDATE，一UPDATE就報(bào)ORACLE內(nèi)部代碼錯(cuò)誤，當(dāng)時(shí)我們并沒(méi)在意，但是不久，我們又發(fā)現(xiàn)另一表中編號(hào)有重復(fù)的現(xiàn)象，根據(jù)ORACLE8的數(shù)據(jù)唯索引表性，這種現(xiàn)象應(yīng)該根本不會(huì)存在，因?yàn)槲覀冊(cè)谶@個(gè)表中只建立了唯一索引，于是我們電話(huà)詢(xún)問(wèn)ORACLE公司的技術(shù)工程師，也許ORACLE的技術(shù)工程師們也是第一次遇到這種問(wèn)題，他們的回答是數(shù)據(jù)字典太老，數(shù)據(jù)索引壞掉，建議重建索引，并把問(wèn)題向亞太反映。在ORACLE公司的技術(shù)工程師的指導(dǎo)下，我們重建了該表，并重新建立了索引，在重建索引過(guò)程中，開(kāi)始幾次都不成功，而且無(wú)法DROP掉先前的表，經(jīng)過(guò)仔細(xì)的查找，我們發(fā)現(xiàn)ORACLE8中的確有索引重復(fù)的現(xiàn)象，一個(gè)表中有兩條重復(fù)的索引，直接導(dǎo)致數(shù)據(jù)庫(kù)HANG，不能訪(fǎng)問(wèn)，但查看系統(tǒng)狀態(tài)、進(jìn)程、LISTENER卻都正常，從日志文件來(lái)看，文件過(guò)?。?MB），CHECK POINT頻繁，影響到了系統(tǒng)的性能，通過(guò)以上調(diào)整后，數(shù)據(jù)庫(kù)問(wèn)題暫時(shí)緩解了，可以做UPDATE，但是ORACLE的內(nèi)部代碼錯(cuò)誤卻依然存在，只是暫時(shí)還不會(huì)影響到我們對(duì)數(shù)據(jù)庫(kù)的使用，而回滾段開(kāi)始出現(xiàn)“online rollback segment”的問(wèn)題，更加令人不解的是數(shù)據(jù)庫(kù)居然出現(xiàn)了自動(dòng)DOWN機(jī)的現(xiàn)象，于是我們?cè)俅卧?xún)問(wèn)ORACLE公司的技術(shù)工程師，他們的答復(fù)是ORACLE已經(jīng)注意到了ORACLE8.0.4版本的一些問(wèn)題，他們將會(huì)給數(shù)據(jù)庫(kù)打PATCH，希望能夠解決到這些問(wèn)題，但是考慮到給數(shù)據(jù)庫(kù)打一個(gè)PATCH，將會(huì)把所有的數(shù)據(jù)都要EXPORT出來(lái)，這將是一個(gè)非常危險(xiǎn)的操作，而且所有主機(jī)上的程序都要重新編譯一到，沒(méi)有一個(gè)星期的時(shí)間是無(wú)法做好的，而那是根本不可能的事情，因而我們現(xiàn)在還在等待ORACLE公司一個(gè)更好的解決辦法。
以上問(wèn)題可能是ORACLE的一個(gè)BUG，但任何軟件都有它不完善的一面，否則又何必出什么補(bǔ)丁了，有了補(bǔ)丁肯定會(huì)比沒(méi)有補(bǔ)丁強(qiáng)，但是我們?cè)谠O(shè)計(jì)一個(gè)系統(tǒng)時(shí)也一定要考慮到以下的一些方面： 1、 主機(jī)系統(tǒng)的CPU能力與I/0能力：HP偏重于I/0能力，CPU能力不強(qiáng)，你的數(shù)據(jù)庫(kù)就應(yīng)該盡量避免讓CPU占用率太大；DEC偏重于CPU能力，I/0能力不強(qiáng)，你的數(shù)據(jù)庫(kù)就可以考慮適當(dāng)增大某些占用CPU參數(shù)的設(shè)置；SUN的CPU能力與I/0能力差不多，你的數(shù)據(jù)庫(kù)就應(yīng)該考慮平衡參數(shù)，過(guò)大過(guò)小都不好。 2、 增大日志文件的SIZE，至少不會(huì)低于8MB，日志文件過(guò)小會(huì)導(dǎo)致CHECK POINT頻繁，從而影響到系統(tǒng)的性能。 3、 回滾段最好保持一個(gè)比較合理的值，對(duì)一些較大的回滾段可適當(dāng)增加MINEXTENTS，并設(shè)置OPTIMAL，保證一般事物處理無(wú)需經(jīng)常動(dòng)態(tài)分配空間與及時(shí)回收空間。 4、 要充分利用CPU系統(tǒng)資源及提高CPU的命中率，可適當(dāng)增大log_simultaneous_copies,db_block_latches,db_writes的設(shè)置。 5、 適當(dāng)增加db_block_buffera與share_pool_size的SIZE，以提高BUFFER值，增加內(nèi)存，盡快提高BUFF及SQL的命中率。 6、 主機(jī)-終端方式盡管可以便于數(shù)據(jù)維持，但主機(jī)-終端方式卻造成主機(jī)負(fù)荷太重，建議采用客戶(hù)-服務(wù)端方式建系統(tǒng)。 |