1. 管理者ガイド
  2. CDBの作成
  3. CDBの作成: 高度なトピック

4 CDBの作成: 高度なトピック

この章では、CDBの作成について詳しく説明します。

  • CREATE DATABASE文の句の指定
    CREATE DATABASE文を実行すると、Oracle Databaseはいくつかの操作を実行します。実際の操作は、CREATE DATABASE文で指定した句、および初期化パラメータの設定に応じて実行されます。
  • 初期化パラメータの指定
    新規データベースを作成する前に、基本初期化パラメータを追加または編集できます。
  • サーバー・パラメータ・ファイルを使用した初期化パラメータの管理
    Oracle Databaseの初期化パラメータは、テキスト形式の初期化パラメータ・ファイルに格納されていました。管理性を向上させるために、データベースを起動および停止している間も持続するバイナリ形式のサーバー・パラメータ・ファイルによる初期化パラメータのメンテナンスを選択できます。
  • データベース・サービスでのアプリケーション・ワークロードの管理
    データベース・サービスは、1つ以上のデータベース・インスタンスをある単位にまとめて表現したものです。サービスを使用すれば、データベースのワークロードをグループ化し、特定の作業リクエストを適切なインスタンスにルーティングできます。
  • Oracle DatabaseのStandard Edition高可用性の管理
    Standard Edition高可用性機能は、Oracle Clusterwareを使用したOracle Database Standard Edition 2単一インスタンス・データベースに向けて計画外停止に対する保護を提供します。
  • データベースのクローニング
    この項では、Oracleデータベースの様々なクローニング方法について説明します。
  • データベースの削除
    CDBの削除には、データファイル、オンラインREDOログ、制御ファイルおよび初期化パラメータ・ファイルの削除も含まれます。

親トピック: CDBの作成

CREATE DATABASE文の句の指定

CREATE DATABASE文を実行すると、Oracle Databaseはいくつかの操作を実行します。実際の操作は、CREATE DATABASE文で指定した句、および初期化パラメータの設定に応じて実行されます。

親トピック: CDBの作成: 高度なトピック

CREATE DATABASE文の句について

CREATE DATABASE句を使用して、データベースの作成および管理を簡略化できます。

CREATE DATABASE文を実行すると、Oracle Databaseは少なくとも次の操作を実行します。

  • データベース用のデータファイルの作成

  • データベース用の制御ファイルの作成

  • データベース用のオンラインREDOログの作成とARCHIVELOGモードの設定

  • SYSTEM表領域の作成

  • SYSAUX表領域の作成

  • データ・ディクショナリの作成

  • データベースへのデータの格納に使用する文字セットの設定

  • データベース・タイム・ゾーンの設定

  • データベースのマウントとオープン

親トピック: CREATE DATABASE文の句の指定

データベースの保護: ユーザーSYSおよびSYSTEMのパスワードの指定

データベースを保護するには、ユーザーSYSおよびSYSTEMのパスワードを指定します。

  • CREATE DATABASE文に、ユーザーSYSおよびSYSTEMのパスワードを指定する句を含めます。

CREATE DATABASE文でユーザーSYSおよびSYSTEMのパスワード指定に使用する句は、次のとおりです。

  • USER SYS IDENTIFIED BY password

  • USER SYSTEM IDENTIFIED BY password

パスワードを選択するときは、パスワードでは大/小文字が区別されることに注意してください。また、使用中のデータベースにパスワード形式の要件が設定されている場合もあります。

関連項目:

セキュアなパスワードの作成についてのオラクル社のガイドラインについては、Oracle Databaseセキュリティ・ガイドを参照してください。

親トピック: CREATE DATABASE文の句の指定

ローカル管理のSYSTEM表領域の作成

データベースの作成時に、ローカル管理のSYSTEM表領域を作成します。ローカル管理表領域では、各データファイルに格納されるビットマップを使用してエクステントを管理します。

  • CREATE DATABASE文にEXTENT MANAGEMENT LOCAL句を指定すると、ローカル管理のSYSTEM表領域を作成できます。

EXTENT MANAGEMENT LOCAL句を指定しない場合は、デフォルトでディクショナリ管理のSYSTEM表領域が作成されます。ディクショナリ管理表領域は非推奨です。

ローカル管理のSYSTEM表領域を指定してデータベースを作成する場合にOracle Managed Filesを使用していない場合は、次の条件が満たされているかどうかを確認してください。

  • DEFAULT TEMPORARY TABLESPACE句をCREATE DATABASE文に指定

  • UNDO TABLESPACE句をCREATE DATABASE文に指定

関連項目:

親トピック: CREATE DATABASE文の句の指定

SYSAUX表領域のデータファイル属性の指定

SYSAUX表領域はデフォルトで作成されますが、データベース作成時にデータファイル属性を指定できます。

SYSAUX表領域のデータファイル属性を指定するには:

  • CREATE DATABASE文にSYSAUX DATAFILE句を含めます。

SYSTEM表領域に対してDATAFILE句を指定している場合は、SYSAUX DATAFILE句も指定する必要があり、指定しない場合は、CREATE DATABASE文が失敗します。この要件は、Oracle Managed Files機能が使用可能な場合は適用されません(「データベース作成時のOracle Managed Filesの作成」を参照してください)。

親トピック: CREATE DATABASE文の句の指定

SYSAUX表領域について

SYSAUX表領域はデータベース作成時に必ず作成されます。

SYSAUX表領域は、SYSTEM表領域の予備の表領域として機能します。これは、以前に固有の表領域を必要としていたOracle Databaseの多くの機能と製品に対するデフォルトの表領域であるため、データベースに必要な表領域の数が削減されます。また、SYSTEM表領域の負荷も軽減されます。

SYSAUX表領域に対して指定できるのはデータファイルの属性のみで、CREATE DATABASE文でSYSAUX DATAFILE句を使用して指定します。SYSAUX表領域の必須属性は、Oracle Databaseによって設定され、次のような属性があります。

  • PERMANENT

  • READ WRITE

  • EXTENT MANAGEMENT LOCAL

  • SEGMENT SPACE MANAGEMENT AUTO

これらの属性は、ALTER TABLESPACE文で変更できず、変更しようとするとエラーが発生します。SYSAUX表領域の削除や名前変更はできません。

SYSAUX表領域のサイズは、SYSAUXを使用するデータベース・コンポーネントのサイズにより決定します。V$SYSAUX_OCCUPANTSビューを問い合せることにより、これらのコンポーネントのリストを表示できます。これらのコンポーネントの初期サイズに基づいて、SYSAUX表領域には、データベース作成時に最低限400MB必要です。SYSAUX表領域の領域要件は、データベースが完全にデプロイされた後、その使用状況やワークロードによって増加します。

SYSAUX表領域のセキュリティ属性はSYSTEM表領域と同じです。

関連項目:

SYSAUX表領域の管理方法を学習するには、『Oracle Database管理者ガイド』を参照

親トピック: SYSAUX表領域のデータファイル属性の指定

自動UNDO管理の使用: UNDO表領域の作成

自動UNDO管理ではUNDO表領域が使用されます。

  • 自動UNDO管理を使用可能にするには、初期化パラメータ・ファイルでUNDO_MANAGEMENT初期化パラメータをAUTOに設定します。または、このパラメータを省略すると、デフォルトでデータベースが自動UNDO管理になります。

このモードでは、UNDOデータがUNDO表領域に格納され、Oracle Databaseによって管理されます。UNDO表領域を定義して名前を付けるには、データベース作成時にCREATE DATABASE文にUNDO TABLESPACE句を指定する必要があります。この句を省略して自動UNDO管理を使用可能にすると、SYS_UNDOTBSという名前のデフォルトのUNDO表領域が作成されます。

ノート:

UNDO表領域を自分で定義する場合は、ブロック・サイズがデータベースのデータファイルの最大ブロック・サイズと一致するようにします。

関連項目:

親トピック: CREATE DATABASE文の句の指定

デフォルト表領域の作成

デフォルトの表領域を作成することをお薦めします。この表領域には、Oracle Databaseによって、別の表領域が明示的に指定されていないSYSTEM以外のユーザーが割り当てられます。

データベースのデフォルトの表領域を指定するには:

  • DEFAULT TABLESPACE句をCREATE DATABASE文に含めます

DEFAULT TABLESPACE句を指定しない場合、SYSTEM以外のユーザーに対するデフォルトの表領域はSYSTEM表領域です。

関連項目:

CREATE DATABASEおよびALTER DATABASEのDEFAULT TABLESPACE句の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

親トピック: CREATE DATABASE文の句の指定

デフォルト一時表領域の作成

デフォルト一時表領域を作成する場合、Oracle Databaseでは、一時表領域が明示的に割り当てられていないユーザーに対してこの表領域が一時表領域として割り当てられます。

CDBのデフォルト一時表領域を作成するには:

  • DEFAULT TEMPORARY TABLESPACE句をCREATE DATABASE文に含めます。

一時表領域または表領域グループは、CREATE USER文で明示的にユーザーに割り当てることができます。ただし、それを行わない場合は、デフォルトの一時表領域がデータベースに指定されていないと、これらのユーザーには一時表領域としてSYSTEM表領域がデフォルトで割り当てられます。一時データをSYSTEM表領域に格納するのはよい方法ではなく、すべてのユーザーに一時表領域を個別に割り当てるのは非効率的です。したがって、CREATE DATABASEのDEFAULT TEMPORARY TABLESPACE句の使用をお薦めします。

ノート:

ローカル管理のSYSTEM表領域を指定すると、そのSYSTEM表領域は一時表領域として使用できません。この場合は、デフォルトの一時表領域を作成する必要があります。この動作については、「ローカル管理のSYSTEM表領域の作成」を参照してください。

関連項目:

親トピック: CREATE DATABASE文の句の指定

データベース作成時のOracle Managed Filesの作成

Oracle Managed Files機能を使用すると、CREATE DATABASE文に指定する句とパラメータの数を最小限に抑えることができます。

  • Oracle Databaseによってファイルが作成および管理されるディレクトリまたはOracle Automatic Storage Management(Oracle ASM)ディスク・グループのいずれかを指定します。

初期化パラメータ・ファイルにDB_CREATE_FILE_DEST、DB_CREATE_ONLINE_LOG_DEST_nまたはDB_RECOVERY_FILE_DEST初期化パラメータを設定すると、データベースの基礎となるオペレーティング・システム・ファイルをOracle Databaseで作成および管理できます。指定した初期化パラメータおよびCREATE DATABASE文で指定した句に応じて、次のデータベース構造のオペレーティング・システム・ファイルがOracle Databaseによって自動的に作成および管理されます。

  • 表領域とそのデータファイル

  • 一時表領域とその一時ファイル

  • 制御ファイル

  • オンラインREDOログ・ファイル

  • アーカイブREDOログ・ファイル

  • フラッシュバック・ログ

  • ブロック・チェンジ・トラッキング・ファイル

  • RMANバックアップ

次のCREATE DATABASE文で、Oracle Managed Files機能の動作を示します。必要な初期化パラメータは指定されているとします。 

CREATE DATABASE mynewdb
     USER SYS IDENTIFIED BY sys_password
     USER SYSTEM IDENTIFIED BY system_password
     EXTENT MANAGEMENT LOCAL
     UNDO TABLESPACE undotbs1
     DEFAULT TEMPORARY TABLESPACE tempts1
     DEFAULT TABLESPACE users
     ENABLE PLUGGABLE DATABASE
       SEED
       SYSTEM DATAFILES SIZE 125M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED
       SYSAUX DATAFILES SIZE 100M;

  • SYSTEM表領域はローカル管理の表領域として作成されます。EXTENT MANAGEMENT LOCAL句を指定しないと、SYSTEM表領域はディクショナリ管理の対象として作成されますが、この方法はお薦めしません。

  • DATAFILE句が指定されていないため、SYSTEM表領域用のOracle Managed Filesのデータファイルが作成されます。

  • LOGFILE句が指定されていないため、Oracleが管理するREDOログ・ファイルのグループが2つ作成されます。

  • SYSAUX DATAFILEが指定されていないため、SYSAUX表領域用のOracle Managed Filesのデータファイルが作成されます。

  • UNDO TABLESPACE句およびDEFAULT TABLESPACE句にDATAFILE副次句が指定されていないため、これらの各表領域用にOracle Managed Filesのデータファイルが作成されます。

  • DEFAULT TEMPORARY TABLESPACE句にTEMPFILE副次句が指定されていないため、Oracle Managed Filesの一時ファイルが作成されます。

  • 初期化パラメータ・ファイルにCONTROL_FILES初期化パラメータが指定されていない場合は、Oracle Managed Filesの制御ファイルも作成されます。

  • サーバー・パラメータ・ファイルを使用している場合は、データベースによって適切な初期化パラメータが自動的に設定されます。

    関連項目:

親トピック: CREATE DATABASE文の句の指定

データベース作成時のbigfile表領域のサポート

Oracle Databaseでは、bigfile表領域を作成できるようにすることで、表領域の管理を簡素化し、非常に大規模なデータベースのサポートを可能にしています。

bigfile表領域に含めることができるファイルは1つのみですが、そのファイルには最大40億ブロックまで設定できます。1つのOracle Databaseのデータファイルの最大数は制限されています(通常は64000ファイル)。したがって、bigfile表領域によって、Oracle Databaseの記憶域容量が大幅に増加します。

この項では、bigfile表領域のサポートを可能にするCREATE DATABASE文の句について説明します。

  • デフォルトの表領域タイプの指定
    CREATE DATABASE文のSET DEFAULT...TABLESPACE句によって、後続のCREATE TABLESPACE文でこのデータベースに使用される表領域のデフォルト・タイプが決定します。
  • デフォルトの表領域タイプの上書き
    SYSTEMおよびSYSAUX表領域は、常にデフォルトの表領域タイプで作成されます。ただし、UNDOおよびDEFAULT TEMPORARY表領域のデフォルトの表領域タイプは、CREATE DATABASE操作時に、オプションで明示的に上書きできます。

関連項目:

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

親トピック: CREATE DATABASE文の句の指定

デフォルトの表領域タイプの指定

CREATE DATABASE文のSET DEFAULT...TABLESPACE句によって、後続のCREATE TABLESPACE文でこのデータベースに使用される表領域のデフォルト・タイプが決定します。

  • SET DEFAULT BIGFILE TABLESPACEまたはSET DEFAULT SMALLFILE TABLESPACEを指定します。

この句を省略すると、デフォルトでは、従来のタイプのOracle Database表領域であるsmallfile表領域が作成されます。smallfile表領域には最大1022ファイルを含めることができ、それぞれ400万ブロックまで設定できます。

bigfile表領域によってデータファイルがユーザーに対して完全に透過的になるため、bigfile表領域を使用するとOracle Managed Filesの機能がさらに強化されます。ALTER TABLESPACE文のSQL構文は、基礎になるデータファイルではなく表領域で操作を実行できるように拡張されています。

表領域のデフォルト・タイプがbigfile表領域であることを指定するには、「データベース作成時のOracle Managed Filesの作成」に示したCREATE DATABASE文を次のように変更します。 

CREATE DATABASE mynewdb
     USER SYS IDENTIFIED BY sys_password
     USER SYSTEM IDENTIFIED BY system_password
     SET DEFAULT BIGFILE TABLESPACE
     UNDO TABLESPACE undotbs1
     DEFAULT TEMPORARY TABLESPACE tempts1
     ENABLE PLUGGABLE DATABASE
        SEED
        SYSTEM DATAFILES SIZE 125M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED
        SYSAUX DATAFILES SIZE 100M;

デフォルトの表領域タイプをデータベース作成後に動的に変更するには、ALTER DATABASE文のSET DEFAULT TABLESPACE句を使用します。 

ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE;

データベースの現行のデフォルト一時表領域タイプを判断するには、DATABASE_PROPERTIESデータ・ディクショナリ・ビューを次のように問い合せます。 

SELECT PROPERTY_VALUE FROM DATABASE_PROPERTIES 
   WHERE PROPERTY_NAME = 'DEFAULT_TBS_TYPE';
デフォルトの表領域タイプの上書き

SYSTEMおよびSYSAUX表領域は、常にデフォルトの表領域タイプで作成されます。ただし、UNDOおよびDEFAULT TEMPORARY表領域のデフォルトの表領域タイプは、CREATE DATABASE操作時に、オプションで明示的に上書きできます。

  • デフォルトの表領域タイプをオーバーライドするUNDO TABLESPACE句またはDEFAULT TEMPORARY TABLESPACE句を指定します。

たとえば、次のように指定すると、デフォルトの表領域タイプがsmallfileのデータベースで、bigfileのUNDO表領域を作成できます。 

