SAP SQL Anywhere Tips – Ver.17 SQL Anywhere プロファイラ（前編）

今回はVer.17です。

今回はSAP SQL Anywhere Ver.17のパフォーマンス分析ツール「SQL Anywhereプロファイラ」の解説です。
本当は古いバージョンから書くほうが新しいバージョンでの進化がわかりやすく良いのですが、御了承いただければと思います。また、それぞれのバージョン用の解説が単独のブログ投稿として成り立つような内容にしておりますので説明が似ている点も御了承ください。

今回は長くなってしまいましたので前後編となります。こちらは前編です。後編はこちら。

SQL Anywhereプロファイラ

SQL Anywhereプロファイラはデータベースで発生するアクティビティを記録するツールです。このツールは開発及び診断ツールで、パフォーマンスの問題に関する情報を分析できるようになっています。CPUやディスクの使用率なども取得します。このツールはパフォーマンスだけではなく「デッドロックおよびロック待ちによる動作のブロックの検出」にも使用することが可能です。
その他にも

• トリガ、イベント、ネストされたストアドプロシージャコールなどのコストの高い隠れたプロシージャ
• プロシージャ本文内の、問題の可能性があるコード範囲分析

等の機能があります。
個人的にはこのツールは本番開始後の問題発生時だけではなく、開発の後半段階、製品テスト段階でも使用したほうが良いと考えます。手動でテストしているのであれば手間になるかもしれませんが通常のテストを行った他にこのツールを使用しながらテストすることでデータベース的な問題をより探る事ができます。

このツールの残念な点

先にこのツールの残念な点をお伝えしておきます。このツールは現在「SQL Centralの機能」として提供されています。そのためアプリケーション開発者がアプリケーション内でスイッチやボタンでプロファイリングを実行できるように仕掛けておくということが出来ません。（要求ロギングではそれが可能です。）そしてエンドユーザー様に代わりに行っていただくのは少々難しいです。やはりオンサイトでのサポート時や開発時に使用すると考えたほうが良いでしょう。

余談となりますが、SQL Anywhereエンジンが提供する機能とその他ツールが提供する機能は混同しないようにしてください。例えば
http://dcx.sap.com/index.html#sqla170/ja/html/817126526ce21014b4b6e257c19b45eb.html
INPUT文はSQL Anywhereエンジンが提供する機能ではなく見出しに「INPUT 文 [Interactive SQL]」とあるようにInteractive SQLツールが提供する機能です。つまりはODBCなどのアプリケーション内でINPUT文は使用することは出来ません。（やるとしたら….OSコマンドを直接実行する命令でInteractive SQLを起動してその中で実行させるという少々無理やりな形になります。）

プロファイリングモードの選択

SQL Anywhere「プロファイラ」の名前の通り、このツールは稼働中のデータベースのプロファイリング、つまりは情報収集を行います。モードは

• 包括的プロファイリングモード
• ターゲットプロファイリングモード

の2種類あります。
（正確にはこの他に「サポートモード」というモードもありますが、これはSAP製品サポートチームから要求された場合に使用するモードで通常使用しません。）
包括的はその名称通りほぼ全ての情報を包括的に取得することができる強力なモードです。が、その分パフォーマンスにも多くの影響を与えます。
ターゲットプロファイリングモードは取得するターゲットが絞られている場合にその部分だけをプロファイリングするのでパフォーマンスの低下は最小限に抑えられます。ターゲットとは「特定のSQL」や「XX秒以上かかるSQL」などの「条件」を意味します。

この2つのモード、どちらを使うかですが、現時点でこちらのブログの最初の図でどのフェーズにいるのかというのが重要になります。現在「全体的」（上側）のフェーズにいるのであれば包括的を使用することになります「個別」（下側）のフェーズにいるのであればターゲットの使用を考えることになります。但し、ターゲットでも多く該当してしまうような条件は意味がなくなりますし、短時間に特定の処理に対して包括的プロファイリングモードを仕掛けるという戦略もあるでしょう。私はパフォーマンスの問題のときは包括的プロファイリングモードを短期間で、「包括的プロファイリングモードON→問題の処理を行う→完了後プロファイリング停止」で行うことを推奨します。

このパフォーマンスに与える影響ですが、何％の影響を与えるのかとよく聞かれます。これはアプリケーションによって異なるので一概に言えないというのが答えです。CPUが強力、ディスクが高速であればあるほど影響は少なくなります。同時アクセス数もパフォーマンス低下度合いに関わってきます。これもONにした時にどのくらいの影響があるか開発（最終テスト時）に把握しておくのがベストです。

プロファイリングの開始

今回の投稿では包括的プロファイリングモードので方法を解説します。（ターゲットプロファイリングモードの解説もご希望でしたらコメントにてお寄せください。）

SQL AnywhereプロファイリングはSQL Centralの一機能として提供されています。まずはSQL Centralを起動します。なお、プロファイリングはSQL Anywhereサーバーマシン上で行ったほうが良いです。

