15 CDBの管理

マルチテナント・コンテナ・データベース(CDB)の管理には、コンテナへのアクセス、CDBの変更、DDL文の実行、およびオラクル社が提供するSQLスクリプトの実行などのタスクが含まれます。

ノート:

この章のタスクは、SQL*PlusまたはOracle SQL Developerを使用して実行できます。
  • CDB管理について
    一部の管理タスクはCDB全体に適用されますが、それ以外のタスクは特定のコンテナに適用されます。
  • CDB内のコンテナへのアクセス
    SQL*Plus CONNECTコマンドを使用してコンテナに接続できます。または、ALTER SESSION SET CONTAINER SQL文を使用してコンテナに切り替えることができます。
  • CDBの起動および停止
    CDBの起動時には、インスタンスを作成して、そのCDBの状態を確認します。現在実行中のOracle Databaseインスタンスの停止では、必要に応じて、CDBをクローズおよびディスマウントできます。
  • システム・レベルでのCDBの変更
    CDBレベルで初期化パラメータを設定できます。場合によっては、これらのパラメータをPDBレベルで上書きできます。
  • CDBルートへの接続時のコンテナの変更
    ALTER DATABASE文を使用して、CDB全体またはルートを変更できます。
  • 別のコンテナでのSQLの実行
    別のコンテナでSQLを実行するには、DMLのCONTAINERS句、またはDDLのCONTAINER句を使用します。
  • CDB内のコンテナの監視
    CDB、PDBおよびアプリケーション・コンテナに関するメタデータを表示するには、SQL*PlusまたはSQL Developerを使用します。

関連項目:

「マルチテナント環境のツール」

親トピック: マルチテナント環境の管理

CDB管理について

一部の管理タスクはCDB全体に適用されますが、それ以外のタスクは特定のコンテナに適用されます。

親トピック: CDBの管理

現在のコンテナについて

CDB内の各コンテナのデータ・ディクショナリは分かれており、現在のコンテナのデータ・ディクショナリは、名前解決と権限の承認に使用されます。

現在のコンテナは、CDBルート、アプリケーション・ルート、PDBまたはアプリケーションPDBにできます。各セッションには、任意の時点で現在のコンテナがそれぞれ1つのみ含まれます。ただし、セッションでは、あるコンテナから別のコンテナへ切替えができます。

各コンテナにはCDB内で一意のIDと名前があります。USERENVネームスペースのCON_IDおよびCON_NAMEパラメータを使用すると、SYS_CONTEXTファンクションで現在のコンテナのIDと名前を判断できます。たとえば、次の問合せは現在のコンテナ名を返します。 

SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

コンテナには様々な方法でアクセスできます。たとえば、SQL*PlusのCONNECTコマンドを使用し、ALTER SESSION SET CONTAINER文を使用すると、現在のセッションのコンテナを切り替えることができます。

CDBの現在のコンテナには、次のルールが適用されます。

  • 共通ユーザーの場合にのみ、現在のコンテナはCDB$ROOT (CDBルート)にできます。

  • 共通ユーザーおよびローカル・ユーザーの場合に、現在のコンテナは特定のPDBにできます。

  • アプリケーション・ルートで作成された共通ユーザーまたはアプリケーション共通ユーザーの場合、現在のコンテナにできるのはアプリケーション・ルートのみです。

  • 共通ユーザー、アプリケーション共通ユーザーおよびローカル・ユーザーの場合に、現在のコンテナは特定のアプリケーションPDBにできます。

  • SQL文にCONTAINER = ALLが含まれる場合、現在のコンテナはCDBルートまたはアプリケーション・ルートである必要があります。

    CONTAINER句は、CREATE USER、ALTER USER、CREATE ROLE、GRANT、REVOKEおよびALTER SYSTEM文などのいくつかのSQL文に含めることができます。CONTAINER = ALLに関する次のルールに注意してください。

    • SQL文にCONTAINER = ALLが含まれ、現在のコンテナがCDBルートの場合、SQL文は、すべてのPDB、アプリケーション・ルートおよびアプリケーションPDBを含む、CDB内のすべてのコンテナに影響します。

    • SQL文にCONTAINER = ALLが含まれ、現在のコンテナがアプリケーション・ルートの場合、SQL文は、アプリケーション・ルートおよびアプリケーション・ルートに属するすべてのアプリケーションPDBを含む、アプリケーション・コンテナ内のすべてのコンテナに影響します。SQL文は、CDBルート、PDB、または現在のアプリケーション・ルートに属さないアプリケーションPDBには影響しません。

    • 共通にSET CONTAINER権限が付与されている共通ユーザーまたはアプリケーション共通ユーザーのみ、CONTAINER = ALLを含むSQL文を実行できます。

関連項目:

親トピック: CDB管理について

CDBにおける管理タスクについて

共通ユーザーがCDBの管理タスクを実行します。

共通ユーザーは1つのIDを持ち、CDBルート、アプリケーション・ルート、PDBまたは権限を持つアプリケーションPDBにログインできます。CDBインスタンスの起動などの一部のタスクは、共通ユーザーのみが実行できます。

ノート:

マルチテナント・コンテナ・データベースが、Oracle Database 21c以降のリリースで唯一サポートされているアーキテクチャです。ドキュメントが改訂されている間は、従来の用語が残っている可能性があります。ほとんどの場合、「データベース」と「非CDB」は、コンテキストに応じてCDBまたはPDBを指しています。アップグレードなどの一部のコンテキストでは、「非CDB」が以前のリリースの非CDBを指しています。

次の表は、CDB管理タスクの一部についての説明と、関連ドキュメントへのポインタを示しています。

表15-1 CDBの管理タスク

タスク 説明 追加情報

CDBインスタンスの起動

CDBインスタンスを起動するには、現在のユーザーは、その現在のコンテナがCDBルートである共通ユーザーである必要があります。

CDBをオープンすると、CDBルートがオープンされますが他のコンテナはマウントされます。ALTER PLUGGABLE DATABASE文を使用して、1つ以上のコンテナのオープン・モードを変更します。

データベースの起動については、CDBの起動および停止を参照してください

「PDBのオープン・モードの変更」

「ALTER PLUGGABLE DATABASE文を使用したPDBの変更」

「現在のコンテナについて」

プロセスの管理

CDBには、CDBルートとすべてのコンテナによって共有された1セットのバックグラウンド・プロセスが存在します。

プロセスの管理の詳細は、『Oracle Database管理者ガイド』を参照してください

メモリーの管理

CDBには、単一のシステム・グローバル領域(SGA)および単一の集計プログラム・グローバル領域(PGA)があります。CDBで必要なメモリーは、CDBに含められるすべてのコンテナのメモリー要件の合計となります。

メモリーの管理の詳細は、『Oracle Database管理者ガイド』を参照してください

セキュリティの管理

CDBでは、共通ユーザー、アプリケーション共通ユーザーおよびローカル・ユーザーを作成および削除できます。また、これらのユーザーに対して権限の追加および取消しを行うこともできます。共通ユーザーおよびアプリケーション共通ユーザーのCONTAINER_DATA属性を管理することもできます。

さらに、次のロールを適切なユーザーに付与します。

  • CDB_DBAロールをCDB管理者に付与します。

  • アプリケーション・コンテナ管理者とPDB管理者にPDB_DBAロールを付与します。

『Oracle Databaseセキュリティ・ガイド』

エラーおよびアラートの監視

CDBには、CDB全体について1つのアラート・ログが存在します。アプリケーション・コンテナ、PDBまたはアプリケーションPDBの名前は、該当する場合にトレース・ファイルのレコードに含まれます。

エラーおよびアラートの監視の詳細は、『Oracle Database管理者ガイド』を参照してください

診断データの管理

CDBでは、Oracle Databaseの障害診断インフラストラクチャおよび自動診断リポジトリ(ADR)を使用できます。

診断データの管理の詳細は、『Oracle Database管理者ガイド』 を参照してください。

制御ファイルの管理

CDBには1つまたは複数の制御ファイルが存在します。

制御ファイルの管理の詳細は、『Oracle Database管理者ガイド』を参照してください

オンラインREDOログ・ファイルおよびアーカイブREDOログ・ファイルの管理

CDBには、1つまたは複数のオンラインREDOログ・ファイルおよび1セットまたは複数セットのアーカイブREDOログ・ファイルが存在します。

REDOログの管理の詳細は、『Oracle Database管理者ガイド』を参照してください

アーカイブREDOログ・ファイルの管理の詳細は、『Oracle Database管理者ガイド』を参照してください

表領域の管理

CDBルートおよび個々のコンテナの表領域および一時表領域を作成、変更および削除できます。また、CDBルートのデフォルトの表領域、デフォルトの表領域タイプおよびデフォルトの一時表領域を指定することもできます。CDBルートには、オラクル社が提供する表領域(SYSTEM表領域など)の独自のセットがあり、他のコンテナにはオラクル社が提供する表領域の独自のセットがあります。

表領域の管理の詳細は、『Oracle Database管理者ガイド』を参照してください

「CDBルートへの接続時のコンテナの変更について」

データファイルおよび一時ファイルの管理

CDBルートには独自のデータファイルがあり、他のコンテナには独自のデータファイルがあります。次の点に注意してください。

  • CREATE PLUGGABLE DATABASEまたはALTER PLUGGABLE DATABASE文でSTORAGE句を使用して、コンテナのデータファイルで使用される記憶域の量を制限できます。

  • CDBルートおよび個々のコンテナについてデフォルト一時表領域が存在します。

データファイルおよび一時ファイルの管理の詳細は、『Oracle Database管理者ガイド』を参照してください

「CDBルートへの接続時のコンテナの変更について」

「ストレージ制限」

「データベース・レベルでのPDBの変更」

UNDOの管理

CDBは、ローカルUNDOモードまたは共有UNDOモードで実行できます。ローカルUNDOモードは、CDB内のすべてのコンテナがローカルUNDOを使用することを意味します。共有UNDOモードは、単一インスタンスCDBに1つのアクティブなUNDO表領域があるか、Oracle RAC CDBの場合はインスタンスごとに1つのアクティブなUNDO表領域があることを意味します。

CDBでは、UNDO_MANAGEMENT初期化パラメータをAUTOに設定する必要があり、UNDOデータの管理にUNDO表領域が必要です。

「ALTER DATABASEを使用したCDBのUNDOモードの設定」

UNDOの管理の詳細は、『Oracle Database管理者ガイド』を参照してください

「現在のコンテナについて」

コンテナ間のデータの移動

CDB間でデータを移動する場合と同じ方法を使用して、CDB内のコンテナ間でデータを移動できます。たとえば、データをトランスポートしたり、データ・ポンプ・エクスポートおよびインポートを使用してデータを移動できます。

データのトランスポートの詳細は、『Oracle Database管理者ガイド』を参照してください

『Oracle Databaseユーティリティ』

Oracle Managed Filesの使用

Oracle Managed Filesを使用すると、CDBの管理を簡略化できます。

Oracle Managed Filesの使用の詳細は、『Oracle Database管理者ガイド』を参照してください

透過的データ暗号化の使用

透過的データ暗号化は、個々の表の列をデータファイルに格納する前に暗号化するか、表領域全体を暗号化する機能です。CDBには、コンテナごとに透過的データ暗号化の独自のマスター・キーが存在し、適用可能な場合、ADMINISTER KEY MANAGEMENT SQL文によって、コンテナごとにCDBレベルでキー管理を行うことができます。

Oracle Database Advanced Securityガイド

「現在のコンテナについて」

スタンバイ・データベースの使用

Oracle Data Guardを使用すると、CDBのフィジカル・スタンバイまたはロジカル・スタンバイを構成できます。Data Guardは、CDB内の個々のコンテナではなくCDB全体を操作します。

『Oracle Data Guard概要および管理』

Oracle Database Vaultの使用

Oracle Database Vault共通レルムは、共通オブジェクトのアプリケーション・ルートにスコープ指定できます。Database Vault共通コマンド・ルールは、CDBまたはアプリケーション・ルートにスコープ指定できます。ローカル・レルムとコマンド・ルールは、個々のPDBまたはアプリケーションPDBにローカルにスコープ指定できます。Oracle Database Vaultセキュリティ・オブジェクトがCDBルートまたはアプリケーション・ルートにある場合は、セキュリティ・オブジェクトの施行はOracle Database Vaultが有効になっているコンテナにのみ適用されます。

Oracle Database Vaultの管理者ガイド

データベースの削除

CDBを削除すると、CDB内のすべてのコンテナがデータとともに削除されます。これらのコンテナには、CDBルートおよびPDBシードと、すべてのアプリケーション・コンテナ、アプリケーション・シード、PDBおよびアプリケーションPDBが含まれます。

DROP PLUGGABLE DATABASE文を使用して、個々のアプリケーション・コンテナ、アプリケーション・シード、PDBおよびアプリケーションPDBを削除することもできます。

データベースの削除の詳細は、『Oracle Database管理者ガイド』を参照してください

「PDBの削除」

関連項目:

CDBのアーキテクチャの詳細は、Oracle Database概要を参照してください

親トピック: CDB管理について

CDBにおける管理性機能の使用について

CDB内のOracle Databaseの各管理機能について、データの場所とデータの可視性を理解することが重要です。

CDBルートに機能データが存在している場合、そのデータはPDBの切断時に含まれなくなります。ただし、そのデータがPDBに存在する場合、データはPDBの切断時と接続時のどちらでも存続します。

通常、CDBでは、共有ユーザーの現在のコンテナがCDBルートである場合、共通ユーザーはCDBルートおよび複数のPDBのデータを表示できます。共通ユーザーは、コンテナ・データ・オブジェクトを問い合せてこのデータを表示できます。表示できる特定のデータは、管理性機能によって異なります。現在のコンテナがPDBであるユーザーは、そのPDBのデータのみを表示できます。

次の表で、CDBにおける管理性機能の動作について説明します。

表15-2 CDBにおける管理性機能

管理性機能 データの場所 データの可視性 追加情報

アクティブ・セッション履歴(ASH)

ASHにより、アクティブ・データベース・セッションに関する情報が収集されます。この情報を使用して、パフォーマンス上の問題を分析および識別できます。

ほとんどのASHデータは、メモリーに格納されます。ごく一部のASHデータ・サンプルは、CDBルートに格納されます。

PDBが切断されていると、PDBに関連するASHデータは含まれません。

現在のコンテナがCDBルートである共通ユーザーは、CDBルートとPDBのASHデータを表示できます。

現在のコンテナがPDBであるユーザーは、そのPDBのASHデータのみを表示できます。

Oracle Databaseパフォーマンス・チューニング・スタート・ガイド

Oracle Databaseパフォーマンス・チューニング・ガイド

アラート

アラートとは、考えられる問題の通知です。

PDBに関連するしきい値設定は、PDBに格納されます。

しきい値に違反したときに転送されるアラートは、CDBルートのアラート・キューにエンキューされます。

PDBに関連するしきい値設定は、PDBが切断されていても含まれます。PDBが切断されていると、PDBに関連するアラートは含まれません。

現在のコンテナがCDBルートである共通ユーザーは、CDBルートとPDBのアラートを表示できます。

現在のコンテナがPDBであるユーザーは、そのPDBのアラートしきい値およびアラートのみを表示できます。

エラーおよびアラートの監視の詳細は、『Oracle Database管理者ガイド』を参照してください

自動データベース・メンテナンス・タスク

自動化データベース・メンテナンス・タスクとは、データベースのメンテナンス操作を実行するために、一定の間隔をおいて自動的に開始されるタスクです。自動タスクには、自動オプティマイザ統計収集、自動セグメント・アドバイザ・タスクおよび自動SQLチューニング・アドバイザ・タスクが含まれます。

ENABLE_AUTOMATIC_MAINTENANCE_PDB初期化パラメータは、CDB内のすべてのPDBまたはCDB内の個別のPDBでの自動メンテナンス・タスクの実行を有効または無効にできます。

AUTOTASK_MAX_ACTIVE_PDBS初期化パラメータは、自動メンテナンス・タスクを同時(メンテナンス・ウィンドウ中)にスケジュールできるPDBの数を制限します。

SQLチューニング・アドバイザは、自動メンテナンス・タスクでプログラムAUTO_SQL_TUNING_PROGを実行します。マルチテナント環境では、CDBは、タスク名がSYS_AUTO_SQL_TUNING_TASKである自動SQLチューニング・アドバイザのみを実行します。PDBは、タスク名がSYS_AUTO_SPM_EVOLVE_TASKであるSQL計画管理(SPM)展開アドバイザのみを実行します。

ユーザーは、メンテナンス期間をスケジュールして、現在のコンテナのみのメンテナンス・タスクを有効または無効にできます。現在のコンテナがCDBルートである場合、変更はCDBルートにのみ適用されます。現在のコンテナがPDBの場合、変更はPDBにのみ適用されます。

PDBに関連するデータは、自動オプティマイザ統計収集および自動セグメント・アドバイザのPDBに格納されます。このデータは、PDBが切断されていても含まれます。

自動SQLチューニング・アドバイザは、CDBルートでのみ実行されます。自動SQLチューニング・アドバイザによって収集されたデータの詳細は、この表のSQLチューニング・アドバイザの行を参照してください。

管理性機能(自動オプティマイザ統計収集、オプティマイザ統計アドバイザ、自動セグメント・アドバイザおよび自動SQLチューニング・アドバイザ)に関するデータの可視性の詳細は、この表の適切な行を参照してください。

データベースの自動メンテナンス・タスクの詳細は、『Oracle Database管理者ガイド』を参照してください

ENABLE_AUTOMATIC_MAINTENANCE_PDB初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

AUTOTASK_MAX_ACTIVE_PDBS初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

自動データベース診断モニター(ADDM)

ADDMでは、CDBまたはPDBのパフォーマンスを診断して、特定された問題の解決方法を判断できます。

ADDMは、PDBまたはCDBルートで実行されます。ADDMは、次のいずれかのソースを使用してデータを分析します。

  • PDB内で取得したAWRスナップショットを通じてPDB内に格納されているAWRデータ

  • PDBのAWR記憶域にインポートされたCDBルートまたはPDBのAWRデータ

  • ルートで取得したAWRスナップショットを通じてルート・コンテナに格納されているAWRデータ

分析の開始前に、ADDMはAWRデータのソース(PDBまたはCDBルート)を判断して、それぞれのデータ型に適用可能なルールを適用します。

ノート: PDBの自動ADDMは、そのPDBの自動スナップショットが有効になっている場合にのみ有効です。

現在のコンテナがCDBルートである共通ユーザーは、CDB全体の結果を確認できます。ADDM結果には、複数のPDBに関する情報が含まれる場合があります。PDBが切断されていると、PDBに関連するADDM結果は含まれません。現在のコンテナがPDBである場合、ADDM結果を表示することはできません。

現在のコンテナがPDBであるユーザーは、現在のPDBのみのADDM結果データを表示できます。この結果には、CDB全体に該当する診断結果(バッファ・キャッシュ・サイズに関連するI/Oの問題など)は含まれません。

Oracle Databaseパフォーマンス・チューニング・ガイド

自動オプティマイザ統計収集

自動オプティマイザ統計収集により、データベース内に統計がないか、古い統計のみがあるすべてのスキーマ・オブジェクトに関するオプティマイザ統計を収集します。このタスクで収集された統計は、SQLの実行パフォーマンスを改善するためにSQL問合せオプティマイザによって使用されます。

自動オプティマイザ統計収集タスクによりPDBのデータが収集されると、このデータはPDBに格納されます。このデータは、PDBが切断されていても含まれます。

現在のコンテナがCDBルートである共通ユーザーは、PDBのオプティマイザ統計データを表示できます。

現在のコンテナがPDBであるユーザーは、そのPDBのオプティマイザ統計データのみを表示できます。

Oracle Database SQLチューニング・ガイド

自動セグメント・アドバイザ

自動セグメント・アドバイザでは、再生可能な領域が存在しているセグメントを識別し、それらのセグメントの断片化を解消する方法について推奨事項を生成します。

自動セグメント・アドバイザによってPDBのデータが収集されると、このデータはPDBに格納されます。このデータは、PDBが切断されていても含まれます。

現在のコンテナがCDBルートである共通ユーザーは、PDBの自動セグメント・アドバイザ・データを表示できます。

現在のコンテナがPDBであるユーザーは、そのPDBの自動セグメント・アドバイザ・データのみを表示できます。

未使用領域の解放の詳細は、『Oracle Database管理者ガイド』を参照してください

自動ワークロード・リポジトリ(AWR)

AWRにより、問題の検出および自己チューニングを目的として、パフォーマンス統計を収集、処理およびメンテナンスします。このデータはデータベースに格納されます。収集されたデータは、レポートとビューに表示できます。

AWRレポートは、CDBルートまたはPDBで生成できます。CDBルートで生成されたAWRレポートはCDB全体に関係し、PDBが現在のコンテナであるときに生成されたAWRレポートはそのPDBにのみ関係します。

CDBルートで生成されたAWRデータは、そのCDBルートに格納されます。PDBで生成されたAWRデータは、PDBに格納されます。

PDBが切断されている場合、CDBルートに格納されているAWRデータは含められません。

PDBに格納されたAWRデータは、PDBが切断されていても含められます。

現在のコンテナがCDBルートである共通ユーザーは、CDBルートとPDBのAWRデータを表示できます。

現在のコンテナがPDBであるユーザーは、そのPDBのAWRデータのみを表示できます。

Oracle Databaseパフォーマンス・チューニング・ガイド

データベース・リプレイ

データベース・リプレイは、Oracle Real Application Testingの機能です。データベース・リプレイは、CDBまたはPDBのワークロードを取得して、そのワークロードをテスト・データベースで正確にリプレイします。

取得ファイルは常にオペレーティング・システム・ファイルに格納されます。取得とリプレイがCDBレベルであるかPDBレベルであるかは関係ありません。

CDBレベルのワークロードの場合、現在のコンテナがCDBルートである共通ユーザーは、データベースの取得およびリプレイの情報を表示できます。PDBレベルのワークロードの場合、SELECT_CATALOG_ROLE権限を持つローカルまたは共通PDB管理者は、この情報をDBA_WORKLOAD_CAPTURESおよびDBA_WORKLOAD_REPLAYSで確認できます。

『Oracle Databaseテスト・ガイド』

オプティマイザ統計アドバイザ

オプティマイザ統計アドバイザは、統計の収集方法を分析し、統計収集を微調整するために行うことのできる変更を提案します。

PDBに関連するデータは、オプティマイザ統計アドバイザのPDBに格納されます。このデータは、PDBが切断されていても含まれます。

現在のコンテナがCDBルートである共通ユーザーは、PDBのオプティマイザ統計アドバイザ・データを表示できます。

現在のコンテナがPDBであるユーザーは、そのPDBのオプティマイザ統計アドバイザ・データのみを表示できます。

Oracle Database SQLチューニング・ガイド

SQL管理ベース(SMB)

SMBにより、文のログ、計画履歴、SQL計画ベースラインおよびSQLプロファイルが、データ・ディクショナリに格納されます。

PDBに関連するSMBデータは、PDBに格納されます。PDBに関連するSMBデータは、PDBが切断されていても含められます。

現在のコンテナがCDBルートである共通ユーザーは、PDBのSMBデータを表示できます。

現在のコンテナがPDBであるユーザーは、そのPDBのSMBデータのみを表示できます。

Oracle Database SQLチューニング・ガイド

SQLパフォーマンス・アナライザ(SPA)

SPAでは、SQLチューニングおよびその他のシステム変更がSQLパフォーマンスに及ぼす影響を分析できます。通常、SPAはデータベース・リプレイで使用されます。

現在のコンテナがCDBルートである共通ユーザーは、任意のPDBのSPAを実行できます。この場合、SPAの結果データはCDBルートに格納され、PDBが切断されている場合は含められません。

現在のコンテナがPDBであるユーザーは、そのPDBについてSPAを実行できます。この場合、SPA結果データはPDBに格納され、PDBが切断されていても含められます。

現在のコンテナがCDBルートである共通ユーザーは、PDBのSPA結果データを表示できます。

現在のコンテナがPDBであるユーザーは、そのPDBのSPA結果データのみを表示できます。

『Oracle Databaseテスト・ガイド』

SQLチューニング・セット(STS)

STSは、1つ以上のSQL文とその実行統計および実行コンテキストを含むデータベース・オブジェクトで、ユーザーの優先順位ランキングを含む場合があります。

STSを使用すると、SQL文のグループをチューニングしたり、SPAを使用してパフォーマンスをテストできます。

STSはCDBルートまたは任意のPDBに格納できます。CDBルートに格納されている場合は、任意のPDBからSQL文をロードできます。

PDBが切断されていると、STSにPDBからのSQL文が含まれている場合でも、CDBルートに格納されたSTSは含められません。

PDBに格納されたSTSは、PDBが切断されていても含められます。

現在のコンテナがCDBルートである共通ユーザーは、CDBルートに格納されたSTSデータのみを表示できます。

