パフォーマンス問題の犯人探し？

情報システムに問題（特にパフォーマンス問題）が発生した場合、運用を担っているインフラ・チームが真っ先にやり玉に挙げられることが多いようです。

そんな時のアプリ・チームの主張は

• 自分たちはアプリケーションに一切手を加えていないので悪くない。悪いはずがない。
• インフラ・チームが何かやらかしたのではないか？（過去に痛い経験があればなおさら）
• 隠しパラメータみたいな秘密のスイッチがあるらしいから、それをうまく使って切り抜けてくれ！
• インフラには高い金をつぎ込んでいるのだから何とかしろ！

というようなものが多いのではないでしょうか？

しかも、大抵の場合アプリ・チームの方が人数が多いので、多勢に無勢いつの間にか問題はインフラ・チームのせいになってしまっている、というようなことはよくあります。

最近は、新卒でインフラ・チームに配属されるというケースも多くなっていますが、ベテラン開発者から運用者に転向しているような技術者は総じてスキルのレベルが高いので（好意的に解釈して）重要な問題の解決を期待されているということの裏返しなのかもしれません。

ただし、インフラ・チームの名誉のために補足しますが、私はパフォーマンス問題の8〜9割近くはSQLつまりアプリケーションの問題のような印象を持っています。（なぜアプリケーションに手を加えていないのに問題が発生するのかは改めて触れたいと思います。）

DBAは問題解決の要

DBAは多くの場合インフラ・チームの一員として数えられていますが、データベースはミドルウェアと言いながらOSから見れば一種のアプリケーションであるので、DBAがアプリ・チームとの仲介役としてうまく機能できれば問題解決に対して非常に強い組織になります。

専任のDBAを置いている組織は少ないかもしれません。サーバ管理者が兼任していたりしてDBAの職務が曖昧になっている場合、インフラ・チームとアプリ・チームの溝が深くなってしまうことはよくあります。

DBA自らがアプリケーションを理解する

問題が発生してからアクションを起こすのでは遅すぎます。DBAは常日頃からアプリケーションに対して関心を持つ必要があります。理想的にはアプリ・チームの責任としてDBAが理解できるドキュメントを整備するのがベストですが、現実的にはなかなか難しいことが多いかと思います。

従って、DBA側から能動的に情報を収集することが必要です。DBAから見た最も身近なアプリケーションはSQL文です。Oracleでは実行されているSQL文に関するさまざまな情報をV$SQL*ビュー（Oracle11gR2であれば30種）から得ることができます。

V$SQL_PLAN

それではV$SQL_PLANを使用してSQL文とテーブルの相関表を作ってみましょう。あるSQL文がどのテーブルを使用しているか、あるいはあるテーブルはどのようなSQL文によって使用されているかを一覧にしたものです。これはDB設計におけるCRUD表に近いものですが、実際に動いているSQL文の情報を使って作るというのがポイントです。

 実行計画のおさらい（SELECT）

以下の簡単な実行計画の例で考えてみます。

-----------------------------------------------------------------------------------
| Id  | Operation                     |  Name        | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |              |     3 |   189 |    10  (10)|
|   1 |  NESTED LOOPS                 |              |     3 |   189 |    10  (10)|
|   2 |   NESTED LOOPS                |              |     3 |   141 |     7  (15)|
|*  3 |    TABLE ACCESS FULL          | EMPLOYEES    |     3 |    60 |     4  (25)|
|   4 |    TABLE ACCESS BY INDEX ROWID| JOBS         |    19 |   513 |     2  (50)|
|*  5 |     INDEX UNIQUE SCAN         | JOB_ID_PK    |     1 |       |            |
|   6 |   TABLE ACCESS BY INDEX ROWID | DEPARTMENTS  |    27 |   432 |     2  (50)|
|*  7 |    INDEX UNIQUE SCAN          | DEPT_ID_PK   |     1 |       |            |
-----------------------------------------------------------------------------------

まず中程の「Name」列は、その実行計画でアクセス（SELECT）されるテーブルあるいはインデックスとなります。テーブルなのかインデックスなのか名前から判断することもできますが確実なのは左隣りの「Operation」列が

• TABLE ACCESS  で始まっているものが「テーブル」
• INDEX で始まっているものが「インデックス」

です。

V$SQL_PLANからSELECT対象のテーブル一覧を取得する

V$SQL_PLANから情報を取得するクエリーを考えてみます。

select distinct
 SQL_ID
,OBJECT_NAME
,3 CRUD_TYPE_ID
,OPTIONS
from
 V$SQL_PLAN
where OPERATION like 'TABLE%'
and   OBJECT_OWNER = 'xxxx'
order by
 OBJECT_NAME
,CRUD_TYPE_ID
,SQL_ID;

8行目のWHERE条件でテーブルアクセスのオペレーションのみを取り出しています。
9行目ではテーブルの所有者で絞り込みをしています。

4行目で何をしているのかというと、V$SQL_PLANにはない V$SQL.COMMAND_TYPE に相当する情報をここで付加しています。
SELECTであれば「3」になります。この理由は追って説明します。

以下は実行例です。

SQL> select distinct
  2   SQL_ID
  3  ,OBJECT_NAME
  4  ,3 CRUD_TYPE_ID
  5  ,OPTIONS
  6  from
  7   V$SQL_PLAN
  8  where OPERATION like 'TABLE%'
  9  and   OBJECT_OWNER = 'SCOTT'
 10  order by
 11   OBJECT_NAME
 12  ,CRUD_TYPE_ID
 13  ,SQL_ID;

SQL_ID        OBJECT_NAME  CRUD_TYPE_ID OPTIONS
------------- ------------ ------------ --------
0cc0hqvr7kpgx BONUS                   3 FULL
30hdyzpfrzgbf BONUS                   3 FULL
3154rqzb8xudy DEPT                    3 FULL
678kpdu03jc8x DEPT                    3 FULL
1srhq04p4x0zz EMP                     3 FULL
a2dk8bdn0ujx7 EMP                     3 FULL
25tuw6725a9h7 SALGRADE                3 FULL
30p00zk91247c SALGRADE                3 FULL

8行が選択されました。

（続く）