マイクロソフトの北川です。
TechEd 終了後なかなかブログの更新ができておりませんでした。
そして、更新できていない間にオラクル社のサイトでは「中堅企業向け オラクル都市伝説シーズン2: 其の二」が公開されたようです。相変わらず「前提なき比較」を継続しているようですが、
”本当にOracle Databaseを選択すると「ソースコードがスリム」になるのか？徹底検証予定。乞うご期待！”
とされていますので、予定が現実のものとなり、徹底検証の結果が開示されることを祈っております。
是非 Oracle Database の優れた機能を生かした「スリムなコード」というものを提示いただきたいですね。もちろん、どれほどスリムになるのかの比較対象付きで。
前回のブログ ポストでも触れましたが、機能を十分に生かすためには
「データベースは企業の重要な資産を格納している」
という認識をしていただき、運用体制を確立する必要があります。
その中で発生した不測の事態に対応するために、製品に備えられている機能を生かすことが大切なのではないかと思います。
今回の都市伝説で訴求されているのは「フラッシュバック・クエリ」と「フラッシュバック・ドロップ」の2種類です。
機能としては触れられているとおりですが、これらの機能が正しく動作するためには、データベースに対して日々どれくらいのトランザクションが実行され、どれくらいの UNDO を使用するかの目途を付けた上で、UNDO 領域の再利用をつかさどるパラメータの設定などを行う必要があります。でなければ、せっかくの「フラッシュバック」機能であっても、過去のデータを復元することはできません。
このような、データベースで発生した人的ミスによる障害対策まで、十分に注意を払えるデータベース技術者であれば、その運用対象がたとえ SQL Server であっても、同様に任意の時点でのデータ復旧を行う重要性というものを認識していただけると思いますし、マイクロソフトがそのために Data Protection Manager (DPM) というシステム管理製品を提供していることをご存知かと思います。
この DPM を利用すれば、複数の SQL Server のバージョン/エディションのバックアップやリカバリ ポリシーを簡単に統合管理することが可能となります。
もちろんデータの復旧も GUI で簡単に行うことができます。(エディションやバージョンを問わず共通のリカバリ ポリシーを利用できることは DPM のメリットですね。)
きちんとした運用設計ができていれば、いずれのデータベースであっても夜を徹した作業になることはありませんし、もちろんその逆も真です。
面白おかしく記事を作成するのも耳目を集めるためには大切だとは思いますが、きちんとした前提を提示しないまま、都合のよい比較を行うのは、どうでしょうか…。
データベースをメインで扱われている技術者の方や、システム提案を行われている技術者の方にはご理解いただけるかと思います。
また、フラッシュバック ドロップに関しての部分ですが、24時間、365日止められない オンライン ゲーム システムであるにもかかわらず、システム稼働中に本番システムが使用しているテーブルを削除してしまったとあります。
ここで K さんは
「今度こそは終わった・・。Oracle Databaseといえども、こんな致命的なミスは復旧できない…」
と自責の念に駆られているようですが、正にその通りです。
K さんがテーブルを削除した時点のデータは、当該テーブルに格納された状態で、フラッシュバック ドロップにより復旧することができるかと思いますが、当該テーブルを削除してしまった際に実行されていたトランザクションのデータは復旧することができません。
もちろんそのタイミングで、他のテーブルには更新が行われた可能性もあります。
フラッシュバック ドロップを K さんに教えてくれた M 部長は、そこまでは気が回らなかったようです。
結果、整合性のとれた状態に戻すためには、フラッシュバック データベースを使用して表を削除する前の状態を復元することになるのではないでしょうか。もちろん、そのためにはデータベースの停止、すなわち24時間、365日止められないシステムを停止することを意味しています。
製品がいかに優れた機能を持ったとしても、その機能を正しく訴求し、正しく利用方法を伝えていかなければ、その機能を生かすことはでいないという事を再度認識した次第です。