SQL Central内でのSQL Anywhereプロファイリングの起動方法としては2種類あります。まずはこちらのほうが多く使用するのではと思われる方法から解説です。（もう一つは後編で解説します。）

SQL Centralでプロファイリングを行うデータベースに対して接続します。接続したら、左ペインのデータベースアイコンを右クリックします。

右クリックで表示されるメニューの上のほうに「SQL Anywhereプロファイラを開く」がありますのでクリックします。

（SQL Anywhereプロファイラのウインドウが起動し、そのままその上に）プロファイリングオプションのウインドウが起動します。

操作タブでは実行するプロファイリングの種類を指定します。今回は「包括的」を指定します。

「OK」をクリックしてください。

プロファイリングが開始されます。この状態でアプリケーションの問題の処理を実行してください。

処理が実行されると下記のように実行したSQLが時系列で表示されることを確認することが出来ます。

プロファイリングを実行中でもプロファイリングしたデータは見ることが出来ますし、プロファイリングしたデータを保存して後でゆっくり見るということも可能です。（保存したファイルを別のマシンのSQL Central上で見ることが出来ます）保存方法と保存したファイルを見る方法に関しては後編で解説します。

ただし、後述するインデックスの提案機能に関しては保存したファイルから実行させることは出来ません。プロファイリング実行中に行う必要があります。

さて、プロファイリングを始めるとSQL Anywhereプロファイラの画面が動き始めますがその画面の意味について説明したいと思います。まず、上記の画面「操作タブ」ですが、これはデータベースに対しての操作が表示されます。左側には実行したSQL文（これにはにはSQL Anywhere内部で実行されるSQLも含まれます。）、右側は実行時間の時系列スクロールする棒グラフです。長いものが出現したらそれは時間がかかっていると考えると良いでしょう。ただし、遅いものを見つけたからと言ってすぐさまそれの改善に移るのではなく、アプリ上で問題となっている処理かを照らし合わせるようにしてください。アプリ上で遅いという処理は単一のSQLが原因ではなく、処理で実行される一連の（複数の）SQLの合計時間ということがあります。

例を挙げますと、あるお客様で表を表示するのが異常に遅いという現象が発生しました。（当時はSQL Anywhereプロファイラがなかった時代ですが、）プロファイラで分析してもその表の表示が遅い原因となるSQLが見つからなかったのです。そこでアプリ内のコードを見てみると表の1マスを1つのSQL結果で埋めているというロジックでした。確か横12マスx縦10マス程度の表だったと記憶していますが、その表を表示するのに合計120回のSQL実行を行っていました。これは1回のSQLの実行が0.5秒で済んでも*120で60秒かかる計算となります。

このような場合、このグラフや他のタブで表示するデータでは問題として見つけられないでしょう。
なお、このお客様はSQLの実行回数を減らすようにアプリ側ロジックを改善し、劇的な性能改善を得ました。

話を戻し、「操作タブ」の左側で気になったSQLを右クリックするとサブメニューが開きます。

そこでプロパティをクリックすると

その文の実行時間の詳細を見ることが出来ます。ここで例えば文の実行に時間がかかっているならそのSQL文自体が高負荷のものであるので、SQL文を見直す、インデックスの追加やマテリアライズド・ビューを使用して負荷の軽減を図る、アプリのロジックを工夫する、フェッチに時間がかかるのであれば（結果行数の問題もありますが）アプリのフェッチ内で行っているロジックのチューニング、というふうに改善の検討を行うことになります。

「文のインデックスを提案」はこの文をインデックスコンサルタントにかけ、高速化する可能性のあるインデックスの提案を受けることが出来ます。

「文タブ」は「操作タブ」の内容を文単位でまとめたものとなります。

同一の文が何回実行されたか、平均実行時間と最大実行時間がわかります。

「ブロックタブ」はいわゆるロックによって実行がブロックされた状態が発生すると記録されます。デッドロックの情報もここに入ります。

ロックは複数の（ユーザーからの）操作が関わり、アプリケーションのロジックやSQL実行の際の排他レベルが原因となってきますので、ロックに関わっているSQL文及び接続情報から操作タブにもどり、そこからアプリケーション上での操作に照らし合わせるという形で分析するということになるかと思います。

「プロファイリングタブ」はストアドプロシジャやトリガの内部のプロファイリングを行います。

このスナップショットのように、実はプロシジャ内のコードレベルで実行時間を計測することが出来ます。この機能は開発時にも使用するとよいでしょう。

「分析タブ」はプロファイリングしたデータを総合的に纏めたデータが表示されます。

注目は「負荷のサマリ」タブです。

このタブはプロファイリングしたデータから問題がある点をまとめて表示します。例えばCPUやディスクIO、ワーカースレッドの不足があればそれを指摘、バックアップなどのシステムワークがユーザー操作を妨害しているようであればそれを指摘します。問題がわからない状態でもこれを使用することで発見が可能ですし、原因追求中も役に立つでしょう。

ブログシステムの関係で前篇はここまでとして、残りは後編で解説したいと思います。