現在のコンテナがPDBであるユーザーは、そのPDBのSTSデータのみを表示できます。

Oracle Database SQLチューニング・ガイド

SQLチューニング・アドバイザ

SQLチューニング・アドバイザでは、高負荷SQL文として識別されたSQL文が最適化されます。

自動SQLチューニング・アドバイザ・データは、CDBルートに格納されます。このデータには、PDBで実行され、アドバイザによって分析されたSQL文に関する結果が含まれていることがありますが、PDBが切断されている場合、これらの結果は含まれません。

現在のコンテナがCDBルートである共通ユーザーは、任意のPDBからのSQL文についてSQLチューニング・アドバイザを手動で実行できます。文をチューニングすると、その文を実行する任意のコンテナでチューニングされます。

現在のコンテナがPDBであるユーザーも、PDBからのSQL文についてSQLチューニング・アドバイザを手動で実行できます。SQLチューニング・アドバイザがPDBから手動で実行される場合、その結果は実行元のPDBに格納されます。この場合、文は現在のPDB用にのみチューニングされ、PDBが切断されているとPDBに関連する結果が含まれます。

SQLチューニング・アドバイザが自動的に実行される場合、その結果は、現在のコンテナがCDBルートである共通ユーザーにのみ表示されます。現在のコンテナがPDBである場合、これらの結果を表示することはできません。

SQLチューニング・アドバイザが、現在のコンテナがPDBであるユーザーによって手動で実行された場合、結果は現在のコンテナがそのPDBであるユーザーにのみ表示されます。

Oracle Databaseパフォーマンス・チューニング・スタート・ガイド

Oracle Database SQLチューニング・ガイド

SPAまたはSQLチューニング・アドバイザをPDBからのSQL文について実行するには、共通ユーザーに次の権限が必要です。

  • PDBにおける共通権限SET CONTAINERまたはローカル権限SET CONTAINER

  • PDBでSQL文を実行するために必要な権限

関連項目:

親トピック: CDB管理について

CDB内表領域の管理について

表領域とは、記憶域を使用するデータベース・オブジェクト(表や索引など)の論理記憶域コンテナです。

物理レベルでは、表領域のデータは、1つ以上のデータファイルまたは一時ファイルに格納されます。ALTER DATABASE文を使用すると、CDB内の表領域を管理できます。

CDBの表領域については、次のことを考慮する必要があります。

  • 表領域を関連付けることができるコンテナは厳密に1つです。

  • コンテナに表領域を作成する場合、表領域はそのコンテナに関連付けられます。

  • ローカルUNDOがCDBに対して無効になっている場合、CDBには、アクティブなUNDO表領域が1つのみ存在するか、またはOracle RAC CDBのインスタンスごとにアクティブなUNDO表領域が1つ存在します。ローカルUNDOがCDBに対して有効になっている場合、CDB内の各コンテナには独自のUNDO表領域があります。

  • PDBがオープンされるOracle Real Application Clusters (Oracle RAC)クラスタの各ノードに、ローカルUNDO表領域が必要となります。

  • CDBルート、各PDB、各アプリケーション・ルート、各アプリケーションPDBなど、CDB内のコンテナごとに1つのデフォルト一時表領域があります。

親トピック: CDB管理について

CDB内表領域の管理について

表領域を関連付けることができるコンテナは1つのみです。したがって、表領域はルートまたは1つのPDBと関連付けることができます。

CDB内のコンテナごとに独自のデフォルト表領域が存在する必要があり、デフォルト表領域をコンテナ間で共有することはできません。表領域を明示的に割り当てられていないユーザーがコンテナに接続された場合、コンテナのデフォルト表領域を使用します。

CDB内の一時表領域の管理について

CDB内の各コンテナには、独自のデフォルト一時表領域(または表領域グループ)があります。

追加の一時表領域を個々のコンテナに作成して、コンテナの特定のユーザーをこれらの一時表領域に割り当てることができます。PDBを切断すると、その一時表領域も切断されます。

ユーザーにコンテナ内の一時表領域が明示的に割り当てられていない場合、ユーザーの一時表領域はコンテナのデフォルト一時表領域です。

CDBにおけるデータベース・オブジェクトの管理について

CDBでは、異なるコンテナに異なるデータベース・オブジェクトを含めることができます。

Oracle Databaseには、表、索引、ディレクトリなどのデータベース・オブジェクトが格納されます。スキーマに所有されているデータベース・オブジェクトはスキーマ・オブジェクトと呼ばれ、スキーマによって所有されていないデータベース・オブジェクトは非スキーマ・オブジェクトと呼ばれます。CDBルートおよびPDBにはスキーマが含まれ、スキーマにはスキーマ・オブジェクトが含まれています。CDBルートおよびPDBに、ユーザー、ロール、表領域、ディレクトリ、エディションなどの非スキーマ・オブジェクトを含めることもできます。

CDBルートには、Oracleが提供するスキーマおよびデータベース・オブジェクトが含まれています。SYSやSYSTEMなどのオラクル社が提供する共通ユーザーは、これらのスキーマおよび共通データベース・オブジェクトを所有します。また、これらのユーザーは、CDBルートとPDBの両方にローカル・オブジェクトを所有することもできます。

CDBルートに共通ユーザー・アカウントを作成して、PDBおよびアプリケーション・コンテナを管理できます。ユーザーが作成した共通ユーザー・アカウントは、CDBルートにデータベース・オブジェクトを作成できます。CDBルートでは、ユーザーが作成した共通ユーザー・アカウントによって所有されるスキーマには、データベース・トリガーおよびそれらの定義で使用されるオブジェクトのみを含めることをお薦めします。ユーザーが作成した共通ユーザー・アカウントは、PDBの任意のタイプのローカル・オブジェクトを所有することもできます。

PDBにローカル・ユーザー・アカウントを作成できます。PDBのローカル・ユーザーは、PDBにスキーマ・オブジェクトおよび非スキーマ・オブジェクトを作成できます。CDBルートにローカル・ユーザー・アカウントを作成することはできません。

CDBでは、ユーザーの現在のコンテナのディクショナリのコンテキストで、名前が解決されます。

関連項目:

親トピック: CDB管理について

PDBのフラッシュ・バックについて

FLASHBACK PLUGGABLE DATABASE文を使用して、PDBを過去の時点またはシステム変更番号(SCN)に戻すことができます。

PDBのリストア・ポイントを作成して、CDBまたは他のPDBに影響を与えずに、PDBをリストア・ポイントにフラッシュバックできます。

ノート:

『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

親トピック: CDB管理について

セキュリティを強化するためのPDBユーザーの制限について

セキュリティを強化するためにPDBユーザーを制限する方法はいくつかあります。

PDBロックダウン・プロファイルは、PDB内のユーザーが使用可能な機能とオプションを制限します。PDB_OS_CREDENTIAL初期化パラメータでは、PDBに一意のオペレーティング・システム・ユーザーを指定して、オペレーティング・システム・アクセスを制限できます。また、PATH_PREFIXおよびCREATE_FILE_DEST句がPDBの作成時に指定された場合は、ファイル・システム・アクセスを制限します。

  • PDBロックダウン・プロファイル
    アイデンティティがPDB間で共有される場合は、過剰な権限が存在することがあります。ロックダウン・プロファイルを使用すると、この権限の昇格を防ぐことができます。
  • PDB_OS_CREDENTIAL初期化パラメータ
    データベースがextprocエージェントを使用して外部プロシージャにアクセスするときに、PDB_OS_CREDENTIAL初期化パラメータによって、PDBからオペレーティング・システムと対話するときに使用されるオペレーティング・システム・ユーザーのIDが決まります。

親トピック: CDB管理について

PDBロックダウン・プロファイル

アイデンティティがPDB間で共有される場合は、過剰な権限が存在することがあります。ロックダウン・プロファイルを使用すると、この権限の昇格を防ぐことができます。

IDは、次の状況で共有できます。

  • オペレーティング・システム・レベルでは、データベースがファイルやプロセスなどのオペレーティング・システム・リソースと対話するとき

  • ネットワーク・レベルでは、データベースが他のシステムと通信するとき

  • データベースの内部では、PDBが共通オブジェクトをアクセスまたは作成するか、データベース・リンクなどの機能を使用してコンテナ境界を越えて通信するとき

セキュリティを高めるために、CDB管理者はPDBロックダウン・プロファイルを使用して特定のPDBのユーザーを制限できます。PDBロックダウン・プロファイルでは、ALTER SYSTEM文などの指定したSQL文をユーザーが実行できないようにしたり、UTL_SMTPなど、ネットワークにアクセスできるパッケージへのアクセスを無効にしたりできます。PDBロックダウン・プロファイルでは、共通ユーザー、共通オブジェクトおよび管理ツール(Oracle XML DB、管理機能(例: カーソル共有)、データベース・オプション(例: Oracle Databaseアドバンスト・キューイング)など)へのアクセスも制限できます。PDBロックダウン・プロファイルでは、XDB_PROTOCOLS機能でPDBによるXDBプロトコル(FTP、HTTP、HTTPS)の使用を禁止できます。

CDBルートまたはアプリケーション・ルートにログインするときに、次のオプション句をサポートしているCREATE LOCKDOWN PROFILE文を発行して、ロックダウン・プロファイルを作成します。

  • FROM static_base_profileは、既存のプロファイルの値を使用して、新しいロックダウン・プロファイルを作成します。既存のプロファイルへの以降の変更は、新しいプロファイルには影響しません。

  • INCLUDING dynamic_base_profileは、既存のプロファイルの値を使用して新しいロックダウン・プロファイルを作成しますが、この新しいロックダウン・プロファイルは、基本プロファイルを構成するDISABLE STATEMENTルール、および基本プロファイルへの以降の変更を継承するという点が異なります。

文を発行するユーザーは、現在のコンテナでCREATE LOCKDOWN PROFILEシステム権限を持っている必要があります。制約を追加および削除するには、ALTER LOCKDOWN PROFILE文を使用します。ユーザーはCDBルートまたはアプリケーション・ルートでALTER文を発行する必要があり、現在のコンテナでALTER LOCKDOWN PROFILEシステム権限を持っている必要があります。

ロックダウン・プロファイルは、PDB_LOCKDOWN初期化パラメータを使用して指定します。このパラメータによって、PDBロックダウン・プロファイルが指定のPDBに適用されるかどうかが決定します。このパラメータは、次のレベルで設定できます。

  • PDB

    プロファイルは、設定されるPDBにのみ適用されます。

  • アプリケーション・コンテナ

    プロファイルは、アプリケーション・コンテナ内のすべてのアプリケーションPDBに適用されます。値を変更できるのは、アプリケーション共通のSYSDBA権限または共通のALTER SYSTEM権限を持つアプリケーション共通ユーザー、あるいは共通のSYSDBA権限または共通のALTER SYSTEM権限を持つCDB共通ユーザーのみです。

  • CDB

    プロファイルはすべてのPDBに適用されます。共通のSYSDBA権限または共通のALTER SYSTEM権限を持つ共通ユーザーは、特定のPDBに対するCDB全体の設定をオーバーライドできます。

PDBのPDB_LOCKDOWNパラメータが、このPDBのコンテナ(CDBまたはアプリケーション・コンテナ)とは異なるロックダウン・プロファイルの名前に設定されている場合は、一連のルールによって制限の間の相互作用が制御されます。

関連項目:

親トピック: セキュリティを強化するためのPDBユーザーの制限について

PDB_OS_CREDENTIAL初期化パラメータ

データベースがextprocエージェントで外部プロシージャにアクセスする際に、PDB_OS_CREDENTIAL初期化パラメータはPDBからオペレーティング・システムと対話するときに採用されるオペレーティング・システム・ユーザーのIDを決定します。

名前がPDB_OS_CREDENTIAL初期化パラメータの値として指定された資格証明で記述されるオペレーティング・システム・ユーザーを使用すると、オペレーティング・システムの対話が強力な権限を持たないユーザーとして実行されます。このようにして、あるPDBに属するデータを別のPDBに接続しているユーザーからアクセスできないように保護する機能が提供されます。資格証明は、DBMS_CREDENTIALパッケージ内のCREATE_CREDENTIALプロシージャを使用して作成されるオブジェクトです。

通常、Oracleオペレーティング・システム・ユーザーは高い権限を持つユーザーです。オペレーティング・システムの対話にこのアカウントを使用することはお薦めしません。また、異なるPDBからのオペレーティング・システムの対話に同じOSユーザーを使用すると、特定のPDBに属するデータが危険にさらされる可能性があります。

CDB内のコンテナへのアクセス

SQL*Plus CONNECTコマンドを使用してコンテナに接続できます。または、ALTER SESSION SET CONTAINER SQL文を使用してコンテナに切り替えることができます。

親トピック: CDBの管理

CDB内のコンテナへのアクセスについて

SQL*Plusを使用してCDB内のルートまたはPDBにアクセスできます。

関連項目:

親トピック: CDB内のコンテナへのアクセス

CDBのサービス

クライアントからは、データベース・サービスを使用してルートまたはPDBにアクセスします。

データベース・サービスには、オプションのPDBプロパティがあります。PDBが作成されると、PDBの新しいデフォルト・サービスが自動的に作成されます。サービスには、PDBと同じ名前が付いています。サービス名を使用すると、簡易接続構文またはtnsnames.oraファイル内のネット・サービス名を使用してPDBにアクセスできます。このサービスにアクセスするクライアントには、Oracle Net Serviceが正しく構成されている必要があります。

ユーザーがnull以外のPDBプロパティを含むサービスを使用して接続する場合、ユーザー名は指定したPDBのコンテキストで解決されます。ユーザーがサービスを指定しないか、またはnullのPDBプロパティを含むサービス名を使用して接続する場合、ユーザー名はルートのコンテキストで解決されます。サービスのPDBプロパティを表示するには、CDB_SERVICESデータ・ディクショナリ・ビューを問い合せるか、またはconfig serviceコマンドをSRVCTLユーティリティで実行します。

ノート:

同じコンピュータ・システム上の2つ以上のCDBで同じリスナーが使用され、これらのCDB内で2つ以上のPDBが同じサービス名を持つ場合、このサービス名を指定する接続は、そのサービス名のPDBの1つにランダムに接続します。不正に接続されることを回避するには、コンピュータ・システム上のPDBのすべてのサービス名が一意であることを確認するか、コンピュータ・システム上の各CDBに別のリスナーを構成します。

重要:

デフォルトのサービス名は使用せずに、かわりにユーザー定義サービスを作成してください。
CDBでのセッション制限

SESSIONS初期化パラメータの設定によって、PDBに接続されたセッションなどのCDBで使用できるセッションの合計数が制限されます。

CDBの制限に達すると、ユーザーはPDBに接続できなくなります。1つのPDBで過剰なセッションが使用されないようにするには、PDBでSESSIONS初期化パラメータを設定して、PDBで使用できるセッションの数を制限できます。

マルチテナント環境のユーザー名

各PDB内のユーザー名は、そのPDB内の他のユーザー名およびロールと比較して一意である必要があります。

以下の制限に注意してください。

  • 共通ユーザー名の場合、ユーザー作成の共通ユーザーの名前は共通のユーザー接頭辞で始める必要があります。デフォルトでは、CDB共通ユーザーの場合、この接頭辞はC##です。アプリケーション共通ユーザーの場合、この接頭辞は空の文字列です。これは、CDB共通ユーザー用に予約された接頭辞を使用しないかぎり、アプリケーション共通ユーザーに割り当てる名前には制限がないことを意味します。たとえば、CDB共通ユーザーにc##hr_admin、アプリケーション共通ユーザーにhr_adminという名前を付けることができます。

    CDB$ROOTのCOMMON_USER_PREFIXパラメータは、共通のユーザー接頭辞を定義します。この設定は変更できますが、十分に注意して行うようにしてください。

  • ローカル・ユーザー名の場合、名前をC## (またはc##).で始めることはできません。

  • ユーザーとロールに同じ名前を付けることはできません。

管理ユーザーのパスワード・ファイルに対するマルチテナント・オプションの影響

ローカル管理ユーザーと共通管理ユーザーのパスワード情報は、異なる場所に格納されます。

  • CDB共通管理ユーザーの場合: CDBルートで管理権限が付与されたCDB共通管理ユーザーのパスワード情報(パスワードのハッシュ)は、パスワード・ファイルに格納されます。

  • CDBルート外で管理権限が付与された、CDB内のすべてのユーザーの場合: これらのユーザーのパスワード・ハッシュ情報に関する情報を確認するには、$PWFILE_USERS動的ビューを問い合せます。

CDB内のコンテナへのアクセス

SQL*PlusのCONNECTまたはALTER SESSIONコマンドを発行して、CDB内のコンテナにアクセスします。

親トピック: CDB内のコンテナへのアクセス

SQL*Plus CONNECTコマンドを使用したコンテナへの接続

SQL*Plus CONNECTコマンドを使用してルートまたはPDBに接続できます。

親トピック: CDB内のコンテナへのアクセス

SQL*Plus CONNECTコマンドを使用したCDBルートへの接続

CDBルートには、いくつかの方法で接続できます。

具体的には、SQL*Plus CONNECTコマンドでルートに接続するために、次の手法を使用できます。

  • ローカル接続

  • オペレーティング・システム認証を使用したローカル接続

  • 簡易接続を使用したデータベース接続

  • サービス名を使用したデータベース接続

  • 外部認証を使用したリモート・データベース接続

ユーザーがCDBルートに接続するには、次の前提条件を満たしている必要があります。

  • ユーザーは共通ユーザーである必要があります。

  • ユーザーは、CDBルートでのCREATE SESSION権限を付与されている必要があります。

SQL*Plus CONNECTコマンドを使用してルートに接続するには:

  1. SQL*Plusを起動できるよう、環境を構成します。

  2. /NOLOG引数を使用してSQL*Plusを起動します。 

    sqlplus /nolog

  3. 次の例のように、SQL*PlusのCONNECTコマンドを発行し、ルートとして接続します。

例15-1 ローカル接続を使用したルートへの接続

この例では、ユーザーSYSTEMとしてローカルCDBのルートに接続します。SQL*Plusによって、ユーザーSYSTEMのパスワードの入力が求められます。 

connect system

例15-2 オペレーティング・システム認証を使用したrootへの接続

この例では、オペレーティング・システム認証を使用してSYSDBA管理権限でルートにローカルに接続します。 

connect / as sysdba

例15-3 ネット・サービス名を使用したルートへの接続

CDBのルートのネット・サービス名が含まれるようにクライアントが構成されていると想定します。たとえば、ネット・サービス名をtnsnames.oraファイルのエントリに含めることができます。

この例では、共通ユーザーc##dbaとして、ネット・サービス名mycdbによって指定されたデータベース・サービスに接続します。SQL*Plusによって、ユーザーc##dbaのパスワードの入力が求められます。 

connect c##dba@mycdb

関連項目:

データベースに対するコマンドおよびSQLの発行の詳細は、『Oracle Database管理者ガイド』を参照してください

親トピック: SQL*Plus CONNECTコマンドを使用したコンテナへの接続

SQL*Plus CONNECTコマンドを使用したPDBへの接続

SQL*Plus CONNECTコマンドを使用してPDBに接続するには、簡易接続またはネット・サービス名を使用できます。

PDBに接続するには、ユーザーは次のいずれかである必要があります。

  • CREATE SESSION権限が共通に付与されているか、PDBでローカルに付与されている共通ユーザー

  • CREATE SESSION権限を持つPDBで定義されたローカル・ユーザー

SYSDBA、SYSOPER、SYSBACKUPまたはSYSDG権限を持つユーザーのみが、マウント・モードのPDBに接続できます。PDBのオープン・モードを変更するには、「PDBのオープン・モードの変更」を参照してください。

SQL*Plus CONNECTコマンドを使用してPDBに接続するには:

  1. SQL*Plusを起動できるよう、環境を構成します。

  2. /NOLOG引数を使用してSQL*Plusを起動します。 

    sqlplus /nolog

  3. 簡易接続またはネット・サービス名を使用してSQL*Plus CONNECTコマンドを発行し、PDBに接続します。

例15-4 PDBへの接続

PDBごとに各PDB名と一致するネット・サービス名を持つように、クライアントが構成されていると想定します。たとえば、ネット・サービス名をtnsnames.oraファイルのエントリに含めることができます。

次のコマンドにより、salespdb PDB内のshローカル・ユーザーに接続します。 

CONNECT sh@salespdb

次のコマンドにより、salespdb PDB内のSYSTEM共通ユーザーに接続します。 

CONNECT system@salespdb

関連項目:

SQL*Plus CONNECTコマンドの発行の詳細は、『Oracle Database管理者ガイド』を参照してください

親トピック: SQL*Plus CONNECTコマンドを使用したコンテナへの接続

ALTER SESSION文を使用したコンテナへの切替え

共通ユーザーとしてコンテナに接続している場合、ALTER SESSION文を使用して、別のコンテナおよびアプリケーション・サービスに切り替えることができます。

次の文を使用して、別のコンテナおよびアプリケーション・サービスに切り替えることができます。

ALTER SESSION SET CONTAINER = container_name [SERVICE = service_name]

container_nameについては、次のいずれかを指定します。

  • CDBルートに切り替えるにはCDB$ROOT

  • PDBシードに切り替えるにはPDB$SEED

  • PDBに切り替えるにはPDB名

    現在のコンテナがルートである場合、DBA_PDBSビューを問い合せると、CDB内のPDBの名前を表示できます。

service_nameには、PDBで実行されているサービスを指定します。CDBルートを除くCDBのコンテナで実行されているサービスをリストするには、CDBルートが現在のコンテナであるときに次の問合せを発行します。 

COL NAME FORMAT A30
COL CON_NAME FORMAT A20

SELECT NAME,CON_NAME, CON_ID
  FROM V$ACTIVE_SERVICES
  WHERE UPPER(NAME) != CON_NAME
  AND CON_ID !=1
  ORDER BY CON_ID;

デフォルトでは、コンテナに切り替えると、セッションはコンテナのデフォルト・サービスを使用します。ただし、PDBのデフォルト・サービスでは、すべてのサービス属性および機能(サービス・メトリック、高速アプリケーション通知(FAN)、ロード・バランシング、リソース・マネージャ、トランザクション・ガード、アプリケーション・コンティニュイティなど)がサポートされているわけではありません。ベスト・プラクティスは、SERVICE = service_name (service_nameはサービスの名前)を指定することによって、コンテナにデフォルト以外のサービスを使用することです。

この新しい機能によって、接続プールでサービスを切り替えたり、プールの接続を使用した接続でPDBが必要な場合に切り替えることができます。Oracle Database 12cリリース2 (12.2.0.1)以降では、接続プールはUCP (Universal Connection Pool)を使用して複数のデータベース・サービスをサポートします。スタンドアロンで使用することもできます。

サービスを切り替える場合は、データベース・サービスの識別、優先順位、測定および高可用性が維持されたままで、アプリケーションをCDBに統合できます。デフォルト以外のサービスに切り替えると、次のような利点があります。

  • サービス属性および機能が維持されます。

  • これらのテナントに使用される接続が多すぎる過剰な接続プールがなくなります。

  • アプリケーションが、接続プールを過剰に消費することなく、ワークロード制御のためにデータベース・サービスをさらに使用できます。顧客は、データベース接続のサイズが大きくなりすぎることなく、サービスを使用したワークロードを識別して優先できます。

ALTER SESSION SET CONTAINER文を使用する場合は、次のことを考慮する必要があります。

  • 文が正常に完了した後、セッションの現行スキーマは、指定されたコンテナの共通ユーザーが所有するスキーマに設定されます。

  • 文が正常に完了した後、セキュリティ・コンテキストは、指定されたコンテナの共通ユーザーが所有するスキーマのセキュリティ・コンテキストにリセットされます。

  • 文が正常に完了した後、指定されたコンテナのログイン・トリガーは起動されません。

    トリガーが必要な場合は、ALTER SESSION SET CONTAINER文が実行される前または後に起動するように、BEFOREまたはAFTER SET CONTAINERトリガーをPDBで定義できます。

  • この文が正常に完了し、SERVICE句によってPDBにデフォルト以外のサービスが指定されている場合、セッションは設定されている属性(新しいサービスのメトリック、FAN、TAF、アプリケーション・コンティニュイティ、トランザクション・ガード、drain_timeoutおよびstop_optionを含む)を使用して新しいサービスを使用します。

  • パッケージの状態は複数のコンテナにわたって共有されません。

  • PDBをクローズするとき、PDBに切り替えられたセッションおよびPDBに直接接続されたセッションは同様に処理されます。

  • トランザクションを複数のコンテナにわたって実行することはできません。トランザクションを開始し、ALTER SESSION SET CONTAINERを使用して別のコンテナに切り替えると、そのトランザクションを開始したコンテナに再び切り替えるまで、DML、DDL、COMMITまたはROLLBACK文を発行できなくなります。

  • カーソルをオープンし、ALTER SESSION SET CONTAINERを使用して別のコンテナに切り替えると、カーソルをオープンしたコンテナに再び切り替えるまで、このカーソルからデータをフェッチできなくなります。

  • 接続プーリングおよび拡張CDB管理に、SERVICE句を指定したALTER SESSION SET CONTAINER文を使用できます。

    たとえば、マルチテナント・アプリケーションのPDBで、この文を接続プーリングに使用できます。マルチテナント・アプリケーションでは、サーバー上のソフトウェアの単一インスタンスを使用して、複数の顧客(テナント)に対処します。CDBでは、各テナントが固有のPDBを持つことができます。接続プーリング構成でALTER SESSION SET CONTAINER文を使用できます。

  • 複数のアプリケーションを処理する接続プールを使用している場合、アプリケーションは別のサービスのデータ・ソースを使用できます。SERVICE句を指定してALTER SESSION SET CONTAINER文を使用すると、接続プールで多数のアプリケーションに同じ接続を使用して、サービスを共有できます。

