動的SGAと自動メモリ管理に関する検証 その５
＜動的SGAと自動メモリ管理に関する検証 その５＞
ペンネーム：アイスケーキ
オリンピックのメダル奪取に寝不足の毎日が続きますが今回も引き続き動的
SGAと自動メモリ管理について検証をします。
◆環境
Windows XP Pro + SP1
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 – Prod
◆はじめに
前回は動的SGAの動作として共有プール、Javaプール、ラージプール領域が不
足した場合自動的にデフォルト・バッファキャッシュが縮小し共有プール、
Javaプール、ラージプールの拡張が発生する事を確かめてみました。
又、３つのコンポーネント間での領域の貸し借りもありません。
（共有プール ラージプール Javaプール 共有プール）
では自動調整されたコンポーネントに余裕が出た場合にデフォルト・バッファ
キャッシュへ領域が戻されるバターンはあるのでしょうか？
（共有プール ->デフォルト・バッファキャッシュ
Javaプール ->デフォルト・バッファキャッシュ
ラージプール ->デフォルト・バッファキャッシュ）
■その１
(1)共有プールをクリアします（alter system flush shared_pool）
(2)ライブラリキャッシュヒット率が良好であることを確認します。
(3)バッファキャッシュのヒット率を低下させます（今回は98％ ⇒ 83％）
select round(100
* ( ( max(decode(name,'db block gets',value))
+ max(decode(name,'consistent gets',value))
- max(decode(name,'physical reads',value)))
/ ( max(decode(name,'db block gets',value))
+ max(decode(name,'consistent gets',value)))),2) HIT_RATIO
from v$sysstat
/
HIT_RATIO
----------
83.01
SGAコンポーネント領域については何も変化はありませんでした。
（バッファーキャッシュヒット率が動的SGAのトリガーとなっていなければ全
く検討ハズレなんですけど）
TIME COMPONENT OPER_TYPE GAP Final Size STATUS ------------------- -------------------- --------- --- ---------- -------- 2004/08/23 15:03:44 DEFAULT buffer cache SHRINK -4 76 COMPLETE 2004/08/23 15:03:44 shared pool GROW 4 40 COMPLETE 2004/08/23 15:03:58 DEFAULT buffer cache SHRINK -4 72 COMPLETE 2004/08/23 15:03:58 shared pool GROW 4 44 COMPLETE
マニュアルを見てもデフォルト・バッファキャッシュが拡張するロジックがあ
るようには思えませんでした。
それなら手動にて変更することは可能なのでしょうか？
■その２
手動でデフォルト・バッファキャッシュを拡張変更してみます。
共有プール（44⇒40MB）★縮小
デフォルト・バッファキャッシュ（72⇒76MB）★拡張
sga_target（128MB⇒140MB:sga_max_size)
TIME COMPONENT OPER_TYPE GAP Final Size STATUS ------------------- -------------------- --------- --- ---------- -------- 2004/08/23 15:03:58 DEFAULT buffer cache SHRINK -4 72 COMPLETE 2004/08/23 15:03:58 shared pool GROW 4 44 COMPLETE
SQL> alter system set sga_target=140M; システムが変更されました。 SQL> alter system set shared_pool_size=40M; システムが変更されました。 SQL> alter system set db_cache_size=76M; システムが変更されました。
SGAコンポーネント領域については何も変化はありませんでした。
デフォルト・バッファキャッシュの拡張は手動でもできないようです。且つ、
共有プールの縮小も手動では何の変化もありません。
（この場合、共有プールの”拡張”指定が再計算のトリガーと考えるべきか）
★Oracle9.2では手動にて共有プールの縮小が可能です。
sga_targetは余裕があるので、共有プールを拡張させます。
SQL> alter system set shared_pool_size=48M;
システムが変更されました。
TIME COMPONENT OPER_TYPE GAP Final Size STATUS
------------------- -------------------- --------- --- ---------- --------
2004/08/23 15:09:03 DEFAULT buffer cache SHRINK -4 80 COMPLETE
2004/08/23 15:09:03 shared pool GROW 4 48 COMPLETE
^^^
共有プールが拡張しました。sga_targetの範囲で余った領域がデフォルト・バ
ッファキャッシュに割り当てられ再計算もされています（72⇒80M）
結果としてデフォルト・バッファキャッシュも拡張しました。
■今回の結果
共有プール、Javaプール、ラージプール領域サイズに余裕が出てデフォルト・
バッファキャッシュ領域が不足しても動的SGAの動作としては、サイズ変更は
発生しないようです。（バッファキャッシュ領域が不足しアプリケーションが
待機となる事の解決策として動的SGA機能に期待するのは難しいようです）
どうしてもデフォルト・バッファキャッシュを増やしたい場合
sga_max_size>=sga_targetであれば手動でsga_targetを増やし共有プール、
Javaプール、ラージプール領域を手動調整する事で実現する事は可能です。
（残りのサイズがデフォルト・バッファキャッシュに割り当てられるので差分
が現デフォルト・バッファキャッシュより大きくなるように考慮しなければな
りませんが）
共有プール、Javaプール、ラージプールサイズに余裕があると判断するのはロ
ジック的に困難なのかもしれませんが手動でもこの３コンポーネントを縮小で
きないのは不思議でした。
特に不思議なのは、
sga_target<=SGAコンポーネント総サイズの状況で
alter system set db_cache_size=”拡張予定サイズ”;
を使用して拡張エラーを起こした場合
（当然SGAサイズに余裕がないので拡張不能ですけど）
V$SGA_RESIZE_OPS動的ビューには以下のレコードが記録され
TIME COMPONENT OPER_TYPE GAP Final Size STATUS ------------------- -------------------- --------- --- ---------- ------ 2004/08/23 15:06:13 shared pool SHRINK 0 44 ERROR 2004/08/23 15:06:13 DEFAULT buffer cache GROW 0 72 ERROR ^^^^
共有プールを縮小してデフォルト・バッファキャッシュを増やそう(GROW)とし
ているかに見えるのです。
（そういうロジックが存在している証拠にも思えるのです）
お盆休み明けの茅ヶ崎より