CREATE DATABASE mynewdb
...
     BIGFILE UNDO TABLESPACE undotbs1
        DATAFILE '/u01/oracle/oradata/mynewdb/undotbs01.dbf'
        SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

次のように指定すると、デフォルトの表領域タイプがbigfileのデータベースで、smallfileのDEFAULT TEMPORARY表領域を作成できます。 

CREATE DATABASE mynewdb
   SET DEFAULT BIGFILE TABLESPACE
...
     SMALLFILE DEFAULT TEMPORARY TABLESPACE tempts1
        TEMPFILE '/u01/oracle/oradata/mynewdb/temp01.dbf' 
        SIZE 20M REUSE
...

データベースのタイム・ゾーンとタイム・ゾーン・ファイルの指定

Oracle Databaseの日時データ型、期間データ型およびタイム・ゾーン・サポートにより、イベントとトランザクションの時間に関して一貫性のある情報を格納できます。

親トピック: CREATE DATABASE文の句の指定

データベースのタイム・ゾーンの設定

CREATE DATABASE文のSET TIME_ZONE句を使用して、データベース・タイム・ゾーンを設定できます。

  • データベースの作成時にデータベースのタイム・ゾーンを設定するには、CREATE DATABASE文でSET TIME_ZONE句を使用します。

データベースのタイム・ゾーンを設定しない場合は、デフォルトでホスト・オペレーティング・システムのタイム・ゾーンに設定されます。

セッションのデータベース・タイム・ゾーンを変更するには、ALTER SESSION文でSET TIME_ZONE句を使用します。

関連項目:

データベース・タイム・ゾーンの設定の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

親トピック: データベースのタイム・ゾーンとタイム・ゾーン・ファイルの指定

データベースのタイム・ゾーン・ファイルについて

Oracleホーム・ディレクトリのサブディレクトリには、次の2つのタイム・ゾーン・ファイルがあります。タイム・ゾーン・ファイルには有効なタイム・ゾーン名が含まれています。

タイム・ゾーンごとに次の情報も含まれています。

  • 協定世界時(UTC)からのオフセット。

  • 夏時間への移行時間。

  • 標準時間と夏時間の略称。

デフォルトのタイム・ゾーン・ファイルはORACLE_HOME/oracore/zoneinfo/timezlrg_11.datです。タイム・ゾーン数の少ないタイム・ゾーン・ファイルはORACLE_HOME/oracore/zoneinfo/timezone_11.datにあります。

ファイル内で、データベースで使用されているタイム・ゾーン名を表示するには、次の問合せを実行します。

SELECT * FROM V$TIMEZONE_NAMES;

関連項目:

タイム・ゾーン・ファイルの管理および選択の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

親トピック: データベースのタイム・ゾーンとタイム・ゾーン・ファイルの指定

データベースのタイム・ゾーン・ファイルの指定

情報を共有しているすべてのデータベースが同じタイム・ゾーン・データファイルを使用する必要があります。

データベース・サーバーでは、定義数が多いタイム・ゾーン・ファイルが常にデフォルトで使用されます。

クライアントで小さなタイム・ゾーン・ファイルを使用するには、すべてのデータが小さなファイル内の地域のみ参照することを認識します。

  • クライアントのORA_TZFILE環境変数をクライアントのタイムゾーンversion.datファイルのフルパス名に設定します。versionは、データベース・サーバーで使用されるタイム・ゾーン・ファイル・バージョンと一致します。

デフォルトの定義数の多いタイム・ゾーン・ファイルをクライアントですでに使用している場合、定義数の少ないタイム・ゾーン・ファイルに変更するのは実用的ではありません。データベースに、定義数の少ないファイルには含まれていないタイム・ゾーンのデータが含まれている可能性があるためです。

FORCE LOGGINGモードの指定

一部のデータ定義言語文(CREATE TABLEなど)では、NOLOGGING句を使用できますが、ある種のデータベース操作ではデータベースREDOログにREDOレコードが生成されません。NOLOGGING句を設定すると、データベース・リカバリ・メカニズム外で容易にリカバリできる操作は高速化されますが、メディア・リカバリとスタンバイ・データベースに悪影響を与える可能性があります。

Oracle Databaseでは、DDL文にNOLOGGINGが指定されていても、REDOレコードを強制的に書き込ませることができます。データベースでは、一時表領域と一時セグメントのREDOレコードは生成されないため、FORCE LOGGINGはオブジェクトに影響を与えません。

関連項目:

NOLOGGINGモードで実行できる操作の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

親トピック: CREATE DATABASE文の句の指定

FORCE LOGGING句の使用

NOLOGGINGがDDL文で指定されている場合でも、REDOレコードを強制的に書き込むことができます。

データベースをFORCE LOGGINGモードにするには:

  • CREATE DATABASE文にFORCE LOGGING句を含めます。

この句を指定しない場合、データベースはFORCE LOGGINGモードになりません。

データベースの作成後に、ALTER DATABASE文を使用してデータベースをFORCE LOGGINGモードにします。この文は、ロギングなしの直接書込みがすべて完了するまで待機するため、完了までに長時間かかる可能性があります。

次のSQL文を使用すると、FORCE LOGGINGモードを取り消すことができます。 

ALTER DATABASE NO FORCE LOGGING;

データベースに対してFORCE LOGGINGを指定するかどうかに関係なく、表領域レベルでFORCE LOGGINGまたはNO FORCE LOGGINGを選択的に指定できます。ただし、FORCE LOGGINGモードがデータベースに対して有効になっている場合、表領域の設定より優先されます。データベースに対して有効になっていない場合、個々の表領域の設定が実行されます。データベース全体をFORCE LOGGINGモードにするか、または個々の表領域をFORCE LOGGINGモードにすることをお薦めしますが、一度に両方の設定を行わないでください。

FORCE LOGGINGモードは、データベースの永続属性です。つまり、データベースが停止され、再起動されても、同じロギング・モードのままです。ただし、制御ファイルを再作成すると、CREATE CONTROL FILE文でFORCE LOGGING句を指定しないかぎり、データベースはFORCE LOGGINGモードで再起動しません。

関連項目:

表領域の作成にFORCE LOGGING句を使用する方法の詳細は、Oracle Database管理者ガイドを参照してください。

親トピック: FORCE LOGGINGモードの指定

FORCE LOGGINGモードのパフォーマンスに関する考慮点

FORCE LOGGINGモードは、ある程度のパフォーマンスの低下を伴います。

主として完全メディア・リカバリを確実に行うためにFORCE LOGGINGを指定し、アクティブになっているスタンバイ・データベースがない場合は、次の点を考慮する必要があります。

  • 発生すると思われるメディア障害の数

  • ロギングなしの直接書込みをリカバリできない場合のダメージの重大度

  • FORCE LOGGINGモードによるパフォーマンスの低下は許容範囲内かどうか

データベースがNOARCHIVELOGモードで稼働している場合、通常はFORCE LOGGINGモードにする利点はありません。NOARCHIVELOGモードではメディア・リカバリが不可能であるため、FORCE LOGGINGと組み合せて使用する場合は、ほとんど利点がなく、パフォーマンスが低下する可能性があります。

Oracle Databaseリリース18c以降には、次の2つの新しいNOLOGGING句が導入されています。この句を使用すると、ログに記録されない操作の実行と、Active Data Guardスタンバイ・データベースによるすべてのデータの受信が可能になるため、FORCE LOGGINGモードで生成される巨大なREDOログによるパフォーマンスの低下を防止できます。

  • STANDBY NOLOGGING FOR DATA AVAILABILITY

  • STANDBY NOLOGGING FOR LOAD PERFORMANCE

関連項目:

STANDBY NOLOGGING句の詳細は、『Oracle Data Guard概要および管理』を参照してください

親トピック: FORCE LOGGINGモードの指定

初期化パラメータの指定

新しいデータベースを作成する前に、基本初期化パラメータを追加または編集できます。

  • 初期化パラメータと初期化パラメータ・ファイルについて
    Oracleインスタンスの起動時に、初期化パラメータ・ファイルから初期化パラメータが読み込まれます。このファイルでは、少なくともDB_NAMEパラメータを指定する必要があります。他のすべてのパラメータにはデフォルトの値があります。
  • グローバル・データベース名の決定
    グローバル・データベース名は、ユーザー指定のローカル・データベース名と、ネットワーク構造内でのデータベースの位置で構成されます。
  • 高速リカバリ領域の指定
    高速リカバリ領域とは、Oracle Databaseでバックアップおよびリカバリに関連するファイルを格納および管理できる場所のことです。これは、現在のデータベース・ファイル(データファイル、制御ファイルおよびオンラインREDOログ)の場所であるデータベース領域とは別です。
  • 制御ファイルの指定
    すべてのデータベースには、データベースの構造(名前、作成時のタイムスタンプ、データ・ファイルおよびREDOファイルの名前や場所など)を記述するエントリを含む制御ファイルがあります。CONTROL_FILES初期化パラメータには、1つ以上の制御ファイル名をカンマで区切って指定します。
  • データベース・ブロック・サイズの指定
    DB_BLOCK_SIZE初期化パラメータは、データベースの標準ブロック・サイズを指定します。
  • 最大プロセス数の指定
    Oracle Databaseに同時に接続できるオペレーティング・システム・プロセスの最大数は、PROCESSES初期化パラメータによって決定します。
  • DDLロック・タイムアウトの指定
    ブロッキングDDL文がロックを待機する時間を指定できます。
  • UNDO領域管理方法の指定
    すべてのOracle Databaseには、データベースの変更を取り消すために使用する情報のメンテナンス方法が必要です。これらの情報は、主にコミットされる前のトランザクションの処理レコードから構成されます。これらのレコードを総称してUNDOデータと呼びます。
  • データベース互換性レベルの指定
    データベースの互換レベルは、COMPATIBLE初期化パラメータによって制御されます。
  • ライセンスに関するパラメータの設定
    指名ユーザー・ライセンスを使用している場合、Oracle Databaseではこの形式のライセンスを施行できます。データベース内に作成するユーザーの数に対して、制限を設定できます。この制限に達すると、それ以上のユーザーは作成できません。

関連項目:

親トピック: CDBの作成: 高度なトピック

初期化パラメータと初期化パラメータ・ファイルについて

Oracleインスタンスの起動時に、初期化パラメータ・ファイルから初期化パラメータが読み込まれます。このファイルでは、少なくともDB_NAMEパラメータを指定する必要があります。他のすべてのパラメータにはデフォルトの値があります。

初期化パラメータ・ファイルは、読取り専用のテキスト・ファイル(PFILE)または読取り/書込みのバイナリ・ファイルです。

バイナリ・ファイルはサーバー・パラメータ・ファイルと呼ばれています。サーバー・パラメータ・ファイルを使用すると、ALTER SYSTEMコマンドを使用して初期化パラメータを変更でき、変更内容は停止して起動した後も持続します。また、Oracle Databaseによる自己チューニングの基礎ともなります。このため、サーバー・パラメータ・ファイルを使用することをお薦めします。サーバー・パラメータ・ファイルは、編集済のテキスト形式の初期化ファイルから手動で作成するか、またはデータベースを作成するDatabase Configuration Assistant(DBCA)を使用して自動的に作成できます。

サーバー・パラメータ・ファイルを手動で作成する前に、テキスト形式の初期化パラメータ・ファイルを使用してインスタンスを起動できます。起動時に、Oracleインスタンスは最初にデフォルトの場所でサーバー・パラメータ・ファイルを検索し、見つからない場合は、テキスト形式の初期化パラメータ・ファイルを検索します。また、STARTUPコマンドの引数としてテキスト形式の初期化パラメータ・ファイルを指定すると、既存のサーバー・パラメータ・ファイルを上書きすることもできます。

テキスト形式の初期化パラメータ・ファイルのデフォルトのファイル名と場所は、次の表のとおりです。

プラットフォーム デフォルト名 デフォルトの場所

UNIXおよびLinux

initORACLE_SID.ora

たとえば、mynewdbデータベースの初期化パラメータ・ファイル名は次のようになります。

initmynewdb.ora

ORACLE_BASE_CONFIG/dbs

Windows

initORACLE_SID.ora

ORACLE_HOME\database

初めてOracle Databaseを作成する場合は、変更するパラメータ値の数を最小限にとどめておくことをお薦めします。データベースと環境に慣れてから、多数の初期化パラメータをALTER SYSTEM文で動的にチューニングします。テキスト形式の初期化パラメータ・ファイルを使用している場合、現行のインスタンスについてのみ変更できます。これを永続的にするには、初期化パラメータ・ファイル内で手動で更新する必要があり、更新しない場合は、次回データベースを停止して起動すると変更内容が失われます。サーバー・パラメータ・ファイルを使用している場合、ALTER SYSTEM文で行った初期化パラメータ・ファイルの変更内容は、停止して起動した後も持続します。

  • 初期化パラメータ・ファイルのサンプル
    Oracle Databaseには通常、適切な値が設定されたテキスト形式の初期化パラメータのサンプルが用意されています。構成やオプション、およびデータベースのチューニング計画によっては、オラクル社が提供するこれらの初期化パラメータを編集し、他の初期化パラメータを追加することが可能です。
  • テキスト形式の初期化パラメータ・ファイル
    テキスト形式の初期化パラメータ・ファイルでは、パラメータの値を名前/値ペアで指定します。
  • 初期化パラメータの式の設定
    初期化パラメータの値を必要な数値、テキスト値または式に設定します。

関連項目:

親トピック: 初期化パラメータの指定

初期化パラメータ・ファイルのサンプル

Oracle Databaseには通常、適切な値が設定されたテキスト形式の初期化パラメータのサンプルが用意されています。構成やオプション、およびデータベースのチューニング計画によっては、オラクル社が提供するこれらの初期化パラメータを編集し、他の初期化パラメータを追加することが可能です。

テキスト形式の初期化パラメータ・ファイルのサンプルはinit.oraという名前で、ほとんどのプラットフォームの次の場所にあります。 

ORACLE_HOME/dbs

サンプル・ファイルの内容は、次のとおりです。

##############################################################################
# Example INIT.ORA file
#
# This file is provided by Oracle Corporation to help you start by providing
# a starting point to customize your RDBMS installation for your site. 
# 
# NOTE: The values that are used in this file are only intended to be used
# as a starting point. You may want to adjust/tune those values to your
# specific hardware and needs. You may also consider using Database
# Configuration Assistant tool (DBCA) to create INIT file and to size your
# initial set of tablespaces based on the user input.
###############################################################################
 
# Change '<ORACLE_BASE>' to point to the oracle base (the one you specify at
# install time)
 
db_name='ORCL'
memory_target=1G
processes = 150
db_block_size=8192
db_domain=''
db_recovery_file_dest='<ORACLE_BASE>/flash_recovery_area'
db_recovery_file_dest_size=2G
diagnostic_dest='<ORACLE_BASE>'
dispatchers='(PROTOCOL=TCP) (SERVICE=ORCLXDB)'
open_cursors=300 
remote_login_passwordfile='EXCLUSIVE'
undo_tablespace='UNDOTBS1'
# You may want to ensure that control files are created on separate physical
# devices
control_files = (ora_control1, ora_control2)
compatible ='12.0.0'
enable_pluggable_database=TRUE
テキスト形式の初期化パラメータ・ファイル

テキスト形式の初期化パラメータ・ファイルでは、パラメータの値を名前/値ペアで指定します。

テキスト形式の初期化パラメータ・ファイル(PFILE)には、次のいずれかの書式の名前/値ペアを含める必要があります。

  • 値を1つのみ受け入れるパラメータの場合

    parameter_name=value

  • 1つ以上の値を受け入れるパラメータの場合(CONTROL_FILESパラメータなど) 

    parameter_name=(value[,value] ...)

