「準備があれば怖くない」――12cへのアップグレードについて取材した：Oracle DBユーザーに朗報

Oracle Database 12c（以降、12c）がリリースされた。既に評価版ダウンロードが開始されているが、＠IT読者はすでに触れているだろうか。もし、触れていないならば、ぜひ本稿を読んで下準備として欲しい。[プライベートクラウド/データベース統合][運用管理効率化][Engineered System][Oracle Enterprise Manager]

[PR／＠IT]

PR

12cへのアップグレードと新アーキテクチャへの移行はどのように行われるのか？

　2012年のOracle OpenWorldでラリー・エリソンが発表したOracle Database 12cのマルチテナント・アーキテクチャ。実態はどういうものなのか、アーキテクチャ上の変更はどれくらいのインパクトになるのか、それには何の利点があるのか、など、技術的に興味のある点が多かっただけに、12cのリリースを待ち望む声は多かった。半面、新しいアーキテクチャにはアップグレードへの不安もつきものだ。過去に苦労をした読者もいるかもしれない。

　では12cへのアップグレードはどうなのだろうか？

日本オラクル テクノロジー製品事業統括本部製造ソリューション部 グループリーダー 内野充氏

　「データベースエンジンという視点から見ると、11gと12cの間には大きな違いは生じません。アップグレードにおいて、アーキテクチャ変更に伴うアプリケーションの大規模改修といったリスクはほとんどないと言ってよいでしょう」

　そう説明するのは、リリースに際して取材に応じていただいた日本オラクル テクノロジー製品事業統括本部製造ソリューション部 グループリーダー 内野充氏だ。

　もちろん新機能や機能強化の提供や、それに伴う変更点は多岐にわたるが、それらがアップグレードの障壁になるようなことはないという。

アップグレードで変わった点は？

　既存ユーザーにとっての関心の1つは、アップグレード工数がどれくらいかかるのか、という点だ。

　「アップグレードのプロセスについては、従来と大きく変更になるものはありません。今までと同じプロセスでアップグレードが行えます」（内野氏）

　12cへのアップグレードが直接行えるのは、10.2.0.5、11.1.0.7、11.2.0.2以降の環境からになる。

　「マルチテナント・アーキテクチャを活用するためには、一度12cへアップグレードを行ってからマルチテナント・アーキテクチャへ移行していただく必要があります」（内野氏）

マルチテナント・アーキテクチャは必須になる？

　「アップグレードは簡単」そういわれても、アーキテクチャが新しいのでは、動作検証もそれなりの工数が必要なのでは？　そう考える向きもあるだろう。この12cのマルチテナント・アーキテクチャは、移行したら必ず利用しなければならないものなのだろうか？　複数データベースを持たない場合はどうなるのだろうか？

　「12cにアップグレードしたからといって、必ずしも複数のデータベースを統合しなければいけないわけではありません。12cのその他の機能を活用しつつ、必要があれば、マルチテナント・アーキテクチャを使ってデータベースを統合すればよいのです。また、12cに移行しておけば、その後の運用管理工数を減らすことができます」（内野氏）

Oracleがマルチテナントを実現する仕組みを知る

日本オラクル テクノロジー製品事業統括本部 ソリューション本部 基盤技術部 データベース技術グループ エンジニア 早坂真由美氏

　12cがもたらす最大の革新はプラガブル・データベース（PDB）と呼ばれる仮想的なデータベースの導入だ。先の記事で言及したとおり、データベース層においてマルチテナントを実現している。

　12cでは、マルチテナント・アーキテクチャを構成するための新しいタイプのデータベースを作れるようになっている。これは、その配下に複数の仮想的なデータベースを持つことができるデータベースで、「マルチテナント・コンテナ・データベース（CDB）」と呼ばれる。このCDBの上に、仮想的なデータベースであるPDBを複数まとめて持つ構成が「マルチテナント構成」だ。

12cでのパッチ適用・バックアップ・アップグレードはどうなる？

　「従来であれば、複数のデータベースを同じ環境に置いた場合、パッチ適用やアップグレードを行う時に全てのデータベースを停止してパッチを適用し、1つずつアップグレードをしなければなりませんでした。それを回避するにはOracle Homeを独立して用意しなければならなかったのですが、この手法の場合、今度は多数のOracle Homeを管理しなければならかったのです」（日本オラクル テクノロジー製品事業統括本部 基盤技術本部 DB技術グループ エンジニア 早坂真由美氏）

　では、12cのマルチテナント・アーキテクチャを使った場合はどうなのだろうか？

　「まず、CDBに対してパッチ適用やアップグレードを一度実施します。以降、対象のCDB上のPDBは、新しいバージョンでの動作をします。」（内野氏）

