Oracle10g數(shù)據(jù)庫性能調(diào)優(yōu)方法研究

/內(nèi)容摘要：數(shù)據(jù)庫系統(tǒng)的性能最終了決定數(shù)據(jù)庫的可用性和生命力。大多數(shù)數(shù)據(jù)庫系統(tǒng)在運行一段時間后都會存在一定的性能問題，主要涉及數(shù)據(jù)庫硬件、數(shù)據(jù)庫效勞器、數(shù)據(jù)庫內(nèi)存、應(yīng)用程序、操作系統(tǒng)、數(shù)據(jù)庫參數(shù)等方面。因此，基于數(shù)據(jù)庫系統(tǒng)的性能調(diào)整與優(yōu)化對于整個系統(tǒng)的正常運行起著至關(guān)重要的作用。數(shù)據(jù)庫性能調(diào)整與優(yōu)化涉及到多個層面，通過統(tǒng)一規(guī)劃、系統(tǒng)分析做出相應(yīng)的調(diào)整，可以提高數(shù)據(jù)庫的穩(wěn)定性和可用性，保障系統(tǒng)高效地運行，解決系統(tǒng)瓶頸，節(jié)約系統(tǒng)開銷，具有良好的應(yīng)用價值，同時也對理論研究提供了一定的方法指導(dǎo)?；诖?，論文將Oracle10g數(shù)據(jù)庫的內(nèi)存分配、磁盤I/O以及SQL語句等方面的性能調(diào)整與優(yōu)化問題作為主要研究內(nèi)容，對其進行了深入地分析和討論，給出了一般情況下Oracle數(shù)據(jù)庫應(yīng)用系統(tǒng)的性能調(diào)整策略及優(yōu)化方法。關(guān)鍵詞：Oracle10g數(shù)據(jù)庫；體系結(jié)構(gòu)；系統(tǒng)全局區(qū)；性能調(diào)整與優(yōu)化AbstractAbstract:Theperformanceofdatabasesystemseventuallydeterminestheiravailabilityandsurvivability.Mostofthemwillbringaboutsomeperformanceproblemsmoreorlessafterrunningforaperiodoftime,whichmainlyinvolvedatabasehardware,databaseserver,databasememory,applications,operatingsystemsanddatabaseparameters,etc.Therefore,performancetuningandoptimizationofdatabasesystems,whichconcernmultipleaspects,areveryvitaltothenormalrunningofthewholesystem.Wecanimprovethestabilityandavailabilityofdatabase,guaranteeitshighrunningefficiency,solvesystembottleneck,reducesystemoverhead,obtainconsiderableapplicabilityandinthemmeanwhile,providesomeguidelinesfortheoreticalresearchthroughaunifiedplanandsystematicalanalysistomakeappropriateadjustment.Basedontheabove-mentionedidea,thepaperprincipallypaysattentiontotheresearchontheperformancetuningandoptimizationproblemsofmemoryallocationofOracle10g,discI/O,SQLstatements,etc,andmakesafurtheranalysisanddiscuss.Besides,itprovidessomeperformancetuningstrategiesandoptimizationapproachesofOracleapplicationsystemingeneralcondition.KeyWords:Oracle10gDatabase不Architecture不SystemGlobalArea不AdjustmentandOptimizationofPerformance

1導(dǎo)言網(wǎng)格技術(shù)是本世紀(jì)初最新和最有吸引力的技術(shù)之一，數(shù)據(jù)庫管理系統(tǒng)作為信息系統(tǒng)的根本支撐在信息化建設(shè)中扮演著重要的要色。目前的Oracle10g數(shù)據(jù)庫是業(yè)界首個為網(wǎng)格計算而設(shè)計的數(shù)據(jù)庫，是一種高效率、可靠性好的適應(yīng)高吞吐量的數(shù)據(jù)庫解決方案，該方案可讓客戶將多臺標(biāo)準(zhǔn)效勞器系統(tǒng)整合成一套可擴充的容錯運算平臺。然而，隨著數(shù)據(jù)庫規(guī)模的擴大及用戶數(shù)量的增加，數(shù)據(jù)庫應(yīng)用系統(tǒng)的響應(yīng)速度下降，性能問題越來越突出。Oracle10g數(shù)據(jù)庫系統(tǒng)體系結(jié)構(gòu)龐大、技術(shù)細(xì)節(jié)繁雜，如何合理有效地建立基于Oracle的數(shù)據(jù)庫系統(tǒng)及如何調(diào)整使系統(tǒng)性能到達最優(yōu)，成為Oracle數(shù)據(jù)庫應(yīng)用領(lǐng)域的熱點問題。本課題通過對Oracle10g數(shù)據(jù)庫系統(tǒng)的深入分析，設(shè)計一套完整的Oracle數(shù)據(jù)性能評測指標(biāo)和方法，并針對發(fā)現(xiàn)的性能問題制定相應(yīng)的性能優(yōu)化策略。2Oracle10g體系結(jié)構(gòu)Oracle數(shù)據(jù)管理系統(tǒng)是Oracle實例(Instance)和Oracle數(shù)據(jù)庫構(gòu)成的。下面是Oracle10g數(shù)據(jù)庫的體系結(jié)構(gòu)圖：圖1Oracle10g數(shù)據(jù)庫體系結(jié)構(gòu)2.1ORACLE實例Oracle實例包括系統(tǒng)全局共享區(qū)SystemGlobalAre和后臺進程BackgroundProcess。2.1.1系統(tǒng)全局共享區(qū)SystemGlobalArea(SGA)SystemGlobalArea是一塊巨大的共享內(nèi)存區(qū)域，他被看做是Oracle數(shù)據(jù)庫的一個大緩沖池，這里的數(shù)據(jù)可以被ORACLE的各個進程共用[1]。其大小可以通過如下語句查看：SQL>select*fromv$sga;NAMEVALUEFixedSize39816VariableSize259812784DatabaseBuffers1.049E+09RedoBuffers327680主要包括以下幾個局部：共享池(Sharedpool)共享池是SGA中最關(guān)鍵的內(nèi)存片段，特別是在性能和可伸縮性上。一個太小的共享池會扼殺性能，使系統(tǒng)停止，太大的共享池也會有同樣的效果，將會消耗大量的CPU來管理這個共享池。不正確的使用共享池只會帶來災(zāi)難。共享池主要又可以分為以下兩個局部：（1）SQL語句緩沖(LibraryCache)當(dāng)一個用戶提交一個SQL語句，Oracle會將這句SQL進行分析(parse)，這個過程類似于編譯，會消耗相對較多的時間。在分析完這個SQL，Oracle會把他的分析結(jié)果給保存在Sharedpool的LibraryCache中，當(dāng)數(shù)據(jù)庫第二次執(zhí)行該SQL時，Oracle自動跳過這個分析過程，從而減少了系統(tǒng)運行的時間。這也是為什么第一次運行的SQL比第二次運行的SQL要慢一點的原因。下面舉例說明parse的時間SQL>selectcount(*)fromscpass;COUNT(*)243Elapsed:00:00:00.08這是在Share_pool和Databuffer都沒有數(shù)據(jù)緩沖區(qū)的情況下所用的時間SQL>altersystemflushSHARED_POOL;Systemaltered.清空Share_pool，保存DatabufferSQL>selectcount(*)fromscpass;COUNT(*)243Elapsed:00:00:00.02SQL>selectcount(*)fromscpass;COUNT(*)243Elapsed:00:00:00.00從兩句SQL的時間差上可以看出該SQL的Parse時間約為00:00:00.02。對于保存在共享池中的SQL語句，可以從V$Sqltext、v$Sqlarea中查詢到，對于編程者來說，要盡量提高語句的重用率，減少語句的分析時間。一個設(shè)計的差的應(yīng)用程序可以毀掉整個數(shù)據(jù)庫的Sharepool，提高SQL語句的重用率必須先養(yǎng)成良好的變成習(xí)慣，盡量使用Bind變量。（2）數(shù)據(jù)字典緩沖區(qū)(DataDictionaryCache)顯而易見，數(shù)據(jù)字典緩沖區(qū)是ORACLE特地為數(shù)據(jù)字典準(zhǔn)備的一塊緩沖池，供ORACLE內(nèi)部使用。塊緩沖區(qū)高速緩存(DatabaseBufferCache)這些緩沖是對應(yīng)所有數(shù)據(jù)文件中的一些被使用到的數(shù)據(jù)塊。讓他們能夠在內(nèi)存中進行操作。在這個級別里沒有系統(tǒng)文件，戶數(shù)據(jù)文件，臨時數(shù)據(jù)文件，回滾段文件之分。也就是任何文件的數(shù)據(jù)塊都有可能被緩沖。數(shù)據(jù)庫的任何修改都在該緩沖里完成，并由DBWR進程將修改后的數(shù)據(jù)寫入磁盤[2]。這個緩沖區(qū)的塊根本上在兩個不同的列表中管理。一個是塊的“臟〞表(DirtyList)，需要用數(shù)據(jù)庫塊的書寫器(DBWR)來寫入，另外一個是不臟的塊的列表(FreeList)，一般的情況下，是使用最近最少使用(LeastRecentlyUsed,LRU)算法來管理。塊緩沖區(qū)高速緩存又可以細(xì)分為以下三個局部（Defaultpool,Keeppool,Recyclepool）。如果不是人為設(shè)置初始化參數(shù)(Init.ora)，ORACLE將默認(rèn)為Defaultpool。由于操作系統(tǒng)尋址能力的限制，不通過特殊設(shè)置，在32位的系統(tǒng)上，塊緩沖區(qū)高速緩存最大可以到達1.7G，在64位系統(tǒng)上，塊緩沖區(qū)高速緩存最大可以到達10G。重做日志緩沖區(qū)(Redologbuffer)重做日志文件的緩沖區(qū)，對數(shù)據(jù)庫的任何修改都按順序被記錄在該緩沖，然后由LGWR進程將它寫入磁盤。這些修改信息可能是DML語句，如(Insert,Update,Delete)，或DDL語句，如(Create,Alter,Drop等)。重做日志緩沖區(qū)的存在是因為內(nèi)存到內(nèi)存的操作比較內(nèi)存到硬盤的速度快很多，所以重作日志緩沖區(qū)可以加快數(shù)據(jù)庫的操作速度，但是考慮的數(shù)據(jù)庫的一致性與可恢復(fù)性，數(shù)據(jù)在重做日志緩沖區(qū)中的滯留時間不會很長。所以重作日志緩沖區(qū)一般都很小，大于3M之后的重作日志緩沖區(qū)已經(jīng)沒有太大的實際意義。Java程序緩沖區(qū)(JavaPool)Java的程序區(qū)，Oracle8I以后，Oracle在內(nèi)核中參加了對Java的支持。該程序緩沖區(qū)就是為Java程序保存的。如果不用Java程序沒有必要改變該緩沖區(qū)的默認(rèn)大小。大池(LargePool)大池的得名不是因為大，而是因為它用來分配大塊的內(nèi)存，處理比共享池更大的內(nèi)存，下面對象使用大池：MTS——在SGA的LargePool中分配UGA。語句的并行查詢(ParallelExecutionofStatements)——允許進程間消息緩沖區(qū)的分配，用來協(xié)調(diào)并行查詢效勞器。備份(Backup)——用于RMAN磁盤I/O緩存。2.1.2后臺進程(Backgroundprocess)后臺進程是Oracle的程序，用來管理數(shù)據(jù)庫的讀寫，恢復(fù)和監(jiān)視等工作。ServerProcess主要是通過他和userprocess進行聯(lián)系和溝通，并由他和userprocess進行數(shù)據(jù)的交換。在Unix機器上，Oracle后臺進程相對于操作系統(tǒng)進程，也就是說，一個Oracle后臺進程將啟動一個操作系統(tǒng)進程；在Windows機器上，Oracle后臺進程相對于操作系統(tǒng)線程，翻開任務(wù)管理器，我們只能看到一個ORACLE.EXE的進程，但是通過另外的工具，就可以看到包含在這里進程中的線程。在Unix上可以通過如下方法查看后臺進程：ps–ef|grepora_#ps-ef|grepora_|grepXCLUATOracle2943110Sep022:02ora_dbwr_SIDOracle2944410Sep020:03ora_ckpt_SIDOracle2944810Sep022:42ora_smon_SIDOracle2944210Sep023:25ora_lgwr_SIDOracle2942710Sep020:01ora_pmon_SIDOracle系統(tǒng)有5個根本進程他們是:DBWR(數(shù)據(jù)文件寫入進程)LGWR(日志文件寫入進程)SMON(系統(tǒng)監(jiān)護進程)PMON(用戶進程監(jiān)護進程)CKPT(檢查點進程,同步數(shù)據(jù)文件，日志文件，控制文件)（1）DBWR（DatabaseWriter數(shù)據(jù)寫入進程）將數(shù)據(jù)緩沖區(qū)的數(shù)據(jù)寫入數(shù)據(jù)文件，是負(fù)責(zé)數(shù)據(jù)緩沖區(qū)管理的一個后臺進程。當(dāng)數(shù)據(jù)緩沖區(qū)中的一數(shù)據(jù)被修改后，就標(biāo)記為dirty，DBWR進程將數(shù)據(jù)緩沖區(qū)中“臟〞