文字列型のパラメータ値は、一重引用符(')で囲む必要があります。ファイル名の大/小文字区別が有効になるのは、ホスト・オペレーティング・システムで有効な場合のみです。

複数の値を受け入れるパラメータの場合、アラート・ログから名前/値ペアを簡単にコピーして貼り付けられるように、複数行でパラメータを繰り返すことができます。この場合、各行には異なる値が含まれます。

control_files='/u01/app/oracle/oradata/orcl/control01.ctl'
control_files='/u01/app/oracle/oradata/orcl/control02.ctl'
control_files='/u01/app/oracle/oradata/orcl/control03.ctl'

複数の値を受け入れないパラメータを繰り返した場合、最後に指定した値のみが有効です。

関連項目:

親トピック: 初期化パラメータと初期化パラメータ・ファイルについて

初期化パラメータの式の設定

初期化パラメータの値を必要な数値、テキスト値または式に設定します。

Oracle Databaseリリース21c以降では、初期化パラメータの値を設定するときに式を使用できます。この式には、他の初期化パラメータと、次の中から1つ以上を含めることができます。

  • 算術演算子(+, -, *, /)
  • 環境変数
  • MINまたはMAXファンクション

例:

SGA_TARGET = SYSTEM_MEMORY * 0.4
PARALLEL_MAX_SERVERS = MAX(100, PROCESSES * 0.4)
DB_CREATE_FILE_DEST=$ORACLE_HOME/oracle/database_files

グローバル・データベース名の決定

グローバル・データベース名は、ユーザー指定のローカル・データベース名と、ネットワーク構造内でのデータベースの位置で構成されます。

  • DB_NAMEおよびDB_DOMAIN初期化パラメータを設定します。

データベース名のローカル名コンポーネントはDB_NAME初期化パラメータによって決定し、ネットワーク構造内のドメイン(論理的な位置)はオプションで指定できるDB_DOMAINパラメータによって決定します。これら2つのパラメータの設定を組み合せて、ネットワーク内で一意になるデータベース名を形成する必要があります。

たとえば、test.us.example.comというグローバル・データベース名を持つデータベースを作成するには、新しいパラメータ・ファイルのパラメータを次のように編集します。 

DB_NAME = test
DB_DOMAIN = us.example.com

ALTER DATABASE RENAME GLOBAL_NAME文を使用すると、データベースのGLOBAL_NAMEを変更できます。ただし、最初にDB_NAMEおよびDB_DOMAIN初期化パラメータを変更し、制御ファイルを再作成した後に、データベースを停止して再起動する必要があります。制御ファイルの再作成は、ALTER DATABASE BACKUP CONTROLFILE TO TRACEコマンドで簡単に行えます。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

  • DB_NAME初期化パラメータ
    データベース識別子はDB_NAME初期化パラメータで指定します。
  • DB_DOMAIN初期化パラメータ
    分散データベース・システムでは、DB_DOMAIN初期化パラメータには、ネットワーク構造内でのデータベースの論理上の位置を指定します。

関連項目:

データベース名の別の変更手段であるDBNEWIDユーティリティの使用方法は、『Oracle Databaseユーティリティ』を参照してください。

親トピック: 初期化パラメータの指定

DB_NAME初期化パラメータ

データベース識別子はDB_NAME初期化パラメータで指定します。

DB_NAMEには、8文字以内のテキスト文字列を設定する必要があります。データベース名はアルファベットで開始する必要があります。DB_NAMEに指定した名前は、データベースの作成時に、データベースのデータファイル、REDOログ・ファイルおよび制御ファイルに記録されます。データベース・インスタンスの起動時に、(パラメータ・ファイル内の)DB_NAMEパラメータの値と制御ファイル内のデータベース名が一致しないと、データベースは起動しません。

DB_DOMAIN初期化パラメータ

分散データベース・システムでは、DB_DOMAIN初期化パラメータには、ネットワーク構造内でのデータベースの論理上の位置を指定します。

DB_DOMAINは、データベースが作成されるネットワーク・ドメインを指定するテキスト文字列です。作成しようとしているデータベースが分散データベース・システムの一部である場合は、データベースを作成する前に、この初期化パラメータに特に注意してください。このパラメータは省略可能です。

関連項目:

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

親トピック: グローバル・データベース名の決定

高速リカバリ領域の指定

高速リカバリ領域とは、Oracle Databaseでバックアップおよびリカバリに関連するファイルを格納および管理できる場所のことです。これは、現在のデータベース・ファイル(データファイル、制御ファイルおよびオンラインREDOログ)の場所であるデータベース領域とは別です。

高速リカバリ領域を指定するには、次の初期化パラメータを使用します。

  • DB_RECOVERY_FILE_DEST: 高速リカバリ領域の場所。ディレクトリ、ファイル・システムまたは自動ストレージ管理(Oracle ASM)のディスク・グループです。

    Oracle Real Application Clusters(Oracle RAC)環境では、この位置はクラスタ・ファイル・システム、Oracle ASMディスク・グループ、またはNFSを介して構成された共有ディレクトリであることが必要です。

  • DB_RECOVERY_FILE_DEST_SIZE: 高速リカバリ領域で使用される最大総バイト数を指定します。この初期化パラメータは、DB_RECOVERY_FILE_DESTを使用可能にする前に指定する必要があります。

Oracle RAC環境では、これら2つのパラメータの設定がすべてのインスタンスで同じであることが必要です。

これらのパラメータは、LOG_ARCHIVE_DESTおよびLOG_ARCHIVE_DUPLEX_DESTパラメータの値を設定している場合は使用可能にできません。高速リカバリ領域を設定する前に、これらのパラメータを使用禁止にする必要があります。かわりに、LOG_ARCHIVE_DEST_nパラメータの値を設定できます。

高速リカバリ領域によってデータベースのバックアップ操作およびリカバリ操作が簡素化されるため、この領域を使用することをお薦めします。

関連項目:

高速リカバリ領域の作成方法と使用方法を学習するには、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

親トピック: 初期化パラメータの指定

制御ファイルの指定

すべてのデータベースには、データベースの構造(名前、作成時のタイムスタンプ、データ・ファイルおよびREDOファイルの名前や場所など)を記述する制御ファイルがあります。CONTROL_FILES初期化パラメータには、1つ以上の制御ファイル名をカンマで区切って指定します。

  • CONTROL_FILES初期化パラメータを設定します。

CREATE DATABASE文を実行すると、CONTROL_FILESパラメータに記述した制御ファイルが作成されます。

初期化パラメータ・ファイルにCONTROL_FILESを指定しないと、オペレーティング・システム固有のデフォルト・ファイル名を使用して、初期化パラメータ・ファイルと同じディレクトリにOracle Databaseが制御ファイルを作成します。Oracle Managed Filesが使用可能な場合は、Oracle Managed Filesの制御ファイルが作成されます。

データベース用の制御ファイルを作成するときに新しいオペレーティング・システム・ファイルを作成する場合は、CONTROL_FILESパラメータに記述されているファイル名がシステム上に現在存在するいずれのファイル名とも一致しないことを確認してください。データベース用の制御ファイルを作成するときに既存のファイルを再利用または上書きする場合は、CONTROL_FILESパラメータに記述されているファイル名が、再利用されるファイル名と一致することを確認し、CREATE DATABASE文にCONTROLFILE REUSE句を指定します。

データベースごとに、少なくとも2つの制御ファイルを別々の物理ディスク・ドライブに格納して使用することをお薦めします。

関連項目:

親トピック: 初期化パラメータの指定

データベース・ブロック・サイズの指定

DB_BLOCK_SIZE初期化パラメータは、データベースの標準ブロック・サイズを指定します。

  • DB_BLOCK_SIZE初期化パラメータを設定します。

このブロック・サイズはSYSTEM表領域に使用され、その他の表領域ではデフォルトで使用されます。Oracle Databaseは、最大4つの非標準ブロック・サイズをサポートします。

親トピック: 初期化パラメータの指定

DB_BLOCK_SIZE初期化パラメータ

標準ブロック・サイズには、最も一般的に使用するブロック・サイズを選択します。多くの場合、設定が必要なブロック・サイズはこれのみです。

  • DB_BLOCK_SIZE初期化パラメータを設定します。

通常、DB_BLOCK_SIZEは4Kまたは8Kに設定します。このパラメータの値を指定しないと、オペレーティング・システム固有のデフォルト・データ・ブロック・サイズが使用されますが、大抵の場合、このデフォルト・ブロック・サイズで十分です。

データベースの作成後は、データベースを再作成する以外にブロック・サイズを変更する方法はありません。データベースのブロック・サイズがオペレーティング・システムのブロック・サイズと異なる場合は、データベースのブロック・サイズがオペレーティング・システムのブロック・サイズの倍数であることを確認してください。たとえば、使用しているオペレーティング・システムのブロック・サイズが2KB(2048バイト)の場合、次のDB_BLOCK_SIZE初期化パラメータの設定は有効です。 

DB_BLOCK_SIZE=4096

データ・ブロック・サイズを大きくすると、ディスクとメモリーのI/O(データのアクセスと格納)の効率が向上します。したがって、次の条件に該当する場合は、オペレーティング・システムのブロック・サイズより大きいブロック・サイズの指定を考慮してください。

  • Oracle Databaseが大容量メモリーと高速ディスク・ドライブを装備した大型コンピュータ・システム上にある場合。たとえば、莫大なハードウェア資源を有するメインフレーム・コンピュータによって制御されるデータベースは、通常4KB以上のデータ・ブロック・サイズを使用します。

  • Oracle Databaseが動作するオペレーティング・システムのブロック・サイズが小さい場合。たとえば、オペレーティング・システムのブロック・サイズが1KBで、この値がデフォルトのデータ・ブロック・サイズと一致する場合、データベースは通常の処理で過度のディスクI/Oを実行している可能性があります。この場合にパフォーマンスを最高にするには、データベース・ブロックを複数のオペレーティング・システム・ブロックから構成する必要があります。

    関連項目:

    デフォルトのブロック・サイズの詳細は、オペレーティング・システム固有のOracleマニュアルを参照してください。

非標準ブロック・サイズ

非標準ブロック・サイズの表領域を作成できます。

非標準ブロック・サイズの表領域を作成するには:

  • CREATE TABLESPACE文でBLOCKSIZE句を指定します。

これらの非標準ブロック・サイズには、2の累乗である2KB、4KB、8KB、16KB、32KBのいずれかを指定します。最大ブロック・サイズに関するプラットフォーム固有の制限が適用されるので、プラットフォームによっては、これらのサイズの一部は指定できない場合があります。

非標準ブロック・サイズを使用する場合は、使用するすべての非標準ブロック・サイズについて、SGAメモリーのバッファ・キャッシュ領域内にサブキャッシュを構成する必要があります。これらのサブキャッシュの構成に使用される初期化パラメータは、Oracle Database管理者ガイドで説明されています。

データベースに複数のブロック・サイズを指定できる機能は、特にデータベース間で表領域をトランスポートする場合に役立ちます。たとえば、OLTP環境から、8KBの標準ブロック・サイズを使用するデータ・ウェアハウス環境に、4KBのブロック・サイズを使用する表領域をトランスポートできます。

ノート:

32KBのブロック・サイズは、64ビットのプラットフォームでのみ有効です。

注意:

セクター・サイズが4KBのディスクを使用している場合、パフォーマンスが低下する可能性があるため、2KBのブロック・サイズを指定することはお薦めしません。詳細は、Oracle Database管理者ガイドを参照してください。

最大プロセス数の指定

Oracle Databaseに同時に接続できるオペレーティング・システム・プロセスの最大数は、PROCESSES初期化パラメータによって決定します。

  • PROCESSES初期化パラメータを設定します。

このパラメータの値は、最低でも各バックグラウンド・プロセスごとに1つ、および各ユーザー・プロセスごとに1つです。バックグラウンド・プロセスの数は、使用しているデータベースの機能によって異なります。たとえば、アドバンスト・キューイングまたはファイル・マッピング機能を使用している場合は、追加のバックグラウンド・プロセスが必要です。自動ストレージ管理を使用している場合は、データベース・インスタンス用に追加プロセスを3つ追加します。

50のユーザー・プロセスを実行する予定の場合は、PROCESSES初期化パラメータの値を70に見積もって設定することをお薦めします。

親トピック: 初期化パラメータの指定

DDLロック・タイムアウトの指定

ブロッキングDDL文がロックを待機する時間を指定できます。

データ定義言語(DDL)文は非ブロッキングまたはブロッキングのいずれかで、どちらのタイプのDDL文にも内部構造の排他ロックが必要です。DDL文の実行時にこのようなロックが使用できない場合、非ブロッキングDDL文とブロッキングDDL文の動作は異なります。

  • 非ブロッキングDDLは、DDLの影響を受けるオブジェクトを参照している同時DMLトランザクションがすべてコミットするかロール・バックするまで待機します。

  • ブロッキングDDLは、ロックが使用できるようになった直後に実行していれば成功するような場合でも失敗します。

ブロッキングDDL文でロックを待機できるようにするには、DDLロック・タイムアウトを指定します。これは、DDLコマンドが必要なロックを待機する秒数であり、この秒数を超えるとDDL文は失敗します。

  • DDLロック・タイムアウトを指定するには、DDL_LOCK_TIMEOUTパラメータを設定します。

設定可能なDDL_LOCK_TIMEOUTの値の範囲は、0から1,000,000です。デフォルトは0です。DDL_LOCK_TIMEOUTは、ALTER SESSION文を使用して、システム・レベルまたはセッション・レベルで設定できます。

ノート:

DDL_LOCK_TIMEOUTパラメータは、非ブロッキングDDL文に作用しません。

関連項目:

親トピック: 初期化パラメータの指定

UNDO領域管理方法の指定

すべてのOracle Databaseには、データベースの変更を取り消すために使用する情報の管理方法が必要です。これらの情報は、主にコミットされる前のトランザクションの処理レコードから構成されます。これらのレコードを総称してUNDOデータと呼びます。

UNDO表領域を使用する自動UNDO管理用の環境を設定する手順。

  • UNDO_MANAGEMENT初期化パラメータをデフォルトのAUTOに設定します。

  • UNDO_MANAGEMENT初期化パラメータ
    UNDO_MANAGEMENT初期化パラメータでは、インスタンスを自動UNDO管理モード(UNDOがUNDO表領域に格納されます)で起動するかどうかを指定します。自動UNDO管理モードを使用可能にするには、このパラメータをAUTOに設定します。パラメータを省略するか、NULLにすると、デフォルトでAUTOになります。
  • UNDO_TABLESPACE初期化パラメータ
    UNDO_TABLESPACE初期化パラメータでは、インスタンスのデフォルトのUNDO表領域をオーバーライドできます。

関連項目:

Oracle Database管理者ガイド

親トピック: 初期化パラメータの指定

UNDO_MANAGEMENT初期化パラメータ

UNDO_MANAGEMENT初期化パラメータでは、インスタンスを自動UNDO管理モード(UNDOがUNDO表領域に格納されます)で起動するかどうかを指定します。自動UNDO管理モードを使用可能にするには、このパラメータをAUTOに設定します。パラメータを省略するか、NULLにすると、デフォルトでAUTOになります。

UNDO_TABLESPACE初期化パラメータ

UNDO_TABLESPACE初期化パラメータでは、インスタンスのデフォルトのUNDO表領域をオーバーライドできます。

インスタンスを自動UNDO管理モードで起動すると、そのインスタンスは、UNDOデータを格納するためのUNDO表領域を選択しようとします。自動UNDO管理モードでデータベースが作成されている場合は、デフォルトのUNDO表領域(システム生成のSYS_UNDOTBS表領域またはユーザー指定のUNDO表領域)が、インスタンス起動時に使用されるUNDO表領域となります。インスタンスに対するこのデフォルトは、UNDO_TABLESPACE初期化パラメータに値を指定することで上書きできます。このパラメータは特に、Oracle Real Application Clusters環境のインスタンスに特定のUNDO表領域を割り当てる際に役立ちます。

UNDO表領域がUNDO_TABLESPACE初期化パラメータによって指定されていない場合は、データベース内で最初に使用可能なUNDO表領域が選択されます。使用可能なUNDO表領域がない場合、インスタンスはUNDO表領域のない状態で起動し、UNDOデータはSYSTEM表領域に書き込まれます。このモードでは実行しないようにしてください。

ノート:

CREATE DATABASE文を使用してデータベースを作成するときには、UNDO_TABLESPACEパラメータを初期化パラメータ・ファイルに指定しないでください。かわりに、UNDO TABLESPACE句をCREATE DATABASE文に指定します。

データベースの互換性レベルの指定

データベースの互換レベルは、COMPATIBLE初期化パラメータによって制御されます。

  • COMPATIBLE初期化パラメータをリリース番号に設定します。

  • COMPATIBLE初期化パラメータについて
    COMPATIBLE初期化パラメータによって、ディスクのファイル形式に影響を与える機能の使用をデータベースで使用可能または使用不可にできます。たとえば、Oracle Database 19cデータベースを作成しても、初期化パラメータ・ファイルにCOMPATIBLE=12.0.0を指定すると、Oracle Database 19cとの互換性が必要な機能の使用を試行した場合にエラーが生成されます。これは、データベースが12.0.0互換性レベルにあるとみなされているためです。

親トピック: 初期化パラメータの指定

COMPATIBLE初期化パラメータについて

COMPATIBLE初期化パラメータによって、ディスクのファイル形式に影響を与える機能の使用をデータベースで使用可能または使用不可にできます。たとえば、Oracle Database 19cデータベースを作成しても、初期化パラメータ・ファイルにCOMPATIBLE=12.0.0を指定すると、Oracle Database 19cとの互換性が必要な機能の使用を試行した場合にエラーが生成されます。これは、データベースが12.0.0互換性レベルにあるとみなされているためです。

COMPATIBLE初期化パラメータを変更することによって、データベースの互換性レベルを上げることができます。このようにすると、設定した互換性レベルよりも低いレベルではデータベースを起動できなくなりますが、互換性を上げる前の時点にPoint-in-Timeリカバリを実行することはできます。

COMPATIBLEパラメータのデフォルト値は、主要な最新リリースの番号です。

ノート:

  • このパラメータをALTER SYSTEM文を使用してサーバー・パラメータ・ファイル(SPFILE)に設定する場合、SCOPE=SPFILEを指定し、データベースを再起動して変更を有効にする必要があります。

  • COMPATIBLE初期化パラメータは、19.0.0のように、ドットで区切られた3桁以上の数字として指定する必要があります。

関連項目:

親トピック: データベースの互換性レベルの指定

ライセンスに関するパラメータの設定

指名ユーザー・ライセンスを使用している場合、Oracle Databaseではこの形式のライセンスを施行できます。データベース内に作成するユーザーの数に対して、制限を設定できます。この制限に達すると、それ以上のユーザーは作成できません。

ノート:

このメカニズムでは、データベースにアクセスする人がそれぞれ一意のユーザー名を持ち、ユーザー名を共有していないものと想定しています。したがって、指名ユーザー・ライセンスによってOracleのライセンス契約に従っていることを保証できるように、複数のユーザーが同じ名前を使用してログインすることを許可しないでください。

データベースに作成するユーザー数を制限するには、そのデータベースの初期化パラメータ・ファイルにLICENSE_MAX_USERS初期化パラメータを設定します。

次の例は、LICENSE_MAX_USERS初期化パラメータを設定します。 

LICENSE_MAX_USERS = 200

ノート:

Oracleでは、同時セッションの数によるライセンス提供がなくなりました。したがって、LICENSE_MAX_SESSIONSおよびLICENSE_SESSIONS_WARNING初期化パラメータは不要のため、非推奨になりました。

親トピック: 初期化パラメータの指定

サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

Oracle Databaseの初期化パラメータは、テキスト形式の初期化パラメータ・ファイルに格納されていました。管理性を向上させるために、データベースを起動および停止している間も持続するバイナリ形式のサーバー・パラメータ・ファイルによる初期化パラメータのメンテナンスを選択できます。

  • サーバー・パラメータ・ファイルの概要
    サーバー・パラメータ・ファイルは、Oracle Databaseサーバーが稼働するシステムで管理される初期化パラメータのリポジトリと考えられます。これは、サーバー側の初期化パラメータ・ファイルとして設計されています。
  • サーバー・パラメータ・ファイルへの移行
    現在、テキスト形式の初期化パラメータ・ファイルを使用している場合は、サーバー・パラメータ・ファイルに移行できます。
  • サーバー・パラメータ・ファイルのデフォルトの名前と場所
    SPFILEの名前と格納場所には、データベースによるデフォルト設定を使用することをお薦めします。これにより、データベースの管理が容易になります。たとえば、STARTUPコマンドはこのデフォルトの場所を想定して、SPFILEを読み込みます。
  • サーバー・パラメータ・ファイルの作成
    サーバー・パラメータ・ファイルを作成するには、CREATE SPFILE文を使用します。この文を実行するには、SYSDBA、SYSOPERまたはSYSBACKUP管理権限が必要です。
  • SPFILE初期化パラメータ
    SPFILE初期化パラメータには、現在のサーバー・パラメータ・ファイルの名前を指定します。
  • 初期化パラメータ値の変更
    データベース・インスタンスの操作に影響するように初期化パラメータ値を変更できます。
  • 初期化パラメータ値のクリア
    ALTER SYSTEM RESET文を使用すると、初期化パラメータ値をクリアできます。これを行うと、初期化パラメータ値はデフォルト値または開始値に変更されます。
  • サーバー・パラメータ・ファイルのエクスポート
    CREATE PFILE文を使用すると、サーバー・パラメータ・ファイル(SPFILE)をテキスト形式の初期化パラメータ・ファイルにエクスポートできます。
  • サーバー・パラメータ・ファイルのバックアップの作成
    サーバー・パラメータ・ファイル(SPFILE)をエクスポートすることでバックアップを作成できます。データベースのバックアップおよびリカバリ計画がRecovery Manager(RMAN)を使用して実装されている場合は、RMANを使用してSPFILEのバックアップを作成できます。SPFILEのバックアップは、データベースのバックアップ作成時にRMANにより自動的に作成されますが、RMANを使用すると現在アクティブになっているSPFILEのバックアップも作成できます。
  • 失われたまたは破損したサーバー・パラメータ・ファイルのリカバリ
    サーバー・パラメータ・ファイル(SPFILE)をリカバリできます。サーバー・パラメータ・ファイル(SPFILE)が失われるかまたは破損した場合は、現行インスタンスが失敗するか、またはデータベース・インスタンス起動時の次回の試行が失敗する可能性があります。
  • パラメータ設定を表示する方法
    いくつかの異なる方法を使用してパラメータ設定を表示できます。

親トピック: CDBの作成: 高度なトピック

サーバー・パラメータ・ファイルの概要

サーバー・パラメータ・ファイルは、Oracle Databaseサーバーが稼働するシステムで管理される初期化パラメータのリポジトリと考えられます。これは、サーバー側の初期化パラメータ・ファイルとして設計されています。

サーバー・パラメータ・ファイルに格納された初期化パラメータは持続性があり、インスタンスの実行中に加えられたパラメータへの変更はインスタンスの停止から起動までの間も持続します。この配置によって、ALTER SYSTEM文による変更を持続させるために、初期化パラメータを手動で更新する必要がなくなります。また、Oracle Databaseサーバーによる自己チューニングの基礎ともなります。

最初のサーバー・パラメータ・ファイルは、CREATE SPFILE文を使用して、テキスト形式の初期化パラメータ・ファイルから作成します。(Database Configuration Assistantで直接作成することもできます。)サーバー・パラメータ・ファイルは、テキスト・エディタで編集できないバイナリ・ファイルです。Oracle Databaseには、サーバー・パラメータ・ファイル内のパラメータの設定を表示および変更するために、他のインタフェースが用意されています。

ノート:

テキスト・エディタでバイナリ形式のサーバー・パラメータ・ファイルをオープンし、そのテキストを表示することは可能ですが、手動で編集しないでください。手動で編集すると、ファイルが破損します。また、インスタンスが起動できなくなり、たとえインスタンスが起動しても失敗します。

PFILE句を指定せずにSTARTUPコマンドを発行すると、Oracleインスタンスは、オペレーティング・システム固有のデフォルトの位置でサーバー・パラメータ・ファイルを検索し、そのファイルから初期化パラメータの設定を読み込みます。サーバー・パラメータ・ファイルが見つからない場合は、テキスト形式の初期化パラメータ・ファイルを検索します。サーバー・パラメータ・ファイルがあってもテキスト形式の初期化パラメータ・ファイルの設定を優先する場合は、STARTUPコマンドの発行時にPFILE句を指定する必要があります。

関連項目:

CDBの起動

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

サーバー・パラメータ・ファイルへの移行

現在、テキスト形式の初期化パラメータ・ファイルを使用している場合は、サーバー・パラメータ・ファイルに移行できます。

サーバー・パラメータ・ファイルへ移行するには:

  1. 初期化パラメータ・ファイルがクライアント・システム上にある場合は、FTPなどを使用して、クライアント・システムからサーバー・システムにファイルを転送してください。

    ノート:

    Oracle Real Application Clusters環境でサーバー・パラメータ・ファイルに移行する場合は、インスタンス固有のすべての初期化パラメータ・ファイルを、1つの初期化パラメータ・ファイルに結合する必要があります。この操作の方法、およびOracle Real Application Clustersのインストールの一部であるインスタンスでサーバー・パラメータ・ファイルを使用する際の固有の処理については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』および使用しているプラットフォーム固有のOracle Real Application Clustersインストレーション・ガイドを参照してください。

  2. CREATE SPFILE FROM PFILE文を使用して、デフォルト位置にサーバー・パラメータ・ファイルを作成します。詳細は、「サーバー・パラメータ・ファイルの作成」を参照してください。

    この文を実行すると、テキスト形式の初期化パラメータ・ファイルが読み込まれて、サーバー・パラメータ・ファイルが作成されます。CREATE SPFILE文を発行するために、データベースを起動する必要はありません。

  3. インスタンスを起動または再起動します。

    インスタンスはデフォルト位置にある新規SPFILEを検出し、そのファイルを使用して起動します。

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

サーバー・パラメータ・ファイルのデフォルトの名前と場所

SPFILEの名前と格納場所には、データベースによるデフォルト設定を使用することをお薦めします。これにより、データベースの管理が容易になります。たとえば、STARTUPコマンドはこのデフォルトの場所を想定して、SPFILEを読み込みます。

次の表は、UNIX、LinuxおよびWindowsのプラットフォームごとに、テキスト形式の初期化パラメータ・ファイル(PFILE)とサーバー・パラメータ・ファイル(SPFILE)の両方のデフォルトの名前と場所を示しています(Oracle Automatic Storage Management(Oracle ASM)を使用する場合と使用しない場合について)。この表では、SPFILEをファイルと想定しています。

表4-1 UNIX、LinuxおよびWindowsにおけるPFILEおよびSPFILEのデフォルトの名前と場所

プラットフォーム PFILEのデフォルト名 SPFILEのデフォルト名 PFILEのデフォルトの場所 SPFILEのデフォルトの場所

UNIXおよびLinux

initORACLE_SID.ora

spfileORACLE_SID.ora

ORACLE_BASE_CONFIG/dbsまたはデータファイルと同じ場所

Oracle ASMを使用しない場合:

ORACLE_BASE_CONFIG/dbsまたはデータファイルと同じ場所

Oracle ASMを使用する場合:

データファイルと同じディスク・グループ(データベースがDBCAによって作成されたことを想定)

Windows

initORACLE_SID.ora

spfileORACLE_SID.ora

Oracle_Home\database

Oracle ASMを使用しない場合:

OH\database

Oracle ASMを使用する場合:

データファイルと同じディスク・グループ(データベースがDBCAによって作成されたことを想定)

ノート:

起動時に、インスタンスは最初にspfileORACLE_SID.oraという名前のSPFILEを検索し、見つからない場合はspfile.oraを検索します。spfile.oraを使用すると、すべてのReal Application Clusters(Oracle RAC)インスタンスで同じサーバー・パラメータ・ファイルを使用できます。

いずれのSPFILEも見つからない場合、インスタンスはテキスト形式の初期化パラメータ・ファイルinitORACLE_SID.oraを検索します。

デフォルトの場所以外の場所にSPFILEを作成する場合は、デフォルトのPFILEの場所に、そのサーバー・パラメータ・ファイルを指し示すスタブPFILEを作成する必要があります。詳細は、「データベースの起動」を参照してください。

Oracle ASMが存在する場合にDBCAを使用してデータベースを作成すると、DBCAによってSPFILEはOracle ASMディスク・グループ内に配置され、このスタブPFILEも作成されます。

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

サーバー・パラメータ・ファイルの作成

サーバー・パラメータ・ファイルを作成するには、CREATE SPFILE文を使用します。この文を実行するには、SYSDBA、SYSOPERまたはSYSBACKUP管理権限が必要です。

サーバー・パラメータ・ファイルを作成するには:

  • CREATE SPFILE文を実行します。

ノート:

Database Configuration Assistantを使用してデータベースを作成した場合は、サーバー・パラメータ・ファイルが自動的に作成されます。

CREATE SPFILE文は、インスタンスの起動前後に実行できます。ただし、すでにサーバー・パラメータ・ファイルを使用してインスタンスを起動している場合に、インスタンスで現在使用されているのと同じサーバー・パラメータ・ファイルを再作成しようとすると、エラーが発生します。

サーバー・パラメータ・ファイル(SPFILE)は、既存のテキスト形式の初期化パラメータ・ファイルまたはメモリーから作成できます。メモリーからのSPFILEの作成では、実行中のインスタンス内の初期化パラメータの現行値をSPFILEにコピーします。

次の例では、テキスト形式の初期化パラメータ・ファイル/u01/oracle/dbs/init.oraからサーバー・パラメータ・ファイルを作成しています。この例ではSPFILEの名前を指定していないため、ファイルは、表4-1に示したプラットフォーム固有のデフォルトの名前と場所で作成されます。 

CREATE SPFILE FROM PFILE='/u01/oracle/dbs/init.ora';

次の例では、名前と場所を指定してサーバー・パラメータ・ファイルを作成しています。

CREATE SPFILE='/u01/oracle/dbs/test_spfile.ora'
       FROM PFILE='/u01/oracle/dbs/test_init.ora';

次の例では、メモリー内の初期化パラメータの現行値から、デフォルトの場所にサーバー・パラメータ・ファイルを作成しています。

CREATE SPFILE FROM MEMORY;

デフォルトのSPFILE名と場所を使用するか、SPFILE名と場所を指定するかどうかに関係なく、同じ名前のSPFILEがその場所にすでに存在する場合は、警告メッセージなしに上書きされます。

テキスト形式の初期化パラメータ・ファイルからSPFILEを作成すると、初期化パラメータ・ファイル内のパラメータ設定と同じ行に記述されているコメントもSPFILEで管理されます。他のコメントはすべて無視されます。

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

SPFILE初期化パラメータ

SPFILE初期化パラメータには、現在のサーバー・パラメータ・ファイルの名前を指定します。

データベースでデフォルトのサーバー・パラメータ・ファイルが使用されている場合(つまり、PFILEパラメータを指定せずにSTARTUPコマンドを発行した場合)、SPFILEの値はサーバーによって内部的に設定されます。SQL*PlusコマンドのSHOW PARAMETERS SPFILE(またはパラメータの値を問い合せる他の方法)を使用すると、現在使用中のサーバー・パラメータ・ファイルの名前が表示されます。

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

初期化パラメータ値の変更

データベース・インスタンスの操作に影響する初期化パラメータ値を変更できます。

  • 初期化パラメータ値の変更について
    ALTER SYSTEM文を使用すると、初期化パラメータ値を設定、変更またはデフォルトにリストアできます。テキスト形式の初期化パラメータ・ファイルを使用している場合、現行のインスタンスに対するパラメータの値のみALTER SYSTEM文で変更されます。これは、ディスク上のテキスト形式の初期化パラメータを自動的に更新するメカニズムがないためです。以後のインスタンスに渡すためには、ディスク上の初期化パラメータを手動で更新する必要があります。サーバー・パラメータ・ファイルを使用している場合は、このような制限はありません。
  • 初期化パラメータ値の設定または変更
    サーバー・パラメータ・ファイルで、ALTER SYSTEM文のSET句を使用して初期化パラメータ値を設定または変更します。

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

初期化パラメータ値の変更について

ALTER SYSTEM文を使用すると、初期化パラメータ値を設定、変更またはデフォルトにリストアできます。テキスト形式の初期化パラメータ・ファイルを使用している場合、現行のインスタンスに対するパラメータの値のみALTER SYSTEM文で変更されます。これは、ディスク上のテキスト形式の初期化パラメータを自動的に更新するメカニズムがないためです。以後のインスタンスに渡すためには、ディスク上の初期化パラメータを手動で更新する必要があります。サーバー・パラメータ・ファイルを使用している場合は、このような制限はありません。

初期化パラメータには、次の2種類があります。

  • 動的な初期化パラメータ: 現行のOracle Databaseインスタンスに対して変更できます。変更は即時に有効になります。

  • 静的な初期化パラメータ: 現行のインスタンスに対して変更できません。これらのパラメータはテキスト形式の初期化パラメータまたはサーバー・パラメータ・ファイルで変更し、変更を有効にするにはデータベースを再起動する必要があります。

初期化パラメータ値の設定または変更

サーバー・パラメータ・ファイルで、ALTER SYSTEM文のSET句を使用して初期化パラメータ値を設定または変更します。

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

たとえば、次の文は、接続を中断するまでのログイン試行の最大失敗回数を変更します。ここにはコメントが含まれており、変更をサーバー・パラメータ・ファイルにのみ適用することを明示しています。

ALTER SYSTEM SET SEC_MAX_FAILED_LOGIN_ATTEMPTS=3
                 COMMENT='Reduce from 10 for tighter security.'
                 SCOPE=SPFILE;

次の例では、属性のリストをとる複雑な初期化パラメータを設定しています。値を設定するパラメータは、LOG_ARCHIVE_DEST_n初期化パラメータです。この文によって、このパラメータの既存の設定を変更するか、または新しいアーカイブ先を作成できます。 

ALTER SYSTEM 
     SET LOG_ARCHIVE_DEST_4='LOCATION=/u02/oracle/rbdb1/',MANDATORY,'REOPEN=2'
         COMMENT='Add new destination on Nov 29'
         SCOPE=SPFILE;

値がパラメータのリストで構成されている場合は、位置または序数によって個々の属性を編集することはできません。パラメータを更新するたびに、完全な値のリストを指定する必要があります。これによって、新しいリストで古いリストが完全に置換されます。

  • ALTER SYSTEM SET文のSCOPE句
    ALTER SYSTEM SET文のオプションのSCOPE句では、初期化パラメータの変更のスコープを指定します。

親トピック: 初期化パラメータ値の変更

ALTER SYSTEM SET文のSCOPE句

ALTER SYSTEM SET文のオプションのSCOPE句では、初期化パラメータの変更のスコープを指定します。

SCOPE句 説明

SCOPE = SPFILE

サーバー・パラメータ・ファイルのみに変更が適用されます。その場合、それぞれ次のような結果になります。

  • 変更は現行インスタンスには適用されません。

  • 動的パラメータと静的パラメータの両方について、次の起動時に変更が有効になり、以後持続します。

静的パラメータでは、SCOPE指定のみ使用できます。

SCOPE = MEMORY

メモリーのみに変更が適用されます。その場合、それぞれ次のような結果になります。

  • 変更は現行インスタンスに適用され、即時に有効になります。

  • 動的パラメータの場合は、変更が即時に有効になりますが、サーバー・パラメータ・ファイルは更新されないので、変更は持続しません。

静的パラメータでは、この指定は使用できません。

SCOPE = BOTH

サーバー・パラメータ・ファイルとメモリーの両方に変更が適用されます。その場合、それぞれ次のような結果になります。

  • 変更は現行インスタンスに適用され、即時に有効になります。

  • 動的パラメータの場合は、サーバー・パラメータ・ファイルが更新されるので、変更が持続します。

静的パラメータでは、この指定は使用できません。

インスタンスがサーバー・パラメータ・ファイルを使用して起動していない場合にSCOPE=SPFILEまたはSCOPE=BOTHを指定すると、エラーが発生します。デフォルトは、インスタンス起動時にサーバー・パラメータ・ファイルを使用した場合はSCOPE=BOTH、テキスト形式の初期化パラメータ・ファイルを使用した場合はMEMORYになります。

動的パラメータの場合は、DEFERREDキーワードを指定することもできます。このキーワードを指定すると、これから確立するセッションでのみ変更が有効になります。

SCOPEをSPFILEまたはBOTHに指定した場合は、オプションのCOMMENT句を使用すると、パラメータの更新にテキスト文字列を関連付けることができます。サーバー・パラメータ・ファイルにコメントが記述されます。

初期化パラメータ値のクリア

ALTER SYSTEM RESET文を使用すると、初期化パラメータ値をクリアできます。これを行うと、初期化パラメータ値はデフォルト値または開始値に変更されます。

ALTER SYSTEM RESET文にはSCOPE句が含まれています。ALTER SYSTEM RESET文およびSCOPE句を非CDBまたはマルチテナント・コンテナ・データベース(CDB)ルートで実行した場合は、この文がプラガブル・データベース(PDB)、アプリケーション・ルートまたはアプリケーションPDBで実行された場合と異なる動作となります。

パラメータの開始値は、インスタンスの起動またはPDBのオープンが完了した後のメモリー内のパラメータの値です。この値は、起動直後にV$SYSTEM_PARAMETERビューのVALUE列およびDISPLAY_VALUE列に表示されます。パラメータの値は起動時に内部的に調整されることがあるため、開始値はspfileの値またはデフォルト値(spfileにパラメータが設定されていない場合)と異なる場合があります。

ALTER SYSTEM RESET文のSCOPE値は、非CDBおよびCDBのCDB$ROOTでは次のように動作します。

  • SCOPE=SPFILE: インスタンスでspfileが使用されている場合は、spfileからパラメータを削除します。次のインスタンスの起動時に、デフォルト値が有効になります。

  • SCOPE=MEMORY: 開始値がすぐに有効になります。ただし、変更はインスタンスのspfileに格納されず、インスタンスの再起動時に失われます。

  • SCOPE=BOTH: インスタンスでspfileが使用されている場合は、spfileからパラメータを削除します。デフォルト値が即座に有効になり、この変更はインスタンスを再起動しても維持されます。

ノート:

SCOPE=BOTHはSCOPE=MEMORYの動作を変更します。SCOPE=BOTHを発行すると、その後のSCOPE=MEMORYでは常にパラメータがデフォルト値にリセットされます。

ALTER SYSTEM RESET文のSCOPE値は、PDB、アプリケーション・ルートまたはアプリケーションPDBでは次のように動作します。

  • SCOPE=SPFILE: コンテナのspfileからパラメータを削除します。コンテナは次にPDBがオープンされたときにルートからパラメータ値を継承します。

  • SCOPE=MEMORY: 次に2つの例を示します。

    • パラメータはコンテナがオープンされたときにコンテナのspfileに存在します。パラメータ値はパラメータの開始値に更新されます。この変更はコンテナのspfileに格納されず、次にコンテナがオープンされたときに失われます。

    • パラメータはコンテナがオープンされたときにコンテナのspfileに存在しません。コンテナはルートからパラメータ値を継承して起動されます。

  • SCOPE=BOTH: コンテナのspfileからパラメータを削除します。コンテナはルートからパラメータ値を継承します。

ノート:

  • SCOPE=BOTHはSCOPE=MEMORYの動作を変更します。SCOPE=BOTHが発行された後にSCOPE=MEMORYが発行されると、コンテナは常にルートからパラメータ値を継承します。

  • コンテナがルートからパラメータ値を継承する場合、PDBはCDB$ROOTから値を継承します。アプリケーション・コンテナでは、アプリケーションPDBはアプリケーション・ルートからパラメータ値を継承し、アプリケーション・ルートはCDB$ROOTからパラメータ値を継承します。

関連項目:

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

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

サーバー・パラメータ・ファイルのエクスポート

CREATE PFILE文を使用すると、サーバー・パラメータ・ファイル(SPFILE)をテキスト形式の初期化パラメータ・ファイルにエクスポートできます。

  • CREATE PFILE文を実行します。

いくつかの理由でサーバー・パラメータ・ファイルのエクスポートが必要な場合があります。

  • 診断のために、現在インスタンスで使用しているすべてのパラメータのリストを作成する場合。これは、SQL*PlusのSHOW PARAMETERSコマンド、あるいはV$PARAMETERまたはV$PARAMETER2ビューの選択と同じです。

  • 最初にエクスポートし、結果のテキスト・ファイルを編集してから、CREATE SPFILE文を使用して再作成するという手順で、サーバー・パラメータ・ファイルを変更する場合

PFILE句にエクスポート・ファイルを指定して、インスタンスを起動することもできます。

CREATE PFILE文を実行するには、SYSDBA、SYSOPERまたはSYSBACKUP管理権限が必要です。エクスポート・ファイルは、データベース・サーバー・システム上に作成されます。そこには、パラメータ設定と同じ行に記述されているパラメータに関するコメントがすべて含まれます。

次の例では、SPFILEからテキスト形式の初期化パラメータ・ファイルを作成しています。

CREATE PFILE FROM SPFILE;

この例ではファイル名を指定していないため、プラットフォーム固有のデフォルト・サーバー・パラメータ・ファイルから、プラットフォーム固有の名前で初期化パラメータ・ファイルが作成されます。

次の例では、サーバー・パラメータ・ファイルからテキスト形式の初期化パラメータ・ファイルを作成していますが、複数のファイル名が指定されています。

CREATE PFILE='/u01/oracle/dbs/test_init.ora'
  FROM SPFILE='/u01/oracle/dbs/test_spfile.ora';

ノート:

メモリー内の初期化パラメータの現行値からPFILEを作成する方法もあります。次は、必要なコマンドの例です。

CREATE PFILE='/u01/oracle/dbs/test_init.ora' FROM MEMORY;

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

サーバー・パラメータ・ファイルのバックアップ

サーバー・パラメータ・ファイル(SPFILE)をエクスポートすることでバックアップを作成できます。データベースのバックアップおよびリカバリ計画がRecovery Manager(RMAN)を使用して実装されている場合は、RMANを使用してSPFILEのバックアップを作成できます。SPFILEのバックアップは、データベースのバックアップ作成時にRMANにより自動的に作成されますが、RMANを使用すると現在アクティブになっているSPFILEのバックアップも作成できます。

  • エクスポートするかRMANを使用してサーバー・パラメータ・ファイルをバックアップします。

関連項目:

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

失われたまたは破損したサーバー・パラメータ・ファイルのリカバリ

サーバー・パラメータ・ファイル(SPFILE)をリカバリできます。サーバー・パラメータ・ファイル(SPFILE)が失われるかまたは破損した場合は、現行インスタンスが失敗するか、またはデータベース・インスタンス起動時の次回の試行が失敗する可能性があります。

SPFILEをリカバリする方法は複数あります。

  • インスタンスが実行中の場合は、次のコマンドを発行して、メモリー内の初期化パラメータの現行値からSPFILEを再作成します。

    CREATE SPFILE FROM MEMORY;

    このコマンドでは、SPFILEはデフォルトの場所にデフォルトの名前で作成されます。新しい名前を使用して、または指定した場所にSPFILEを作成することもできます。例については、「サーバー・パラメータ・ファイルの作成」を参照してください。

  • 有効なテキスト形式の初期化パラメータ・ファイル(PFILE)がある場合は、次の文を使用してPFILEからSPFILEを再作成します。

    CREATE SPFILE FROM PFILE;

    このコマンドは、PFILEがデフォルトの場所にあり、デフォルトの名前であると想定しています。PFILEがデフォルト以外の場所にあるか、デフォルト以外の名前の場合に使用するコマンド構文については、「サーバー・パラメータ・ファイルの作成」を参照してください。

  • バックアップからSPFILEをリストアします。

    詳細は、「サーバー・パラメータ・ファイルのバックアップの作成」を参照してください。

  • これらのいずれの方法も使用できない状況の場合は、次のステップを実行します。

    1. アラート・ログのパラメータ値のリストからテキスト形式の初期化パラメータ・ファイル(PFILE)を作成します。

      インスタンスの起動時に、起動に使用された初期化パラメータがアラート・ログに書き込まれます。このセクションを(XMLタグが含まれていない)テキスト・バージョンのアラート・ログからコピーして、新規PFILEに貼り付けることができます。

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

    2. PFILEからSPFILEを作成します。

      詳細は、「サーバー・パラメータ・ファイルの作成」を参照してください。

パラメータ更新時の読取り/書込みエラー

パラメータの更新時にサーバー・パラメータ・ファイルの読込みまたは書込みでエラーが発生した場合は、アラート・ログにエラーが記録されて、サーバー・パラメータ・ファイルに対する後続のパラメータ更新がすべて無視されます。この時点では、次の処理のいずれかを実行できます。

  • インスタンスを停止し、この項の前述の説明に従ってサーバー・パラメータ・ファイルをリカバリした後、インスタンスを再起動します。

  • 後続のパラメータ更新を持続的にするための処置を講じない場合は、データベースの実行を継続します。

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

パラメータ設定を表示する方法

いくつかの異なる方法を使用してパラメータ設定を表示できます。

方法 説明

SHOW PARAMETERS

このSQL*Plusコマンドを使用すると、現行セッションで有効な初期化パラメータの値が表示されます。

SHOW SPPARAMETERS

このSQL*Plusコマンドを使用すると、サーバー・パラメータ・ファイル(SPFILE)の初期化パラメータの値が表示されます。

CREATE PFILE

このSQL文は、SPFILEまたは現在のインメモリー設定からテキスト形式の初期化パラメータ・ファイル(PFILE)を作成します。PFILEはテキスト・エディタで表示できます。

V$PARAMETER

このビューを使用すると、現行セッションで有効な初期化パラメータの値が表示されます。

V$PARAMETER2

このビューを使用すると、現行セッションで有効な初期化パラメータの値が表示されます。各リスト・パラメータ値が別々の行に出力されるため、このビューの方がリスト・パラメータ値を容易に識別できます。

V$SYSTEM_PARAMETER

このビューを使用すると、インスタンスで有効な初期化パラメータの値が表示されます。新しいセッションは、インスタンス全体の値からパラメータ値を継承します。

V$SYSTEM_PARAMETER2

このビューを使用すると、インスタンスで有効な初期化パラメータの値が表示されます。新しいセッションは、インスタンス全体の値からパラメータ値を継承します。各リスト・パラメータ値が別々の行に出力されるため、このビューの方がリスト・パラメータ値を容易に識別できます。

V$SPPARAMETER

このビューを使用すると、SPFILEの現在の内容が表示されます。インスタンスでSPFILEが使用されていない場合は、ISSPECIFIED列にFALSEが返されます。

関連項目:

ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

親トピック: サーバー・パラメータ・ファイルを使用した初期化パラメータの管理

データベース・サービスでのアプリケーション・ワークロードの管理

データベース・サービスは、1つ以上のデータベース・インスタンスをある単位にまとめて表現したものです。サービスを使用すれば、データベースのワークロードをグループ化し、特定の作業リクエストを適切なインスタンスにルーティングできます。

親トピック: CDBの作成: 高度なトピック

データベース・サービス

データベース・サービスは1つのデータベースを表します。このデータベースは、単一インスタンス・データベースか、または複数の同時データベース・インスタンスが含まれたOracle Real Application Clusters (Oracle RAC)データベースとなります。グローバル・データベース・サービスは、データ・レプリケーションを介して同期化された複数のデータベースが提供するサービスです。

親トピック: データベース・サービスでのアプリケーション・ワークロードの管理

データベース・サービスについて

データベース・サービスは、1つのデータベースのワークロードを互いに共通の要素を持たないグループに分割します。

各データベース・サービスは、一般的な属性、サービス・レベルしきい値および優先度でワークロードを表します。グループ化は作業の属性に基づいて行われますが、これらの属性には、使用するアプリケーション機能、アプリケーション機能を実行する場合の優先度、管理の対象になるジョブ・クラス、アプリケーション機能またはジョブ・クラスで使用するデータの範囲などが含まれていることがあります。たとえば、Oracle E-Business Suiteでは、総勘定元帳、売掛金勘定、受注など、職務ごとにサービスを定義します。データベース・サービスを構成するとき、一意の名前、関連するパフォーマンス目標および関連する重要性を各サービスに指定します。これらのデータベース・サービスは、Oracle Databaseと緊密に統合され、データ・ディクショナリに保持されます。

接続要求には、データベース・サービス名を指定できます。このように、中間層アプリケーションおよびクライアントとサーバーのアプリケーションでは、データベース・サービスをTNS接続データ内の接続の一部として指定することで、サービスを利用します。データベース・サービス名が指定されておらず、Net Servicesファイルlistener.oraにデフォルトのデータベース・サービスが指定されている場合は、デフォルトのデータベース・サービスを使用して接続されます。

データベース・サービスを使用すると、1つのデータベースのワークロードの構成、管理、有効化と無効化を実行でき、さらに単一エンティティとして測定できます。これは、Database Configuration Assistant (DBCA)、Oracle Net Configuration Assistant、Oracle Enterprise Manager Cloud Control (Cloud Control)などの標準的なツールを使用して実行できます。Cloud Controlは、表示と操作に関するサービスを全体としてサポートし、必要な場合はインスタンス・レベルへのドリルダウンをサポートしています。

Oracle Real Application Clusters(Oracle RAC)環境では、データベース・サービスは1つ以上のインスタンスにまたがり、トランザクション・パフォーマンスに基づいたワークロードの均衡化に役立ちます。この機能によって、エンドツーエンドの無人リカバリ、ワークロードによるロール変更、位置の完全な透過性が可能となります。また、Oracle RACを使用すると、Cloud Control、DBCAおよびServer Controlユーティリティ(SRVCTL)で複数のデータベース・サービス機能を管理できます。

データベース・サービスには、アプリケーション、アプリケーション機能およびデータの範囲が、機能サービスまたはデータ依存サービスとして記述されています。機能サービスは最も一般的なワークロードのマッピングです。特定の機能を使用する複数のセッションはまとめてグループ化されます。これに対して、データ依存ルーティングは、データ・キーに基づいてセッションをデータベース・サービスにルーティングします。作業要求のデータベース・サービスへのマッピングは、アプリケーション・サーバーとTPモニターのオブジェクト関連マッピング・レイヤーで発生します。たとえば、Oracle RACでは、データベースが共有されているため、これらの範囲は要求に基づいて完全に動的にできます。

アプリケーションにより使用されるデータベース・サービスに加えて、Oracle Databaseでは、2つの内部データベース・サービスもサポートされています。SYS$BACKGROUNDはバックグラウンド・プロセスのみで使用され、SYS$USERSはサービスに関連していないユーザー・セッションに対するデフォルトのデータベース・サービスです。

データベース・サービスを使用する場合にアプリケーション・コードを変更する必要はありません。クライアント側の作業は、指定したデータベース・サービスに接続できます。Oracle Scheduler、パラレル実行、Oracle Databaseアドバンスト・キューイングなどのサーバー側での作業では、ワークロード定義の一部としてデータベース・サービス名を設定します。データベース・サービス下で実行される作業要求は、そのサービスのパフォーマンスしきい値を継承し、サービスの一部として測定されます。

関連項目:

親トピック: データベース・サービス

データベース・サービスおよびパフォーマンス

データベース・サービスは、パフォーマンス・チューニングに追加のディメンションを提供します。

すべてのセッションを匿名で共有している大部分のシステムでは、「サービスとSQL」によるチューニングで「セッションとSQL」によるチューニングを置換できます。データベース・サービスを使用することで、ワークロードが表示可能および測定可能となります。リソースの使用と待機は、アプリケーションがその起因となっています。また、データベース・サービスに割り当てたリソースは、ロードの増減にあわせて調整できます。この動的なリソース割当てによって、要求の発生に対応した費用効率の高いソリューションが可能となります。たとえば、データベース・サービスを自動的に測定し、そのパフォーマンスをサービス・レベルのしきい値と比較できます。パフォーマンス違反はCloud Controlにレポートされるため、自動ソリューションまたはスケジュールされたソリューションを実行できます。

データベース・サービスを使用するOracle Databaseの機能

Oracle Database機能のいくつかは、データベース・サービスをサポートしています。

自動ワークロード・リポジトリ(AWR)は、サービスのパフォーマンスを管理します。AWRには、実行時間、待機クラスおよびサービスで使用されたリソースも含めて、データベース・サービスのパフォーマンスが記録されます。AWRは、データベース・サービス応答時間がしきい値を超えた場合、警告をアラートします。動的なビューには、現在のサービス・パフォーマンスのメトリックが時間の履歴単位でレポートされます。各データベース・サービスには、応答時間とCPU使用に関するサービス品質のしきい値があります。

さらに、データベース・リソース・マネージャでは、データベース・サービスをコンシューマ・グループにマッピングできます。これによって、データベース・サービスの優先度を他のサービスと関連させて自動的に管理できます。コンシューマ・グループを使用すると、比率またはリソース使用量の観点から相対的な優先順序を定義できます。

データベース・サービスのエディション属性を指定することもできます。エディションを使用すると、データベース内に同じオブジェクトの複数のバージョンを保持できます。データベース・サービスにエディションを指定すると、そのデータベース・サービスを指定するそれ以降のすべて接続で、初期セッション・エディションとしてこのエディションが使用されます。

エディションをデータベース・サービス属性として指定すると、リソース使用の管理が容易になります。たとえば、1つのエディションに関連付けられた複数のデータベース・サービスを1つのOracle RAC環境における個別のインスタンスに配置でき、データベース・リソース・マネージャは、リソース・プランを対応するデータベース・サービスに関連付けることによって、異なるエディションで使用されているリソースを管理できます。

Oracle Schedulerでは、ジョブ・クラスの作成時にオプションでデータベース・サービスを割り当てることができます。実行中に複数のジョブがジョブ・クラスに割り当てられ、データベース・サービス内で複数のジョブ・クラスを実行できます。ジョブ・クラスとともにデータベース・サービスを使用することで、ジョブ・スケジューラによって実行される作業が、ワークロード管理とパフォーマンス・チューニングに対して示されます。

パラレル問合せとパラレルDMLの場合、問合せコーディネータは他のクライアントと同じようにデータベース・サービスに接続します。パラレル問合せプロセスは、実行中そのデータベース・サービスを継承します。問合せが終了した時点で、パラレル実行プロセスはデフォルトのデータベース・サービスに戻ります。

データベース・サービスの作成

データベース・サービスの作成方法はデータベースの構成によっていくつかあります。

ノート:

Oracle Database 19c以降、SERVICE_NAMESパラメータをお客様が使用することは非推奨になりました。今後のリリースでサポートが終了する可能性があります。サービスを管理するには、SRVCTLまたはGDSCTLコマンドライン・ユーティリティ、またはDBMS_SERVICEパッケージを使用することをお薦めします。

ノート:

この項では、ローカルでのサービスの作成について説明します。

データベース・サービスを作成するには:

  • 単一インスタンスのデータベースをOracle Restartで管理している場合は、SRVCTLユーティリティを使用してデータベース・サービスを作成します。 

    srvctl add service -db db_unique_name -service service_name

  • Oracle Restartで管理していない単一インスタンスのデータベースでは、次のいずれかを実行します。

    • SERVICE_NAMESパラメータに希望するデータベース・サービス名を追加します。

    • DBMS_SERVICE.CREATE_SERVICEパッケージ・プロシージャをコールします。

  • (オプション)データベース・サービス属性をCloud ControlまたはDBMS_SERVICE.MODIFY_SERVICEで定義します。

Oracle Netリスナー(リスナー)はクライアントからの着信接続要求を受信し、データベース・サーバーへのこれらの要求のトラフィックを管理します。リスナーは、登録済サービスの接続を処理し、動的サービス登録をサポートしています。

関連項目:

親トピック: データベース・サービス

グローバル・データ・サービス

Oracle Database 12cからは、複数のOracle Databaseが関連するワークロードを管理するために、グローバル・データ・サービス(GDS)を使用できます。

GDSを使用すると、管理者は、共通のサービスを提供する複数のレプリケート・データベースにまたがるクライアント・ワークロードを自動的かつ透過的に管理できます。これらの共通サービスは、グローバル・サービスと呼ばれます。

GDSにより、様々な場所に存在する複数のデータベースを、グローバル・クライアントが共有できるプライベートGDS構成に統合できます。次の利点があります。

  • グローバル・リソースの集中管理が可能になります。

  • グローバルなスケーラビリティ、可用性およびランタイム・ロード・バランシングを提供します。

  • データベースをGDS構成に動的に追加したり、グローバル・サービスを動的に移行できます。

  • Oracle Active Data Guard、Oracle GoldenGateなどの機能を使用するレプリケート・データベースの分散環境でのサービス管理、ロード・バランシングおよびフェイルオーバーの各機能を拡張します。

  • (ローカルまたはグローバルの両方に配置された)複数のデータベースをまたいで、グローバル・サービスをシームレスにフェイルオーバーすることによって、高可用性を提供します。

  • サービス、接続ロード・バランシングおよびランタイム・ロード・バランシングにより、データ・センター内およびデータ・センター間の両方でのワークロード・バランシングを提供します。

  • サービス・クライアントの要求に応じて、GDS構成のリソースを効率的に使用できます。

関連項目:

グローバル・データ・サービスの概要については、Oracle Databaseグローバル・データベース・サービス概要および管理ガイドを参照してください

親トピック: データベース・サービスでのアプリケーション・ワークロードの管理

データベース・セッション状態のリセットによるアプリケーションの状態リークの防止

RESET_STATEサービス属性を使用すると、リクエストでアプリケーションによって設定されたセッション状態が、リクエスト終了時にクリアされます。

サービス属性RESET_STATEは、セッション状態のリークによるそれ以降の再利用を防ぐために、すべてのステートレス・アプリケーションに対して推奨されています。

ステートレス・アプリケーション

ステートレス・アプリケーションとは、リクエストのセッション状態(そのセッションの以前の使用で設定された、コンテキストやPL/SQLの状態など)が別のWebリクエストや同様の接続プール利用で使用されないアプリケーション・プログラムです。リクエストを処理するために必要な状態は、そのリクエスト自体の一部として、そのリクエスト内(URL、問合せ文字列パラメータ、リクエスト本文またはヘッダー内)に含まれています。

クラウド環境では、アプリケーションは、スケーラビリティと移植性のためにステートレスにすることをお薦めします。ステートレスにすることでスケーラビリティが向上します。これは、サーバーではセッション状態の保持、更新およびやり取りの必要がないためです。たとえば、ロード・バランサでは、ステートレス・システムのセッション・アフィニティを考慮する必要がありません。最新のWebアプリケーションのほとんどはステートレスです。

アプリケーションの状態リークによる以降の使用の防止

リクエストでセッション状態を設定すると、そのセッションは現在の状態のままになります。つまり、そのセッションをそれ以降に使用したときは、現在のセッション状態となります。たとえば、アプリケーションで接続が流用され接続プールに返却されるときに、セッション状態がクリアされないと、その接続の次回使用時には、前回使用時のセッション状態となります。

RESET_STATEは、データベース・サービスの属性です。RESET_STATEサービス属性を使用すると、リクエストでアプリケーションによって設定されたセッション状態が、データベース・リクエスト終了時にクリアされます。RESET_STATEを使用すると、アプリケーションが、リクエストの終了時に状態をリセットすることを依存できます。RESET_STATEを使用しない場合は、アプリケーション開発者が、接続を再利用のためにプールに戻す前に、カーソルを取り消し、設定されているセッション状態をクリアする必要があります。

RESET_STATEは、リクエスト間でステートレスなアプリケーションで使用されます。このようなタイプのアプリケーションでは、リクエストでセッション状態が使用され、そのセッション状態がそれ以降のリクエストで使用されることはありません。リクエストに必要なセッション状態は、そのリクエスト自体に含まれています。ステートレス・アプリケーションの例としては、REST、ORDS、Oracle Application Express (APEX)があります。

RESET_STATEは、リクエスト境界に関して、Oracleおよびサード・パーティの接続プールを使用するすべてのアプリケーションで使用できます。RESET_STATEをLEVEL1に設定すると、リクエストの明示的な終了時にセッション状態を自動的にリセットできます。RESET_STATEは、暗黙的なリクエスト境界(DRCPの暗黙的文キャッシュを使用するものなど)には適用されません。

RESET_STATE属性を使用すると、リクエストの終了時に次のような影響があります:

  • カーソルは取り消されます。
  • PL/SQLグローバル変数はクリアされます
  • 期間がセッション・ベースの一時表は切り捨てられます
  • 期間がセッション・ベースの一時LOBはクリアされます
  • セッション・ローカル順序がリセットされます

RESET_STATEは非常に重要なデータベース機能で、開発者は、リクエスト境界を持つ接続プールにセッションが返されたときに、セッション状態がクリーンであることに依存できます。これは、リクエスト境界が追加されたOracle接続プールまたはカスタム接続プールです。また、RESET_STATEを使用すると、新しいリクエストの開始時にセッション状態がクリーンになるため、透過的アプリケーション・コンティニュイティ(TAC)を使用するときの保護が強化されます。

親トピック: データベース・サービスでのアプリケーション・ワークロードの管理

データベース・サービスのデータ・ディクショナリ・ビュー

データ・ディクショナリ・ビューを問い合せて、データベース・サービスに関する情報を検索できます。

データベース・サービスに関する情報は、次のビューで参照できます。

次の追加ビューにも、データベース・サービスに関する情報が表示されます。

ALL_SERVICESビューにはGLOBAL_SERVICE列が含まれ、V$SERVICESビューとV$ACTIVE_SERVICESビューにはGLOBAL列が含まれます。これらのビューおよび列により、データベース・サービスがグローバル・サービスであるかどうかを判断できます。

親トピック: データベース・サービスでのアプリケーション・ワークロードの管理

Oracle DatabaseのStandard Edition高可用性の管理

Standard Edition高可用性機能は、Oracle Clusterwareを使用したOracle Database Standard Edition 2単一インスタンス・データベースに向けて計画外停止に対する保護を提供します。

ノート:

Standard Edition高可用性は、このリリースのOracle Databaseでサポートされています。

ノート:

Standard Edition高可用性で使用するsrvctlコマンドは、Oracle Restartで使用するものとは異なります。Standard Edition高可用性の場合、srvctlコマンドとは、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』で説明されているものを表します。

関連トピック

親トピック: CDBの作成: 高度なトピック

Standard Edition高可用性について

このリリースでは、Oracle Database Standard Edition 2を高可用性モードでインストールできます。

Standard Edition高可用性では、Oracle Clusterwareを使用し、単一インスタンスのStandard Edition Oracle Databases用にクラスタベースのフェイルオーバーを提供します。

Oracle Standard Edition高可用性は、Oracle Clusterware、Oracle Automatic Storage Management (Oracle ASM)およびOracle Advanced Cluster File System (Oracle ACFS)など、Oracle Grid Infrastructureにすでに含まれているクラスタ機能およびストレージ・ソリューションを利用しています。

データベース・ファイル用および非構造化データ用のOracle ASMやOracle ACFSなどの、統合された、共有の、同時にマウントされた記憶域を使用することにより、Oracle Grid Infrastructureではフェイルオーバーのノード上でOracle Databaseを再起動でき、これは、フェイルオーバーおよび再マウントされたボリュームやファイル・システムに依存するクラスタ・ソリューションよりもはるかに高速です。

Standard Edition高可用性は、Linux x86-64でサポートされています。

ノート:

この項では、Standard Edition Oracle Databases 23c以降に向けてクラスタ・ベースのデータベース・フェイルオーバーを提供する、Standard Edition高可用性について詳しく説明します。Oracle Databaseの高可用性オプションの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

親トピック: Oracle DatabaseのStandard Edition高可用性の管理

Oracle DatabaseでStandard Edition High Availabilityを使用するための要件

Standard Edition高可用性を使用する場合は、次に示す構成の要件に従ってOracle Database Standard Edition 2をデプロイします。

  • データベースはスタンドアロン・クラスタ用のOracle Grid Infrastructureを実行しているクラスタ内に作成します。そのデータベース・ファイルは、Oracle Automatic Storage Management (Oracle ASM)またはOracle Advanced Cluster File System (Oracle ACFS)に配置します。
  • Database Configuration Assistantを使用しているときには、Standard Edition高可用性用に構成するOracle Database Standard Edition 2データベースの作成時にリスナーを作成しないでください。
  • データベースは、リモート・リスナーとしての単一クライアント・アクセス名(SCAN)リスナーと、ローカル・リスナーとしてのノード・リスナーに登録します。
  • データベース・サービスを作成します。このサービスは、デフォルトのデータベース・サービスのかわりに、アプリケーション・クライアントまたはデータベース・クライアントをデータベースに接続するときに使用します。
  • サーバー・パラメータ・ファイル(spfile)とパスワード・ファイルが、Oracle ASMまたはOracle ACFSに配置されていることを確認します。spfileとパスワード・ファイルがデータベースの作成時または構成時にローカル・ファイル・システムに配置されていた場合は、それらのファイルをOracle ASMまたはOracle ACFSに移動します。

満たしておく必要のある追加の要件については、データベースのインストール・ドキュメントを参照してください。

関連トピック

親トピック: Oracle DatabaseのStandard Edition高可用性の管理

Oracle DatabaseのStandard Edition高可用性の有効化

Standard Edition高可用性を有効化することで、Oracle Database Standard Edition 2データベースにクラスタ・ベースのフェイルオーバーを実現します。

ノート:

このトピックに示すステップは、Standard Edition高可用性を構成するためのOracle Databaseソフトウェア・バイナリをインストールして(『Oracle Databaseインストレーション・ガイドfor Linux』を参照)、データベースを作成した後で実行する必要があります。1つのクラスタ・ノードで実行する既存のStandard Edition 2データベースがあるときに、このデータベースのStandard Edition高可用性を有効化する場合は、その構成にノードを追加する必要があります。

ノート:

次のトピック(DBCAを使用したStandard Edition高可用性データベースの作成)を使用する場合は、このトピックをスキップします

前提条件

  • 初期化パラメータlocal_listenerが設定されていないことを確認します。これにより、ノードのリスナーが自動的に使用されるようにして、データベース接続がノードの仮想IPアドレスを通じて確立されるようにします。

    次のコマンドを使用して、現在のリスナー構成を表示します。

    SQL> SHOW PARAMETER LOCAL_LISTENER;

    このコマンドの出力にローカル・リスナー名が表示された場合は、次のコマンドを使用してローカル・リスナーをリセットします。

    SQL> ALTER SYSTEM RESET LOCAL_LISTENER SCOPE = BOTH;

    リスナー構成の変更が反映されるようにするために、データベースを再起動する必要があります。ただし、Standard Edition高可用性構成の検証の一環として、データベースが別のノードに再配置された場合は、データベースの再起動は不要です。

  • Oracle Advanced Cluster File System (Oracle ACFS)にデータベース・ファイルを格納する場合は、Oracle ClusterwareにOracle ACFSファイル・システムを登録し、対応するOracle ACFSリソースに対するデータベース・リソースの依存関係を構成するためにsrvctlコマンドを使用する必要があります。たとえば: 

    $ srvctl modify database -db se2cdb2 -acfspath /u01/app/oradata

Oracle Database Standard Edition 2データベースのStandard Edition高可用性を有効化するには:

  1. データベースの作成にCREATE DATABASEコマンドを使用した場合は、そのデータベースをOracle Clusterwareに登録します。

    CREATE DATABASEコマンドを使用して作成したデータベースは、Oracle Clusterwareに自動的には登録されません。srvctl add databaseコマンドを使用して、データベースを登録します。

    たとえば、次のコマンドでは、se2cdbという一意の名前が付いた単一インスタンス・データベースをノードnode2およびnode3に登録します。 

    $ srvctl add database -db se2cdb -oraclehome $ORACLE_HOME 
-dbtype SINGLE -spfile +DATA/SE2CDB1/PARAMETERFILE/spfile.276.1030845691 
-node node2,node3
  2. データベースがすでにOracle Clusterwareに登録されている場合は、srvctl modify databaseコマンドを使用してStandard Edition高可用性を有効化します。

    たとえば、次のコマンドでは、一意のデータベース名がse2cdbのStandard Edition 2データベースでStandard Edition高可用性を有効化します。 

    $ srvctl modify database -db se2cdb -node node2,node3

    ノート:

    固定単一インスタンス・データベースを作成するための-fixedオプションは、Standard Edition高可用性ではサポートされていません。

データベースのStandard Edition高可用性を有効化すると、次のようになります。

  • データベース・インスタンスを実行しているノードの計画外停止が発生すると、インスタンスは構成済ノードのリストにある使用可能なノードで再起動されます。
  • データベース・インスタンスの計画外中断が発生すると、現在のノードでインスタンスの再起動が試行されます。再起動に失敗した場合は、構成済ノードのリストにある使用可能なノードへのフェイルオーバーが開始されます。
  • データベース・インスタンスを実行しているノードのパブリック・ネットワークへの接続が完全に失われると、そのインスタンスは構成済ノードのリストにある使用可能なノードに再配置されます。

ノート:

ノード・リスト内のノードの順序によって、データベースを起動するノードが決まります。Oracle Clusterwareは、ノード・リストの最初のノードでデータベースを起動しようとします。最初のノードが使用できない場合は、ノード・リストの次のノードに移動します。

また、Oracle Clusterwareは、現在のノードで障害が発生した場合、ノード・リスト内のノードの順序を使用してフェイルオーバー・ターゲットを決定します。フェイルオーバー・ターゲットが考慮されるのは、リスト内の最初のノードから始まって適切な候補が見つかるまでで、クラスタ内の他の状況によってこの順序でフェイルオーバー・ノードを決定できない場合を除きます。

Standard Edition高可用性の構成(特に現在の構成済ノードのリスト)を検証するには、srvctl config databaseコマンドを使用します。たとえば: 

$ srvctl config database -db se2cdb 
...
Type: SINGLE
...
Configured nodes:
        node2, node3

この出力では、データベースのタイプが単一でありながら、構成済ノードが複数存在していることに注目してください。これは、Standard Edition高可用性が有効になっていることを示しています。

さらに検証を進めるには、データベースを別の構成済ノードに再配置します。

関連トピック

親トピック: Oracle DatabaseのStandard Edition高可用性の管理

DBCAを使用したStandard Edition高可用性データベースの作成

Oracle Database Configuration Assistant (Oracle DBCA)を使用すると、Standard Edition高可用性(SEHA)、単一インスタンスのOracle Databaseを作成できます。

Standard Edition高可用性データベース・ソフトウェアのインストールが完了したら、対話モードまたはサイレント・モードでOracle DBCAを使用して単一インスタンスのOracle Databaseを作成できます。詳細は、Standard Edition高可用性のデプロイを参照してください。

Standard Edition高可用性データベース:

  • フェイルオーバー機能を備えた単一インスタンス・データベースです。
  • データベース記憶域ファイルにOracle ASMまたはOracle ACFSを使用します(NASはサポートされていません)。

DBCAは、Standard Edition高可用性単一インスタンス・データベースに対して次の機能を提供します:

  • DBCAには、Standard Edition高可用性データベースを配置するためのノード・リストを選択するインタフェースが用意されています。
  • DBCAはStandard Edition高可用性データベースのサービスを作成します。
  • DBCAは、dbの記憶域の場所に基づいてOracle ASMまたはOracle ACFSにspfileおよびパスワード・ファイルを作成します。

DBCAを使用したStandard Edition高可用性データベースの作成

  1. 対話モードでOracle Database Configuration Assistant (Oracle DBCA)を起動します。
    cd $ORACLE_HOME/bin
 ./dbca
  2. 「データベース操作の選択」画面で、「データベースの作成」を選択し、「次へ」をクリックします。
  3. 「データベース作成モードの選択」画面で、「拡張構成」を選択し、「次へ」をクリックします。

  4. データベース・デプロイメント・タイプの選択ページの「データベース・タイプ」フィールドで、「Oracle SEHA (SI)」データベースを選択します。データベース管理ポリシーとして「自動」を選択し、データベースに適したテンプレートを選択します。「次へ」をクリックします

  5. データベース・テンプレートを選択し、「次へ」をクリックします。
  6. ノード・リストの選択ページで、単一インスタンス・クラスタに使用する各ノードを選択します。「次へ」をクリックします
  7. データベースIDの詳細の指定ページで、グローバル・データベース名およびSID接頭辞を指定します。
  8. 必要に応じて構成画面やプロンプトに応答し、データベース作成プロセスを完了します。構成画面は、選択した構成オプションによって異なります。

Standard Edition高可用性のサイレント・モードのオプション

-databaseConfigType SEHA

[-SEHAServiceName Standard Edition高可用性データベース用に作成するサービスのサービス名]。databaseConfigTypeがSEHAの場合、このオプションは必須です]

