Oracle奥深くて面白いなぁ～。
という事で現場で色々チューニングしてます。
アクセス数がありえないくらい凄いので
どうしようか未だ検討中ですがね。
■Oracle調査 （同時接続コネクション増加方法）
・前提
OS：redhatlinuxEnterpriseES4
Ver：Oracle9.2ｉ
メモリ：8GB。すご・・
フロントWeb/APサーバ：20台
適切なメモリ割り当てについては
日々の運用から検討していく必要あり。
バッファサイズを小さくする事により、
OSのスワップ、ページングの頻度が減少する為。
１セッションで数ギガByteのデータを検索するシステムと、
１０セッションで数メガByteを参照するシステムでは、
どちらがメモリを必要とするか
セッション数では判断つかない。
①PGA：プログラムグローバルエリアは，
SQLなどの作業領域として使われるメモリ領域。
1.PGA_AGGREGATE_TARGET
PGA自体の上限値。
※OLTP(On-Line Transaction Processing)頻繁に
発生する場合はOracleで利用する場合は
メモリの20%程度割り当てるのが妥当。
2.WORKAREA_SIZE_POLICY
パラメータPGA_AGGREGATE_TARGETの有効/無効を決める
②SGA：システムグローバルエリアはOracleインスタンスそのもの。
Oracleを起動した際に割り当てられるメモリのサイズ。
1.SHARED_POOL_SIZE(共有プール領域)
・ライブラリ、ディクショナリキャッシュを指す。
ライブラリキャッシュ：SQL解析、ストアド、PL/SQL
ディクショナリキャッシュ：テーブルの列、属性等
以下の２つのクエリでキャッシュヒット率を調査し、
アサインするメモリのサイズを増やす必要がある。
[本番サーバで確認するクエリ]
SELECT A.RATIO "LIBRARY CACHE HIT RATIO",
DECODE(SIGN(A.RATIO - 0.99),1,
'ライブラリキャッシュのヒット率は十分です',
'SHARED_POOL_SIZEを増やしましょう') "notes"
FROM (SELECT SUM(PINS - RELOADS) /SUM(PINS) RATIO
FROM V$LIBRARYCACHE) A;
SELECT A.RATIO "ROW CACHE HIT RATIO",
DECODE(SIGN(A.RATIO - 0.95),1,
'ディクショナリキャッシュは十分です',
'SHARED_POOL_SIZEを増やしましょう') "notes"
FROM (SELECT SUM(GETS - GETMISSES) /SUM(GETS) RATIO
FROM V$ROWCACHE) A;
※ライブラリキャッシュヒット率99%以上で計算
ディクショナリキャッシュヒット率95以上で計算
2.DB_CACHE_SIZE(DBバッファ)
V$DB_CACHE_ADVICE ← の内容から設定内容を調整
※DB_CACHE_ADVICEパラメタをONにする必要あり
3.LOG_BUFFER(REDOログバッファ)
REDOログ：データに対して行われたすべての変更履歴を記録するファイル。
[本番サーバで確認するクエリ]
SELECT A.RATIO "REDO SPACE WAIT RATIO",
DECODE(SIGN(A.RATIO - 0.01),1,
'LOG_BUFFERを増やしましょう',
'LOG_BUFFERは十分です') "notes"
FROM (SELECT R.VALUE / W.VALUE RATIO
FROM V$SYSSTAT R, V$SYSSTAT W
WHERE R.NAME = 'redo log space requests'
※REDOログバッファの待機割合は1%以下で計算
つづく