ALTER SESSION SET CONTAINER文を使用するには、次の前提条件を満たしている必要があります。

  • 現在のユーザーは共通ユーザーである必要があります。初期接続は、SQL*Plus CONNECTコマンドを使用して確立する必要があります。

  • Oracle Databaseで提供されていない共通ユーザーとして、セッションを変更してPDBに切り替える場合、現在のユーザーには、SET CONTAINER権限が共通に付与されているか、またはこの権限がPDBでローカルに付与されている必要があります。

ノート:

ALTER SESSION SET CONTAINER文を使用して現在のコンテナを切り替える場合、このような前提条件は強制されず、満たされていない場合、エラー・メッセージは返されません。

SERVICE句を指定してALTER SESSION SET CONTAINER文を発行する前に、次の前提条件を満たしている必要があります。

  • 切り替える先のサービスがアクティブである必要があります。実行されていないサービスに切り替えることはできません。

  • サービス間で切り替える場合は、切り替える元のサービスと切り替える先のサービスのサービス属性が一致している必要があります。たとえば、切り替える元と切り替える先のサービスの両方が、TAFを持っているか、アプリケーション・コンティニュイティを使用しているか、drain_timeout設定がある必要があります。

ALTER SESSION文を使用してコンテナに切り替えるには:

  1. SQL*Plusで、必要な権限を持つ共通ユーザーとしてコンテナに接続します。

  2. 切替え先のコンテナの現在のオープン・モードを確認します。

    ルートまたはPDBの現在のオープン・モードを確認するには、現在のコンテナがルートのときに、V$CONTAINERSビューでOPEN_MODE列を問い合せます。

    ルートのオープン・モードを変更する必要がある場合は、『Oracle Database管理者ガイド』のデータベースの可用性の変更に関する項の手順に従って、オープン・モードを変更します。

    PDBのオープン・モードを変更する必要がある場合は、「PDBのオープン・モードの変更」の手順に従って、オープン・モードを変更します。

    ルートのオープン・モードにより、PDBのオープン・モードが制限されます。たとえば、PDBをオープンするには、ルートがオープンしている必要があります。したがって、PDBのオープン・モードを変更する前に、ルートのオープン・モードを変更することが必要な場合があります。

  3. 特定のサービスに切り替える場合は、そのサービスが実行されていることを確認します。

    サービスのアクティブ・ステータスを確認するには、現在のコンテナがCDBルートであるときにV$ACTIVE_SERVICESビューを問い合せます。

    サービスが実行されていない場合は、SRVCTLユーティリティまたはDBMS_SERVICEパッケージを使用して、サービスを開始します。

  4. ALTER SESSION SET CONTAINER文を実行して、切替え先のコンテナを指定します。

    SERVICE句を含めて、特定のアプリケーション・サービスに切り替えます。

次の例では、ALTER SESSIONを使用して様々なコンテナに切り替えます。

例15-5 PDB salespdbへの切替えとsalesrepサービスの使用

ALTER SESSION SET CONTAINER = salespdb SERVICE = salesrep;

例15-6 PDB salespdbへの切替えとデフォルト・サービスの使用

ALTER SESSION SET CONTAINER = salespdb;

例15-7 CDBルートへの切替え

ALTER SESSION SET CONTAINER = CDB$ROOT;

例15-8 PDBシードへの切替え

ALTER SESSION SET CONTAINER = PDB$SEED;

例15-9 CDBルートのダミー・サービスを使用したサービスの切替え

コンテナおよびサービスを切り替える接続プールを設計するには、CDBルートにダミー・サービスを作成し、必要なすべての属性(たとえば、drain_timeout、TAFまたはアプリケーション・コンティニュイティ)をこのダミー・サービスに設定することが1つの方法です。サービス属性は、CDBルートおよびPDB間で一致している必要があります。この方法を使用するには、次のステップを実行します。

  1. 最初に接続プールを作成するとき、および新しい接続を作成するときに、ダミー・サービスに接続します。

  2. サービスが各PDBに追加されると、これらの実際のサービスに同じ属性が設定されます。

  3. アプリケーションが接続を必要とする場合は、次のいずれかのアクションを実行します。

    • ダミー・サービスへの新しい接続を作成し、そのPDBおよびサービスに切替えます。

    • プールの空き接続を使用して、PDBおよびサービスに切り替えます。

      PDB間で切り替える場合、CDBに戻る必要はありません。

PDB間で切り替える場合、CDBに戻る必要はありません。

関連項目:

データベース常駐接続プーリングの詳細は、Oracle Database管理者ガイドを参照してください

親トピック: CDB内のコンテナへのアクセス

CDBの起動および停止

CDBの起動時には、インスタンスを作成して、そのCDBの状態を確認します。現在実行中のOracle Databaseインスタンスの停止では、必要に応じて、CDBをクローズおよびディスマウントできます。

  • CDBの起動
    データベースの起動時には、そのデータベースのインスタンスを作成し、データベースの状態を確認します。
  • データベースの可用性の変更
    データベースの可用性を変更できます。可用性の変更は、メンテナンス上の理由やデータベースを読取り専用にするために行う場合があります。
  • CDBの停止
    SQL*PlusまたはOracle RestartでCDBを停止できます。
  • CDBの静止
    CDBの静止中は、DBAによるトランザクション、問合せ、フェッチまたはPL/SQL文のみ実行できます。
  • データベースの一時停止と再開
    ALTER SYSTEM SUSPEND文は、データファイル(ファイル・ヘッダーとファイル・データ)および制御ファイルへの入出力(I/O)をすべて停止します。一時停止状態によって、I/Oに干渉されずにデータベースのバックアップを作成できます。データベースを一時停止すると、実行中のすべてのI/O操作の完了が許可され、新しいデータベース・アクセスはキューに待機した状態になります。通常のデータベース操作を再開するには、ALTER SYSTEM RESUME文を使用します。
  • インスタンス中断の遅延
    INSTANCE_ABORT_DELAY_TIME初期化パラメータを使用して、エラーによりインスタンスが中断したときに、データベースの停止を遅延する時間を秒単位で指定します。

関連項目:

Oracle Real Application Clusters環境に固有の追加情報は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

親トピック: CDBの管理

CDBの起動

CDBの起動時には、そのデータベースのインスタンスを作成し、データベースの状態を確認します。

インスタンスは通常、CDBをマウントおよびオープンすることで起動します。この操作によって、有効なユーザーはCDBに接続して通常のデータ・アクセス操作を実行できます。

  • データベースの起動オプションについて
    Oracle Restartを使用していない場合は、SQL*Plus、Recovery ManagerまたはOracle Enterprise Manager Cloud Control (Cloud Control)を使用してデータベース・インスタンスを起動できます。Oracle Restartでデータベースを管理している場合は、SRVCTLを使用してデータベースを起動することをお薦めします。
  • 起動時における初期化パラメータの指定
    CDBは、データベース・インスタンスを起動するために、サーバー・パラメータ・ファイル(SPFILE)またはテキスト形式の初期化パラメータ・ファイル(PFILE)からインスタンス構成パラメータ(初期化パラメータ)を読み込む必要があります。
  • データベース・サービスの自動起動について
    データベースがOracle Restartで管理されている場合は、個々のデータベース・サービス(サービス)ごとに起動オプションを構成できます。
  • インスタンス起動の準備
    SQL*Plusを使用してCDBのインスタンスを起動する前に、いくつかの準備ステップを実行する必要があります。
  • インスタンスの起動
    SQL*PlusまたはOracle Restartを使用してインスタンスを起動できます。

親トピック: CDBの起動および停止

データベースの起動オプションについて

Oracle Restartを使用していない場合は、SQL*Plus、Recovery ManagerまたはOracle Enterprise Manager Cloud Control (Cloud Control)を使用してデータベース・インスタンスを起動できます。Oracle Restartでデータベースを管理している場合は、SRVCTLを使用してデータベースを起動することをお薦めします。

Oracle Restartの詳細は、Oracle Database管理者ガイドを参照してください

  • SQL*Plusを使用したデータベースの起動
    SQL*Plusセッションを開始し、管理者権限でOracle Databaseに接続すると、STARTUPコマンドを発行できます。このマニュアルでは、SQL*Plusを使用するこの方法について詳細に説明します。
  • Recovery Managerを使用したデータベースの起動
    Recovery Manager (RMAN)を使用して、STARTUPおよびSHUTDOWNコマンドを実行する方法もあります。この方法を選択するのは、RMAN環境でSQL*Plusを起動しない場合です。
  • Cloud Controlを使用したデータベースの起動
    Cloud Controlは、起動や停止も含めたデータベースの管理に使用できます。Cloud Controlは、GUIコンソール、エージェント、共有サービスおよびOracleのツール製品を組み合せて、Oracle製品の管理のために統合された包括的なシステム管理プラットフォームを提供します。Cloud Controlを使用すると、コマンドライン操作のかわりにGUIインタフェースを使用して、このマニュアルで説明されている機能を実行できます。
  • SRVCTLを使用したデータベースの起動
    Oracle Restartがインストールされてデータベース用に構成されている場合は、SRVCTLを使用してデータベースを起動することをお薦めします。

親トピック: CDBの起動

SQL*Plusを使用したデータベースの起動

SQL*Plusセッションを開始し、管理者権限でOracle Databaseに接続すると、STARTUPコマンドを発行できます。このマニュアルでは、SQL*Plusを使用するこの方法について詳細に説明します。

  • SQL*PlusのSTARTUPコマンドを実行します。

Recovery Managerを使用したデータベースの起動

Recovery Manager(RMAN)を使用して、STARTUPおよびSHUTDOWNコマンドを実行する方法もあります。この方法を選択するのは、RMAN環境でSQL*Plusを起動しない場合です。

  • RMANのSTARTUPコマンドを実行します。

関連項目:

RMAN STARTUPコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

親トピック: データベースの起動オプションについて

Cloud Controlを使用したデータベースの起動

Cloud Controlは、起動や停止も含めたデータベースの管理に使用できます。Cloud Controlは、GUIコンソール、エージェント、共有サービスおよびOracleのツール製品を組み合せて、Oracle製品の管理のために統合された包括的なシステム管理プラットフォームを提供します。Cloud Controlを使用すると、コマンドライン操作のかわりにGUIインタフェースを使用して、このマニュアルで説明されている機能を実行できます。

  • Cloud Controlでデータベース・インスタンスを起動します。

関連項目:

Cloud Controlのオンライン・ヘルプ

親トピック: データベースの起動オプションについて

SRVCTLを使用したデータベースの起動

Oracle Restartがインストールされてデータベース用に構成されている場合は、SRVCTLを使用してデータベースを起動することをお薦めします。

SRVCTL使用してデータベース・インスタンスを起動すると、次の項目が保証されます。

  • データベースが依存する任意のコンポーネント(Oracle Automatic Storage ManagementやOracle Netリスナーなど)が、適切な順序で最初に自動起動します。

  • データベースはOracle Restart構成の設定に従って起動します。そのような設定の例は、サーバー・パラメータ・ファイルの場所です。

  • データベースのOracle Restart構成に格納された環境変数は、インスタンス起動前に設定されます。

SRVCTLを使用してデータベース・インスタンスを起動するには:

  • srvctl start databaseコマンドを実行します。

srvctl start databaseについてさらに学習するには、Oracle Database管理者ガイドを参照してください

起動時における初期化パラメータの指定

CDBは、データベース・インスタンスを起動するために、サーバー・パラメータ・ファイル(SPFILE)またはテキスト形式の初期化パラメータ・ファイル(PFILE)からインスタンス構成パラメータ(初期化パラメータ)を読み込む必要があります。

CDBは、デフォルトの場所でこれらのファイルを検索します。これらのファイルにデフォルト以外の場所を指定することも可能で、その方法は、データベースの起動にSQL*Plusを使用するか(Oracle Restartを使用していない場合)、SRVCTLを使用するか(データベースをOracle Restartで管理している場合)によって異なります。

関連項目:

初期化パラメータ、初期化パラメータ・ファイルおよびサーバー・パラメータ・ファイルの詳細は、CDBの作成: 基本的なステップを参照してください

親トピック: CDBの起動

初期化パラメータ・ファイルおよび起動について

データベース・インスタンスを起動すると、データベースは、プラットフォーム固有のデフォルトの場所にあるSPFILEから初期化パラメータの読込みを試行します。SPFILEが見つからない場合は、テキスト形式の初期化パラメータ・ファイルを検索します。

プラットフォーム固有のデフォルトの場所では、Oracle Databaseは次の順序でファイル名を検査し、初期化パラメータ・ファイルを検索します。

  1. SRVCTLコマンドのsrvctl add databaseまたはsrvctl modify databaseの-spfileオプションで指定した場所

    現在の設定はsrvctl config databaseコマンドで確認できます。

  2. spfileORACLE_SID.ora

  3. spfile.ora

  4. initORACLE_SID.ora

最初の3つのファイルはSPFILEであり、4つ目はテキスト形式の初期化パラメータ・ファイルです。DBCAによってOracle Automatic Storage Managementディスク・グループにSPFILEが作成されている場合、データベースではそのディスク・グループ内のSPFILEが検索されます。

CREATE SPFILE文でAS COPYが指定されず、データベースがOracle Clusterwareのリソースとして定義されている場合、spfile_nameとFROM PFILE句の両方を指定すると、データベース・リソース内のSPFILEの名前と場所がこの文によって自動的に更新されます。CREATE SPFILE文でAS COPYが指定されている場合は、SPFILEがコピーされ、データベース・リソースは更新されません。

ノート:

spfile.oraファイルがこの検索パスに含まれているのは、Oracle Real Application Clusters環境では、すべてのインスタンスの初期化パラメータ設定が1つのサーバー・パラメータ・ファイルに格納されるためです。サーバー・パラメータ・ファイルにはインスタンス固有の格納場所はありません。

ユーザー(またはDatabase Configuration Assistant)が作成したサーバー・パラメータ・ファイルをテキスト形式の初期化パラメータ・ファイルで上書きする場合は、SQL*Plusを使用してSTARTUPコマンドのPFILE句を指定すると、その初期化パラメータ・ファイルを識別できます。 

STARTUP PFILE = /u01/oracle/dbs/init.ora

デフォルト以外のサーバー・パラメータ・ファイル

デフォルト以外のサーバー・パラメータ・ファイル(SPFILE)とは、デフォルトの場所以外の場所に存在するSPFILEです。通常は、インスタンスをデフォルト以外のSPFILEで起動する必要はありません。ただし、そうする必要がある場合は、SRVCTL (Oracle Restartを使用)およびSQL*Plusのいずれでも実行できます。これらについては、この項で後ほど説明します。

初期化ファイルおよびOracle Automatic Storage Management

Oracle Automatic Storage Management (Oracle ASM)を使用するデータベースの場合、通常はデフォルト以外のSPFILEがあります。Database Configuration Assistant(DBCA)を使用してOracle ASMを使用するようにデータベースを構成すると、DBCAによってOracle ASMディスク・グループ内にデータベース・インスタンスのSPFILEが作成され、ローカル・ファイル・システム内のデフォルトの場所に、そのSPFILEを指し示すテキスト形式の初期化パラメータ・ファイル(PFILE)が作成されます(次の項を参照)。

関連項目:

親トピック: 起動時における初期化パラメータの指定

デフォルト以外のサーバー・パラメータ・ファイルを使用したSQL*Plusでの起動

SQL*Plusでは、PFILE句を使用して、デフォルト以外のサーバー・パラメータ・ファイルでインスタンスを起動できます。

SQL*Plusでデフォルト以外のサーバー・パラメータ・ファイルを使用して起動するには:

  1. SPFILEパラメータのみを記述した1行のテキスト形式の初期化パラメータ・ファイルを作成します。パラメータの値には、デフォルト以外のサーバー・パラメータ・ファイルの場所を指定します。

    たとえば、次のパラメータのみを記述したテキスト形式の初期化パラメータ・ファイル/u01/oracle/dbs/spf_init.oraを作成します。 

    SPFILE = /u01/oracle/dbs/test_spfile.ora

    ノート:

    従来のテキスト形式の初期化パラメータ・ファイルで、サーバー・パラメータ・ファイルを設定するためにIFILE初期化パラメータを使用することはできません。この場合は、必ずSPFILE初期化パラメータを使用してください。

  2. この初期化パラメータ・ファイルを指定して、インスタンスを起動します。
    STARTUP PFILE = /u01/oracle/dbs/spf_init.ora

SPFILEはデータベース・ホスト・コンピュータに存在している必要があります。したがって、前述の方法は、クライアント・システムからSPFILEを使用するデータベースを起動する手段にもなります。また、クライアント・システムがクライアント側で初期化パラメータ・ファイルを維持する必要もなくなります。クライアント・システムがSPFILEパラメータが含まれている初期化パラメータ・ファイルを読み込むと、その値をサーバーに渡し、そこで指定されたSPFILEが読み込まれます。

デフォルト以外のサーバー・パラメータ・ファイルを使用したSRVCTLでの起動

データベースがOracle Restartで管理されている場合は、データベースのOracle Restart構成でSPFILEの場所オプションを設定または変更することにより、デフォルト以外のSPFILEの場所を指定できます。

SRVCTLでデフォルト以外のサーバー・パラメータ・ファイルを使用して起動するには:

  1. Oracle Database管理者ガイドの説明に従って、SRVCTLを実行する準備をします。
  2. 次のコマンドを入力します。
    srvctl modify database -db db_unique_name -spfile spfile_path

    db_unique_nameは、データベースのDB_UNIQUE_NAME初期化パラメータの設定と一致している必要があります。

  3. 次のコマンドを入力します。
    srvctl start database -db db_unique_name [options]

関連項目:

Oracle Restart用のSRVCTLコマンド・リファレンスについては、Oracle Database管理者ガイドを参照してください

親トピック: 起動時における初期化パラメータの指定

データベース・サービスの自動起動について

データベースがOracle Restartで管理されている場合は、個々のデータベース・サービス(サービス)ごとに起動オプションを構成できます。

サービスの管理ポリシーをAUTOMATIC(デフォルト)に設定した場合は、SRVCTLを使用してデータベースを起動するとサービスが自動的に起動します。管理ポリシーをMANUALに設定した場合、サービスは自動起動されず、SRVCTLを使用して手動で起動する必要があります。MANUALを設定しても、サービスは実行中にOracle Restartで監視され、障害が発生すると再起動されます。

データベースがOracle Restartで管理されているOracle Data Guard(Data Guard)環境では、Oracle Restart構成でサービスにData Guardロールを割り当てることにより、サービスの自動起動をさらに制御できます。サービスの管理ポリシーがAUTOMATICであり、割り当てられているいずれかのロールがデータベースの現行のロールに一致する場合にのみ、手動でデータベースを起動するとサービスが自動的に起動されます。

ノート:

Oracle Restartを使用する場合は、SRVCTLを使用してデータベース・サービスを作成することをお薦めします。

関連項目:

サービスに対してData Guardロールの管理ポリシーを設定する構文は、Oracle Database管理者ガイドのsrvctl add serviceおよびsrvctl modify serviceを参照してください

親トピック: CDBの起動

インスタンス起動の準備

SQL*Plusを使用してCDBのインスタンスを起動する前に、いくつかの準備ステップを実行する必要があります。

ノート:

次の手順は、Oracle Restartを使用していないインストール用です。

インスタンスを起動準備するには:

  1. データベースが依存するOracleコンポーネントが起動されたことを確認します。

    たとえば、CDBのデータがOracle Automatic Storage Management (Oracle ASM)のディスク・グループに格納される場合は、Oracle ASMインスタンスが実行中であること、および必要なディスク・グループがマウントされていることを確認します。また、CDBが起動する前にOracle Netリスナーを起動することをお薦めします。

  2. オペレーティング・システム認証を使用する場合は、OSDBAグループのメンバーとしてデータベース・ホスト・コンピュータにログインします。
  3. 環境変数が目的のOracleインスタンスに接続するように設定されていることを確認します。
  4. SQL*Plusを起動し、CDBルートに接続します。
    SQLPLUS /NOLOG
  5. SYSOPER、SYSDBA、SYSBACKUPまたはSYSDGとしてCDBルートに接続します。たとえば:
    CONNECT username AS SYSDBA

—or—

CONNECT / AS SYSDBA

CDBルートに接続され、データベース・インスタンスを起動する準備が完了しました。

関連項目:

親トピック: CDBの起動

インスタンスの起動

SQL*PlusまたはOracle Restartを使用してインスタンスを起動できます。

親トピック: CDBの起動

インスタンスの起動について

Oracle Restartを使用していない場合は、SQL*PlusのSTARTUPコマンドを使用してOracle Databaseインスタンスを起動します。Oracle Restartでデータベースを管理している場合は、srvctl start databaseコマンドを使用することをお薦めします。

SQL*PlusおよびOracle Restartを使用して、次のような様々なモードでデータベース・インスタンスを起動できます。

  • NOMOUNT—CDBをマウントせずにインスタンスを起動します。この場合、データベースへのアクセスは禁止され、通常はデータベース作成または制御ファイルの再作成時にのみ使用されます。

  • MOUNT—インスタンスを起動し、CDBをマウントするが、クローズしたままにするモード。この状態では、一部のDBAアクティビティは可能ですが、データベースへの汎用アクセスはできません。

  • OPEN—インスタンスを起動し、CDBをマウントしてオープンするモード。この操作を非制限モードで実行してユーザー全員にアクセスを許可するか、制限モードで実行してデータベース管理者のみにアクセスを許可できます。

  • FORCE—起動時または停止時に問題が発生した後にインスタンスを強制的に起動するモード。

  • OPEN RECOVER—インスタンスを起動し、直後に完全メディア・リカバリを開始するモード。

ノート:

共有サーバー・プロセスを介してデータベースに接続してデータベースのインスタンスを起動することはできません。

次の例では、インスタンスを起動できるいくつかの状態を具体的に説明します。STARTUPコマンドの句の結合時やsrvctl start databaseコマンドの起動オプションの結合時は、いくつかの制限が適用されます。

ノート:

制御ファイル、データベース・ファイルまたはオンラインREDOログが使用できない場合は、インスタンスの起動で問題が発生することがあります。データベースをマウントするときにCONTROL_FILES初期化パラメータで指定された1つ以上のファイルが存在しない場合、またはオープンできない場合は、Oracle Databaseによって警告メッセージが返され、データベースはマウントされません。データベースをオープンするときに、1つ以上のデータファイルまたはオンラインREDOログを使用できない場合、またはオープンできない場合、データベースは警告メッセージを返し、データベースをオープンしません。

関連項目:

親トピック: インスタンスの起動

インスタンスを起動し、データベースをマウントしてオープンする方法

通常のデータベース操作とは、インスタンスを起動し、データベースをマウントおよびオープンすることを意味します。このモードでは、有効なユーザーがデータベースに接続して、データ・アクセス操作を実行できます。

次のコマンドは、インスタンスを起動し、デフォルトの場所から初期化パラメータを読み込んで、データベースをマウントおよびオープンします。

SQL*Plus SRVCTL(Oracle Restartを使用している場合) 
STARTUP
 
srvctl start database -db db_unique_name

db_unique_nameはDB_UNIQUE_NAME初期化パラメータと一致します。

親トピック: インスタンスの起動

インスタンスを起動するが、データベースをマウントしない方法

インスタンスは、データベースをマウントしなくても起動できます。通常、この方法で起動するのはデータベースの作成時のみです。

次のコマンドのいずれかを使用します。

SQL*Plus SRVCTL(Oracle Restartを使用している場合) 
STARTUP NOMOUNT
 
srvctl start database -db db_unique_name -startoption nomount

親トピック: インスタンスの起動

インスタンスを起動し、データベースをマウントする方法

インスタンスを起動し、CDBをオープンしないでマウントして、特定のメンテナンス操作を実行できます。

たとえば、次のようなタスクの実行時は、CDBのマウントは必要ですが、オープンはしないでください。

