Linux 核心引數及Oracle相關引數調整

我們一般在Linux 上安裝設定Oracle 資料庫或者在更換或升級硬體的時候都需要
配置Linux 系統的核心引數, 然後才是調整Oracle 系統引數 。具體這些引數的實質意
義是什麼，為什麼要做調整，如何合理調整？ 帶著這些問題我們做以下的一些分析以
及測試。 注意： 以下的一些測試可能只適用於Linux 系統，且測試Linux 系統為64Bit,
32Bit Linux 系統可能有不一樣 。

測試環境： Linux AS 4.0 U5 64Bit
核心版本： 2.6.9-55.ELsmp #1 SMP x86_64


1. Linux 系統下的核心引數：
[root@ECSDB etc]# cat sysctl.conf 或者到 /proc/sys/kernel 下檢視。
kernel.shmall = 2097152
kernel.shmmax = 8405194752
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144   

----- 小技巧： 修改 /etc/sysctl.conf 檔案之後立刻生效命令 # sysctl -p

2. Linux 下核心引數調整  

kernel.shmmax ----

SHMMAX Available physical memory Defines the maximum allowable size
of one shared memory segment. The SHMMAX setting should be large enough
to hold the entire SGA in one shared memory segment. A low setting can
cause creation of multiple shared memory segments which may lead to
performance degradation.


Shmmax 是核心引數中最重要的引數之一，用於定義單個共享記憶體段的最大值，
shmmax 設定應該足夠大，能在一個共享記憶體段下容納下整個的SGA ,設定的過低可能會
導致需要建立多個共享記憶體段，這樣可能導致系統效能的下降 。

http://www.itpub.net/showthread.php?threadid=551229&pagenumber

    論壇上的一些說法： SHMMAX 僅僅是在共享記憶體段被建立的時候用來比較的一個數
字，當共享記憶體段被一個程式(Process)建立，作業系統檢查是否被要求的共享記憶體段
的值大於shmmax 的值 ，如果是，那麼將會丟擲一個錯誤。這個時候系統會建立另外的
一個或多個共享記憶體段滿足程式的需求 。一般來說，共享記憶體段個數和系統效能沒有
太直接的關係，也不會對效能產生太大的影響。

    Steve Adams 在他的小冊子中說過，在例項啟動以及Server Process 建立的時候，
多個小的共享記憶體段可能會導致當時輕微的系統效能的降低(在啟動的時候 需要去創
建多個虛擬地址段，在程式建立的時候要讓程式對多個段進行“識別”，會有一些影響)，
但是其他時候都不會有影響。這意味著如果你的程式不是經常Create Processes（以及
Destroy Them）,效能方面就不是考慮的問題。

      當然Oralce 的建議是希望一個大的共享記憶體段能容納整個SGA，這樣在任何時候
都不會有甚至輕微的效能下降的隱患。

      Oracle 安裝文件建議 32Bit Linux 系統設定shmmax 為32Bit 最大的限制值
(setting shmmax to the 32-bit number limit),也就是4G 。

       所以一般來說，1-4G 的實體記憶體，可以直接設定shmmax 為最大實體記憶體即可，那
麼SGA 肯定在一個共享記憶體段中，32Bit Linux 系統實體記憶體大於4G 的設定為4G 即可 。
總之，一般設定shmmax >=SGA (32Bit 系統是否支援到1.7G 以上SGA 需要注意) 。
如果是64Bit 的Linux 作業系統，shmmax 設定為大於SGA_MAX_SIZE 即可。
(僅供參考)


http://www.itpub.net/551203,1.html

Ipcs  -sa 可以看到共享記憶體段個數

3. Oracle 下需要做調整的引數
SGA_MAX_SIZE
SGA_TARGET
DB_CACHE_SIZE


SGA_MAX_SZIE 為例項允許使用的sga 上限,一個靜態引數,是不能動態修改的.
SGA_TARGET 為10g 推出的sga 自動管理的引數,動態引數,可以動態修改.
sga_max_size 與 SGA 各元件大小的關係
設定的 sga_max_size 小於實際的SGA 中各個pool 的尺寸總和的大小，那麼
sga_max_size 的值會被oracle 自動以實際的SGA 的總尺寸代替。如果不設定
sga_max_size ，oracle 會自動的以實際的SGA 的總尺寸來設定sga_max_size 的值。
設定 sga_max_size 的值為大於SGA 中各個pool 的尺寸總和的值：但是
sga_max_size 的值相對於所有可用的實體記憶體來說，是一個合理的值。sga_max_size
的實際的值和pfile 中的sga_max_size 指定的值是一樣的。  

在Oracle 10g 中引入了一個非常重要的引數：SGA_TARGET，這也是Oracle 10g
的一個新特性。自動共享記憶體管理（Automatic Shared Memory Management ASMM），控
制這一特性的，就僅僅是這個引數SGA_TARGE。設定這個引數後，你就不需要為每個內
存區來指定大小了。SGA_TARGET 指定了SGA 可以使用的最大記憶體大小，而SGA 中各個內
存的大小由Oracle 自行控制，不需要人為指定。Oracle 可以隨時調節各個區域的大小，
使之達到系統效能最佳狀態的個最合理大小，並且控制他們之和在SGA_TARGET 指定的
值之內。一旦給SGA_TARGET 指定值後（預設為0，即沒有啟動ASMM），就自動啟動了ASMM
特性。

10g 下設定 SGA_TARGET 之後啟動ASSM 特性之後， 只有以下的這些區的記憶體大小動態
共享起來：
* Buffer cache (DB_CACHE_SIZE)
* Shared pool (SHARED_POOL_SIZE)
* Large pool (LARGE_POOL_SIZE)
* Java pool (JAVA_POOL_SIZE)
* Streams pool (STREAMS_POOL_SIZE)
而SGA 中的其他區域的記憶體大小仍然是固定不共享的。
它的含義和SGA_MAX_SIZE 的一樣，也表示SGA 最大的大小，於是它也就有了一個
限制，那就是它的大小不能大於SGA_MAX_SIZE 的大小。
Oracle10g 下， SGA_MAX_SIZE 仍然表示SGA 的大小的上限值，而SGA_TARGET 是
SGA 的所有元件的大小的最大值之和，即當SGA_TARGET< SGA_MAX_SIZE 的時候，oracle
就會忽略SGA_MAX_SIZE 的值，SGA_TARGET 也就成了SGA 的在此例項中的上限制，它能
動態改變大小，但是不能夠大於SGA_MAX_SIZE 的值。

有人曾經做過試驗，在某些版本中（可能在我的版本之後的版本），當SGA_TARGET
< SGA_MAX_SIZE 時，例項重啟以後SGA_MAX_SIZE 就變成SGA_TARGET 的大小了。

在11g 中，這個SGA_TARGET 只能設定是等於SGA_MAX_SIZE 的大小了，設定比它
小，oracle 會自動幫你調整，設定比它大，那還是出錯。現在可以自己想想，oracle
對SGA_TARGET 的大小處理在往正確的簡單的方向前進中。

SGA_TARGET 帶來一個重要的好處就是，能使SGA 的利用率達到最佳，從而節省內
存成本。因為ASMM 啟動後，Oracle 會自動根據需要調整各個區域的大小，大大減少了
某些區域記憶體緊張，而某些區域又有記憶體空閒的矛盾情況出現。

come from：http://blog.zol.com.cn/1084/article_1083499.html