數(shù)據(jù)寫入數(shù)據(jù)文件，保持?jǐn)?shù)據(jù)緩沖區(qū)的“干凈〞。由于數(shù)據(jù)緩沖區(qū)的數(shù)據(jù)被用戶修改并占用，空閑數(shù)據(jù)緩沖區(qū)會不斷減少，當(dāng)用戶進程要從磁盤讀取數(shù)據(jù)塊到數(shù)據(jù)緩沖區(qū)卻無法找到足夠的空閑數(shù)據(jù)緩沖區(qū)時，DBWR將數(shù)據(jù)緩沖區(qū)內(nèi)容寫入磁盤，使用戶進程總可以得到足夠的空閑數(shù)據(jù)緩沖區(qū)。DBWR的作用：?管理數(shù)據(jù)緩沖區(qū)，以便用戶進程總能夠找到足夠的空閑緩沖區(qū)。?將所有修改后的緩沖區(qū)數(shù)據(jù)寫入數(shù)據(jù)文件。?使用LRU（最近最少使用）算法保持緩沖區(qū)數(shù)據(jù)是最近經(jīng)常使用的。?通過延遲寫來優(yōu)化磁盤I/O讀寫。（2）LGWR（LogWriter日志寫入進程）將日志數(shù)據(jù)從日志緩沖區(qū)寫入磁盤日志文件組。數(shù)據(jù)庫在運行時，如果對數(shù)據(jù)庫進行修改則產(chǎn)生日志信息，日志信息首先產(chǎn)生于日志緩沖區(qū)。當(dāng)日志到達一定數(shù)量時，由LGWR將日志數(shù)據(jù)寫入到日志文件組，再經(jīng)過日志切換,由歸檔進程（ARCH）將日志數(shù)據(jù)寫入歸檔進程（前提是數(shù)據(jù)庫運行在歸檔模式下）。數(shù)據(jù)庫遵循寫日志優(yōu)先原則，即在寫數(shù)據(jù)之前先寫日志。（3）SMON工作主要包含：去除臨時空間在系統(tǒng)啟動時，完成系統(tǒng)實例恢復(fù)聚結(jié)空閑空間從不可用的文件中恢復(fù)事務(wù)的活動OPS中失敗節(jié)點的實例恢復(fù)去除OBJ$表縮減回滾段使回滾段脫機（4）PMON主要用于去除失效的用戶進程，釋放用戶進程所用的資源。如PMON將回滾未提交的工作，釋放鎖，釋放分配給失敗進程的SGA資源。（5）CKPT同步數(shù)據(jù)文件，日志文件和控制文件，由于DBWR/LGWR的工作原理，造成了數(shù)據(jù)文件，日志文件，控制文件的不一至，這就需要CKPT進程來同步。CKPT會更新數(shù)據(jù)文件/控制文件的頭信息。CKPT工作的主要條件如下：a.在日志切換的時候。b.數(shù)據(jù)庫用Immediate,Transaction,Normal選項Shutdown數(shù)據(jù)庫的時候。c.根據(jù)初始化文件LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT、FAST_START_IO_TARGET、的設(shè)置數(shù)值來確定。d.用戶觸發(fā)。以下進程的啟動需要手工配置（1）ARCH當(dāng)數(shù)據(jù)庫以歸檔方式運行的時候，Oracle會啟動ARCH進程，當(dāng)重做日志文件被寫滿時，日志文件進行切換，舊的重做日志文件就被ARCH進程復(fù)制到一個/多個特定的目錄/遠(yuǎn)程機器。這些被復(fù)制的重做日志文件被叫做歸檔日志文件。（2）RECO負(fù)責(zé)解決分布事物中的故障。Oracle可以連接遠(yuǎn)程的多個數(shù)據(jù)庫，當(dāng)由于網(wǎng)絡(luò)問題，有些事物處于懸而未決的狀態(tài)。RECO進程試圖建立與遠(yuǎn)程效勞器的通信，當(dāng)故障消除后，RECO進程自動解決所有懸而未決的會話。（3）效勞進程ServerProcess效勞進程的分類：專用效勞進程(DedicatedServerProcess)一個效勞進程對應(yīng)一個用戶進程共享效勞進程(MultiTreadedServerProcess)一個效勞進程對應(yīng)多個用戶進程，輪流為用戶進程效勞。PGA&UGAPGA=ProcessGlobalAreaUGA=UserGlobalArea他保存了用戶的變量、權(quán)限、堆棧、排序空間等用戶信息，對于專用效勞器進程，UGA在PGA中分配。對于多線程進程，UGA在Largepool中分配。（4）用戶進程UserProcess在客戶端，將用戶的SQL語句傳遞給效勞進程2.2ORACLE數(shù)據(jù)庫ORACLE數(shù)據(jù)庫的組成——物理操作系統(tǒng)文件的集合。主要包括以下幾種。2.2.1控制文件（參數(shù)文件init.ora記錄了控制文件的位置）控制文件包括如下主要信息：數(shù)據(jù)庫的名字，檢查點信息，數(shù)據(jù)庫創(chuàng)立的時間戳，所有的數(shù)據(jù)文件，聯(lián)機日志文件，歸檔日志文件信息，備份信息等。有了這些信息，Oracle就知道那些文件是數(shù)據(jù)文件，現(xiàn)在的重做日志文件是哪些，這些都是系統(tǒng)啟動和運行的根本條件，所以他是Oracle運行的根本。如果沒有控制文件系統(tǒng)是不可能啟動的。控制文件是非常重要的，一般采用多個鏡相復(fù)制來保護控制文件，或采用RAID來保護控制文件?？刂莆募膯适В瑢⑹箶?shù)據(jù)庫的恢復(fù)變的很復(fù)雜。控制文件信息可以從V$Controlfile中查詢獲得。2.2.2數(shù)據(jù)文件（數(shù)據(jù)文件的詳細(xì)信息記載在控制文件中）可以通過如下方式查看數(shù)據(jù)文件SQL>selectnamefromv$datafile;NAME/u05/dbf/PROD/system_01.dbf/u06/dbf/PROD/temp_01.dbf/u04/dbf/PROD/users_01.dbf/u09/dbf/PROD/rbs_01.dbf/u06/dbf/PROD/applsys_indx_01.dbf/u05/dbf/PROD/applsys_data_01.dbf從以上可以看出，數(shù)據(jù)文件大致可以分為以下幾類：系統(tǒng)數(shù)據(jù)文件(system_01.dbf)存放系統(tǒng)表和數(shù)據(jù)字典，一般不放用戶的數(shù)據(jù)，但是用戶腳本，如過程，函數(shù)，包等卻是保存在數(shù)據(jù)字典中的。（數(shù)據(jù)字典是一些系統(tǒng)表或視圖，他存放系統(tǒng)的信息，他包括數(shù)據(jù)庫版本，數(shù)據(jù)文件信息，表與索引等段信息，系統(tǒng)的運行狀態(tài)等各種和系統(tǒng)有關(guān)的信息和用戶腳本信息。數(shù)據(jù)庫管理員可以通過對數(shù)據(jù)字典的查詢，就可以了解到Oracle的運行狀態(tài)。）回滾段文件(rbs_01.dbf)如果數(shù)據(jù)庫進行對數(shù)據(jù)的修改，那么就必須使用回滾段，回滾段是用來臨時存放修改前的數(shù)據(jù)(BeforeImage)?；貪L段通常都放在一個單獨的表空間上（回滾表空間），防止表空間碎片化，這個表空間包含的數(shù)據(jù)文件就是回滾數(shù)據(jù)文件。臨時數(shù)據(jù)文件(temp_01.dbf)主要存放用戶的排序等臨時數(shù)據(jù)，與回滾段相似，臨時段也容易引起表空間碎片化，而且沒有方法在一個永久表空間上開辟臨時段，所以就必須有一個臨時表空間，它所包含的數(shù)據(jù)文件就是臨時數(shù)據(jù)文件，主要用于不能在內(nèi)存上進行的排序操作。我們必須為用戶指定一個臨時表空間。用戶數(shù)據(jù)文件(/applsys_data_01.dbf,applsys_indx_01.dbf)存放用戶數(shù)據(jù)，這里列舉了兩類常見的用戶型數(shù)據(jù)，一般數(shù)據(jù)和索引數(shù)據(jù)，一般來說，如果條件許可的話，可以考慮放在不同的磁盤上。2.2.3重做日志文件（聯(lián)機重做日志）用戶對數(shù)據(jù)庫進行的任何操作都會記錄在重做日志文件。在了解重做日志之前必須了解重做日志的兩個概念，重做日志組和重做日志組成員(Member)，一個數(shù)據(jù)庫中至少要有兩個日志組文件，一組寫完后再寫另一組，即輪流寫。每個日志組中至少有一個日志成員，一個日志組中的多個日志成員是鏡相關(guān)系，有利于日志文件的保護，因為日志文件的損壞，特別是當(dāng)前聯(lián)機日志的損壞，對數(shù)據(jù)庫的影響是巨大的。聯(lián)機日志組的交換過程叫做切換，需要特別注意的是，日志切換在一個優(yōu)化效果不好的數(shù)據(jù)庫中會引起臨時的“掛起〞。通過v$log可以查看日志組，v$logfile可以查看具體的成員文件。2.2.4歸檔日志文件Oracle可以運行在兩種模式之中，歸檔模式和不歸檔模式[4]。如果不用歸檔模式，當(dāng)然，就不會有歸檔日志，但是，系統(tǒng)將不會是一個實用系統(tǒng)，特別是不能用于生產(chǎn)系統(tǒng)，因為此系統(tǒng)可能會喪失數(shù)據(jù)。但是在歸檔模式中，為了保存用戶的所有修改，在重做日志文件切換后和被覆蓋之間系統(tǒng)將他們另外保存成一組連續(xù)的文件系列，該文件系列就是歸檔日志文件。有人或許會說，歸檔日志文件占領(lǐng)了用戶大量的硬盤空間，但是具體想一想，用戶是愿意浪費一點磁盤空間來保護數(shù)據(jù)，還是愿意喪失數(shù)據(jù)呢？顯而義見，我們需要保證我們的數(shù)據(jù)的平安性。其實，歸檔并不是一直占領(lǐng)用戶的磁盤空間，用戶可以把它備份到磁帶上，或則刪除上一次完整備份前的所有日志文件。2.2.5初始化參數(shù)文件initSID.ora或init.ora文件，因為版本的不一樣，其位置也可能會不一樣。初始化文件記載了許多數(shù)據(jù)庫的啟動參數(shù)，如內(nèi)存，控制文件，進程數(shù)等，在數(shù)據(jù)庫啟動的時候加載（Nomount時加載），初始化文件記錄了很多重要參數(shù)，對數(shù)據(jù)庫的性能影響很大。2.2.6其他文件密碼文件用于Oracle的具有sysdba權(quán)限用戶的認(rèn)證.其它日志文件（1）報警日志文件（alert.log或alrt.ora）記錄數(shù)據(jù)庫啟動，關(guān)閉和一些重要的出錯信息。數(shù)據(jù)庫管理員應(yīng)該經(jīng)常檢查這個文件，并對出現(xiàn)的問題作出即使的反應(yīng)。可以通過以下SQL找到他的路徑selectvaluefromv$PARAMETERwherename="background_dump_dest";（2）后臺或用戶跟蹤文件系統(tǒng)進程或用戶進程出錯前寫入的信息，一般不可能讀懂，可以通過ORACLE的TKPROF工具轉(zhuǎn)化為可以讀懂的格式。對于系統(tǒng)進程產(chǎn)生的跟蹤文件與報警日志文件的路徑一樣，用戶跟蹤文件的路徑，你可以通過以下SQL找到他的路徑selectvaluefromv$PARAMETERwherename="user_dump_dest";3Oracle數(shù)據(jù)庫常見的瓶頸問題Oracle數(shù)據(jù)庫系統(tǒng)提供了相應(yīng)的應(yīng)用工具，管理人員可以方便地對Oracle進行有效的管理。從而建立一個良好的環(huán)境，使系統(tǒng)發(fā)揮最大的效能[5]。但是，有時用戶還是抱怨系統(tǒng)運行速度慢，對用戶查詢反應(yīng)的時間長，即出現(xiàn)所謂的瓶頸效應(yīng)。這就需要管理人員對Oracle進行調(diào)整。在Oracle系統(tǒng)中比較常見的瓶頸出現(xiàn)在以下部件中：3.1中央處理器(CPU)CPU是計算機在運行中最重要的局部，如果CPU總是運行在極限速度下，那么我們說CPU成為系統(tǒng)的瓶頸，尤其在多用戶同時使用系統(tǒng)時，CPU的計算能力尤為重要。盡管多數(shù)情況下，都是由操作系統(tǒng)的內(nèi)核來管理分配有效的CPU給RACLE數(shù)據(jù)庫進程使用。但是，仍然會出現(xiàn)過多的應(yīng)用進程對CPU使用周期劇烈競爭的現(xiàn)象。3.2內(nèi)存內(nèi)存是計算機程序運行的場所，處于等待狀態(tài)數(shù)據(jù)和請求信息也都存放在內(nèi)存中。如果內(nèi)存缺乏，cache(高速緩存區(qū))的命中率就不會太高，大局部所需數(shù)據(jù)不在cache中，因此出現(xiàn)了瓶頸問題。3.3存儲設(shè)備諸如硬盤驅(qū)動器、CD-ROM等設(shè)備，用于存儲系統(tǒng)所需信息，計算機系統(tǒng)每秒能處理的最大I/O數(shù)量是固定的，當(dāng)CPU和內(nèi)存要求的I/O速度大于系統(tǒng)的速率時，存儲設(shè)備的瓶頸就會發(fā)生。3.4網(wǎng)絡(luò)當(dāng)網(wǎng)絡(luò)負(fù)擔(dān)太重，網(wǎng)絡(luò)部件速度跟不上，不可能把數(shù)據(jù)傳輸?shù)酶?，網(wǎng)絡(luò)瓶頸就會發(fā)生。3.5其它由于其它系統(tǒng)硬件或軟件的原因而導(dǎo)致的瓶頸，如應(yīng)用系統(tǒng)本身的設(shè)計問題，超出系統(tǒng)吞吐量(在一定時間內(nèi)系統(tǒng)處理數(shù)據(jù)的能力)的限制等造成的瓶頸。對于Oracle數(shù)據(jù)庫系統(tǒng)的存在的瓶頸問題的解決，其實最終還是歸結(jié)為數(shù)據(jù)庫性能優(yōu)化問題。實際上，為了保證ORACLE數(shù)據(jù)庫運行在最正確的性能狀態(tài)下，在信息系統(tǒng)開發(fā)之前就應(yīng)該考慮數(shù)據(jù)庫的優(yōu)化策略。優(yōu)化策略一般包括效勞器操作系統(tǒng)參數(shù)調(diào)整、ORACLE數(shù)據(jù)庫參數(shù)調(diào)整、網(wǎng)絡(luò)性能調(diào)整、應(yīng)用程序SQL語句分析及設(shè)計等幾個方面，其中應(yīng)用程序的分析與設(shè)計是在信息系統(tǒng)開發(fā)之前完成的。分析評價ORACLE數(shù)據(jù)庫性能主要有數(shù)據(jù)庫吞吐量、數(shù)據(jù)庫用戶響應(yīng)時間兩項指標(biāo)[6]。數(shù)據(jù)庫吞吐量是指單位時間內(nèi)數(shù)據(jù)庫完成的SQL語句數(shù)目：數(shù)據(jù)庫用戶響應(yīng)時間是指用戶從提交SQL語句開始到獲得結(jié)果的那一段時間。數(shù)據(jù)庫用戶響應(yīng)時間又可以分為系統(tǒng)效勞時間和用戶等待時間兩項，即：數(shù)據(jù)庫用戶響應(yīng)時間=系統(tǒng)效勞時間+用戶等待時間，上述公式告訴我們，獲得滿意的用戶響應(yīng)時間有兩個途徑：一是減少系統(tǒng)效勞時間，即提高數(shù)據(jù)庫的吞吐量：二是減少用戶等待時間，即減少用戶訪問同一數(shù)據(jù)庫資源的沖突率。4CPU參數(shù)的調(diào)整CPU是效勞器的一項重要資源，效勞器良好的工作狀態(tài)是在工作頂峰時C使用率在90%以上。如果空閑時間CPU使用率就在90%以上，說明效勞器缺資源，如果工作頂峰時CPU使用率仍然很低，說明效勞器CPU資源還比較富玉。使用操作相同命令可以看到CPU的使用情況，一般UNLK操作系統(tǒng)的服可以使用sar一命令查看CPU的使用率，NT操作系統(tǒng)的效勞器，可以使用N能管理器來查看CPU的使用率。數(shù)據(jù)庫管理員可以通過查看v$sysstat數(shù)據(jù)字典中“CPUusedbythissession〞統(tǒng)計項得知ORACLE數(shù)據(jù)庫使用的CPU時間，查看“OSUserlevelCPUtime〞統(tǒng)計項得知操作系統(tǒng)用戶態(tài)下的CPU時間，查看“OSSystemcallCPUtime〞統(tǒng)計項得知操作系統(tǒng)系統(tǒng)態(tài)下的CPU時間，操作系統(tǒng)總的CPU時間就是用戶態(tài)和系統(tǒng)態(tài)時間之和，如果ORACLE數(shù)據(jù)庫使用的CPU時間占操作系統(tǒng)總的CPU時間90%以上，說明效勞器CPU根本上被ORACLE數(shù)據(jù)庫使用著，這是合理，反之，說明效勞器CPU被其它程序占用過多，ORACLE數(shù)據(jù)庫無法得到更多的CPU時間。數(shù)據(jù)庫管理員還可以通過查看v$sesstat數(shù)據(jù)字典來獲得當(dāng)前連接ORACLE數(shù)據(jù)庫各個會話占用的CPU時間，從而得知什么會話耗用效勞器CPU比較多[7]。出現(xiàn)CPU資源缺乏的情況是很多的：SQL語句的重解析、低效率的SQL語句、鎖沖突都會引起CPU資源缺乏。（1）數(shù)據(jù)庫管理員可以執(zhí)行下述語句來查看SQL語句的解析情況。SELECT*FROMV$SYSSTATWHERENAMEIN('parsetimecpu','parsetimeelapsed','parsecount(hard)');這里parsetimecpu是系統(tǒng)效勞時間，parsetimeelapsed是響應(yīng)時間，用戶等待時間waitetime=parsetimeelapsed-parsetimecpu。由此可以得到用戶SQL語句平均解析等待時間=waitetime/parsecount。這個平均等待時間應(yīng)該接近于0，如果平均解析等待時間過長，數(shù)據(jù)庫管理員可以通過下述語句來發(fā)現(xiàn)是什么SQL語句解析效率比較低。程序員可以優(yōu)化這些語句，或者增加ORACLE參數(shù)SESSION_CACHED_CURSORS的值。SELECTSQL_TEXT,PARSE_CALLS,EXECUTIONSFROMV$SQLAREAORDERBYPARSE_CALLS.（2）數(shù)據(jù)庫管理員還可以通過下述語句查看低效率的SQL語句，優(yōu)化這些語句也有助于提高CPU的利用率。SELECTBUFFER_GETS,EXECUTIONS,SQL_TEXTFROMV$SQLAREA.（3）數(shù)據(jù)庫管理員可以通過v$systen_event數(shù)據(jù)字典中的“l(fā)atchfree〞統(tǒng)計項查看ORACLE數(shù)據(jù)庫的沖突情況，如果沒有沖突的話，latchfree查詢出來沒有結(jié)果。如果沖突太大的話，數(shù)據(jù)庫管理員可以降低spin_count參數(shù)值，來消除高的CPU使用率。5內(nèi)存參數(shù)的調(diào)整內(nèi)存參數(shù)的調(diào)整主要是指ORACLE數(shù)據(jù)庫的系統(tǒng)全局區(qū)(SGA)的調(diào)整。SGA主要由三局部構(gòu)成:共享池、數(shù)據(jù)緩沖區(qū)、日志緩沖區(qū)。系統(tǒng)全局區(qū)(SystemGlobalArea，SGA)，SGA隨著不同的環(huán)境而不同，沒有一種普通的最正確方案，我們在設(shè)置它之前要先考慮以下的幾個方面：物理內(nèi)存多大；操作系統(tǒng)是那種及占多大的內(nèi)存，數(shù)據(jù)庫系統(tǒng)是文件系統(tǒng)還是裸設(shè)備；數(shù)據(jù)庫運行的模式[8]。SGA包括：Fixedsize、VariableBuffers、RedoBuffers。SGA占有物理內(nèi)存的比例沒有嚴(yán)格的規(guī)定，只能遵從一般的規(guī)則：SGA占據(jù)物理內(nèi)存的40%~60%左右。如果通過直觀的公式化來表達則為：OS使用內(nèi)存+SGA+并發(fā)進程數(shù)*(sort_area_size+Hash_area_size+2M)<0.7RAM，這個公式也只是參考，不必拘于此，實際情況可以自由發(fā)揮。初始化參數(shù)文件中的一些參數(shù)對SGA的大小有決定性的影響。參數(shù)Db_block_Buffers(SGA中存儲區(qū)高速緩存的緩沖區(qū)數(shù)目)，參數(shù)Shared_pool_size(分配給共享SQL區(qū)的字節(jié)數(shù))，是SGA大小的主要影響者。DatabaseBuffers參數(shù)是SGA大小和數(shù)據(jù)庫性能的最重要的決定因素。該值較高，可以提高系統(tǒng)的命中率，減少I/O。每個緩沖區(qū)的大小等于參數(shù)Db_block_size的大小。Oracle數(shù)據(jù)庫塊以字節(jié)表示大小。OracleSGA區(qū)共享池局部由庫高速緩存、字典高速緩存及其他一些用戶和效勞器會話信息組成，共享池是最大的消耗成分。調(diào)整SGA區(qū)各個結(jié)構(gòu)的大小，可以極大地提高系統(tǒng)的性能。5.1共享池的構(gòu)成共享池由兩局部構(gòu)成：共享SQL區(qū)和數(shù)據(jù)字典緩沖區(qū)。5.1.1共享SQL區(qū)共享SQL區(qū)是存放用戶SQL命令的區(qū)域，數(shù)據(jù)字典緩沖區(qū)存放數(shù)據(jù)庫運行的動態(tài)信息。數(shù)據(jù)庫管理員通過執(zhí)行下述語句來查看共享SQL區(qū)的使用率。這個使用率應(yīng)該在90%以上，否則需要增加共享池的大小。Select(sum(pins-reloads))/sum(pins)‘LibCache’fromv$librarycache;5.1.2數(shù)據(jù)字典緩沖區(qū)(DictionaryCACHE)數(shù)據(jù)字典緩存區(qū)的大小由數(shù)據(jù)庫內(nèi)部管理，大小由參數(shù)Share_pool_size來設(shè)置。數(shù)據(jù)字典高速緩存包括了有關(guān)數(shù)據(jù)庫的結(jié)構(gòu)、用戶、實體信息等。數(shù)據(jù)字典的命中率對系統(tǒng)有很大的影響。命中率的計算中，Getmisses表示失敗次數(shù)，gets表示成功次數(shù)，數(shù)據(jù)庫管理員還可以執(zhí)行下述語句查看數(shù)據(jù)字典緩沖區(qū)的使用率，這個使用率也應(yīng)該在90%以上，否則需要增加共享池的大小。select(sum(gets-getmisses-usege-fixed))/sum(gets)Row‘Cache’fromv$rowcache;5.2數(shù)據(jù)緩沖區(qū)在內(nèi)存的配置中把別的參數(shù)設(shè)置完成后，應(yīng)該把能給的都給Databuffers。Oracle在運行期間向數(shù)據(jù)庫高速緩存讀寫數(shù)據(jù)，高速緩存命中表示信息已在內(nèi)存中，高速緩存失敗意味著Oracle必需進行磁盤I/O。保持高速緩存失敗率最小的關(guān)鍵是確保高速緩存的大小。數(shù)據(jù)庫管理員可以通過下述語句來查看數(shù)據(jù)庫數(shù)據(jù)緩沖區(qū)的使用情況[9]。查詢出來的結(jié)果可以計算出來數(shù)據(jù)緩沖區(qū)的使用命中率=1-(physicalreads/(dbblockgets+consistentgets))。SELECTname,valueFROMv$sysstatWHEREnameIN(‘dbblockgets’,‘consistentgets’,‘physicalreads’);這個命中率應(yīng)該在90%以上，否則需要增加數(shù)據(jù)緩沖區(qū)的大小。5.3日志緩沖區(qū)數(shù)據(jù)庫管理員可以通過執(zhí)行下述語句，查看日志緩沖區(qū)的使用情況。查詢出的結(jié)果可以計算出日志緩沖區(qū)的申請失敗率Selectname,valuefromv$sysstatWherenamein(‘redoentries’,‘redologspacerequests’);申請失敗率=requests/entries，申請失敗率應(yīng)該接近于0，否則說明日志緩沖區(qū)開設(shè)太小，需要增加ORACLE數(shù)據(jù)庫的日志緩沖區(qū)。5.4Oracle10g的內(nèi)存優(yōu)化例子無論是一個剛?cè)腴T的DBA還是一個經(jīng)驗豐富的DBA，肯定至少看到過一次類似以下的錯誤：ORA-04031:unabletoallocate2216bytesofsharedmemory("sharedpool"......或者這種錯誤：ORA-04031:unabletoallocateXXXXbytesofsharedmemory("largepool","unknownobject","sessionheap","frame")或者可能這種錯誤：ORA-04031:unabletoallocatebytesofsharedmemory("sharedpool","unknownobject","joxlod:inith","JOX:ioc_allocate_pal")第一種錯誤的原因很明顯：分配給共享池的內(nèi)存缺乏以滿足用戶請求。（在某些情況下，原因可能不是池本身的大小，而是未使用綁定變量導(dǎo)致的過多分析造成的碎片。）其它的錯誤分別來自大型池和Java池的空間缺乏[10]。需要解決這些錯誤情況，而不作任何與應(yīng)用程序相關(guān)的修改。那么有哪些方案可選呢？問題是如何在Oracle例程所需的所有池之間劃分可用的內(nèi)存。一個Oracle例程的系統(tǒng)全局區(qū)域(SGA)包含幾個內(nèi)存區(qū)域（包括緩沖高速緩存、共享池、Java池、大型池和重做日志緩沖）。這些池在\o"操作系統(tǒng)"操作系統(tǒng)的內(nèi)存空間中占據(jù)了固定的內(nèi)存數(shù)；它們的大小由DBA在初始化參數(shù)文件中指定。假定決定了這些池的值分別是2GB、1GB、1GB和1GB。將設(shè)置以下初始化參數(shù)來為數(shù)據(jù)庫例程規(guī)定池的大小。db_cache_size=2gshared_pool_size=1glarge_pool_size=1gjava_pool_size=1g我相信一定會存在有疑慮。在實際中，沒有人能夠為這些池指定確切的內(nèi)存數(shù)——它們太依賴于數(shù)據(jù)庫內(nèi)部的處理，而處理的特性隨時在變化。下面是一個例如場景。假定有一個典型的、大局部屬于OLTP的數(shù)據(jù)庫，并且為緩沖高速緩存分配的專用內(nèi)存比為純OLTP數(shù)據(jù)庫（現(xiàn)在已經(jīng)很少見了）分配的要少。用戶放開了一些非常大的全表掃描，以創(chuàng)立當(dāng)天的結(jié)束報表。Oracle9i數(shù)據(jù)庫提供了在線修改內(nèi)存分配的功能，但由于提供的總物理內(nèi)存有限，有可能從大型池和Java池中取出一些內(nèi)存：altersystemsetdb_cache_size=3gscope=memory;altersystemsetlarge_pool_size=512mscope=memory;altersystemsetjava_pool_size=512mscope=memory;這個解決方案能夠很好地工作一段時間，但是接著夜間的RMAN作業(yè)（它們使用大型池）開始了，大型池將立即出現(xiàn)內(nèi)存缺乏。同樣，可能從數(shù)據(jù)庫高速緩存中取出一些內(nèi)存來補充大型池，以挽救這種局面。RMAN作業(yè)完成，然后啟動一個廣泛使用Java的批處理程序，接著開始看到與Java池相關(guān)的錯誤。因此，再次重新分配池，以滿足Java池和數(shù)據(jù)庫高速緩存上的內(nèi)存需求：altersystemsetdb_cache_size=2Gscope=memory;altersystemsetlarge_pool_size=512Mscope=memory;altersystemsetjava_pool_size=1.5Gscope=memory;OLTP作業(yè)恢復(fù)在線，這個循環(huán)又完全重復(fù)！解決這種惡性循環(huán)的一種替代方法是永久設(shè)置每個池的最大需求。不過，這么做的話，分配的總的SGA可能超出可用的內(nèi)存——從而在為每個池分配的內(nèi)存數(shù)缺乏時，將增加交換和分頁的風(fēng)險。人工重新分配的方法（雖然不實際）目前看起來很不錯。另一種替代方法是將值設(shè)為可接受的最小值。不過，當(dāng)需求增長且內(nèi)存不能完全滿足時，性能將受到影響。在所有這些例如中，分配給SGA的總內(nèi)存保持不變，而池之間的內(nèi)存分配根據(jù)即時的需求進行修改。如果RDBMS將自動探測來自用戶的需求并相應(yīng)地重新分布內(nèi)存分配，那不是很好嗎？Oracle數(shù)據(jù)庫10g中的自動共享內(nèi)存管理特性正好能夠?qū)崿F(xiàn)這一目的。可以決定SGA的總大小，然后設(shè)置一個名稱為SGA_TARGET的參數(shù)，這個參數(shù)決定SGA的總大小。SGA內(nèi)部的各個池將根據(jù)工作負(fù)載動態(tài)地進行配置。實現(xiàn)自動內(nèi)存分配僅僅需要SGA_TARGET參數(shù)的一個非零值。5.4.1設(shè)置自動共享內(nèi)存管理首先，確定SGA的總大小。可以通過確定現(xiàn)在分配了多少內(nèi)存來估計這個值。SQL>selectsum(value)/1024/1024fromv$sga;SUM(VALUE)/1024/1024500此時SGA的當(dāng)前總大小近似為500MB，并且這個值將變?yōu)镾GA_TARGET的值。接下來，執(zhí)行語句：altersystemsetsga_target=500Mscope=both;這種方法不需要為各個池設(shè)置不同值；因而，將需要在參數(shù)文件中使它們的值為零或全部刪除它們。shared_pool_size=0large_pool_size=0java_pool_size=0db_cache_size=0再循環(huán)數(shù)據(jù)庫，使這些值生效。這個人工過程還可以通過EnterpriseManager10g實施。從數(shù)據(jù)庫主頁中，選擇"Administration"選項卡，然后選擇"MemoryParameters"。對于人工配置的內(nèi)存參數(shù)，將顯示標(biāo)記為"Enable"的按鈕，以及所有人工配置的池的值。單擊"Enable"按鈕，啟用自動共享內(nèi)存管理特性。企業(yè)管理器將完成剩下的工作。在配置了自動內(nèi)存分配之后，可以利用以下命令檢查它們的大?。篠QL>selectcurrent_sizefromv$buffer_pool;CURRENT_SIZE340SQL>selectpool,sum(bytes)/1024/1024Mbytesfromv$sgastat