次のコマンドは、インスタンスを起動してデータベースをマウントしますが、データベースはクローズしたままです。

SQL*Plus SRVCTL(Oracle Restartを使用している場合) 
STARTUP MOUNT
 
srvctl start database -db db_unique_name -startoption mount

親トピック: インスタンスの起動

起動時にインスタンスへのアクセスを制限する方法

インスタンスの使用を管理担当者にのみ許可し、一般データベース・ユーザーの使用を禁止するには、制限モードでインスタンスを起動して、オプションでデータベースをマウントおよびオープンします。

次のいずれかのタスクを実行する必要があるときは、このインスタンス起動モードを使用してください。

  • データのエクスポートまたはインポートを実行する場合

  • SQL*Loaderを使用してデータをロードする場合

  • 一時的に一般ユーザーがデータを使用できないようにする場合

  • 特定の移行またはアップグレード操作を実行する場合

通常、CREATE SESSIONシステム権限を持つすべてのユーザーが、オープンしているデータベースに接続できます。データベースを制限モードでオープンすると、CREATE SESSIONおよびRESTRICTED SESSIONシステム権限の両方を持つユーザーのみがデータベースへのアクセスを許可されます。データベース管理者のみにRESTRICTED SESSIONシステム権限が付与されている必要があります。さらに、インスタンスが制限モードの場合、データベース管理者はOracle Netリスナーからリモートでインスタンスにアクセスすることはできませんが、インスタンスが実行されているシステムからローカルでインスタンスにアクセスすることのみ可能です。

次のコマンドは、制限モードでインスタンスを起動します(データベースをマウントしてオープンします)。

SQL*Plus SRVCTL(Oracle Restartを使用している場合) 
STARTUP RESTRICT
 
srvctl start database -db db_unique_name -startoption restrict

MOUNT、NOMOUNTおよびOPENモードと制限モードを組み合せて使用できます。

RESTRICTED SESSION機能を無効にするには、ALTER SYSTEM文を使用します。 

ALTER SYSTEM DISABLE RESTRICTED SESSION;

関連項目:

親トピック: インスタンスの起動

インスタンスを強制的に起動する方法

通常と異なる状況では、データベース・インスタンスを起動しようとしたときに問題が発生することがありますが、データベース・インスタンスを強制的に起動できます。

次の問題が発生している場合以外は、データベースを強制的に起動しないでください。

  • 現行インスタンスをSHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALコマンドで停止できない場合

  • インスタンス起動時に問題が発生した場合。

このような問題が発生した場合、次のいずれかのコマンドを指定して新しいインスタンスを起動(必要に応じて、データベースをマウントおよびオープン)すると、通常は問題を解決できます。

SQL*Plus SRVCTL(Oracle Restartを使用している場合) 
STARTUP FORCE
 
srvctl start database -db db_unique_name -startoption force

インスタンスの実行中にFORCEモードを使用すると、ABORTモードでインスタンスを停止した後に再起動します。この場合、メッセージ「インスタンス"abort"の停止中」に続いて「ORACLEインスタンス"normal"の起動中」がアラート・ログに表示されます。

関連項目:

現行インスタンスの強制終了による影響の詳細は、「ABORTモードによる停止」を参照してください

親トピック: インスタンスの起動

インスタンスを起動し、データベースをマウントして、完全メディア・リカバリを開始する方法

メディア・リカバリが必要な場合は、インスタンスを起動し、データベースをインスタンスにマウントして、リカバリ処理を自動的に開始できます。

これには、次のいずれかのコマンドを使用します。

SQL*Plus SRVCTL(Oracle Restartを使用している場合) 
STARTUP OPEN RECOVER
 
srvctl start database -db db_unique_name -startoption "open,recover"

必要ない場合にリカバリを実行しようとすると、Oracle Databaseによってエラー・メッセージが表示されます。

親トピック: インスタンスの起動

オペレーティング・システム起動時にデータベースを自動的に起動する方法

多くのサイトでは、システムの起動直後に1つ以上のOracle Databaseインスタンスとデータベースを自動的に起動する手順を使用しています。

そのための手順は、オペレーティング・システムによって異なります。自動起動の詳細は、オペレーティング・システム固有のOracleマニュアルを参照してください。

データベースの自動起動を構成する方法としてお薦めする(およびプラットフォームに依存しない)方法は、Oracle Restartです。

関連項目:

Oracle Restartについて学習するには、Oracle Database管理者ガイドを参照してください

親トピック: インスタンスの起動

リモート・インスタンスの起動

ローカルのOracle Databaseサーバーが分散データベースの一部を構成している場合は、リモート・インスタンスとデータベースを起動できます。

リモート・インスタンスの起動と停止の手順は、通信プロトコルとオペレーティング・システムによって大きく異なります。

親トピック: インスタンスの起動

データベースの可用性の変更

データベースの可用性を変更できます。可用性の変更は、メンテナンス上の理由やデータベースを読取り専用にするために行う場合があります。

親トピック: CDBの起動および停止

インスタンスにデータベースをマウントする方法

特定の管理操作を実行する場合は、データベースを起動してインスタンスにマウントし、クローズしたままにする必要があります。そのためには、インスタンスを起動してデータベースをマウントします。

  • あらかじめ起動したインスタンスにデータベースをマウントするには、次のように、SQL文ALTER DATABASEでMOUNT句を指定します。
    ALTER DATABASE MOUNT;

関連項目:

データベースをマウントし、クローズしておくことが必要な操作(およびインスタンスの起動とデータベースを1ステップでマウントする手順)の詳細は、「インスタンスを起動し、データベースをマウントする方法」を参照してください

親トピック: データベースの可用性の変更

クローズしているデータベースをオープンする方法

データベースをオープンすることによって、マウントされ、クローズしているデータベースを一般的な用途のために使用可能にできます。

  • マウントされたデータベースをオープンするには、ALTER DATABASE SQL文でOPEN句を使用します。
    ALTER DATABASE OPEN;

この文の実行後は、CREATE SESSIONシステム権限を持つ有効なOracle Databaseユーザーであれば、誰でもデータベースに接続できます。

データベースを読取り専用モードでオープンする方法

データベースを読取り専用モードでオープンすると、オープンしたデータベースを問い合せることができますが、その間にデータの内容がオンラインで変更されることはありません。

これにより、データファイルとREDOログ・ファイルにデータが書き込まれないことが保証されますが、データベース・リカバリや、REDOを生成せずにデータベースの状態を変更する操作が制限されることはありません。たとえば、データファイルをオフラインとオンラインの間で切り替えてもデータの内容には影響しないため、このような切替えは可能です。

ディスク・ソートの実行時など、読取り専用モードでデータベースを問い合せるときに一時表領域を使用する場合、問合せの発行者には、デフォルト一時表領域としてローカル管理表領域が割り当てられている必要があります。割り当てられていない場合は、問合せが失敗します。

次の文では、データベースが読取り専用モードでオープンします。

ALTER DATABASE OPEN READ ONLY;

また、次のように読取り/書込みモードでデータベースをオープンすることもできます。

ALTER DATABASE OPEN READ WRITE;

ただし、読取り/書込みはデフォルトのモードです。

ノート:

RESETLOGS句とREAD ONLY句は併用できません。

読取り専用データベースの制約

  • 読取り専用データベースに対してアプリケーションを実行中は、データベース・オブジェクトへ書き込まないでください。たとえば、アプリケーションは、グローバルな一時表を含むデータベース表に対して行の挿入、削除、更新またはマージを実行する際に、データベース・オブジェクトに書き込みます。アプリケーションは、データベースの順序を操作する際にデータベース・オブジェクトに書き込みます。また、アプリケーションは行のロック、EXPLAIN PLANの実行またはDDLの実行の際にデータベース・オブジェクトに書き込みます。オラクル社が提供するPL/SQLパッケージのファンクションとプロシージャの多くは(DBMS_SCHEDULERなど)、データベース・オブジェクトに書き込みます。アプリケーションがこれらのファンクションとプロシージャのいずれかをコールする場合、または前述の操作のいずれかを実行する場合、アプリケーションからデータベース・オブジェクトへ書込みが実行されるため、読取り専用ではありません。

  • 読取り専用データベースで実行する場合は、1つのデータベース・リンクを使用する進行中のトランザクションをコミットまたはロールバックしてから、別のデータベース・リンクを使用する必要があります。これは、最初のデータベース・リンクで汎用的なSELECT文を実行し、トランザクションが現在読取り専用である場合も当てはまります。

  • 読取り専用データベースではPL/SQLストアド・プロシージャをコンパイルまたは再コンパイルできません。リモート・プロシージャ・コールが原因のPL/SQLの無効化を最小限に抑えるには、読取り専用データベースに対してリモート・プロシージャ・コールを実行するセッションではREMOTE_DEPENDENCIES_MODE=SIGNATUREを使用します。

  • 読取り専用データベースで一度もコールされたことがないリモート・プロシージャ(読取り専用のリモート・プロシージャであっても)は、そのデータベースから起動できません。この制約は、無名PL/SQLブロックの中およびSQL文の中のリモート・プロシージャ・コールに当てはまります。ストアド・プロシージャ内にリモート・プロシージャ・コールを指定するか、またはデータベース内のリモート・プロシージャを読取り専用にする前に起動できます。

関連項目:

ALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください

親トピック: データベースの可用性の変更

オープンしているデータベースへのアクセスを制限する方法

データベースが制限モードの場合は、RESTRICTED SESSION権限を持つユーザーのみが新しい接続を開始できます。SYSDBAとして接続するユーザー、またはDBAロールを使用して接続するユーザーにはこの権限があります。

すでに実行中のインスタンスを制限モードにするには:

  • ENABLE RESTRICTED SESSION句を指定して、SQL文ALTER SYSTEMを実行します。

実行中インスタンスを制限モードにすると、ユーザー・セッションは終了されないか、終了された場合は影響を受けます。したがって、インスタンスを制限モードにした場合は、管理タスクを実行する前に現行のユーザー・セッションをすべて終了することを検討してください。

インスタンスの制限モードを解除するには、ALTER SYSTEMでDISABLE RESTRICTED SESSION句を指定します。

関連項目:

親トピック: データベースの可用性の変更

CDBの停止

SQL*PlusまたはOracle RestartでCDBを停止できます。

  • データベースの停止について
    Oracle Restartを使用していない場合、データベース・インスタンスを停止するには、SQL*PlusでSYSOPER、SYSDBA、SYSBACKUPまたはSYSDGとして接続し、SHUTDOWNコマンドを発行します。Oracle Restartでデータベースを管理している場合は、srvctl stop databaseコマンドを使用してデータベースを停止する方法をお薦めします。
  • NORMALモードによる停止
    NORMALモードでデータベースを停止する場合、現在、接続しているすべてのユーザーが切断するまで待機してから、データベースが停止します。通常モードはデフォルトの停止モードです。
  • IMMEDIATEモードによる停止
    IMMEDIATEモードでデータベースを停止する場合、Oracle Databaseにより実行中のSQL文が終了され、ユーザーが切断されます。アクティブなトランザクションは終了され、コミットされていない変更はロールバックされます。
  • TRANSACTIONALモードによる停止
    TRANSACTIONALモードでデータベースを停止する場合、ユーザーが新規トランザクションを開始できなくなりますが、現在のトランザクションがすべて完了するまで待機してから、データベースが停止します。現行トランザクションの性質によっては、停止までにかなりの時間がかかる場合があります。
  • ABORTモードによる停止
    データベース・インスタンスを終了することによって、データベースをただちに停止できます。
  • 停止のタイムアウト
    ユーザーによる切断またはトランザクションの完了を待機する停止モードには、待機時間に制限があります。

親トピック: CDBの起動および停止

データベースの停止について

Oracle Restartを使用していない場合、データベース・インスタンスを停止するには、SQL*PlusでSYSOPER、SYSDBA、SYSBACKUPまたはSYSDGとして接続し、SHUTDOWNコマンドを発行します。Oracle Restartでデータベースを管理している場合は、srvctl stop databaseコマンドを使用してデータベースを停止する方法をお薦めします。

停止処理が完了するまで、データベース停止を開始したセッションに制御が戻されません。停止処理の進行中に接続しようとするユーザーは、次のようなメッセージを受け取ります。

ORA-01090: shutdown in progress - connection is not permitted

ノート:

共有サーバー・プロセスを介してデータベースに接続している場合は、データベースを停止できません。

データベースには、複数の停止モード(NORMAL、IMMEDIATE、TRANSACTIONALおよびABORT)があります。一部の停止モードでは、データベースを実際に停止する前に、特定のイベント(トランザクションの完了またはユーザーによる切断など)の発生を待機します。これらのイベントに対するタイムアウト間隔は1時間です。

関連項目:

Oracle Restartの詳細は、Oracle Database管理者ガイドを参照してください

親トピック: CDBの停止

NORMALモードによる停止

データベースを通常モードで停止する場合、データベースは停止する前に、接続されているすべてのユーザーが切断するまで待機します。通常モードはデフォルトの停止モードです。

データベースを通常の状況で停止するには、次のいずれかのコマンドを使用します。

SQL*Plus SRVCTL(Oracle Restartを使用している場合) 
SHUTDOWN [NORMAL]
 
srvctl stop database -db db_unique_name -stopoption normal

SQL*Plus SHUTDOWNコマンドのNORMAL句はオプションです(これがデフォルトの停止方法であるため)。SRVCTLの場合、-stopoptionオプションを省略すると、停止操作はデータベースのOracle Restart構成に格納されている停止オプションに従って進行します。デフォルトの停止オプションはIMMEDIATEです。

通常のデータベース停止では、次のように処理が進みます。

  • 文が発行された後は、新しい接続は許可されません。

  • データベースは、停止する前に、現在データベースに接続しているすべてのユーザーによるデータベースからの切断を待機します。

次にデータベースを起動するときに、インスタンス・リカバリ手順は必要ありません。

親トピック: CDBの停止

IMMEDIATEモードによる停止

データベースを即時モードで停止する場合、Oracle Databaseは、実行中のSQL文をすべて終了し、ユーザーとの接続を切断します。アクティブなトランザクションは終了され、コミットされていない変更はロールバックされます。

データベースの即時停止は、次のような状況のときにのみ使用します。

  • 自動バックアップおよび無人バックアップを開始する場合

  • 電源が間もなく停止する場合

  • データベースやデータベース・アプリケーションの一部が異常に動作している場合で、ユーザーにログオフを依頼できない場合、またはユーザーがログオフできない場合

データベースを即時に停止するには、次のいずれかのコマンドを使用します。

SQL*Plus SRVCTL(Oracle Restartを使用している場合) 
SHUTDOWN IMMEDIATE
 
srvctl stop database -db db_unique_name -stopoption immediate

このデータベース停止では、次のように処理が進みます。

  • 文が発行されると、新しい接続は許可されず、新しいトランザクションは開始できません。

  • すべての未コミットのトランザクションは、ロールバックされます。(長くかかる未コミットのトランザクションが存在する場合、この停止方法ではその名前に反して即座に終了しない場合があります。)

  • Oracle Databaseは、現在データベースに接続しているユーザーが切断されるのを待機しません。アクティブなトランザクションは暗黙的にロールバックされ、接続中のユーザーはすべて切断されます。

次にデータベースを起動するときに、インスタンス・リカバリ手順は必要ありません。

親トピック: CDBの停止

TRANSACTIONALモードによる停止

TRANSACTIONALモードでデータベースを停止する場合、ユーザーが新規トランザクションを開始できなくなりますが、現在のトランザクションがすべて完了するまで待機してから、データベースが停止します。現行トランザクションの性質によっては、停止までにかなりの時間がかかる場合があります。

アクティブ・トランザクションを完了してから、計画どおりにインスタンスを停止する場合は、次のいずれかのコマンドを使用します。

SQL*Plus SRVCTL(Oracle Restartを使用している場合) 
SHUTDOWN TRANSACTIONAL
 
srvctl stop database -db db_unique_name -stopoption transactional

このデータベース停止では、次のように処理が進みます。

  • 文が発行されると、新しい接続は許可されず、新しいトランザクションは開始できません。

  • すべてのトランザクションが完了すると、まだインスタンスに接続されているすべてのクライアントが切断されます。

  • この時点で、インスタンスはSHUTDOWN IMMEDIATE文を発行した場合と同じように停止します。

次にデータベースを起動するときに、インスタンス・リカバリ手順は必要ありません。

TRANSACTIONALオプションによる停止では、クライアントの作業内容が失われずに済み、すべてのユーザーがログオフする必要がなくなります。

親トピック: CDBの停止

ABORTモードによる停止

データベース・インスタンスを終了することによって、データベースをただちに停止できます。

この停止方法は、次の場合を除いてできるだけ使用を避けてください。

  • データベース、もしくはそのアプリケーションの1つが不適切に機能していて、かつ他のいずれの停止モードも作動しない場合。

  • データベースをただちに停止する必要がある(たとえば、電源遮断が1分以内に発生することがわかっている)場合。

  • データベース・インスタンスを起動するときに問題が発生した場合。

トランザクションとユーザーの接続を強制終了してデータベースを停止する必要がある場合は、次のいずれかのコマンドを使用します。

SQL*Plus SRVCTL(Oracle Restartを使用している場合) 
SHUTDOWN ABORT
 
srvctl stop database -db db_unique_name -stopoption abort

このデータベース停止では、次のように処理が進みます。

  • 文が発行されると、新しい接続は許可されず、新しいトランザクションは開始できません。

  • Oracle Databaseによって処理されている現行のクライアントSQL文はただちに終了します。

  • コミットされていないトランザクションはロールバックされません。

  • Oracle Databaseは、現在データベースに接続しているユーザーが切断されるのを待機しません。接続中のユーザーはすべて暗黙的に切断されます。

次にデータベースを起動するときに、自動インスタンス・リカバリ手順が必要になります。

親トピック: CDBの停止

停止のタイムアウト

ユーザーによる切断またはトランザクションの完了を待機する停止モードには、待機時間に制限があります。

停止をブロックするすべてのイベントが1時間以内に発生しない場合、停止操作は「ORA-01013: ユーザーによって現行の操作の取消しがリクエストされました」というメッセージを表示して強制終了されます。また、このメッセージは停止プロセスを中断した場合(たとえばCTRL-Cを押した場合など)にも表示されます。インスタンスの停止を中断しようとしないことをお薦めします。停止プロセスが完了してから、インスタンスを再起動してください。

ORA-01013が発生した後は、インスタンスが予測できない状態になると考える必要があります。このため、SHUTDOWNコマンドを再発行して、停止プロセスを継続する必要があります。後続のSHUTDOWNコマンドが引き続き失敗する場合は、SHUTDOWN ABORTコマンドを発行してインスタンスを停止する必要があります。その後でインスタンスを再起動できます。

親トピック: CDBの停止

CDBの静止

CDBの静止中は、DBAによるトランザクション、問合せ、フェッチまたはPL/SQL文のみ実行できます。

  • データベースの静止について
    データベースを、DBAによるトランザクション、問合せ、フェッチまたはPL/SQL文の実行のみ許可された状態にすることが必要な場合があります。このような状態は、システム上でDBA以外によるトランザクション、問合せ、フェッチまたはPL/SQL文が実行されていないという意味で、静止状態と呼びます。
  • データベースの静止状態への変更
    データベースを静止状態にした場合、DBA以外によるアクティブ・セッションは非アクティブになるまで続行されます。アクティブなセッションとは、トランザクション、問合せ、フェッチまたはPL/SQL文を現在実行しているセッション、または現在なんらかの共有リソース(エンキューなど)を保持しているセッションです。非アクティブなセッションがアクティブになることはできません。
  • 通常操作へのシステムのリストア
    システムを通常操作にリストアすると、DBA以外によるすべてのアクティビティを続行できます。
  • インスタンスの静止状態の表示
    V$INSTANCEビューを問い合せて、インスタンスの静止状態を表示できます。

親トピック: CDBの起動および停止

データベースの静止について

データベースを、DBAによるトランザクション、問合せ、フェッチまたはPL/SQL文の実行のみ許可された状態にすることが必要な場合があります。このような状態は、システム上でDBA以外によるトランザクション、問合せ、フェッチまたはPL/SQL文が実行されていないという意味で、静止状態と呼びます。

ノート:

静止中のデータベースに関するこの項の説明では、DBAがユーザーSYSまたはSYSTEMとして定義されています。DBAロールを持つユーザーなどの他のユーザーには、ALTER SYSTEM QUIESCE DATABASE文の発行や、データベース静止後の処理の継続は許可されていません。

データベースを静止状態にすることで、管理者は、それ以外の状態では安全に実行できない処理を実行できます。次の処理を実行できます。

  • 同時ユーザー・トランザクションが同じオブジェクトにアクセスした場合に失敗する処理。たとえば、データベース表のスキーマの変更や、NOWAITロックが必要な既存表への列の追加などがこれに該当します。

  • 同時ユーザー・トランザクションによって好ましくない中間影響を受けるアクション、たとえば表を最初にエクスポートしてから削除し、最後にインポートする場合のような、複数ステップ手順からなる表の再編成処理など。表が削除された後であっても、インポートされる前に同時ユーザーが表にアクセスしようとすると、状況を正確に認識できません。

データベースの静止機能がない場合は、データベースを停止し、制限モードで再度オープンする必要があります。これは、特に24時間、365日の可用性が必要なシステムにとっては重大な制限です。データベースの静止によって、ユーザーに対する遮断とデータベースの停止と再起動に伴う停止時間を最小限にできるため、制限が大幅に緩和されます。

データベースが静止中の場合、DBA以外のセッションがアクティブにならないようにするために、データベース・リソース・マネージャの機能が使用されています。したがって、この文が有効な間に現行のリソース・プランを変更しようとすると、その処理はシステムが静止解除されるまでキューに待機します。

関連項目:

Database Resource Managerの詳細は、Oracle Database管理者ガイドを参照

親トピック: CDBの静止

データベースの静止状態への変更

データベースを静止状態にした場合、DBA以外によるアクティブ・セッションは非アクティブになるまで続行されます。アクティブなセッションとは、トランザクション、問合せ、フェッチまたはPL/SQL文を現在実行しているセッション、または現在なんらかの共有リソース(エンキューなど)を保持しているセッションです。非アクティブなセッションがアクティブになることはできません。

たとえば、ユーザーが非アクティブなセッションを強制的にアクティブにしようとしてSQL問合せを発行すると、その問合せは停止したようになります。後でデータベースが静止解除されると、セッションが再開され、ブロックされていた処理が実行されます。

  • データベースを静止状態にするには、次のSQL文を発行します。
    ALTER SYSTEM QUIESCE RESTRICTED;

DBA以外のセッションがすべて非アクティブになると、ALTER SYSTEM QUIESCE RESTRICTED文が完了し、データベースは静止状態となります。Oracle Real Application Clusters環境でこの文を発行すると、文を発行したインスタンスだけでなく、すべてのインスタンスが影響を受けます。

ALTER SYSTEM QUIESCE RESTRICTED文は、アクティブなセッションが非アクティブになるまで、長時間待機する場合があります。V$BLOCKING_QUIESCEビューを問い合せると、静止操作をブロックしているセッションを判別できます。このビューでは、1つの列SID(セッションID)のみが返されます。これをV$SESSIONと結合すると、次の例のように、セッションに関する詳細を取得できます。 

select bl.sid, user, osuser, type, program
from v$blocking_quiesce bl, v$session se
where bl.sid = se.sid;

データベース静止の要求を中断した場合、またはアクティブなセッションがすべて静止する前にセッションが異常終了した場合は、Oracle Databaseによって、この文による部分的な影響がすべて自動的に取り消されます。

複数のOracle Call Interface (OCI)の連続したフェッチによって問合せが実行されている場合、ALTER SYSTEM QUIESCE RESTRICTED文はすべてのフェッチが完了するまで待機しません。現行のフェッチの完了のみを待機します。

専用サーバー接続の場合も、共有サーバー接続の場合も、この文の発行後、DBA以外のユーザーがログインしようとすると、その処理はデータベース・リソース・マネージャによってすべてキューに送られ、進行しません。ユーザーにはログインが停止したように見えます。データベースが静止解除されると、ログインは再開されます。

文を発行したセッションが終了しても、データベースは静止状態のままです。DBAは、データベースを静止解除される文を明示的に発行するために、データベースにログインする必要があります。

ノート:

データベースが静止状態の場合でも、Oracle Databaseのバックグラウンド・プロセスが内部の目的のために更新を実行している可能性があるため、データベースが静止状態の場合はコールド・バックアップを実行できません。また、オンライン・データファイルのヘッダーは引き続きアクセス可能に見えます。このファイル・ヘッダーの状態は、データベースが正しく停止された場合とは異なります。ただし、データベースが静止状態の間でも、オンライン・バックアップ操作は実行できます。

関連項目:

親トピック: CDBの静止

通常操作へのシステムのリストア

