マルチテナントアーキテクチャのバックアップ設計、考え方とNGパターン：ユーザー目線でチェック！ Oracle Database 12cの知りたいところ（3）（3/3 ページ）

[青野友香，株式会社コーソル]

印刷

通知 連載「％」の新着をメールで通知

隕九ｋPost

Shareシェア

はてなブックマーク

SharePocket Button

陥りやすいNGパターン

　バックアップ設計での大前提は、障害から復旧できるようにバックアップを取得するということです。マルチテナントアーキテクチャでは、バックアップ範囲を柔軟に選択できますが、有効なバックアップが存在しないという状況が発生しないように十分に留意する必要があります。これまでの説明と重複する部分もありますが、バックアップ設計を行うにあたり、陥りやすい設計のNGパターンを2つご紹介します。

NGパターン1：バックアップを取得していないコンテナがある

　バックアップを取得していないコンテナで障害が発生した場合、状況によっては、他のコンテナにも影響を与え、CDB内にある全コンテナが使用できないという状況に陥る可能性があります。そのため、CDB内にある全コンテナのバックアップを漏れなく、かつ定期的に取得するようにしてください。

　特に、CDB$ROOTが障害から復旧できない場合、インスタンスが起動できないため、致命的な問題になります。CDB$ROOTはオブジェクトの追加や削除ができませんが、管理情報は都度更新されています。CDB$ROOTについても、定期的にバックアップを取得するようにしてください。

NGパターン2：必要なアーカイブREDOログを削除してしまう

　もう1つ、陥りやすいNGパターンとしては、誤って必要なアーカイブREDOログを削除してしまうことが挙げられます。

　バックアップの取得間隔が各コンテナで異なる場合、バックアップ取得頻度の高いコンテナに合わせてアーカイブREDOログを削除してしまうと、取得頻度の低いコンテナで障害が発生した時に、必要とするアーカイブREDOログが存在せず、バックアップ取得時点にしか障害復旧できないという事態に陥る可能性があります（図5）。

　アーカイブREDOログの保持期間は、バックアップの取得頻度が低いコンテナに合わせるようにしてください。ただし、RMANの削除ポリシーに従えば、必要なアーカイブREDOログを削除することは原則的にないはずです。

図5 誤って必要なアーカイブREDOログを削除してまったNGパターン

許容できますか？ 障害発生時の影響範囲

　CDB内にある各コンテナ間では、インスタンスや一部の構成ファイルを共有しています。そのため、1つのコンテナで障害が発生すると、他のコンテナに影響を及ぼす可能性があります。障害発生状況により各コンテナに及ぼす影響はさまざまですが、特に注意が必要な障害状況とその影響範囲について、以下の表に記載します。

注意が必要な障害状況とその影響範囲

No	障害状況	影響範囲
1	制御ファイル、REDO、UNDO破損	インスタンス停止が必要なため、CDB内の全コンテナに影響を及ぼす
2	CDB$ROOTのSYSTEM表領域破損	インスタンス停止が必要なため、CDB内の全コンテナに影響を及ぼす
3	PDBのSYSTEM表領域破損	PDB起動時とMOUNT時で影響範囲が異なる
4	ユーザーデータの誤削除	障害が発生したコンテナのみに影響を及ぼす

その1　CDB内にあるコンテナ間で、インスタンスや制御ファイル、REDO、UNDOなど一部の構成ファイルを共有しています。そのため、これらのファイルが破損すると、CDB内にある全コンテナに影響を及ぼします。

その2　CDB$ROOTのSYSYTEM表領域の一部を他のコンテナでも共有しているため、CDB内にある全コンテナに影響を及ぼします。

その3　PDBのSYSTEM表領域が破損した場合の影響範囲は、PDB起動時とMOUNT時で異なります。PDBが起動している状態で障害が発生すると、障害復旧のためにCDB$ROOTの停止が必要となるため、CDB内にある全コンテナに影響を及ぼします。一方、MOUNT状態の場合は、CDB$ROOTの停止は必要ありませんので影響範囲は障害が発生したPDBのみとなります。多くの場合、PDBは起動状態であるかと思いますので、PDBのSYSTEM表領域についても全コンテナに影響を及ぼすと言っていいでしょう。

その4　マルチテナントアーキテクチャでは、CDB内の全コンテナ、特定のPDBのみ、どちらの範囲でも、ポイント・イン・タイム・リカバリ（PITR）を行うことができます。そのため、ユーザーデータの誤削除が特定のPDBのみで発生した場合は、他のコンテナに影響を及ぼすことなく障害復旧できます。

　上記の障害発生パターンとその影響範囲をご確認いただくと、多くの場合、CDB内の全コンテナに影響を及ぼし、そのコンテナにひも付くアプリケーションが一時的に使用不可となる可能性が高いことが分かるかと思います。

　コンテナ内に存在するPDBのデータは論理的に分離しており独立したデータベースといえます。しかし、障害発生時の影響範囲を考えた場合、統合前のシステム（インスタンスが各アプリケーションで分かれている環境）よりも、各コンテナにひも付くアプリケーションへの影響度は大きくなると考えます（図6）。そのため、基本的なことではありますが、データベースの統合を行う場合は、堅牢なインフラ（RAIDやASM）の上にデータベースを構築し、障害の発生確率をできるだけ小さくするように配慮することをお勧めします。

図6 障害時の影響範囲

今回のまとめ

　今回は、マルチテナントアーキテクチャを使用した場合のバックアップ設計を中心にご紹介しました。マルチテナントアーキテクチャを使用してデータベース統合を行うことにより、バックアップの運用コストを削減することができます。しかし、一方で、障害発生時の影響範囲が大きくなることを踏まえて、堅牢なインフラを用意することを検討する必要があるでしょう。

　第2回、第3回と2回にわたり、12cの新機能の中でも注目を集めている、マルチテナントアーキテクチャについてご紹介してきました。12cではマルチテナントアーキテクチャ以外にもセキュリティ、ASMなど注目すべき新機能が多くあります。今後も、気になる新機能をユーザー目線でご紹介していきますので、ご期待ください。