oracle7技術(shù)與技巧數(shù)據(jù)庫高可用第一集

操作系統(tǒng)（OS）是計算機上所運行的最復雜軟件之一。由于操作系統(tǒng)與硬件之間的相互關(guān)系最為緊密，因此它也是系統(tǒng)可用性的關(guān)鍵組件。包括數(shù)據(jù)庫在內(nèi)的所有應(yīng)用程序都極大地依賴于操作系統(tǒng)所提供的服務(wù)。一個存在許多問題的操作系統(tǒng)可能會使得任何系統(tǒng)崩潰。如果不考慮操作系統(tǒng)的配置問題，那么任何試圖獲取高可用性的努力都是徒勞的。 小，每種硬件系統(tǒng)都有自己的操作系統(tǒng)。在這里，筆者不可能對它們一一列舉。雖然筆者也曾經(jīng)試圖將它們列舉出來，但實踐證明這幾乎不可能的。根據(jù)筆者的個人經(jīng)驗，UNIX似乎是運行于中大型計算機系統(tǒng)中大多數(shù)24×7站點所選擇的操作系統(tǒng)。因此，本章將主要考慮UNIXWindowsNT4.0說明。在進行深入的討論之前，筆者將列出UNIX上的OracleServer體系結(jié)構(gòu)與WindowsNT上的OracleServerUNIX上的Oracle與WindowsNT上的在UNIX環(huán)境下運行的Oracle系統(tǒng)與在WindowsNT環(huán)境下運行的Oracle系統(tǒng)之間的基本不進程結(jié)構(gòu) 一個UNIX環(huán)境下的Oracle實例中包含有多個背景進程與前景進程，而WindowsNT環(huán)境下的Oracle實例則是由多個線程所組成的單個進程。這樣，在WindowsNT、DBWR、LGW、ARCH等等中，Oracle7x進或Oracle8x進（這里7x與8x都是指Oracle版本號）中的所有內(nèi)部線程都不能從NTTaskManager中看到。在WindowsNT下，動態(tài)視圖$bgprocess必須被查詢之后才能確定每個后備進程的存在性，而在UNIX下，ps命令可以列出所有的后備進程。此外，雖然在WindowsNT下Oracle（Multi-ThreadedServer，多線程服務(wù)器）WindowsNT下的Oracle中配置多個調(diào)度程序與共享服務(wù)器。在進程內(nèi)，每個用戶會話都是的，并且能夠產(chǎn)生一個獨立型OP數(shù)據(jù)庫，可擴展性成為WindowsNT操作系統(tǒng)的一個問題，因為在這種操作系統(tǒng)中任何進程的最大內(nèi)存地址空間被限制為2GB。這就意味著Oracle內(nèi)核與所有連接的用戶會話都被限制為這個大小。這在UNIX系統(tǒng)中不會導致任何問題，因為其中的每個進程都是單獨的并且有自己獨立的進程空間。文件系統(tǒng)選項在WindowsNT環(huán)境下，只有兩個實際可用的文件系統(tǒng)選項：raw與NTFS（由于安全性的問題，大多數(shù)系統(tǒng)中都不能采用FAT方法。在UNIX環(huán)境下，可WindowsNT4.0環(huán)境下，初始化參數(shù)DB_BLOCK_SIZE8KB，而在大多數(shù)UNIX版本中，DB_BLOCK_SIZE的最大值一般都比較高。NT在這方面的限熱備份有些WindowsNT4.0命令例如ntbackup）會對開放式數(shù)據(jù)庫的文件備份動作。因此，必須使用Oracle所提供的應(yīng)用程序ocopyocopy并不支持直接向磁帶進行備份。所有的文件首先需要拷貝到硬盤上，然后通過indowNT命令傳輸?shù)酱艓е小τ赩LDB站點，這將會導致非常嚴重的管理，因為對于某些巨大的表空間，可能沒有足夠的硬盤空間可用于進行聯(lián)機備份（對于整個數(shù)據(jù)庫的備份，這個問題更為突出。UNIXUNIX的某個UNIX內(nèi)核進行優(yōu)化，那么其他的優(yōu)化努力基本上是白費的。數(shù)據(jù)庫實例使用共享內(nèi)存與信號燈，可以在內(nèi)核上調(diào)整數(shù)據(jù)庫實例，以便達到合適的實例大小。內(nèi)核位于UNIX操作系統(tǒng)的部分，它能夠執(zhí)行所有的基本任務(wù)，例如內(nèi)存管理、進程管理與I/O管理，這些基本任務(wù)使操作系統(tǒng)完成自己的功能。內(nèi)核又是操作系統(tǒng)的骨架，在這個骨架上還有其他的所有外部層次。內(nèi)核有一些非常獨特的特點，大多數(shù)內(nèi)核都是永久地與物理內(nèi)存聯(lián)系在一起的。也就是說，它們不能被對換或者被換頁。因此，應(yīng)該將內(nèi)核進行盡量濃縮的配置。由于UNIX系統(tǒng)安裝的復雜性，許多系統(tǒng)管理員都不考慮過多的配置問題，而是使用缺省方式進行UNIX系統(tǒng)的安裝。這樣的安裝方式所得到的內(nèi)核一般都比較大，需要占用較多的物理內(nèi)存。事實上，最好能夠取消那些不需要的內(nèi)核功能，使得內(nèi)核能夠盡可能精簡。特別是對于那些感到內(nèi)存資源不足的站點，這也不愧為獲取更大內(nèi)存的一種好方法。VLDB，那么就有可能需要支持大量的用戶與程序。這樣，由于缺省內(nèi)存安裝方式的限制，使得它可能會阻礙系統(tǒng)的平滑操作（讀者“umusersreached。因此，如果希望支持的用戶與進程，或者支持的文件能夠同時打開，那么就必須修改內(nèi)核的配置。raw設(shè)備而不是使用文件（本章后面將詳細討論rawraw設(shè)備上之后，應(yīng)該減小缺省文件系統(tǒng)緩沖器的大小。在使用raw設(shè)備時，文件系統(tǒng)緩沖器的使用是非常小的?？梢栽诓挥绊懭魏涡阅艿那闆r下，將緩沖器的大小截取為其初始大小的四分之一。這種內(nèi)存截取動作也需要進行內(nèi)核的自定義。大多數(shù)Oracle站點所碰到的真正是如何在所有與數(shù)據(jù)庫相關(guān)的資源增加的情況下取消那些不需要的操作系統(tǒng)選項。大多數(shù)內(nèi)核都能夠支持大量的設(shè)備驅(qū)動器，因此擁有很大的內(nèi)核表。通過向硬件提供商進行咨詢或者在系統(tǒng)啟動時查看屏幕上的消息的方法，可以非常容易地知道內(nèi)核所使用的總物理內(nèi)存的大小。系統(tǒng)啟動時屏幕上的消息中包含有關(guān)于真實內(nèi)存（總RAM）與可用內(nèi)存的消息。這兩者之間的差大約就是操作系統(tǒng)內(nèi)核的大小。如果這種差看上去很大，那么就應(yīng)該考慮對內(nèi)核進行精簡。（SunSolaris上的/var/adm/messages。這些文件能夠捕獲許多關(guān)于系統(tǒng)啟動的信息，其中就包括真實內(nèi)存大小與可用內(nèi)存大小。任何內(nèi)核的定制都需要進行系統(tǒng)重新啟動，因此，這些任務(wù)只能夠在初始配置過程中或者利用后備服務(wù)器處于活躍狀態(tài)時才能夠進行。最好是在應(yīng)用程序被部署之前將所有的內(nèi)核進行所需的改變。大多數(shù)版本的UNIX都有一個菜單驅(qū)動的內(nèi)核配置工具（例如HP-UX上的SAM與IBMAIX上的SMIT4-1中列出了與數(shù)據(jù)庫相關(guān)的一些內(nèi)核參數(shù)。在后面的技巧中將對它們進行詳細的描述，大多數(shù)內(nèi)核參數(shù)都是用以下列格式在配置文件中以單獨命令行序列的方式給出的：kernel-parameter- val根據(jù)UNIX版本的不同，這些內(nèi)核配置文件名與文件位置也不相同。例如，在Sun中，內(nèi)核文件是/etc/system在改變?nèi)魏蝺?nèi)核參數(shù)之前，應(yīng)該確保有內(nèi)核工作版本的可靠備份。這里所謂的工作版本bug的補丁程序。在保存任何修改之前，應(yīng)該確保自己能夠非常容易地回到改變之前的狀態(tài)。若有可能，應(yīng)該在具有相同配置的非產(chǎn)品系統(tǒng)中對所有的改變先進試。在改變發(fā)生之后，應(yīng)該檢查系統(tǒng)是否能夠不出現(xiàn)任何錯誤消息或警告消息地恢復，并且不存在任何不好的副作用。，可靠但不高效的內(nèi)核遠遠優(yōu)于不可靠但比較高效的內(nèi)核。 對Oracle比較重要的UNIX內(nèi)核參 NPROC24×7該確保這些參數(shù)的值比較大。因為這樣的系統(tǒng)不能經(jīng)常重新啟動，應(yīng)該估計自己所需要的最大值，并將參數(shù)設(shè)置為這數(shù)的設(shè)置值降低。如果使用的是純文件系統(tǒng)，可以根據(jù)數(shù)據(jù)文件的數(shù)目與應(yīng)用程序的特點，考慮加大這些參數(shù)的設(shè)置值。對于大多數(shù)基于文件系統(tǒng)的Oracle安裝方式，文件系統(tǒng)緩沖器的大小一般可以設(shè)置為物理內(nèi)存在10%～20%在某些UNIX版（例如SVR4）中，文件系統(tǒng)緩沖器大小態(tài)管理。但是，