Oracle ASM用のサンプル・コマンドライン: 
dbca -silent -createDatabase -createAsContainerDatabase true 
-templateName $ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbc -gdbname test 
-sehaNodeList node1,node2 -storageType ASM -diskgroupName +DATA –databaseConfigType SEHA 
–SEHAServiceName dbtestsvc
Oracle ACFS用のサンプル・コマンドライン: 
dbca -silent -createDatabase -createAsContainerDatabase true 
-templateName $ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbc -gdbname testdb 
-sehaNodeList node1,node2 -storageType FS –datafileDestination /acfsmount/oradata –databaseConfigType SEHA 
–SEHAServiceName dbtestsvc

親トピック: Oracle DatabaseのStandard Edition高可用性の管理

Standard Edition高可用性データベースの別のノードへの再配置

計画停止を管理するために、Standard Edition高可用性を使用するOracle Database Standard Edition 2データベースは、別の構成済ノードに再配置できます。

データベースの再配置先ノードは、このデータベースの構成済ノードのリストに含まれている必要があります。

アクティブなOracle Database Standard Edition 2データベースを現在のノードから別の構成済ノードに再配置するには:

  • srvctl relocateコマンドを使用します。

    このコマンドでは、オフライン再配置を実行します。既存のノードのデータベースを停止してから、新しいノードで起動します。