groupbypool;POOLMBYTESjavapool4largepool4sharedpool148正如所看到的，所有的池都從500MB的總目標(biāo)大小中自動進行分配。如圖2所示緩沖高速緩存大小是340MB，Java池是4MB，大型池是4MB，共享池是148MB。它們合起來總的大小為(340+4+4+148=)496MB，近似與500MB的目標(biāo)SGA的大小相同。圖2池的初始分配現(xiàn)在假定提供應(yīng)Oracle的主機內(nèi)存從500MB減少為300MB，這意味著必須減少總SGA的大小?？梢酝ㄟ^減小目標(biāo)SGA大小來反映這種變化。altersystemsetsga_target=300Mscope=both;現(xiàn)在查看各個池，可以看到：SQL>selectcurrent_sizefromv$buffer_pool;CURRENT_SIZE244SQL>selectpool,sum(bytes)/1024/1024Mbytesfromv$sgastatgroupbypool;POOLMBYTESjavapool4largepool4sharedpool44占用的總大小是240+4+4+44=296MB，接近于目標(biāo)的300MB。如圖3所示，當(dāng)SGA_TARGET改變時，如何自動重新分配池。圖3在將SGA大小減少到300MB之后重新分配池這些池的大小是動態(tài)的。池將根據(jù)工作負(fù)載擴展，以容納需求的增長，或縮小以容納另一個池的擴展。這種擴展或縮小自動發(fā)生，無需DBA的干預(yù)，這與本文開頭的例如不同。讓我們暫時返回到那個場景，假定在初始分配后，RMAN作業(yè)啟動，指示需要一個更大的大型池，大型池將從4MB擴展到40MB，以容納需求。這個額外的36MB將從數(shù)據(jù)庫緩沖中劃出，數(shù)據(jù)庫塊緩沖將縮小，如圖4所示。圖4在對大型池的需求增長之后經(jīng)過重新分配的池池的大小變化基于系統(tǒng)上的工作負(fù)載，因此不需要為最壞的情況調(diào)整池的大小——它們將根據(jù)需求的增長自動調(diào)整。此外，SGA的總大小始終在由SGA_TARGET指定的最大值之內(nèi)，因此不存在使內(nèi)存需求的增長比例失調(diào)（這將導(dǎo)致分頁和交換）的風(fēng)險。可以動態(tài)地將SGA_TARGET增加至絕對最大值,這個絕對最大值是通過調(diào)整參數(shù)SGA_MAX_SIZE指定的。5.4.2不受影響的池SGA中的一些池不受動態(tài)大小調(diào)整的影響，但是必須顯式指定這些池[11]。其中值得注意的是非標(biāo)準(zhǔn)塊大小的緩沖池，以及KEEP池或RECYCLE池的非默認(rèn)塊大小。如果數(shù)據(jù)庫有一個塊大小為8K，而想要配置2K、4K、16K和32K塊大小的池，那么必須手動設(shè)置它們。它們的大小將保持不變；它們將不會根據(jù)負(fù)載縮小或擴展。當(dāng)使用多種大小的緩沖池、KEEP池和RECYCLE池時，應(yīng)當(dāng)考慮這個因素。此外，日志緩沖不受內(nèi)存調(diào)整的影響——不管工作負(fù)載如何，在參數(shù)log_buffer中設(shè)定的值是不變的。(在10g中，還可以在SGA中定義一種新的池：流池(streampool)，它用參數(shù)streams_pool_size進行設(shè)置。該池也不受自動內(nèi)存調(diào)整的影響。）這就產(chǎn)生了一個問題，如果需要一個非默認(rèn)塊大小的池，而且想自動管理其它的池，那么該怎么辦？如果指定了這些非自動調(diào)整的參數(shù)中的任意一個（如db_2k_cache_size），那么它們的總大小將從SGA_TARGET值中減去，以計算自動調(diào)整的參數(shù)值，以使SGA的總大小保持不變。例如，假設(shè)值看起來像這樣。sga_target=500Mdb_2k_cache_size=50M其余的池參數(shù)未設(shè)置。50MB的2KB緩沖池為自動調(diào)整的池（如默認(rèn)塊大小緩沖池(db_cache_size)、共享池、Java池和大型池）保存了450MB。當(dāng)以一種方法動態(tài)地調(diào)整不可自動調(diào)整的參數(shù)（如2KB塊大小池）——這種方法將影響到可自動調(diào)整局部的大小，可自動調(diào)整的局部將重新調(diào)整。例如，將db_2k_cache_size的值從50MB提高到100MB只為可自動調(diào)整的參數(shù)剩余400MB。因此，如圖5所示,可調(diào)整的池（如共享池、大型池、Java池和默認(rèn)緩沖池）自動縮小，以將它們的總大小從450MB減少到400MB。圖5配置非自動緩沖參數(shù)的效果但如果有足夠的可用內(nèi)存，或者上述風(fēng)險可能不是那么明顯，那應(yīng)該怎么辦？如果這樣的話，可以通過不指定參數(shù)文件中的參數(shù)SGA_TARGET、通過在文件中將其設(shè)為0，或者通過使用ALTERSYSTEM動態(tài)地將其修改為0來關(guān)閉自動大小調(diào)整。當(dāng)SGA_TARGET被設(shè)為0時，池的當(dāng)前值被自動設(shè)為它們的參數(shù)。5.4.3使用EnterpriseManager還可以使用EnterpriseManager10g來處理這些參數(shù)。從數(shù)據(jù)庫主頁中單擊超鏈接"MemoryParameters"，如圖6所示。圖6在EnterpriseManager中調(diào)整自動共享內(nèi)存管理注意紅圈中的工程：數(shù)據(jù)庫在AutomaticSharedMemoryManagement模式下運行，總大小為564MB，與在參數(shù)SGA_TARGET中指定的值相同?？梢栽诖诵薷乃缓髥螕鬉pply按鈕接受這些值，可調(diào)整的參數(shù)將自動調(diào)整。為每個池指定一個最小值，假定將SGA_TARGET設(shè)為600MB，并且各個池已自動分配。表1各個池的最小值池大?。∕B）緩沖池404Java池4大型池4共享池148看上述值，可能推斷4MB的Java池和大型池可能有點缺乏，這個值在運行時無疑需要增加。因此，可能想確保這些池至少在最初時具有更高的值，比方說，分別為8MB和16MB?？梢酝ㄟ^在參數(shù)文件中顯式地指定這些池的值或動態(tài)使用ALTERSYSTEM來實現(xiàn)這一目的（如下所示）。altersystemsetlarge_pool_size=16M;altersystemsetjava_pool_size=8M;現(xiàn)在查看這些池，可以看到SQL>selectpool,sum(bytes)/1024/1024Mbytesfromv$sgastat

groupbypool;POOLMBYTESjavapool8largepool16sharedpool148SQL>selectcurrent_sizefromv$buffer_pool;CURRENT_SIZE388表2池的重新分配顯示如下池大小（MB）緩沖池388Java池8大型池16共享池148如表2所示Java池和大型池被重新配置為8MB和16MB，并且為了使總的SGA保持在600MB以下，緩沖池已從404MB減少為388MB。當(dāng)然，這些池仍然由自動共享內(nèi)存管理控制——它們的大小將根據(jù)需求縮小或擴展。顯式指定的值為池的大小設(shè)定了一個下限；它們將永遠(yuǎn)不會縮小到低于這個界限。5.4.4小結(jié)OracleSGA中的各種池的內(nèi)存需求不是靜態(tài)的。相反，它們根據(jù)系統(tǒng)上的需求而變化。Oracle數(shù)據(jù)庫10g中的自動共享內(nèi)存管理特性通過動態(tài)地將資源重新分配到最需要它們的地方同時施加一個指定的最大值以防止分頁和交換，使得Oracle10g數(shù)據(jù)庫的內(nèi)存得到更好的優(yōu)化配置。6調(diào)整I/OOracleRDBMS的性能與操作系統(tǒng)和I/O子系統(tǒng)密切相關(guān)。某些時候，操作系統(tǒng)會阻礙Oracle的性能。Oracle幾乎就是它自己的操作系統(tǒng)。管理員必須利用操作系統(tǒng)來實現(xiàn)幾個關(guān)鍵任務(wù)，這些任務(wù)包括內(nèi)存管理系統(tǒng)、進程調(diào)度程序和I/O子系統(tǒng)等。在操作系統(tǒng)的這些任務(wù)中，I/O子系統(tǒng)及I/O子系統(tǒng)的性能對OracleRDBMS的性能是非常重要的[12]。Oracle的主要功能是為數(shù)據(jù)庫用戶提供和維護數(shù)據(jù)；數(shù)據(jù)庫的數(shù)據(jù)(不在內(nèi)存中時)就是存放在I/O子系統(tǒng)中的。Oracle的性能是和I/O子系統(tǒng)的性能直接相關(guān)的。6.1定位I/O性能問題如何確定系統(tǒng)的主要問題是I/O問題，并定位存在I/O性能瓶頸的設(shè)備是解決I/O性能問題的第一步。使用操作系統(tǒng)的監(jiān)控工具可以實時監(jiān)控I/O的情況。第一種方法是使用vrnstat工具，使用該工具，可以查看b列的值，如果該值比較大，說明等待I/O的進程比較多，I/O可能存在問題，如圖7所示。圖7vmstat輸出圖8sar輸出然后，通過sar[1]命令或者iostat命令可以進一步確認(rèn)，如圖8所示，從上圖中發(fā)現(xiàn)wio值長時間高于40（這個值是個經(jīng)驗值，根據(jù)不同的系統(tǒng)，這個值可以調(diào)整），這說明I/O等待比較嚴(yán)重。此時可以通過sar-d命令來監(jiān)控到底哪些I/O設(shè)備存在性能問題。如果發(fā)現(xiàn)某個設(shè)備的繁忙度長時間超過90%，那就說明該設(shè)備比較繁忙，如果該設(shè)備的平均效勞時間比較大或者比其它設(shè)備高很多。那么就說明該設(shè)備存在性能問題。通過Oracle的statspack工具也可以檢查系統(tǒng)的I/O問題，如果系統(tǒng)的性能不佳，并且從報告中看到的dbread等待事件是系統(tǒng)等待事件中排在前幾位的事件，占系統(tǒng)總等待時間的比例比較高，那么系統(tǒng)很可能存在I/O性能問題?？梢酝ㄟ^檢查文件I/O情況來進一步確認(rèn)并找出存在性能問題的設(shè)備。方法是通過檢查文件I/O中的平均讀響應(yīng)時間，如果某個文件的平均讀響應(yīng)時間超過20毫秒，那么說明該文件所在的設(shè)備可能存在性能問題。應(yīng)該注意的是，20毫秒是一個相對的參數(shù)，在不同的應(yīng)用環(huán)境下可能選擇不同的參考值。通過比對操作系統(tǒng)的情況，數(shù)據(jù)庫管理員應(yīng)該很快就能確定所管理的系統(tǒng)的平均讀響應(yīng)時間和操作系統(tǒng)I/O情況的對應(yīng)關(guān)系。檢查讀平均響應(yīng)時間的時候還要注意幾個問題。第一個問題是在報告時間區(qū)域內(nèi)的I/O量，如果某個文件在報告時間區(qū)間內(nèi)的I/O數(shù)量很小，那么此平均響應(yīng)時間可能缺乏代表性，可以通過檢查存放在相同設(shè)備上的其它文件來進一步確認(rèn)。另外一種情況是平均每次讀的數(shù)據(jù)量比較多（每次讀的塊數(shù)比較多），那么略高的平均讀響應(yīng)時間也是正常的。下面圖3中的數(shù)據(jù)就是從I/O存在問題的數(shù)據(jù)庫上取下的statspack數(shù)據(jù)。圖9statspack報告可以看出dbread是等待事件的第一位事件，并且占整個等待事件的60%以上。這是一個典型的I/O存在性能瓶頸的例子，通過statspack報告的“文件I/O性能分析〞數(shù)據(jù)中，可以進一步檢查到底哪些文件出現(xiàn)了問題。另外，bufferbusywaits等待事件也往往是伴隨著I/O性能存在問題的系統(tǒng)中經(jīng)常出現(xiàn)，通過以下語句查詢：SELECTpl““Block〞,p3”Reason〞FROMv$session-waitWHEREevent=’bufferbusywaits’如果Reason值是130，那么說明當(dāng)某個會話需要訪問某個數(shù)據(jù)塊的時候，有另外一個會話正在將該數(shù)據(jù)塊讀入緩沖區(qū)。此時肯定有一個相同p1,p2參數(shù)的等待事件，該等待事件或者是dbread,或者是dbread。也就是說產(chǎn)生bufferbusywaits的根本原因是I/O的等待。6.2Oracle對I/0的依賴性O(shè)racleRDBMS的主要任務(wù)是維護數(shù)據(jù)。Oracle把RDBMS中的數(shù)據(jù)存在于兩個地方:內(nèi)存和磁盤。內(nèi)存中的數(shù)據(jù)要么來源于磁盤，要么最終被寫入磁盤。OracleRDBMS對I/O子系統(tǒng)具有很強的依賴性。就正如OracleRDBMS依賴于I/O子系統(tǒng)一樣，OracleRDBMS的性能也依賴于I/O子系統(tǒng)的性能。實際上，OracleRDBMS的性能對I/O子系統(tǒng)的性能具有很強的依賴性。OracleRDBMS執(zhí)行的絕大局部任務(wù)都涉及到某些I/O操作，而且很多任務(wù)還涉及到大量的I/O操作。為深入理解造成I/O性能低下的原因，需要參考一些實際例子。因為檢索數(shù)據(jù)時，磁盤驅(qū)動器有搜索時間和旋轉(zhuǎn)延遲，所以磁盤驅(qū)動器的性能受到了某些限制。因此，為了滿足一個隨機請求，I/O子系統(tǒng)需要花6.3ms的時間。這個時間被稱為寫操作延遲。6.2.1讀操作延遲的重要性因為讀數(shù)據(jù)請求是用戶請求，所以O(shè)racle對讀操作的時間延遲是非常敏感的。該用戶可能需要等待系統(tǒng)返回數(shù)據(jù)，所以讀數(shù)據(jù)操作花的時間越長用戶等待的時間也越長。管理員可能會問為什么會有人關(guān)心僅需要6ms的讀數(shù)據(jù)操作。如果讀數(shù)據(jù)操作確實只需要6ms的時間，那么這個問題的答案將是沒有人會關(guān)心讀數(shù)據(jù)操作。問題在于僅僅一次讀操作根本滿足不了用戶需求。目前，讀操作延遲仍然是個問題。一個缺乏效率的I/O子系統(tǒng)可能使大型查詢需要花幾個小時而不是幾分鐘。但是，在絕大多數(shù)系統(tǒng)中，I/O子系統(tǒng)一直被使用，在很多情況下。I/O延遲時間可能非常長。這通常說明I/O子系統(tǒng)的性能己經(jīng)影響了Oracle的性能。一般情況下，因為排隊和隨機I/O的特性，讀操作的延遲時間在10~~20ms的范圍內(nèi)。盡管20ms是這個時間范圍的臨界點，但這些值是很合理的。在最壞情況下，讀操作的性能會怎樣?在過載I/O子系統(tǒng)中，50--100ms的時間延遲是很普遍的。管理員甚至可能會經(jīng)歷數(shù)百微秒的延遲時間。讀操作延遲時間可能會到達250ms甚至更高。在這樣的系統(tǒng)中，I/O性能非常低下。因為等待這些I/O的進程很可能鎖定數(shù)據(jù)，所以低下的I/O性能會造成進一步的惡性循環(huán)。因此，讀操作延遲是非常重要的。6.2.2寫操作延遲Oracle對寫操作延遲的依賴是多方面的。盡管用戶進程經(jīng)常等待系統(tǒng)完成讀操作以獲得需要的數(shù)據(jù)，但寫操作與此不同,用戶進程只改變緩沖區(qū)內(nèi)的數(shù)據(jù)。系統(tǒng)只允許DBWR進程改變磁盤上的數(shù)據(jù)文件。因為DBWR進程改變磁盤上的數(shù)據(jù)文件的操作是在后臺進行的，所以寫操作的性能不像讀操作那么重要。對所有用戶數(shù)據(jù)文件都是如此。為什么這里要特別指明是用戶數(shù)據(jù)文件?因為使用的方法不同，undo表空間或回滾表空間是不受這個規(guī)則限制的。另外，重做日志文件對寫操作性能是非常敏感的。操作延遲和重做日志文件在OracleRDBMS中，重做日志文件用于維護系統(tǒng)的可恢復(fù)性。因此，在一個事務(wù)的重做日志記錄被寫入到磁盤之前，不能認(rèn)為該事務(wù)已經(jīng)結(jié)束。系統(tǒng)將重做日志記錄寫入重做日志緩沖區(qū)中，而LGWR又將緩沖區(qū)內(nèi)的重做日志記錄寫入到重做日志文件中。只要寫日志進程能滿足系統(tǒng)需求，系統(tǒng)就能順利處理事務(wù)。如果重做日志記錄耗盡了重做日志緩區(qū)，那么系統(tǒng)將強制事務(wù)等待寫日志進程清空重做日志緩沖區(qū)。另外，寫操作越慢，處理事務(wù)提交的時間就越長，從而進程鎖定數(shù)據(jù)的時間也越長。因此，重做日志驅(qū)動器寫操作的性能是非常重要的。寫操作延遲和Undo表空間文件除了重做日志文件所在的磁盤驅(qū)動器外，某種程度上說，Undo表空間所在的磁盤驅(qū)動器對寫操作性能也是很敏感的。如果數(shù)據(jù)庫數(shù)據(jù)經(jīng)常被修改，那么系統(tǒng)對Undo表空間的使用將非常頻繁。因為Undo表空間的寫操作很頻繁，所以系統(tǒng)對Undo文件的寫操作可能也很多。因此，如果Undo文件的寫操作很頻繁，那么寫操作對時間延遲也是比較敏感的。寫操作延遲和數(shù)據(jù)文件一般情況下，數(shù)據(jù)文件上的寫操作延遲都不會引起性能問題。寫操作有不同的類型，并且都是由DBWR進程在后臺處理的。只要DBWR進程能滿足系統(tǒng)需求，并且檢查點進程花的時間不太長，那么寫操作延遲都不會是問題。如果DBWR進程不能滿足系統(tǒng)需求，那么寫操作延遲將引起系統(tǒng)性能問題。如果系統(tǒng)中沒有可用的空閑緩沖區(qū)，而且DBWR進程又不能迅速清空緩沖區(qū)以滿足用戶進程對緩沖區(qū)的請求，那么該用戶進程將被掛起。但不太可能出現(xiàn)這種情況。6.2.3容錯除了性能方面的考慮，比方讀寫操作時間延遲外，Oracle還必須依靠I/O子系統(tǒng)保證數(shù)據(jù)的平安性。如果磁盤上的數(shù)據(jù)遭到了破壞，那么數(shù)據(jù)庫將毫無用處。因此，管理員需要在自己的Oracle數(shù)據(jù)文件中使用某種容錯功能。6.3調(diào)整1/0對Oracle數(shù)據(jù)庫用戶而言I/O可能是他們面臨的最主要的問題之一。很多情況下，磁盤I/O速度完全限制了系統(tǒng)性能。而在另一些情況下，為等待完成用戶進程對磁盤的I/O請求，系統(tǒng)實際上己處于閑置狀態(tài)。這樣的系統(tǒng)稱為I/O被限制的系統(tǒng)或被磁盤限制的系統(tǒng)。調(diào)整磁盤I/O的策略是將所有驅(qū)動器的I/O持在其物理極限之內(nèi)。這樣就可以縮短I/O操作的排隊時間，從而提高I/O性能。在特定系統(tǒng)中，管理員可能發(fā)現(xiàn)某些磁盤的IOPS高于其他磁盤。我們將這些磁盤稱為“熱點〞磁盤。任何時候都應(yīng)當(dāng)盡可能減少熱點磁盤。任何時候，如果某個或某組磁盤上的資源競爭很劇烈，那么這些磁盤將成為熱點磁盤。6.3.1識別磁盤競爭問題為了識別磁盤競爭問題，管理員必須分析系統(tǒng)的I/O速度以及系統(tǒng)中每個磁盤驅(qū)動器的延遲時間。對于單個磁盤和磁盤陣列，分析過程是不一樣的。對于單個磁盤驅(qū)動器，只需簡單地啟動操作系統(tǒng)或第三方工具并檢查每個驅(qū)動器上的I0PS即可。這些工具獲得的數(shù)據(jù)將為管理員提供每個磁盤驅(qū)動器上I/O操作的準(zhǔn)確信息。在上一節(jié)中己經(jīng)了解到I/O操作的首要規(guī)則是每個磁盤驅(qū)動器上的隨機I/O操作不能，超過125IOPS，而順序I/O操作不能超過300IOPS。如果系統(tǒng)中出現(xiàn)了磁盤盯I/O問題，那么管理員將觀察到大量的空閑CPU周期和很長系統(tǒng)響應(yīng)時間。除了檢查每個磁盤驅(qū)動器上的IOPS之外，檢查磁盤驅(qū)動器的延遲時間也是非常重要的。管理員可通過操作系統(tǒng)的監(jiān)控工具或磁盤使用情況的統(tǒng)計數(shù)據(jù)(如果初始化參數(shù)TIMED_STAISTICS的值被設(shè)置為TRUE)來監(jiān)控磁盤驅(qū)動器的延遲時間。操作系統(tǒng)的統(tǒng)計數(shù)據(jù)可能比Oracle的統(tǒng)計數(shù)據(jù)更為精確。應(yīng)當(dāng)重點注意延遲時間超過20ms的磁盤驅(qū)動器。可接受的驅(qū)動器延遲時間為10~20ms，而如果驅(qū)動器的延遲時間超過了20ms，那么該驅(qū)動器的I/O操作肯定出現(xiàn)了問題。對于磁盤陣列，管理員也可通過操作系統(tǒng)監(jiān)控工具或磁盤使用情況的統(tǒng)計數(shù)據(jù)來監(jiān)控相同的工程——主要還是每個驅(qū)動器上的IOPS數(shù)量。這個磁盤陣列看起來好似一個磁盤。對于現(xiàn)在市場上最流行的磁盤陣列，管理員只需簡單地將該磁盤陣列的I/O速度除以該陣列中磁盤驅(qū)動器的數(shù)量就能得到每個磁盤驅(qū)動器上IOPS的準(zhǔn)確數(shù)據(jù)。但是，通過這些工具獲得的延遲時間本身就是準(zhǔn)確的，不需要任何計算。識別磁盤競爭問題的下一步是確定磁盤I/O的大概情況。管理員可將I/O操作分為兩種主要類型:順序I/O和隨機I/O。下面就是這兩類I/O操作的特性。（1）順序I/O：在順序I/O操作中，系統(tǒng)從磁盤上順序讀取或?qū)懭霐?shù)據(jù)，因此幾乎不會出現(xiàn)磁頭的跳躍移動。通常情況下，對重做日志文件的訪問都是順序訪問。（2）如果訪問的數(shù)據(jù)位于磁盤上的不同地方，那么這樣的I/O就是隨機I/O，隨機I/O將導(dǎo)致磁頭的跳躍移動。對數(shù)據(jù)文件的訪問幾乎都是隨機訪問。數(shù)據(jù)庫加載時，系統(tǒng)對數(shù)據(jù)文件的訪問是順序訪問；而在其他絕大多數(shù)情況下(特別是在OLPT系統(tǒng)中)，對數(shù)據(jù)文件的訪問模式幾乎都是隨機訪問。對于順序I/O，磁盤的操作速度遠(yuǎn)高于隨機I/O的操作速度。如果磁盤正在處理的I/O操作中包含了任何隨機I/O，那么我們認(rèn)為對該磁盤的訪問模式為隨機模式。即使系統(tǒng)中還有兩個獨立進程以順序模式訪問該磁盤，我們也認(rèn)為該磁盤的訪問模式為隨機模式。對于隨機I/O，系統(tǒng)不僅需要訪問磁盤，還涉及到磁頭的大量跳躍移動，這將降低磁盤性能。最后，將計算得到的速度與磁盤驅(qū)動器的推薦速度進行比較。如下是一些好建議。a.順序I/O：一個典型的ULTRA-SCSI-160磁盤驅(qū)動器能支持的順序I/O速度大約為300IOPS。b.隨機I/O：一個典型的ULTRA-SCSI-160磁盤驅(qū)動器能支持的隨機I/O速度大約為125IOPS。6.3.2解決磁盤竟?fàn)巻栴}在解決磁盤競爭問題時應(yīng)當(dāng)遵循如下一些規(guī)則:（1）別離系統(tǒng)中的順序I/O因為順序操作的速度遠(yuǎn)大于隨機的，所以別離出系統(tǒng)中的順序I/O可大大提高驅(qū)動器的運行速度。（2）分散隨機I/O?？赏ㄟ^Oracle分片技術(shù)、操作系統(tǒng)分片技術(shù)或硬件分片技術(shù)來分片存儲數(shù)據(jù)庫表中的數(shù)據(jù)從而到達分散隨機I/O的目的。（3）分別存儲數(shù)據(jù)及索引。通過分別存儲一個被頻繁訪問的表和該表的索引，管理員將允許對該表的查詢同時訪問位于不同磁盤的該表的數(shù)據(jù)及索引。（4）對于一個包含數(shù)據(jù)庫文件的磁盤，管理員應(yīng)當(dāng)去除該磁盤上的非OracleI/O操作。任何其他的磁盤I/O都將降低份Oracle訪問該磁盤的速度。6.3.3下面局部內(nèi)容將分別討論這幾種不同的解決方案及如何實現(xiàn)這些解決方案別離系統(tǒng)中的順序I/O通過別離系統(tǒng)中的順序I/O可使以順序方式訪問的磁盤的運行速度遠(yuǎn)高于以隨機方式訪問的磁盤的運行速度。管理員只需簡單地將Oracle的重做日志文件放到不同的磁盤上就能實現(xiàn)系統(tǒng)中順序I/O的別離。管理員必須確保將每個重做日志文件都放到了它自己的磁盤上一對鏡像日志文件更是如此——如果系統(tǒng)中使用了鏡像重做日志文件的話。如果使用了操作系統(tǒng)或硬件的鏡像特性，那么Oracle的重做日志文件本身就在不同的卷上。盡管Oracle對每個重做日志文件的寫操作都是順序I/O操作，但如果將某一重做日志文件與其鏡像文件放到同一個磁盤上，那么將導(dǎo)致該磁盤在相鄰的讀操作之間會在兩個日志文件中檢索數(shù)據(jù)，從而降低磁盤的I/O速度。通過鏡像重做日志文件來降低系統(tǒng)故障的危險是非常重要的。讀者可通過Oracle、操作系統(tǒng)或硬件的容錯特性來實現(xiàn)重做日志文件鏡像。分散隨機I/O隨機I/O的特點是被訪問的數(shù)據(jù)位于數(shù)據(jù)文件的不同位置上。管理員只需簡單地向Oracle中添加足夠數(shù)量的磁盤并將表放置在所有這些磁盤上，就能非常容易地降低隨機I/O引起的性能問題?？筛鶕?jù)系統(tǒng)的不同配置將數(shù)據(jù)分別存放在多個驅(qū)動器上，管理員只需簡單地將表存放到多個驅(qū)動器上就可實現(xiàn)隨機I/O的分散化。Oracle分片技術(shù)Oracle分片技術(shù)的功能是將一個表的數(shù)據(jù)分成多個小局部，并將這些不同的局部存放到不同的數(shù)據(jù)文件中。Oracle是通過CREAIETABLESPACE命令在表空間層次上實現(xiàn)分片的?？墒褂萌缦抡Z句創(chuàng)立一個分片表空間:SQL>CREATETABLESPACEmytablespace2DATAFILE’’SIZE500K3‘’SIZE500K4‘f’SIZE500K5‘f’SIZE500KTablespacecreated.為完成這個任務(wù)，管理員還必須在這個表空間中創(chuàng)立一個帶有4個盤區(qū)的表。在該表空間中創(chuàng)立的表將跨越該表空間中的所有4個數(shù)據(jù)文件，而這些數(shù)據(jù)文件分別位于不同的磁盤上。創(chuàng)立表的SQL語句如下:SQL>CREATETABLESPACEmytablespace2namevarcar(40),3titlevarchar(20),4office_numbermunber(4)5TABLESPACEmytablespace6STOREAGE(INTIAL495KNEXT495K7MINEXTENTS4PCTNCREASE00;Tablecreated.在這個例子中，每個數(shù)據(jù)文件的尺寸為500K。這個尺寸稱為分片尺寸。如果表很大，那么分片尺寸也會很大(除非管理員向表空間中添加了很多的數(shù)據(jù)片)。如果表中數(shù)據(jù)各個局部的尺寸很大，比方BLOB類型數(shù)據(jù)，那么使用大尺寸的數(shù)據(jù)片是很有優(yōu)勢的。但在絕大多數(shù)OLPT應(yīng)用程序中，使用尺寸較小的數(shù)據(jù)片可使I/O操作在不同磁盤上的分布更加均衡。數(shù)據(jù)文件的尺寸取決于表的尺寸。因為管理數(shù)以百計的數(shù)據(jù)文件是件非常復(fù)雜的工作，所以一般情況下，每個表空間只包含一個磁盤卷，且只包含一個數(shù)據(jù)文件。如果數(shù)據(jù)庫尺寸為10GB，且系統(tǒng)中有10個磁盤卷，那么數(shù)據(jù)文件的尺寸將為1GB。通過增加更多尺寸更小的數(shù)據(jù)文件，系統(tǒng)中的I/O分布將更加均衡；但因為數(shù)據(jù)文件的數(shù)量增加了，所以數(shù)據(jù)文件的管理也將更加復(fù)雜。管理員可聯(lián)合使用Oracle分片技術(shù)和操作系統(tǒng)或硬件分片技術(shù)。6.4調(diào)整Client/Server模式下的網(wǎng)絡(luò)I/OClient/Server環(huán)境中的應(yīng)用處理是分布在客戶應(yīng)用程序和數(shù)據(jù)庫效勞程序之間的。在Client/Server環(huán)境中Client與Server之間的網(wǎng)絡(luò)I/O是整個系統(tǒng)性能提高的瓶頸，一個客戶應(yīng)用程序引起的網(wǎng)絡(luò)I/O越少，應(yīng)用及整個系統(tǒng)的性能越好。減少網(wǎng)絡(luò)I/O的最重要的一條原則：將應(yīng)用邏輯集中在數(shù)據(jù)庫效勞器中。6.4.1使用Oracle數(shù)據(jù)庫的完整約束性當(dāng)為應(yīng)用建表時，應(yīng)當(dāng)為一些有特殊要求的數(shù)據(jù)加上適當(dāng)?shù)耐暾约s束，這樣就能實現(xiàn)由數(shù)據(jù)庫本身而不是應(yīng)用程序來約束數(shù)據(jù)符合一定的條件。數(shù)據(jù)庫效勞器端的完整約束的執(zhí)行操作是在比SQL語句級別更低的系統(tǒng)機制上優(yōu)化，它與客戶端無關(guān)，只在效勞器中運行，不需在Client端和S~端之間傳遞SQL語句，有效地減輕網(wǎng)絡(luò)I/O負(fù)擔(dān)。6.4.2使用數(shù)據(jù)庫觸發(fā)器完整約束性只能實現(xiàn)一些較簡單的數(shù)據(jù)約束條件，對一些較復(fù)雜的事物處理規(guī)則就無能為力，這時最好不要在應(yīng)用程序中實施復(fù)雜的程序控制，而是應(yīng)當(dāng)采用數(shù)據(jù)庫觸發(fā)器來實施復(fù)雜的事物規(guī)則。數(shù)據(jù)庫觸發(fā)器能實現(xiàn)由數(shù)據(jù)庫本身，而不是應(yīng)用程序，來約束數(shù)據(jù)符合復(fù)雜的事物處理規(guī)則，并且容易創(chuàng)立，便于管理，防止大量的網(wǎng)絡(luò)I/O。例如:將當(dāng)前表A中成為歷史的記錄從A表中轉(zhuǎn)儲到歷史表B中，表示為Lsbs。在應(yīng)用程序中實現(xiàn):用數(shù)據(jù)庫觸發(fā)器實現(xiàn):BeignCreatetriggerdeletelUpdateAsetlsbs=T;AfterUpdateoflsbsonAInserti