システムを通常操作にリストアすると、DBA以外によるすべてのアクティビティを続行できます。

  • データベースを通常操作にリストアするには、次のSQL文を発行します。
    ALTER SYSTEM UNQUIESCE;

Oracle Real Application Clusters環境では、データベースを静止した場合と同じセッションまたは同じインスタンスでこの文を発行する必要はありません。ALTER SYSTEM UNQUIESCE文を発行したセッションが異常終了した場合、Oracle Databaseサーバーは静止解除を確実に完了します。

親トピック: CDBの静止

インスタンスの静止状態の表示

V$INSTANCEビューを問い合せて、インスタンスの静止状態を表示できます。

インスタンスの静止状態を表示するには:

  • V$INSTANCEビューのACTIVE_STATE列を問い合せます。

列の値は、次のいずれかになります。

  • NORMAL: 通常の静止していない状態。

  • QUIESCING: 静止途中の状態。DBA以外の一部のセッションがアクティブな状態です。

  • QUIESCED: 静止状態。DBA以外のセッションは非アクティブで、許可されていない状態です。

親トピック: CDBの静止

データベースの一時停止と再開

ALTER SYSTEM SUSPEND文は、データファイル(ファイル・ヘッダーとファイル・データ)および制御ファイルへの入出力(I/O)をすべて停止します。一時停止状態によって、I/Oに干渉されずにデータベースのバックアップを作成できます。データベースを一時停止すると、実行中のすべてのI/O操作の完了が許可され、新しいデータベース・アクセスはキューに待機した状態になります。通常のデータベース操作を再開するには、ALTER SYSTEM RESUME文を使用します。

データベース操作を一時停止するには:

  • ALTER SYSTEM SUSPEND文を実行します。

データベース操作を再開するには:

  • ALTER SYSTEM RESUME文を実行します。

SUSPENDコマンドは、インスタンスに固有ではありません。Oracle Real Application Clusters環境では、あるシステムでSUSPENDコマンドを発行すると、内部ロッキング・メカニズムを通じてインスタンス間で停止要求が伝播し、特定のクラスタのアクティブ・インスタンスがすべて停止します。ただし、あるインスタンスの一時停止中に新しいインスタンスを起動すると、新しいインスタンスは一時停止されません。

SUSPENDコマンドとRESUMEコマンドは、異なるインスタンスから発行できます。たとえば、インスタンス1、2および3の実行中に、インスタンス1からALTER SYSTEM SUSPEND文を発行した場合は、インスタンス1、2または3から同様にRESUME文を発行できます。

一時停止/再開機能は、ディスクやファイルをミラー化してそのミラーを分割できるシステムで役立ち、バックアップとリストアの代替ソリューションを提供します。書込み中に既存のデータベースからミラー化されたディスクを分割できないシステムを使用している場合は、この一時停止/再開機能を使用すると容易に分割できます。

一時停止したデータベースのコピーにはコミット前の更新が含まれるため、一時停止/再開機能は通常の停止操作の簡易版ではありません。

ノート:

表領域をホット・バックアップ・モードに設定する代替手段としてALTER SYSTEM SUSPEND文を使用しないでください。データベースの一時停止操作ではなく、ALTER TABLESPACE BEGIN BACKUP文を使用してください。

次の文は、ALTER SYSTEM SUSPEND/RESUMEの使用方法を示しています。データベースの状態を確認するために、V$INSTANCEビューを問い合せています。 

SQL> ALTER SYSTEM SUSPEND;
System altered
SQL> SELECT DATABASE_STATUS FROM V$INSTANCE;
DATABASE_STATUS
---------
SUSPENDED

SQL> ALTER SYSTEM RESUME;
System altered
SQL> SELECT DATABASE_STATUS FROM V$INSTANCE;
DATABASE_STATUS
---------
ACTIVE

関連項目:

データベースの一時停止/再開機能を使用してデータベースをバックアップする方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

親トピック: CDBの起動および停止

インスタンス中断の遅延

INSTANCE_ABORT_DELAY_TIME初期化パラメータを使用して、エラーによりインスタンスが中断したときに、データベースの停止を遅延する時間を秒単位で指定します。

エラーによってOracleデータベース・インスタンスが中断することがあります。INSTANCE_ABORT_DELAY_TIME初期化パラメータを使用して、インスタンスの停止を遅延する時間を指定します。データベース管理者が遅延時間を使用して、エラーについての情報を取得し、インスタンスが中断したときに発生する可能性のある問題を最小限に抑えることができます。たとえば、データベース管理者が遅延時間を使用して診断を取得し、透過アプリケーション・フェイルオーバー(TAF)を使用して接続をリダイレクトし、バッファ・キャッシュをフラッシュできます。遅延した中断が開始されると、アラート・ログにメッセージが書き込まれます。 

注意:

INSTANCE_ABORT_DELAY_TIMEを大きすぎる値に設定しないでください。インスタンスはエラーが原因でクローズするため、一部のプロセスやリソースが破損したり使用できなくなっている可能性があり、複雑なアクションは実行できない可能性があります。

インスタンス中断を遅延するには:

  • INSTANCE_ABORT_DELAY_TIME初期化パラメータで秒数を設定して、エラーが原因でインスタンスが中断するときに停止を遅延する時間を指定します。

    このパラメータはデフォルトでは0に設定されます。

例15-10 INSTANCE_ABORT_DELAY_TIME初期化パラメータの設定

ALTER SYSTEM SET INSTANCE_ABORT_DELAY_TIME=60;

親トピック: CDBの起動および停止

システム・レベルでのCDBの変更

初期化パラメータはCDBレベルで設定できます。場合によっては、これらのパラメータをPDBレベルで上書きできます。

親トピック: CDBの管理

CDBのシステム・レベルの変更について

ALTER SYSTEM SET文は、1つ以上のコンテナの初期化パラメータを動的に設定します。

CDBでは初期化パラメータの継承モデルが使用されます。このモデルでは、PDBがルートから初期化パラメータの値を継承します。この場合、継承は、ルートの特定のパラメータ値が特定のPDBに適用されることを意味します。

PDBは、一部のパラメータのルート設定を上書きできます。このような場合、PDBには初期化パラメータごとに継承プロパティ(trueまたはfalse)があります。あるパラメータでPDBがルートの値を継承する場合、そのパラメータの継承プロパティはtrueです。それ以外の場合、プロパティはfalseです。

一部のパラメータについては、継承プロパティがtrueである必要があります。その他のパラメータでは、現在のコンテナがPDBである場合、ALTER SYSTEM SET文を実行して継承プロパティを変更できます。初期化パラメータのV$SYSTEM_PARAMETER.ISPDB_MODIFIABLEがTRUEの場合は、そのパラメータの継承プロパティをfalseに設定できます。

現在のコンテナがルートである場合、ALTER SYSTEM SET文のCONTAINER句で設定されるパラメータ値を継承するPDBが制御されます。CONTAINER句の構文は次のとおりです。 

CONTAINER = { CURRENT | ALL }

次の設定を使用できます。

  • CURRENT

    パラメータ設定は現在のコンテナのみに適用されます。これは、CONTAINERのデフォルト設定です。現在のコンテナがルートである場合は、ルートと、そのパラメータについてtrueの継承プロパティを持つすべてのPDBにそのパラメータ設定が適用されます。

  • ALL

    パラメータ設定は、ルートおよびすべてのPDBを含むCDB内のすべてのコンテナに適用されます。ALLを指定すると、すべてのPDB内のパラメータの継承プロパティはtrueに設定されます。

関連項目:

CONTAINER句およびそれに適用するルールの詳細は、「現在のコンテナについて」を参照してください

親トピック: システム・レベルでのCDBの変更

ALTER SYSTEMを使用したCDBの変更

システム・レベルでCDBを変更するには、ALTER SYSTEM文を使用します。

前提条件

現在のユーザーには、ALTER SYSTEM権限が共通して付与されている必要があります。

CDBのルートでALTER SYSTEM SETを使用するには:

  1. SQL*Plusで、現在のコンテナがルートであることを確認します。

  2. ALTER SYSTEM SET文を実行します。

ノート:

PDBのパラメータの継承プロパティをfalseからtrueに変更するには、現在のコンテナがPDBであるときにALTER SYSTEM RESET文を実行して、パラメータをリセットします。次のサンプル文は、OPEN_CURSORSパラメータをリセットします。 

ALTER SYSTEM RESET OPEN_CURSORS SCOPE = SPFILE;

例15-11 すべてのコンテナへの初期化パラメータの設定

このALTER SYSTEM SET文では、すべてのコンテナのOPEN_CURSORS初期化パラメータを200に設定し、各PDBの継承プロパティをTRUEに設定します。 

ALTER SYSTEM SET OPEN_CURSORS = 200 CONTAINER = ALL;

例15-12 ルートの初期化パラメータの設定

このALTER SYSTEM SET文では、ルートおよびPDBのOPEN_CURSORS初期化パラメータを200に設定します(このとき、パラメータの継承プロパティはtrueです)。 

ALTER SYSTEM SET OPEN_CURSORS = 200 CONTAINER = CURRENT;

関連項目:

親トピック: システム・レベルでのCDBの変更

CDBルートへの接続時のコンテナの変更

ALTER DATABASE文を使用してCDB全体またはルートを変更できます。

親トピック: CDBの管理

CDBルートへの接続時のコンテナの変更について

ALTER DATABASE文はCDBを変更します。CDBルートに接続するとき、ALTER PLUGGABLE DATABASE文では、1つ以上のPDBのオープン・モードを変更できます。

ALTER DATABASEおよびALTER PLUGGABLE DATABASEの動作は、文を使用するときに接続されているコンテナによって異なります。

  • 共通ユーザーとしてCDBルートに接続されている場合

    RENAME GLOBAL_NAME句を含むALTER DATABASE文を使用すると、CDBのドメインが変更され、CDBのドメインにデフォルト設定された各PDBのドメインに影響を及ぼします。pdb_change_state句を含むALTER PLUGGABLE DATABASE文は、1つ以上のPDBのオープン・モードを変更します。

  • PDBに接続されている場合

    この場合、ALTER DATABASEおよびALTER PLUGGABLE DATABASE文は現在のPDBのみを変更します。

次の表に、ALTER DATABASEおよびALTER PLUGGABLE DATABASE文の句によって変更されるコンテナを示します。

表15-3 CDBのコンテナを変更する文

CDB全体の変更 ルートのみの変更 1つ以上のPDBの変更

現在のコンテナがルートである共通ユーザーとして接続した場合、次の句を含むALTER DATABASE文を使用すると、CDB全体が変更されます。

現在のコンテナがルートである共通ユーザーとして接続した場合、次の句を含むALTER DATABASE文を使用すると、ルートのみが変更されます。

次の句を含むALTER DATABASE文を使用すると、ルートが変更され、PDBにデフォルト値が設定されます。

これらの句を使用すると、特定のPDBにデフォルト以外の値を設定できます。

現在のコンテナがルートである共通ユーザーとして接続した場合、次の句を含むALTER PLUGGABLE DATABASE文を使用すると、1つ以上のPDBのオープン・モードを変更できます。

現在のコンテナがPDBである場合、この句を含むALTER PLUGGABLE DATABASE文を使用すると、現在のPDBのオープン・モードを変更できます。

現在のコンテナがルートである共通ユーザーとして接続した場合、次の句を含むALTER PLUGGABLE DATABASE文を使用すると、CDBの再起動時にPDBのオープン・モードを保持することも破棄することもできます。

関連項目:

親トピック: CDBルートへの接続時のコンテナの変更

ALTER DATABASEを使用したCDB全体の変更

ALTER DATABASE文を使用して、ルートおよびPDBすべてを含むCDB全体を変更できます。ほとんどのALTER DATABASE文は、CDB全体を変更します。

ルートまたは個々のPDBではなくCDB全体を変更する文のリストは、「CDBルートへの接続時のコンテナの変更について」の「CDB全体の変更」列を参照してください。

前提条件

CDB全体を変更するには、次の前提条件を満たしている必要があります。

  • 現在のユーザーは、ALTER DATABASE権限を持つ共通ユーザーである必要があります。

  • recovery_clauseを含むALTER DATABASE文を実行するには、現在のユーザーにSYSDBA管理権限が共通に付与されている必要があります。この場合、接続時にAS SYSDBAを使用して、この権限を行使する必要があります。

CDB全体を変更するには:

  1. SQL*Plusで、現在のコンテナがルートであることを確認します。

  2. CDB全体を変更する句を含むALTER DATABASE文を使用します。

例15-13 CDBの制御ファイルのバックアップ

次のALTER DATABASE文では、recovery_clauseを使用して制御ファイルをバックアップします。 

ALTER DATABASE BACKUP CONTROLFILE TO '+DATA/dbs/backup/control.bkp';

例15-14 CDBへのREDOログ・ファイルの追加

次のALTER DATABASE文では、logfile_clauseを使用してREDOログ・ファイルを追加します。 

ALTER DATABASE cdb ADD LOGFILE
  GROUP 4 ('/u01/logs/orcl/redo04a.log','/u02/logs/orcl/redo04b.log')
  SIZE 100M BLOCKSIZE 512 REUSE;

関連項目:

Oracle Database SQL言語リファレンス

親トピック: CDBルートへの接続時のコンテナの変更

ALTER DATABASEを使用したCDBのUNDOモードの設定

ローカルUNDOが有効になっている場合、コンテナがオープンされる各インスタンスで、各コンテナに独自のUNDO表領域があります。ローカルUNDOが無効になっている場合は、CDB全体に対して1つのUNDO表領域があります。

親トピック: CDBルートへの接続時のコンテナの変更

CDBのUNDOモードについて

各コンテナでローカルUNDOを使用するように、またはCDB全体で共有UNDO(デフォルト)を使用するようにCDBを構成できます。

CDBは、ローカルUNDOモードまたは共有UNDOモードのどちらかで動作します。UNDOモードはCDB全体に適用されます。したがって、すべてのコンテナは共有UNDOまたはローカルUNDOを使用します。

CREATE DATABASE文のENABLE PLUGGABLE DATABASE句で、CDB作成時にCDBのUNDOモードを指定できます。UNDO句を指定しない場合、共有UNDOモードがデフォルトとなります。CDBの作成後にALTER DATABASE文を発行し、CDBを再起動することで、CDBのUNDOモードを変更できます。

現在のCDB UNDOモードを判断するには、CDBルートで次の問合せを実行します。
SELECT PROPERTY_NAME, PROPERTY_VALUE
FROM   DATABASE_PROPERTIES
WHERE  PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';

問合せでPROPERTY_VALUEに対してTRUEが返された場合、CDBはローカルUNDOモードです。そうでない場合、CDBは共有UNDOモードです。

  • ローカルUNDOモードについて
    ローカルUNDOモードは、コンテナがオープンされる各インスタンスで、各コンテナに独自のUNDO表領域があることを意味します。
  • 共有UNDOモードについて
    共有UNDOモードは、シングル・インスタンスCDBに対して1つのアクティブなUNDO表領域のみが存在することを意味します。Oracle RAC CDBの場合、アクティブなUNDO表領域はインスタンスごとに1つ存在します。

親トピック: ALTER DATABASEを使用したCDBのUNDOモードの設定

ローカルUNDOモードについて

ローカルUNDOモードは、コンテナがオープンされる各インスタンスで、各コンテナに独自のUNDO表領域があることを意味します。

このモードでは、Oracle DatabaseはCDB内のすべてのコンテナ用のUNDO表領域を自動的に作成します。Oracle RAC CDBの場合、アクティブなUNDO表領域はローカルUNDOモードの各PDBのインスタンスごとに1つ存在します。

ローカルUNDOモードでは、各コンテナの分離が向上し、コンテナの切断やコンテナに対するポイント・イン・タイム・リカバリの実行など、一部の操作の効率が向上します。またローカルUNDOモードは、PDBの再配置やオープン読取り/書込みモードでのPDBのクローニングなど、いくつかの操作をサポートするために必要です。

CDBがローカルUNDOモードの場合は、次のことが適用されます。

  • 現在のコンテナに対する適切な権限を持つユーザーは、コンテナのUNDO表領域を作成できます。

  • UNDO表領域は、CDB内のすべてのコンテナの静的データ・ディクショナリ・ビューおよび動的パフォーマンス(V$)ビューに表示されます。

関連項目:

必要な権限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください

親トピック: CDBのUNDOモードについて

共有UNDOモードについて

共有UNDOモードは、シングル・インスタンスCDBに対して1つのアクティブなUNDO表領域のみが存在することを意味します。Oracle RAC CDBの場合、アクティブなUNDO表領域はインスタンスごとに1つ存在します。

CDBが共有UNDOモードの場合は、次のことが適用されます。

  • 適切な権限を持ち、現在のコンテナがCDBルートである共通ユーザーのみが、UNDO表領域を作成できます。

  • 現在のコンテナがCDBルートでない場合、UNDO表領域を作成しようとすると失敗し、エラーが返されます。

  • 現在のコンテナがCDBルートである場合、UNDO表領域は静的データ・ディクショナリ・ビューおよび動的パフォーマンス(V$)・ビューに表示されます。現在のコンテナがPDB、アプリケーション・ルートまたはアプリケーションPDBである場合、UNDO表領域は動的パフォーマンス・ビューにのみ表示されます。

ノート:

  • CDBのUNDOモードを変更した場合、新しいUNDOモードは変更後にコンテナが初めてオープンされたときに個別のコンテナに適用されます。

  • CDBのUNDOモードを変更した場合、CDB内のコンテナは変更前の時間またはSCNにフラッシュ・バックできません。

ローカルUNDOモードを使用するようにCDBを構成する方法

ALTER DATABASE LOCAL UNDO ON文を発行し、データベースを再起動することによって、CDBをローカルUNDOモードに変更できます。

CDBがローカルUNDOモードである場合、コンテナがオープンされる各インスタンスで、各コンテナに独自のUNDO表領域があります。Oracle Databaseは、UNDO表領域を持たないCDB内のコンテナにUNDO表領域を自動的に作成します。UNDO表領域のないPDBがローカルUNDOモードを使用するように構成されたCDBにクローニング、再配置または接続される場合、Oracle Databaseは初めてオープンされるときにPDBのUNDO表領域を自動的に作成します。

CDBを共有UNDOモードからローカルUNDOモードに切り替えると、Oracle Databaseによって必要なUNDO表領域が自動的に作成されます。

  1. CDBインスタンスがオープンしている場合は、停止します。
  2. CDBインスタンスをOPEN UPGRADEモードで起動します。たとえば:
    STARTUP UPGRADE
  3. SQL*Plusで、現在のコンテナがCDBルートであることを確認します。たとえば、次のように入力します。
    SHOW CON_NAME

CON_NAME
------------------------------
CDB$ROOT
  4. CDBの現在のUNDOモードを問い合せます。
    SELECT PROPERTY_NAME, PROPERTY_VALUE 
FROM   DATABASE_PROPERTIES 
WHERE  PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';
  5. ローカルUNDOを有効にするには、次のSQL文を発行します。
    ALTER DATABASE LOCAL UNDO ON;
  6. CDBインスタンスを停止し、再起動します。
  7. オプション: PDBシードにUNDO表領域を手動で作成します。
    Oracle DatabaseはローカルUNDOモードでPDBシードにUNDO表領域を自動的に作成しますが、UNDO表領域を手動で作成することによって、UNDO表領域のサイズおよび構成を制御する場合があります。PDBシードから作成されるPDBが、自動作成されたUNDO表領域ではなく手動で作成したUNDO表領域を使用するようにするには、UNDO_TABLESPACE初期化パラメータに手動で作成したUNDO表領域を設定するか、自動作成されたUNDO表領域を削除する必要があります。
    1. SQL*Plusで、現在のコンテナがルートであることを確認します。
    2. PDBシードを読取り/書込みオープン・モードにします。
      ALTER PLUGGABLE DATABASE PDB$SEED OPEN READ WRITE FORCE;
    3. コンテナをPDBシードに切り替えます。
      ALTER SESSION SET CONTAINER=PDB$SEED;
    4. PDBシードにUNDO表領域を作成します。たとえば:
      CREATE UNDO TABLESPACE seedundots1
   DATAFILE 'seedundotbs_1a.dbf'
   SIZE 10M AUTOEXTEND ON
   RETENTION GUARANTEE;
    5. コンテナをルートに切り替えます。
      ALTER SESSION SET CONTAINER=CDB$ROOT;
    6. PDBシードを読取り専用オープン・モードにします。
      ALTER PLUGGABLE DATABASE PDB$SEED OPEN READ ONLY FORCE;
共有UNDOモードを使用するようにCDBを構成する方法

共有UNDOモードを使用するようにCDBを変更するには、ALTER DATABASE LOCAL UNDO OFF文を使用します。

  1. CDBインスタンスがオープンしている場合は、停止します。
  2. CDBインスタンスをOPEN UPGRADEモードで起動します。たとえば:
    STARTUP UPGRADE
  3. SQL*Plusで、現在のコンテナがCDBルートであることを確認します。たとえば、次のように入力します。
    SHOW CON_NAME

CON_NAME
------------------------------
CDB$ROOT
  4. 必要に応じて、CDBの現在のUNDOモードを問い合せます。
    SELECT PROPERTY_NAME, PROPERTY_VALUE 
FROM   DATABASE_PROPERTIES 
WHERE  PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';
  5. ローカルUNDOをオフにするには、次のSQL文を発行します。
    ALTER DATABASE LOCAL UNDO OFF;
  6. CDBインスタンスを停止し、再起動します。
共有UNDOモードの場合、CDBはローカルUNDOモードのときに作成されたローカルUNDO表領域を無視します。使用しないローカルUNDO表領域を削除することをお薦めします。

ALTER DATABASEを使用したCDBルートの変更

CDBのルートのみを変更するには、ALTER DATABASE文を使用します。

現在のコンテナがルートである場合、一部のALTER DATABASE文を使用すると、PDBのいずれかを直接変更することなくルートが変更されます。これらの文のリストは、表15-3の「ルートのみの変更」列を参照してください。

一部の文は、CDB内のPDBにデフォルトを設定します。PDBのこれらのデフォルトを上書きするには、ALTER PLUGGABLE DATABASE文を使用します。

前提条件

ルートを変更するには、現在のユーザーにルートでのALTER DATABASE権限が必要です。

ルートを変更するには:

  1. SQL*Plusで、現在のコンテナがルートであることを確認します。

  2. ルートを変更する句を含むALTER DATABASE文を実行します。

次の例では、ルートが変更されています。

現在のコンテナがルートであり、表領域を明示的に割り当てられていないユーザーは、ルートのデフォルト表領域を使用します。ALTER DATABASE文で指定された表領域は、ルートに存在している必要があります。

この文を実行すると、これ以降にルートで作成される表領域のデフォルトタイプはbigfileになります。この設定はPDBのデフォルトでもあります。

ALTER DATABASE文で指定された表領域または表領域グループは、ルートに存在している必要があります。

例15-15 ルートのデフォルト表領域の変更

このALTER DATABASE文では、DEFAULT TABLESPACE句を使用して、ルートのデフォルト表領域をroot_tbsに設定します。 

ALTER DATABASE DEFAULT TABLESPACE root_tbs;

例15-16 ルートのデータファイルのオンライン化

このALTER DATABASE文では、database_file_clauseを使用して、/u02/oracle/cdb_01.dbfデータファイルをオンライン化します。 

ALTER DATABASE DATAFILE '/u02/oracle/cdb_01.dbf' ONLINE;

例15-17 ルートのデフォルト表領域タイプの変更

このALTER DATABASE文では、SET DEFAULT TABLESPACE句を使用して、ルートのデフォルト表領域タイプをbigfileに変更します。 

ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE;

例15-18 ルートのデフォルト一時表領域の変更

このALTER DATABASE文では、DEFAULT TEMPORARY TABLESPACE句を使用して、ルートのデフォルト一時表領域をroot_tempに設定します。 

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE root_temp;

関連項目:

親トピック: CDBルートへの接続時のコンテナの変更

別のコンテナでのSQLの実行

別のコンテナでSQLを実行するには、DMLのCONTAINERS句、またはDDLのCONTAINER句を使用します。

親トピック: CDBの管理

CDB内のコンテナに対するDML文の発行

CDBまたはアプリケーション・ルートで発行されるDML (データ操作言語)文では、CDB内の別のコンテナを変更できます。また、DML文に対してデフォルト・コンテナ・ターゲットを指定できます。

親トピック: 別のコンテナでのSQLの実行

CDB内のコンテナに対するDML文の発行について

DML文は、CDB内の指定したコンテナ内のデータベース・オブジェクトに影響することがあります。

コンテナはコンテナIDによって指定されます。コンテナIDは複数の場所に表示されることがあるため、データベースでは次の優先順位が使用されます。

  1. DML文のWHERE句に指定されたCON_ID

  2. CONTAINERS_DEFAULT_TARGETデータベース・プロパティ

  3. 現在のコンテナ(CDBルートまたはアプリケーション・ルートのいずれか)