たとえば、次のコマンドでは、Standard Edition高可用性を使用しているse2cdbという名前のStandard Edition 2データベースをノードnode5に再配置します。 

$ srvctl relocate database -db se2cdb -node node5

ノート:

srvctl relocate databaseコマンドのオプション–abortと–revertは、Standard Edition高可用性ではサポートされていません。

親トピック: Oracle DatabaseのStandard Edition高可用性の管理

Standard Edition高可用性データベースへのノードの追加

既存のStandard Edition高可用性構成に新しいノードを追加することで、Standard Edition 2データベースのフェイルオーバー機能が強化されます。

ノードの追加は、特定のシナリオで必要になることがあります。たとえば、Standard Edition高可用性データベース用に2つのノードを構成したとします。その後、クラスタに新しいノードが追加され、その新しいノードをデータベース構成に組み込もうとしている場合です。これは、そのノードをStandard Edition高可用性構成に追加することで実現できます。別のシナリオとして、既存のStandard Edition 2データベースに対してStandard Edition高可用性を有効にしようとしている場合があります。

Standard Edition高可用性データベースにノードを追加するには:

  1. 新しいノードにOracle DatabaseのOracleホームを拡張します。このステップは、使用している記憶域によって異なります。

    ローカル(非共有) Oracleホームの場合:

    1. 最初のクラスタ・ノード(Standard Edition高可用性を構成したノード)に、Oracleインストール所有者ユーザー・アカウント(oracle)としてログインします。

    2. ORACLE_HOME/addnodeディレクトリに移動し、Linuxのaddnode.shスクリプトまたはWindowsのaddnode.batを実行します。

      たとえば、OracleホームをLinuxのnode3に拡張するには、次のようにします。 

      $ ./addnode.sh -silent "CLUSTER_NEW_NODES={node3}"

    Oracle ACFSを使用している共有Oracleホームの場合:

    1. rootとしてGrid_home/binディレクトリから次のコマンドを実行して、新しいノードでOracle ACFSリソースを起動します。 

      # srvctl start filesystem -device volume_device [-node node_name]

      ノート:

      Oracleホームが格納されているOracle ACFSレジストリ・リソースおよびOracle ACFSファイル・システム・リソースを含むOracle ACFSリソースが、新しく追加されたノードでオンラインであることを確認します。

    2. 最初のクラスタ・ノード(Standard Edition高可用性を構成したノード)に、Oracleインストール所有者ユーザー・アカウント(oracle)としてログインします。

    3. 追加しようとしているノードに、最初のクラスタ・ノードのOracleホームをアタッチします。

      $ $ORACLE_HOME/addnode/addnode.sh -silent CLUSTER_NEW_NODES=new_node_name
  2. 新しいノード(追加することになるノード)で、rootユーザーとしてORACLE_HOME/root.shスクリプトを実行します。
    # /u01/app/oracle/product/21.0.0/dbhome_1/root.sh
  3. いずれかの構成済ノード(追加するノードを含む)で、oracleユーザーとしてsrvctl modify databaseコマンドを使用することで、新しいノード追加します。

    -node引数には、既存の構成済ノードと追加する新しいノードをリストする必要があります。

    たとえば、次のコマンドでは、ノードnode3をse2cdbという一意の名前のデータベースに追加します。既存の構成済ノードは、node1とnode2です。 

    $ srvctl modify database -db se2cdb -node node1,node2,node3
