サブ・ヒープ(Subheap)を含んでいます。ープは基本的に同じ構造を持ちます。インタの役割をします。9i以降の適切な環境を満足する、複数の最上位のヒープを持つことができます。List)形式で率いています。物理的に一つのグラニュー(Granule)を使用します。1Gであれば16Mです(10gあたり)。チャンク(Chunk)で構成されています。KSMSPビューで照会可能です。追加で積む形式に割り当てられるため、ヒープという用語を使用します。・チャンクの状態は大きくfree(直ちに使用可能)、recr(Recreatable。freeあるいはrecr状態であるチャンクは再利用が可能です。・ヒープはフリーリスト(Freelist)を管理するバケットテーブルを持ちます。フリーリストをリンクリスト形式で持っています。フリーチャンクのサイズは、バケット番号が増加するにつれて順次に増加します。・ヒープはLRUリストを持っています。チャンクのリストです。freelist)という別のフリーリストを管理します。Dump)を利用すれば、ヒープの構造を物理的に観察することができます。directoryにヒープ領域のダンプファイルが生じます。ファイルの内容を見てみると、以下の通りです。desc=c000000002e15030上記のようにヒープ・ダンプを実行してみるとヒープの構造についての正確な情報を得ることができます。各ヒープは再びサブヒープ構造を含むことができます。ヒープは、自分が含まれている特定のチャンクにサブヒープのアドレスを保存することにより、サブ・ヒープの位置を管理するのです。Descriptor)の値が設定されているチャンクがサブヒープの位置を保存しているチャンクです。c0000000993293e8がサブヒープのアドレスを指します。次のコマンドを使用して、そのサブ・ヒープをダンプすることができます。0xc0000000993293e8';サブヒープのダンプ内容を確認してみると、以下のようにヒープ・ダンプとほぼ同じ形式を持つことを知ることができます。サブヒープはエクステントサイズが可変であり、予約フリーリストを管理していない点を除けば、最上位のヒープと同じ構造を持ちます。下の図は、ハード解析が過度に発生するアプリケーションを監視した結果です。)待機イベントが起きていることを確認することができます。)のイベントが最も一般的に発生することを確認することができます。ハード解析回数が全体の解析回数と同じくらい過度に発生することを確認することができます。Value=0カーソル共有手法を適用することにより、ハード解析を避けることができます。SQLが自動的にパラメータの処理が行われるます。SCOPE=MEMORY;次の結果は、カーソル共有を適用した後のパフォーマンスの測定結果です。)待機が消え、ハード解析回数が大きく減少したことが確認できます。Value=0カーソル共有手法を適用することにより、ハード解析を避けることができます。SQLが自動的にパラメータの処理が行われます。SCOPE=MEMORY;次の結果は、カーソル共有を適用した後のパフォーマンスの測定結果です。)待機が消え、ハード解析回数が大きく減少したことが確認できます。SQLの過度の使用は、パフォーマンス上の深刻な問題を引き起こす場合が多いことがあります。SQLの過度の使用によって発生したパフォーマンスの低下の問題の原因を究明してみましょう。Events」が急増していることを簡単に確認することができます。Slow-Down)の原因を究明するために、問題の時点(10時17分)の待機イベントの発生内容を確認してみます。freeであることが確認できます。free待機イベントの急激な発生と関連があることを推測することができます。cache)待機イベントが多く発生していることを確認することができます。pool))とラッチフリー(ライブラリキャッシュ)待機イベントが同時に発生した場合には、ハード解析がその原因である場合が多くあります。elapsedの推移を確認してみます。count(hard)の値が200回/秒に発生した事実を確認することができます。fragmentationが発生し、これにより、ライブラリキャッシュでのSQL検索や新規SQLの登録などを行うことが時に遅延が発生していると分析できます。Client」プログラムであることを確認することができます。SQL」であることがわかります。Page本サイトに掲載されている情報は日本エクセム株式会社が提供しています。