Oracle DBアップグレードの実践的手法〜パッチ適用、データ移行、ダウンタイム短縮の手法：データベース運用管理をクラウド化する方法（2）（5/5 ページ）

[PR／＠IT]

PR

アップグレード時のダウンタイムへの対処法

　ここからは、アップグレード時の懸念である、システムダウンタイムを最小化する方法を見ていこう。

パッチ適用／アップグレード時のダウンタイムを最小化する方法

　一般に、アップグレードやパッチ適用、データベースの移行には、いくつかのリスクが伴う。その一つとして挙げられるのが「サービス停止時間」だ。Oracle Databaseには、このリスクを最小化するための方法も複数用意されており、状況に応じて使い分けることができる。

　まず、PSR適用時のバイナリの更新については、11.2.0.2から利用可能な「Out-of-place Upgrade」がある。これは既存のORACLE_HOMEとは別の場所にバイナリファイルをインストールするという方法だ。Oracle Database 11g R1までは既存のORACLE_HOMEを上書き（In-Place Upgrade）していたが、この方法によって既存データベースの実行中に事前に新バージョンをインストールすることで、データベースの停止時間を短縮するわけである。

　個別パッチやPSU、バンドルパッチ適用時のダウンタイム最小化には、「Out-of-Place Patching」と「RAC Rolling Patch Apply」を使うことができる。このうち、Out-of-Place Patchingは、ORACLE_HOMEのクローンを作り、そこにパッチを適用するという方法であり、シングル構成や予備のハードウエアを用意できない場合でも使えるという利点があるが、シャットダウンからスタートアップして切り替えるまでの間にダウンタイムが発生する。

　一方、ダウンタイムなしでパッチを適用できるのがRAC Rolling Patch Applyである。Oracle RAC環境を利用していることが前提となるが、1ノードずつパッチを適用することにより、縮退運転だけで作業を行える。

Oracle Data Guardを利用したダウンタイム短縮方法

　「Oracle Data Guard」を使用する「Standby First Patch Apply」と「Transient Logical Standby」でも、パッチ適用時のダウンタイムを短縮できる。前者はPSUなど比較的、頻繁に行うパッチ適用に、後者はデータベース停止を伴うPSRの適用時に適した方法である。

　Standby First Patch Applyは、「Oracle Data Guardではパッチ適用時に限り、プライマリとスタンバイ環境のバージョンが一時的に（原則として1カ月以内）異なることを許容する」というルールにのっとっている。もう一つのルールとして「許容されるパッチ提供時期のズレは1年間」という制約があるが、ダウンタイムをOracle Data Guardのスイッチオーバーにかかる時間のみに抑えることができる。なお、Standby First Patch Applyのルールについては、Oracle Databaseのサポート情報を参照されたい。

　Transient Logical Standbyは、Oracle Data Guardのロジカルスタンバイによるローリングアップグレードの手法を、多くの企業で採用されているフィジカルスタンバイ環境で実現する方法だ。具体的には、フィジカルスタンバイを一時的にロジカルスタンバイに変換することで実現する。この方法では、何か新たな技術を利用しているわけではなく、Oracle Data Guardが提供するさまざまな機能を組み合わせて実現している。そのため、手順が複雑になるが、停止時間を短くできることと、何よりもデータベースのPSR適用に対応できることが最大のメリットである。

　なお、パッチの種類や適用方法によっては、ここで紹介した方法が使えない場合もある。各パッチのREADMEファイルに適用可能な方法が記載されているので、事前に確認した上で作業を計画していただきたい。

　パッチ適用時のシステム停止を避けたければ、Oracle RACを利用したローリング適用でほとんどのケースに対応できる。ただし、データベースのPSR適用に関しては、残念ながらRACローリングでは対応できない。システムの可用性要件として、パッチ適用時のシステム停止も避けられないのであれば、Oracle Data Guardを活用したTransient Logical Standbyも検討すべきだろう。

　ダウンタイム最小化には、Oracle GoldenGateも有効だ。同ツールによって既存データベースと新データベースを同期しておけば、後はアプリケーションの接続先を切り替えるだけで移行を完了できる。切り替え後は逆方向の同期処理を設定しておくことで、新データベースで問題が生じた際、いつでも旧データベースに切り戻せる点も大きなメリットである。

Oracle Database 12cのマルチテナント環境でのアップグレード方法

　Oracle Database 12cにアップグレードしてマルチテナント環境を構成すれば、その先のアップグレードは容易になる。

　例えば、Oracle Database 12.1.0.1のマルチテナントデータベースからアップグレードする場合は、まず新しいORACLE_HOMEに12.1.0.2をインストールしてコンテナデータベースを作成する。その後は既存のプラガブルデータベースを1つ1つアンプラグして、新しい環境にプラグインするだけだ。そして、最後にアップグレード用のスクリプトを流せば、データベースをオープンして利用できるようになる。この方法なら、プラガブルデータベースごとに柔軟にアップグレードのスケジュールを組むことができ、それぞれの停止時間も短く抑えられる。

　また、コンテナーデータベースごとに、その上で稼働するプラガブルデータベースも含めてアップグレードすることもできる。この方法では一括でのアップグレードとなるため、実施する作業はさらに少なくなる。

　以上、今回はOracle Database 12cによるプライベートクラウド構築に向けたデータベースのアップグレードについて、最新の手法と、それらを使う際の留意点を説明した。次回は、データベースアップグレードにおける大きなリスク要因となる「データベーステスト」にフォーカスを当て、それを大幅に効率化するツールとして「Oracle Real Application Testing」のSQL検証機能「SQL Performance Analyzer」を紹介する。