l?????? 前言
?
對(duì)于oracle的內(nèi)存的管理，截止到9iR2，都是相當(dāng)重要的環(huán)節(jié)，管理不善，將可能給數(shù)據(jù)庫(kù)帶來(lái)嚴(yán)重的性能問(wèn)題。下面我們將一步一步就內(nèi)存管理的各個(gè)方面進(jìn)行探討。
l?????? 概述
?
oracle的內(nèi)存可以按照共享和私有的角度分為系統(tǒng)全局區(qū)和進(jìn)程全局區(qū)，也就是SGA和PGA(process global area or private global area)。對(duì)于SGA區(qū)域內(nèi)的內(nèi)存來(lái)說(shuō)，是共享的全局的，在UNIX上，必須為oracle設(shè)置共享內(nèi)存段（可以是一個(gè)或者多個(gè)），因?yàn)閛racle在UNIX上是多進(jìn)程；而在WINDOWS上oracle是單進(jìn)程（多個(gè)線程），所以不用設(shè)置共享內(nèi)存段。PGA是屬于進(jìn)程（線程）私有的區(qū)域。在oracle使用共享服務(wù)器模式下（MTS）,PGA中的一部分，也就是UGA會(huì)被放入共享內(nèi)存large_pool_size中。
對(duì)于SGA部分，我們通過(guò)sqlplus中查詢可以看到：
SQL> select * from v$sga;
NAME????????????????????? VALUE
--------------------????????????? ----------
Fixed Size?????????????????? 454032
Variable Size???????????????? 109051904
Database Buffers????????????? 385875968
Redo Buffers????????????????? 667648
Fixed Size
oracle 的不同平臺(tái)和不同版本下可能不一樣，但對(duì)于確定環(huán)境是一個(gè)固定的值，里面存儲(chǔ)了SGA各部分組件的信息，可以看作引導(dǎo)建立SGA的區(qū)域。
?
Variable Size
包含了shared_pool_size、java_pool_size、large_pool_size等內(nèi)存設(shè)置和用于管理數(shù)據(jù)緩沖區(qū)等內(nèi)存結(jié)構(gòu)的hash table、塊頭信息(比如x$bh消耗內(nèi)存)等
Database Buffers
??? 指數(shù)據(jù)緩沖區(qū)，在8i中包含default pool、buffer_pool_keep、buffer_pool_recycle三部分內(nèi)存。在9i中包含db_cache_size、db_keep_cache_size、db_recycle_cache_size、db_nk_cache_size。這里要注意在8i中三部分內(nèi)存總和為db_block_buffers*db_block_size。
Redo Buffers
指日志緩沖區(qū)，log_buffer。在這里要額外說(shuō)明一點(diǎn)的是，對(duì)于v$parameter、v$sgastat、v$sga查詢值可能不一樣。v$parameter里面的值，是指用戶在初始化參數(shù)文件里面設(shè)置的值，v$sgastat是oracle實(shí)際分配的日志緩沖區(qū)大?。ㄒ?yàn)榫彌_區(qū)的分配值實(shí)際上是離散的，也不是以block為最小單位進(jìn)行分配的），v$sga里面查詢的值，是在oracle分配了日志緩沖區(qū)后，為了保護(hù)日志緩沖區(qū)，設(shè)置了一些保護(hù)頁(yè)，通常我們會(huì)發(fā)現(xiàn)保護(hù)頁(yè)大小大約是11k(不同環(huán)境可能不一樣)。參考如下內(nèi)容
?
SQL>? select substr(name,1,10) name,substr(value,1,10) value
? 2? from v$parameter where name = 'log_buffer';
NAME???????????????? VALUE
--------------------???? --------------------
log_buffer?????????????? 524288
?
SQL> select * from v$sgastat ;
POOL? NAME???????????? BYTES
----------- -------------------
fixed_sga?????????????????? 454032
buffer_cache??????????????? 385875968
log_buffer????????????????? 656384
SQL> select * from v$sga;
NAME???????????????????? VALUE
--------------------????????????? ----------
Fixed Size????????????????? 454032
Variable Size??????????????? 109051904
Database Buffers???????????? 385875968
Redo Buffers??????????????? 667648
關(guān)于各部分內(nèi)存的作用，參考o(jì)racle體系結(jié)構(gòu)，在此不再敘述。
l?????? SGA的大小
?
那么我們現(xiàn)在來(lái)考察內(nèi)存參數(shù)的設(shè)置。實(shí)際上，對(duì)于特定的環(huán)境，總是存在著不同的最優(yōu)設(shè)置的，沒(méi)有任何一種普遍適用的最優(yōu)方案。但為什么在這里我們還要來(lái)談設(shè)置這個(gè)話題呢，那僅僅是出于一個(gè)目的，避免過(guò)度的犯錯(cuò)誤。事實(shí)上，在任何一個(gè)生產(chǎn)系統(tǒng)正式投入使用之前，我們不擁有任何系統(tǒng)運(yùn)行信息讓我們?nèi)フ{(diào)整，這樣就只有兩種可能，一是根據(jù)文檔推薦設(shè)置，另外一種就是根據(jù)經(jīng)驗(yàn)設(shè)置。相對(duì)來(lái)說(shuō)，根據(jù)經(jīng)驗(yàn)的設(shè)置比根據(jù)文檔的設(shè)置要可靠一些。尤其是那些24*7的系統(tǒng)，我們更要減少錯(cuò)誤的發(fā)生。那么我們嘗試去了解不同的系統(tǒng)不同的應(yīng)用的具體設(shè)置情況，從而提供一個(gè)參照信息給大家。
為了得出一個(gè)參照設(shè)置，我們就必須假定一個(gè)參照環(huán)境。以下所有設(shè)置我們基于這樣一個(gè)假定，那就是硬件服務(wù)器上只考慮存在操作系統(tǒng)和數(shù)據(jù)庫(kù)，在這個(gè)單一的環(huán)境中，我們來(lái)考慮內(nèi)存的設(shè)置。
在設(shè)置參數(shù)之前呢，我們首先要問(wèn)自己幾個(gè)問(wèn)題
一：物理內(nèi)存多大
二：操作系統(tǒng)估計(jì)需要使用多少內(nèi)存
三：數(shù)據(jù)庫(kù)是使用文件系統(tǒng)還是裸設(shè)備
四：有多少并發(fā)連接
五：應(yīng)用是OLTP類型還是OLAP類型
根據(jù)這幾個(gè)問(wèn)題的答案，我們可以粗略地為系統(tǒng)估計(jì)一下內(nèi)存設(shè)置。那我們現(xiàn)在來(lái)逐個(gè)問(wèn)題地討論，首先物理內(nèi)存多大是最容易回答的一個(gè)問(wèn)題，然后操作系統(tǒng)估計(jì)使用多少內(nèi)存呢？從經(jīng)驗(yàn)上看，不會(huì)太多，通常應(yīng)該在200M以內(nèi)（不包含大量進(jìn)程PCB）。
接下來(lái)我們要探討一個(gè)重要的問(wèn)題，那就是關(guān)于文件系統(tǒng)和裸設(shè)備的問(wèn)題，這往往容易被我們所忽略。操作系統(tǒng)對(duì)于文件系統(tǒng)，使用了大量的buffer來(lái)緩存操作系統(tǒng)塊。這樣當(dāng)數(shù)據(jù)庫(kù)獲取數(shù)據(jù)塊的時(shí)候，雖然SGA中沒(méi)有命中，但卻實(shí)際上可能是從操作系統(tǒng)的文件緩存中獲取的。而假如數(shù)據(jù)庫(kù)和操作系統(tǒng)支持異步IO，則實(shí)際上當(dāng)數(shù)據(jù)庫(kù)寫(xiě)進(jìn)程DBWR寫(xiě)磁盤(pán)時(shí)，操作系統(tǒng)在文件緩存中標(biāo)記該塊為延遲寫(xiě)，等到真正地寫(xiě)入磁盤(pán)之后，操作系統(tǒng)才通知DBWR寫(xiě)磁盤(pán)完成。對(duì)于這部分文件緩存，所需要的內(nèi)存可能比較大，作為保守的估計(jì)，我們應(yīng)該考慮在 0.2——0.3 倍內(nèi)存大小。但是如果我們使用的是裸設(shè)備，則不考慮這部分緩存的問(wèn)題。這樣的情況下SGA就有調(diào)大的機(jī)會(huì)。
關(guān)于數(shù)據(jù)庫(kù)有多少并發(fā)連接，這實(shí)際上關(guān)系到PGA的大?。∕TS下還有l(wèi)arge_pool_size）。事實(shí)上這個(gè)問(wèn)題應(yīng)該說(shuō)還跟OLTP類型或者OLAP類型相關(guān)。對(duì)于OLTP類型oracle傾向于可使用MTS,對(duì)于OLAP類型使用獨(dú)立模式，同時(shí)OLAP還可能涉及到大量的排序操作的查詢，這些都影響到我們內(nèi)存的使用。那么所有的問(wèn)題綜合起來(lái)，實(shí)際上主要反映在UGA的大小上。UGA主要包含以下部分內(nèi)存設(shè)置
SQL> show parameters area_size
NAME???????????????????????????????? TYPE???????? VALUE
------------------------------------?????????????? -------????????? -------------
bitmap_merge_area_size?????????????????? integer???????? 1048576
create_bitmap_area_size?????????????????? integer???????? 8388608
hash_area_size?????????????????????????? integer???????? 131072
sort_area_size??????????????????????????? integer???????? 65536
SQL>
在這部分內(nèi)存中我們最關(guān)注的通常是sort_area_size，這是當(dāng)查詢需要排序的時(shí)候，數(shù)據(jù)庫(kù)會(huì)話將使用這部分內(nèi)存進(jìn)行排序，當(dāng)內(nèi)存大小不足的時(shí)候，使用臨時(shí)表空間進(jìn)行磁盤(pán)排序。由于磁盤(pán)排序效率和內(nèi)存排序效率相差好幾個(gè)數(shù)量級(jí)，所以這個(gè)參數(shù)的設(shè)置很重要。這四個(gè)參數(shù)都是針對(duì)會(huì)話進(jìn)行設(shè)置的，是單個(gè)會(huì)話使用的內(nèi)存的大小，而不是整個(gè)數(shù)據(jù)庫(kù)使用的。偶爾會(huì)看見(jiàn)有人誤解了這個(gè)參數(shù)以為是整個(gè)數(shù)據(jù)庫(kù)使用的大小，這是極其嚴(yán)重的錯(cuò)誤。假如設(shè)置了MTS，則UGA被分配在large_pool_size，也就是說(shuō)放在了共享內(nèi)存里面，不同進(jìn)程（線程）之間可以共享這部分內(nèi)存。在這個(gè)基礎(chǔ)上，我們假設(shè)數(shù)據(jù)庫(kù)存在并發(fā)執(zhí)行server? process為100個(gè)，根據(jù)上面我們4個(gè)參數(shù)在oracle8.1.7下的默認(rèn)值，我們來(lái)計(jì)算獨(dú)立模式下PGA的大致大小。由于會(huì)話并不會(huì)經(jīng)常使用create_bitmap_area_size、bitmap_merge_area_size，所以我們通常不對(duì)四個(gè)參數(shù)求和。在考慮到除這四個(gè)參數(shù)外會(huì)話所保存的變量、堆棧等信息，我們估計(jì)為2M，則100個(gè)進(jìn)程最大可能使用200M的PGA。
現(xiàn)在，根據(jù)上面這些假定，我們來(lái)看SGA實(shí)際能達(dá)到多少內(nèi)存。在1G的內(nèi)存的服務(wù)器上，我們能分配給SGA的內(nèi)存大約為400—500M。若是2G的內(nèi)存，大約可以分到1G的內(nèi)存給SGA，8G的內(nèi)存可以分到5G的內(nèi)存給SGA。當(dāng)然我們這里是以默認(rèn)的排序部分內(nèi)存sort_area_size=64k進(jìn)行衡量的，假如我們需要調(diào)大該參數(shù)和hash_area_size等參數(shù)，然后我們應(yīng)該根據(jù)并發(fā)的進(jìn)程的數(shù)量，來(lái)衡量考慮這個(gè)問(wèn)題。
事實(shí)上，通常我們更習(xí)慣通過(guò)直觀的公式化來(lái)表達(dá)這樣的問(wèn)題：
OS使用內(nèi)存+SGA+并發(fā)執(zhí)行進(jìn)程數(shù)*(sort_area_size+hash_ara_size+2M) < 0.7*總內(nèi)存
?
???
??? (公式是死的，系統(tǒng)是活的，實(shí)際應(yīng)用的調(diào)整不必框公式，這不過(guò)是一個(gè)參考建議)
??? 在我們的實(shí)際應(yīng)用中，假如采用的是裸設(shè)備，我們可適當(dāng)?shù)脑龃骃GA(如果需要的話)。由于目前幾乎所有的操作系統(tǒng)都使用虛擬緩存，所以實(shí)際上如果就算SGA設(shè)置的比較大也不會(huì)導(dǎo)致錯(cuò)誤，而是可能出現(xiàn)頻繁的內(nèi)存頁(yè)的換入與換出(page in/out)。在操作系統(tǒng)一級(jí)如果觀察到這個(gè)現(xiàn)象，那么我們就需要調(diào)整內(nèi)存的設(shè)置。
l?????? SGA內(nèi)參數(shù)設(shè)置
?
Log_buffer
對(duì)于日志緩沖區(qū)的大小設(shè)置，通常我覺(jué)得沒(méi)有過(guò)多的建議，因?yàn)閰⒖糒GWR寫(xiě)的觸發(fā)條件之后，我們會(huì)發(fā)現(xiàn)通常超過(guò)3M意義不是很大。作為一個(gè)正式系統(tǒng)，可能考慮先設(shè)置這部分為log_buffer=1—3M 大小，然后針對(duì)具體情況再調(diào)整。
Large_pool_size
對(duì)于大緩沖池的設(shè)置，假如不使用MTS，建議在20—30M 足夠了。這部分主要用來(lái)保存并行查詢時(shí)候的一些信息，還有就是RMAN在備份的時(shí)候可能會(huì)使用到。如果設(shè)置了MTS，則由于UGA部分要移入這里，則需要具體根據(jù)server process數(shù)量和相關(guān)會(huì)話內(nèi)存參數(shù)的設(shè)置來(lái)綜合考慮這部分大小的設(shè)置。
Java_pool_size
假如數(shù)據(jù)庫(kù)沒(méi)有使用JAVA，我們通常認(rèn)為保留10—20M大小足夠。事實(shí)上可以更少，甚至最少只需要32k，但具體跟安裝數(shù)據(jù)庫(kù)的時(shí)候的組件相關(guān)(比如http server)。
shared_pool_size
這是迄今為止最具有爭(zhēng)議的一部分內(nèi)存設(shè)置。按照很多文檔的描述，這部分內(nèi)容應(yīng)該幾乎和數(shù)據(jù)緩沖區(qū)差不多大小。但實(shí)際上情況卻不是這樣的。首先我們要考究一個(gè)問(wèn)題，那就是這部分內(nèi)存的作用，它是為了緩存已經(jīng)被解析過(guò)的SQL，而使其能被重用，不再解析。這樣做的原因是因?yàn)椋瑢?duì)于一個(gè)新的SQL（shared_pool里面不存在已經(jīng)解析的可用的相同的SQL），數(shù)據(jù)庫(kù)將執(zhí)行硬解析，這是一個(gè)很消耗資源的過(guò)程。而若已經(jīng)存在，則進(jìn)行的僅僅是軟分析（在共享池中尋找相同SQL），這樣消耗的資源大大減少。所以我們期望能多共享一些SQL，并且如果該參數(shù)設(shè)置不夠大，經(jīng)常會(huì)出現(xiàn)ora-04031錯(cuò)誤，表示為了解析新的SQL，沒(méi)有可用的足夠大的連續(xù)空閑空間，這樣自然我們期望該參數(shù)能大一些。但是該參數(shù)的增大，卻也有負(fù)面的影響，因?yàn)樾枰S護(hù)共享的結(jié)構(gòu)，內(nèi)存的增大也會(huì)使得SQL的老化的代價(jià)更高，帶來(lái)大量的管理的開(kāi)銷，所有這些可能會(huì)導(dǎo)致CPU的嚴(yán)重問(wèn)題。
在一個(gè)充分使用綁定變量的比較大的系統(tǒng)中，shared_pool_size的開(kāi)銷通常應(yīng)該維持在300M以內(nèi)。除非系統(tǒng)使用了大量的存儲(chǔ)過(guò)程、函數(shù)、包，比如oracle erp這樣的應(yīng)用，可能會(huì)達(dá)到500M甚至更高。于是我們假定一個(gè)1G內(nèi)存的系統(tǒng)，可能考慮設(shè)置該參數(shù)為100M，2G的系統(tǒng)考慮設(shè)置為150M,8G的系統(tǒng)可以考慮設(shè)置為200—300M。
對(duì)于一個(gè)沒(méi)有充分使用或者沒(méi)有使用綁定變量系統(tǒng)，這可能給我們帶來(lái)一個(gè)嚴(yán)重的問(wèn)題。所謂沒(méi)有使用bind var 的SQL，我們稱為L(zhǎng)iteral SQL。也就是比如這樣的兩句SQL我們認(rèn)為是不同的SQL,需要進(jìn)行2次硬解析：
select * from EMP where name = ‘TOM’;
select * from EMP where name = ‘JERRY’;
假如把’TOM’ 和 ‘JERRY’ 換做變量V，那就是使用了bind var，我們可以認(rèn)為是同樣的SQL從而能很好地共享。共享SQL本來(lái)就是shared_pool_size這部分內(nèi)存存在的本意，oracle的目的也在于此，而我們不使用bind var就是違背了oracle的初衷，這樣將給我們的系統(tǒng)帶來(lái)嚴(yán)重的問(wèn)題。當(dāng)然，如果通過(guò)在操作系統(tǒng)監(jiān)控，沒(méi)有發(fā)現(xiàn)嚴(yán)重的cpu問(wèn)題，我們?nèi)绻l(fā)現(xiàn)該共享池命中率不高可以適當(dāng)?shù)脑黾觭hred_pool_size。但是通常我們不主張這部分內(nèi)存超過(guò)800M（特殊情況下可以更大）。
事實(shí)上，可能的話我們甚至要想辦法避免軟分析，這在不同的程序語(yǔ)言中實(shí)現(xiàn)方式有差異。我們也可能通過(guò)設(shè)置session_cached_cursors 參數(shù)來(lái)獲得幫助（這將增大PGA）。
Data buffer
現(xiàn)在我們來(lái)談數(shù)據(jù)緩沖區(qū)，在確定了SGA的大小并分配完了前面部分的內(nèi)存后，其余的，都分配給這部分內(nèi)存。通常，在允許的情況下，我們都嘗試使得這部分內(nèi)存更大。這部分內(nèi)存的作用主要是緩存 DB BLOCK，減少甚至避免從磁盤(pán)上獲取數(shù)據(jù)，在8i中是由db_block_buffers*db_block_size來(lái)決定大小的（包含default、keep、recycle）。如果我們?cè)O(shè)置了buffer_pool_keep 和buffer_pool_recycle，這兩部分內(nèi)存的大小包含在前面設(shè)置中（db_block_buffers*db_block_size）。
buffer_pool_keep 是用來(lái)取代8i版本以前的緩存頻繁小表于LUR 的MOST? USED端的。通過(guò)開(kāi)辟一段獨(dú)立的內(nèi)存用于緩存頻繁的小表，在創(chuàng)建表的時(shí)候可以指定存儲(chǔ)參數(shù)，或者也可以動(dòng)態(tài)修改表的存儲(chǔ)參數(shù)（alter table t storage(buffer_pool? keep);）。
Buffer_pool_recycle 作為一塊單獨(dú)開(kāi)辟出來(lái)的內(nèi)存，主要用于很少執(zhí)行的大表全表掃描的查詢，使得這些大表掃描不會(huì)影響到default里面LRU而沖擊整個(gè)數(shù)據(jù)庫(kù)緩沖區(qū)的性能。雖然這樣有可能降低大表的全表掃描的性能，但是保護(hù)了整體性能不間歇性的受到較大的沖擊。同樣，除了設(shè)置參數(shù)外還需要在創(chuàng)建表的過(guò)程中使用存儲(chǔ)參數(shù)或者動(dòng)態(tài)修改表的存儲(chǔ)參數(shù)（alter table t storage(buffer_pool? recycle);）
l?????? 9i下參數(shù)的變化
?
oracle的版本的更新，總是伴隨著參數(shù)的變化，并且越來(lái)越趨向于使得參數(shù)的設(shè)置更簡(jiǎn)單，因?yàn)閺?fù)雜的參數(shù)設(shè)置使得DBA們經(jīng)常焦頭爛額。關(guān)于內(nèi)存這部分的變化，我們可以考察下面的參數(shù)。事實(shí)上在9i中數(shù)據(jù)庫(kù)本身可以給出一組適合當(dāng)前運(yùn)行系統(tǒng)的SGA相關(guān)部分的參數(shù)調(diào)整值（參考V$DB_CACHE_ADVICE、V$SHARED_POOL_ADVICE），關(guān)于PGA也有相關(guān)視圖V$PGA_TARGET_ADVICE等。
Data buffer
9i中保留了8i中的參數(shù)，如設(shè)置了新的參數(shù)，則忽略舊的參數(shù)。9i中用db_cache_size來(lái)取代db_block_buffers，用db_keep_cache_size取代buffer_pool_keep,用db_recycle_cache_size取代buffer_pool_recycle；這里要注意9i中設(shè)置的是實(shí)際的緩存大小而不再是塊的數(shù)量。另外9i新增加了db_nk_cache_size，這是為了支持在同一個(gè)數(shù)據(jù)庫(kù)中使用不同的塊大小而設(shè)置的。對(duì)于不同的表空間，可以定義不同的數(shù)據(jù)塊的大小，而緩沖區(qū)的定義則依靠該參數(shù)的支持。其中n可以為2、4、6、8、16等不同的值。在這里順便提及的一個(gè)參數(shù)就是db_block_lru_latches，該參數(shù)在9i中已經(jīng)成為了保留參數(shù)，不推薦手工設(shè)置。
PGA
??? 在9i里面這部分也有了很大的變化。在獨(dú)立模式下，9i已經(jīng)不再主張使用原來(lái)的UGA相關(guān)的參數(shù)設(shè)置，而代之以新的參數(shù)。假如workarea_size_policy=AUTO（缺?。?，則所有的會(huì)話的UGA共用一大塊內(nèi)存，該內(nèi)存在 pga_aggregate_target 設(shè)置以內(nèi)分配。在我們根據(jù)前面介紹的方法評(píng)估了所有進(jìn)程可能使用的最大PGA內(nèi)存之后，我們可以通過(guò)在初始化參數(shù)中設(shè)置這個(gè)參數(shù)，從而不再關(guān)心其他 ”*_area_size” 參數(shù)。
SGA_MAX_SIZE
在9i中若設(shè)置了SGA_MAX_SIZE，則在總和小于等于這個(gè)值內(nèi)，可以動(dòng)態(tài)的調(diào)整數(shù)據(jù)緩沖區(qū)和共享池的大小
SQL> show parameters sga_max_size
NAME???????????????????????????????? TYPE??? VALUE
------------------------------------ ------- -------------
sga_max_size???????????????????????? unknown 193752940
SQL>
SQL>? alter system set db_cache_size = 30000000;
System altered.
SQL>? alter system set shared_pool_size = 20480000;
System altered.
l?????? Lock_sga = true 的問(wèn)題
?
由于幾乎所有的操作系統(tǒng)都支持虛擬內(nèi)存，所以即使我們使用的內(nèi)存小于物理內(nèi)存，也不能避免操作系統(tǒng)將SGA換到虛擬內(nèi)存（SWAP）。所以我們可以嘗試使得SGA鎖定在物理內(nèi)存中不被換到虛擬內(nèi)存中，這樣減少頁(yè)面的換入和換出，從而提高性能。但在這里遺憾的是，windows是無(wú)法避免這種情況的。下面我們來(lái)參考在不同的幾個(gè)系統(tǒng)下怎么實(shí)現(xiàn)lock_sga
AIX 5L（AIX 4.3.3以上）
?
logon aix as root
?
cd /usr/samples/kernel
?
./vmtune (信息如下) v_pingshm已經(jīng)是1
?
./vmtune -S 1
?
然后oracle用戶修改initSID.ora 中 lock_sga = true
?
重新啟動(dòng)數(shù)據(jù)庫(kù)
?
HP UNIX
?
Root身份登陸
?
Create the file "/etc/privgroup":? vi /etc/privgroup
?
Add line "dba MLOCK" to file
?
As root, run the command "/etc/setprivgrp -f /etc/privgroup":
?
$/etc/setprivgrp -f /etc/privgroup
?
oracle用戶修改initSID.ora中l(wèi)ock_sga=true
?
重新啟動(dòng)數(shù)據(jù)庫(kù)
?
SOLARIS (solaris2.6以上)
?
8i版本以上數(shù)據(jù)庫(kù)默認(rèn)使用隱藏參數(shù) use_ism = true ，自動(dòng)鎖定SGA于內(nèi)存中,不用設(shè)置lock_sga, 如果設(shè)置 lock_sga =true 使用非 root 用戶啟動(dòng)數(shù)據(jù)庫(kù)將返回錯(cuò)誤。
?
WINDOWS
?
不能設(shè)置lock_sga=true,可以通過(guò)設(shè)置pre_page_sga=true,使得數(shù)據(jù)庫(kù)啟動(dòng)的時(shí)候就把所有內(nèi)存頁(yè)裝載，這樣可能起到一定的作用。
?
l?????? 關(guān)于內(nèi)存參數(shù)的調(diào)整
?
關(guān)于參數(shù)調(diào)整，是oracle的復(fù)雜性的一個(gè)具體體現(xiàn)。通常來(lái)講，我們更傾向于讓客戶做statspack報(bào)告，然后告訴我們os監(jiān)控的狀況，在這些的信息的基礎(chǔ)上，再向客戶索取具體的詳細(xì)信息以診斷問(wèn)題的所在。系統(tǒng)的調(diào)整，現(xiàn)在我們通常采用從等待事件入手的方法。因?yàn)橐粋€(gè)系統(tǒng)感覺(jué)到慢，必然是在某個(gè)環(huán)節(jié)上出現(xiàn)等待，那么我們從等待最多的事件入手逐步診斷并解決問(wèn)題。
對(duì)于內(nèi)存的調(diào)整，相對(duì)來(lái)說(shuō)簡(jiǎn)單一些，我們首先可以針對(duì)數(shù)據(jù)緩沖區(qū)的大小來(lái)看。首先觀察命中率
數(shù)據(jù)緩沖區(qū)命中率
?
SQL> select value from? v$sysstat where name ='physical reads';
?
???? VALUE
?
----------
?
???? 14764
?
SQL>? select value from? v$sysstat where name ='physical reads direct';
?
???? VALUE
?
----------
?
??????? 50
?
SQL> select value from? v$sysstat where name ='physical reads direct (lob)';
?
???? VALUE
?
----------
?
???????? 0
?
SQL> select value from? v$sysstat where name ='consistent gets';
?
???? VALUE
?
----------
?
167763
?
SQL> select value from v$sysstat where name = 'db block gets';
?
???? VALUE
?
----------
?
???? 14305
?
這里命中率的計(jì)算應(yīng)該是
?
令 x = physical reads direct + physical reads direct (lob)
?
命中率 =100 - ( physical reads - x) / (consistent gets + db block gets - x)*100
?
通常如果發(fā)現(xiàn)命中率低于90%,則應(yīng)該調(diào)整應(yīng)用可可以考慮是否增大數(shù)據(jù)緩沖區(qū)
?
共享池的命中率
?
SQL> select sum(pinhits)/sum(pins)*100 "hit radio" from v$librarycache;
?
?hit radio
?
----------
?
?99.809291
?
假如共享池的命中率低于95%,就要考慮調(diào)整應(yīng)用（通常是沒(méi)使用bind var ）或者增加內(nèi)存
?
關(guān)于排序部分
?
SQL>? select name,value from v$sysstat where name like '%sort%';
NAME????????????????????????????????????????????????????????????????? VALUE
---------------------------------------------------------------- ----------
sorts (memory)??????????????????????????????????????????????????????? 67935
sorts (disk)????????????????????????????????????????????????????????????? 1
sorts (rows)?????????????????????????????????????????????????????????? 7070
SQL>
假如我們發(fā)現(xiàn)sorts (disk)/ (sorts (memory)+ sorts (disk))的比例過(guò)高，則通常意味著sort_area_size部分內(nèi)存較小，可考慮調(diào)整相應(yīng)的參數(shù)。
關(guān)于log_buffer
?
SQL>? select name,value from v$sysstat
?
? 2??? where name in('redo entries','redo buffer allocation retries');
?
NAME????????????????????????????????????????????????????????????????? VALUE
?
---------------------------------------------------------------- ----------
?
redo entries??????????????????????????????????????????????????????? 2325719
?
redo buffer allocation retries?????????????????????????????????????????? 10
?
假如 redo buffer allocation retries/ redo entries 的比例超過(guò)1%我們就可以考慮增大log_buffer
通常來(lái)說(shuō)，內(nèi)存的調(diào)整的焦點(diǎn)就集中在這幾個(gè)方面，更多更詳細(xì)的內(nèi)容，建議從statspack入手來(lái)一步一步調(diào)整。最后關(guān)于內(nèi)存的調(diào)整，再?gòu)?qiáng)調(diào)這一點(diǎn)，一定要結(jié)合操作系統(tǒng)來(lái)衡量，任何理論都必須要實(shí)踐來(lái)檢驗(yàn)。在操作系統(tǒng)中觀察 page? in/out 狀況，發(fā)現(xiàn)問(wèn)題嚴(yán)重，應(yīng)該考慮調(diào)小SGA。
?
l?????? 32bit 和 64bit 的問(wèn)題
?
對(duì)于oracle來(lái)說(shuō)，存在著32bit與64bit的問(wèn)題。這個(gè)問(wèn)題影響到的主要是SGA的大小。在32bit的數(shù)據(jù)庫(kù)下，通常oracle只能使用不超過(guò)1.7G的內(nèi)存，即使我們擁有12G的內(nèi)存，但是我們卻只能使用1.7G，這是一個(gè)莫大的遺憾。假如我們安裝64bit的數(shù)據(jù)庫(kù),我們就可以使用很大的內(nèi)存，幾乎不可能達(dá)到上限。但是64bit的數(shù)據(jù)庫(kù)必須安裝在64bit的操作系統(tǒng)上，可惜目前windows上只能安裝32bit的數(shù)據(jù)庫(kù)，我們通過(guò)下面的方式可以查看數(shù)據(jù)庫(kù)是32bit還是64bit：
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
PL/SQL Release 8.1.7.0.0 - Production
CORE??? 8.1.7.0.0?????? Production
TNS for 32-bit Windows: Version 8.1.7.0.0 - Production
NLSRTL Version 3.4.1.0.0 - Production
??? 但是在特定的操作系統(tǒng)下，可能提供了一定的手段，使得我們可以使用超過(guò)1.7G的內(nèi)存，達(dá)到2G以上甚至更多。
本文來(lái)自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/pharaohsprince/archive/2005/07/07/416220.aspx