第9回 バージョン管理していますか？
Tweet
前回（2015年11月）の掲載から、ずいぶん時間がたってしまいました。申し訳ありません。昨年からOracle Cloud関連のプロジェクトに関わるようになって忙しく、コラムが後回しになってしまいました。今後は2カ月に1回のペースをなるべく守ります。
DBAの世界は遅れている？
今回のテーマは「クラウド」と言いたいところですが、温めていたネタの「データベースのバージョン管理」です。このバージョン管理とは、11.2や12.1といったデータベース・バージョンのことではありません。データベースの初期化パラメーターやスキーマ情報などの変更管理のことです。
今日のシステム開発プロジェクトでは、ソースコード管理にSubversionやGit、Team Foundation Serverなどのツールを使うことが一般化しています。しかしデータベースの変更管理に、ツールを導入しているプロジェクトは少数派ではないでしょうか。
おそらく多くのプロジェクトでは
- 初期化パラメーター：Excelシートで管理
- スキーマ情報：DDL生成機能を独自追加したExcelシートで管理
くらいが平均的なところでしょう。
システム開発の現場では、本番環境や検証環境、開発環境など同一システムが複数あるのが一般的です。さらに開発環境は、同一システムに数十個存在することもあります。このような複雑な環境下で、手動管理するのには限界があります。そのため、以下のようなトラブルが発生しています。
- 本番環境と検証環境の初期化パラメーターが乖離して、設計書と違うものになっている。そして履歴管理していないため、変更した理由がわからない
- 開発環境のスキーマ変更情報を検証環境に反映し忘れて、アプリケーションエラーになる
- ストアド・プロシージャとテーブル定義がミスマッチでエラーになる
- 環境によってパフォーマンスが違うので調べてみたら、インデックスの有無が違っていた
現代のアプリケーション開発現場・・・SubversionやGitでソースコード管理、AntやMaven、Gradleでビルド管理、Jenkinsや各種クラウドサービスでCI（継続的インテグレーション）・・・と言った状況と比べると、DBAの世界はずいぶん原始的です。
使っていてもデータベース・モデリング・ツール？
ツールを使っていたとしても、データベース・モデリング・ツール（スキーマ設計）くらいではないでしょうか。この分野は歴史が古く、80年代からいろいろなツールがありました。現在Oracleデータベースで使われているものとしては、SQL Developer Data ModelerやER/Studio、ERWin、SI Object Browser ER、ERMaster（Eclipseプラグイン）などがあります。そういえば筆者がOracle7時代にERWinを使っていたことを思い出しました。インストールメディアはフロッピーディスクです。
ただしデータベース設計者用のツールなので、データベース・スキーマの変更管理ツールとしてDBAまで普及しているかと言えば微妙です。またツールの機能にも依存しますが、きちんとバージョン管理まで活用できているのは少数派でしょう。
また、これらのツールで管理できるのはスキーマ情報だけです。データベースの初期化パラメーターやパッチ適用レベルなどの構成情報は管理できません。
どのようにバージョン管理すればよいか？
原始的な方法として思いつくのは、テキスト化できる操作やパラメーターをSubversionやGitで管理する方法です。少人数開発で小規模アプリケーションならば、なんとかなりそうです。しかし、規模が大きくなるほど大変になり、記録漏れも発生しそうです。
そのため実際には
- 設計書→開発環境→検証環境→本番環境
のような一方向の伝搬だけでなく、現状の環境をキャプチャーし、
- 「検証環境と本番環境」「設計書と開発環境」のギャップ分析
のようなリバースエンジニアリング&比較機能もあるのが理想的です。
そこで今回は次のソリューションを紹介します。
- Database Lifecycle Management Pack
- SQL Developer Data Modeler
- エディションベースの再定義（11gR2～）
- その他サードパーティーツール
実際のところ、この分野の議論をインターネットで検索しても意見はさまざまです。それぞれのソリューションで、コンセプトや機能に違いがあり、同一基準では判断できないからです。また何が適しているのかは、使用する組織の文化やプロジェクト次第でしょう。
しかし、どのようなソリューションがあるのか理解することは重要です。それぞれを紹介します。
Database Lifecycle Management Pack
Oracle Enterprise Managerのオプション製品であるDatabase Lifecycle Management Packです。Lifecycle Management Packには、プロビジョニングやパッチ適用、スキーマの変更管理、システムの構成管理など、たくさんの機能があります。その中でも今回紹介するのは「スキーマの変更管理」と「システムの構成管理」です。
「スキーマの変更管理」では、テーブルやインデックスの定義を管理できるだけではありません。おもな機能としては以下のものがあり、プロシージャやトリガーなども変更管理できます。
- ベースラインの保存：ある地点におけるデータベースと関連オブジェクトの保存
- スキーマ比較：異なる2つのスキーマを比較して差異を表示
- スキーマ同期化：ターゲットデータベースに変更を反映して同期化
- スキーマ変更計画：開発環境の変更をまとめ、複数のターゲットに伝搬
- データの比較：2つのデータベース間の行データ比較
「システムの構成管理」では、データベースの初期化パラメーターだけでなく以下のことを管理できます。これらのデータは保存できるだけでなく、履歴管理や比較も可能です。
- メモリーやCPUなどのハードウェア情報
- OSバージョン
- Oracleソフトウェア
- バージョンやパッチレベル
- データベースの初期化パラメーター
- 表領域情報
etc
こうして機能を見てみると、Oracleが作ったものだけあって、DBAの運用にとって便利な機能が充実しています。利用するにはDatabase Lifecycle Management Packのライセンスが必要です。しかしExadataユーザーのほとんどがライセンスを購入していることを考えると、使わないともったいない機能です。運用に乗せるまでには、それなりの学習・教育コストはかかりますが、数多くのデータベースがあるシステムでは、それだけのコストをかけても十分元が取れるはずです。詳細は、以下のマニュアルや動画をご覧ください。
- 『Oracle Enterprise Managerライフサイクル管理ガイド』の「構成情報の管理」
- 『Oracle Enterprise Managerライフサイクル管理ガイド』の「データベース・スキーマの変更管理」
- Oracle Enterprise Manager 12c:DB Lifecycle スキーマの変更管理（動画）
- Oracle Enterprise Manager 12c:DB Lifecycle 設定管理（動画）
SQL Developer Data Modeler
SQL Developer Data Modelerは、SQL Developerの姉妹ツールで、データベース・モデリングに特化したツールです。無償で使用でき、Database Lifecycle Management Pack とは異なり、Standard Editionのデータベースでも使用できます。
またDDL生成機能は当然として、リバースエンジニアリングやSubversionと連携したバージョン管理も可能です。次の例では、リバースエンジニアリング機能を使ってスキーマ情報をインポートし、設計との違いをチェックしています。
1. データベースに接続して、スキーマ情報をインポート。
2. 設定との差分を反映するSQLを生成。差分だけでなく、フルバージョンのSQL(CREATE TABLE文)も生成可能。
エディションベースの再定義
エディションベースの再定義は、これまで説明してきたバージョン管理とは毛色が違う機能です。しかし使いこなせば便利な機能なので紹介します。簡単に説明すると「PL/SQLオブジェクトやビューなどを同時に複数バージョン持つことで、アプリケーションのアップグレードにおける停止時間をゼロもしくは最少にする機能」です。
PL/SQLオブジェクトやビューなどを更新するときには、次のようにアプリケーションの停止が必要です。
- アプリケーション停止
- PL/SQLオブジェクトやビュー更新
- アプリケーション再開
エディションベースの再定義を利用すると、現行ユーザーには変更前のアプリケーション、新規接続ユーザーには新しいアプリケーションといった使い分けができるので、ほぼダウンタイムなしのアップグレードが可能です。ただし表や表データは「エディションベースの再定義」の対象外なので、ビューやクロス・エディション・トリガーなどの工夫は必要です。
詳細は「 Oracle Databaseアドバンスト・アプリケーション開発者ガイド 11gリリース2」や「Oracle Database開発者ガイド 12cリリース1」をご覧ください。
サードパーティーツール
サードパーティーツールは、たくさんあるので、ここでは簡単な紹介にとどめます。1はSQL Developerの拡張オプションでスキーマの変更管理ができます。2はスキーマの変更や同期ができるだけでなく、データの同期やコンプライアンスチェックなどの機能があります。ともに商用製品です。
3と4はAntやMaven、Gradleとの連携を想定したソフトウェアで、開発ワークフローの中に組み込んで使えます。DevOpsを推進するプロジェクトでは使われ始めています。また製品によっては有償版や有償サポートがあります。簡単に説明するのは難しいので、興味のあるかたは調べてください。
- 1. SVCO Extension for Oracle SQL Developer
http://www.sumsoftsolutions.com/svco_sqldev/tutorial.html - 2. エンバカデロ(IDERA) DB Change Manager
http://forms.embarcadero.com/embt-dbtools-jp - 3. Flyway
https://flywaydb.org/ - 4. Liquibase
http://www.liquibase.org/
おわりに
今回は細かいところまで踏み込めませんでしたが、「1日に何回もアプリケーションをデプロイする」最先端のアプリケーション開発現場と比べると、DBAの運用現場は遅れていると言わざるを得ません。そこまでのアプリケーション要件は無くても、設計書ベースの管理に問題があることは多くの人は認識していると思います。導入時に産みの苦しみはあると思いますが、DBAチームもアプリケーション開発チームに負けない効率化を果たしたいところです。そして本文では説明しませんでしたが、第一歩はDDL文の監査です。少なくとも、いつ誰が何を変更したかは、わかるようにしてください。
にわかワイン通養成講座
第9回 ワインの名前
ワインを飲み始めて戸惑うことの一つが「ワインの名前」です。辛口の白ワインとして有名な「シャブリ」というワインがあります。ところが専門店に行くと、さまざまなメーカーのシャブリが並んでいて、値段も千円くらいから、1万円を超えるものまであります。
初心者のころ、これには戸惑いました。われわれになじみ深いビールや清酒、焼酎で考えてみると、ビールならば「メーカー名」≒「お酒の名前」、清酒や焼酎ならば「メーカー名もしくはブランド名」≒「お酒の名前」が成立します。ワインには異なる規則がありそうです
そして調べてわかったことは、いろいろな「シャブリ」が存在する理由は、
EUにおけるワイン名は地域名を使うことが多い
からです。つまり「シャブリ」という名前は、パリの南東180kmにあるシャブリ地区で醸造され、シャブリの規定に則ったワインならば名乗れるのです。だから名前が同じワインでも、たくさんの種類が存在することになります。
では、同じ「シャブリ」でも値段が大きく違う理由は何でしょうか。もっとも大きな理由は、
生産者と畑の違い
です。ワイン生産者には、一生懸命造っている人もいれば、そうでないこともあります。そうなると当然、ワインの品質も異なります。
またシャブリ地区のブドウ畑は約5400haもあるので（東京都の面積の1/40、東京ドーム1150個）、場所によってワインの品質は異なります。EUはワインの歴史が長いこともあり、よいワインが出来る場所は歴史的に区別され、高値で取引されているのです。
たとえばシャブリの場合、畑は格付けされていて、下からプチ・シャブリ、シャブリ、シャブリ・プルミエ・クリュ（1級）、シャブリ・グラン・クリュ（特級）の順に高くなります。最上級のグラン・クリュは、シャブリ全体のたった2%にすぎません。
地域が狭いほど場所が限られるので、値段も高くなります。仮に東京でワインを作っていたと仮定して、地価で考えるとわかりやすいかもしれません。
日本 ＜ 東京都 ＜ 中央区 ＜ 銀座5丁目
銀座5丁目産のワインがあったら高そうですよね。フランスワインの2大生産地ブルゴーニュとボルドーでは少し仕組みは違うのですが、これをボルドーの5大シャトー筆頭であるシャトー・ラフィット・ロートシルトに当てはめると次のようになります。
日本：フランス
東京都：ボルドー
中央区：ポイヤック
銀座5丁目：シャトー・ラフィット・ロートシルト
つまりラベルに「ボルドー」とだけ書かれているワインよりは「ポイヤック」のほうが高く、さらに「シャトー・ラフィット・ロートシルト」のほうが高くなります。
このような名称の認証制度をフランスでは、AOC（アペラシオン・ドリジーヌ・コントロレ：原産地統制呼称）と言います。AOCでは生産方法やブドウ品種などを規定しているので、同じAOCであれば味わいも似た傾向になります。
そのためフランスワインを理解する第一歩はAOCを覚えることです。AOCは300以上もあって覚えるのが大変とか、いろいろ例外もあるとか、言い出すときりがないのですが、主要なAOCを覚えていると便利なことはたしかです。
これまでヨーロッパのワイン名の話をしましたが、アメリカや南半球の国々では事情が異なります。ニューワールドと呼ばれるこれらの国々では「メーカー名／ブランド名」＋「グレード」＋「ブドウ品種」という名前が一般的です。
なんだか、まじめな話になってしまいました。生産者や畑を熟知しているとステキなのですが、そのためには多大な時間とお金が必要です。簡単に見栄を張れる知識・・・、とりあえず、シャブリのトップ生産者であるフランソワ・ラヴノーを覚えることにしましょう。最低でも1万円、上級の畑では数万円もする高級品です。
「シャブリと言えばラヴノーだよね」と言えば一目置かれるかもしれません。ただし、うかつにレストランで頼むと、ものすごい請求金額が来るのでご注意を。
まとめ
- EU産ワインの多くは「地域名＝ワイン名」
- 指す地域が狭いほど値段が高い
- 同じAOCならば、味わいの傾向も似ている
Tweet