是不是很難準(zhǔn)確地分配不同的池所需的內(nèi)存數(shù)？自動共享內(nèi)存治理特性使得自動將內(nèi)存分配到最需要的地方去成為可能。 無論您是一個剛?cè)腴T的 DBA 還是一個經(jīng)驗豐富的 DBA，您肯定至少看到過一次類似以下的錯誤： ORA-04031:unable to allocate 2216 bytes of shared memory ('shared pool'... ...　或者這種錯誤： ORA-04031:unable to allocate XXXX bytes of shared memory('large pool','unknown object','session heap','frame')　或者可能這種錯誤： ORA-04031:unable to allocate bytes of shared memory ('shared pool','unknown object','joxlod:init h', 'JOX:ioc_allocate_pal')　第一種錯誤的原因很明顯：分配給共享池的內(nèi)存不足以滿足用戶請求。（在某些情況下，原因可能不是池本身的大小，而是未使用綁定變量導(dǎo)致的過多分析造成的碎片，這是我很喜歡的一個主題；但目前讓我們把重點放在手頭的問題上。）其它的錯誤分別來自大型池和 Java 池的空間不足。 您需要解決這些錯誤情況，而不作任何與應(yīng)用程序相關(guān)的修改。那么有哪些方案可選呢？問題是如何在 Oracle 例程所需的所有池之間劃分可用的內(nèi)存。餡餅怎么分？ 正如您所了解的，一個 Oracle 例程的系統(tǒng)全局區(qū)域 (SGA) 包含幾個內(nèi)存區(qū)域（包括緩沖高速緩存、共享池、Java 池、大型池和重做日志緩沖）。這些池在操作系統(tǒng)的內(nèi)存空間中占據(jù)了固定的內(nèi)存數(shù)；它們的大小由 DBA 在初始化參數(shù)文件中指定。 這四個池（數(shù)據(jù)庫塊緩沖高速緩存、共享池、Java 池和大型池）幾乎占據(jù)了 SGA 中所有的空間。（與其它區(qū)域相比，重做日志緩沖沒有占據(jù)多少空間，對我們這里的討論無關(guān)緊要。）作為 DBA，您必須確保它們各自的內(nèi)存分配是充足的。 假定您決定了這些池的值分別是 2GB、1GB、1GB 和 1GB。您將設(shè)置以下初始化參數(shù)來為數(shù)據(jù)庫例程規(guī)定池的大小。 db_cache_size = 2gshared_pool_size = 1glarge_pool_size = 1gjava_pool_size = 1g　現(xiàn)在，仔細看一下這些參數(shù)。坦白講，這些值是否準(zhǔn)確？我相信您一定會有疑慮。在實際中，沒有人能夠為這些池指定確切的內(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)存： alter system set db_cache_size = 3g scope=memory;alter system set large_pool_size = 512m scope=memory;alter system set java_pool_size = 512m scope=memory;　這個解決方案能夠很好地工作一段時間，但是接著夜間的 RMAN 作業(yè)（它們使用大型池）開始了，大型池將立即出現(xiàn)內(nèi)存不足。同樣，您從數(shù)據(jù)庫高速緩存中取出一些內(nèi)存來補充大型池，以拯救這種局面。 RMAN 作業(yè)完成，然后啟動一個廣泛使用 Java 的批處理程序，接著您開始看到與 Java 池相關(guān)的錯誤。因此，您（再次）重新分配池，以滿足 Java 池和數(shù)據(jù)庫高速緩存上的內(nèi)存需求： alter system set db_cache_size = 2G scope=memory;alter system set large_pool_size = 512M scope=memory;alter system set java_pool_size = 1.5G scope=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ù)工作負載動態(tài)地進行配置。實現(xiàn)自動內(nèi)存分配僅僅需要 SGA_TARGET 參數(shù)的一個非零值。 設(shè)置自動共享內(nèi)存治理 讓我們看看該特性是如何工作的。首先，確定 SGA 的總大小。您可以通過確定現(xiàn)在分配了多少內(nèi)存來估計這個值。 SQL> select sum(value)/1024/1024 from v$sga;SUM(VALUE)/1024/1024--------------------500　此時 SGA 的當(dāng)前總大小近似為 500MB，并且這個值將變?yōu)?SGA_TARGET 的值。接下來，執(zhí)行語句： alter system set sga_target = 500M scope=both;　這種方法不需要為各個池設(shè)置不同值；因而，您將需要在參數(shù)文件中使它們的值為零或全部刪除它們。 shared_pool_size = 0large_pool_size = 0java_pool_size = 0db_cache_size = 0再循環(huán)數(shù)據(jù)庫，使這些值生效。這個人工過程還可以通過 Enterprise Manager 10g 實施。從數(shù)據(jù)庫主頁中，選擇 'Administration' 選項卡，然后選擇 'Memory Parameters'。對于人工配置的內(nèi)存參數(shù)，將顯示標(biāo)記為 'Enable' 的按鈕，以及所有人工配置的池的值。單擊 'Enable' 按鈕，啟用自動共享內(nèi)存治理特性。企業(yè)治理器將完成剩下的工作。 在配置了自動內(nèi)存分配之后，您可以利用以下命令檢查它們的大小： SQL> select current_size from v$buffer_pool;CURRENT_SIZE------------340SQL> select pool, sum(bytes)/1024/1024 Mbytes from v$sgastat group by pool;POOL MBYTES------------ ----------java pool 4large pool4shared pool 148正如您所看到的，所有的池都從 500MB 的總目標(biāo)大小中自動進行分配。（參見圖 1。）緩沖高速緩存大小是 340MB，Java 池是 4MB，大型池是 4MB，共享池是 148MB。它們合起來總的大小為 (340+4+4+148=) 496MB，近似與 500MB 的目標(biāo) SGA 的大小相同。 圖 1：池的初始分配現(xiàn)在假定提供給 Oracle 的主機內(nèi)存從 500MB 減少為 300MB，這意味著我們必須減少總 SGA 的大小。我們可以通過減小目標(biāo) SGA 大小來反映這種變化。 　alter system set sga_target = 300M scope=both;現(xiàn)在查看各個池，我們可以看到： SQL> select current_size from v$buffer_pool;CURRENT_SIZE------------244SQL> select pool, sum(bytes)/1024/1024 Mbytes from v$sgastat group by pool;POOL MBYTES------------ ----------java pool 4large pool4shared pool　44占用的總大小是 240+4+4+44 = 296MB，接近于目標(biāo)的 300MB。注重如圖 2 所示，當(dāng) SGA_TARGET 改變時，如何自動重新分配池。 　 圖 2：在將 SGA 大小減少到 300MB 之后重新分配池這些池的大小是動態(tài)的。池將根據(jù)工作負載擴展，以容納需求的增長，或縮小以容納另一個池的擴展。這種擴展或縮小自動發(fā)生，無需 DBA 的干預(yù)，這與本文開頭的示例不同。讓我們暫時返回到那個場景，假定在初始分配后，RMAN 作業(yè)啟動，指示需要一個更大的大型池，大型池將從 4MB 擴展到 40MB，以容納需求。這個額外的 36MB 將從數(shù)據(jù)庫緩沖中劃出，數(shù)據(jù)庫塊緩沖將縮小，如圖 3 所示。 　 圖 3：在對大型池的需求增長之后經(jīng)過重新分配的池池的大小變化基于系統(tǒng)上的工作負載，因此不需要為最壞的情況調(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 指定的。