新しい構成を必要に応じて確認してください(「Oracle DatabaseのStandard Edition高可用性の有効化」を参照)。

関連トピック

親トピック: Oracle DatabaseのStandard Edition高可用性の管理

Standard Edition高可用性データベースからの構成済ノードの削除

srvctlコマンドを使用して、Standard Edition高可用性データベース用に構成されたノードのリストからノードを削除します。

Oracle Databaseホーム・ディレクトリに移動します。Linuxの場合は、Oracleインストール所有者ユーザー・アカウント(oracle)として、データベース・ホスト・コンピュータにログインします。Windowsの場合は、管理者としてデータベース・ホスト・コンピュータにログインします。

Standard Edition高可用性を使用するデータベースから構成済ノードを削除するには:

  1. srvctl config databaseコマンドを使用して、既存の構成済ノードをリストします。
  2. 削除しようとしているノードでデータベースが実行されている場合は、srvctl relocate databaseコマンドを使用して、そのデータベースを別の構成済ノードに再配置します。
  3. -node引数を指定したsrvctl modify databaseコマンドを使用して、ノードを削除します。
    -node引数には、削除が必要なノード以外のすべての構成済ノードをリストする必要があります。

例4-1 Standard Edition高可用性データベースからの構成済ノードの削除

この例の前提として、sec2cdbという一意の名前のデータベースがStandard Edition高可用性を使用していて、構成済ノードのnode1、node2およびnode3があるとします。現在、データベースはnode3で実行されています。このデータベースの構成済ノードのリストからnode2を削除するには、Oracle Databaseホームをインストールしたユーザーとしてログインし、次のコマンドを実行します。 