CDBルートまたはアプリケーション・ルートで、CONTAINERS句を含むDML文は、CDBまたはアプリケーション・コンテナ内の単一コンテナ内の表またはビューを変更できます。CONTAINERS句を使用するには、変更される表またはビューをCONTAINERS句に指定し、影響を受けるコンテナIDをWHERE句に指定します。

INSERT VALUES文でターゲット・コンテナを指定するには、VALUES句にCON_ID値を指定します。また、UPDATE文またはDELETE文でターゲット・コンテナを指定するには、WHERE句にCON_ID述語を指定します。たとえば、次のDML文はコンテナ内のsales.customers表を7のCON_IDで更新します。
UPDATE CONTAINERS(sales.customers) ctab 
   SET ctab.city_name='MIAMI' 
   WHERE ctab.CON_ID=7 
   AND CUSTOMER_ID=3425;

CONTAINERS句には、次の制限事項が適用されます。

  • 指定したスキーマは、CON_IDで指定されたコンテナ、および文が実行されるCDBまたはアプリケーション・ルートの両方に存在する必要があります。

  • WHERE句のCON_IDに指定する値は、CDB内のPDB、アプリケーション・ルートまたはアプリケーションPDBを参照する必要があります。

  • INSERTのターゲットがCONTAINERS()内にあるSELECT文を使用したINSERT文はサポートされません。

  • INSERTのターゲットがCONTAINERS()内にある、複数表に対するINSERT文はサポートされません。

  • CONTAINERS句を使用するDML文では、データベース・リスナーがTCP (IPCではなく)を使用して構成され、PORT値およびHOST値がPORT句およびHOST句を使用して各ターゲットPDBに指定されている必要があります。

CDBにおけるDML文のデフォルト・コンテナの指定

CDB内のDML文のデフォルト・コンテナを指定するには、CONTAINERS DEFAULT TARGET句を指定したALTER DATABASE文を発行します。

WHERE句でコンテナを指定せずにDML文がCDBルートで発行されている場合、DML文はCDBのデフォルト・コンテナに影響します。デフォルト・コンテナには、CDBルート、PDB、アプリケーション・ルートまたはアプリケーションPDBを含む、CDB内の任意のコンテナを指定できます。1つのデフォルトのコンテナのみを使用できます。

CONTAINERS_DEFAULT_TARGETデータベース・プロパティは、デフォルト・コンテナを設定します。デフォルトでは、このプロパティは設定されていません。次の問合せを実行することで、CDBのデフォルト・ターゲット・コンテナを決定できます。
SELECT PROPERTY_VALUE 
FROM   DATABASE_PROPERTIES 
WHERE  PROPERTY_NAME='CONTAINERS_DEFAULT_TARGET';
  1. SQL*Plusで、現在のコンテナがCDBルートまたはアプリケーション・ルートであることを確認します。
    現在のユーザーには、ALTER DATABASE権限が共通して付与されている必要があります。
  2. CONTAINERS DEFAULT TARGET句を指定してALTER DATABASE文を実行します。

例15-19 CDB内のDML文のデフォルト・コンテナの指定

この例では、PDB1がCDB内のDML文のデフォルト・コンテナであることを指定します。 

ALTER DATABASE CONTAINERS DEFAULT TARGET = (PDB1);

例15-20 デフォルト・コンテナのクリア

この例は、デフォルト・コンテナ設定をクリアしています。設定されていない場合、デフォルト・コンテナはCDBルートです。

ALTER DATABASE CONTAINERS DEFAULT TARGET = NONE;

CDBでのDDL文の実行

CDBでは、現在のコンテナまたはすべてのコンテナでデータ定義言語(DDL)文を実行できます。

親トピック: 別のコンテナでのSQLの実行

CDBにおけるDDL文の実行について

CDBでは、DDL文をすべてのコンテナに適用できる場合も、現在のコンテナにのみ適用できる場合もあります。

影響を受けるコンテナを指定するには、CONTAINER句を使用します。 

CONTAINER = { CURRENT | ALL }

次の設定を使用できます。

  • CURRENTは、文は現在のコンテナのみに適用されることを意味します。

  • ALLは、ルートおよびすべてのPDBを含むCDB内のすべてのコンテナに文が適用されることを意味します。

DDL文のCONTAINER句には、次の制限があります。

表15-4 CDBでのDDL文およびCONTAINER句

DDL文 CONTAINER = CURRENT CONTAINER = ALL

CREATE USER

現在のPDBにローカル・ユーザーを作成します。

共通ユーザーを作成します。

ALTER USER

現在のPDBのローカル・ユーザーを変更します。

共通ユーザーを変更します。

CREATE ROLE

現在のPDBにローカル・ロールを作成します。

共通ロールを作成します。

GRANT

ローカル・コンテナでの権限をローカル・ユーザー、共通ユーザーまたはローカル・ロールに付与します。

SET CONTAINER権限を、現在のPDBでユーザーが作成した共通ユーザーに付与できます。

共通オブジェクトに対するシステム権限またはオブジェクト権限を、共通ユーザーまたは共通ロールに付与します。指定された権限は、CDB全体にわたってユーザーまたはロールに付与されます。

REVOKE

ローカル・コンテナでの権限をローカル・ユーザー、共通ユーザーまたはローカル・ロールから取り消します。

この文では、ローカル・コンテナの指定されたユーザーまたはロールから、CONTAINER句にCURRENTを指定して付与された権限のみを取り消すことができます。この文は、CONTAINER句にALLを指定して付与された権限には影響しません。

SET CONTAINER権限を、現在のPDBでユーザーが作成した共通ユーザーから取り消すことができます。

共通オブジェクトに対するシステム権限またはオブジェクト権限を、共通ユーザーまたは共通ロールから取り消します。指定された権限は、CDB全体にわたってユーザーまたはロールから取り消されます。

この文では、指定された共通ユーザーまたは共通ロールから、CONTAINER句にALLを指定して付与された権限のみを取り消すことができます。この文は、CONTAINER句にCURRENTを指定して付与された権限には影響しません。ただし、取消し対象の共通付与権限に依存するローカル付与権限も取り消されます。

他のすべてのDDL文は、現在のコンテナにのみ適用されます。

ユーザー、ロールおよびプロファイルの名前の通常のルールに加えて、CDBでユーザー、ロールまたはプロファイルを作成する場合には、次のルールおよびベスト・プラクティスが適用されます。

  • 共通のユーザー、ロールおよびプロファイルの名前のベスト・プラクティスは、共通のユーザー、ロールおよびプロファイルとローカルのユーザー、ロールおよびプロファイルの間に名前の競合が発生しないように、接頭辞で開始することです。この接頭辞は、CDBルートでCOMMON_USER_PREFIX初期化パラメータを使用して指定します。デフォルトでは、CDBルートでの接頭辞はC##またはc##です。

  • アプリケーション・コンテナでの共通ユーザー、ロールおよびプロファイルの名前のベスト・プラクティスは、アプリケーションの共通ユーザー、ロールおよびプロファイルとローカルのユーザー、ロールおよびプロファイルとの間に名前の競合が発生しないように接頭辞で開始することです。この接頭辞は、アプリケーション・ルートでCOMMON_USER_PREFIX初期化パラメータを使用して指定します。デフォルトでは、アプリケーション・ルートでの接頭辞はNULLです。

  • COMMON_USER_PREFIX初期化パラメータがアプリケーション・ルートで設定されている場合、設定はアプリケーション・コンテナ内のアプリケーション共通ユーザー、ロールおよびプロファイルの名前に適用されます。接頭辞はCDBルートとアプリケーション・ルートで異なる場合があり、各アプリケーション・コンテナでも異なる場合があります。

  • 共通のユーザー、ロールおよびプロファイルの名前は、ASCII文字のみで構成する必要があります。この制限は、アプリケーションの共通のユーザー、ロールおよびプロファイルの名前には適用されません。

  • ローカルのユーザー、ロールおよびプロファイルの名前は、COMMON_USER_PREFIX初期化パラメータで共通ユーザーに指定した接頭辞で始めることができません。

  • ローカルのユーザー、ロールおよびプロファイルの名前は、C##またはc##で始めないでください。

  • CDBルートのCOMMON_USER_PREFIXの値に関係なく、アプリケーションの共通ユーザー、ロールおよびプロファイルの名前をC##またはc##で開始することはできません。

  • アプリケーションの共通ユーザー、ロールおよびプロファイルの名前は、COMMON_USER_PREFIX初期化パラメータで共通ユーザーに指定した接頭辞で始めることができません。

関連項目:

親トピック: CDBでのDDL文の実行

現在のコンテナにおけるDDL文の実行

DDL文のCONTAINER句にCURRENTを指定して、現在のコンテナで文を実行します。

サポートされるDDL文を表15-4に示します。

現在のユーザーは、現在のコンテナでDDL文を実行するために必要な権限を付与されている必要があります。たとえば、ユーザーを作成するには、現在のユーザーに現在のコンテナでのCREATE USERシステム権限が付与されている必要があります。

現在のコンテナでDDL文を実行するには:

  1. SQL*Plusでコンテナにアクセスします。

    「SQL*Plusを使用したCDB内のコンテナへのアクセス」を参照してください。

  2. CONTAINERがCURRENTに設定されたDDL文を実行します。

ローカル・ユーザーのユーザー名は、COMMON_USER_PREFIX初期化パラメータで指定した接頭辞で始めることができません。デフォルトでは、CDBルートでは接頭辞はC##またはc##です。アプリケーション・ルートでは、アプリケーション・コンテナに独自の接頭辞を指定できます。さらに、共通ユーザーの名前はASCII文字のみで構成する必要があります。指定する表領域は、PDBに存在している必要があります。

例15-21 PDBでのローカル・ユーザーの作成

この例では、現在のPDBにローカル・ユーザーtestpdbを作成します。 

CREATE USER testpdb IDENTIFIED BY password 
   DEFAULT TABLESPACE pdb1_tbs
   QUOTA UNLIMITED ON pdb1_tbs
   CONTAINER = CURRENT;

親トピック: CDBでのDDL文の実行

CDB内のすべてのコンテナにおけるDDL文の実行

DDL文のCONTAINER句にALLを指定して、CDB内のすべてのコンテナで文を実行します。

サポートされるDDL文を表15-4に示します。

次の前提条件を満たしている必要があります。

  • 現在のユーザーは共通ユーザーである必要があります。

  • 現在のユーザーは、DDL文を実行するために必要な権限を共通に付与されている必要があります。たとえば、ユーザーを作成するには、現在のユーザーには共通でCREATE USERシステム権限を付与する必要があります。

CDB内のすべてのコンテナでDDL文を実行するには:

  1. SQL*Plusで、現在のコンテナがルートであることを確認します。

    「CDB内のコンテナへのアクセスについて」を参照してください。

  2. CONTAINERがALLに設定されたDDL文を実行します。

共通ユーザーのユーザー名は、COMMON_USER_PREFIX初期化パラメータで指定した接頭辞で始める必要があります。デフォルトでは、CDBルートでは接頭辞はC##またはc##です。アプリケーション・ルートでは、アプリケーション・コンテナに独自の接頭辞を指定できます。さらに、共通ユーザーの名前はASCII文字のみで構成する必要があります。指定する表領域は、ルートおよびすべてのPDBに存在している必要があります。

例15-22 CDBでの共通ユーザーの作成

この例では、共通ユーザーc##testcdbを作成します。 

CREATE USER c##testcdb IDENTIFIED BY password 
   DEFAULT TABLESPACE cdb_tbs
   QUOTA UNLIMITED ON cdb_tbs
   CONTAINER = ALL;

親トピック: CDBでのDDL文の実行

CDBでのオラクル社が提供するSQLスクリプトの実行

catcon.plスクリプトを使用して、Oracleが提供するSQLまたはSQLスクリプトをCDB内で実行できます。スクリプトは、指定した任意のコンテナに対して実行できます。

親トピック: 別のコンテナでのSQLの実行

CDBでのオラクル社が提供するSQLスクリプトの実行について

CDBでは、SQLスクリプトおよびSQL文を実行する場合、catcon.plスクリプトが最良の方法となります。

Oracle Databaseインストールには、複数のSQLスクリプトが含まれています。これらのスクリプトにより、データ・ディクショナリ・ビューの作成やオプションのインストールなどの操作が実行されます。

catcon.plスクリプトは、ルートおよび指定したPDBでスクリプトを正しい順序で実行でき、SQLスクリプトまたはSQL文で予期しないエラーが生成されなかったことを確認するために表示できるログ・ファイルを生成します。また、これにより、複数のプロセスが開始され、それらのプロセスが、事前に割り当てられたスクリプトの実行を完了すると、新しいスクリプトがプロセスに割り当てられます。

ノート:

catcon.plを実行するときにPDBシードを除外しないかぎり、SQLスクリプトまたはSQL文はPDBシード上で実行されます。

catcon.plの構文およびパラメータ

catcon.plスクリプトはPerlスクリプトであり、オペレーティング・システムのプロンプトで実行される必要があります。

catcon.plスクリプトには、次の構文およびパラメータが含まれています。 

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl  
[--usr username[/password]] 
[--int_usr username[/password]] 
[--script_dir directory] 
[--log_dir directory] 
[{--incl_con|--excl_con} container] 
[--echo] 
[--spool] 
[--error_logging { ON | errorlogging-table-other-than-SPERRORLOG } ] 
[--app_con application_root] 
[--no_set_errlog_ident] 
[--diag] 
[-ignore_unavailable_pdbs] 
[--verbose] 
[--force_pdb_mode pdb_mode] 
[--num_procs number]
[--user_scripts]
[--recover] 
--log_file_base log_file_name_base 
-- { SQL_script [arguments] | --x'SQL_statement' }

--x SQL_statementは、1文字のパラメータが続く場合、前に--を付けます。--x SQL_statementの前にスクリプト名または別の--x SQL_statementを指定する場合、前の--は付けません。また、SQL文は一重引用符で囲む必要があります。

SQLスクリプトにコマンドライン・パラメータは、--pを使用して導入します。SQLスクリプトに対話型(シークレット)パラメータは、--Pを使用して導入します。

catcon.plスクリプトのヘルプを表示するには、ディレクトリを$ORACLE_HOME/perl/bin/に変更してから、次のコマンドを実行します。 

perl $ORACLE_HOME/rdbms/admin/catcon.pl --help

次の表は、catcon.plパラメータの説明です。必須と指定されていないかぎり、パラメータはオプションです。

次の表に示す短いパラメータ名は、下位互換性があります。短縮名がないパラメータもあります。

表15-5 catcon.plパラメータ

パラメータ 短縮名 説明

--usr

-u

ルートおよび指定されたPDBに接続するユーザー名およびパスワードを指定します。SQLスクリプトまたはSQL文を実行するために必要な権限を持つ共通ユーザーを指定します。デフォルトは/ AS SYSDBAです。パスワードを入力しないと、catcon.plによってパスワードが求められます。

--int_usr

-U

ルートおよび指定されたPDBに接続するユーザー名およびパスワードを指定します。CDBメタデータを問い合せるなどの内部タスクを実行する場合は、必要な権限を持つ共通ユーザーを指定します。デフォルトは、/ AS SYSDBAです。パスワードを入力しないと、catcon.plによってパスワードが求められます。

--script_dir

-d

SQLスクリプトを含むディレクトリ。デフォルトは、現行のディレクトリです。

--log_dir

-l

catcon.plによってログ・ファイルが書き込まれるディレクトリ。デフォルトは、現行のディレクトリです。

{--incl_con|--excl_con}

{-c|-C}

SQLスクリプトを実行するコンテナまたは実行しないコンテナ。

--incl_conパラメータには、SQLスクリプトを実行するコンテナをリストします。

--excl_conパラメータには、SQLスクリプトを実行しないコンテナをリストします。

一重引用符で囲まれたPDB名のスペース区切りリストで、コンテナを指定します。

--incl_conパラメータと--excl_conパラメータは、両方同時には指定できません。

このパラメータを使用する場合、--app_conパラメータは使用できません。

--echo

-e

スクリプト実行時のエコーをONに設定します。デフォルトでのエコーはOFFです。

--spool

-s

すべてのスクリプトの出力を次の名前でファイルにスプーリングします。

log-file-name-base_script-name-without-extension_[container-name-if-any].default-extension

--error_logging

-E

ONに設定されている場合、デフォルトのエラー・ロギング表が使用されます。デフォルト設定はONです。ONに設定されている場合、エラーは、SQLスクリプトを実行する各コンテナの現行スキーマ内の表SPERRORLOGに書き込まれます。この表がコンテナに存在しない場合は、自動的に作成されます。

SPERRORLOG以外の表が指定されている場合、エラーは指定された表に書き込まれます。この表はSQLスクリプトを実行する各コンテナに存在している必要があり、現在のユーザーには、これらのコンテナごとの表にDML操作を実行するために必要な権限がある必要があります。

エラー・ロギング表の詳細は、SQL*Plusユーザーズ・ガイドおよびリファレンスを参照してください。

--app_con

-F

アプリケーション・ルートを指定します。スクリプトは、アプリケーション・ルートと、アプリケーション・ルートにプラグインされるアプリケーションPDBで実行されます。

このパラメータを使用する場合、--incl_conパラメータと--excl_conパラメータは使用できません。

--no_set_errlog_ident

-I

SET ERRORLOGGING識別子を発行しないでください。このオプションは、SET ERRORLOGGING識別子がすでに設定され、上書きしない場合を対象としています。

--diag

-g

デバッグ情報の生成をオンにします。

--verbose

-v

冗長出力をオンにします

--ignore_unavailable_pdbs

-f

クローズされているPDBあるいは--incl_conまたは--excl_conオプションを使用している場合は存在しないPDBを無視し、明示的または暗黙的に指定したオープンPDBのみを処理します。

このオプションを指定せず、指定されたPDBの一部が存在しなかったり、オープンされていない場合、エラーが返されてコンテナは処理されません。

--force_pdb_mode

該当なし

スクリプトを実行する対象のPDBすべてに必要なオープン・モード。次のいずれかの値を指定します。

  • UNCHANGED

  • READ WRITE

  • READ ONLY

  • UPGRADE

  • DOWNGRADE

UNCHANGED以外の値を指定した場合、スクリプトを実行する対象のPDBはすべて、指定したオープン・モードに変更されます。PDBが異なるモードでオープンされている場合、PDBはクローズされ、指定したモードで再オープンされます。スクリプトがすべて実行されると、PDBは元のオープン・モードにリストアされます。

デフォルトのUNCHANGEDを指定した場合、PDBのオープン・モードは変更されません。

--num_procs

-n

コール元から提供された文またはスクリプト(またはその両方)を実行するためにcatcon.plによって生成される、SQL*Plusプロセスの数を指定します。これは、CDB内のPDBの数およびCPU_COUNT初期化パラメータの値に基づいてcatcon.plによって生成される数より優先されます。

--user_scripts

-S

コール元から提供されるすべてのスクリプトまたは文(またはその両方)をCDB$ROOT、PDB$SEEDまたはアプリケーション・ルート・クローンで実行しないことを指定します。スクリプトまたは文(またはその両方)によって作成された表やビューなどのすべてのオブジェクトは、Oracleの保持対象としてマークされません。

--recover

-R

catcon.plによって起動されたSQL*Plusプロセスが予期せず終了した場合に、catcon.plでSQL*Plusプロセスのリカバリを試みます。このパラメータを指定しない場合、catcon.plはプロセスのリカバリを試行せずにクローズします。

--log_file_base

-b

(必須)ログ・ファイル名のベース名。
catcon.plスクリプトの実行

catcon.plスクリプトの実行を例で示します。

catcon.plで実行されるSQLスクリプトまたはSQL文によって、データ操作言語(DML)またはデータ定義言語(DDL)の各操作を実行する場合、変更対象のコンテナは、読取り/書込みモードである必要があります。

catcon.plスクリプトを実行するには:

  1. コマンドライン・プロンプトをオープンします。

  2. catcon.plスクリプトを実行し、1つ以上のSQLスクリプトまたはSQL文を指定します。 

    cd $ORACLE_HOME/perl/bin/
perl $ORACLE_HOME/rdbms/admin/catcon.pl parameters SQL_script
perl $ORACLE_HOME/rdbms/admin/catcon.pl parameters -- --xSQL_statement

例15-23 CDB内のすべてのコンテナにおけるcatblock.sqlスクリプトの実行

次の例では、CDBのすべてのコンテナでcatblock.sqlスクリプトを実行します(バックスラッシュは行の継続を示します)。 

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl \
--usr SYS --script_dir $ORACLE_HOME/rdbms/admin \
--log_file_base catblock_output catblock.sql

次のパラメータが指定されます。

  • --usrパラメータは、SYSユーザーが各コンテナでスクリプトを実行することを指定します。

  • --script_dirパラメータは、SQLスクリプトが$ORACLE_HOME/rdbms/adminディレクトリに存在することを指定します。

  • --log_file_baseパラメータでは、ログ・ファイル名のベース名がcatblock_outputであることを指定します。

デフォルトのパラメータ値は、その他すべてのパラメータに使用されます。--incl_conと--excl_conのいずれのパラメータも指定されていません。したがって、catcon.plにより、デフォルトですべてのコンテナにおいてスクリプトが実行されます。

例15-24 特定のPDBにおけるcatblock.sqlスクリプトの実行

次の例では、CDB内のPDB hrpdbおよびsalespdbで、catblock.sqlスクリプトが実行されます。 

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl \
--usr SYS --int_usr SYS --script_dir $ORACLE_HOME/rdbms/admin \
--log_dir '/disk1/script_output' --incl_con 'HRPDB SALESPDB' \
--log_file_base catblock_output catblock.sql

次のパラメータが指定されます。

  • --usrパラメータは、SYSユーザーが各コンテナでスクリプトを実行することを指定します。

  • --int_usrパラメータは、SYSユーザーが内部タスクを実行することを指定します。

  • --script_dirパラメータは、SQLスクリプトが$ORACLE_HOME/rdbms/adminディレクトリに存在することを指定します。

  • --log_dirパラメータは、出力ファイルが/disk1/script_outputディレクトリに配置されることを指定します。

  • --incl_conパラメータは、SQLスクリプトがPDB hrpdbおよびsalespdbで実行されることを指定します。スクリプトは、CDB内の他のコンテナでは実行されません。

  • --log_file_baseパラメータでは、ログ・ファイル名のベース名がcatblock_outputであることを指定します。

例15-25 特定のPDBを除くすべてのコンテナにおけるcatblock.sqlスクリプトの実行

次の例では、PDB hrpdbおよびsalespdbを除くCDB内のすべてのコンテナで、catblock.sqlスクリプトを実行します。 

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl \
--usr SYS --script_dir $ORACLE_HOME/rdbms/admin \
--log_dir '/disk1/script_output' --excl_con 'HRPDB SALESPDB' \ 
--log_file_base catblock_output catblock.sql

次のパラメータが指定されます。

  • --usrパラメータは、SYSユーザーが各コンテナでスクリプトを実行することを指定します。

  • --script_dirパラメータは、SQLスクリプトが$ORACLE_HOME/rdbms/adminディレクトリに存在することを指定します。

  • --log_dirパラメータは、出力ファイルが/disk1/script_outputディレクトリに配置されることを指定します。

  • --excl_conパラメータは、PDB hrpdbおよびsalespdbを除くCDB内のすべてのコンテナで、SQLスクリプトを実行することを指定します。

  • --log_file_baseパラメータでは、ログ・ファイル名のベース名がcatblock_outputであることを指定します。

例15-26 コマンドライン・パラメータを使用したSQLスクリプトの実行

次の例では、CDB内のすべてのコンテナに対し、custom_script.sqlスクリプトを実行します。 

cd $ORACLE_HOME/perl/bin/
perl $ORACLE_HOME/rdbms/admin/catcon.pl --usr SYS --script_dir /u01/scripts \
--log_file_base custom_script_output custom_script.sql '--phr' \
'--PEnter password for user hr:'

次のパラメータが指定されます。

  • --usrパラメータは、SYSユーザーが各コンテナでスクリプトを実行することを指定します。

  • --script_dirパラメータは、SQLスクリプトが/u01/scriptsディレクトリ内にあることを指定します。

  • --log_file_baseパラメータは、ログ・ファイル名のベース名がcustom_script_outputであることを指定します。

  • --pパラメータは、コマンドライン・パラメータに対してhrを指定します。

  • --Pパラメータは、ユーザーhrのパスワードを求める対話型パラメータを指定します。

デフォルトのパラメータ値は、その他すべてのパラメータに使用されます。-incl_conと-excl_conのいずれのパラメータも指定されていません。したがって、catcon.plにより、デフォルトですべてのコンテナにおいてスクリプトが実行されます。

例15-27 CDB内のすべてのコンテナにおけるSQL文の実行

次の例では、CDBのすべてのコンテナでSQL文を実行します。

