Undocumented secrets for super-sizing your PGA
今日はSearchOracle.comをご紹介します。 このサイトはIT総合メディアのTechTargetが運営する Oracleの情報発信サイトです。 TechTargetは様々なジャーナリズムに関する賞を受賞している メディアですが、SearchOracle.comもその名に恥じない コンテンツを発信できていると思います。 ちなみに08/26号でご紹介したPete Finniganさんの Security問題については、Pete Finniganさんに 直接インタビューしたPodcastが配信されていますので Pete Finniganさんの生声で解説を聞くことができます。 http://imoment.web.fc2.com/20060827.html 数あるコンテンツの中から、前々回にご紹介した Donald Burlesonさんの記事をピックアップします。 <前々回の記事はこちら> http://imoment.web.fc2.com/20060904.html PGAやPGA_AGGREGATE_TARGETがわからない方は先に 解説の後半を確認してください。 タイトルからも想像つくと思いますが、PGAに関する記事になります、 簡単に記事の内容を説明すると 皆さんもご存知PGA_AGGREGATE_TARGETが、実はいくら大きなサイズを 指定しても隠されたパラメータによって実際に割り当てられるサイズには 制限が発生してしまうという内容です。 その制限の中でも"_pga_max_size"は比較的有名ですね。 このサイズはデフォルトで200MBで、１つのプロセスが使用できる 最大のPGAサイズはこの値の半分となってしまいます。 ですからどんなに競合セッションがなく、大きなPGA_AGGREGATE_TARGETが 指定されていても100MBを超えるソート処理はDISKソートになってしまうんです。 ちなみにPGA_AGGREGATE_TARGETの5%のサイズがそれより小さい場合は その小さいサイズの方が制限サイズとして優先されてしまいます。 この記事の確証を取るためになんと２３０頁にも及ぶ テストがなされています。 aggregateとは集合とか総数とか言うニュアンスを持つ単語です。 aggregate functionと言えば、countやsum,aveなどの関数のことです。 ■ SearchOracle.com http:// searchoracle.techtarget.com/home/ ■ 引用ページ http://searchoracle.techtarget.com/tip/1,289483,sid41_gci1116697,00.html ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 記事本文 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ◆ Undocumented secrets for super-sizing your PGA Introduction Almost every Oracle professional agrees that the old-fashioned sort_area_size and hash_area_size parameters imposed a cumbersome one-size-fits-all approach to sorting and hash joins. Different tasks require different RAM areas, and the trick has been to allow "enough" PGA RAM for sorting and hash joins without having any high-resource task "hog" all of the PGA, to the exclusion of other users. Oracle9i introduced the pga_aggregate_target parameters to fix this resource issue, and by-and-large, pga_aggregate_target works very well for most systems. You can check your overall PGA usage with the v$pga_target_advice advisory utility or a STATSPACK or AWR report. High values for multi-pass executions, high disk sorts, or low hash join invocation might indicate a low resource usage for PGA regions. Let's take a look at the issues surrounding the hidden limits of pga_aggregate_target. ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 英語の語順に近い解釈 ※自然な語順で解釈する癖をつけるために 敢えて不自然な日本語になっています。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ◆ Undocumented secrets for super-sizing your PGA PGAを大きくするためのドキュメント化されていない秘密 Introduction 導入 Almost every Oracle professional agrees ほとんどのOracleプロは同意します。 that the old-fashioned sort_area_size and hash_area_size parameters imposed 時代遅れのsort_area_sizeやhash_area_sizeが 強制していたことを a cumbersome one-size-fits-all approach 非効率で扱いづらいサイズ固定のアプローチを to sorting and hash joins. sort処理やhash join処理に対する Different tasks require different RAM areas, 異なる処理は異なるメモリ領域を要求します。 and the trick has been to allow "enough" PGA RAM そしてそのアプローチは充分すぎるPGAを許してきました。 for sorting and hash joins ソート処理やhash joinに without having any high-resource task "hog" all of the PGA, to the exclusion of other users. PGAを占有してしまうほど多くのリソースを必要とするタスクに 他のユーザを排除してしまうことをさせることなく Oracle9i introduced the pga_aggregate_target parameters 9iは紹介しました。pga_aggregate_targetを to fix this resource issue, このリソース問題を解決するために and by-and-large, pga_aggregate_target works very well そして総じてpga_aggregate_targetはとても良く機能しました。 for most systems. ほとんどのシステムに。 You can check あなたはチェックすることができまます。 your overall PGA usage あなたの全てのPGA使用状況を with the v$pga_target_advice advisory utility v$pga_target_adviceによるアドバイスによって or a STATSPACK or AWR report. またはSTATSPACKやAWRリポートで High values for multi-pass executions, multi-pass実行の高い値や high disk sorts, 高い割合のディスクソートや or low hash join invocation または、hash joinが少ないことなどは might indicate 兆候を示しているかもしれません。 a low resource usage for PGA regions. PGA領域の低い使用率を。 Let's take a look at the issues それではそれらの問題を見ていきましょう。 surrounding the hidden limits of pga_aggregate_target. pga_aggregate_targetに関連する隠された制限についての。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 用語解説 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ Undocumented ※ドキュメント化されていないということは Oracleが正式にサポートしない非公式な手法であることを 意味します。 old-fashioned ※9i以降で、sort_area_sizeやhash_area_size を（メインで）使用することは時代遅れです。 cumbersome ※大きかったり、重かったり、非効率な為に扱いづらい場合に 使用します。 sorting and hash joins. ※PGAは主にソートやハッシュ結合で使用されます。 "enough" PGA RAM ※小さなPGAサイズで充分な処理にも固定のサイズを 与えてしまうので"enough"が強調されています。 hog ※元々は食用ブタを指していたものが、欲張りなイメージになり 最終的には分け前以上に奪い取ろうとする人を指すようになり、 動詞としても使われるようになりました。 今回は、PGAを占有する高負荷処理を指しています。 by-and-large ※どの点から見ても同じというニュアンスで、 「概して」とか「総じて」と訳されます。 v$pga_target_advice advisory utility ※このビューがpga_aggregate_targetの最適なサイズを 考慮する際に役立ちます。 AWR report. ※10gの新機能でStatsPackのように自分で 統計やイベントを調査することなく Oracleがネックとなっている処理を提示してくれます。 multi-pass executions, ※多くのディスクソートが発生してしまった処理を multi-pass executionと呼びます。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 解説 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 隠しパラメータである"_pga_max_size"のデフォルト設定値を確認するには x$表というv$ビューのベースとなるOracleの内部表を参照しなければなりません。 col parameter for a55 col descr for a100 col val for a10 select i.ksppinm parameter ,v.ksppstvl VAL,i.ksppdesc descr from x$ksppi i, x$ksppcv v where i.indx = v.indx and i.ksppinm like '\_pga%' escape '\' order by PARAMETER; ※アンダースコアは１文字ワイルドカードなので エスケープ文字を指定して検索文字として認識させています。 また、変更はalter systemで変更することができます。 alter system set "_pga_max_size"=xxxxxxxx scope=both ※アンダースコアを含むので" " で囲む必要があります。 隠しパラメータでも一度値を設定した後はshow parameterでも確認が可能になります。 show parameter pga ※以下わかっている人は飛ばしてください --PGAについて-- Program Global Area 専用サーバ接続の際にソート処理や結合処理、SQLLOAD時の書込みバッファなどで 使用されます。 （共有サーバ接続の際はLarge Pool（定義してなければShared pool）に格納されます） --PGA_AGGREGATE_TARGETについて-- 9iより前のバージョンではPGAのサイズを明示的に指定するのではなく、 sort_area_sizeやhash_area_size,bitmap_merge_area_sizeなど 個々の作業領域を間接的に指定していました。 その場合、同時接続が最大でいくつになるかによって、 最大のPGAが雪だるま式に膨れ上がっていくことになっていました。 9iからはこのパラメータが作成され、同時最大接続にかかわらず、 最大のPGAサイズをこの値で指定できるようになりました。 厳密にはここで指定するのはPGAサイズではなく、SQL作業領域に限定されます SQL作業領域は、ソート領域,ハッシュ領域,ビットマップ領域などで、 SQL作業領域以外ではプライベートSQL領域やカーソル領域、SessionMemoryなどがあります。 ですから、このサイズよりもMAXとして割り当てられる領域は 少しだけ大きくなりますね。 9iでは、専用サーバ接続専用の機能でしたが、 10gからは、共有サーバ接続でもこの機能が共有サーバのSQL作業領域で 有効に働くようになりました。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 編集後記 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 今号からご購読いただいた皆様はじめまして。 本日も最後まで読んでいただきありがとうございます。 エレクトロキューショニスト号が突然天国へ 召されてしまいました。 名前らしいと言ってしまうと不謹慎ですが、 本当に人生も馬生もわからないですね。 いつ自分が天国(?)に行くことになっても 後悔の無い日々を送りたいですね。 ご冥福をお祈り致します。 それとは関係ありませんが、 私のACアダプターが突然天国へ召されてしまい 週末に作成した原稿を配信することができず、 ここまで遅れてしまいました。 皆さんもコードの取り扱いには気をつけましょう^^ それではまた。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ おわりに ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 記述誤りなどのご指摘、 記事に関する疑問点・質問・感想・ご意見・ご感想など yakusa_oracle@yahoo.co.jpまでお願い致します。 簡単な自己紹介はこちら http://pr2.cgiboy.com/S/3191274 バックナンバー兼ブログはこちら http://imoment.web.fc2.com/ 登録・解除はこちらから http://www.mag2.com/m/0000200441.htm