$ srvctl modify database -db sec2cdb -node node1,node3

関連トピック

親トピック: Oracle DatabaseのStandard Edition高可用性の管理

Standard Edition高可用性データベースの起動と停止

srvctlコマンドを使用して、Standard Edition高可用性用に構成されたOracle Databaseを起動または停止します。

Oracle Databaseホーム・ディレクトリに移動します。Linuxの場合は、Oracleインストール所有者ユーザー・アカウント(oracle)として、データベース・ホスト・コンピュータにログインします。Windowsの場合は、管理者としてデータベース・ホスト・コンピュータにログインします。

Standard Edition高可用性データベースを起動するには:

  • srvctl start databaseコマンドを使用します。

    オプションとして、データベースを起動する必要のあるノードを指定する-node引数を含めます。

Standard Edition高可用性データベースを停止するには:

  • srvctl stop databaseコマンドを使用します

例4-2 指定したノードでのStandard Edition高可用性データベースの起動

この例では、一意の名前がse2cdbというデータベースをnode3という名前のノードで起動します。 

$ srvctl start database -db sec2cdb -node node3

例4-3 Standard Edition高可用性データベースの停止

この例では、Standard Edition高可用性を使用するように構成されたデータベース・インスタンスを停止します。このデータベースの一意の名前はsec2cdbです。 

$ srvctl stop database -db sec2cdb

関連トピック

親トピック: Oracle DatabaseのStandard Edition高可用性の管理

Oracle DatabaseのStandard Edition高可用性の非アクティブ化

単一インスタンスOracle DatabaseのStandard Edition高可用性を非アクティブ化すると、そのデータベースは高可用性フェイルオーバー構成に含まれなくなります。

Oracle DatabaseのStandard Edition高可用性を非アクティブ化するには:

  • srvctl modifyコマンドを使用して、-node引数に1つのノードのみを含めます。

例4-4 Oracle DatabaseのStandard Edition高可用性の使用の非アクティブ化

この例では、se2cdbという一意の名前が付いたデータベースのStandard Edition高可用性の使用を非アクティブ化して、このデータベース用にnode1という1つのノードのみを構成します。 

srvctl modify database -db se2cdb -node node1

以前のすべての構成済ノードは削除され、このデータベースはOracle Clusterwareに登録された単一インスタンス・データベースになります。

親トピック: Oracle DatabaseのStandard Edition高可用性の管理

データベースのクローニング

この項では、Oracleデータベースの様々なクローニング方法について説明します。

親トピック: CDBの作成: 高度なトピック

非マルチテナント環境でのCloneDBを使用したデータベースのクローニング

CloneDBを使用すると、複数の異なる場所にデータ・ファイルをコピーすることなく、非マルチテナント環境でデータベースを複数回クローニングできます。かわりに、CloneDBはcopy-on-writeテクノロジを使用するため、ディスク上に追加の記憶域が必要となるのは変更されているブロックのみとなります。

親トピック: データベースのクローニング

CloneDBを使用したデータベースのクローニングについて

多くの場合、テスト目的またはその他の目的で本番データベースをクローニングすることが必要となります。

本番データベースをクローニングする一般的な理由は、次のとおりです。

  • データベースを使用する新規アプリケーションのデプロイ、または既存のアプリケーションの更新

  • データベースを実行するシステムでの、オペレーティング・システムのアップグレード計画

  • データベース・インストール用の新しい記憶域

  • レポート

  • 古いデータの分析

新しいアプリケーションをデプロイする前、オペレーティング・システムのアップグレードを実行する前、または新しい記憶域を使用する前に、新しい状況でデータベースが適切に動作することを確認するために徹底的にテストすることが必要です。クローニングは、本番データファイルのコピーを1つ以上のテスト環境に作成することで実行できますが、通常、これらのコピーを割り当てて管理するために、大量の記憶域が必要となります。

CloneDBを使用すると、データファイルを複数の異なる場所にコピーしなくても、データベースを複数回クローニングできます。Oracle Databaseでは、かわりにcopy-on-writeテクノロジを使用してCloneDBデータベースにファイルを作成するため、ディスク上に追加の記憶域が必要になるのは、CloneDBデータベースで変更されたブロックのみとなります。

この方法でデータベースをクローニングすると、次の利点があります。

  • テスト目的で必要になる記憶域の量が削減されます。

  • 様々な目的のために複数のデータベース・クローンを迅速に作成できます。

CloneDBデータベースは、データベース・バックアップのデータファイルを使用します。バックアップ・データファイルを使用すると、CloneDBインスタンスによる本番データファイルへのアクセスが行われず、CPUやI/Oリソースなどの本番データベースのリソースに対するCloneDBインスタンスによる競合が発生しません。