cd $ORACLE_HOME/perl/bin/
perl $ORACLE_HOME/rdbms/admin/catcon.pl --usr SYS --echo \
--log_file_base select_output -- --x"SELECT * FROM DUAL"

次のパラメータが指定されます。

  • --usrパラメータは、SYSユーザーが各コンテナでスクリプトを実行することを指定します。

  • --echoパラメータは、SQL文に対する出力を表示します。

  • --log_file_baseパラメータは、ログ・ファイル名のベース名がselect_outputであることを指定します。

  • SQL文SELECT * FROM DUALは引用符で囲まれ、前に--xが付きます。--xの前にはパラメータ(--log_file_base)が指定されているため、--を前に付ける必要があります。

デフォルトのパラメータ値は、その他すべてのパラメータに使用されます。-incl_conと-excl_conのいずれのパラメータも指定されていません。したがって、catcon.plにより、デフォルトですべてのコンテナにおいてSQL文が実行されます。

関連項目:

親トピック: CDBでのオラクル社が提供するSQLスクリプトの実行

DBMS_SQLパッケージを使用したコンテナのコードの実行

CDBのコンテナ内でPL/SQLコードを実行する場合に別のコンテナで1つ以上のSQL文を実行する場合、DBMS_SQLパッケージを使用してコンテナを切り替えます。

たとえば、複数のコンテナで同じアクションを実行する必要がある場合は、DBMS_SQLパッケージを使用してコンテナを切り替えることができます。

コンテナの切替えにDBMS_SQLを使用する場合、次を考慮します。

  • トランザクションを複数のコンテナにわたって実行することはできません。

    ターゲット・コンテナ内で実行する必要のあるアクションのセットがトランザクションである必要がある場合、最終アクションとしてコミットまたはロールバックを行う、自律型のトランザクションの使用を検討します。

  • SET ROLE文は許可されていません。

例15-28 複数のコンテナでの同一のアクションの実行

次の例のPL/SQLブロックは、2つのPDB (pdb1およびpdb2)のhrスキーマにidentact表を作成します。この例では、両方のPDBのidentact表に行も挿入します。 

DECLARE
  c1 INTEGER;
  rowcount INTEGER;
  taskList VARCHAR2(32767) :=
    'DECLARE
      PRAGMA AUTONOMOUS TRANSACTION;
     BEGIN
       -- Create the hr.identact table.
       EXECUTE IMMEDIATE
         ''CREATE TABLE hr.identact
             (actionno NUMBER(4) NOT NULL,
              action VARCHAR2 (10))'';
       EXECUTE IMMEDIATE
         ''INSERT INTO identact VALUES(1, 'ACTION1')'';
       -- A commit is required if the tasks include DML.
       COMMIT;
       EXCEPTION
         WHEN OTHERS THEN
           -- If there are errors, then drop the table.
           BEGIN
             EXECUTE IMMEDIATE ''DROP TABLE identact'';
           EXCEPTION
            WHEN OTHERS THEN
              NULL;
            END;
        END;';
  TYPE containerListType IS TABLE OF VARCHAR2(128) INDEX BY PLS_INTEGER;
  containerList  containerListType;
BEGIN
  containerList(1) := 'PDB1';
  containerList(2) := 'PDB2';
  c1 := DBMS_SQL.OPEN_CURSOR;
  FOR conIndex IN containerList.first..containerList.last LOOP
    DBMS_OUTPUT.PUT_LINE('Creating in container: ' || containerList(conIndex));
    DBMS_SQL.PARSE(
      c => c1 ,
      statement                  => taskList,
      language_flag              => DBMS_SQL.NATIVE,
      edition                    => NULL,
      apply_crossedition_trigger => NULL,
      fire_apply_trigger         => NULL,
      schema                     => 'HR',
      container                  => containerList(conIndex));
     rowcount := DBMS_SQL.EXECUTE(c=>c1);
  END LOOP;
  DBMS_SQL.CLOSE_CURSOR(c=>c1);
END;
/

関連項目:

親トピック: 別のコンテナでのSQLの実行

CDB内のコンテナの監視

CDB、PDBおよびアプリケーション・コンテナに関するメタデータを表示するには、SQL*PlusまたはSQL Developerを使用します。

関連トピック

親トピック: CDBの管理

ビュー内のCDBおよびコンテナの情報について

CDBでは、データ・ディクショナリ表およびビュー定義のメタデータがルートのみに格納されます。

各コンテナ(各PDB、アプリケーション・ルート、アプリケーションPDBを含む)には、そのコンテナに含まれているオブジェクトに関する、独自のデータ・ディクショナリ表とビューのセットがあります。各コンテナには異なるデータ・オブジェクトとスキーマ・オブジェクトを含めることができるため、各コンテナで同じビューを問い合せても、コンテナによってデータ・ディクショナリ・ビューに異なるメタデータが表示される場合があります。たとえば、2つの異なるコンテナでは、DBA_TABLESビューに表示される、表に関するメタデータが異なる場合があり、これは、コンテナごとに異なる表が含まれていることがあるためです。コンテナは、メタデータ・リンクと呼ばれる内部メカニズムを使用して、ルート内のこれらのビューのメタデータにアクセスできます。

ディクショナリ表に、各コンテナではなくCDB全体に関連する情報が格納される場合は、メタデータと、データ・ディクショナリ・ビューに表示されるデータの両方がルートに格納されます。たとえば、自動ワークロード・リポジトリ(AWR)データはルートに格納でき、DBA_HIST_ACTIVE_SESS_HISTORYビューなどの一部のデータ・ディクショナリ・ビューに表示されます。コンテナは、データ・リンクと呼ばれる内部メカニズムを使用して、ルート内のこれらのタイプのビューのメタデータとデータの両方にアクセスできます。

関連項目:

コンテナ、メタデータ・リンクおよびデータ・リンクでのディクショナリ・アクセスの詳細は、『Oracle Database概要』を参照してください

親トピック: CDB内のコンテナの監視

現在のコンテナがCDBルートではない場合の情報の表示について

現在のコンテナがPDB、アプリケーション・ルートまたはアプリケーションPDBの場合、データ・ディクショナリには現在のコンテナのみのメタデータが表示されます。

また、CDBルートではないコンテナでは、CDB_ビューには、対応するDBA_ビューで表示されるデータベース・オブジェクトに関する情報のみが示されます。

現在のコンテナがCDBルートである場合の情報の表示について

現在のコンテナがCDBルートである場合、共通ユーザーは、コンテナ・データ・オブジェクトを問い合せて、CDBルート、PDB、アプリケーション・ルートおよびアプリケーションPDBのデータ・ディクショナリ情報を表示できます。

コンテナ・データ・オブジェクトは、次の内容に関連するデータを含めることができる表またはビューです。

  • 1つ以上のコンテナ

  • CDB全体

  • 1つ以上のコンテナおよびCDB全体

コンテナ・データ・オブジェクトには、V$、GV$、CDB_およびいくつかの自動ワークロード・リポジトリDBA_HIST*のビューが含まれています。共通ユーザーのCONTAINER_DATA属性は、コンテナ・データ・オブジェクトに表示できるコンテナを決定します。

CDBでは、すべてのDBA_ビューに、対応するCDB_ビューがあります。すべてのCDB_ビューはコンテナ・データ・オブジェクトですが、ほとんどのDBA_ビューはそうではありません。

各コンテナ・データ・オブジェクトには、返された各行のコンテナを識別するCON_ID列が含まれています。表15-6では、CON_ID列の値の意味について説明します。

表15-6 コンテナ・データ・オブジェクトのCON_ID列

CON_ID列の値 説明

0

CDB全体に関連するデータ

1

CDBルートに関連するデータ

2

PDBシードに関連するデータ

3 - 4,098

PDB、アプリケーション・ルートまたはアプリケーションPDBに関連するデータ

各コンテナには独自のコンテナIDがあります。

次のビューは、他の[G]V$ビューとは動作が異なります。

  • [G]V$SYSSTAT

  • [G]V$SYS_TIME_MODEL

  • [G]V$SYSTEM_EVENT

  • [G]V$SYSTEM_WAIT_CLASS

CDBルートからの問合せにおいて、これらのビューは、返される各行のCON_ID列に0を含めてインスタンス全体のデータを返します。ただし、他のコンテナ・データ・オブジェクトと同じように動作する同等のビューを問い合せできます。[G]V$CON_SYSSTAT、[G]V$CON_SYS_TIME_MODEL、[G]V$CON_SYSTEM_EVENTおよび[G]V$CON_SYSTEM_WAIT_CLASSの各ビューは、CDB内の各コンテナに固有のデータを返すことができます。

ノート:

  • コンテナ・データ・オブジェクトの問合せにおいて返されるデータは、コンテナがオープンであるかどうか、および問合せを実行するユーザーに付与された権限によって異なります。

  • Oracle Real Application Clusters (Oracle RAC)環境では、コンテナ・データ・オブジェクトによって返されるデータは、セッションの接続先インスタンスによって変わる場合があります。

  • コンテナが制限モードでオープンされている場合は、CDB_ビューに対する問合せで無視されます。

関連項目:

親トピック: ビュー内のCDBおよびコンテナの情報について

CDBのビュー

CDBおよびそのPDBに関する情報をビューのセットに問い合せることができます。

表15-7は、CDBおよびそのPDBの監視に役立つデータ・ディクショナリ・ビューについて説明しています。

表15-7 CDBのビュー

ビュー 説明 詳細情報

次を含むコンテナ・データ・オブジェクト

  • V$ビュー

  • GV$ビュー

  • CDB_ビュー

  • DBA_HIST*ビュー

コンテナ・データ・オブジェクトによって、複数のPDBに関する情報を表示できます。各コンテナ・データ・オブジェクトには、コンテナを識別するためのCON_ID列が含まれています。

対応する各DBA_ビューのCDB_ビューがあります。

「コンテナ・データ・オブジェクトの問合せ」

『Oracle Databaseセキュリティ・ガイド』

{CDB|DBA}_PDBS

各PDBのステータスなど、CDBに関連付けられたPDBに関する情報が表示されます。

「PDBに関する情報の表示」

『Oracle Databaseリファレンス』

CDB_PROPERTIES

CDB内の各コンテナの永続的なプロパティが表示されます。

『Oracle Databaseリファレンス』

{CDB|DBA}_PDB_HISTORY

各PDBの履歴が表示されます。

Oracle Databaseリファレンス

{CDB|DBA}_CONTAINER_DATA

CDBに指定されているユーザー・レベルおよびオブジェクト・レベルのCONTAINER_DATA属性に関する情報が表示されます。

Oracle Databaseリファレンス

{CDB|DBA}_HIST_PDB_INSTANCE

ワークロード・リポジトリのPDBおよびインスタンスが表示されます。

『Oracle Databaseリファレンス』

{CDB|DBA}_PDB_SAVED_STATES

CDBの現在保存されているPDBの状態に関する情報が表示されます。

『Oracle Databaseリファレンス』

「CDB再起動時のPDBのオープン・モードの保持または破棄」

{CDB|DBA}_APPLICATIONS

アプリケーション・コンテナ内のすべてのアプリケーションを記述します。

アプリケーションに関する情報の表示

{CDB|DBA}_APP_STATEMENTS

アプリケーション・コンテナ内でのアプリケーション・インストール、アップグレードおよびパッチ操作からのすべての文を記述します。

アプリケーション文に関する情報の表示

{CDB|DBA}_APP_PATCHES

アプリケーション・コンテナ内のすべてのアプリケーション・パッチを記述します。

アプリケーション・パッチに関する情報の表示

{CDB|DBA}_APP_ERRORS

アプリケーション・コンテナ内に生成されたすべてのアプリケーション・エラー・メッセージを記述します。

アプリケーション・エラーに関する情報の表示

{CDB|DBA}_CDB_RSRC_PLANS

すべてのCDBリソース・プランに関する情報が表示されます。

『Oracle Databaseリファレンス』

{CDB|DBA}_CDB_RSRC_PLAN_DIRECTIVES

すべてのCDBリソース・プラン・ディレクティブに関する情報が表示されます。

『Oracle Databaseリファレンス』

PDB_ALERTS

PDBアラートの理由の説明が示されます。

『Oracle Databaseリファレンス』

PDB_PLUG_IN_VIOLATIONS

PDBと、それが属するCDB間の非互換性に関する情報が表示されます。このビューは、DBMS_PDB.CHECK_PLUG_COMPATIBILITYを実行して生成される情報を表示するためにも使用されます。

『Oracle Databaseリファレンス』

「切断されたPDBの接続」

{USER|ALL|DBA|CDB}_OBJECTS

データベース・オブジェクトに関する情報が表示され、SHARING列に、データベース・オブジェクトがメタデータ・リンク・オブジェクト、データ・リンク・オブジェクト、拡張データ・リンク・オブジェクト、または別のオブジェクトにリンクされていないスタンドアロン・オブジェクトのいずれであるかが示されます。

『Oracle Databaseリファレンス』

{ALL|DBA|CDB}_SERVICES

データベース・サービスに関する情報が表示され、PDB列に、各サービスに関連付けられているPDBの名前が示されます。

『Oracle Databaseリファレンス』

{USER|ALL|DBA|CDB}_VIEWS

{USER|ALL|DBA|CDB}_TABLES

CONTAINER_DATA列に、ビューまたは表がコンテナ・データ・オブジェクトであるかどうかが示されます。

『Oracle Databaseリファレンス』

{USER|ALL|DBA|CDB}_USERS

COMMON列に、ユーザーが共通ユーザーであるかローカル・ユーザーであるかが示されます。

『Oracle Databaseリファレンス』

{USER|ALL|DBA|CDB}_ROLES

{USER|ALL|DBA|CDB}_COL_PRIVS

{USER|ALL}_COL_PRIVS_MADE

{USER|ALL}_COL_PRIVS_RECD

{USER|ALL}_TAB_PRIVS_MADE

{USER|ALL}_TAB_PRIVS_RECD

{USER|DBA|CDB}_SYS_PRIVS

{USER|DBA|CDB}_ROLE_PRIVS

ROLE_TAB_PRIVS

ROLE_SYS_PRIVS

COMMON列に、ロールまたは権限が共通に付与されているか、またはローカルに付与されているかが示されます。

『Oracle Databaseリファレンス』

{USER|ALL|DBA|CDB}_ARGUMENTS

{USER|ALL|DBA|CDB}_CLUSTERS

{USER|ALL|DBA|CDB}_CONSTRAINTS

{ALL|DBA|CDB}_DIRECTORIES

{USER|ALL|DBA|CDB}_IDENTIFIERS

{USER|ALL|DBA|CDB}_LIBRARIES

{USER|ALL|DBA|CDB}_PROCEDURES

{USER|ALL|DBA|CDB}_SOURCE

{USER|ALL|DBA|CDB}_SYNONYMS

{USER|ALL|DBA|CDB}_VIEWS

ORIGIN_CON_ID列は、行の元のコンテナIDを示します。

『Oracle Databaseリファレンス』

[G]V$DATABASE

制御ファイルからの、データベースに関する情報が表示されます。データベースがCDBである場合は、CDB関連の情報が含まれます。

『Oracle Databaseリファレンス』

[G]V$CONTAINERS

ルートおよびすべてのPDBを含む、現在のCDBに関連付けられているコンテナに関する情報が表示されます。

「CDB内のコンテナに関する情報の表示」

『Oracle Databaseリファレンス』

[G]V$PDBS

各PDBのオープン・モードなど、現在のCDBに関連付けられているPDBに関する情報が表示されます。

「各PDBのオープン・モードの表示」

『Oracle Databaseリファレンス』

[G]V$PDB_INCARNATION

すべてのPDBインカネーションに関する情報を示します。RESETLOGSオプションを指定してPDBをオープンすると、新規のPDBインカネーションが作成されます。

『Oracle Databaseリファレンス』

[G]V$SYSTEM_PARAMETER

[G]V$PARAMETER

初期化パラメータに関する情報が表示され、ISPDB_MODIFIABLE列にPDBのパラメータを変更できるかどうかが示されます。

「PDBの変更可能な初期化パラメータをリスト」

『Oracle Databaseリファレンス』

V$DIAG_ALERT_EXT

[G]V$DIAG_APP_TRACE_FILE

[G]V$DIAG_OPT_TRACE_RECORDS

V$DIAG_SESS_OPT_TRACE_RECORDS

V$DIAG_SESS_SQL_TRACE_RECORDS

[G]V$DIAG_SQL_TRACE_RECORDS

[G]V$DIAG_TRACE_FILE

[G]V$DIAG_TRACE_FILE_CONTENTS

CDBの現在のコンテナのトレース・ファイルおよびアラート・ファイルのデータを表示します。

Oracle Database SQLチューニング・ガイド

V$DIAG_INCIDENT

V$DIAG_PROBLEM

CDB内の現在のコンテナの問題およびインシデントに関する情報を表示します。

『Oracle Databaseリファレンス』

CDB内のコンテナに関する情報の表示

V$CONTAINERSビューは、ルートおよびすべてのPDBを含む、CDB内のすべてのコンテナに関する情報を提供します。

この情報を表示するには、現在のコンテナがルートである共通ユーザーが問合せを実行する必要があります。現在のコンテナがPDBである場合、このビューには現在のPDBに関する情報のみが表示されます。

CDB内のコンテナに関する情報を表示するには:

  1. SQL*Plusで、現在のコンテナがルートであることを確認します。

    「CDB内のコンテナへのアクセスについて」を参照してください。

  2. V$CONTAINERSビューを問い合せます。

例15-29 CDB内の各コンテナに関する識別情報の表示

COLUMN NAME FORMAT A8

SELECT NAME, CON_ID, DBID, CON_UID, GUID FROM V$CONTAINERS ORDER BY CON_ID;

出力例:

NAME         CON_ID       DBID    CON_UID GUID
-------- ---------- ---------- ---------- --------------------------------
CDB$ROOT          1  659189539          1 C091A6F89C7572A1E0436797E40AC78D
PDB$SEED          2 4026479912 4026479912 C091AE9C00377591E0436797E40AC138
HRPDB             3 3718888687 3718888687 C091B6B3B53E7834E0436797E40A9040
SALESPDB          4 2228741407 2228741407 C091FA64EF8F0577E0436797E40ABE9F

関連項目:

親トピック: CDB内のコンテナの監視

PDBに関する情報の表示

CDB_PDBSビューおよびDBA_PDBSビューは、各PDBのステータスなど、CDBに関連付けられたPDBに関する情報を提供します。

この情報を表示するには、現在のコンテナがルートである共通ユーザーが問合せを実行する必要があります。現在のコンテナがPDBである場合は、これらのビューに対するすべての問合せで結果が返されません。

PDBに関する情報を表示するには:

  1. SQL*Plusで、現在のコンテナがルートであることを確認します。

    「SQL*Plusを使用したCDB内のコンテナへのアクセス」を参照してください。

  2. CDB_PDBSまたはDBA_PDBSビューを問い合せます。

例15-30 各PDBのコンテナID、名前およびステータスの表示

COLUMN PDB_NAME FORMAT A15
 
SELECT PDB_ID, PDB_NAME, STATUS FROM DBA_PDBS ORDER BY PDB_ID;

出力例:

    PDB_ID PDB_NAME        STATUS
---------- --------------- -------------
         2 PDB$SEED        NORMAL
         3 HRPDB           NORMAL
         4 SALESPDB        NORMAL

関連項目:

「現在のコンテナについて」

親トピック: CDB内のコンテナの監視

各PDBのオープン・モードの表示

V$PDBSビューは、現在のデータベース・インスタンスに関連付けられたPDBに関する情報を提供します。

このビューを問い合せて、各PDBのオープン・モードを判断します。オープンしている各PDBについて、このビューでは、PDBが最後にオープンされたかのがいつであるかを表示することもできます。共通ユーザーは、現在のコンテナがルートまたはPDBである場合にこのビューを問い合せることができます。現在のコンテナがPDBである場合、このビューには現在のPDBに関する情報のみが表示されます。

各PDBのオープン・ステータスを表示するには:

  1. SQL*Plusでコンテナにアクセスします。

    「SQL*Plusを使用したCDB内のコンテナへのアクセス」を参照してください。

  2. V$PDBSビューを問い合せます。

例15-31 各PDBの名前およびオープン・モードの表示

COLUMN NAME FORMAT A15
COLUMN RESTRICTED FORMAT A10
COLUMN OPEN_TIME FORMAT A30
 
SELECT NAME, OPEN_MODE, RESTRICTED, OPEN_TIME FROM V$PDBS;

出力例:

NAME            OPEN_MODE  RESTRICTED OPEN_TIME
--------------- ---------- ---------- ------------------------------
PDB$SEED        READ ONLY  NO         21-MAY-12 12.19.54.465 PM
HRPDB           READ WRITE NO         21-MAY-12 12.34.05.078 PM
SALESPDB        MOUNTED    NO         22-MAY-12 10.37.20.534 AM

関連項目:

親トピック: CDB内のコンテナの監視

コンテナ・データ・オブジェクトの問合せ

ルートでは、コンテナ・データ・オブジェクトは、ルートおよびそのPDBに含まれるデータベース・オブジェクト(表やユーザーなど)に関する情報を表示できます。PDB情報へのアクセスは、共通ユーザーのCONTAINER_DATA属性によって制御されます。

たとえば、CDB_ビューはコンテナ・データ・オブジェクトです。コンテナ・データ・オブジェクトの詳細は、「現在のコンテナがCDBルートである場合の情報の表示について」および『Oracle Databaseセキュリティ・ガイド』を参照してください。

各コンテナ・データ・オブジェクトには、問合せ結果内の各PDBのコンテナIDが表示されたCON_ID列が含まれています。DBA_PDBSビューを問い合せて、コンテナIDのPDB名を表示できます。

コンテナ・データ・オブジェクトを使用して複数のPDBに関する情報を表示するには:

  1. SQL*Plusで、現在のコンテナがルートであることを確認します。

    「CDB内のコンテナへのアクセスについて」を参照してください。

  2. コンテナ・データ・オブジェクトを問い合せて、目的の情報を表示します。

ノート:

問合せにコンテナ・データ・オブジェクトおよび非コンテナ・データ・オブジェクトの結合が含まれ、現在のコンテナがルートである場合、問合せはCDB全体のデータのみを返します(CON_ID = 0)。

例15-32 複数のPDBの特定のスキーマが所有する表の表示

この例では、ルートからDBA_PDBSビューおよびCDB_TABLESビューを問い合せて、CDBに関連付けられているPDBのhrユーザーおよびoeユーザーが所有する表を表示します。この問合せは、PDBのIDが2より大きい(p.PDB_ID > 2)行のみを返すことで、CDBルートおよびPDBシードのユーザーを表示しないようにしています。 

COLUMN PDB_NAME FORMAT A15
COLUMN OWNER FORMAT A15
COLUMN TABLE_NAME FORMAT A30
 
SELECT p.PDB_ID, p.PDB_NAME, t.OWNER, t.TABLE_NAME 
  FROM DBA_PDBS p, CDB_TABLES t 
  WHERE p.PDB_ID > 2 AND
        t.OWNER IN('HR','OE') AND
        p.PDB_ID = t.CON_ID
   ORDER BY p.PDB_ID;

出力例:

    PDB_ID PDB_NAME        OWNER           TABLE_NAME
---------- --------------- --------------- ------------------------------
         3 HRPDB           HR              COUNTRIES
         3 HRPDB           HR              JOB_HISTORY
         3 HRPDB           HR              EMPLOYEES
         3 HRPDB           HR              JOBS
         3 HRPDB           HR              DEPARTMENTS
         3 HRPDB           HR              LOCATIONS
         3 HRPDB           HR              REGIONS
         4 SALESPDB        OE              PRODUCT_INFORMATION
         4 SALESPDB        OE              INVENTORIES
         4 SALESPDB        OE              ORDERS
         4 SALESPDB        OE              ORDER_ITEMS
         4 SALESPDB        OE              WAREHOUSES
         4 SALESPDB        OE              CUSTOMERS
         4 SALESPDB        OE              SUBCATEGORY_REF_LIST_NESTEDTAB
         4 SALESPDB        OE              PRODUCT_REF_LIST_NESTEDTAB
         4 SALESPDB        OE              PROMOTIONS
         4 SALESPDB        OE              PRODUCT_DESCRIPTIONS

この出力例では、PDB hrpdbにhrスキーマの表があり、PDB salespdbにoeスキーマの表があることを示しています。

例15-33 複数のPDBのユーザーの表示

この例では、ルートからDBA_PDBSビューおよびCDB_USERSビューを問い合せて、各PDBのユーザーを表示します。この問合せでは、p.PDB_ID > 2を使用して、CDBルートおよびPDBシードのユーザーを表示しないようにしています。 

COLUMN PDB_NAME FORMAT A15
COLUMN USERNAME FORMAT A30
 