　これまではシステムごとに必要だったパッチ適用やアップグレードのプロセスが1度で済むことになる。

　一方で、一部のデータベースのみを旧バージョンのまま残しておきたいというケースにも対応が容易になる。

　「マルチテナント・アーキテクチャでは、PDB単位で別のCDBへ移動することができます。例えば、新しいバージョンで構成したCDBにPDB単位で移動することもできますし、既存のバージョンで構成したCDBで稼働させ続けることもできます。運用スケジュールの都合などですぐにアップグレードできない場合でも、PDB単位でシステムの対応を待ってからデータベースのアップグレードを随時進められるようになります」（早坂氏）

パッチ適用ポリシーごとにPDBを「付け替え」られる。複数バージョンのCDBを用意しておくことで、暫時的にバージョンアップを適用していく場合もより容易な操作で実現できるようになる

12cでのバックアップとリストアは？

　12cでは、CDBに対してコマンドを発行することで、1度の作業で複数のデータベースに対してバックアップを取得できるようになる。作業負荷を大幅に削減できるようになるのだ。

　一方で、リストアに関してはCDB、PDB、PDB内の表領域など柔軟な単位での実行を選択できる。これによって、システム停止時間の短縮、作業工数の削減が期待できる。

　データベース運用者の負荷はデータベースごとの運用ポリシー差異を考慮したバックアップ計画やパッチ適用計画をシステムごとに実施しなければならない点にあるマルチテナント・アーキテクチャは、複数のシステムが同居するデータベース・クラウド環境での運用負荷軽減を目指したものである。運用者であれば、その効果は想像が付くかもしれない。

　ところで、マルチテナント・アーキテクチャの利用は、12c以上のバージョンでなくてはならない。1つのCDB上に複数のPDBを構成するマルチテナント構成には、オプション製品が必要になるが、1つのCDBに1つのPDBを構成するだけなら、Standard Editionでも可能だ。

　Standard Editionでマルチテナント・アーキテクチャを実装することで、将来、12cで構成されたプライベートまたはパブリック・クラウドの環境にシステムを移動したい場合には容易に統合ができるようになるし、アップグレードの負荷削減での効果が得られるようになる。

アップグレードのための機能強化

　実は、12cではユーザーの声を反映したアップグレードに際しての改善がいくつか行われている。

アップグレード・チェックスクリプト

　例えば、アップグレードでは、既存データベース側の設定がそのまま引き継がれるかどうかを個別に確認する必要があった。これにはドキュメントから情報を得る必要があり、管理者のスキルや作業負荷具合に大きく依存する要素だった。

日本オラクル テクノロジー製品統括本部 通信・公益・メディアソリューション部 シニアセールスコンサルタント 阿部拓也氏

　「12cでは、互換性について事前に調査するためのツールがスクリプトとして提供されています。12cで提供されるこのスクリプトを、アップグレードする環境にコピーして走らせると、修正すべき項目が抽出できます。また、抽出結果に対して、全て推奨値で設定を適用するスクリプトも用意されています」（日本オラクル テクノロジー製品統括本部 通信・公益・メディアソリューション部 シニアセールスコンサルタント 阿部拓也氏）

アップグレード・チェックスクリプト「preupgrd.sql」　パラメータを設定するスクリプトが生成される

「preupgrd.sql」スクリプトの出力例　事前に変更すべきパラメータが出力される

　加えて、Oracleのユーザーコミュニティサイト「OTN」内にはアップグレードに関するドキュメント類も用意されている。日本語版のアップグレードマニュアルも間もなく公開予定だ。

　「アップグレードそのものを極力簡素化したことから、ドキュメントのページ数もぐんと減っているのです」（阿部氏）

アップグレードでは計画が重要！

　もちろん従来通り、適切な計画と準備なしには安全なアップグレードはあり得ない。

「システム停止によるビジネスインパクトに比例した、計画やテストの準備も重要です。労力・リスク・コストを減らすために、バージョンアップ前後のフェイズで適切なツールを利用し、万全の準備を整えてバージョンアップを進めることがアップグレード成功の原則です」（阿部氏）

　幸い12c側にはデータベースのアップグレード計画を進める上でのツールやドキュメントが多数用意されている。事前情報を十分に検討し、システム停止計画などを策定してアップグレードを推進してほしい。

この記事に関連するホワイトペーパー

”クラウド”のために開発されたデータベース「Oracle Database 12c」

「Oracle Database 12c」は、初めてクラウドを意識して設計・開発された。データベース層でマルチテナントを実装するために採用された「マルチテナント・アーキテクチャ」を始め、その新機能の全貌を紹介！

※ダウンロードにはTechTargetジャパンへの会員登録が必要です