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

データベースをプライベートクラウドの構築に最適なOracle Database 12cに移行する際には、アップグレード作業をいかに円滑に行うかが重要なポイントとなる。また、高い安定性を確保するためのパッチ適用も忘れてはならない。今回は、Oracle Databaseの最新アップグレード手法とパッチ適用のベストプラクティスを紹介する。[プライベートクラウド/データベース統合][Oracle Database 12c][Oracle Multitenant]

[PR／＠IT]

PR

　連載第一回では、プライベートクラウドを構築する上で重要な観点／アプローチと、Oracle Database 12cのマルチテナントアーキテクチの有効性について解説した。連載第二回の今回は既存データベースの移行プロセスに焦点を当てて解説する。

適切なパッチ適用でトラブルを未然に防ぐには

　Oracle Databaseの旧バージョンから12cを用いたプライベートクラウド環境に移行する際には、既存のデータベース環境を適宜アップグレードしていくことになる。

　このとき、旧バージョンで培った知識やノウハウが通用せず、当惑する方がおられるかもしれない。そこで、今回はOracle Databaseのアップグレードやパッチ適用に関する最新の考え方／手法／ツールをベストプラクティスとして紹介する。

　初めに、データベースの安定稼働に不可欠なパッチ適用について説明しておこう。

　プライベートクラウド環境では、個別の目的、個別のシステムごとに構築されてきたデータベース環境よりも高い安定性／可用性を求められることが多い。それぞれに異なるシステムの要件を包括的に満たさなければならないからだ。

　多くのソフトウエアでは、不具合の修正やセキュリティ脆弱性への対応、機能追加といったアップグレードの手段として、修正プログラムやパッチが提供されている。安定したシステムを運用していくためには、これらを使って適宜アップグレード作業を行い、ソフトウエアを最新の状態に保つことが極めて重要だ。それにより、不具合によってトラブルが生じたり、セキュリティ脆弱（ぜいじゃく）性を突いて情報が窃取されたりするリスクを最小限に抑えつつ、最新の機能を取り込めるからである。

　これらのことは、当然ながらOracle Databaseについても当てはまる。パッチ適用やアップグレードを運用に組み込むことで、最新機能をいち早く導入できるだけでなく、システムダウンや結果不正といった重大な問題の発生を防ぎ、システムの安定性を高められる。また、オラクルが提供する最新のセキュリティパッチを適用すれば、機密データに対する攻撃を防ぐことができる。

　ここに、パッチ適用の重要性を如実に示す調査結果がある。Oracle Databaseを搭載したEngineered Systemである「Oracle Exadata」を利用する企業が遭遇した不具合のうち約70％について、既に対策のためのパッチがリリース済みだったという。それらを適用していれば、多くの企業がトラブルを回避できたということだ。

　また、ある企業のOracle Database環境では、製品の不具合を原因とする障害の約9割が既知のものであり、未知の不具合は1割しかなかった。さらに、既知の不具合の半分については1年以上前に修正パッチがリリースされており、その他の不具合を解消するパッチも半年前には提供されていた。つまり、適切にパッチを適用していれば、製品の不具合に起因するほとんどのトラブルを回避できたということだ。

　これらの事実からも、Oracle Databaseを適切にアップグレードし、パッチを適用していくことの大切さがわかるだろう。

Oracle Databaseで提供される5種類のパッチを理解しよう

　Oracle Databaseに対して提供されるパッチには、大きく次の5種類がある。

1. Interim Patch（個別パッチ）：個別の不具合を修正するパッチ
2. Security Patch Update（SPU）：セキュリティ脆弱性への対策を目的とするパッチの集合体
3. Patch Set Update（PSU）：個別パッチを集約し、四半期ごとにリリースされるパッチ集合体
4. Patch Set Release（PSR）：1〜2年に一度の頻度でリリースされるパッチ集合体
5. Bundle Patch：Oracle ExadataやWindowsなど、特定のプラットフォームに対して提供されるパッチの集合体

SPU、PSUはオプティマイザの変更なし

　これらのうち、特に覚えておいていただきたいのは、「SPUとPSUの二つは、オプティマイザの変更を含まない」ということだ。つまり、Oracle Databaseの挙動は変わらないわけである。したがって、これらを適用する際には、工数の掛かるパフォーマンステストやアプリケーションテストは最小限で済み、基本的なテストとインストールテストを通常どおり行えばよい。

　また、Oracle Database 12cから、SPU単体での提供は行われなくなった。つまり、新たに発見された脆弱性への対策としてはPSUを適用することになる。なお、個別パッチを大量に適用しているような環境ではパッチの競合が発生することがあるが、個別パッチとの競合を回避する形式でPSUを提供することもできる。

　さらに、PSUと同様に個別パッチを集約したパッチセットとしてPSRがあるが、これには新機能が含まれる。例えば、Oracle Database 12cではOracle Database In-Memoryが導入されたが、これはPSR（12.1.0.2）として提供されている。こちらはオプティマイザの変更を伴うので、適用に際しては入念なテストを実施されたい。

　PSRは、公開されているロードマップに従って提供される。Release 1（メンテナンスリリース番号が1）に対して提供されるPSRは一つ、Release 2（メンテナンスリリース番号が2）に対しては三つのPSRが提供される。提供のタイミングもおおむね決まっており、ベースリリース（Release 1、2の初回リリース）、または直近のPSRから12カ月後を基本とし、Release 2の三つ目のPSRは直近のPSRから18〜24カ月後に提供される。多少、前後する場合もあるが、これらのタイミングでPSRがリリースされるとご理解いただきたい。

　もう一つご注意いただきたいのが、PSRは新規パッチの提供条件の一つであるということだ。すなわち、新規パッチの提供を受けるためには、「Oracle Premier Support期間中であるか、またはExtended Supportを契約」しており、その上で「最新のPSRを当てている、または猶予期間中である」ことが必要となる。猶予期間は、ベースリリースについては最初のPSRがリリースされてから1年間、それ以降のリリースは新しいPSRのリリースから2年間となっている。

「Release 1を避ける」は過去のこと。常に最新版を使うのが常識

　読者が今後、Oracle Databaseのアップグレードを計画していく際、まず意識していただきたいのは「サポート提供期間」であり、この中では「リリースをスキップしない」ことが重要になる。特に近年は製品のリリースサイクルが従来とは変わっており、平行してサポートされるバージョンが少なくなっているので注意が必要だ。

　例えば、一昔前までは、「Oracle Databaseは、Release 1（R1）よりも品質が安定しているRelease 2（R2）を渡り歩くのが安全」という考え方があった。Oracle Database 10g R2の次は11g R2、そして12c R2といった具合にR1をスキップしてアップグレードしていくわけだ。しかし、この考え方はもはや通用しない。昨今はリリースサイクルが長くなっており、次のR2がリリースされるタイミングではPremier Supportが終了している可能性がある。

　そもそも、R1よりもR2の方が品質が安定しているという考え方自体が誤りである。Oracle Databaseでは、常にメインラインのコードに対して新機能の追加や不具合の修正が行われている。つまり、常に最新のリリースが最も品質が高く、安定しているのだ。もし、安定した品質を求めるのならば、古いバージョンを使い続けてR2を待つのではなく、常にその時点の最新バージョンをお使いいただきたい。

　もう一つ、新規パッチの提供対象となる最新のPSRに保つことも重要だ。PSRは1〜2年に一度の頻度でリリースされているため、猶予期間を考慮しても2〜3年に一度は適用しておきたい。