SELECT p.PDB_ID, p.PDB_NAME, u.USERNAME 
  FROM DBA_PDBS p, CDB_USERS u
  WHERE p.PDB_ID > 2 AND
        p.PDB_ID = u.CON_ID
  ORDER BY p.PDB_ID;

出力例:

    PDB_ID PDB_NAME        USERNAME
---------- --------------- ------------------------------
         .
         .
         .
         3 HRPDB           HR
         3 HRPDB           OLAPSYS
         3 HRPDB           MDSYS
         3 HRPDB           ORDSYS
         .
         .
         .
         4 SALESPDB        OE
         4 SALESPDB        CTXSYS
         4 SALESPDB        MDSYS
         4 SALESPDB        EXFSYS
         4 SALESPDB        OLAPSYS
         .
         .
         .

例15-34 CDB内の各PDBのデータファイルの表示

この例では、DBA_PDBSおよびCDB_DATA_FILESビューを問い合せて、PDBシードなど、CDB内のすべてのPDBの各データファイルの名前と場所を表示します。 

COLUMN PID FORMAT 999
COLUMN PDB_NAME FORMAT A8
COLUMN FILE_ID FORMAT 9999
COLUMN TABLESPACE_NAME FORMAT A10
COLUMN FILE_NAME FORMAT A45

SELECT p.PDB_ID AS PID, p.PDB_NAME, d.FILE_ID, d.TABLESPACE_NAME, d.FILE_NAME
  FROM DBA_PDBS p, CDB_DATA_FILES d
  WHERE p.PDB_ID = d.CON_ID
  ORDER BY p.PDB_ID;

出力例:

PID PDB_NAME FILE_ID TABLESPACE FILE_NAME
--- -------- ------- ---------- ----------------------------------------
  2 PDB$SEED       6 SYSAUX     /disk1/oracle/dbs/pdbseed/cdb1_ax.f
  2 PDB$SEED       5 SYSTEM     /disk1/oracle/dbs/pdbseed/cdb1_db.f
  3 HRPDB          9 SYSAUX     /disk1/oracle/dbs/hrpdb/hrpdb_ax.f
  3 HRPDB          8 SYSTEM     /disk1/oracle/dbs/hrpdb/hrpdb_db.f
  3 HRPDB         13 USER       /disk1/oracle/dbs/hrpdb/hrpdb_usr.dbf
  4 SALESPDB      15 SYSTEM     /disk1/oracle/dbs/salespdb/salespdb_db.f
  4 SALESPDB      16 SYSAUX     /disk1/oracle/dbs/salespdb/salespdb_ax.f
  4 SALESPDB      18 USER       /disk1/oracle/dbs/salespdb/salespdb_usr.dbf

例15-35 CDB内の一時ファイルの表示

この例では、CDB_TEMP_FILESビューを問い合せて、CDB内の各一時ファイルの名前と場所、および一時ファイルを使用する表領域を表示します。 

COLUMN CON_ID FORMAT 999
COLUMN FILE_ID FORMAT 9999
COLUMN TABLESPACE_NAME FORMAT A15
COLUMN FILE_NAME FORMAT A45

SELECT CON_ID, FILE_ID, TABLESPACE_NAME, FILE_NAME
  FROM CDB_TEMP_FILES
  ORDER BY CON_ID;

出力例:

CON_ID FILE_ID TABLESPACE_NAM FILE_NAME
------ ------- -------------- ---------------------------------------------
     1       1 TEMP           /disk1/oracle/dbs/t_tmp1.f
     2       2 TEMP           /disk1/oracle/dbs/pdbseed/t_tmp1.f
     3       3 TEMP           /disk1/oracle/dbs/hrpdb/t_hrpdb_tmp1.f
     4       4 TEMP           /disk1/oracle/dbs/salespdb/t_salespdb_tmp1.f

例15-36 PDBに関連付けられているサービスの表示

この例では、CDB_SERVICESビューを問い合せて、PDB名、ネットワーク名、およびPDBに関連付けられている各サービスのコンテナIDを表示します。 

COLUMN NETWORK_NAME FORMAT A30
COLUMN PDB FORMAT A15
COLUMN CON_ID FORMAT 999

SELECT PDB, NETWORK_NAME, CON_ID FROM CDB_SERVICES
  WHERE PDB IS NOT NULL AND
        CON_ID > 2
  ORDER BY PDB;

出力例:

PDB             NETWORK_NAME                   CON_ID
--------------- ------------------------------ ------
HRPDB           hrpdb.example.com                   3
SALESPDB        salespdb.example.com                4

関連項目:

親トピック: CDB内のコンテナの監視

CONTAINERS句を使用したコンテナ間の問合せ

CONTAINERS句を使用すると、CDB内のすべてのコンテナ間で表およびビューを問い合せることができます。アプリケーション・コンテナ内のすべてのコンテナでアプリケーション共通オブジェクトを問い合せることもできます。

親トピック: CDB内のコンテナの監視

CONTAINERS句を使用したコンテナ間の問合せについて

CONTAINERS句を使用すると、CDB内のコンテナ間で問い合せることができます。

CONTAINERS句を使用すると、CDB内のすべてのコンテナ間でユーザーが作成した表およびビューを問い合せることができます。この句により、CDB内のすべてのオープン・コンテナに存在する表またはビューのデータを表示するために、CDBルートからの問合せが可能になります。

また、CONTAINERS句では、アプリケーション・コンテナ内のすべてのアプリケーションPDBで表やビューなどのアプリケーション共通オブジェクトを問い合せることができます。この句では、アプリケーション・ルートから問い合せて、アプリケーション・コンテナ内のオープンしているすべてのアプリケーションPDBに存在する表またはビューのデータを表示できます。

CONTAINERS句は、暗黙的に生成された次の3つの列を公開します。
  • CON_ID: 行の取得元のコンテナのID。
  • CON$NAME: 行の取得元のコンテナの名前。これは非表示の列です。
  • CDB$NAME: 行の取得元のCDBの名前。プロキシPDBまたはCDBフリートがない場合、すべての行のCDB$NAMEの値は同じになります。これは非表示の列です。

CONTAINERS句が評価される際、各コンテナはパーティションとして扱われます。したがって、CONTAINERS句を使用した問合せの計画出力にはパーティション・イテレータが含まれます。パーティション・プルーニングを使用すると、問合せの実行中にアクセスされるコンテナのセットを制限できます。プルーニング述語は、CON_ID列またはCON$NAME列のいずれかに指定でき、どちらもCONTAINERS句に対して暗黙的に生成されます。

CONTAINERS句の評価では、パラレル実行プロセスを使用します。各コンテナがパラレル実行プロセス(P00 *)に割り当てられ、プロセスはコンテナに切り替わって実表またはビューで再帰SQL文を実行します。実表またはビューは、その名前が引数としてCONTAINERS句に渡されるオブジェクトです。

CONTAINERS_PARALLEL_DEGREE初期化パラメータでは、CONTAINERS句を含む問合せの並列度を制御できます。CONTAINERS_PARALLEL_DEGREEの値が65535 (デフォルト)未満の場合は、指定した値が使用されます。

CONTAINERS_PARALLEL_DEGREE初期化パラメータにデフォルト値(65535)が設定されている場合、CONTAINERS句を使用する問合せはデフォルトでパラレル化されます。デフォルトの並列度は、次の式を使用して計算します。
max(min(cpu_count,number_of_open_containers),#instances)

また、DEFAULT_PDB_HINTヒントをCONTAINERS句に渡すことができます。ヒントは、各コンテナで実行される問合せで渡されます。

再帰的SQL文によってアクセスされる列は、問合せでアクセスされるCONTAINERS句の列によって決まります。CONTAINERS句を使用する問合せの述語は、再帰的SQLにプッシュ・ダウンして各コンテナ内で評価できるため、CONTAINERS句でポスト・フィルタとして処理する必要がある行数が大幅に削減されます。

CONTAINERS句を含む問合せから生成される再帰的SQLが並列化されるように強制するには、CONTAINERS句のDEFAULT_PDB_HINTヒントを使用するか、自動並列度を使用します。ただし、CONTAINERS句を含む問合せから生成される再帰的SQLには、パラレル文のキューイングは使用できません。

次のタイプの列がCONTAINERS句に指定された表に存在する場合は、削除されます。

  • 次のユーザー定義型: オブジェクト型、VARRAY、REFおよびネストした表

  • 次のOracle提供のタイプ: ANYTYPE、ANYDATASET、URIタイプ、SDO_TOPO_GEOMETRY、SDO_GEORASTERおよびExpression

ノート:

  • コンテナが制限モードでオープンされている場合は、CONTAINERS句で無視されます。

  • CONTAINERS句が使用され、エラーがコンテナで戻される場合、問合せではエラーが発生したコンテナから結果を戻さず、エラーは戻りません。たとえば、ローカル変数にリモート表からのBFILE列は選択できません。これを実行する問合せがCONTAINERS句を使用し、ローカルおよびリモート・コンテナを含む場合、問合せはローカル・コンテナの結果を戻しますが、リモート・コンテナは戻さず、エラーは戻りません。

関連項目:

親トピック: CONTAINERS句を使用したコンテナ間の問合せの概要

すべてのコンテナ間でのユーザーが作成した表およびビューの問合せ

CONTAINERS句を使用すると、すべてのコンテナ間でユーザーが作成した表およびビューを問い合せることができます。この句により、CDB内のすべてのオープンPDBに存在する表またはビューのデータを表示するために、CDBルートからの問合せが可能になります。

前提条件

CONTAINERS句に指定した表およびビュー、またはそのシノニムは、CDBルートおよび他のすべてのコンテナに存在する必要があります。

CONTAINERS句を使用してすべてのコンテナ間で表およびビューを問い合せるには:

  1. SQL*Plusでコンテナにアクセスします。

    複数のコンテナのデータを表示する場合は、現在のコンテナがCDBルートであることを確認します。

    「CDB内のコンテナへのアクセスについて」を参照してください。

  2. CONTAINERS句を含む問合せを実行します。

例15-37 すべてのコンテナ間での共通ユーザーが所有する表の問合せ

この例では、次のことを想定しています。

  • 組織に複数のPDBがあり、各PDBは組織内のそれぞれ異なる部門のものです。

  • 各PDBには、部門の従業員を追跡管理するemployees表がありますが、各PDBの表には別個の従業員が含まれます。

  • また、CDBルートには空のemployees表があります。

  • 各コンテナのemployees表は、同じ共通ユーザーが所有します。

CDBルートを現在のコンテナとし、表を所有する共通ユーザーを現行ユーザーとして、CONTAINERS句を指定した次の問合せを実行し、すべてのPDBのemployees表の全従業員を返します。 

SELECT * FROM CONTAINERS(employees);

例15-38 すべてのコンテナ間でのローカル・ユーザーが所有する表の問合せ

この例では、次のことを想定しています。

  • 組織に複数のPDBがあり、各PDBは組織内のそれぞれ異なる部門のものです。

  • 各PDBには、部門の従業員を追跡管理するhr.employees表がありますが、各PDBの表には別個の従業員が含まれます。

  • また、CDBルートには、共通ユーザーが所有する空のemployees表があります。

すべてのPDBの全従業員を返す問合せを実行するには、最初に共通ユーザーとして各PDBに接続し、次の文を使用してビューを作成します。

CREATE OR REPLACE VIEW employees AS SELECT * FROM hr.employees;

ビューを所有する共通ユーザーは、CDBルートのemployees表を所有する共通ユーザーと同じである必要があります。各PDBでこの文を実行すると、共通ユーザーは各PDBにemployeesという名前のビューを保持します。

CDBルートを現在のコンテナとし、共通ユーザーを現行ユーザーとして、CONTAINERS句を指定した次の問合せを実行し、すべてのPDBのhr.employees表の全従業員を返します。 

SELECT * FROM CONTAINERS(employees);

特定のコンテナのビューを問い合せることもできます。たとえば、次のSQL文では、CON_IDが3および4のコンテナのビューを問い合せます。 

SELECT * FROM CONTAINERS(employees) WHERE CON_ID IN(3,4);

ノート:

CONTAINERS句を使用してオラクル社提供の表およびビューを問い合せることもできます。この問合せを実行する際、現行ユーザーが表またはビューの所有者であることを確認するか、CONTAINERS句を使用してビューを作成し、そのビューに対するSELECT権限を適切なユーザーに付与します。

関連項目:

親トピック: CONTAINERS句を使用したコンテナ間の問合せの概要

CONTAINERS句を使用したコンテナ間の問合せ時の再帰的SQLの実行について

CONTAINERS句を含む問合せを実行したときに実行される再帰的SQLについて説明します。

ユースケース: CONTAINERSの引数として使用されるベース・オブジェクト

再帰的SQL: CONTAINERS句を含むSQLの実行時に各コンテナで実行されるSQL

説明: CONTAINERS句を含む問合せを実行すると、ベース・オブジェクトに対する再帰的SQLが各コンテナで実行されます。このSQLには、デフォルトでRESULT_CACHEヒントが含まれています。また、デフォルトで有効になっているRESULT_CACHEヒントのSYSOBJオプションもあります。

たとえば、CONTAINERS句を使用して問い合せるには、次を実行します:
select count(*)
from containers(dba_db_links);
次の再帰的SQLは、問合せがCDBルートで実行される場合に各コンテナで実行されます:
SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE) */ 1 
FROM "SYS"."DBA_DB_LINKS" "DBA_DB_LINKS"

ユースケース: CONTAINERS句のベース・オブジェクトが固定オブジェクトに依存している

説明: CONTAINERS句のベース・オブジェクトが固定オブジェクトに依存している場合、各コンテナでの再帰的SQL実行のRESULT_CACHEヒントには、SHELFLIFEオプションがデフォルト値の30として含められます。

たとえば、CONTAINERS句を使用して問い合せるには、次を実行します:
select count(*)
from containers(v$inmemory_area);
次の再帰的SQLは、問合せがCDBルートで実行される場合に各コンテナで実行されます:
SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) */ 1 FROM "SYS"."V$INMEMORY_AREA" "V$INMEMORY_AREA"

ユースケース: 再帰的SQLで使用されるSHELFLIFEの値の変更

説明:再帰的SQLで使用されるSHELFLIFEの値は、CONTAINERS句を使用する問合せのRESULT_CACHEヒントのSHELFLIFEオプションを使用して変更できます。

たとえば、CONTAINERS句を使用して問い合せるには、次を実行します:
select /*+ RESULT_CACHE(SYSOBJ=TRUE SHELFLIFE=2024) */ count(*)
from containers(v$inmemory_area);
次の再帰的SQLは、問合せがCDBルートで実行される場合に各コンテナで実行されます:
SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=2024) */ 1 FROM "SYS"."V$INMEMORY_AREA" "V$INMEMORY_AREA"

ユースケース: 再帰的SQLで使用されるSHELFLIFEの値の変更

説明:再帰的SQLで使用されるSHELFLIFEの値は、CONTAINERS句を使用する問合せのRESULT_CACHEヒントのSHELFLIFEオプションを使用して変更できます。

たとえば、CONTAINERS句を使用して問い合せるには、次を実行します:
select /*+ RESULT_CACHE(SYSOBJ=TRUE SHELFLIFE=2024) */ count(*)
from containers(v$inmemory_area);
次の再帰的SQLは、問合せがCDBルートで実行される場合に各コンテナで実行されます:
SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=2024) */ 1 FROM "SYS"."V$INMEMORY_AREA" "V$INMEMORY_AREA"

CONTAINERSのベース・オブジェクトは、SHELFLIFEオプションを自動的に使用するために、固定オブジェクトである必要はありません。ベースのオブジェクトは、依存オブジェクトとして固定オブジェクトを持っている必要があるだけです。

たとえば:
select count(*)
from containers(dba_data_files);
次の再帰的SQLは、問合せがCDBルートで実行される場合に各コンテナで実行されます:
SELECT /*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) */ 1 FROM "SYS"."DBA_DATA_FILES" "DBA_DATA_FILES"

関連項目:

親トピック: CONTAINERS句を使用したコンテナ間の問合せの概要

アプリケーションPDB間のアプリケーション共通オブジェクトの問合せ

CONTAINERS句では、アプリケーション・コンテナ内のすべてのPDBでアプリケーション共通オブジェクトを問い合せることができます。アプリケーション・ルートからの問合せによって、コンテナ内のオープンしているすべてのPDBに存在するオブジェクトのデータが表示されます。

CONTAINERS句は、メタデータリンク・アプリケーション共通オブジェクトに最も役立ちます。メタデータリンク・アプリケーション共通オブジェクトでは、構造はアプリケーション・コンテナのすべてのコンテナで同じですが、データは異なります。CONTAINERS句を使用して、複数のアプリケーションPDB内のメタデータリンク・アプリケーション共通オブジェクトのデータを表示できます。拡張データリンク・オブジェクトについてのメリットも同様です。CONTAINERS句は、パラレル実行を使用して、アプリケーション・ルートでホストされる各アプリケーションPDB間で問合せを実行します。

CONTAINERS句を使用してすべてのアプリケーションPDB間で表およびビューを問い合せるには:

  1. SQL*Plusで、アプリケーション・ルートにアクセスします。

    「CDB内のコンテナへのアクセスについて」を参照してください。

  2. CONTAINERS句を含む問合せを実行します。

ノート:

アプリケーション・ルートの表またはビューに対してCONTAINERS_DEFAULT属性を有効にできます。この属性が有効になっている場合、CONTAINERS句はデフォルトでデータベース・オブジェクトに対する問合せおよびDML文に使用され、SQL文にCONTAINERS句は必要ありません。アプリケーション・ルートの表またはビューに対してCONTAINERS_DEFAULT属性を有効にするには、ENABLE CONTAINERS_DEFAULT句を指定したALTER VIEWまたはCREATE OR REPLACE VIEW文を実行します。

例15-39 すべてのアプリケーションPDBでのアプリケーション共通オブジェクトの問合せ

この例では、次のことを想定しています。

  • 組織に複数のアプリケーションPDBがあり、各アプリケーションPDBは組織内のそれぞれ異なる部門のものです。

  • 各アプリケーションPDBには、部門の従業員を追跡管理するemployees表がありますが、各アプリケーションPDBの表には別個の従業員が含まれます。

  • また、アプリケーション・ルートには空のemployees表があります。

  • 各コンテナのemployees表は、同じ共通ユーザーが所有します。

  • 会社には、アプリケーション・コンテナ内のアプリケーションを使用する複数のテナントがあり、各テナントに固有のアプリケーションPDBがあります。

  • 会社は、メタデータリンク・アプリケーション共通オブジェクトを使用して、すべてのアプリケーションPDB内で同じデータの構造を維持しますが、データはアプリケーションPDBごとに異なります。

  • 各アプリケーションPDBには、各テナントの顧客に関する情報を格納するメタデータリンクsales.customers表があります。

アプリケーション・ルートを現在のコンテナとし、表を所有するアプリケーション共通ユーザーを現行ユーザーとして、CONTAINERS句を指定した次の問合せを実行し、すべてのアプリケーションPDBのsales.customers表の全顧客を返します。 

SELECT * FROM CONTAINERS(sales.customers);

現在のコンテナのIDまたは名前の判別

CDB内の現在のコンテナIDまたはコンテナ名を判別できます。

現在のコンテナIDを判別するには:

  • 次のSQL*Plusコマンドを実行します。

    SHOW CON_ID

現在のコンテナ名を判別するには:

  • 次のSQL*Plusコマンドを実行します。

    SHOW CON_NAME

また、表15-8に示されているファンクションを使用して、コンテナのコンテナID、コンテナ名、DBID、GUIDおよびUIDを判別することもできます。

表15-8 コンテナ情報を返すファンクション

ファンクション 説明

CON_NAME_TO_ID('container_name')

コンテナの名前に基づいてコンテナIDを返します。

CON_DBID_TO_ID(container_dbid)

コンテナのDBIDに基づいてコンテナIDを返します。

CON_UID_TO_ID(container_uid)

コンテナの一意識別子(UID)に基づいてコンテナIDを返します。

CON_GUID_TO_ID(container_guid)

コンテナのグローバル一意識別子(GUID)に基づいてコンテナIDを返します。

CON_ID_TO_CON_NAME(container_id)

コンテナIDに基づいてコンテナの名前を返します。

CON_ID_TO_DBID(container_id)

コンテナIDに基づいてコンテナのDBIDを返します。

CON_ID_TO_GUID(container_id)

コンテナIDに基づいてコンテナのグローバル一意識別子(GUID)を返します。

CON_ID_TO_UID(container_id)

コンテナIDに基づいてコンテナの一意識別子(UID)を返します。

V$CONTAINERSビューには、CDB内の各コンテナの名前、DBID、UIDおよびGUIDが表示されます。

例15-40 コンテナの名前に基づいたコンテナIDの戻し

SELECT CON_NAME_TO_ID('HRPDB') FROM DUAL;

例15-41 コンテナDBIDに基づいたコンテナIDの戻し

SELECT CON_DBID_TO_ID(2226957846) FROM DUAL;

例15-42 コンテナIDに基づいたコンテナの名前の戻し

SELECT CON_ID_TO_CON_NAME(4) FROM DUAL;

関連項目:

親トピック: CDB内のコンテナの監視

PDBの変更可能な初期化パラメータをリスト

CDBでは、一部の初期化パラメータがルートおよびすべてのPDBに適用されます。このような初期化パラメータが変更されると、CDB全体に影響を与えます。他の初期化パラメータは、各コンテナで異なる値に設定できます。

たとえば、1つのパラメータについて、ルートで1つの値を設定し、あるPDBで別の値を設定し、2番目のPDBではさらに別の値を設定できます。

この項で示す問合せによって、各PDBで個別に設定できる初期化パラメータがリストされます。

各コンテナで変更可能な初期化パラメータをリストするには:

  1. SQL*Plusでコンテナにアクセスします。

    「CDB内のコンテナへのアクセスについて」を参照してください。

  2. 次の問合せを実行します。

    SELECT NAME FROM V$SYSTEM_PARAMETER
  WHERE ISPDB_MODIFIABLE = 'TRUE'
  ORDER BY NAME;

この問合せでリストされた初期化パラメータがPDBに個別に設定されていない場合、PDBではルートのパラメータ値が継承されます。

  • PDBの履歴の表示
    CDB_PDB_HISTORYビューには、CDB内のPDBの履歴が表示されます。各PDBがいつどのように作成されたかに関する情報、および各PDBの履歴に関するその他の情報を提供します。

関連項目:

親トピック: CDB内のコンテナの監視

PDBの履歴の表示

CDB_PDB_HISTORYビューには、CDB内のPDBの履歴が表示されます。各PDBがいつどのように作成されたかに関する情報、および各PDBの履歴に関するその他の情報を提供します。

各PDBの履歴を表示するには:

  1. SQL*Plusで、現在のコンテナがルートであることを確認します。

    「SQL*Plusを使用したCDB内のコンテナへのアクセス」を参照してください。

  2. CDB_PDB_HISTORYビューを問い合せます。

例15-43 PDBの履歴の表示

この例では、各PDBの履歴に関する次の情報を表示します。

  • DB_NAMEフィールドには、PDBが含まれているCDBが表示されます。

  • CON_IDフィールドには、PDBのコンテナIDが表示されます。

  • PDB_NAMEフィールドには、PDBのいずれかのインカネーションでのPDBの名前が表示されます。

  • OPERATIONフィールドには、PDBの履歴で実行された操作が表示されます。

  • OP_TIMESTAMPフィールドには、操作が実行された日付が表示されます。

  • PDBが操作でクローニングされた場合、CLONED_FROM_PDBフィールドにはPDBのクローニング元となるPDBが表示されます。 

COLUMN DB_NAME FORMAT A10
COLUMN CON_ID FORMAT 999
COLUMN PDB_NAME FORMAT A15
COLUMN OPERATION FORMAT A16
COLUMN OP_TIMESTAMP FORMAT A10
COLUMN CLONED_FROM_PDB_NAME FORMAT A15
 
SELECT DB_NAME, CON_ID, PDB_NAME, OPERATION, OP_TIMESTAMP, CLONED_FROM_PDB_NAME
  FROM CDB_PDB_HISTORY
  WHERE CON_ID > 2
  ORDER BY CON_ID;

出力例:

DB_NAME    CON_ID PDB_NAME        OPERATION        OP_TIMESTA CLONED_FROM_PDB
---------- ------ --------------- ---------------- ---------- ---------------
NEWCDB          3 HRPDB           CREATE           10-APR-12  PDB$SEED
NEWCDB          4 SALESPDB        CREATE           17-APR-12  PDB$SEED
NEWCDB          5 TESTPDB         CLONE            30-APR-12  SALESPDB

ノート:

現在のコンテナがPDBである場合、CDB_PDB_HISTORYビューには、現在のPDBの履歴のみが表示されます。現在のコンテナがPDBであるローカル・ユーザーは、DBA_PDB_HISTORYビューを問い合せ、問合せからCON_ID列を除外して、現在のPDBの履歴を表示できます。