ミッションクリティカル分野の「DBアップグレード」はどう進めるべき？ 富士通北陸システムズとオラクルのキーパーソンが語る勘所：確かな技術力とノウハウ、最新ソリューションの活用が成功の鍵（2/3 ページ）
ミッションクリティカル領域におけるオラクル製品の活用に関して豊富な実績と高い技術力を誇る富士通北陸システムズ。ORACLE MASTER Platinumを有する同社のエキスパートらが、Oracle Database製品の開発を主導するキーパーソンと“データベースアップグレード”を巡って議論を交わした。[プライベートクラウド/データベース統合][パブリッククラウド][Oracle Cloud][Oracle Database 12c]
大規模データベースの移行で有効な手法とは？
田所 先ほどご紹介したOracle GoldenGateの活用事例では、Oracle Data Guardを使った待機系システムがあったために、それを活用して最短のダウンタイムで移行できました。それでは、Oracle Data Guardを使っていないシステムでデータベースを移行する場合には、どのようなプロセスを採ることが多いのでしょうか？
スウォンガー 移行するデータベースの規模が大きくなればなるほど、ダウンタイムの短縮が大きな課題となるのは万国共通です。この課題の解決にはOracle Data Guardを使うのが最も便利なのですが、これを使えないケースもあるでしょう。例えば、HP-UXからSolarisにプラットフォームを移行したいといった場合は使えません。そのようなケースで使われるのが「Oracle Data Pump」です。これをOracle GoldenGateと組み合わせて使い、ダウンタイムを可能な限り短縮することを目指すのです。
問題はデータベースが数十TBもあるようなケースで、この場合はエクスポート時に正確性や一貫性をどう担保するかが課題となります。このようなケースではテーブルスペースの単位で1つずつ移行したり、完全移行の前に履歴だけを移しておいたりする方法を組み合わせて使うことが多いですね。なぜならば、データベースが巨大な場合、変更頻度の少ないデータの割合が高くなるからです。そこで、テーブル構造やデータ構造が部分的に動かせるものかを調べ、効率化が可能かどうかを検討するのです。
例えば以前、あるお客さまが220TBのデータベースを別のプラットフォームに移行するというプロジェクトに取り組まれました。通常ならデータベースをコピーするだけで作業に100時間はかかりますが、移行に伴うダウンタイムは16時間以内に抑えたいという要件がありました。そこで、この作業ではOracle GoldenGateは使わずにRMAN（Recovery Manager）からのインクリメンタルバックアップとテーブルスペースの移行を組み合わせて、可能な限りダウンタイムを短くするよう努めました。
このように特殊なケースもありますが、通常はOracle GoldenGateやOracle Data Guardを使って移行するのがベストな選択肢となるでしょう。
田所 日本では、まずデータベースのフレームをしっかりと作ってから何度もテストするというアプローチを採ることが多いですね。お話しされたケースのように、まずレベル0のバックアップからデータベースを作るという方法はあまり使われないのですが、データベースの規模によってはレベル0から作り、テストを繰り返しながらレベル1、レベル2と積み上げていく方法も有効かもしれません。
デートリッヒ Oracle Exadataなどにおける大規模なデータベース移行プロジェクトでは、半数ほどがこのようなアプローチを採っており、それを効率化するスクリプトもありますので、ぜひお試しください。
ただし、最後のインクリメンタルバックアップに関しては難しい部分もあります。その間、データベースをリードオンリーにしておく必要があるために、そこでどうしてもダウンタイムが生じるのです。この場合は、テスト時にフィジカルスタンバイを作っておき、それをスタンバイモードで動かすのが1つの解決策になります。これなら本番環境のトランザクションに悪影響を与えずにテストが行えます。
Oracle RATでアプリケーションも合わせたアップグレードの影響を検証
スウォンガー 日本のお客さまでは、Oracle Database 12cへの移行はどの程度進んでいますか？
池田 Oracle Database 12c R1に移行されたお客さまは全体の2割弱といったところです。多くのお客さまは12c R2を待たれているようです。
デートリッヒ やはりそうですか。日本のお客さまは特に“R2”を待つ傾向がありますからね（笑）
スウォンガー 新規システムにおける12cの採用は進んでいるようですが、既存システムのアップグレードはこれからといったところなのでしょう。
池田 当社では、お客さまがシステム環境を最新バージョンにアップグレードしていくに当たり、データベースに加えて既存アプリケーションをどう移行するかといったことも合わせてご提案する取り組みを進めています。その中で最近実施したのが、「Oracle Real Application Testing（RAT）」による検証作業です。
この検証では、Oracle Exadata V2（Oracle Database 11g R2）からOracle Exadata X5（Oracle Database 12c）への移行において、11g上で独立して動いているDWH用データベースとOLTP用データベースを12cのコンテナデータベース（CDB）上にプラガブルデータベース（PDB）として併存させるという状況を想定しました。この状況で、正常に問題なく動作するか、処理時間やサーバの負荷は変化するかといったことを検証したのです。
また、検証のシナリオとしては、「移行前と同じ処理を行う場合（単純なリプレイ）」「OLTPデータベースへの負荷が2倍に増えた場合（負荷を増やしたリプレイ）」「移行前（分離）と移行後（CDBに集約済み）の環境で両データベースにまったく同じ内容の負荷がかかった場合（統合リプレイ）」などを想定し、それぞれの挙動を測定しました。
検証の結果、データベースの移行だけでなく、アプリケーションの移行に関しても、互換性や性能の面で問題が起きないことが確認できました。
スウォンガー 12cへのアップグレードを促進していく上で、非常に重要なポイントを検証していただきましたね。というのも、お客さまがアップグレードを控える理由として、環境を変えることでこれまで正常に動いていたものがうまく動かなくなるのではないかという恐怖心や、テストにかかる時間の問題が大きいのです。
Oracle RATを使うことで、事前に本番環境と同じワークロードによって移行に伴うシステムの変化をシミュレートし、作業に要する時間やコストを大幅に削減できます。これを活用した移行支援サービスが提供されれば、お客さまも安心して最新のOracle Databaseへのアップグレードを進めていただけるでしょう。
提供：日本オラクル株式会社
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2017年3月28日
Copyright © ITmedia, Inc. All Rights Reserved.