NFILEMINODEBUFPAGESinode的最大數(shù)目（所有的打開文件、管道等等都需要一個inode）。這個值應(yīng)該用戶文件大小的最大值(以物理操作系512字節(jié)為單位。在設(shè)定這個值時，可以考慮自己的最大Oracle導出轉(zhuǎn)儲需要添加到文件系統(tǒng)緩沖器中的頁面數(shù)目。每個頁面通常為1K在SystemV3中，這個參數(shù)用來說明可以同時存在的緩沖器總數(shù)。在SystemV4中，用來說明分配給每個批量數(shù)據(jù)緩沖器頭的數(shù)目。在系統(tǒng)用完所有的緩沖器頭（BUFHWM）時，就要分配一個新的批量數(shù)據(jù)。沒有被使用的緩沖器頭不能重新成為內(nèi)存。如果NBUF的值過低，那么系統(tǒng)將不得不分配給很多的緩沖器批量數(shù)據(jù)，從而降低效率。而如果NBUF的值過高，那么沒有被使用的緩沖器頭就很多，從而導致內(nèi)存的浪費緩沖器可以使用的最大物理內(nèi)存，單位為K。它可以用來限制能夠存在的緩沖器數(shù)目。如果系統(tǒng)經(jīng)常發(fā)生換頁現(xiàn)象，應(yīng)該考慮減少這個參數(shù)的值。但是，在運行DSS應(yīng)用程序時，通過增加這個參數(shù)的值系統(tǒng)頁表的大小。如果增加了緩沖器Cache，就應(yīng)該增加這個參數(shù)的值。如果頁表過小，以至于不能進行整個緩沖器Cache的映射，系統(tǒng)將在啟動時減少Cache大小。有些系統(tǒng)不允許用戶改變這個值，這時就只能在系統(tǒng)所給的值上工作啟動頁面對換動作的門檻值。當空閑內(nèi)存低于LOTS 時，頁面對換程序開始工作 如果需要進行內(nèi)存對換動作，應(yīng)該考慮增加LOTS值。這樣可能會增加內(nèi)存換頁的次數(shù)，但能夠有效地減少空閑內(nèi)存低于DES的機會。如果LOTS的值。如果有足夠的物理內(nèi)存，使得一般都能夠避免內(nèi)存對換操作應(yīng)該牢記“現(xiàn)在少命中，將來多命中”規(guī)則：內(nèi)存換頁動作開始得越晚，系統(tǒng)就越可能會進行內(nèi)存對換。另一種 信號燈是用來進行進程間通信的計數(shù)器。當某個進程占用某種資源時，計數(shù)器就將自增。如果資源被釋放，計數(shù)器將自減?？梢詫⑿盘枱艨醋魇恰凹冁i”。如果Oraclepost-wait驅(qū)動器，而不是信號燈，那么這一部分就不是很關(guān)鍵（關(guān)于post-wait驅(qū)動器，請參見第7章））中的一個特定部分，用來進行進程間通信。它允許多個進程在不必將內(nèi)存中的內(nèi)容從一個進程傳輸?shù)搅硪粋€進程的條Orale的所有SGA都必須適合于共享內(nèi)存。如果正在SGA，應(yīng)該為這些參數(shù)指定

系統(tǒng)認為自己完全用完了內(nèi)存的門檻值。必須將系統(tǒng)配置為不到達這個值。如果內(nèi)存已經(jīng)到達這個值，系統(tǒng)將分配內(nèi)存，直到某些在某個進程可以被對換出去之前，進程應(yīng)該處于空閑狀態(tài)的秒數(shù)信號燈集合（每個集合中包含有信號燈共享內(nèi)存段的最大字節(jié)數(shù)。應(yīng)該使這個參數(shù)是，并不嚴格要求這個參數(shù)值適合于共享內(nèi)存段的整個SGA。但由于它能夠減少進程間通信能被分配到一個單獨的共享內(nèi)存段上，那么它筆者常常被派往客戶站點，為其提供服務(wù)，主要是幫助客戶站點對那些低性能的數(shù)據(jù)庫系統(tǒng)進行性能優(yōu)化。在筆者檢查Oracle初始參數(shù)時，發(fā)現(xiàn)有各種各樣的數(shù)據(jù)庫塊大?。◤?KB～16KBDBA(數(shù)據(jù)庫管理員)Oracle初始化文件中的許多參數(shù)都取決于數(shù)據(jù)塊大?。―B_BLOCK_SIZE）Oracle安裝程序缺省設(shè)置（2KB）或者在不考慮操作系統(tǒng)塊大小的情況下隨便設(shè)置DB_BLOCK_SIZE大小，就有可能會造成嚴重的性能損失以及資源的浪費。因此，必須非常熟悉自己的操作系統(tǒng)塊大小。如果在創(chuàng)建數(shù)據(jù)庫時沒有考慮這個信息，那么所創(chuàng)建的數(shù)據(jù)庫塊大小就未必是最優(yōu)的。在數(shù)據(jù)庫的創(chuàng)建過程中，塊大小是一項非常重要的設(shè)置，因為這個參數(shù)在數(shù)據(jù)庫的整個生存期內(nèi)都是不可改變的。因此，在進行這樣一個單向的操作之前，應(yīng)該確保自己對于操作系統(tǒng)塊大小非常了解。至少應(yīng)該要保證數(shù)據(jù)庫塊大小大于或等于操作系統(tǒng)塊大?。ㄗ詈檬菙?shù)據(jù)庫塊大小幾倍于操作系統(tǒng)塊大小raw設(shè)備，可以考慮使用操作系統(tǒng)物理塊大小（512字節(jié)。在使用普通的文件系統(tǒng)時，應(yīng)該考慮使用操作系統(tǒng)邏輯塊大小，邏輯塊大小是由系統(tǒng)管理員進行設(shè)置的。缺省情況下，大多數(shù)VM（LogicalolumeManager）將操作系統(tǒng)邏輯塊大小設(shè)置為8KVM，那么很有可能站8K8K。如果讀者正在管理一個OTP應(yīng)用程序，并且希望設(shè)置一個粒度更小的數(shù)據(jù)庫塊大?。ɡ?K4K的操作系統(tǒng)塊大小來重新建立文件系統(tǒng)（可以通過mkfs命令手工地創(chuàng)建，也可以利用菜單驅(qū)動的系統(tǒng)管理工具創(chuàng)建。這與為了改變數(shù)據(jù)庫塊大小而必須重新創(chuàng)建數(shù)據(jù)庫類似。也許所有的這些過程似乎要花費很多的管理開銷，但為了保證數(shù)據(jù)庫速度與可用性，任何代價都是值得的。同樣，如第3章中所說的，將DB_BLOCK_SIZE設(shè)置為操作系統(tǒng)塊大小的整倍數(shù)可能會包括預讀，這是因為哪怕是一個數(shù)據(jù)庫塊也會導致多個操作系統(tǒng)塊的讀操作。在不需要進行預讀的OTP環(huán)境下，可以將DB_BLOCK_SIZE設(shè)置為與操作系統(tǒng)塊大小相同的值（而不必是操作系統(tǒng)塊大小的倍數(shù)。raw設(shè)備（或raw硬盤）就是一個未格式化的設(shè)備（硬盤）raw設(shè)備沒有任何文件系統(tǒng)安裝在其中，對它們的讀寫是從字符設(shè)備驅(qū)動器中進行的。由于沒有常規(guī)的文件系統(tǒng)（例如UFS、VxFS、NTFSraw系統(tǒng)之后，文件系統(tǒng)將管理所有的I/O請求，每個I/O請求主要通過文件系統(tǒng)的緩沖器。也就是說，數(shù)據(jù)首先被寫入文件系統(tǒng)緩沖器中，然后與物理硬盤進行同步。當在某個raw硬盤上創(chuàng)建了Oracle文件（例如數(shù)據(jù)文件、聯(lián)機重作日志或控制文件）時，由于文件系統(tǒng)不存在，Oracle將負責進行對硬盤的讀寫控制。圖4-1中顯示了UNIX系統(tǒng)與WindowsNT系統(tǒng)下的raw硬盤與格式化硬盤。在UNIX系統(tǒng)下，（包括硬與符號

