現在の立場がDBAでSQLのパフォーマンスチェックと言う業務をやってるので、ここまでやってきたパフォーマンスの管理の方法を書いておく。
管理対象 | ツール |
---|---|
ファイル | Subversion |
スケジュール | Redmine |
SQLはプログラムから呼び出すため、条件式などが動的に変わる仕組みになっている。 そのため、そのパターンごとにチェックする必要がある。
例えば(下の例は架空のORマッパーもどきです)、
SELECT T1.I1, T2.I2, T1.I3 FROM TABLE1 T1 LEFT JOIN TABLE2 T2 ON T2.I1 = T1.I1 WHERE T1.I2 = ? AND <IF "I2<>NULL"> T2.I2 == ? AND </IF> T1.I3 = '0'
と言うSQLがあった場合、I2のパラメータがNULLかどうかでSQLの内容が変わります。
この場合、I2の条件ありバージョンとなしバージョンを作って、2つとも検証します。
こうした検証が必要なため、DBAとして、別途切り出して独自のSQLファイルを作ることになります。 これと、実際のプログラムで呼び出すSQLとの整合性をとるための管理が必要になりました。
方法
- 呼び出すSQLIDごとに親チケットを発行
- SQLIDの子にチェックするタスクを作る
- SQLをチケットの説明に記載する
この様なかんじで始めてみました
実施内容
チェック内容は、アクセスパスチェックと書式などのチェックの2つなので、1回のチェックに2つのチケットが作られることになります。 アクセスパスチェックは、レビューを通して評価NGとなると再チェックの必要があるため、アクセスパスチェックからさらに評価NGごとにチケットを作るようにしました(この方式は賛否ありそうです)
SQLの評価コメントは別にExcelファイルがあるため、SubversionのリポジトリをRedmineに連携して参照できるようにしました。 Subversionで管理する物は評価用のExcelファイル、DBA管理のSQLファイルに絞り込んでます(DBA用のSVNで正式なSVNは別管理)。
チケットのコメントは、評価内容でNGになった部分、SQLの修正部分とインデックスの追加はルール化して後で検索しやすいようにしました。
当初は、SQL変更管理表というExcelが存在していましたが、こちらへの記述をしなくてもRedmineからだけで良くなればそれも廃止できそうです(SQL一覧とインデックス一覧は納品物なので廃止できません)。
結果
- バージョン管理と連携できていればチケットのステータスだけで、特にステータスごとのフォルダがいらないので移動の煩わしさは軽減できた。
- インデックスをつけた経緯、SQLを変更した経緯が残るので、何でこんなインデックスがとか、何でこの順番になったのかと言ったことを過去のメールから漁らずに済んだ。
- SQLの変更も履歴があるため、変更履歴を別に書く必要がないということは認識してもらえそう(ここはもう一頑張り)。
ネットにつながらない、許可されたソフト意外使えないという制約の中、RedmineとSVN( IPA 独立行政法人 情報処理推進機構:定量的プロジェクト管理ツール(EPM-X) がありました。Gitはクライアントがなかったので断念)が使えたので、これまでの何でもExcelでの作業を少しでも軽減できるように持っていきたい。