Oracle8 Tuning
〜SHARED_POOL_SIZEの検討〜
０．更新履歴
- 2001.01.19 新規作成
１．SHARED_POOL_SIZEの検討
１．１．現在利用されているSHARED_POOL_SIZEの確認
- SQL*Plusを起動し，system/managerでログインする．
- 次の様にSQL文を実行する．
db1% sqlplus system/manager
SQL*Plus: Release 8.1.5.0.0 - Production on Fri Jan 19 22:13:16 2001
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Connected to:
Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production
SQL> select sum(sharable_mem) from v$db_object_cache;
SUM(SHARABLE_MEM)
-----------------
2436668
SQL> select sum(sharable_mem) from v$sqlarea;
SUM(SHARABLE_MEM)
-----------------
1808447
SQL> select sum(250*users_opening) from v$sqlarea;
SUM(250*USERS_OPENING)
--------------------
250
SQL>
|
- このそれぞれのSQL文が書き出しているものは，
- DBオブジェクト・キャッシュ
- SQLエリアにおける共有メモリー使用量の合計
- 各SQLを所有しているユーザー数？
- となり，それらを合計すると，4,245,365となる． この値が，共有プールの必要最小限の容量の目安となる．
- 現在の共有プールサイズ(shared_pool_size)は，show parameterやinit.oraファイルで確認したとおり，15,728,640となっているので，十分足りていることになる．
- 一般的には，shared_pool_sizeは1.3倍に設定すると良いといわれている．
- また，ユーザー数が数名のシステムでは1MB，数十名程ではデフォルト（今回の15,728,640），大人数が利用するシステムでは10MB程度が適切な値とされている．
２．２．ライブラリキャッシュの検討
ライブラリキャッシュとは，次の様なライブラリキャッシュオブジェクトをキャッシュしているものである．
- パッケージ
- プロシージャ
- ファンクション
- 共有カーソル
- 無名のPL/SQLブロック
- 表定義
- ビュー定義
- フォーム定義
チェックするのは，ヒット率とリロードの値である．
ヒット率は，１に近い程，キャッシュ内に存在したことになり，パフォーマンスが高いことの証明になる．
リロードとは，オブジェクトの再初期化と再ロードを行った回数で，0に近いほうが良い．
前出のreport.txtには，ライブラリキャッシュについて次の様なレポートが作成されている．
LIBRARY GETS GETHITRATI PINS PINHITRATI RELOADS INVALIDATI ------------ ---------- ---------- ---------- ---------- ---------- ---------- BODY 1 1 1 1 0 0 CLUSTER 46 1 70 1 0 0 INDEX 56 .018 56 .018 0 0 OBJECT 0 1 0 1 0 0 PIPE 0 1 0 1 0 0 SQL AREA 9505 .961 61914 .989 1 127 TABLE/PROCED 919 .838 1468 .716 48 0 TRIGGER 0 1 0 1 0 0 |
- GETHITRATIOとPINHITRATIOがヒット率
- RELOADSがリロード
PIHHITRATIOは1に近いほうが良いので，この場合，INDEXについてのヒット率がかなり低いことになる．
また，RELOADSはTABLE/PROCEDに関する回数が多い．
この値を改善したい場合は，SHARED_POOL_SIZEの値を大きくする．
２．３．ディクショナリキャッシュの検討
ディクショナリキャッシュとは，データディクショナリの内容をキャッシュしている．
チェックするのは次のとおりである．
| カウンタ | 説明 |
|---|---|
GET_MISS |
キャッシュ上になかったオブジェクト情報の合計． |
SCAN_MISS |
スキャンミスの合計 |
CUR_USAGE |
有効なデータのキャッシュエントリ総数 |
COUNT |
キャッシュ内のエントリ総数 |
- GET_MISSとSCAN_MISSの値が0に近いほうが良い．
- キャッシュがいっぱいになると，CUR_USAGEがCOUNTと等しくなる． COUNTはCUR_USAGEよりも常に大きい状態になっていたほうが良い．
前出のreport.txtには，ディクショナリキャッシュについて次の様なレポートが作成されている．
NAME GET_REQS GET_MISS SCAN_REQ SCAN_MIS MOD_REQS COUNT CUR_USAG --------------- -------- -------- -------- -------- -------- -------- -------- dc_tablespaces 2966 8 0 0 0 11 9 dc_free_extents 3036 957 739 0 2391 56 26 dc_segments 1524 158 0 0 722 148 147 dc_rollback_seg 240 0 0 0 0 16 7 dc_used_extents 976 580 0 0 976 232 203 dc_tablespace_q 127 1 0 0 127 23 1 dc_files 106 3 0 0 52 14 3 dc_users 2077 9 0 0 0 12 10 dc_user_grants 1497 8 0 0 0 20 8 dc_objects 1081 233 0 0 408 305 300 dc_usernames 655 1 0 0 0 21 2 dc_object_ids 490 125 0 0 104 215 206 dc_constraints 188 94 0 0 188 51 49 dc_sequences 8 7 0 0 1 9 8 dc_profiles 2 1 0 0 0 14 1 dc_histogram_de 269 225 0 0 225 229 225 |
この場合，次の様に考えられる．
- CUR_USAGEの値はCOUNTを下回っているので問題ない
- SCAN_MISSも0なので問題ない．
- GET_MISSが若干ある．
この値を改善したい場合は，SHARED_POOL_SIZEの値を大きくする．
