Oracle Database Standard Editionユーザーが次に選ぶべきDBはどれだ?!《後編》

座談会の《前編》はこちらから

ゲスト（順不同）

• 岸和田 隆氏（株式会社アシスト）
• 渡部 亮太氏（株式会社コーソル）
• 桑内 崇志氏（日本オラクル株式会社）

司会

• 谷川 耕一氏（DB Online チーフキュレーター）

ライセンス料以外のコストが移行のハードルを上げていく

●谷川 耕一氏（以下、谷川）：この記事の前編では、SE／SE1から他のデータベースに載せ替える場合、移行のためのイニシャルコストが高くなるというお話でしたが、具体的にどんな原因があるのでしょうか。

●渡部 亮太氏（以下、渡部）：やはり、テストですね。一般論になりますが、今はデータベース移行のための転換ツールも多数リリースされていますし、もともとデータベースとして複雑に作り込んだりしているとトラブルが起きやすいが、シンプルに使っていれば比較的安全といったことも経験則としておおよそ見えています。とはいえ、やはり移行にあたってはテストを実施しないわけにはいかないので、結果としてトータルの工数が膨大にならざるを得ません。

●谷川：同じくそのあたりについて、岸和田さんはどうお考えでしょう。

●岸和田 隆氏（以下、岸和田）：同感ですね。たとえばプロシージャの作り込みを、どのレベルまで行っているか。もし対応できない部分まで深く作りこんでいると、それを移行の際にどこで吸収するかという問題が出てきます。Oracleのプロシージャに含まれている部分を、他の言語で置き換える場合など、その部分のデザインが変わってくるので、すんなり移行できるかどうかは未知数です。要するにデータベース移行と一口で言っても、お客様のアプリケーションの作り方次第でその難易度が大きく左右されるわけです。

●谷川：移行対象のデータベースがアプリケーションの一部だったりすると、やはりテストは相当のボリュームになりますよね。また、たとえばRACを構築していたり、たとえSEでも特定の機能を使い込んでいたりすると、他社のデータベースには移行しにくいかもしれません。

●渡部：そういう点では、Materialized Viewが好きなお客様は、この機能をひんぱんに使う傾向があるので、なかなか他に行きにくいでしょうね。細かい話ですが。

●岸和田：Oracleに依存している機能を多用していればいるほど、当然ながら移行は難しくなってきます。もし移行を検討する場合は、まず自社での使い方にそうした特定の傾向がないか棚卸ししてみるのもよいと思います。

移行の見積もりではデータベース周辺にも十分に注意を払う

●谷川：移行のハードルを上げる要因として、ハイアベイラビリティ（HA）構成などはどうでしょうか。運用の仕方などが変わると思いますが。

●岸和田：HA構成そのものは何とかなりますが、デザインが変わると思います。移行先がPostgreSQLなどだと、Oracle Data Guardと同様な機構のレプリケーション構成を取り、その上にスイッチングするミドルウェアを入れて切り替えるような仕組みになります。そのため、RACのように残存ノードで処理を継続するという可用性を簡単に提供することはできません。アプリケーションのデータを複数のDBに分散配置するデザインなども検討する必要が生じてきます。ただ、移行はデータベースだけの問題なので、他のWeb層やアプリケーション層も含め、全体としてどう見せるかを考えれば十分に可能だと思います。

●渡部：他には、多数のユーザーによる多種多様なクライアントからのアクセスを受けているデータベースの移行は大変になりがちです。しかも言語がそれぞれ異なっている場合は、相当な苦労を覚悟することになります。

●谷川：それは想像するだけでも大変ですね。エンジニアの側も相当に幅広いスキルを持っていないと、完璧な対応は難しいでしょう。

●渡部：クライアントアプリケーションを含めたシステム全体で考えると、単にOracleのデータベースをバージョンアップするだけでも、なかなか大変な作業です。Oracleのバージョンを上げたいけれど、このクライアントがまだ対応していないとか。Oracle単体のバージョンを上げるだけだから楽勝だと思っていると、クライアントを見逃しているケースは意外に少なくありません。

●谷川：Oracleはいろいろなものに対応できる分、アプリケーションを構築する分には有利だけれど、それがバージョンアップの時には難易度を上げてしまうことがあるわけですね。