技術関連の覚書

案件でやったり自宅で試したことの覚書

SQL管理をRedmineでやってみた話

現在の立場が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との整合性をとるための管理が必要になりました。

方法

  1. 呼び出すSQLIDごとに親チケットを発行
  2. SQLIDの子にチェックするタスクを作る
  3. 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の変更も履歴があるため、変更履歴を別に書く必要がないということは認識してもらえそう(ここはもう一頑張り)。

ネットにつながらない、許可されたソフト意外使えないという制約の中、RedmineSVN( IPA 独立行政法人 情報処理推進機構:定量的プロジェクト管理ツール(EPM-X) がありました。Gitはクライアントがなかったので断念)が使えたので、これまでの何でもExcelでの作業を少しでも軽減できるように持っていきたい。