2014年4月27日日曜日

SmartScanの検証


最近、業務でExadataを触っておりますが、Exadataの特徴の一つとしてSmartScanがあります。
通常、データベース側でSQL文を発行すると、ストレージからデータを取ってきて、データベースで必要な情報を抽出してSQLを実行します。
これをExadataでは、ストレージ側でデータベースに渡すデータをあらかじめ抽出することによって物理I/Oを減らす機能です。
SmartScanを有効にするには、Direct Path Readである必要があります。
実行計画でDirect Path Readを選択してくれないと、Smart Scanが効かないのが問題となる可能性があります。
一応、こんな方法でSmartScanを効かすことはできます。
alter session set "_serial_direct_read"=true;

とはいえ、アプリ側でalter文を発行するのも嫌、というのはあると思いますので、もう少し調べてみました。
すると、こんな隠しパラメータを見つけました。
_small_table_threshold
11.2からは、セグメントサイズが 5×_small_table_threshold×blocksize以上の場合、Direct Path Readを選択するようです。
ちなみに、_small_table_thresholdはデフォルトではバッファキャッシュの2%になるような値にセットされるようです。
つまり、バッファキャッシュを大きくすればするほど、DirectPathReadは効きづらくなるということのようです。

ただ、セグメントサイズ > 5×_small_table_threshold×blocksizeの場合であっても、SmartScanにならない事象が発生してしまいました。
これについては、OracleACEの渡部さんが、TanelPoderさんのブログを翻訳してくださっています(素晴らしい!)。
http://www.csus4.net/d/japanese_translations_of_tanel_poder_s_posts_and_articles/optimizer-statistics-driven-direct-path-read-decision-for-full-table-scans-_direct_read_decision_statistics_driven-ja/

11.2.0.2から少し事情が違うようです。
もう少し検証が必要そうです。

2014年4月23日水曜日

[受験記] データベーススペシャリスト試験

この間の日曜日は情報処理技術者試験ということで、私はデータベーススペシャリスト試験を受けてきましたので、雑感というかレポートを書きます。

昨年の秋試験で一部試験免除の権利を取得したので、午前2からの試験でした。
[午前2]
例年通り過去問からの出題も多いが、やや用語を答えさせる問題が増えた感があり、少し焦りました。
[午後1]
傾向が大きく変わりました。
例年はデータベース基礎理論、テーブル設計、SQLの3問中2問を選択するものでしたが、
今年はデータベース基礎理論、データベース同時実行制御、テーブル設計+SQLの3問となり、必ずSQLの問題は解かなければならなくなりました。
同時実行制御の問題は苦手なので、問2は避けて問1、問3を選択。
データベース基礎理論はやや難しく45分かかってしまったが、テーブル設計+SQLは30分程度で回答できました。
[午後2]
例年は解答用紙が冊子であるが、今年は一枚紙なので焦ったが、傾向は例年通り。
問2のE-R図を選択。設問3の(2)bに10分程度解答に時間がかかったものの、消去法で解答を導き出した。ひとまずすべて書き込むことができました。
今年で5回目の受験なので、そろそろ合格したいですね。

2014年4月13日日曜日

データベースリプレイの基礎知識

先週から現場でRealApplicationTesting(RAT)を使用した性能チェックの準備を始めています。
データベースリプレイは、システム変更の影響を分析する機能です。
リプレイまでの流れは以下の通り
 ・本番システムでワークロードを取得する
 ・取得ファイルをテストシステムにコピーして事前処理する
 ・ワークロードをリプレイする
 ・分析する
ワークロードの取得については、10g以降でサポートされていますが、今回は9iからの変更ですので
サポート問い合わせをしたようです。

テストシステムへの事前処理は、PROCESS_CAPTUREプロシージャを使用します。
BEGIN
 DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE (capture_dir => 'old_system');
END;
/
ディレクトリのオブジェクトはあらかじめ作っておく必要があります。

準備ができたらワークロードをリプレイします。
まずはテストシステムにデータベースをリストアして、オプションの設定をします。
 synchronization     コミット順序の保持
 connect_time_scale    ワークロード開始から各セッションが接続するまでの待ち時間を縮小できます。
              デフォルトを100とし、待ち時間を半分にしたければ50、などとします。
 think_time_auto_correct セッションがSQL等を実行し終えてから次を実行するまでの思考時間を縮小できます。
              デフォルトを100とし、待ち時間を半分にしたければ50、などとします。
リプレイクライアントには、wrcの設定をします。
 wrc user/password@server mode=replay replaydir=XXXX
これであとは実行です。

今回は構築をほとんどやらなかったのですが、機会があればやってみたいですね。

2014年4月6日日曜日

Exadataの待機イベント

最近、仕事でExadataを触ることが多くなりました。
Exadataとは、Oracle社が出しているストレージ一体型でして、ストレージの部分をセルサーバと言います。
Exadataではsmart scanという、ストレージからの読み込みを先読みして速くする機能があります。
んなもので、いろいろとselectして見てみました。

FULL SCANをしてみて、AWR Reortを見てみると・・
cell multiblock physical read
が出てきました。初めて見る待機イベントです。Exadata以外で言うところのdb file scattered readで、ランダムアクセス。
では、INDEX SCANでは・・・?
cell single block physical read
となります。
smart scanになっているわけではないようです。

smart scanになるには、direct path readにならなければなりません(他にも条件はありますが)。
大きなテーブルを作成してFULL SCANしてみると、
cell smart table scan
smart scanになりました!
ちなみに、INDEX SCANのsmart scan版は cell smart index scanです。

ここらへんを来週ももう少し見ていきたいですね。