新・ソートに関する検証 その６ - InsightTechnology 旧ブログ
＜新・ソートに関する検証 その６＞ ペンネーム グリーンペペ 今回は実践編です。 実例を元とした検証を行います。 □背景 あるシステムにおいて、同一処理ロジックを行っているにも関わらず、ある特 定のクライアントのみ、実行時間が倍以上かかってしまっています。 調査を進めていくとソート処理を行っているSQL文が悪さをしているらしいこ とが判明しました。 早速、ソート関連の設定を確認してみます。 □環境 OS:Red Hat Linux release 7.1 Oracle:9.2.0.1 □問題点の切り分け その１□ ＠初期化パラメタの確認 SQL> select name,value from v$parameter where name in ('workarea_size_policy','pga_aggregate_target') or name like 'sort%'; NAME
OracleをIn-Memoryで使うためには2 | Insight Technology, Inc.
（前回の続き） DB_KEEP_CACHE_SIZEを可能な限り大きく設定した場合のインデックスレンジ検索の振る舞いを見てみます。 主キー項目であるKEY列に与える条件を調整して戻り行数を変化させてみました。（注目ポイントをハイライト表示させています。） SQL> select * from LARGE_TBL_KEEP where key < 76501; 76500行が選択されました。 実行計画 ---------------------------------------------------------- Plan hash value: 3698628736 ---------------------------------------------------------------------------------------------- | Id | Operatio
OracleをIn-Memoryで使うためには | Insight Technology, Inc.
あるお客様から「頻繁にアクセスされる大きな（というより巨大な）テーブルをメモリ上に常駐させて物理I/Oを削減したいのだけど。」という要望を受けました。 通常、Oracleは（9i以降であれば） 20ブロックもしくはv$buffer_pool.buffers / 50のいずれかより大きなテーブル（long table）は、全件検索時にDB_FILE_MULTIBLOCK_READ_COUNT分のブロックを読み込みながら、どんどんメモリ（キャッシュ）から追い出してしまいます。これは限りあるメモリ資源を有効に活用するための仕組みです。 従って、この場合SGAを単純に大きくすればよいというものではありません。明示的に”KEEP”バッファ・プールを指定して、当該テーブルの属性も”KEEP”に設定しage outされないようにする必要があります。 KEEPバッファ・プールというのは、それほど大きくはな
redhat.com | Red Hat responds.
Platform solutionsArtificial intelligenceBuild, deploy, and monitor AI models and apps. Linux standardizationGet consistency across operating environments. Application developmentSimplify the way you build, deploy, and manage apps. AutomationScale automation and unite tech, teams, and environments. Explore solutions Use casesVirtualizationModernize operations for virtualized and containerized work
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