圖4- UNIX與WindowsNT環(huán)境下raw硬盤與已格式化硬盤的不同之（文件系統(tǒng)被裝配在每個已格式化硬盤上本書不打算對這些文件類型進行過多的討論（但有些類型，例如與已命名管道，將在后面章節(jié)中進行解釋。為了能夠有效地理解UNIX系統(tǒng)中raw硬盤的概念，必須知道常規(guī)文件與設(shè)備文件。UNIX使用設(shè)備文件與硬件組件（例如硬盤驅(qū)動器與磁帶驅(qū)動器）進行通信。每個硬盤驅(qū)動器都在/dev中有相應(yīng)的表項。一個已格式化的硬盤有塊設(shè)備文件與字符設(shè)備文件，而一個raw硬盤只有字符設(shè)備文件。字符設(shè)備文件使用自己的設(shè)備驅(qū)動器對硬盤進行讀寫并且按照可變的大小執(zhí)行I/OI/O操作，并且以固定長度大小對硬盤進行讀寫（讀寫單位通常是物理塊單位或者物理塊大小的整倍數(shù)。常規(guī)文件通常包含有一些二進制數(shù)據(jù)，這些二進制數(shù)據(jù)用來表示詞、數(shù)字、圖像等等。Oracle數(shù)據(jù)庫就是由這樣的常規(guī)文件（數(shù)據(jù)文件、重作日志、控制文件)所組成的。每個常規(guī)文件不需要在硬盤劃分的某些位置存在。對于已格式化的硬盤，多個常規(guī)文件可以共存于一個硬盤劃分中，其中每個常規(guī)文件在一個大 或者某個特定的子 下面。但是，對于未格式化的硬盤，每個raw劃分只能存放一個常規(guī)文件（慮Oracle時。也就是說，在raw劃分與Oracle文件之間必須存在一對一的相關(guān)性。Oracle文件所在的raw設(shè)備必須屬于Oracle軟件所屬的用戶ID許多在非OPS（Oracle并行服務(wù)器）環(huán)境下（在OSP環(huán)境下，強制使用raw硬盤）使用硬盤的站點中，筆者發(fā)現(xiàn)了一個共同的問題：在設(shè)計與配置過程中，操作人員非常熱衷于討論raw設(shè)備優(yōu)缺點。雖然他們認為raw硬盤的比較，但仍然決定克服這個，使用raw設(shè)備以獲取性能效益。但幾個月之后，他們發(fā)現(xiàn)并沒有得到明顯的性能改善，反而帶來了系統(tǒng)的不靈活性、不確定性以及正常的停工時間。有些文章毫無根據(jù)地聲稱使用raw設(shè)備可以獲取10％到20％的性能改善，但在筆者與眾多經(jīng)驗豐富的DBA交談過程中，發(fā)現(xiàn)并沒有充分的能夠說明raw，rawraw筆者曾經(jīng)聽到過那些在進行OTP的benark測試過程中使用raw設(shè)備的Oracle術(shù)員強調(diào)測試（TPC-C）的重要性，以便證明Oracle在速度與健壯性方面的優(yōu)勢（讀者可以在的中見到這樣的數(shù)據(jù)。但是，在現(xiàn)實生活中，許多這樣的技術(shù)人員并不會真正考慮使用raw設(shè)備，特別是在高可用性問題更為重要時尤其如此。只有在硬盤I/O是主要的瓶頸時，使用rawOracle中非常成熟的內(nèi)存體系結(jié)構(gòu)使用數(shù)據(jù)塊緩沖器來合理地與管理數(shù)據(jù)，并且使得硬盤I/O最小化。筆者曾經(jīng)見到許多使用了rawI/O瓶頸的可能。相反，大多數(shù)I/O瓶頸的發(fā)生都是因為很少有硬盤或者硬盤控制器和用于進行優(yōu)化的數(shù)據(jù)放置，或者甚至是因為數(shù)據(jù)文件沒有在所有的可用硬盤與硬盤控制器上得到優(yōu)化的分配。無論是使用raw設(shè)備還是使用I/O瓶頸問題的有效途徑。另一個導致I/O瓶頸的重要原因是沒有經(jīng)過優(yōu)化的SQL語句。許多時候，沒有經(jīng)過優(yōu)化的SQL語句常常會導致完全的索引掃描與表掃描，從而導致許多不必要的I/O。即使是在一個經(jīng)過優(yōu)化的環(huán)境中，這些I/O也可能會導致硬盤產(chǎn)生瓶頸，從而使得管理員相信轉(zhuǎn)移到raw設(shè)備中可能會解決這個問題。但是事實上，對SQL語句進行優(yōu)化以及對大表進行不必要的I/OrawDBA認為自己采用正確的方法解決了站點中所存在的性能問題。，他們并沒有高興多久。在此后的六個月中，當需要添加數(shù)據(jù)文件時，他們發(fā)現(xiàn)自己掉入了一個惡夢中。事實上，他raw設(shè)備本身帶來的，而是由于他們將數(shù)據(jù)存放方式轉(zhuǎn)換為raw設(shè)備方式這個動作而得到的。在轉(zhuǎn)換過程中，整個舊有的數(shù)據(jù)庫都被以組塊的方式導出，然后被重新導入到建立在raw設(shè)備上的新數(shù)據(jù)庫中。所有主要的索引都被重新創(chuàng)建，從而導致數(shù)據(jù)庫是完全非預期的：表中的所有行被排列在一起，行鏈被消除，索引被非常簡潔地重新創(chuàng)建（這些都是由于移動所帶來的好處。其最終結(jié)果是，性能得到了改善，而不是硬盤I/O的問題。幾個月之后，當數(shù)據(jù)庫又被分段成許多部分時，先前的性能問題又重新出現(xiàn)。而這時，就連數(shù)據(jù)文件管理的靈活性也喪失了。，在又將數(shù)據(jù)方式轉(zhuǎn)換為UFS同樣獲得了性能改善，而且這一次故意使得數(shù)據(jù)庫被分段。從這個例子中可以看出，在不理解使用raw設(shè)備可能會帶來的影響的情況下就直接使用raw設(shè)備時，可能會帶來許多不必要的DBA任務(wù)（那些大多數(shù)不使用raw設(shè)備的站點的DBA認為想當然的任務(wù)。這樣一些任務(wù)很容易使得系統(tǒng)可用性受到影響，即使是像轉(zhuǎn)移到raw設(shè)備 下面將分析raw下面這些是raw由于旁路了文件系統(tǒng)緩沖器而進行直接讀寫，從而具有更好的性能對硬盤的直接讀寫就意味著取消了硬盤與文件系統(tǒng)的同步需求，反之亦然。這一點對于純OTP系統(tǒng)非常有用，因為在這種系統(tǒng)中，讀寫的隨機性非常大以至于一旦數(shù)據(jù)被讀寫之后，它們在今后較長的一段時間內(nèi)不會得到再次使用。除了OTP，raw設(shè)備還能夠從以下幾個方面改善DSS應(yīng)用程序的性能：DSSraw設(shè)備所提供的直接寫功能也非常有用，因為對臨時表空間的寫動作速度更快。即使是在初始化參數(shù)SOT_DIRECT_WRITES被打開的情況下，這個結(jié)論也是對的，因為任何寫操作都會從中受益（無論是否旁路了SGA。序列化raw設(shè)備非常適合于序列化I/O動作。同樣地，DSS中常見的序列化（表/索引的完全掃描）使得raw多數(shù)時候，除非存在嚴重的硬盤I/O瓶頸，否則由于直接讀寫所帶來的性能改善是非常小的（因為緩沖器I/O非?？欤?，并且基本上無法被終端用戶所察覺。在許多UNIX版本中，由于支持對常規(guī)文件系統(tǒng)進行直接I/O的能力，使得raw設(shè)備不再是進行直接硬盤讀寫的唯一方法（但要說明的是，“純”直接I/O只能通過使用raw設(shè)備得到；文件系統(tǒng)所為Oracle獲取的內(nèi)存在常規(guī)的文件系統(tǒng)中，寶貴的內(nèi)存被文件系統(tǒng)緩沖器所占據(jù)。，大多數(shù)主要的產(chǎn)品計算機都有至少1000MB的內(nèi)存，從而意味著為文件系統(tǒng)緩沖器分配一些內(nèi)存不會造成嚴重的。此外，對Oracle內(nèi)存結(jié)構(gòu)等預先規(guī)劃與智能配置也能夠?qū)е聝?nèi)存的更高使用效率。如果確實使用了raw設(shè)備，但是沒有收回文件系統(tǒng)緩使用raw設(shè)備的缺點非常突出，足以使得那些想要轉(zhuǎn)換到使用raw恢復難度增大在raw設(shè)備上不能使用由Oracle所提供的數(shù)據(jù)文件管理靈活性。任何站點，只要其性能受到過I/O瓶頸的影響，就會理解在進行數(shù)據(jù)文件轉(zhuǎn)移時靈活性的重要性。如果發(fā)現(xiàn)某個硬盤在絕大多數(shù)時候（90％的時間）都處于忙狀態(tài)（這樣的硬盤被稱對于一個常規(guī)的文件系統(tǒng)，如果在目標硬盤上有足夠的空間，這個任務(wù)就相對較簡單。但是，rawraw劃分raw劃分。例如，如果raw硬盤上的數(shù)據(jù)文件是1GB，并且這個硬盤上的raw劃分是1GB外加1M（這個1MB是raw劃分的開銷，因此必須在目標硬盤上有與這個劃分相等或者更大的劃分存在。這個過程似乎很容易，但各種Oracle表空間的大小并不相同，因此，與每個表空間的數(shù)據(jù)文raw劃分是一項非常艱巨的任務(wù)，特別是對于大型數(shù)據(jù)庫更為如此。容量規(guī)劃是一項非常無聊的工作，因為必須保證有相同大小或者更大的raw劃分，必須I/O此外，許多標準、易用且易記令（例如cp、mv、rm等等）不能在raw設(shè)備上正常沒有文件系統(tǒng)緩沖器 其實，這既是raw設(shè)備的優(yōu)點，也是其缺點。在那些所讀寫的數(shù)據(jù)不久就將被使用的應(yīng)用程序（包括OTP與DSS）中，如果數(shù)據(jù)沒有在SGA中存在，那么raw設(shè)備將會請求另一個硬盤讀出并獲取所需的數(shù)據(jù)。這種情況下，文件系統(tǒng)緩沖器也許會有所幫助，這是因為數(shù)據(jù)首先在緩沖器中存在，直到緩沖器空間被其他應(yīng)用程序所重新使用。如果所需的數(shù)據(jù)已經(jīng)在文件系統(tǒng)緩沖器中，那么就可以避免進行硬盤的讀寫操作，因為操作系統(tǒng)可以從緩沖器中獲取數(shù)據(jù)?？梢姡跊Q定使用raw設(shè)備之前，必須仔細地分析自己的環(huán)境與需求。與OPS環(huán)境不同，在這種環(huán)境下，是強制使用raw設(shè)備的，應(yīng)用程序很少牽涉到raw設(shè)備的不靈活性問題。由于正如前面所述，如果應(yīng)用程序的數(shù)據(jù)傳輸率很高以至于可能會產(chǎn)生或者已經(jīng)正在產(chǎn)生I/O瓶頸，那么raw設(shè)備的使用就很值得。這可以通過benark來建立。通過使用自動工具，可以模擬產(chǎn)品級通信負載并決定是否會引起I/O瓶頸（雖然使用了最好的物理數(shù)據(jù)文件放置方法。還應(yīng)該注意到，正在使用的SQL語句也可能會導致高數(shù)據(jù)傳輸率問題，因此，進行SQLraw”設(shè)備推崇者并且仍然堅持使用raw設(shè)備，或者已經(jīng)準備好了能夠進行簡單的恢復，那么就會發(fā)現(xiàn)以下技巧非常有用，特別是在管理關(guān)鍵的產(chǎn)品環(huán)境時更是如此。根據(jù)Oracle的OA中所推薦的，應(yīng)該將表從索引、臨時段與反轉(zhuǎn)段中區(qū)分開來。為了達到這個目的，至少必須有表空間（DA、INDEX、SYSTEM、TEMPORARY等等）數(shù)目一樣多的raw劃分數(shù)。對于任何站點，考慮將所有的段放置在一個大的表空間（SYSTEM）中都是24×7站點了。因此，表空間中的數(shù)目越多，所需要的raw劃分數(shù)也就越多。預先進行raw劃分的創(chuàng)建使得能夠及時地對所需的表空間進行擴展（從而可以避免在出現(xiàn)“Unabletoallocatenextextent”錯誤消息之前還一直忙于獲取足夠的raw夠多的raw劃分也能夠為將數(shù)據(jù)分散到盡量多的表空間與數(shù)據(jù)文件上以獲取高性能提供極大的靈活性。raw劃分時，就應(yīng)該限定所有劃分的標準大小。畢竟，將所有的rawOracle數(shù)據(jù)文件提供最大的靈活性。而且這種方法也適合于Oracle內(nèi)在文件管理特性，例如重命名或移動數(shù)據(jù)文件、刪除與重建數(shù)據(jù)文件等等。而使用多個不同的大小通常會增加將數(shù)據(jù)文件從一個硬盤移動到另一個硬盤的復雜性?，F(xiàn)在來看一下這個問題的另一面。如果全部使用一種標準大小，那么就不可避免地要將一個很大的空間分配給一個較小的表空間。也就是說，可能會造成空間的極大浪費。例如，假設(shè)SYSTEM表空間占用了80MB，運行需要移動到一個只有300MB的raw硬盤上，那么這種移動將會導致220MB的硬盤空間浪費。在這種情況下，人們也許會考慮到用220MB的空間來普通的表空間內(nèi)混合使用多個段（SYSTEM在中加入non-data-dictionary段）所花費的開銷可能比浪費硬盤空間的開銷更大。如果由于正常的數(shù)據(jù)庫增長和空間的浪費而使得所有預先創(chuàng)建的raw劃分最終被用完，DBA將會被迫從已經(jīng)在文件系統(tǒng)中存在的空間中添加一個數(shù)據(jù)文件，而不是立刻去使用新硬盤。這將會使問題更加復雜，因為包括備份與恢復在內(nèi)的所有操作都需要有文件系統(tǒng)那樣的靈活性來處理raw因此，必須經(jīng)過大量的分析之后才能決定應(yīng)該使用的“標準尺寸”。必須保證這個尺寸不是特別小，以便能夠容納大表空間。例如，如果一個10GB200MB的raw硬盤劃分，那么這一個表空間就需要有50個數(shù)據(jù)文件。這樣小的標準尺寸將會限制數(shù)據(jù)庫的總大小，這是因為Oracle對硬件與軟件都有參數(shù)進行限制。增加硬件限制就意味著需要重新創(chuàng)建控制文件，而且一旦到達硬件限制的最大值，就不可再增加數(shù)據(jù)庫的大小了。這一點對于Oracle7很在1022～4000個文件之間。Oracle8為了決64M～256M個文件。任何情況下，數(shù)據(jù)庫實例與控制文件的重24×7環(huán)境是難以接受的。注意Oracle數(shù)據(jù)文件的最大數(shù)目不僅取決于MAXDATAFILES命令的CREATEDATABASE參數(shù)與初始參數(shù)OPEN_FILES，同時還取決于為Oracle軟件所有者所設(shè)置的某些操作系統(tǒng)內(nèi)核參數(shù)（例如，NFILE與NINODE）以及打開文件上的會話限制（LIMIT。此外，Oracle7中的DB_BLOCK_SIZE也對于一個Oracle實例所能夠容納的文件總數(shù)進行了限制（8K的DB_BLOCK_SIZE最多能夠支持502個文件。同時，必須確保標準尺寸不是特別大，從而防止在表空間比較小時導致空間的嚴重浪費。為了能夠照顧到這兩方面的因素，必須采取折衷方案。而不應(yīng)該僅僅選擇一種標準尺寸，最好能夠同時給定三個標準尺寸（小、中、大4-2所示?？刂莆募☉?yīng)該記住，Oracle8中的控制文件越來越大）與其他較小的數(shù)據(jù)文件（SYSTEM）可以被放置在“小”raw部分中。聯(lián)機重作日志與其他中等大小的表空間（例如TEMPORAY）大小的raw部分中。最后，非常大的表空間的數(shù)據(jù)文件可以放置在“大”raw部分中。如果公司的站點是一個VLDB站點，還必須給出一個“超大”規(guī)模的raw 常見的raw硬盤劃分尺寸（每個尺寸中都有1MB用作raw硬盤的開銷 小大中雖然數(shù)據(jù)文件I/O可以是異步的（假設(shè)操作系統(tǒng)支持異步I/O，但從重作日志與控制文件I/O總是同步的。raw設(shè)備對于同步I/O操作與序列化I/O操作都非常有效。如果正在自己的站點上使用raw設(shè)備，那么應(yīng)該用它們作聯(lián)機重作日志。重作日志由LGWR序列化地寫入，由ARCH序列化地讀出。此外，重作日志通常都是I/O密集型的。因此，重作日志非常適合置在raw如果正在使用OPSraw設(shè)備上。但請切記，不能將已歸檔的日志放置在raw設(shè)備上，而是必須將它們放置在常規(guī)的文件系統(tǒng)中。因為Oracle一個raw劃分中只能存放一個Oracle文件，不能在一個大的raw劃分上存放多個已歸檔的日志。當前版本的Oracle也不允許特定數(shù)目的raw劃分為創(chuàng)建已歸檔的日志進行預先配置。這樣，必須在每個參與節(jié)點上為已歸檔的日志指定一個文件系統(tǒng)。這個問題看上去更像是一個硬件問題。在簇/MPP環(huán)境（在此環(huán)境中使用了OPS）中，一個節(jié)點不能知道另一個節(jié)點所使用的文件系統(tǒng)（Cache、上鎖技術(shù)等等所存在的潛在高開銷所決定的。raw劃分并假設(shè)某個應(yīng)用程序（Oracle）正在負責處理所有的并發(fā)問題。無論筆者如何強調(diào)這個技巧的重要性都不為過。事實上，它也不成其為技巧，因為這個問題在OPS手冊中有詳細的說明。非OPS文檔中比較粗略地概括了這個問題，而且文檔中沒有強調(diào)并說明了這個問題的重要性。筆者認為，這個建議應(yīng)該在手冊中著重說明一下。不久之前，由于筆者缺乏對這個問題的足夠認識，使得幾乎花費了56個小時來為某個客戶安裝Oracle系統(tǒng)。由于這個客戶是運行于24×7模式的，我們制定了一個能夠移植到Oracle新版本的升級計劃，并決定采用raw設(shè)備。當時認為很容易就可以完成大部分的升級任務(wù)，例如在進行數(shù)據(jù)移植之前在新的機器上創(chuàng)建raw設(shè)備并建立新的數(shù)據(jù)庫，并且認為這個過程相對事實上，停工時間也確實比較短，但所作的預先工作卻持續(xù)了許多個白天與夜晚。最后才知道，系統(tǒng)管理員在每個硬盤的0raw劃分。完成這個工作之后，系統(tǒng)管理員就把其他的任務(wù)交由筆者，讓筆者自己來完成DBA的任務(wù)，創(chuàng)建數(shù)據(jù)庫。在對某些負載的情況進行試驗之后發(fā)現(xiàn)各個部分都能夠正常工作，就重新啟動數(shù)據(jù)庫系統(tǒng)。但系統(tǒng)重新啟動之后，發(fā)現(xiàn)硬盤已經(jīng)完全沒有用，因為硬盤中所裝載的所有數(shù)據(jù)都丟失了。在經(jīng)過多次反復之后，最后終于找出了問題的根源：在硬盤的0柱面上創(chuàng)建raw硬盤時，就覆蓋了硬盤的劃分信息。硬盤上的0柱面是用來那些關(guān)鍵的與硬盤相關(guān)的信息，例如劃分與邏輯容量控制映射。UNIX會自動保護0柱面。但是，在使用rawUNIX就完全由應(yīng)用程序進行控制。這樣，就必須手工地確保不要在0柱面上創(chuàng)建raw劃分。當然，據(jù)說新版本的UNIX已經(jīng)能夠這個問題的發(fā)生，因為它們采用了更高級的硬盤管理例程。經(jīng)過這次的教訓，筆者已經(jīng)不再關(guān)心硬盤管理程序?qū)@個問題的解決情況，因為自己能夠牢記不再使用0另一個值得說明的問題是當在raw設(shè)備上創(chuàng)建數(shù)據(jù)文件時，應(yīng)該使得數(shù)據(jù)文件的大小比raw劃分的尺寸要?。ㄖ辽僖蓚€Oracle塊），如表4-2所示。同時必須使得raw劃分比數(shù)據(jù)文筆者再次強調(diào)在使用raw設(shè)備時，應(yīng)該減小UNIX緩沖器分配給OracleSGA。如果沒有進行這個操作，那么將會導致文件系統(tǒng)緩沖器所占用內(nèi)存的浪費。在使用raw設(shè)備時，有這樣一個好的建議可供采納：為每個raw劃分創(chuàng)建UNIX符號，并且在所有的Oracle（CRETEDAABASE、CREATE/ATERTABLESPACE）中號接raw劃分。這樣能夠帶來極大的管理靈活性。例如，有時需要取出raw設(shè)備（I/O瓶頸問題，這時就可以關(guān)閉數(shù)據(jù)庫（大家應(yīng)該知道raw劃分對可用性的影響，重新創(chuàng)建必要的符號（保證符號名相同）指向新加入的劃分，再重新啟動數(shù)據(jù)庫就可以了?？梢?，符號能夠在物理raw設(shè)備與Oracle文件名之間建立一個有用的中間層。符號也能夠方便在raw設(shè)備上使用dbv應(yīng)用程序（dbv是一種用來驗證數(shù)據(jù)文件完整性的Oracle應(yīng)用程序。如果raw設(shè)備的名與路徑以dbv參數(shù)的形式給出，它將會產(chǎn)生一個“DEV-00100：Specifiedfile(filename)notaccessible(指定的文件（文件名）不可)”錯誤消息。這時，就應(yīng)該為raw設(shè)備創(chuàng)建一個符號，并使用這個名作為dbv參數(shù)。此外，在Oracle7.3的某些版本中在raw設(shè)備使用dbv時，必須特別指定最后一個塊參數(shù)，從而避免出現(xiàn)關(guān)于數(shù)據(jù)文件被破壞的誤導信息。為了更好地理解這個問題，可以參考下面這個在raw設(shè)備上對數(shù)據(jù)文件物理結(jié)構(gòu)的表示：其中，H表示數(shù)據(jù)文件頭，D表示數(shù)據(jù)塊，F(xiàn)表示空閑空間，R表示raw設(shè)備額外開銷。由于raw設(shè)備比實際的數(shù)據(jù)文件大，使得數(shù)據(jù)文件可能會被dbv不正確地讀，這是因為不知道raw設(shè)備的額外開銷有多大（必須使得它小于兩個Oracle塊。例如，假設(shè)在一個501MB的raw設(shè)備劃分上創(chuàng)建了一個500MB的數(shù)據(jù)文件。那么在dbv這個501MB的文件之利用下列查詢來判斷數(shù)據(jù)庫塊大小（DB_BLOCK_SIZ這個查詢將報告500MB（而不是501MB，因為Oracle判定被文件（500MB/DB_BLOCK_SIZE）所占據(jù)的數(shù)據(jù)庫塊（#_db_blocks）再次運行dbv。但這次指定END參數(shù)值為數(shù)據(jù)文件中總的數(shù)據(jù)庫塊數(shù)目減1（因為一般并不是只有UNIX文件系統(tǒng)（UFS）與raweritas的VxFS、Ciprico的xFS與IBM的VestaParallelFile-systemxFS與VestaParallelFile-systemVxFS了非常成商業(yè)應(yīng)用。VxFS是一種能夠提供多種高可用性選項與較高性能的健壯文件系統(tǒng)。它能夠提供基于事務(wù)的日志功能；快速恢復功能；使用基于擴展分配方法的自定義I/O大小；直接I/O；聯(lián)機管理操作（例如備份、大小調(diào)整、文件系統(tǒng)的碎片整理。24×7環(huán)境下，聯(lián)機I/O功能能夠提供像raw設(shè)備那樣高的吞吐率。此外，它還能夠允許直接I/O與帶緩沖器的I/O共存。也就是說，應(yīng)該關(guān)心那些將raw設(shè)備的性能與文件系統(tǒng)管理的簡易相結(jié)合的第文件系benark，并且與使用這種文件系統(tǒng)的其他組織中的系raw設(shè)備與UFS的文件系統(tǒng)。Oracle公司的CaryMillsap了一篇名為“MakingthedecisiontoUseUNIXRawDevices(關(guān)于使用UNIXraw設(shè)備的決策問題)”的，在這篇中對raw設(shè)備的各個方面都進行了深入的討論。讀者可以從OracleSupport中獲取這篇。本節(jié)將討論如何判斷系統(tǒng)是否已經(jīng)具有某項能力，或者應(yīng)該具有某項能力。然后再討論幾種造成系統(tǒng)瓶頸的現(xiàn)象。任何時候，只要達到系統(tǒng)的能力極限都會導致性能瓶頸與可用性瓶頸問題。最初，當系統(tǒng)資源被耗盡時，系統(tǒng)的吞吐率與響應(yīng)時間將會受到嚴重的影響。隨著這種情況的逐漸，系統(tǒng)將會花費越來越多的時間去試圖解決資源缺乏問題，最終將會通過進入緊急狀態(tài)而關(guān)閉系統(tǒng)功能。這樣，就使得高可用性成為泡影。應(yīng)該經(jīng)常執(zhí)行前攝(預先)監(jiān)視任務(wù)，以便確保沒有達到系統(tǒng)的能力極限。如果本人或者自己的同事不能親自執(zhí)行前攝監(jiān)視任務(wù)，那么就應(yīng)該隨時準備運行系統(tǒng)調(diào)度器（例如cron和at，通過執(zhí)行某些特定的來獲取系統(tǒng)當前工作能力的快照。同時應(yīng)該確保有足夠的RAM可供使用，并且很少發(fā)生內(nèi)存換頁以及幾乎不發(fā)生內(nèi)存對換動作。確保有足夠的對換空間可用，以便系統(tǒng)有足夠的空間可供對換（必要時。如果系統(tǒng)很快就達到了自己的最大工作能力，那么就說明所制定的初始能力規(guī)劃不正確。但事實是，無論怎樣規(guī)劃自己的系統(tǒng)，系統(tǒng)都有可能在某些時候達到自己的最大工作能力。對待這個問題的方法是正確地預防它們、監(jiān)事它們，并且在達到系統(tǒng)的最大工作能力時作出相應(yīng)的反應(yīng)。許多時候，前攝監(jiān)視都會給出關(guān)于潛在問題的警告信息。例如，在運行top或ps時，就可以見到每個進程的大小。如果一個進程看上去很大，那么就有可能說明它連續(xù)地占用內(nèi)存而沒有釋放內(nèi)存。對這些警告信息的觀察，能夠使得在問題變得不可收拾之前進行預先的防范。設(shè)計得不好的操作系統(tǒng)都會表現(xiàn)出一些特定的癥狀,本章后面的這些技巧將討論如何檢測的是一些在24×7站點中常用的解決方案，讀者在自己的站點環(huán)境下，在應(yīng)用這些技巧時也許會出現(xiàn)一些不同的問題。對這些技巧中所講的問題的理解，有助于為自己的24×7站點創(chuàng)由于不適當?shù)挠脖P驅(qū)動器管理而導致的I/O如果對上面出現(xiàn)的這些原因置之不理，那么其中的每個因素都有可能會導致系統(tǒng)逐漸變得不可使用，乃至完全。此外，最初，這些因素所引起的問題并不十分突出。例如，過載的CPUSQL代碼、過多的進程或者初始化參數(shù)SPIN_COUNT的值設(shè)置得過高所引起的。內(nèi)存不足問題可能是由于SOT_AREA_SIZE參數(shù)的值設(shè)置得過高、過多的進程、過大的SGA所引起的。I/O瓶頸問題有可能是SQL代碼配置得不好或編寫得不好所引起的。下面將對這些因素進行詳細的分析。最后需要說明的是，筆者在后續(xù)的討論中經(jīng)常會幾個UNIX命令（SVR4與BSD。對于那些標準命令（例如ps與cron，筆者在本書中對它們的用法與語法并不加以詳細的說明，因為這不是本書的重點。讀者可以參見UNIXman頁面來了解它們的詳細信息。但是，對于某些非常有用的非標準UNIX命令（例如top與sar，將加以簡單的說明。系統(tǒng)負載等級取決于以隊列模式共享操作系統(tǒng)內(nèi)核的所有進程。如果沒有足夠的CPU周期來有效地處理所有這些進程的工作負載，那么這些進程就必須對等待CPU可用。系統(tǒng)命令uptime能夠提供關(guān)于系統(tǒng)負載情況的信息，通過周期性地查看uptime的輸出，就可以知道關(guān)于CPU的典型使用模式。對這些信息的了解，有助于發(fā)現(xiàn)系統(tǒng)潛在的問題，從而使得在系統(tǒng)出現(xiàn)嚴重的性能下降或者導致系統(tǒng)停工之前進行必要的預防操作。系統(tǒng)對于過重負債的承受力取決于可配置區(qū)域的數(shù)目，例如CPU、內(nèi)存、I/O子系統(tǒng)。如果系統(tǒng)能夠在不影響其性能的情況下在高負載的條件下運行，那么這個系統(tǒng)就具有承受高負載的能力。也就是說，最好能夠通過對系統(tǒng)性能的監(jiān)視，知道什么情況對于系統(tǒng)來說是正常的。除非自己對于在較好的性能情況下系統(tǒng)的平均負載比較熟悉，否則就無法判斷當前負載是否對系統(tǒng)會造能影響。如果在平均負載較高的情況下，系統(tǒng)性能很差；而在平均負載比較低時，系統(tǒng)性能較好，那么就說明系統(tǒng)存在負載一致性問題，就應(yīng)該考慮采取適當?shù)牟襟E更加公平地分配CPU、內(nèi)存與I/O首先需要做的就是查看系統(tǒng)負載情況信息，分析在高負載與低負載情況下系統(tǒng)在干什么。在短期情況下，使用強制解決方案以及實現(xiàn)一個暫時性的解決方案（例如添加的硬件設(shè)備或者簡單地減少作業(yè)數(shù)目）可以解決這個問題。但為了完全理解問題的根源并實現(xiàn)正確的解決方案，必須對這個問題進行徹底的分析。例如，也以發(fā)現(xiàn)OTP應(yīng)用程序執(zhí)行時系統(tǒng)性能都比較好，但是每天晚上那三個小時，在運行需要使用數(shù)據(jù)倉庫的批處理作業(yè)時，系統(tǒng)性能就急劇降低。一旦注意到這個問題，就可以采取相關(guān)的解決方案?？梢钥紤]將這個批處理作業(yè)移動到每天早上的凌晨開始工作，因為這時沒有很多用戶使用系統(tǒng)并且不會與系統(tǒng)的熱備份相?；蛘撸梢詫ψ鳂I(yè)中的SQL語句進行性能優(yōu)化，從而允許作業(yè)在不導致系統(tǒng)負載過高的情況下運行?；蛘撸苍S需要對數(shù)據(jù)倉庫進行重新設(shè)計，從而使得作業(yè)可以按照池的方法獲得運行，而不是采用批處理的方法運行（這樣甚至可以消除批處理作業(yè)的必要性。或者，如果批處理作業(yè)是非Oracle進程，那么就可以考慮改變批處理作業(yè)的優(yōu)先級，從而減少命令uptime提供了三種負載平均值：最后1分鐘的平均值、最后5分鐘的平均值、最后從這個輸出信息中可以知道系統(tǒng)的名字（joker、系統(tǒng)運行了多長時間（162天，11個小時再加上38分鐘。命令中所報告的3個平均負載值是5.34、6.28、5.48。必須注意到平均負載是正在減少還是逐漸加大。在這個例子中，15.34；5分鐘之前的平均負載是6.28；15分鐘之前的平均負載是5.48。因此，這個系統(tǒng)的平均負載目前較為穩(wěn)定。如果觀察到某些比較大的平均負載，或者發(fā)現(xiàn)系統(tǒng)的平均負載正在逐漸變大，那么就應(yīng)該找出哪個進程正在運行（ps1分鐘就能夠作一次關(guān)于所有uptime輸出信息。通過將這些快照進行比較，就可以知道是哪個進程導致平均負載逐漸上升。然后，每隔48個小時再重新驗證自己的觀察是否正確，查看在下一個48小時中是否會由于同樣的進程而導致平均負載加大?？梢越⒁粋€cron作業(yè)，來隨機地查詢系統(tǒng)的uptime結(jié)果（每小時一次，或者采用其他的查詢頻率。如果這些平均值比較高，那么系統(tǒng)就有可能會出現(xiàn)問題。這時就應(yīng)該立刻驗證相同的或者類似的作業(yè)是否在平均負載的值期間運行。出現(xiàn)了這種情況，就應(yīng)該考慮使用進程（關(guān)于這個問題，可以參考第19章中名為viacron的進程。通過運行top命令，也可以獲取用來定位故障的必要信息（top實際上是與某些UNIX版本一同的第應(yīng)用程序；讀者可以從許多UNIX實用程序eb站點上到top。應(yīng)該知道，top不是非常精確，但它能夠提供關(guān)于平均負載的許多信息，此外還能夠提供一些其他有用信息，例如什么進程在CPU上、什么進程處于睡眠狀態(tài)，每個進程所占用的內(nèi)存大小，關(guān)top命令輸出結(jié)果的示例：上述輸出結(jié)果中的前三行中顯示了一些非常重要的信息，例如負載信息、進程信息、內(nèi)存使用情況以及內(nèi)存對換統(tǒng)計信息。詳細信息行中顯示的是那個清晨所使用的CPU比例與內(nèi)存比例以及進程的當前狀態(tài)（是睡眠狀態(tài)還是在CPU上。缺省情況下，top顯示的是按照CPU15個CPU資源使用者。top輸出中的第一行信息與uptime命令的輸出信息非常相似。top，因為這個應(yīng)用程序很占用資源。事實上，它也將自己作為CPU使用者中的一個（top排在第3位，這個應(yīng)用程序每秒鐘都要更新，從而增加了資源使用的開銷，有些版本的top允許不如此頻繁地進行輸出更新。即使如此，也需要掃描并大量的內(nèi)核表，以便獲取內(nèi)核的信息，這樣又不可避免地會消耗系統(tǒng)資源。其他用來獲取系統(tǒng)負載信息令還有sar和vmsta。減少系統(tǒng)瓶頸一旦判斷了系統(tǒng)中確實存在CPU競爭，就必須考慮減少這種競爭的方法。但是，如果系統(tǒng)已經(jīng)到達了最大的CPU工作能力，或者公司的財政預算不能允許進行額外的硬件投資，那么就可以考慮使用下列減少CPU瓶頸的技巧。首先應(yīng)該查看除了OracleServer之外，還有什么服務(wù)器在數(shù)據(jù)庫服務(wù)器上運行。然后通過使用上面所討論令來判斷這些應(yīng)用程序?qū)PU對CPU的需求比較高，那么就應(yīng)該考慮在其他現(xiàn)有的服務(wù)運行這樣的應(yīng)用程序。理想情況下，數(shù)據(jù)庫服務(wù)器應(yīng)該為數(shù)據(jù)庫所私有。特別是對于Oracle的NCA體系結(jié)構(gòu)，人們很容易就會利用中間層應(yīng)用程序（例如DeveloperServer、Oracle(Web)ApplicationServer乃至Oracle8的多個應(yīng)用程序）運行于數(shù)據(jù)庫服務(wù)器上，使得數(shù)據(jù)庫服務(wù)器過載。這樣將會導致兩層實現(xiàn)的不平衡現(xiàn)象，從而破壞了NCA所代表的應(yīng)用程序的性能。因此，必須將這些應(yīng)用程序分配到它們自己的服務(wù)器上。與Oracle服務(wù)器相比，它們可能需要更少的資源。因此，就可以在本公司中提供的功能不是很強大的服務(wù)器上運行這些應(yīng)用程序，并且減少這些應(yīng)用程序?qū)τ跀?shù)據(jù)庫服務(wù)器的總體負載。命令limit用來限制每個進程能夠使用的資源（CPU時間或內(nèi)存。可以設(shè)置軟限制與硬限制，硬限制比軟限制更為嚴格。在某個進程到達自己的軟限制時，這個進程將還有一次機會，在自己被kill之前允許增加自己的軟限制。如果某個進程到達了自己的硬限制，進程將沒有任何重新選擇的機會，就會立刻被kill。不要為數(shù)據(jù)庫服務(wù)器中與Oracl相關(guān)的進程設(shè)置限制。因為Oracle數(shù)據(jù)庫引擎對于資源管理非常熟練，為它加上限制只能帶來壞處?？梢詾槟切┓顷P(guān)鍵性的資源（例如連接的空閑時間）加上限制。例如，如果空閑時間被限制為1010分鐘的用戶都將被強制性地斷開連接。對于關(guān)鍵性的CPU時間與內(nèi)存的限制可以作用于中間層/子例程服務(wù)器，在這種服務(wù)器上有許多進程正在運行，從而導致大量的數(shù)據(jù)庫請求。在這樣的服/或CPU時間。的客戶站點上，為了處理ebeb服務(wù)器。在每個eb服務(wù)器上都運行了大量基于Pro*C的CGI，使得產(chǎn)生了對數(shù)據(jù)庫的連續(xù)調(diào)用。人們不斷開發(fā)新的功能用于加強客戶eb站點的功能，這就意味著必須在每個eb服務(wù)器上配置大量新的CGI時，由于時間關(guān)系，某些CGI程序?qū)⒂锌赡軟]有得到嚴格的質(zhì)量檢查，從而導致嚴重的運行時(run-time)bug的發(fā)生。其中有些CGI程序?qū)谔幚泶罅繑?shù)據(jù)的過程中陷入不可控制的循環(huán)狀態(tài)，從而導致占用所有的CPUeb站點的運行速度將會十分緩慢。如果在所有的這些eb服務(wù)器上建立硬限制，就可以防止這種情況的再次出現(xiàn)。在創(chuàng)建限制之前，應(yīng)該考慮所有可能被影響的因素。60分鐘的CPU-h，就可以進行注意：應(yīng)指望這限在所有時內(nèi)都有。些限制僅在Cs (csh)上有效并且不能保證所有的用戶與程序員都會使用站點中所提供的Cs 。由于限制是在特定用戶/程序員的初始文件(.cshrc)中進行配置的，那些知道這個問題的人就有可能會在運行它們的程序之前注釋掉這些限制。這樣，限制通常僅僅用于應(yīng)用程序開發(fā)團體與用戶團體的協(xié)同工作中，他們把獲取對現(xiàn)有資源使用的最優(yōu)組合并且防止不希望發(fā)生的“意外”（例如使某個應(yīng)用程序不再受控制）作為共同的目標。在這里首先將解釋兩個操作系統(tǒng)術(shù)語：調(diào)度(scheduling)(preemption)CPU，每個進程都被調(diào)度為在某個時刻開始運行—一般都是立即開始運行。但是，這種進程調(diào)度方式是基于優(yōu)先級進行的。進程的優(yōu)先級越高，就越有可能被CPU所調(diào)度。如果兩個進程被調(diào)度為在相同的時刻開始運行，那么優(yōu)先級更高的進程將優(yōu)先運行，只要進程運行完成或者到達了一個等待狀態(tài)（CPU等待某些資源可用，以便進程能夠繼續(xù)運行，CPU將運行第二個進程。在第二個進程運行時，如果還有另一個進程被調(diào)度為需要開始運行，并且這第三個進程優(yōu)先級比第二個進程的優(yōu)先級高，那么第二個進程將會被運行，而等待CPUCPU時間將主要用于具有相同優(yōu)先級的進程，直到以下發(fā)生：如果某個進程進入等待狀態(tài)或者運行完成，那么下一個高優(yōu)先級的進程將占用CPU處于運行狀態(tài)。這樣，調(diào)度就是在某個時刻使得某個進程處于運行狀態(tài)的動作，搶占就是一個具有更高優(yōu)先級的進程低優(yōu)先級進程的運行狀態(tài)，使自己處于運行狀態(tài)的動作?？梢?，進程的優(yōu)先級決定了進程的調(diào)度與搶占。例如，低級的系統(tǒng)進程優(yōu)先級高于用戶級進程。因此，如果某個用戶級進程正在使用CPU，而這時某個系統(tǒng)級進程啟動，那么用戶級進程將被CPU而進入睡眠狀態(tài)。一旦系統(tǒng)級進程運行完成，用戶級進程又可以重新在用CPU。通常，系統(tǒng)級進程執(zhí)行的是一些基本的關(guān)鍵性任務(wù)，他們確實需要被優(yōu)先地執(zhí)行，以便系統(tǒng)能夠提供平滑的功能服務(wù)。但是，在具有多個用戶級進程的情況下，具有較高優(yōu)先級的進程明顯優(yōu)于其他用戶級進程；只有在從事有許多進程在系統(tǒng)中運行并且必須選擇某些進程優(yōu)先運行時，才能使用用戶進程優(yōu)先級。也就是說，必須基于用戶進程的功能與緊急程度，對每個用戶及進程進行深入的分析，然后再為它分配一個特定的優(yōu)先級。如果在某個系統(tǒng)中多個不同優(yōu)先級的用戶及進程經(jīng)常競爭使用CPU，那么系統(tǒng)性能將會受到嚴重的影響，這是因為許多時間都被用于CPU關(guān)閉某個進程然后切換到另一個進程。此外，那些或者管理優(yōu)先級調(diào)度的用戶有可能迫使CPU花費大部分的時間處理某個特定的進程，以至于幾乎忽略了其他的進程，從而導致?lián)碛衅渌M程的用戶不滿。因此，只有在非常有必要時，才為用戶級進程特別地設(shè)置優(yōu)先級。不應(yīng)該對任何與Oracle相關(guān)的進程進行優(yōu)先級的管理，其優(yōu)先級最好不要隨意改動。OracleServer是一個非常復雜的軟件，有內(nèi)置的調(diào)度功能。這個軟件假設(shè)操作系統(tǒng)環(huán)境為所有的用戶進程設(shè)置相同的優(yōu)先級，并且Oracle進程將按照自己內(nèi)置的功能進行工作。因此，如果將某些OracleOracleServer的功能平滑性。UNIX為進行用戶進程的優(yōu)先級設(shè)置提供了一個nice命令。這個命令可以設(shè)置進程的“niceness(仁慈性)CPU方面的能力就越強。如果企業(yè)的用戶在數(shù)據(jù)庫服務(wù)器上執(zhí)行非Oracle的資源密集型進程，從而使得數(shù)據(jù)庫的運行速度極大地降低，那么就可以考慮增加這些進程的“仁慈性”，從而使得所有與Oracle相關(guān)的進程能夠最大限度地獲取CPU。此外，許多UNIX版本還支持renice命令，這個命令能夠允許改變那些正在運行的進程的優(yōu)先級。這樣，如果發(fā)現(xiàn)數(shù)據(jù)庫性能的降低是由于用戶進程使用了過多的CPU資源而引起的，就可以使用renice命令降低這些進程的優(yōu)先級，使得它不再過于活躍。Oracle進程的優(yōu)先級。例如，在某個客戶站點上，系統(tǒng)管理員在降低所有非Oracle進程的優(yōu)先級時，就會降低從屬于BACKUPuserID的優(yōu)先級，而這時如果BACKUPuserID被設(shè)置為運行所有的備份作業(yè)（Oracle個備份）；那么，將8小時，仍然沒有完成。這樣，備份動作將會持續(xù)到系統(tǒng)工作的期，從而使得數(shù)據(jù)庫性能又會降低。熱備份花費了這么長時間才完成，這個問3筆者關(guān)于降低非Oracle進程優(yōu)先級的建議是在假設(shè)傳遞數(shù)據(jù)庫服務(wù)器上的數(shù)據(jù)庫進程能夠獲取最高的資源使用優(yōu)先級的情況下。改變非Oracle進程的nice級別與renice級別都能夠有利于達到這個目標。但是，這僅僅是一個短期的解決方案。最終，必須使得那些在產(chǎn)品數(shù)據(jù)庫服務(wù)器上運行資源密集型非數(shù)據(jù)庫進程的用戶得以運行。CacheCPU由于某個CPU已經(jīng)運行了某個進程，那么如果進程在下一次運行時同樣使用這個CPU能夠獲益（3章。這個假設(shè)認為進程在下一次運行時仍然可以重新使用CPULevel-1(L1)Cache中的數(shù)據(jù)，從而避免了從物理內(nèi)存中數(shù)據(jù)的開銷。對于大多數(shù)現(xiàn)代Oracle應(yīng)用程序，這個假設(shè)一般是不成立的。這是因為CPUL1Cache太小而不能存放任何有價值的數(shù)據(jù)。而且，即使是有所獲益，這種性能獲益（個ns(納秒)）也幾乎是可以忽略不計的。的單處理器計算機和SMP計算機都是實現(xiàn)了CPU與物理內(nèi)存之間非常短總線的連接。因此，現(xiàn)在物理內(nèi)存的速度也是非?？斓?。但是，某些站點上的技術(shù)人員人仍堅持使用處理器仿射方法來改善系統(tǒng)性能。他們最終所得得到的是的管理開銷以及性能下降。因為處理器綁定就意味著某個進程只能在某個CPU上運行，如果這時CPU正在運行另一個進程而處于忙狀態(tài)，那么這個進程就必須等待（睡眠CPUCPU。這種情況在同時運很多時候，讀者都會在產(chǎn)品期實行非常巨大的查詢操作（并且他們常常抱怨系統(tǒng)性能問題DSS系統(tǒng)（例如數(shù)據(jù)倉庫與數(shù)據(jù)超市）的公司更為嚴重。不知什么原因，那些應(yīng)該在深夜運行的作業(yè)有時也會在期或者下午才結(jié)束。那么為什么會造成這種情況呢？似乎無人能夠回答。但必須保證自己能夠檢測并這些非產(chǎn)品關(guān)鍵型任務(wù)或非會話關(guān)鍵型任務(wù)占用寶貴的產(chǎn)品資源。雖然不可能100％地防止這些情況的發(fā)生，但是至少可以給出一個，要求所有非產(chǎn)品關(guān)鍵型作業(yè)與所有非會話關(guān)鍵型作業(yè)必須在得到DBA的之后才能在系統(tǒng)期運行。雖然有些頑固的用戶仍然會對這個置之不理，但是大多數(shù)用戶都會遵守這個的。該非Oracle進程（例如C程序或Perl）之外，還應(yīng)該避免使用源密集型UNIX命令。筆者曾經(jīng)在許多客戶站點上看到系統(tǒng)管理員與DBA制定了非常嚴格的產(chǎn)品標準，并且為開發(fā)者與終端用戶制定了相應(yīng)的使用規(guī)則，然后自己沒有任何猶豫地在產(chǎn)品數(shù)據(jù)庫服務(wù)器上使用資源密集型UNIX命令。實際上，某些UNIX命令可能與C程序一樣會影響系統(tǒng)的性能。任何產(chǎn)品規(guī)則文檔除了要包括開發(fā)者與終端用戶之外，還應(yīng)該包括系統(tǒng)管理員與DBA所適用的標準。必須對命令進行歸類，盡量少（如果不是完全取消使用）地在期使用特別消耗資源令。例如，有些系統(tǒng)管理員經(jīng)常使用ps-ef來查詢是否有任何進程使用了過多的CPU資源。ps-ef命令對進程表執(zhí)行一次完全的掃描并且自身就是一個資源密集型的程序。同時，在某些大站點上，筆者也注意到所有的DBA與系統(tǒng)管理員都使用各種各樣的監(jiān)視工具來連續(xù)地在期對系統(tǒng)進行監(jiān)視。這些工具與sar不同，它們都是獨立運行的并且會消耗大量的CPU資源。應(yīng)該努力尋找能夠獲取相同結(jié)果但消耗CPU資源更小的方法。例如，在產(chǎn)品期從根文件系統(tǒng)中使用find命令，對于系統(tǒng)使用與性能有非常嚴重的影響。另一種替代方法是，在每天凌晨通過cron從根文件系統(tǒng)執(zhí)行l(wèi)s-lR命令，并將這種命令的輸出結(jié)果保存在一個預定義的文件中。然后，當需要進行文件定位時，就可以不使用find命令，而對那個存放有l(wèi)s-lR命令結(jié)果的文件執(zhí)行相對較小的grep命令。由于grep命令僅僅作用于單個文件，使得進行文件定位的動作更加迅速，并且不會消耗很多的資源。這個方法可以用來查找任何在ls-lR命令運行之如果內(nèi)存不足以處理所有的活躍進程（Oracle進程與非Oracle進程，那么內(nèi)存就成為性能瓶頸。為了補償內(nèi)存不足的問題，操作系統(tǒng)使用硬盤作為物理內(nèi)存的無縫擴展，并且將內(nèi)存頁面在硬盤上的某個特定部分進行讀寫。這種延伸到硬盤上的“內(nèi)存”被稱為是虛擬內(nèi)存（virtualmemory，虛擬內(nèi)存使得進程在內(nèi)存不足的情況下能夠繼續(xù)運行。但是，每次虛擬內(nèi)存時，性能就開始降低，這是因為牽涉到了物理硬盤I/O過程。對內(nèi)存的是以電子速度（納秒級）進行，而對硬盤的則是機械速度（毫秒級。此外，由于多個不同進程可能會競爭使用同一個硬盤，因此使得這樣的毫秒級延遲時間擴展到秒級，從而使得終端用戶可以注意到這種延遲的存在。通過將內(nèi)容轉(zhuǎn)移到硬盤上所釋放出來的內(nèi)存空間被其他進程或者同一進程的其他部份所重用。內(nèi)存是按照頁面的單位來進行傳送的，通常每個頁面為4K。那些從內(nèi)存轉(zhuǎn)移到硬盤上的內(nèi)存頁面稱為換出頁面（out，那些從硬盤返回到內(nèi)存中的頁面稱為換入頁面（in，頁面的換入換出動作被稱為內(nèi)存頁面交換（paging。在許多操作系統(tǒng)中，換入頁面是不可避免的，特別是在系統(tǒng)支持請求調(diào)頁時更是如此。在請求調(diào)頁方式下，不必將整個程序裝載到內(nèi)存中，程序就可以運行。如果物理內(nèi)存中不存在需要使用的某個程序部分（頁面，那么就會導致在運行狀態(tài)下從硬盤上將這個程序部分裝載到內(nèi)存中。對在物理內(nèi)存中不存在的頁面的稱為缺頁。由于許多操作系統(tǒng)都使用請求調(diào)頁來啟動進程，因此，缺頁與后續(xù)的頁面換入過程就表明新的進程開始工作，而不是說存在內(nèi)存問題。但是，如果經(jīng)常發(fā)生頁面換出動作，這時就表明內(nèi)存空間不足。在發(fā)生內(nèi)存問題之后，會存在嚴重的頁面換入、頁面換出與缺頁現(xiàn)象。也就是說，在判斷是否存在與內(nèi)存相關(guān)的瓶頸問題時，除了考慮頁面換出現(xiàn)象之外，還應(yīng)該綜合考慮頁面換入與缺頁問題。關(guān)于缺頁現(xiàn)象需要考慮的另一個因素是，缺頁未必就會導致物理硬盤I/O。通常，內(nèi)核中維持有一個關(guān)于頁面的列表，這個列表就是所謂的自由列表(list)，它可以被換出內(nèi)存。在OracleSGA中，LRU算法可以決定什么時候頁面可以進入自由列表中。隨著頁面一直保持LRU列表的尾部移動，并且最終進入自由列表。但是，有時頁面被移動到自由列表中之后，在頁面被實際轉(zhuǎn)移到物理硬盤上之前，使用這個頁面的進程又可能需要這個頁面。這種情況下所產(chǎn)生的缺頁稱為是軟缺頁或者鏡像缺頁，這是因為不需要從理盤上這頁面。只將這個面單地從由表中放到LRU列表前端即可。但是，如果頁面已經(jīng)被轉(zhuǎn)移到物理硬盤上，那么就必須進行真正的物理硬盤讀操作，這就是所謂的硬缺頁或者說是主缺頁。在內(nèi)存嚴重短缺時，LRU算法就不能非常有效地將不活躍頁面轉(zhuǎn)移到自由列表上，因為許多頁面都應(yīng)該處于活躍狀態(tài)，而物理內(nèi)存又不能提供足夠的頁面供這些活躍頁面使用。這樣，那些不太活躍頁面就會很快被轉(zhuǎn)移到自由列表上（幾乎是隨機性的，然后被立即寫入硬盤中。因此，在內(nèi)存嚴重短缺時，任何缺頁都會最終導致硬缺頁。在發(fā)生非常嚴重的內(nèi)存調(diào)頁并且系統(tǒng)性能正在降低時，就應(yīng)該采取必要的補救措施。如果內(nèi)存調(diào)頁現(xiàn)象仍然十分嚴重，并且活躍進程對于內(nèi)存的需求不斷增加，系統(tǒng)就開始進行內(nèi)存對換。當某個進程被完全轉(zhuǎn)移到硬盤上，以便收回的物理內(nèi)存空間時，就發(fā)生所謂的內(nèi)存對換。先前章節(jié)中已經(jīng)討論了內(nèi)存對換不同級別，例如常規(guī)內(nèi)存對換（就是在執(zhí)行正常的操作系統(tǒng) 任務(wù)時所發(fā)生的內(nèi)存對換，此外還有緊急內(nèi)存對換或絕望內(nèi)存對換（就是操作系統(tǒng)所提供的在發(fā)生緊急時將內(nèi)存中的數(shù)據(jù)保存到硬盤上的一種新方法。內(nèi)存換頁相似，內(nèi)存對換也包括內(nèi)存換出（在此過程中進程從內(nèi)存寫入硬盤上、內(nèi)存換入（在此過程中進程從硬盤寫入內(nèi)存中。同樣，在某些操作系統(tǒng)中，內(nèi)存換入是不可避免的。但是，它們發(fā)生的次數(shù)一般都非常少。如果經(jīng)常發(fā)生內(nèi)存換入與換出現(xiàn)象，那么就應(yīng)該提高警惕。在這種情況下，都會導致性能降低。一般來說，非常少數(shù)的內(nèi)存換入與沒有任何內(nèi)存換出，就說明系統(tǒng)正在健康地運行，有足夠的內(nèi)存。如何能夠知道自己的系統(tǒng)頁面換出與內(nèi)存換出的高低呢？本節(jié)將討論一些非常好用的UNIX命令，可用來監(jiān)視內(nèi)存的換頁與對換問題。在查看這些命令的輸出信息時，應(yīng)該特別關(guān)心那些非常嚴重的內(nèi)存換出、頁面換出、內(nèi)存換入、頁面換入以及缺頁問題。必須綜合考慮這五個因素，才能正確地分析與解釋系統(tǒng)性能問題。在進行分析時，首先應(yīng)該考慮的是內(nèi)存換出與頁面換出，然后應(yīng)該考慮的是內(nèi)存換入、頁面換入與缺頁。如果發(fā)現(xiàn)前者以較高，那么就很有可能后者也同樣很高，說明存在系統(tǒng)短缺問題。UNIX命令（例如vmstat與sar）能夠提供關(guān)于換頁與內(nèi)存對換的主要信息。其令（例如ps與top）則通過顯示不同進程對內(nèi)存使用模式，來提供更為詳細的信息。下面給出了一個使用vmstat的例子：5秒鐘的vmstat命令的5次輸出結(jié)果。通常，將間隔時間設(shè)置為5秒鐘是一個比較好的值，因為它能夠有效地防止結(jié)果由于命令自身的運行而導致的不準確現(xiàn)象。在使用vmstat時，應(yīng)該總是忽略第一行的值，因為這個值并不可靠，它考慮了自從系統(tǒng)啟動以來的累加平均值。這個列表中的第6列與第7列（si(swap-ins)so(swap-outs）在上面的第一個表中是不存在的。如果在系統(tǒng)中發(fā)生內(nèi)存對換動作，“si”與“so”列上的值就會大于0以隨機性的時間間隔（通過手工設(shè)定或者利用cron設(shè)定）遠行此命令，以判斷是否發(fā)生了比較前面討論的用來減少系統(tǒng)負載的技巧也能夠用于節(jié)省內(nèi)存。但是，在許多情況下，最有效（更別說是最實際）的解決方案是的內(nèi)存并且重新配置內(nèi)存設(shè)置（括SGA大小這種方法能夠解決大多數(shù)內(nèi)存問題。如果硬件預算不允許，或者已經(jīng)到達了操作系統(tǒng)可以尋址的最大物理內(nèi)存，就應(yīng)該考慮采用前面講述的技巧更為慎重地使用內(nèi)存。下面還將介紹幾個專門用來節(jié)省內(nèi)存、管理內(nèi)存的技巧。有些程序，特別是新版本的軟件程序，通常都存在內(nèi)存泄漏方面的bug。這些程序按照指數(shù)的增長率吸收內(nèi)存并且逐漸變大，而且不釋放自己所占用的內(nèi)存。引起這個問題的原因可能非常簡單，例如，在程序的某個循環(huán)中程序員在使用了malloc()調(diào)用之后，沒有使用相應(yīng)的()必須經(jīng)常性地利用ps或top監(jiān)視進程對內(nèi)存的使用情況。如果發(fā)現(xiàn)某個進程特別大，那么就有可能發(fā)生了內(nèi)存泄漏情況。這時，就應(yīng)該在今后的12～24小時監(jiān)視這個進程，如果發(fā)現(xiàn)進程沒有正常地或者進程的大小沒有減小，就應(yīng)該手工地將這個進程“殺死”。有時，即使是kill了某個進程，也不會釋放內(nèi)存，就必須重新啟動系統(tǒng)。在Oracle7的某些版本中，內(nèi)存泄漏是MTS(多線程服務(wù)器)的主要問題。在安裝新版本的Oracle之前，必須在Oracle資料bug報告。在內(nèi)存換頁與內(nèi)存對換過程中，交換區(qū)空間被非常頻繁地使用。這時，必須保證配置有足夠的硬盤交換區(qū)空間用來完成這些動作。如果系統(tǒng)不能得到足夠的交換區(qū)空間，它將進入致統(tǒng)會括root。這樣將會用戶采用root登錄的邏輯步驟來kill些間(swapspace)進程。雖然這個建議也許是老調(diào)重彈，但筆者還是認為，為了獲取高可用性，必須無條件地保2～4倍。筆者也曾見到過某些站點，能夠支持大物理內(nèi)存訪問（2GB或）的系統(tǒng)中，所分配的交換區(qū)空間與物理內(nèi)存空間一樣大（有時甚至更少。只要不是需要的交換區(qū)空間，這也許沒有問題。但如果后來又需要更大的交換區(qū)空間，那么就太晚了，因為已經(jīng)不能再獲取可用來擴展交換區(qū)的空間了。在空間非常充足時(例如在安裝操作系統(tǒng)與配置硬盤時)如果硬件系統(tǒng)的內(nèi)存比較?。?GB或者更少)，最好能夠?qū)⒔粨Q區(qū)空間設(shè)置為RAM的4倍。對于內(nèi)存空間比較大的情況（2GB或者），也應(yīng)該將交換區(qū)空間至少設(shè)置為RAM的2倍。在Solaris的某些特定版本中，有一個稱為“虛擬內(nèi)存對換文件系統(tǒng)”的功能，它能夠允不分配任何交換區(qū)空間的情況下，直接對物理硬盤進行操作。如果自己的RAM足夠大，這個功能允許應(yīng)用程序?qū)AM用作硬盤上的物理對換文件，并且保證應(yīng)用程序正常運行，因(virtualswapfilesystem)Oracle在這樣的系統(tǒng)（沒有在硬盤上分配任何交換區(qū)空間）上運行時有可能會出現(xiàn)問題。這是因為Oracle大量的共享內(nèi)存（由于SGA被映射到共享內(nèi)存段上），使得它的虛擬地址空間需求（用來映射數(shù)據(jù)、文本、棧以及堆區(qū)域的內(nèi)存）也非常高，有時甚至會高于可用的物理內(nèi)存。這時，Oracle將不能僅僅在虛擬內(nèi)存對換物理系統(tǒng)上進行操作，至少需要在硬盤上有相同數(shù)目的空間，以便能夠在不用完成（虛擬）RAM。如果是在單獨的硬盤上創(chuàng)建一個大內(nèi)存對換文件，作為交換區(qū)空間，就有可能會導致非常嚴重的硬盤I/O問題。實際上，可以在多個硬盤與硬盤控制器上創(chuàng)建多個較小的內(nèi)存對換文件，用來構(gòu)換區(qū)空間。在這種方式中，交換區(qū)空間必須被連續(xù)地分配在所有的這些可用內(nèi)存對換文件上，以確保所有這些可用的交換區(qū)空間達到負載平衡。但是，如果每個這樣的內(nèi)存對換劃分空間都位于一個硬盤上，那么在出現(xiàn)比較大的內(nèi)存換出動作時就有可能會發(fā)生問題。即使是在不出現(xiàn)內(nèi)存換出的情況下，對交換區(qū)空間較小的寫動作也有可能會與正常的應(yīng)用程序?qū)τ脖P的數(shù)據(jù)動作發(fā)生。因此，在發(fā)生比較大的內(nèi)存對換動作時，系統(tǒng)性能將會下降很多。最后，就可能會導致I/O瓶頸?？梢岳梅謼l方法來解決這個問題。應(yīng)該確保自己在多個硬盤與硬盤控制器上對內(nèi)存對換區(qū)域進行了分條。如果主機系統(tǒng)的內(nèi)置硬盤是最快的，那么就應(yīng)該將內(nèi)存對換文件放在這里。否則，就應(yīng)該將交換區(qū)空間放置在外部硬盤陣列上。若有可能，應(yīng)該避免將交換區(qū)空間設(shè)置在RAID5、RAIDS或者RAID7劃分上，以便避免寫性能損失（writepenalty。理想情況下，應(yīng)該將交換區(qū)空間放置在RAID0（已經(jīng)進行了分條）上，以便避免RAID1中所存在的RAID1所采用的是基于硬件的硬盤控制器，而不是基于軟件的硬盤控制器，那么也可以考慮將交換區(qū)空間放置在RAID0+1上（因為在基于硬件的硬盤控制器上雙重寫能夠并行地完成。在進行內(nèi)存對換文件放置問題的規(guī)劃時，應(yīng)該考慮到有些UNIX版本對于每個內(nèi)存對換文件存在2GB(strip)內(nèi)存對換文件時，沒有意外地創(chuàng)建一個大于2GB的內(nèi)存交換文件分區(qū)。遺憾的是，在有些操作系統(tǒng)版本中，即使是超過了這個最大上限，系統(tǒng)也不會給出任何出錯信息，從而導致過多空間的浪費。有時，似乎解決內(nèi)存問題的最佳途徑就是進行的投資—內(nèi)存。但如果沒有進行實際的需求分析并考慮到操作系統(tǒng)的尋址能力，那么所的過多內(nèi)存就有可能會被浪費。例如，某客戶站上為了增系性能，費投資一個10GB的RAM。而且這個客戶站點使用的是SunEnterprise4000，并且給這個硬件系統(tǒng)配置了EMC硬盤陣列以及運行SunSolaris2.5DBA小組也正在開始預計這個新的、更大的SGA會如何如何有效，以及如何配置每個單獨組件。但是，Enterprise4000上的Solaris2.5不能尋址2GB空間之外的RAM。因此，這個10GB的RAM并不能充分發(fā)揮作用！此外，既使是即將發(fā)布的Solaris2.6也不能處理10GB大小的RAM。因此，必須等待64位的Solaris2.7（或者說Solaris7）從這個例子中可以得到以下教訓：必須在進行超過2GB系統(tǒng)的內(nèi)存尋址能力。即使是公司經(jīng)理被說服同意這樣大的物理內(nèi)存，也應(yīng)該確保自己的硬盤空間能夠創(chuàng)建足夠大的可對換內(nèi)存空間。某些UNIX版本支持對RAM中的共享內(nèi)存區(qū)域進行上鎖。能夠進行這種動作的先決條件是有足夠的RAM可用，否則就達不到對共享內(nèi)存區(qū)域上鎖的目的。進行共享內(nèi)存區(qū)域上鎖之后，在多個進程并發(fā)共享內(nèi)存時，就可以極大地減少進程間通信。也就是說，這樣將會導致整個OracleSGA被鎖定在主存中，從而防止了它被換頁或者對換出內(nèi)存。在運行基于Oracle的應(yīng)用程序（I/O密集型應(yīng)用程序）時，必須遵循“全方位分布”規(guī)則：盡可能在的硬盤與硬盤控制器上均勻地分配數(shù)據(jù)與重作日志。如果使用了外部硬盤陣列，應(yīng)該確保陣列中所有的硬盤都有相同大小與速度。這樣將有助于過去最優(yōu)Oracle服務(wù)器性能下降時，首先應(yīng)該考慮的就是I/OI/O樣會將一個經(jīng)過性能優(yōu)化的應(yīng)用程序變成執(zhí)行緩慢的程序。為了確保不產(chǎn)生I/O瓶頸，應(yīng)該如何預先監(jiān)視I/O負載呢？答案就是應(yīng)該使用能夠詳細地標志I/O負載等級的方法。這種I/O負載等級必須通過不斷地查看系統(tǒng)處于低性能期間與處于高性能期間的當前I/O負載來決定。UNIX提供了一些用來檢查I/O負載令。本章前面已經(jīng)提到，也可以使用基于GUI的第軟件來完成檢查I/O負載的工作。無論使用什么方法，都必須確保自己知道如何使用這些命令與工具?？捎脕頇z查I/O負載的UNIX命令包括iostat與sar。5秒種為時間間隔、對iostat5次統(tǒng)計之后得到的。第二個列表顯示的是通過使用-x開關(guān)而得到的以5秒種為時間間隔、對iostat命令的輸出結(jié)果進行10次統(tǒng)計之后得到的結(jié)果。-x開關(guān)能夠顯示諸如每秒鐘的讀操作（r/s、每秒鐘的寫操作（w/s）以及由于I/O瓶頸而導致的等待時間所占用的百分比。如果等待時間所占用的比例比較大，而且性能不高，那么就應(yīng)該考慮對硬盤進行整理。在那些沒有提供命令的系統(tǒng)（例如SystemV3與SystemV4）中，可以用sar來獲取相同的這個列表中顯示了sar命令以55次分析得到的輸出結(jié)果。關(guān)鍵列中包含有每秒種的讀寫次數(shù)（r+w/s與%busy。如果%busy的值非常高并且性能比較差，那么就說明可能存在硬盤熱點問題。減少I/O通常，諸如硬盤分條或者轉(zhuǎn)移“熱點”文件以避免活躍硬盤之類的方法是有效地消除硬盤瓶頸問題的解決方案。如果所連接的硬盤已經(jīng)分條，可以考慮選擇一個粒度更小的分條大小，然后再重新對硬盤進行分條，這樣做也許會有所幫助。同時，對當前分條配置進行重新分析也會對于系統(tǒng)的性能有所幫助。如果系統(tǒng)不提供基于硬件的分條，可以考慮使用VM（LogicalVolumeManagerOracle分條（Oracle分條并不是真正的分條。其中包括對潛在的“熱點”表與索引進行預分配，使得它們能夠擴展到不同的硬盤與硬盤控制器上。這個過程需要進行大量的人工干預，在一個數(shù)據(jù)庫增長速度很快的易變環(huán)境下，這個過程對于管理員來說非常復雜。（例如VeritasVolumeManager此外，某些UNIX的版本也VM，使得能夠在不增加任何開銷的情況下進行分條操作。誠然，硬件分條是非常理想的；但基于軟件的分條（利用VM）比不進行任何分條或者純粹進行Oracle分條要好得多。第3章中詳細討論了分條的方法。在進行I/O負載平衡設(shè)置時，預配置規(guī)劃是非常重要的。必須保證有另法能夠進行恢復