DBチューニング

DBチューニング作業の依頼を受けました

利用者が増加したことから、キャッシュが不足してきたとのこと。

キャッシュの不足についてはZabbixで値を確認しているようです。(Zabbixについても勉強しないといけないですね)

ディクショナリヒット率が下がったことから、recursive callsのスパイクが発生しているため、DBのshared pool sizeを増やして対応するとのことです。

なんのこっちゃ

ということで調べてみます。

DBチューニング

サーバーの性能を最大限に利用するため、DBが使用するメモリ使用量を最適化する。これによってディスクI/Oを減らすのが目的とのこと。

ディスクI/O

データの読み書き操作のこと

ディクショナリヒット率

キャッシュヒット率のDB版っぽい感じかな？

詳しくはOracleの勉強をする必要がありそうです。

recursive calls

再起SQL文の実行回数。

再起SQL文っていうのは、ユーザーが出したSQLを、Oracleが解析するときに発行するSQLとのこと。

スパイク

急激に増加すること

できるITの人たちの仲だと一般的な言葉なのかな？　初めて聞きましたが、これからよく聞くことになるのかな。

shared pool size

共有プールサイズのこと

この値を今回はSQLでいじくります。

共有プール

以下のコンポーネントで主に構成されている。

• ライブラリキャッシュ
• データ・ディクショナリ・キャッシュ
• サーバー結果キャッシュ

共有プール内のキャッシュの多くは、必要に応じてサイズを自動的に変更している。

共有プールに空きがない場合は、新しいエントリ(データ入力)を受け入れるために、古いエントリを消している。

ライブラリキャッシュやデータ・ディクショナリ・キャッシュのミスは、バッファ・キャッシュでのミスよりも影響が大きいとのこと。

共有プールのサイズを調整して頻繁に利用されるデータが確実にキャッシュされるようにする必要があるらしい。

バッファ・キャッシュ？？？な状態ですので、これについても後で調べる必要がありますね。

作業手順

①事前確認(shared_pool_sizeの確認)

SQL> set line 1000

SQL> show parameter pool

②shared_pool_sizeの変更

SQL> ALTER SYSTEM SET shared_pool_size=共有プールのサイズ

SQL> ;

③確認(shared_pool_sizeの確認)

SQL> set line 1000

SQL> show parameter pool