ノート:

  • この項で説明するCloneDBを使用したデータベースのクローニングの手順は、マルチテナント環境のデータベースには適用できません。

  • CloneDB機能は、パフォーマンス・テスト向けではありません。

関連項目:

マルチテナント環境でのデータベースのクローニングの詳細は、「マルチテナント環境でのデータベースのクローニング」を参照してください

親トピック: 非マルチテナント環境でのCloneDBを使用したデータベースのクローニング

CloneDBを使用したデータベースのクローニング

CloneDBでデータベースをクローニングできます。

データベースをクローニングするには、次の前提条件を満たしている必要があります。

  • 各CloneDBデータベースはDirect NFSクライアントを使用する必要があり、本番データベースのバックアップはNFSボリューム上に存在する必要があります。

    Direct NFSクライアントにより、Oracle Databaseは、オペレーティング・システム・カーネルのNFSクライアントを使用するかわりに、ネットワーク接続記憶域(NAS)デバイスに直接アクセスできます。このCloneDBデータベース機能は、Direct NFSクライアントをサポートするプラットフォームで使用可能です。

    Direct NFSクライアントの詳細は、使用しているオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

  • CloneDBデータベースの変更されたブロックを追跡するには、少なくとも2MBの追加システム・グローバル領域(SGA)メモリーが必要です。

    Oracle Database管理者ガイドを参照してください。

  • データベース・バックアップ用および各CloneDBデータベースの変更されたブロック用の記憶域が必要となります。

    データベース・バックアップに必要な記憶域は、バックアップの実行に使用する方法によって異なります。単一の全体RMANバックアップでは、最も多くの記憶域が必要となります。ストレージ・アプライアンスの機能を使用して実行される記憶域スナップショットは、そのストレージ・アプライアンスの要件に従います。単一のバックアップで複数のCloneDBデータベースをサポートできます。

    各CloneDBデータベースで必要になる記憶域の量は、そのデータベースの書込みアクティビティによって異なります。変更される各ブロックには、記憶域の使用可能な1つのブロックが必要となります。したがって、必要になる合計記憶域は、一定期間にCloneDBデータベースで変更されるブロックの数によって異なります。

この項では、1つのCloneDBデータベースを作成するためのステップについて説明し、これらのサンプル・データベースおよびディレクトリを使用します。

  • 本番データベースPROD1のOracleホームは/u01/prod1/oracleです。

  • データベース・バックアップのファイルは/u02/oracle/backup/prod1にあります。

  • CloneDBデータベースCLONE1のOracleホームは/u03/clone1/oracleです。

CloneDBを使用してデータベースをクローニングするには:

  1. 本番データベースのバックアップを作成します。次のバックアップ・オプションがあります。

    • オンライン・バックアップ

      オンライン・バックアップを実行する場合は、本番データベースがARCHIVELOGモードになっており、必要なすべてのアーカイブREDOログ・ファイルが保存され、CloneDBデータベース環境にアクセスできることを確認します。

    • 全体オフライン・バックアップ

      全体オフライン・バックアップを実行する場合は、バックアップ・ファイルがCloneDBデータベース環境にアクセスできることを確認します。

    • データベース・ファイルをコピーするバックアップ

      BACKUP AS COPYをRMANで指定すると、RMANは各ファイルを、ディスクに作成されたデータベース・ファイルのビットごとのコピーであるイメージ・コピーとしてコピーします。イメージ・コピーは、LinuxのcpやWindowsのCOPYなどのオペレーティング・システム・コマンドで作成したコピーと同じですが、RMANのリポジトリに記録されるため、RMANで使用できます。RMANを使用すると、データベースがオープンしている間にイメージ・コピーを作成できます。コピーされたデータベース・ファイルがCloneDBデータベース環境にアクセスできることを確認します。

    データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

  2. テキスト形式の初期化パラメータ・ファイル(PFILE)がない場合は、作成します。

    サーバー・パラメータ・ファイル(SPFILE)を使用する場合は、本番データベース上で次の文を実行して、PFILEを作成します。

    CREATE PFILE FROM SPFILE;

  3. 本番データベースをクローニングするためのSQLスクリプトを作成します。

    後のステップで、CloneDBデータベースを作成するために、1つ以上のSQLスクリプトを使用します。SQLスクリプトを作成するには、オラクル社が提供するclonedb.plと呼ばれるPerlスクリプトを使用するか、またはSQLスクリプトを手動で作成できます。

    clonedb.pl Perlスクリプトを使用するには、次のステップを実行します。

    1. オペレーティング・システムのプロンプトで、次の環境変数を設定します。

      MASTER_COPY_DIR - ステップ1で作成したバックアップが含まれるディレクトリを指定します。このディレクトリには、本番データベースのデータファイルのバックアップのみが含まれていることを確認します。

      CLONE_FILE_CREATE_DEST - データファイル、ログ・ファイル、制御ファイルなど、CloneDBデータベース・ファイルが作成されるディレクトリを指定します。

      CLONEDB_NAME - CloneDBデータベースの名前を指定します。

      S7000_TARGET - バックアップ用のファイル・システムを提供するNFSホストおよびCloneDBデータベースがSun Storage 7000である場合は、ホストの名前を指定します。それ以外の場合は、この環境変数を設定しないでください。この環境変数は、記憶域スナップショットを使用してクローニングを実行する必要がある場合にのみ設定します。この変数を設定せずに、Direct NFSクライアントにS7000ストレージ・アレイを使用できます。

    2. clonedb.pl Perlスクリプトを実行します。

      このスクリプトは、$ORACLE_HOME/rdbms/installディレクトリにあり、次の構文が含まれます。

      $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/install/clonedb.pl 
prod_db_pfile [sql_script1] [sql_script2]

      次のオプションを指定します。

      prod_db_pfile - 本番データベースのPFILEのフルパスを指定します。

      sql_script1 - clonedb.plによって生成された最初のSQLスクリプトの名前を指定します。デフォルトはcrtdb.sqlです。

      sql_script2 - clonedb.plによって生成された2番目のSQLスクリプトの名前を指定します。デフォルトはdbren.sqlです。

      clonedb.plスクリプトは、本番データベースのPFILEをCloneDBデータベースのディレクトリにコピーします。また、CloneDBデータベースの作成に使用する2つのSQLスクリプトも作成します。

    3. clonedb.pl Perlスクリプトにより生成された2つのSQLスクリプトを確認し、必要に応じて変更します。

    4. CloneDBデータベース環境の初期化パラメータを変更し、ファイルを保存します。

      CloneDBデータベース環境固有の初期化パラメータ(SGAサイズ、PGAターゲット、CPUの数などを制御するパラメータなど)を変更します。CLONEDBパラメータをTRUEに設定する必要があり、初期化パラメータ・ファイルにこのパラメータが含まれています。初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

    5. SQL*Plusで、CloneDBデータベースにSYSDBA管理権限で接続します。

    6. clonedb.pl Perlスクリプトで生成されたSQLスクリプトを実行します。

      たとえば、スクリプトでデフォルト名を使用する場合は、SQLプロンプトで次のスクリプトを実行します。

      crtdb.sql
dbren.sql

    SQLスクリプトを手動で作成するには、次のステップを実行します。

    1. SYSDBAまたはSYSBACKUP管理権限でデータベースに接続します。

      Oracle Database管理者ガイドを参照してください。

    2. 次のステップを実行して、本番データベースからバックアップ制御ファイル・スクリプトを生成します。

      次のSQL文を実行します。

      ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

      この文により、制御ファイルを作成するSQL文を含むトレース・ファイルが生成されます。CREATE CONTROLFILE文を含むトレース・ファイルは、DIAGNOSTIC_DEST初期化パラメータで指定されたディレクトリに格納されます。データベース・アラート・ログでこのトレース・ファイルの名前と場所を確認します。

    3. ステップ3bで生成したトレース・ファイルを開き、トレース・ファイル内のSTARTUP NOMOUNT文とCREATE CONTROLFILE文を新しいSQLスクリプトにコピーします。

    4. ステップ3cで作成した新しいSQLスクリプトを次の方法で編集します。

      データベースの名前を、作成するCloneDBデータベースの名前に変更します。たとえば、PROD1をCLONE1に変更します。

      ログ・ファイルの場所を、CloneDBデータベース環境のディレクトリに変更します。たとえば、/u01/prod1/oracle/dbs/t_log1.fを/u03/clone1/oracle/dbs/t_log1.fに変更します。

      データファイルの場所を、バックアップの場所に変更します。たとえば、/u01/prod1/oracle/dbs/t_db1.fを/u02/oracle/backup/prod1/t_db1.fに変更します。

      次に、ALTER DATABASE BACKUP CONTROLFILE TO TRACE文で生成された元の文の例を示します。 

      STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "PROD1" NORESETLOGS  ARCHIVELOG
    MAXLOGFILES 32
    MAXLOGMEMBERS 2
    MAXDATAFILES 32
    MAXINSTANCES 1
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/u01/prod1/oracle/dbs/t_log1.f'  SIZE 25M BLOCKSIZE 512,
  GROUP 2 '/u01/prod1/oracle/dbs/t_log2.f'  SIZE 25M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  '/u01/prod1/oracle/dbs/t_db1.f',
  '/u01/prod1/oracle/dbs/t_ax1.f',
  '/u01/prod1/oracle/dbs/t_undo1.f',
  '/u01/prod1/oracle/dbs/t_xdb1.f',
  '/u01/prod1/oracle/dbs/undots.dbf'
CHARACTER SET WE8ISO8859P1;

      次に、新しいSQLスクリプトの変更された文の例を示します。

      STARTUP NOMOUNT PFILE=/u03/clone1/oracle/dbs/clone1.ora
CREATE CONTROLFILE REUSE DATABASE "CLONE1" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 32
    MAXLOGMEMBERS 2
    MAXDATAFILES 32
    MAXINSTANCES 1
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/u03/clone1/oracle/dbs/t_log1.f'  SIZE 25M BLOCKSIZE 512,
  GROUP 2 '/u03/clone1/oracle/dbs/t_log2.f'  SIZE 25M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  '/u02/oracle/backup/prod1/t_db1.f',
  '/u02/oracle/backup/prod1/t_ax1.f',
  '/u02/oracle/backup/prod1/t_undo1.f',
  '/u02/oracle/backup/prod1/t_xdb1.f',
  '/u02/oracle/backup/prod1/undots.dbf'
CHARACTER SET WE8ISO8859P1;

      データファイルで取得した記憶域レベルのスナップショットがある場合は、RMANバックアップ・ファイル名を記憶域スナップショット名に置き換えることができます。

    5. SQLスクリプトを編集した後、そのスクリプトをCloneDBデータベース環境にアクセスできる場所に保存します。

      新しいSQLスクリプトの名前および保存場所をノートにとります。このスクリプトは、後続のステップで実行します。この例では、スクリプトの名前はcreate_clonedb1.sqlであると想定しています。

    6. テキスト形式の初期化パラメータ・ファイル(PFILE)を、本番データベース環境からCloneDBデータベース環境にコピーします。

      たとえば、テキスト形式の初期化パラメータ・ファイルを/u01/prod1/oracle/dbsから/u03/clone1/oracle/dbsにコピーします。ファイルの名前および場所は、変更したSQLスクリプトのSTARTUP NOMOUNTコマンドで指定した名前と場所に一致する必要があります。ステップ3dの例では、ファイルは/u03/clone1/oracle/dbs/clone1.oraです。

    7. CloneDBデータベース環境の初期化パラメータを変更し、ファイルを保存します。

      CLONEDBパラメータを追加し、このパラメータがTRUEに設定されていることを確認します。CloneDBデータベース環境に固有の他のすべての初期化パラメータ(SGAサイズ、PGAターゲット、CPUの数などを制御するパラメータなど)を変更します。初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

    8. SQL*Plusで、CloneDBデータベースにSYSDBA管理権限で接続します。

    9. ステップ3eで保存したSQLスクリプトを実行します。

      たとえば、SQL*Plusで次のように入力します。

      @create_clonedb1.sql

    10. バックアップの場所の各データファイルで、DBMS_DNFSパッケージのCLONEDB_RENAMEFILEプロシージャを実行し、CloneDBデータベース環境の適切な場所を指定します。

      たとえば、バックアップ・データファイルが/u02/oracle/backup/prod1/t_db1.fで、CloneDBデータベース・データファイルが/u03/clone1/oracle/dbs/t_db1.fである場合は、次のプロシージャを実行します。

      BEGIN
  DBMS_DNFS.CLONEDB_RENAMEFILE(
    srcfile  => '/u02/oracle/backup/prod1/t_db1.f',
    destfile => '/u03/clone1/oracle/dbs/t_db1.f');
END;
/

      DBMS_DNFSパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

  4. CloneDBデータベースをオンライン・バックアップから作成した場合は、CloneDBデータベースをリカバリします。全体オフライン・バックアップまたはBACKUP AS COPYバックアップを実行した場合、このステップは必要ありません。

    たとえば、次のSQL文をCloneDBデータベースで実行します。

    RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

    この文により、バックアップが実行されたときのアーカイブREDOログ・ファイルを求められます。

  5. 次のSQL文を実行して、データベースをオープンします。

    ALTER DATABASE OPEN RESETLOGS;

    CloneDBデータベースを使用する準備ができました。

本番データベースの追加のCloneDBデータベースを作成するには、ステップ3から5を各CloneDBデータベースに対して繰り返します。

CloneDBを使用したデータベースのクローニング後

CloneDBデータベースを作成した後、本番データベースを使用するほとんどすべての方法でそのデータベースを使用できます。最初は、CloneDBデータベースは各データファイルに対して最小限の記憶域を使用します。CloneDBデータベースの行に対して変更を加えると、記憶域がオンデマンドで割り当てられます。

同じバックアップ・ファイルを使用して、複数のCloneDBデータベースを作成できます。このバックアップは、RMANまたは記憶域レベルのスナップショットによって取得できます。データファイルで取得した記憶域レベルのスナップショットがある場合は、RMANバックアップ・ファイル名を記憶域スナップショット名に置き換えることができます。

V$CLONEDFILEビューを使用して、CloneDBデータベースの各データファイルに関する情報を表示できます。この情報には、バックアップのデータファイル名、CloneDBデータベースでの対応するデータファイル名、バックアップ・ファイルから読み取られたブロック数、バックアップ・ファイルに対して発行された要求の数が含まれます。

CloneDBデータベースはバックアップ・ファイルをバックエンド記憶域として使用するため、これらのバックアップ・ファイルは、実行するために各CloneDBデータベースで使用可能である必要があります。バックアップ・ファイルが使用不可能になると、CloneDBデータベースはエラーを返します。

CloneDBデータベースの使用が完了した後、CloneDBデータベース環境を破棄できます。CloneDBデータベース環境のすべてのファイルは、本番データベース環境またはバックアップ環境に影響を与えずに削除できます。

関連項目:

V$CLONEDFILEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

親トピック: 非マルチテナント環境でのCloneDBを使用したデータベースのクローニング

マルチテナント環境でのデータベースのクローニング

マルチテナント環境でデータベースをクローニングできます。

マルチテナント環境でのデータベースのクローニングの詳細は、『Oracle Multitenant管理者ガイド』を参照してください。

親トピック: データベースのクローニング

Oracle Automatic Storage Management (Oracle ASM)を使用したデータベースのクローニング

Oracle Automatic Storage Management (Oracle ASM)では、マルチテナント・コンテナ・データベース(CDB)でのプラガブル・データベース(PDB)のクローニングがサポートされています。Oracle ASMでは、非CDBのクローニングはサポートされていません。

詳細は、次のガイドを参照してください。

親トピック: データベースのクローニング

データベースの削除

CDBの削除には、データ・ファイル、オンラインREDOログ、制御ファイルおよび初期化パラメータ・ファイルの削除も含まれます。

警告:

CDBを削除すると、そのすべてのデータが削除されます。

データベースを削除するには:

  • 次の文を発行します。

    DROP DATABASE;

DROP DATABASE文では、まず、すべての制御ファイルと制御ファイルに記述されている他のすべてのデータベース・ファイルが削除されます。その後、データベース・インスタンスが停止されます。

DROP DATABASE文の使用に成功するには、排他的に、制限モードでデータベースをマウントしておく必要があります。

DROP DATABASE文は、アーカイブREDOログ・ファイル、およびデータベースのコピーまたはバックアップには影響を与えません。これらのファイルを削除する場合は、RMANを使用することをお薦めします。

Database Configuration Assistantを使用してデータベースを作成した場合は、データベースおよびファイルの削除にこのツールを使用できます。

関連項目:

Oracle Database管理者ガイド

親トピック: CDBの作成: 高度なトピック