日本語PDF
  1. セキュリティ・ガイド
  2. ユーザー認証および認可の管理
  3. Oracle Databaseユーザーのセキュリティの管理

2 Oracle Databaseユーザーのセキュリティの管理

パスワード作成時に制限を適用するなど、Oracle Databaseユーザーのセキュリティは様々な方法で管理できます。

親トピック: ユーザー認証および認可の管理 

2.1 ユーザー・セキュリティについて

厳密なパスワードおよびユーザー用の特別な制限を指定することで、ユーザー・アカウントを保護できます。

各Oracleデータベースには、有効なデータベース・ユーザーのリストがあります。データベースにアクセスするには、ユーザーは、データベース・アプリケーションを実行し、データベースに定義されている有効なユーザー名を使用して、データベース・インスタンスに接続する必要があります。

ユーザー・アカウントの作成時に、ユーザー・アカウントに対して制限を指定できます。ユーザーのセキュリティ・ドメインの一部として、各ユーザーが使用できる各種のシステム・リソースの容量に制限を設定することもできます。Oracle Databaseには、リソースやセッションなどの情報を検索する際に問い合せることができる一連のデータベース・ビューが用意されています。この章では、プロファイルについても説明します。プロファイルとは、ユーザーに適用される属性の集合です。それらの属性を共有する複数ユーザーの中の任意のユーザーに関する単一の参照になります。

Oracle Databaseには、事前定義された管理ユーザー、非管理ユーザーおよびサンプル・スキーマのアカウントのセットが提供されています。これらのアカウントのリストは、Oracle Databaseのインストレーション・ガイドを参照してください。これらのアカウントのステータスを検索するには、DBA_USERSデータ・ディクショナリ・ビューのUSERNAMEおよびACCOUNT_STATUS列を問い合せます。

関連トピック

親トピック: Oracle Databaseユーザーのセキュリティの管理

2.2 ユーザー・アカウントの作成

プロファイル、デフォルト・ロール、表領域制限など、ユーザー・アカウントに制限を設定できます。

親トピック: Oracle Databaseユーザーのセキュリティの管理

2.2.1 共通ユーザーおよびローカル・ユーザーについて

マルチテナント環境では、CDB共通ユーザーとアプリケーション共通ユーザーはそれぞれのコンテナに対するアクセス権を持ち、ローカル・ユーザーはPDB固有のユーザーです。

親トピック: ユーザー・アカウントの作成

2.2.1.1 共通ユーザーについて

共通ユーザーには、CDB共通ユーザーとアプリケーション共通ユーザーの2つのタイプがあります。

CDB共通ユーザーとは、CDBルートならびに既存および将来のプラガブル・データベース(PDB)によって単一のIDとパスワードが認識されているデータベース・ユーザーです。Oracle提供のSYSおよびSYSTEMなどのすべての管理ユーザー・アカウントはCDB共通ユーザーであり、システム・コンテナを操作できます。CDB共通ユーザーは、異なるPDBで異なる権限を持つことができます。たとえば、ユーザーSYSTEMは、PDBを切り替えて、現在のPDBのSYSTEMに付与されている権限を使用できます。ただし、PDBのいずれかでOracle Database Vaultが有効な場合、SYSTEMがこのPDBに接続している間は、SYSTEMによるユーザー・アカウントの作成が許可されないといったDatabase Vaultの制限が同ユーザーに適用されます。Oracle提供のCDB共通ユーザーの権限を変更することはお薦めしません。

CDB共通ユーザーは、そのユーザーに適切な権限が付与されている場合にかぎり、アプリケーション共通ユーザーが実行できるすべてのタスクを実行できます。

アプリケーション共通ユーザーはアプリケーション・ルートで作成されるユーザー・アカウントで、このアプリケーション・コンテナ内のみで共通です。つまり、アプリケーション共通ユーザーは、CDB共通ユーザーのようにCDB環境全体にアクセスすることはできません。アプリケーション共通ユーザーは、アプリケーションPDBの作成(接続を含む)、オープン、クローズ、切断および削除などのアクティビティに対する責任を負います。このユーザーは、アプリケーション・ルートでアプリケーション共通オブジェクトを作成できます。アプリケーション共通ユーザーを作成できるのは、アプリケーション・ルートに接続しているときに限定されます。ユーザーがアプリケーション共通オブジェクトにアクセスする機能は、ローカルおよびCDB共通オブジェクトと同じ権限に依存します。たとえば、アプリケーション・ルートに関連付けられたPDBのローカル・ユーザーは、そのユーザーが権限を持つPDB内のオブジェクトにのみアクセスできます。アプリケーション・ルート自体では、アプリケーション・コンテナ間で適用される、CDB共通オブジェクトに対する権限を共通に付与できます。

いずれのタイプの共通ユーザーも、それぞれのルート内の共通オブジェクトを管理する責任を負います。CDB共通ユーザーまたはアプリケーション共通ユーザーに適切な権限がある場合、ローカル・ユーザーへの権限の付与など、PDBでの操作も実行できます。これらのユーザーは、共通ユーザーに対してコンテナごとの異なる権限をローカルに付与することもできます。

CDBおよびアプリケーション共通ユーザーは、次のアクティビティを実行できます。

  • 共通ユーザーまたは共通ロールへの権限の付与。つまり、CDB共通ユーザーは共通ユーザーまたは共通ロールに権限を付与でき、この権限が適用される範囲は、文が発行されるコンテナ(CDBルート、アプリケーション・ルートまたはPDB)および権限が(CDBルートまたはアプリケーション・ルートで)共通に付与されたかどうかによって決まります。アプリケーション・ルートに接続しているCDB共通ユーザーは、CDB共通オブジェクトに対する権限を共通に付与でき、その権限はアプリケーション・コンテナ間で適用されます。

    次の図に、CDB共通ユーザー、アプリケーション共通ユーザーおよびローカル・ユーザーのアクセス階層を示します。

    dbseg_vm_011a.epsの説明が続きます
    図dbseg_vm_011a.epsの説明

    CDB共通ユーザーはCDBルートで定義され、CDB内のすべてのPDB(アプリケーション・ルートおよびそのアプリケーションPDBを含む)にアクセスできます。アプリケーション共通ユーザーはアプリケーション・ルートで定義され、アプリケーション・コンテナに属するPDBにアクセスできます。CDB PDBまたはアプリケーションPDBのローカル・ユーザーは、そのローカル・ユーザーが存在するPDBにのみアクセスできます。

  • PDBの状態は、CDBルート、アプリケーション・ルート(PDBがアプリケーション・コンテナに属するアプリケーションPDBである場合)またはPDB自体からALTER PLUGGABLE DATABASE文を発行するための適切な権限を持つユーザーが変更できます。

CDB共通ユーザーとアプリケーション共通ユーザーの違いの1つは、CDB全体に適用されるリカバリ句を指定するALTER DATABASE文を実行できるのはCDB共通ユーザーのみであることです。

関連項目:

親トピック: 共通ユーザーおよびローカル・ユーザーについて

2.2.1.2 PDBへの接続によるCDB共通ユーザーへの影響

CDB以外をPDBとしてCDBに差し込むと、Oracle付属の管理アカウント、ユーザー作成アカウントおよびそれらの権限に影響があります。

これは、これらのCDB共通ユーザー・アカウントのパスワードと、新しく接続したデータベース内のすべてのアカウントの権限に影響します。

次のアクションが実行されます。

  • Oracleから提供される管理アカウントが既存の共通ユーザー・アカウントにマージされます。

  • ユーザー作成のアカウントが既存のユーザー作成の共通ユーザー・アカウントにマージされます。

  • 既存のCDB共通ユーザー・アカウントのパスワードは、非CDBのアカウントのパスワードよりも優先されます。

  • 元のCDB以外のユーザー・アカウントの権限を変更した場合、これらの権限は保存されますが、ローカルに付与された権限としてCDBにPDBを接続した場合に作成されたPDBにのみ適用されます。たとえば、ユーザーSYSTEMにCDB以外のdb1のhr_mgrと呼ばれるロールを付与したとします。db1データベースがCDBに追加された後、SYSTEMは、他のPDBではなくdb1 PDBのhr_mgrロールのみ使用できます。

あるCDB (cdb_1)のPDB (たとえば、pdb_1)を別のCDB (cdb_2)に接続する場合、次の2つのシナリオが可能です。

  • cdb_1には共通ユーザーc##cdb1_userがいます。cdb_2にこのユーザーはいません。

    c##cdb1_userはPDB_1に残っていますが、このアカウントはロックされています。このアカウントを復活させるには、pdb_1をクローズし、cdb_2のルートで共通ユーザーc##cdb1_userを再作成し、pdb_1を再オープンします。

  • cdb_1とcdb_2の両方には、共通ユーザーc##common_userがいます。

    両方のc##common_userアカウントはマージされます。c##common_userはそのパスワードをcdb_2で保持します。cdb_2で割り当てられ、cdb_1では割り当てられていない権限は、pdb_1でローカルに保持されます。

2.2.1.3 ローカル・ユーザーについて

マルチテナント環境では、ローカル・ユーザーとは、単一のPDBにのみ存在するデータベース・ユーザーです。

ローカル・ユーザーは管理権限を持つことができますが、これらの権限はローカル・ユーザー・アカウントが作成されたPDBにのみ適用されます。ローカル・ユーザー・アカウントには、共通ユーザー・アカウントと区別する次の特性があります。

  • ローカル・ユーザー・アカウントは、共通ユーザー・アカウントを作成できないまたは権限をローカルに付与できません。適切な権限を持つ共通ユーザーは、共通またはローカル・ユーザー・アカウントを作成および変更し、共通またはローカルに権限を付与および取り消すことができます。ローカル・ユーザーは、ローカル・ユーザー・アカウントを作成または変更したり、指定のPDBの共通またはローカル・ユーザーに権限をローカルに付与できます。

  • ローカル・ユーザー・アカウントの共通ロールを付与できます。ただし、共通ロールに関連付けられている権限は、ローカル・ユーザーのPDBにのみ適用されます。

  • ローカル・ユーザーは、そのPDB内のみで一意にする必要があります。

  • 適切な権限がある場合、ローカル・ユーザーは、共通ユーザーのスキーマのオブジェクトにアクセスできます。たとえば、共通ユーザーのスキーマ内の表にアクセスするためのローカル・ユーザー権限が共通ユーザーに付与されている場合、ローカル・ユーザーはその表にアクセスできます。

  • 共通ユーザー・アカウントではなくローカル・ユーザー・アカウントのエディションに対応できます。

2.2.2 ユーザー・アカウントの作成者とは

CREATE USERシステム権限を付与されているユーザーは、ユーザー・アカウント(プロキシ・ユーザーとして使用されるユーザー・アカウントを含む)を作成できます。

CREATE USERは強力なシステム権限であるため、通常、この権限を持つユーザーはデータベース管理者またはセキュリティ管理者のみです。

自らユーザーを作成する権限を持つユーザーを作成するには、GRANT文にWITH ADMIN OPTION句を含めます。たとえば: 

GRANT CREATE USER TO lbrown WITH ADMIN OPTION;

権限を付与するすべてのユーザー・アカウントと同様に、これらの権限を信頼できるユーザーのみに付与します。

マルチテナント環境で共通ユーザー・アカウントを作成するには、共通に付与されるCREATE USERシステム権限が必要です。ローカル・ユーザー・アカウントを作成するには、ローカル・ユーザー・アカウントを作成するPDB内に、共通に付与されるCREATE USER権限またはローカルに付与されるCREATE USER権限が必要です。

ノート:

セキュリティ管理者は、独自のロールを作成し、必要な権限のみを割り当てる必要があります。たとえば、それまでCONNECT権限を付与されていた多くのユーザーは、CONNECTで提供されていた追加権限を必要とはしていませんでした。かわりに、CREATE SESSIONのみが実際には必要でした。デフォルトでは、SET CONTAINER権限がCONNECTロールに付与されます。

組織固有のロールを作成することによって、組織で割り当てる権限を詳細に制御でき、Oracle Databaseが定義するロールが将来のリリースで変更された場合に組織を保護できます。

関連トピック

親トピック: ユーザー・アカウントの作成

2.2.3 最小限のデータベース権限を持つ新しいユーザー・アカウントの作成

新しいユーザー・アカウントを作成する場合、このユーザーがデータベースにアクセスできるようにする必要があります。

  1. CREATE USER文を使用して新しいユーザー・アカウントを作成します。

    たとえば:

    CREATE USER jward 
 IDENTIFIED BY password 
 DEFAULT TABLESPACE example 
 QUOTA 10M ON example 
 TEMPORARY TABLESPACE temp
 QUOTA 5M ON system 
 PASSWORD EXPIRE;

    「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

    この例では、ローカル・ユーザー・アカウントを作成し、ユーザー・パスワード、デフォルト表領域、一時セグメントが作成される一時表領域、表領域の割当て制限およびプロファイルを指定します。

  2. 少なくとも、データベース・インスタンスにアクセスできるように、ユーザーにCREATE SESSION権限を付与します。 
    GRANT CREATE SESSION TO jward;

    新規作成されたユーザーは、CREATE SESSION権限を持つまでデータベースに接続できません。Oracle Enterprise Managerへのアクセスが必要なユーザーには、SELECT ANY DICTIONARY権限も付与する必要があります。

関連トピック

親トピック: ユーザー・アカウントの作成

2.2.4 新しいアカウントのユーザー名の作成に関する制限事項

ユーザー・アカウントの名前を指定する場合は、名前が一意かどうかやネーミング規則などの制限事項に注意する必要があります。

  • ユーザー名の一意性
    各ユーザーにはスキーマが関連付けられています。スキーマ内の各スキーマ・オブジェクトには、必ず一意の名前を指定する必要があります。
  • マルチテナント環境のユーザー名
    各PDB内のユーザー名は、そのPDB内の他のユーザー名およびロールと比較して一意である必要があります。
  • ユーザー名の大/小文字の区別
    ユーザー名をどのように作成するかによって、データベースに格納されるユーザー名の大文字と小文字の区別が決まります。

親トピック: ユーザー・アカウントの作成

2.2.4.1 ユーザー名の一意性

各ユーザーにはスキーマが関連付けられています。スキーマ内の各スキーマ・オブジェクトには、必ず一意の名前を指定する必要があります。

Oracle Databaseでは、すでに存在しているユーザー名は作成できません。DBA_USERSデータ・ディクショナリ・ビューのUSERNAME列を問い合せて、既存の名前を確認できます。

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

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

次の制約に注意してください:

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

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

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

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

2.2.4.3 ユーザー名の大/小文字の区別

ユーザー名をどのように作成するかによって、データベースに格納されるユーザー名の大文字と小文字の区別が決まります。

たとえば: 

CREATE USER jward
 IDENTIFIED BY password
 DEFAULT TABLESPACE data_ts
 QUOTA 100M ON test_ts
 QUOTA 500K ON data_ts
 TEMPORARY TABLESPACE temp_ts
 PROFILE clerk
 CONTAINER = CURRENT;

ユーザーjwardはデータベースに大文字で格納されます。たとえば: 

SELECT USERNAME FROM ALL_USERS;

USERNAME
---------
JWARD
...

しかし、ユーザー名を二重引用符で囲むと、このユーザー名は名前に使用した大/小文字の区別を使用して格納されます。たとえば:

CREATE USER "jward" IDENTIFIED BY password;

そのため、ALL_USERSデータ・ディクショナリ・ビューを問い合せると、ユーザー・アカウントが作成に使用した大/小文字を使用して格納されていることがわかります。 

SELECT USERNAME FROM ALL_USERS;

USERNAME
---------
jward
...

ユーザーJWARDとユーザーjwardは、どちらも別々のユーザー・アカウントとしてデータベースに格納されています。後で、二重引用符を使用して作成したユーザーを変更または削除する場合は、そのユーザー名を二重引用符で囲む必要があります。

たとえば:

DROP USER "jward";

2.2.5 ユーザーへのパスワードの割当て

CREATE USER文のIDENTIFIED BY句で、ユーザーにパスワードを割り当てます。

安全性の高いパスワードを作成していることを確認します。

最小限のデータベース権限を持つ新しいユーザー・アカウントの作成の例では、新しいローカル・ユーザーはデータベースを使用して認証されます。この場合、接続に成功するために、接続ユーザーはデータベースに対して正しいパスワードを指定する必要があります。 

CREATE USER jward
 IDENTIFIED BY password
 DEFAULT TABLESPACE data_ts
 QUOTA 100M ON test_ts
 QUOTA 500K ON data_ts
 TEMPORARY TABLESPACE temp_ts
 PROFILE clerk
 CONTAINER = CURRENT;

関連トピック

親トピック: ユーザー・アカウントの作成

2.2.6 ユーザーのデフォルト表領域

デフォルト表領域は、ユーザーが作成するオブジェクトを格納します。

親トピック: ユーザー・アカウントの作成

2.2.6.1 ユーザーに対するデフォルト表領域の割当てについて

各ユーザーには、デフォルト表領域が必要です。

スキーマ・オブジェクトがユーザーのスキーマ内に作成され、かつそのDDL文でそのオブジェクトを格納する表領域が指定されていない場合、そのオブジェクトはユーザーのデフォルト表領域に格納されます。

表領域を使用すると、ユーザー・データとシステム・データ(SYSTEM表領域に格納されるデータなど)を区別できます。CREATE USER文またはALTER USER文を使用して、ユーザーにデフォルト表領域を割り当てます。すべてのユーザーのデフォルト表領域に対するデフォルト設定は、SYSTEM表領域です。ユーザーがオブジェクトを作成せず、オブジェクトを作成するための権限も持っていない場合は、デフォルト設定のままで問題ありません。ただし、任意のタイプのオブジェクトを作成する可能性があるユーザーには、デフォルト表領域(USERS表領域など)を明示的に割り当てる必要があります。SYSTEM以外の表領域を使用すると、同じデータ・ファイルに対するデータ・ディクショナリ・オブジェクトとユーザー・オブジェクト間の競合が解消されます。通常、ユーザー・データはSYSTEM表領域に格納しないでください。

CREATE TABLESPACE SQL文を使用して、データベースの作成時に、データベースの永続オブジェクトのデフォルトとして使用される、SYSTEM以外のデフォルト永続表領域を作成できます。ユーザー・データをシステム・データと区切ることにより、状況次第ではデータベース全体が機能不全になる場合もある、SYSTEM表領域に関する問題が生じる可能性を減らすことができます。このデフォルトの永続表領域は、システム・ユーザー、つまりデフォルトの永続表領域がSYSTEMであるSYS、SYSTEM、およびOUTLNが使用するものではありません。デフォルト永続表領域として指定されている表領域は削除できません。目標を達成するためには、最初にデフォルトの永続表領域として他の表領域を指定する必要があります。ALTER TABLESPACE SQL文を使用して、デフォルトの永続表領域を他の表領域に変更できます。この変更はALTER DDL文の実行後に作成されたすべてのユーザーまたはオブジェクトに影響を及ぼすことに注意してください。

ユーザー作成時に、そのユーザーのデフォルト表領域を設定しておき、作成後にALTER USER文を使用して変更することもできます。ユーザーのデフォルト表領域を変更すると、設定の変更後に作成されたオブジェクトのみがこの変更の影響を受けます。

ユーザーのデフォルト表領域を指定するときは、その表領域に対する割当て制限もあわせて指定してください。

2.2.6.2 デフォルト表領域を割り当てるためのDEFAULT TABLESPACE句

CREATE USER文のDEFAULT TABLESPACE句で、ユーザーにデフォルト表領域を割り当てます。

次のCREATE USER文では、ローカル・ユーザーjwardのデフォルト表領域はdata_tsです。 

CREATE USER jward
 IDENTIFIED BY password
 DEFAULT TABLESPACE data_ts
 QUOTA 100M ON test_ts
 QUOTA 500K ON data_ts
 TEMPORARY TABLESPACE temp_ts
 PROFILE clerk
 CONTAINER = CURRENT;

2.2.7 ユーザーの表領域の割当て制限

表領域の割当て制限により、ユーザーの表領域に提供される領域の量が決まります。

親トピック: ユーザー・アカウントの作成

2.2.7.1 ユーザーへの表領域割当て制限の割当てについて

各ユーザーには、任意の表領域(一時表領域を除く)に対する表領域割当て制限を設定できます。

割当て制限による影響は、次のとおりです。

  • 特定タイプのオブジェクトを作成する権限があるユーザーは、指定した表領域内にオブジェクトを作成できます。

  • Oracle Databaseでは、指定した表領域内にあるユーザーのオブジェクトの記憶域に対して割当て可能な領域は、割当て制限以内に制限されます。

デフォルトでは、ユーザーに対するデータベースの表領域の割当て制限はありません。ユーザーがスキーマ・オブジェクトを作成する権限を持っている場合は、このユーザーがオブジェクトを作成できるようにするための割当て制限を割り当てる必要があります。最低でも、ユーザーにはデフォルト表領域の割当て制限と、ユーザーがオブジェクトを作成する他の表領域の追加割当て制限を割り当てます。表領域に割り当てることができる最大領域は2 TBです。より多くの領域が必要な場合は、QUOTA句にUNLIMITEDを指定します。

ユーザーの割当て制限では、各表領域の一定量のディスク領域を個別に割り当てるか、またはすべての表領域のディスク領域を無制限に割り当てるかのどちらかを選択できます。一定量の割当て制限を設定すると、ユーザーのオブジェクトによってデータベースの領域が大量に使用されるのを防止できます。

ユーザーの表領域に対する割当て制限は、ユーザーを作成するときに割り当てることができ、後で割当て制限の追加または変更もできます。(USER_TS_QUOTASビューを問い合せることで、既存ユーザーの割当て制限を確認できます。)新しい割当て制限が古い割当て制限より少ない場合は、次の状況が当てはまります。

  • ユーザーがすでに新しい表領域割当て制限を超過している場合は、これらのオブジェクトをあわせた領域が新しい割当て制限より少なくならないかぎり、その表領域のユーザー・オブジェクトに追加の領域を割り当てることはできません。

  • ユーザーが新しい表領域割当て制限を超過していない場合、つまり表領域内でユーザーのオブジェクトが使用している領域が新しい表領域割当て制限よりも少ない場合は、そのユーザーのオブジェクトに新しい割当て制限までの領域を割り当てることができます。

2.2.7.2 表領域の割当て制限を割り当てるためのCREATE USER文

CREATE USER文のQUOTA句は、表領域の割当て制限を割り当てます。

次のCREATE USER文では、test_tsおよびdata_ts表領域に対して割当て制限を割り当てています。 

CREATE USER jward
 IDENTIFIED BY password
 DEFAULT TABLESPACE data_ts
 QUOTA 500K ON data_ts
 QUOTA 100M ON test_ts
 TEMPORARY TABLESPACE temp_ts
 PROFILE clerk
 CONTAINER = CURRENT;
2.2.7.3 表領域でのユーザー・オブジェクトに対する割当て限度の制限

現在の割当てがゼロになるように、表領域内のユーザー・オブジェクトに割当て制限を設定できます。

割当て制限を指定するには、ALTER USER SQL文を使用します。

ゼロの割当て制限が割り当てられると、表領域内のユーザーのオブジェクトはそのまま残り、ユーザーは引き続き新規オブジェクトを作成できますが、既存のオブジェクトには新しい領域が割り当てられなくなります。たとえば、このユーザーの既存の表の1つにデータを挿入することはできません。操作は失敗し、 ORA-1536表に対する領域割当て制限を使い果たしました。エラーが発生します。

2.2.7.4 ユーザーへのUNLIMITED TABLESPACEシステム権限の付与

データベース内の表領域を無制限に使用することをユーザーに許可するには、そのユーザーにUNLIMITED TABLESPACEシステム権限を付与します。

UNLIMITED TABLESPACE権限によって、そのユーザーに対する明示的な表領域の割当て制限がすべて置き換えられます。後で権限を取り消す場合、個々の表領域に対して割当て制限を明示的に付与する必要があります。この権限は、ロールに対してではなく、ユーザーに対してのみ付与できます。

UNLIMITED TABLESPACEシステム権限を付与する前に、この方法のメリットとデメリットを考慮してください。

メリット:

  • データベースのすべての表領域に無制限にアクセスできる権限を1つの文でユーザーに付与できます。

デメリット:

  • この権限によって、そのユーザーに対する明示的な表領域割当て制限がすべて置き換えられます。

  • UNLIMITED TABLESPACEシステム権限を持つユーザーから表領域へのアクセス権を選択的に取り消すことはできません。この権限を取り消した後でのみ、選択的または制限付きアクセス権を付与できます。

2.2.8 ユーザーの一時表領域

一時表領域には、ユーザー・セッションの存続期間中のみ保持される一時データが含まれています。

親トピック: ユーザー・アカウントの作成

2.2.8.1 ユーザーに対する一時表領域の割当てについて

各ユーザーには、一時表領域を割り当てる必要があります。

ユーザーが一時セグメントを必要とするSQL文を実行すると、このセグメントはそのユーザーの一時表領域に格納されます。これらの一時セグメントは、ソート操作または結合操作の実行時にシステムによって作成されます。一時セグメントは、すべての表領域のリソースに関する権限を持つSYSが所有します。

一時表領域を作成するには、CREATE TEMPORARY TABLESPACE SQL文を使用できます。

ユーザーの一時表領域を明示的に割り当てない場合、そのユーザーには、データベース作成時に指定された、または作成後にALTER DATABASE文によって指定されたデフォルト一時表領域が割り当てられます。デフォルトの一時表領域が明示的に割り当てられていない場合、デフォルトはSYSTEM表領域またはシステム管理者が設定した別のデフォルト永続表領域になります。一時表領域として使用する表領域を明示的に割り当てることによって、一時セグメントとそれ以外のタイプのセグメントとの間で発生するファイルの競合が解消されます。

ノート:

SYSTEM表領域がローカル管理の場合、ユーザーには特定のデフォルト(ローカル管理)一時表領域を割り当てる必要があります。永続的なローカル管理表領域には、一時オブジェクトを格納できないため、SYSTEM表領域の使用はデフォルトで禁止されます。

ユーザー作成時に、そのユーザーの一時表領域を設定しておき、作成後にALTER USER文を使用して変更できます。個々の一時表領域を割り当てるかわりに、表領域グループを設定することもできます。

2.2.8.2 一時表領域を割り当てるためのTEMPORARY TABLESPACE句

CREATE USER文のTEMPORARY TABLESPACE句で、ユーザーに一時表領域を割り当てます。

次の例では、jwardの一時表領域はtemp_tsです。これは一時セグメントのみを格納するために明示的に作成された表領域です。 

CREATE USER jward
 IDENTIFIED BY password
 DEFAULT TABLESPACE data_ts
 QUOTA 100M ON test_ts
 QUOTA 500K ON data_ts
 TEMPORARY TABLESPACE temp_ts
 PROFILE clerk
 CONTAINER = CURRENT;

2.2.9 ユーザーのプロファイル

プロファイルとは、データベース・リソースとそのデータベースへのパスワード・アクセスについて属性によって定義される一連の制限です。

プロファイルは複数のユーザーに適用でき、それらのユーザーはそうした属性を共有できます。

ユーザーの作成時に、プロファイルを指定できます。CREATE USER文のPROFILE句は、ユーザーにプロファイルを割り当てます。プロファイルを指定しない場合、ユーザーにはデフォルト・プロファイルが割り当てられます。

たとえば: 

CREATE USER jward
 IDENTIFIED BY password
 DEFAULT TABLESPACE data_ts
 QUOTA 100M ON test_ts
 QUOTA 500K ON data_ts
 TEMPORARY TABLESPACE temp_ts
 PROFILE clerk
 CONTAINER = CURRENT;

マルチテナント環境では、ルートおよびPDBの共通ユーザーに異なるプロファイルを割り当てることができます。共通ユーザーがPDBにログインすると、設定がセッションに適用されるプロファイルは、設定がパスワード関連であるかリソース関連であるかに応じて異なります。

  • パスワード関連のプロファイル設定は、ルートの共通ユーザーに割り当てられたプロファイルからフェッチされます。たとえば、共通プロファイルc##prof(FAILED_LOGIN_ATTEMPTSが1に設定されている)をルートの共通ユーザーc##adminに割り当てるとします。PDBでは、そのユーザーにはローカル・プロファイルlocal_prof (FAILED_LOGIN_ATTEMPTSを6に設定)が割り当てられるとします。loc_profが割り当てられているPDBにログインする場合、共通ユーザーc##adminは、1回のログインの失敗のみ許可されます。

  • ルートの共通ユーザーに割り当てられたプロファイルのリソース関連の設定を参照せずに、PDBのユーザーに割り当てられたプロファイルに指定されたリソース関連のプロファイル設定が使用されます。たとえば、PDBのユーザーc##adminに割り当てられたプロファイルlocal_profでSESSIONS_PER_USERが2に設定されている場合、c##adminは、loc_profが割り当てられたPDBにログインすると、ルートで割り当てられたプロファイルにおけるこの設定の値に関係なく、許可される同時セッション数は2つのみになります。

関連トピック

親トピック: ユーザー・アカウントの作成

2.2.10 共通ユーザーまたはローカル・ユーザーの作成

CREATE USER SQL文を使用して、共通(CDBおよびアプリケーション)ユーザーとローカル・ユーザーの両方を作成できます。

親トピック: ユーザー・アカウントの作成

2.2.10.1 共通ユーザー・アカウントの作成について

作成できる場所、ネーミング規則、スキーマに保存されるオブジェクトなど、共通ユーザー・アカウントの制限事項に注意してください。

共通ユーザー・アカウントを作成するには、次の規則に従います。

  • CDB共通ユーザーを作成するには、CDBルートに接続し、共通に付与されるCREATE USERシステム権限を持っていることが必要です。

  • アプリケーション共通ユーザーを作成するには、アプリケーション・ルートに接続し、共通に付与されるCREATE USERシステム権限を持っていることが必要です。

  • CREATE USER ... CONTAINER = ALL文を実行して、アプリケーション・ルートでアプリケーション共通ユーザーを作成できます。その後、このユーザーがアプリケーションPDBで表示されるように、アプリケーションを同期する必要があります。たとえば、saas_sales_appというアプリケーションでは次のようになります。 

    ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;

  • CDBルートに接続する共通ユーザーに付ける名前は、CDBルートのCOMMON_USER_PREFIXパラメータで定義された接頭辞(デフォルトでは、C##)で始まる必要があります。(このパラメータは変更できますが、十分に注意して行うようにしてください。)名前に使用できるのは、ASCIIまたはEBCDIC文字のみです。このネーミング要件は、SYSやSYSTEMなど、Oracle提供の既存のユーザー・アカウントの名前には適用されません。既存のユーザー・アカウントの名前を確認するには、ALL_USERS、CDB_USERS、DBA_USERSおよびUSER_USERSデータ・ディクショナリ・ビューを問い合せます。

  • アプリケーション・ルートに接続する共通ユーザーに付ける名前は、標準ユーザー・アカウントのネーミング規則に従う必要があります。デフォルトでは、アプリケーション・ルートでCOMMON_USER_PREFIXパラメータが空の文字列に設定されています。つまり、アプリケーション・ルートでhr_adminというユーザーを作成できますが、c##hr_adminというユーザーは作成できません。

  • CDBまたはアプリケーション共通ユーザーとしてユーザー・アカウントを明示的に指定するには、CREATE USER文で、CONTAINER=ALL句を指定します。CDBルートまたはアプリケーション・ルートにログインしている場合に、CREATE USER文からCONTAINER句を省略すると、CONTAINER=ALL句が暗黙のうちに入れられます。

  • CDBの共通ユーザーのスキーマにはオブジェクトを作成しないでください。かわりに、アプリケーション共通オブジェクトを作成できます。これらは、アプリケーション・コンテナに属するすべてのアプリケーションPDB間でメタデータおよび(データ・リンクまたは拡張データ・リンクの場合は)データが共有されるオブジェクトです。アプリケーション共通オブジェクトは、アプリケーション・コンテナのルートで作成する必要があります。

  • CDBまたはアプリケーション共通ユーザー・アカウントのCREATE USER文でDEFAULT TABLESPACE、TEMPORARY TABLESPACE、QUOTA...ONおよびPROFILE句を指定する場合、CDB共通ユーザーのCDBのすべてのコンテナに、またはアプリケーション共通ユーザーのアプリケーション・コンテナのアプリケーション・ルートおよびすべてのPDBに、これらのオブジェクト(表領域、表領域グループおよびプロファイル)が存在することを確認する必要があります。

2.2.10.2 共通ユーザー・アカウントを作成するためのCREATE USER文

CREATE USER文のCONTAINER=ALL句を使用して、共通ユーザー・アカウントを作成できます。

CDB共通ユーザー・アカウントを作成するにはCDBルートに、アプリケーション共通ユーザー・アカウントを作成するにはアプリケーション・ルートにいる必要があります。

次の例は、CONTAINER句を使用してCDBルートからCDB共通ユーザー・アカウントを作成し、そのユーザーにSET CONTAINERおよびCREATE SESSION権限を付与する方法を示しています。共通ユーザーは、コンテナ間を移動するためにSET CONTAINERシステム権限を必要とします。このアカウントを作成すると、すべてのコンテナでこの共通ユーザーに1つの共通パスワードが作成されます。 

CONNECT SYSTEM
Enter password: password
Connected.

CREATE USER c##hr_admin
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON test_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
CONTAINER = ALL;

GRANT SET CONTAINER, CREATE SESSION TO c##hr_admin 
CONTAINER = ALL;

次の例は、CONTAINER句を使用してアプリケーション・ルート(app_root)でアプリケーション共通ユーザーを作成し、そのユーザーにSET CONTAINERおよびCREATE SESSIONシステム権限を付与する方法を示しています。最後に、このユーザーがアプリケーションPDBで表示されるように同期するため、ALTER PLUGGABLE DATABASE APPLICATION APP$CON SYNC文が実行されています。 

CONNECT SYSTEM@app_root
Enter password: password
Connected.

CREATE USER app_admin
IDENTIFIED BY password
DEFAULT TABLESPACE data_ts
QUOTA 100M ON temp_ts
QUOTA 500K ON data_ts
TEMPORARY TABLESPACE temp_ts
CONTAINER = ALL;

GRANT SET CONTAINER, CREATE SESSION TO app_admin CONTAINER = ALL; 

CONNECT SYSTEM@app_hr_pdb
Enter password: password
Connected.

ALTER PLUGGABLE DATABASE APPLICATION APP$CON SYNC;
2.2.10.3 ローカル・ユーザー・アカウントの作成について

作成できる場所、ネーミング規則、スキーマに保存されるオブジェクトなど、ローカル・ユーザー・アカウントの制限事項に注意してください。

ローカル・ユーザー・アカウントを作成するには、次の規則に従います。

  • ローカル・ユーザー・アカウントを作成するには、アカウントを作成するPDBに接続して、CREATE USER権限を持つ必要があります。

  • ローカル・ユーザーに付ける名前は、共通ユーザー用に予約された接頭辞(CDB共通ユーザーの場合、デフォルトではC##)で始めることはできません。

  • CREATE USER文にCONTAINER=CURRENTを含め、ローカル・ユーザーとしてユーザーを指定できます。PDBに接続しており、この句を省略すると、CONTAINER=CURRENT句が含まれます。

  • 共通ユーザーとローカル・ユーザーの名前を同じにすることはできません。ただし、異なるPDBのローカル・ユーザーに同じ名前を使用できます。既存のユーザー・アカウントの名前を確認するには、ALL_USERS、CDB_USERS、DBA_USERSおよびUSER_USERSデータ・ディクショナリ・ビューを問い合せます。

  • 適切な権限があれば、PDBに接続されている共通ユーザーとローカル・ユーザーの両方で、ローカル・ユーザー・アカウントを作成できます。

2.2.10.4 ローカル・ユーザー・アカウントを作成するためのCREATE USER文

CREATE USER文のCONTAINER句を使用して、ローカル・ユーザー・アカウントを作成できます。

ローカル・ユーザー・アカウントは、そのアカウントを配置するPDBに作成する必要があります。

次の例は、CONTAINER句を使用したローカル・ユーザー・アカウントの作成方法を示しています。 

CONNECT SYSTEM@hrpdb
Enter password: password
Connected.

CREATE USER kmurray
 IDENTIFIED BY password
 DEFAULT TABLESPACE data_ts
 QUOTA 100M ON test_ts
 QUOTA 500K ON data_ts
 TEMPORARY TABLESPACE temp_ts
 PROFILE hr_profile
 CONTAINER = CURRENT;

2.2.11 ユーザーのデフォルト・ロールの作成

デフォルト・ロールは、ユーザーがセッションを作成したときに、自動的にそのユーザーに対して使用可能になります。

ユーザーには複数のデフォルト・ロールを割り当てることができますが、割り当てなくてもかまいません。CREATE USER文ではユーザーのデフォルト・ロールを設定できません。ユーザーを最初に作成すると、ユーザーのデフォルト・ロール設定はALLであり、ユーザーにその後に付与されるすべてのロールがデフォルト・ロールになります。

  • ALTER USER文を使用して、ユーザーのデフォルト・ロールを変更します。

たとえば:

GRANT USER rdale clerk_mgr;

ALTER USER rdale DEFAULT ROLE clerk_mgr;

ロールをユーザーのデフォルト・ロールにするには、そのロールがユーザーに付与されている必要があります。

関連トピック

親トピック: ユーザー・アカウントの作成

2.3 ユーザー・アカウントの変更

ALTER USER文で、デフォルトの表領域やプロファイル、ユーザー・パスワードの変更など、ユーザー・アカウントを変更します。

親トピック: Oracle Databaseユーザーのセキュリティの管理

2.3.1 ユーザー・アカウントの変更について

ユーザーのセキュリティ設定の変更は、現行セッションではなく、それより後のユーザー・セッションから反映されます。

ほとんどの場合、ユーザーのセキュリティ設定を変更するには、ALTER USER SQL文を使用します。ユーザーは、自分のパスワードを変更できます。ただし、ユーザーのセキュリティ・ドメインの他のオプションを変更するには、ALTER USERシステム権限が必要です。通常は、セキュリティ管理者のみがこのシステム権限を持ちます。これは、この権限によってすべてのユーザーのセキュリティ・ドメインを変更できるためです。この権限には、データベースの任意の表領域に対するユーザーの表領域割当て制限を設定する許可が含まれています。これは、変更を実行するユーザーが、指定した表領域に対する割当て制限を持っていない場合も同じです。

マルチテナント環境で共通ユーザー・アカウントを変更するには、共通に付与されるALTER USERシステム権限が必要です。ローカル・ユーザー・アカウントを変更するには、ローカル・ユーザー・アカウントが存在するPDB内で、共通に付与されるALTER USER権限またはローカルに付与されるALTER USER権限が必要です。

親トピック: ユーザー・アカウントの変更

2.3.2 共通ユーザー・アカウントまたはローカル・ユーザー・アカウントの変更方法

ALTER USER文またはPASSWORDコマンドを使用して、共通ユーザー・アカウントとローカル・ユーザー・アカウントの両方を変更できます。

既存の共通ユーザー・アカウントをローカル・ユーザー・アカウントに変更したり、ローカル・ユーザー・アカウントを共通ユーザー・アカウントに変更することはできません。この場合は、共通ユーザー・アカウントまたはローカル・ユーザー・アカウントとして、新しいアカウントを作成する必要があります。

次の例は、ALTER USER文を使用して、ユーザーc##hr_adminがV$SESSION行を表示する機能を、接続先がCDB$ROOTならびにemp_dbおよびhr_db PDBであるセッションに関連するものに制限する方法を示しています。 

CONNECT SYSTEM
Enter password: password
Connected.

ALTER USER c##hr_admin
 DEFAULT TABLESPACE data_ts
 TEMPORARY TABLESPACE temp_ts
 QUOTA 100M ON data_ts
 QUOTA 0 ON test_ts
 SET CONTAINER_DATA = (emp_db, hr_db) FOR V$SESSION 
 CONTAINER = CURRENT;

このALTER USER文によって、ユーザーc##hr_adminのセキュリティ設定は次のように変更されます。

  • DEFAULT TABLESPACEおよびTEMPORARY TABLESPACEは、data_tsおよびtemp_tsにそれぞれ明示的に設定されます。

  • QUOTA 100Mは、data_ts表領域に100MBを提供します。

  • QUOTA 0は、temp_ts表領域の割当て制限を取り消します。

  • SET CONTAINER_DATAは、ユーザーc##hr_adminがemp_dbおよびhr_db PDBに関するデータにアクセスすることを可能にし、このユーザーがルートからV$SESSIONビューを問い合せる場合はルートに関するデータにアクセスすることを可能にします。

パスワードを変更するにはALTER USERを使用できますが、SYS以外のユーザー・アカウントとSYSユーザー・アカウントの両方で、PASSWORDコマンドを使用してパスワードを変更することをお薦めします。

関連トピック

親トピック: ユーザー・アカウントの変更

2.3.3 SYS以外のユーザー・パスワードの変更

ユーザーは、自身のパスワードを変更できますが、他のユーザーのパスワードを変更するには、正しい権限が必要です。

親トピック: ユーザー・アカウントの変更

2.3.3.1 SYS以外のユーザーのパスワードの変更について

ユーザーは、PASSWORDコマンドまたはALTER USER文を使用してパスワードを変更できます。

ユーザーが自分のパスワードを変更するには、特別な権限(データベースへの接続およびセッションの作成権限以外)は不要です。ユーザーには、自分のパスワードを頻繁に変更することを薦めてください。ALL_USERSビューを問い合せることで、現行データベース・インスタンスの既存のユーザーを検索できます。

セキュリティを強化するには、PASSWORDコマンドを使用してアカウントのパスワードを変更します。ALTER USER文では、新規パスワードが画面に表示されるため、他者に見られる可能性があります。PASSWORDコマンドでは新規パスワードが表示されないため、自分のみが把握し、他者に知られることはありません。PASSWORDコマンドは、ネットワーク上のパスワードも暗号化します。ALTER USERはパスワードをクリア・テキストで送信するため、クライアントとデータベース間のネットワーク接続が暗号化されているか、セッションがネットワークを介してルーティングされないローカル・セッションである場合を除き、パスワードを使用しないでください。

ユーザーが認証方式を切り替えるには、PASSWORDとALTER USER権限が必要です。通常、この権限を持つのは管理者のみです。

2.3.3.2 PASSWORDコマンドまたはALTER USER文を使用したパスワードの変更

ほとんどのユーザーが、SQL*PlusのPASSWORDコマンドまたはALTER USER SQL文を使用して自身のパスワードを変更できます。

マルチテナント環境では、CDB共通ユーザーはCDBルートで自分のパスワードを変更する必要があり、アプリケーション共通ユーザーはアプリケーション・ルートで自分のパスワードを変更する必要があります。

  • 次のいずれかの方法を使用して、ユーザーのパスワードを変更します。

    • SQL*PlusのPASSWORDコマンドを使用してパスワードを変更するには、ユーザーの名前を指定し、プロンプトが表示された場合は新しいパスワードを入力します。

      たとえば:

      PASSWORD andy
Changing password for andy
New password: password
Retype new password: password

    • ALTER USER SQL文を使用してパスワードを変更するには、IDENTIFIED BY句を指定します。

      たとえば: 

      ALTER USER andy IDENTIFIED BY password;

2.3.4 SYSユーザー・パスワードの変更

SYSユーザーのパスワードを変更するには、ALTER USER文、PASSWORDコマンドまたはORAPWDコマンドライン・ユーティリティを使用できます。

親トピック: ユーザー・アカウントの変更

2.3.4.1 SYSユーザーのパスワードの変更について

選択したSYSパスワードを変更する方法は、データベースの構成方法(たとえば、REMOTE_LOGIN_PASSWORDFILE初期化パラメータの設定方法)によって異なります。

PASSWORDコマンド、ALTER USER文またはORAPWDユーティリティを使用して、SYSパスワードを変更できます。

SYS以外のユーザー・アカウントと同様に、PASSWORDを使用してSYSユーザー・アカウントを変更するのには十分な理由があります。PASSWORDは画面に新しいパスワードを表示せず、さらにPASSWORDはネットワーク上のパスワードを暗号化します。ALTER USERはパスワードをクリア・テキストで送信するため、クライアントとデータベース間のネットワーク接続が暗号化されているか、セッションがネットワークを介してルーティングされないローカル・セッションである場合を除き、パスワードを使用しないでください。したがって、リモート接続にはPASSWORDを使用する必要があります。

ALTER USER文には、ORAPWDを使用するよりも次の利点があります。

  • Oracleデータベース・インスタンス内からSYSユーザーのパスワードを変更できます。
  • Oracle Data Guard環境では、SYSパスワードの変更をOracle Data Guardインスタンスに伝播します。

共有パスワード・ファイルを使用するOracle Real Application Clusters (Oracle RAC)データベースには REMOTE_LOGIN_PASSWORDFILE = SHAREDが設定されるため、ALTER USERがSYSパスワードを更新できないことに注意してください。パスワード・ファイルが共有されておらず、パスワードが変更されている場合は、Oracle RACクラスタのすべてのノードにパスワード・ファイルをコピーする必要があります。

REMOTE_LOGIN_PASSWORDFILE初期化パラメータが設定されており、ALTER USERを使用してSYSパスワードを変更する場合は、次の点に注意してください:

  • REMOTE_LOGIN_PASSWORDFILE初期化パラメータがEXCLUSIVEに設定されていることを確認します。そうしないと、SYSユーザー・パスワードの変更(または管理ユーザー・パスワードの変更)の試行は失敗します。
  • REMOTE_LOGIN_PASSWORDFILEがnullの場合、またはNONEに設定されている場合は、パスワードを変更しようとすると失敗し、「ORA-01994: パスワード・ファイルが欠落しているか、無効です」というエラーが発生します。
  • REMOTE_LOGIN_PASSWORDFILEをSHAREDに設定した場合、パスワードを変更するALTER USER文は、ORA-28046: Password change for SYS disallowedエラーで失敗します。

ORAPWDを使用してSYSパスワードを変更する場合は、次の点に注意してください:

  • SYSユーザー・アカウントのパスワードを変更するには、このアカウントのパスワード・ファイルが存在している必要があります。

  • インスタンス初期化パラメータREMOTE_LOGIN_PASSWORDFILEがSHAREDに設定されている場合またはnullの場合は、ORAPWDを使用してSYSパスワードを変更する必要があります。

SYSユーザー・パスワードを変更するALTER USERメソッドとORAPWDメソッドの両方に、次が適用されます。

  • 新しいアカウントは、SHA-2 (SHA-512)ベリファイアで作成されます。SYSユーザー・ベリファイアは、sqlnet.oraパラメータALLOWED_LOGON_VERSION_SERVERに基づいて生成されます。DBA_USERSデータ・ディクショナリ・ビューのPASSWORD_VERSIONS列を問い合せて、これらのアカウントを識別できます。(これらのベリファイアは、DBA_USERSビュー出力のPASSWORD_VERSIONS列に12Cとしてリストされます。)

  • Oracle Real Application Clusters (Oracle RAC)環境では、複数のOracle RACインスタンスで共有できるように、パスワードをASMディスク・グループに格納してください。

2.3.4.2 SYSユーザーのパスワードを変更するためのORAPWDユーティリティ

ORAPWDユーティリティでは、SYSユーザーのパスワードを変更できます。

ORAPWDユーティリティでINPUT_FILEパラメータを使用して、SYSユーザーのパスワードを変更できます。パスワード・ファイルを特定の形式に移行するには、FORMATオプションを指定します。デフォルトでは、FORMATオプションが指定されていない場合の形式は12.2です。

ORAPWDユーティリティを使用してSYSユーザーの新しいパスワードを設定するには、SYSオプションをY (はい)に設定し、INPUT_FILEパラメータを使用して現在のパスワード・ファイル名を指定し、FILEパラメータを使用して元のパスワード・ファイルの移行先のパスワード・ファイルを作成します。たとえば: 

ORAPWD INPUT_FILE='orapworcl' FILE='orapwd' SYS=Y 
Enter password for SYS: new_password

new_passwordを安全なパスワードに置き換えます。パスワード・ファイルを別の形式に移行しない場合、input_fileと同じ形式を指定できます。たとえば、入力ファイルorapworclの形式が12で、SYSユーザー・パスワードを変更する場合、次のようになります。 

ORAPWD INPUT_FILE='orapworcl' FILE='orapwd' FORMAT=12 SYS=Y 
Enter password for SYS: new_password

2.4 ユーザー・リソース制限の構成

リソースの制限により、ユーザーに利用可能なシステム・リソースの量が決まります。

  • ユーザー・リソース制限について
    ユーザーのセキュリティ・ドメインの一部として、各ユーザーが使用できるシステム・リソースの容量に制限を設定できます。
  • システム・リソースのタイプと制限
    CPU時間や論理読取りなど、各種のシステム・リソースについて、セッション・レベル、コール・レベルまたはその両方のレベルで制限を課すことができます。
  • プロファイルのリソース制限の値
    プロファイルを作成しリソース制限を設定する前に、各リソース制限について適切な値を決定する必要があります。
  • プロファイルによるリソースの管理
    プロファイルとは、ユーザーのデータベース使用とインスタンス・リソースを制限する一連のリソース制限およびパスワード・パラメータに名前を付けたものです。

親トピック: Oracle Databaseユーザーのセキュリティの管理

2.4.1 ユーザー・リソース制限について

ユーザーのセキュリティ・ドメインの一部として、各ユーザーが使用できるシステム・リソースの容量に制限を設定できます。

そうすることで、CPUタイムなど貴重なシステム・リソースが無制限に消費されることを防ぐことができます。

このリソース制限機能は、システム・リソースに多額の費用がかかる大規模なマルチ・ユーザー・システムでは非常に有効です。1人以上のユーザーが過度にリソースを使用すると、データベースの他のユーザーに有害な影響を与える可能性があります。シングル・ユーザー・データベースや小規模なマルチ・ユーザー・データベースの場合は、ユーザーがシステム・リソースを消費しても影響は少ないため、システム・リソース機能はそれほど重要ではありません。

ユーザーのリソース制限は、データベース・リソース・マネージャを使用して管理します。パスワード管理の作業環境は、ユーザーごとに個別にプロファイルを使用して設定するか、または多数のユーザー用のデフォルト・プロファイルを使用して設定できます。それぞれのOracleデータベースに指定できるプロファイルの数に、制限はありません。Oracle Databaseでは、セキュリティ管理者が、プロファイルによるリソース制限の規定を全体的に使用可能または使用禁止に設定できます。

リソース制限を設定すると、ユーザーによるセッション作成時に、パフォーマンスがわずかに低下します。これは、各ユーザーがデータベースに接続した時点で、そのユーザーのすべてのリソース制限データがロードされるためです。

関連トピック

親トピック: ユーザー・リソース制限の構成

2.4.2 システム・リソースのタイプと制限

CPU時間や論理読取りなど、各種のシステム・リソースについて、セッション・レベル、コール・レベルまたはその両方のレベルで制限を課すことができます。

  • ユーザー・セッション・レベルの制限
    ユーザーがデータベースに接続すると、セッションが作成されます。セッションではCPU時間とメモリーが使用されますが、これらに制限を設定できます。
  • データベース・コール・レベルの制限
    ユーザーがSQL文を実行するたびに、Oracle Databaseでは、いくつかのステップが実行され文が処理されます。
  • CPU時間の制限
    SQL文やその他のコールがOracle Databaseに発行されると、そのコールを処理するためにCPU時間が必要になります。
  • 論理読取りの制限
    入出力(I/O)は、データベース・システムで最もリソースの使用量が多い操作の1つです。
  • その他のリソースの制限
    ユーザーの同時セッション数やアイドル時間に制限を設定できます。

親トピック: ユーザー・リソース制限の構成

2.4.2.1 ユーザー・セッション・レベルの制限

ユーザーがデータベースに接続すると、セッションが作成されます。セッションではCPU時間とメモリーが使用されますが、これらに制限を設定できます。

複数のリソース制限をセッション・レベルで設定できます。ユーザーがセッション・レベルのリソース限度を超えると、Oracle Databaseは現在の文を終了(ロールバック)して、セッション限度に達したことを示すメッセージを返します。この時点で、カレント・トランザクションのそれ以前の文のすべてがそのまま残り、ユーザーが実行できる操作のみがCOMMIT、ROLLBACK、または切断になります(この場合、カレント・トランザクションはコミットされます)。他のすべての操作はエラーになります。トランザクションがコミットまたはロールバックされた後も、ユーザーはこれ以上の作業をカレント・セッション中は完了できません。

2.4.2.2 データベース・コール・レベルの制限

ユーザーがSQL文を実行するたびに、Oracle Databaseでは、いくつかのステップが実行され文が処理されます。

SQL文の処理では、データベースに対して複数のコールが異なる実行フェーズの一部として発行されます。1回のコールで過度にシステムが使用されないように、Oracle Databaseでは、複数のリソース制限をコール・レベルで設定できます。

ユーザーがコール・レベルのリソース制限を超えると、Oracle Databaseは文の処理を停止してその文をロールバックし、エラーを戻します。ただし、カレント・トランザクションのそれ以前の文の結果はそのまま残り、そのユーザー・セッションは接続されたままになります。

2.4.2.3 CPU時間の制限

SQL文やその他のコールがOracle Databaseに発行されると、そのコールを処理するためにCPU時間が必要になります。

平均的なコールであれば、わずかなCPUタイムですみます。ただし、大量のデータや冗長な問合せを伴うSQL文はCPUタイムを大量に使用することがあるため、他の処理に使用できるCPUタイムが少なくなります。

CPUタイムが無制限に消費されないようにするため、1回のコール当たりのCPUタイムと、1つのセッション中にOracle Databaseコールに使用されるCPUタイムの合計に対して、固定した制限または動的な制限を設定できます。これらの制限は、コールやセッションに使用される1/100秒(0.01秒)単位のCPUタイムで設定し、測定されます。

2.4.2.4 論理読取りの制限

入出力(I/O)は、データベース・システムで最もリソースの使用量が多い操作の1つです。

I/Oを集中的に実行するSQL文は、メモリーとディスクの使用を独占することがあるため、他のデータベース操作がこれらのリソースをめぐって競合する原因になる可能性があります。

単一の原因による過度のI/Oが発生しないようにするために、1コール当たりおよび1セッション当たりの論理データ・ブロック読取り数を制限できます。論理データ・ブロック読取りには、メモリーとディスクの両方からの論理データ・ブロック読取りが含まれます。これらの制限は、1コールまたは1セッション中に実行されるブロック読取りの数として設定し、測定されます。

2.4.2.5 その他のリソースの制限

ユーザーの同時セッション数やアイドル時間に制限を設定できます。

その他のリソースの制限を次に示します。

  • ユーザー当たりの同時実行セッション数の制限。各ユーザーは、事前に定義された数まで同時実行セッションを作成できます。

  • セッションのアイドル時間の制限。1つのセッションでのコール間の時間がアイドル制限時間に達すると、カレント・トランザクションがロールバックされてセッションは終了し、そのセッションのリソースはシステムに戻されます。次のコールは、ユーザーがインスタンスから切断されたことを示すエラーを受け取ります。この制限は、分単位の経過時間として設定します。

    ノート:

    セッションがアイドル時間の制限を超えたために終了すると、その少し後に、終了したセッションの後処理としてプロセス・モニター(PMON)・バックグラウンド・プロセスがクリーン・アップを実行します。PMONがこのプロセスを完了するまでは、終了したセッションも、セッションまたはユーザー・レベルのリソース制限に加算されます。

  • セッション当たりの経過接続時間の制限。セッションの持続時間が経過制限時間を超えると、カレント・トランザクションがロールバックされてセッションが削除され、そのセッションのリソースがシステムに戻されます。この制限は、分単位の経過時間として設定します。

    ノート:

    Oracle Databaseは、経過アイドル時間や経過接続時間を絶えず監視しているわけではありません。絶えず監視した場合、システム・パフォーマンスが低下します。そのかわり数分ごとにチェックします。このため、Oracle Databaseがこの制限を規定してからセッションを終了させるまでの間に、セッションはこの制限をわずかに(5分など)超える可能性があります。

  • セッションのプライベート・システム・グローバル領域(SGA)(プライベートSQL領域に使用)の容量の制限。この制限が重要になるのは、共有サーバーの構成を使用するシステムの場合のみです。それ以外のシステムの場合、プライベートSQL領域はプログラム・グローバル領域(PGA)内にあります。この制限は、インスタンスのSGAに使用するメモリーのバイト数として設定します。KBまたはMBで指定するには、KまたはMの文字を使用します。

2.4.3 プロファイルのリソース制限の値

プロファイルを作成しリソース制限を設定する前に、各リソース制限について適切な値を決定する必要があります。

リソース制限の値は、典型的なユーザーが実行する操作のタイプを基準として決定できます。たとえば、あるクラスのユーザーが通常は大量の論理データ・ブロック読取りを実行しない場合は、ALTER RESOURCE COST SQL文を使用して、LOGICAL_READS_PER_SESSION設定を控えめに設定します。

通常、ユーザー・プロファイルの適切なリソース制限値を決定するには、それぞれのタイプのリソースの使用状況について履歴情報を収集するのが最善です。たとえば、データベース管理者やセキュリティ管理者は、AUDIT SESSION句を使用して、CONNECT_TIMEおよびLOGICAL_READS_PER_SESSIONの制限値についての情報を収集できます。

Oracle Data Guard環境では、アクティブ・スタンバイ・データベースが読取り専用モードでオープンされます。これにより、プライマリ・データベースに対してと同じようにそれに対するユーザー接続が可能になります。したがって、指定されたユーザー・プロファイルのパスワード・リソース関連の制限はすべて、単独で機能します(スタンバイ・データベースでのユーザー・パスワード変更を意味するか必要とするものを除く)。このタスクは、読取り専用モードでオープンされているデータベースでは実行できません。

その他の制限値の統計情報は、Oracle Enterprise Manager(またはSQL*Plus)のモニター機能、特に統計モニターを使用して収集できます。

親トピック: ユーザー・リソース制限の構成

2.4.4 プロファイルによるリソースの管理

プロファイルとは、ユーザーのデータベース使用とインスタンス・リソースを制限する一連のリソース制限およびパスワード・パラメータに名前を付けたものです。

親トピック: ユーザー・リソース制限の構成

2.4.4.1 プロファイルについて

プロファイルとは、ユーザーに適用される属性の集合です。

プロファイルは、これらの属性を複数のユーザーで共有する場合に参照される単一ポイントです。

profileを各ユーザーに割り当てる必要があります。各ユーザーに割り当てることができるプロファイルは1つのみで、新しいプロファイルを作成すると、以前の割当てと置き換えられます。

ユーザー・プロファイルを作成および管理できるのは、リソース制限がデータベースのセキュリティ・ポリシーの要件である場合のみです。プロファイルを使用するには、最初にデータベース内のユーザーの関連タイプを分類します。ロールを使用して関連ユーザーの権限を管理するのと同様に、プロファイルを使用して関連ユーザーのリソース制限を管理します。データベース内のすべてのカテゴリのユーザーを含めるために必要なプロファイル数を決定してから、プロファイルごとに適切なリソース制限を決定します。

Oracle Internet Directoryのユーザー・プロファイルには、各ユーザーのディレクトリ使用と認証に関連した属性が含まれています。同様に、Oracle Label Securityのプロファイルには、Oracle Label Securityのユーザー管理や操作管理に役立つ属性が含まれています。プロファイル属性にはシステム・リソースに関する制限を含めることができます。データベース・リソース・マネージャを使用すると、これらのタイプのリソース制限を設定できます。

マルチテナント環境では、プロファイルは、コンテナ・データベース(CDB)およびアプリケーション・コンテナのほか、それらが関連付けられたプラガブル・データベース(PDB)で行われる管理および操作に役立ちます。CDBとアプリケーション・コンテナのいずれの場合でも、共通プロファイルを定義すると、そのプロファイルはコンテナ全体に適用され、コンテナ外には適用されません。ローカル・プロファイルを作成した場合、プロファイルはそのPDBにのみ適用されます。

プロファイルのリソース制限が適用されるのは、対応するデータベースのリソース制限が使用可能な場合のみです。このリソース制限が使用可能になるのは、データベースの起動前(RESOURCE_LIMIT初期化パラメータを使用)またはオープン中(ALTER SYSTEM文を使用)のいずれかです。

パスワード・パラメータはプロファイル内にありますが、RESOURCE_LIMITまたはALTER SYSTEMの影響は受けず、パスワード管理は常に使用可能です。Oracle Databaseでは、主にデータベース・リソース・マネージャによって、リソースの割当てと制限が処理されます。

認可されたデータベース・ユーザーは、プロファイルの作成、ユーザーへの割当て、変更および削除を(CREATE USERまたはALTER USER文を使用して)随時実行できます。プロファイルは、ロールや他のプロファイルではなく、ユーザーにのみ割り当てることができます。プロファイルの割当ては現行のセッションには影響を与えず、それより後のセッションにのみ有効です。

現行のプロファイルに関する情報を検索するには、DBA_PROFILESビューを問い合せます。

関連項目:

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

親トピック: プロファイルによるリソースの管理

2.4.4.2 ora_stig_profileユーザー・プロファイル

ora_stig_profileユーザー・プロファイルは、セキュリティ技術導入ガイドに準拠するように設計されています。

ora_stig_profileユーザー・プロファイルは、パスワード複雑度ファンクション、ログインの最大失敗回数、最大再利用回数などの要件を求めるSTIG要件に対応します。このプロファイルの定義は次のとおりです。 
CREATE PROFILE ora_stig_profile
  password_life_time        60
  password_grace_time       5
  password_reuse_time       365
  password_reuse_max        10
  failed_login_attempts     3
  password_lock_time        unlimited
  inactive_account_time     35
  idle_time                 15
  password_verify_function  ora12c_stig_verify_function;
2.4.4.3 プロファイルの作成

プロファイルには、パスワードの制限やリソースの制限など、特定のカテゴリに対する制限が含まれます。

プロファイルを作成する場合、CREATE PROFILEシステム権限が必要です。すべての既存のプロファイルを検索するには、DBA_PROFILESビューを問い合せます。

  • プロファイルを作成するには、CREATE PROFILE文を使用します。

たとえば、パスワードの制限を定義するプロファイルを作成するとします。 

CREATE PROFILE password_prof LIMIT
  FAILED_LOGIN_ATTEMPTS 6
  PASSWORD_LIFE_TIME 60
  PASSWORD_REUSE_TIME 60
  PASSWORD_REUSE_MAX 5
  PASSWORD_LOCK_TIME 1/24
  PASSWORD_GRACE_TIME 10
  PASSWORD_VERIFY_FUNCTION DEFAULT;

次の例は、リソース制限プロファイルの作成方法を示しています。

CREATE PROFILE app_user LIMIT 
  SESSIONS_PER_USER          UNLIMITED 
  CPU_PER_SESSION            UNLIMITED 
  CPU_PER_CALL               3500 
  CONNECT_TIME               50 
  LOGICAL_READS_PER_SESSION  DEFAULT 
  LOGICAL_READS_PER_CALL     1200 
  PRIVATE_SGA                20K
  COMPOSITE_LIMIT            7500000;
2.4.4.4 CDBプロファイルまたはアプリケーション・プロファイルの作成

CREATE PROFILEまたはALTER PROFILE文のCONTAINER=ALL句で、CDBまたはアプリケーション・ルート内にプロファイルを作成できます。

ローカル・プロファイルは、CDBルートまたはアプリケーション・ルートでは作成できません。作成するプロファイルは、CDBルートまたはアプリケーション・ルートに関連付けられたすべてのPDBに適用されます。非マルチテナント環境と同様のパラメータを使用してプロファイルを作成します。
  • CDBルートまたはアプリケーション・ルートでプロファイルを作成するには、CREATE PROFILEまたはALTER PROFILE文にオプションとしてCONTAINER=ALL句を含めます。

    CONTAINER=ALL句をオプションとするのは、文が処理される場合のデフォルトであるためです。

たとえば:

CREATE PROFILE password_prof LIMIT
  FAILED_LOGIN_ATTEMPTS 6
  PASSWORD_LIFE_TIME 60
  PASSWORD_REUSE_TIME 60
  PASSWORD_REUSE_MAX 5
  PASSWORD_LOCK_TIME 1/24
  PASSWORD_GRACE_TIME 10
  PASSWORD_VERIFY_FUNCTION DEFAULT
  CONTAINER=ALL;
2.4.4.5 ユーザーへのプロファイルの割当て

プロファイルの作成後、ユーザーにプロファイルを割り当てることができます。

すでにプロファイルを割り当てられているユーザーにプロファイルを割り当てることはできますが、直近に割り当てられたプロファイルが優先されます。外部ユーザーまたはグローバル・ユーザーにプロファイルを割り当てる場合、パスワードのパラメータは、そのユーザーに対して有効ではありません。

ユーザーに現在割り当てられているプロファイルを検索するには、DBA_USERSビューを問い合せます。

  • ALTER USER文を使用して、ユーザーにプロファイルを割り当てます。

たとえば: 

ALTER USER psmith PROFILE app_user;
2.4.4.6 プロファイルの削除

プロファイルは、現在ユーザーに割り当てられている場合でも削除できます。

プロファイルを削除しても、現在アクティブなセッションに影響はありません。プロファイルの削除後に作成されたセッションのみが、変更されたプロファイル割当てを使用します。プロファイルを削除するには、DROP PROFILEシステム権限が必要です。デフォルトのプロファイルは削除できません。

  • プロファイルを削除するには、SQL文のDROP PROFILEを使用します。ユーザーに現在割り当てられているプロファイルを削除するには、CASCADEオプションを使用します。

たとえば:

DROP PROFILE clerk CASCADE;

削除するプロファイルに現在割り当てられているユーザーは、自動的にDEFAULTプロファイルに割り当てられます。DEFAULTプロファイルは削除できません。

2.5 ユーザー・アカウントの削除

ユーザーのスキーマにオブジェクトがある場合、そのユーザーがセッション中でなければユーザー・アカウントを削除できます。

親トピック: Oracle Databaseユーザーのセキュリティの管理

2.5.1 ユーザー・アカウントの削除について

ユーザー・アカウントを削除する前に、削除に適した権限があることを確認する必要があります。

いずれの環境でユーザー・アカウントを削除する場合でも、DROP USERシステム権限が必要です。マルチテナント環境で共通ユーザー・アカウントを削除するには、共通に付与されるDROP USERシステム権限が必要です。ローカル・ユーザー・アカウントを削除するには、ローカル・ユーザー・アカウントが存在するPDB内で、共通に付与されるDROP USER権限またはローカルに付与されるDROP USER権限が必要です。

ユーザー・アカウントを削除すると、Oracle Databaseではこのユーザー・アカウントおよび対応するスキーマがデータ・ディクショナリから削除されます。さらに、ユーザー・スキーマに含まれているすべてのスキーマ・オブジェクトも(存在する場合)削除されます。

ノート:

  • ユーザーのスキーマとそれに対応するオブジェクトは残したままで、データベースへのアクセスを拒否する場合は、そのユーザーからCREATE SESSION権限を取り消してください。

  • SYSユーザーまたはSYSTEMユーザーは削除しないでください。これらのユーザーを削除すると、データベースが破損します。

親トピック: ユーザー・アカウントの削除

2.5.2 ユーザー・セッションの終了

データベースに接続されているユーザーは削除できません。

ユーザーを削除する前に、まずユーザー・セッションを終了する必要があります(または、ユーザーがセッションを終了できます)。
  1. V$SESSION動的ビューを問い合せて、セッションを終了するユーザーのセッションIDを確認します。

    たとえば: 

    SELECT SID, SERIAL#, USERNAME FROM V$SESSION;

    SID         SERIAL# USERNAME
------- --------------- ----------------------
    127          55234  ANDY
...
  2. ALTER SYSTEM SQL文を使用して、V$SESSIONビューのSID設定とSERIAL#設定に基づき、ユーザーのセッションを終了します。

    たとえば: 

    ALTER SYSTEM KILL SESSION '127, 55234';

親トピック: ユーザー・アカウントの削除

2.5.3 ユーザーがデータベースから切断した後のユーザーの削除について

ユーザーがデータベースから切断した後に、DROP USER文を使用してユーザーを削除できます。

ユーザーとそのユーザーのスキーマ・オブジェクト(ある場合)をすべて削除するには、DROP USERシステム権限が必要です。DROP USERシステム権限は強力な権限であるため、通常はセキュリティ管理者のみがこの権限を持ちます。

ユーザーのスキーマに依存型のスキーマ・オブジェクトが含まれている場合に、ユーザーと対応付けられているすべてのオブジェクト、およびそのユーザーの表に依存している外部キーをすべて削除するには、CASCADEオプションを使用します。CASCADEを指定していない場合は、ユーザーのスキーマに依存型のオブジェクトが含まれていると、エラー・メッセージが戻され、ユーザーは削除されません。

親トピック: ユーザー・アカウントの削除

2.5.4 スキーマにオブジェクトが含まれるユーザーの削除

スキーマ内にオブジェクトを格納しているユーザーを削除する前に、スキーマ・オブジェクトを削除した場合の影響を徹底的に調べます。

  1. DBA_OBJECTSデータ・ディクショナリ・ビューを問い合せて、ユーザーが所有するオブジェクトを確認します。

    たとえば: 

    SELECT OWNER, OBJECT_NAME FROM DBA_OBJECTS WHERE OWNER LIKE 'ANDY';

    ユーザー名を大文字で入力します。事前に認識できない連鎖的な影響に注意してください。たとえば、表を所有するユーザーを削除する場合は、ビューまたはプロシージャがその表に依存していないかどうかを確認してください。

  2. ユーザーとすべての関連オブジェクト、およびそのユーザーが所有する表に依存する外部キーを削除するには、DROP USER SQL文とCASCADE句を使用します。

    たとえば: 

    DROP USER andy CASCADE;

親トピック: ユーザー・アカウントの削除

2.6 Oracle Databaseから提供される事前定義済のスキーマ・ユーザー・アカウント

Oracle Databaseのインストール・プロセスでは、事前定義された管理アカウント、非管理ユーザー・アカウント、およびサンプル・スキーマ・ユーザー・アカウントがデータベースに作成されます。

親トピック: Oracle Databaseユーザーのセキュリティの管理

2.6.1 事前定義済のスキーマ・ユーザー・アカウントについて

事前定義済のスキーマ・アカウントは、標準Oracleスクリプトの実行時に自動的に作成されるか、架空の会社を表すアカウントです。

事前定義済のスキーマ・アカウントは、次の2つのカテゴリに分類されます。

  • 事前定義済の管理および非管理スキーマ・アカウントは、様々なcat.*sqlスクリプトなどの標準スクリプトを実行すると自動的に作成されます。これらのアカウントは、ALL_USERSデータ・ディクショナリ・ビューのUSERNAME列およびORACLE_MAINTAINED列を問い合せることで検索できます。ORACLE_MAINTAINEDの出力がYの場合、そのユーザー・アカウントは、アカウントの作成に使用したスクリプトを実行するという方法以外で変更しないでください。

  • HRサンプル・スキーマ・ユーザー・アカウントはデフォルトでインストールされます。一連の追加のスキーマ・ユーザー・アカウント(OE、PM、IXおよびSHとHR)がGitHubで使用できます。これらのスキーマ・アカウントは、様々な製品を製造する架空の会社の異なる部門を表します。これらのアカウントのステータスは、DBA_USERSデータ・ディクショナリ・ビューを問い合せることで確認できます。これらのアカウントに対するORACLE_MAINTAINED列の出力はNになるため、これらのアカウントの作成に使用したスクリプトを再実行することなくアカウントの変更が可能です。

デフォルトでは、これらのアカウントのほとんどがスキーマ限定アカウントとして認証されます。ただし、サンプル・スキーマ・アカウントを除いて、データベース・インストール・プロセス中にロックされて期限切れになります。これらのアカウントを使用する場合、他の方法(パスワード認証など)で認証するように構成できますが、セキュリティを向上させるためにこれらのアカウントをスキーマ限定アカウントとして維持することをお薦めします。

関連トピック

親トピック: Oracle Databaseで提供される事前定義済のスキーマ・ユーザー・アカウント

2.6.2 事前定義済の管理アカウント

デフォルトのOracle Databaseインストールでは、監査などのよく使用される機能を管理するための事前定義された管理アカウントが提供されます。

これらのアカウントには、SYSスキーマが所有するパッケージのEXECUTE権限、CREATE ANY TABLE権限、またはALTER SESSIONのような、データベースの領域の管理に必要となる特別な権限を持ちます。管理アカウントのデフォルトの表領域は、SYSTEMかSYSAUXです。マルチテナント環境では、事前定義された管理アカウントはルート・データベースにあります。

これらのアカウントを無許可アクセスから保護するため、インストール・プロセスにより、次の表に示されたアカウントを除くほとんどのアカウントが期限切れにされ、ロックされます。データベース管理者には、これらのアカウントのロック解除とリセットを行う責任があります。

表2-1に、事前定義済の管理ユーザー・アカウントを示します。このアカウントは、標準スクリプト(各種のcat*.sqlスクリプトなど)の実行時に、Oracleデータベースによって自動的に作成されます。Oracleによって作成および維持されるユーザー・アカウントの完全なリストは、ALL_USERSデータ・ディクショナリ・ビューのUSERNAME列とORACLE_MAINTAINED列を問い合せることで見つかります。ORACLE_MAINTAINEDの出力がYの場合、そのユーザー・アカウントは、アカウントの作成に使用したスクリプトを実行するという方法以外で変更しないでください。

オープン、ロック、または期限切れなど、アカウントのステータスを確認するには、DBA_USERSデータ・ディクショナリ・ビューのACCOUNT_STATUS列を問い合せます。アカウントがスキーマ限定の場合、ステータスはNONEです。

表2-1 事前定義されたOracle Databaseの管理ユーザー・アカウント

ユーザー・アカウント 説明

ANONYMOUS

Oracle XML DBにHTTPアクセス可能なアカウント。EPG (Embedded PL/SQL Gateway)をデータベースにインストールするときにAPEX_PUBLIC_USERアカウントのかわりに使用されます。

EPGはOracle Databaseとともに使用されるWebサーバーです。動的アプリケーションの作成に必要なインフラストラクチャを提供します。

APPQOSSYS

Oracle Quality of Service Managementで必要なすべてのデータおよびメタデータの格納および管理に使用されます。

AUDSYS

統合監査機能によって統合監査証跡レコードの格納に使用される内部アカウント。

監査レコードが作成されるときと場所を参照してください。

CTXSYS

Oracle Textを管理するためのアカウント。Oracle Textを使用すると、テキスト問合せアプリケーションおよびドキュメント分類アプリケーションを作成できます。Oracle Textは、テキスト用の索引付け、語とテーマの検索および表示機能を提供します。

Oracle Textアプリケーション開発者ガイドを参照してください。

DBSNMP

Oracle Enterprise Managerの管理エージェント・コンポーネントによりデータベースの監視および管理に使用されるアカウント。

『Enterprise Manager Cloud Control管理者ガイド』を参照してください。

DBSFWUSER

DBMS_SFW_ACL_ADMINパッケージの実行に使用されるアカウント。

『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

DVF

Oracle Database Vaultが所有するアカウントで、Database Vaultのファクタ値を取得するためのパブリック・ファンクションが含まれます。

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

DVSYS

DV_OWNER(管理構成用)ロールとDV_ACCTMGRロール(アカウント管理用)に関連付けられているOracle Database Vaultアカウント。

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

GGSYS

Oracle GoldenGateが使用する内部アカウント。ロック解除したり、データベース・ログインに使用したりしないでください。

『Oracle Database Global Data Services概念および管理ガイド』を参照してください

GSMADMIN_INTERNAL

Global Data Servicesスキーマを所有する内部アカウント。ロック解除したり、データベース・ログインに使用したりしないでください。

『Oracle Database Global Data Services概念および管理ガイド』を参照してください

GSMCATUSER

グローバル・サービス・マネージャがGlobal Data Servicesカタログへの接続に使用するアカウント。

『Oracle Database Global Data Services概念および管理ガイド』を参照してください

GSMROOTUSER

シャーディング構成内のCDBのCDB$ROOTにログインするために使用されるアカウント。このユーザーはGDS構成では使用されません。CDB内のCDB$ROOTへのすべての接続で、GSMROOTUSERが使用されます。

GSMUSER

グローバル・サービス・マネージャがデータベースへの接続に使用するアカウント。

『Oracle Database Global Data Services概念および管理ガイド』を参照してください

LBACSYS

Oracle Label Security (OLS)を管理するためのアカウント。Label Securityオプションをインストールするときのみ作成されます。

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

MDSYS

Oracle SpatialおよびOracle Multimedia Locatorの管理者アカウント。

『Oracle Spatial and Graph開発者ガイド』を参照してください。

OJVMSYS

Oracle JVMサポートによるJava Naming and Directory Interface (JNDI)のサポートで使用されるアカウント。このアカウントは、JVMオブジェクトに関する詳細(ネームスペース・メタデータ、バインドされた名前、属性、権限およびストアド・オブジェクト表現)を格納するデータベース表を所有します。

『Oracle Database Java開発者ガイド』を参照してください。

OLAPSYS

OLAPカタログ(CWMLite)を所有するアカウント。このアカウントは、非推奨となりましたが、下位互換性のために保持されています。

ORDDATA

このアカウントには、Oracle Multimedia DICOMデータ・モデルが含まれます。詳細は、『Oracle Multimedia DICOM開発者ガイド』を参照してください。

ORDPLUGINS

Oracle Multimediaユーザー。Oracleおよびサード・パーティにより提供されたプラグイン(フォーマット・プラグイン)はこのスキーマにインストールされています。

Oracle MultimediaによりOracle Databaseで画像、音声、動画、DICOMフォーマットの医療用画像などのオブジェクトや、その他の企業情報と統合された異機種間のメディア・データを格納、管理および取得できます。

『Oracle Multimediaユーザーズ・ガイド』 を参照してください。

ORDSYS

Oracle Multimedia管理者アカウント。

『Oracle Multimediaユーザーズ・ガイド』 を参照してください。

OUTLN

プラン・スタビリティをサポートするアカウント。プラン・スタビリティは、同じSQL文の同じ実行計画の保守を可能にします。OUTLNは、ストアド・アウトラインに関連付けられたメタデータを集中管理するロールを実行します。

REMOTE_SCHEDULER_AGENT

データベースのリモート・ジョブを無効化するアカウント。このアカウントはリモート・スケジューラ・エージェントの構成時に作成されます。データベースでリモート・ジョブを実行する機能は、このユーザーを削除することで、無効(使用禁止)にできます。

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

SI_INFORMTN_SCHEMA

SQL/MM Still Image Standardの情報ビューを格納するアカウント。

『Oracle Multimediaユーザーズ・ガイド』 を参照してください。

ノート: SI_INFORMTN_SCHEMAアカウントは、Oracle Database 12cリリース2 (12.2)では非推奨です。

SYS

データベース管理タスクの実行に使用されるアカウント。

Oracle Database 2日でデータベース管理者を参照してください。

SYS$UMF

リモートの自動ワークロード・リポジトリ(AWR)などのリモート管理フレームワークの管理に使用されるアカウント。

『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

SYSBACKUP

Oracle Recovery Managerのリカバリとバックアップの実行に使用されるアカウント。

『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

SYSDG

Oracle Data Guardの操作の実行に使用されるアカウント。

Oracle Data Guard概要および管理を参照してください。

SYSKM

透過的データ暗号化の管理に使用される内部アカウント。

『Oracle Database Advanced Securityガイド』を参照してください。

SYSRAC

Oracle Real Application Clustersの管理に使用するアカウント。

詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。

SYSTEM

Oracle Databaseのデフォルトの汎用データベース管理者アカウント。

本番システムでは、データベース管理操作用に汎用SYSTEMアカウントを使用せずに、個々のデータベース管理者アカウントを作成することをお薦めします。

Oracle Database 2日でデータベース管理者を参照してください。

WMSYS

Oracle Workspace Manager用のメタデータ情報の格納に使用されるアカウント。

Oracle Database Workspace Manager開発者ガイドを参照してください。

XDB

Oracle XML DBのデータおよびメタデータの格納に使用されるアカウント。セキュリティを高めるには、XDBユーザー・アカウントのロックを解除しないでください。

Oracle XML DBはOracle Databaseのデータに対し、パフォーマンスの高いXMLの格納および取得を提供します。

Oracle XML DB開発者ガイドを参照してください。

ノート:

Oracle自動ストレージ管理(Oracle ASM)インスタンスを作成すると、ASMSNMPアカウントが作成されます。Oracle Enterprise Managerはこのアカウントを使用して、ASMインスタンスを監視し、ASM関連のデータ・ディクショナリ・ビューからデータを取得します。ASMSNMPアカウントのステータスはアカウントの作成時にOPENに設定され、SYSDBA管理権限が付与されます。

親トピック: Oracle Databaseで提供される事前定義済のスキーマ・ユーザー・アカウント

2.6.3 事前定義された非管理ユーザー・アカウント

デフォルトのOracle Databaseインストールでは、Oracle Spatialなどの機能を管理するための非管理ユーザー・アカウントが提供されます。

表2-2に、事前定義済の非管理ユーザー・アカウントを示します。このアカウントは、標準スクリプト(各種のcat*.sqlスクリプトなど)の実行時に、Oracleデータベースによって自動的に作成されます。Oracleによって作成および維持されるユーザー・アカウントの完全なリストは、ALL_USERSデータ・ディクショナリ・ビューのUSERNAME列とORACLE_MAINTAINED列を問い合せることで見つかります。ORACLE_MAINTAINEDの出力がYの場合、そのユーザー・アカウントは、アカウントの作成に使用したスクリプトを実行するという方法以外で変更しないでください。

非管理ユーザー・アカウントはジョブの実行に最低限必要な権限のみ所有します。デフォルトの表領域はUSERSです。マルチテナント環境では、事前定義された非管理アカウントはルート・データベースに存在します

これらのアカウントを無許可アクセスから保護するため、インストール・プロセスにより、次の表に示されたアカウントを除くほとんどのアカウントがインストール後すぐにロックされ、期限切れになります。データベース管理者には、これらのアカウントのロック解除とリセットを行う責任があります。

オープン、ロック、または期限切れなど、アカウントのステータスを確認するには、DBA_USERSデータ・ディクショナリ・ビューのACCOUNT_STATUS列を問い合せます。アカウントがスキーマ限定の場合、ステータスはNONEです。

表2-2 事前定義済のOracle Databaseの非管理ユーザー・アカウント

ユーザー・アカウント 説明

DIP

Oracle Label SecurityとともにインストールされるOracle Directory Integration and Provisioning(DIP)のアカウント。このプロファイルは、Oracle Internet Directory対応Oracle Label Securityのインストール・プロセスの一部として自動的に作成されます。

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

MDDATA

格納されるジオコーダおよびルーターのデータ用にOracle Spatialに使用されるスキーマ。

Oracle SpatialはSQLスキーマおよびファンクションを提供し、これによりOracle DatabaseのSpatial機能の格納、取得、更新、問合せができます。

『Oracle Spatial and Graph開発者ガイド』を参照してください。

ORACLE_OCM

Oracle Configuration Managerと使用するアカウント。この機能により現在のOracle Databaseインスタンスの構成情報をMy Oracle Supportと関連付けることができます。サービス・リクエストを記録すると、データベース・インスタンスの構成情報と関連付けられます。

使用しているプラットフォームの『Oracle Databaseインストレーション・ガイド』を参照してください。

XS$NULL

セッションにデータベース・ユーザーが存在せず、実際のセッション・ユーザーは、Oracle Real Application Securityでサポートされるアプリケーション・ユーザーであることを示す内部アカウント。XS$NULLには権限はなく、データベース・オブジェクトを所有しません。XS$NULLとして認証されることはなく、認証資格証明にXS$NULLが割り当てられることもありません。

親トピック: Oracle Databaseで提供される事前定義済のスキーマ・ユーザー・アカウント

2.6.4 事前定義されたサンプル・スキーマ・ユーザー・アカウント

Oracle Databaseでは、サンプル・スキーマをインストールした場合にサンプル・ユーザー・アカウントのセットが作成されます。

サンプル・スキーマ・ユーザー・アカウントはすべて非管理アカウントで、表領域は USERS です。

これらのアカウントを無許可アクセスから保護するため、インストール・プロセスによりこれらのアカウントがインストール直後にロックされ、期限切れになります。データベース管理者には、これらのアカウントのロック解除とリセットを行う責任があります。

表2-3には、様々な製品を製造している架空の企業の個別の部門を表すサンプル・スキーマ・ユーザー・アカウントがリストされています。これらのアカウントのステータスは、DBA_USERSデータ・ディクショナリ・ビューを問い合せることで確認できます。これらのアカウントに対するORACLE_MAINTAINED列の出力はNになるため、これらのアカウントの作成に使用したスクリプトを再実行することなくアカウントの変更が可能です。

オープン、ロック、または期限切れなど、アカウントのステータスを確認するには、DBA_USERSデータ・ディクショナリ・ビューのACCOUNT_STATUS列を問い合せます。アカウントがスキーマ限定の場合、ステータスはNONEです。

表2-3 デフォルトのサンプル・スキーマ・ユーザー・アカウント

ユーザー・アカウント 説明

HR

HR(Human Resources)スキーマを管理するためのアカウント。このスキーマには企業の従業員および施設に関する情報が格納されます。

OE

OE(Order Entry)スキーマを管理するためのアカウント。このスキーマには製品のインベントリや、様々なチャネルによる製品の売上が格納されます。

PM

PM(Product Media)スキーマを管理するためのアカウント。このスキーマには企業が販売した各製品の説明と詳細情報が含まれます。

IX

IX(Information Exchange)スキーマを管理するためのアカウント。このスキーマによりB2B(Business-to-Business)アプリケーションを介した発送が管理されます。

SH

SH(Sales)スキーマを管理するためのアカウント。このスキーマにはビジネス上の決断を容易にするビジネス戦略が格納されます。

例にあるスキーマ・アカウントに加えて、Oracle Databaseでは他のスキーマ・アカウントであるSCOTTの例も用意しています。SCOTTスキーマには、表EMP、DEPT、SALGRADEおよびBONUSが含まれています。SCOTTアカウントはOracle Databaseのドキュメント・セット全体の例で使用されます。Oracle Databaseをインストールすると、SCOTTアカウントはロックされ、期限が切れます。

関連トピック

親トピック: Oracle Databaseで提供される事前定義済のスキーマ・ユーザー・アカウント

2.7 データベース・ユーザーおよびプロファイルのデータ・ディクショナリ・ビュー

Oracle Databaseには、ユーザーとプロファイルの作成に使用した設定の情報を提供する、一連のデータ・ディクショナリ・ビューがあります。

親トピック: Oracle Databaseユーザーのセキュリティの管理

2.7.1 ユーザーとプロファイルに関する情報を表示するデータ・ディクショナリ・ビュー

Oracle Databaseには、データベース・ユーザーおよびプロファイルに関する情報を含むデータ・ディクショナリ・ビュー一式が用意されています。

表2-4に、これらのデータ・ディクショナリ・ビューを示します。

表2-4 ユーザーとプロファイルに関する情報を表示するデータ・ディクショナリ・ビュー

ビュー 説明

ALL_OBJECTS

現行ユーザーがアクセス可能なすべてのオブジェクトが表示されます。

ALL_USERS

現行ユーザーに対して表示可能なユーザーがリストされますが、それらの記述は表示されません。

DBA_PROFILES

すべてのプロファイルとそれぞれの制限が表示されます。

DBA_TS_QUOTAS

ユーザーの表領域割当て制限が表示されます。

DBA_OBJECTS

データベース内のすべてのオブジェクトが表示されます。

DBA_USERS

データベースのすべてのユーザーの記述が表示されます。

DBA_USERS_WITH_DEFPWD

デフォルト・パスワードが設定されているすべてのユーザー・アカウントがリストされます。

PROXY_USERS

他のユーザーの識別情報を引き継ぐことができるユーザーの記述が表示されます。

RESOURCE_COST

セッション当たりのCPU、セッション当たりの読取り、接続時間およびSGAの観点から各リソースのコストがリストされます。

USER_PASSWORD_LIMITS

ユーザーに割り当てられているパスワード・プロファイル・パラメータが表示されます。

USER_RESOURCE_LIMITS

現行ユーザーのリソース制限が表示されます。

USER_TS_QUOTAS

ユーザーの表領域割当て制限が表示されます。

USER_OBJECTS

現行ユーザーが所有するすべてのオブジェクトが表示されます。

USER_USERS

現行ユーザーの記述のみが表示されます。

V$SESSION

現在のデータベース・セッションのセッション情報がリストされます。

V$SESSTAT

ユーザー・セッションの統計が表示されます。

V$STATNAME

V$SESSTATビューに表示される統計のデコードされた統計名が表示されます。

次の各項では、これらのビューの使用例を示します。各例では、次の文がすでに実行されていることを前提としています。ユーザーはすべてローカル・ユーザーです。

CREATE PROFILE clerk LIMIT
 SESSIONS_PER_USER 1
 IDLE_TIME 30
 CONNECT_TIME 600;

CREATE USER jfee
 IDENTIFIED BY password
 DEFAULT TABLESPACE example
 TEMPORARY TABLESPACE temp
 QUOTA 500K ON example
 PROFILE clerk
 CONTAINER = CURRENT;

CREATE USER dcranney
 IDENTIFIED BY password
 DEFAULT TABLESPACE example
 TEMPORARY TABLESPACE temp
 QUOTA unlimited ON example
 CONTAINER = CURRENT;

CREATE USER userscott
 IDENTIFIED BY password
 CONTAINER = CURRENT;

関連トピック

親トピック: データベース・ユーザーおよびプロファイルのデータ・ディクショナリ・ビュー

2.7.2 すべてのユーザーと関連情報を検索する問合せ

DBA_USERSデータ・ディクショナリ・ビューには、データベースで定義されているすべてのユーザーとその関連情報が表示されます。

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

たとえば:

col username format a11
col profile format a10
col account_status format a19
col authentication_type format a29

SELECT USERNAME, PROFILE, ACCOUNT_STATUS, AUTHENTICATION_TYPE FROM DBA_USERS;
 
USERNAME        PROFILE         ACCOUNT_STATUS   AUTHENTICATION_TYPE
--------------- --------------- ---------------  -------------------
SYS             DEFAULT         OPEN             PASSWORD
SYSTEM          DEFAULT         OPEN             PASSWORD
USERSCOTT       DEFAULT         OPEN             PASSWORD
JFEE            CLERK           OPEN             GLOBAL
DCRANNEY        DEFAULT         OPEN             EXTERNAL

親トピック: データベース・ユーザーおよびプロファイルのデータ・ディクショナリ・ビュー

2.7.3 すべての表領域の割当て制限を表示する問合せ

DBA_TS_QUOTASデータ・ディクショナリ・ビューには、各ユーザーに割り当てられているすべての表領域割当てが表示されます。

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

たとえば: 

SELECT * FROM DBA_TS_QUOTAS;

TABLESPACE    USERNAME    BYTES     MAX_BYTES    BLOCKS    MAX_BLOCKS
----------    ---------  --------   ----------   -------   ----------
EXAMPLE       JFEE              0       512000         0          250
EXAMPLE       DCRANNEY          0           -1         0           -1

固有の割当て制限が割り当てられている場合は、正確な数値がMAX_BYTES列に示されます。この数値は常にデータベース・ブロック・サイズの倍数となるため、倍数でない表領域割当て制限を指定すると、適切な値に切り上げられます。無制限割当ての場合は、-1が表示されます。

親トピック: データベース・ユーザーおよびプロファイルのデータ・ディクショナリ・ビュー

2.7.4 すべてのプロファイルと割り当てられている制限を表示する問合せ

DBA_PROFILEビューには、データベース内のすべてのプロファイル、および各プロファイルの制限ごとの関連設定がリストされます。

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

たとえば:

SELECT * FROM DBA_PROFILES
   ORDER BY PROFILE;

PROFILE             RESOURCE_NAME              RESOURCE_TYPE   LIMIT 
-----------------   -----------------------    -------------  --------------
CLERK               COMPOSITE_LIMIT            KERNEL         DEFAULT
CLERK               FAILED_LOGIN_ATTEMPTS      PASSWORD       DEFAULT
CLERK               PASSWORD_LIFE_TIME         PASSWORD       DEFAULT
CLERK               PASSWORD_REUSE_TIME        PASSWORD       DEFAULT
CLERK               PASSWORD_REUSE_MAX         PASSWORD       DEFAULT
CLERK               PASSWORD_VERIFY_FUNCTION   PASSWORD       DEFAULT
CLERK               PASSWORD_LOCK_TIME         PASSWORD       DEFAULT
CLERK               PASSWORD_GRACE_TIME        PASSWORD       DEFAULT
CLERK               PRIVATE_SGA                KERNEL         DEFAULT
CLERK               CONNECT_TIME               KERNEL         600    
CLERK               IDLE_TIME                  KERNEL         30     
CLERK               LOGICAL_READS_PER_CALL     KERNEL         DEFAULT
CLERK               LOGICAL_READS_PER_SESSION  KERNEL         DEFAULT
CLERK               CPU_PER_CALL               KERNEL         DEFAULT
CLERK               CPU_PER_SESSION            KERNEL         DEFAULT
CLERK               SESSIONS_PER_USER          KERNEL         1      
DEFAULT             COMPOSITE_LIMIT            KERNEL         UNLIMITED
DEFAULT             PRIVATE_SGA                KERNEL         UNLIMITED
DEFAULT             SESSIONS_PER_USER          KERNEL         UNLIMITED
DEFAULT             CPU_PER_CALL               KERNEL         UNLIMITED
DEFAULT             LOGICAL_READS_PER_CALL     KERNEL         UNLIMITED
DEFAULT             CONNECT_TIME               KERNEL         UNLIMITED
DEFAULT             IDLE_TIME                  KERNEL         UNLIMITED
DEFAULT             LOGICAL_READS_PER_SESSION  KERNEL         UNLIMITED
DEFAULT             CPU_PER_SESSION            KERNEL         UNLIMITED
DEFAULT             FAILED_LOGIN_ATTEMPTS      PASSWORD       10
DEFAULT             PASSWORD_LIFE_TIME         PASSWORD       180
DEFAULT             PASSWORD_REUSE_MAX         PASSWORD       UNLIMITED
DEFAULT             PASSWORD_LOCK_TIME         PASSWORD       1
DEFAULT             PASSWORD_GRACE_TIME        PASSWORD       7
DEFAULT             PASSWORD_VERIFY_FUNCTION   PASSWORD       UNLIMITED
DEFAULT             PASSWORD_REUSE_TIME        PASSWORD       UNLIMITED
32 rows selected.

デフォルト・プロファイル値を検索するには、次の問合せを実行します。 

SELECT * FROM DBA_PROFILES WHERE PROFILE = 'DEFAULT';

PROFILE             RESOURCE_NAME              RESOURCE_TYPE  LIMIT  
-----------------   -------------------------  -------------  --------------
DEFAULT             COMPOSITE_LIMIT            KERNEL         UNLIMITED
DEFAULT             SESSIONS_PER_USER          KERNEL         UNLIMITED
DEFAULT             CPU_PER_SESSION            KERNEL         UNLIMITED
DEFAULT             CPU_PER_CALL               KERNEL         UNLIMITED
DEFAULT             LOGICAL_READS_PER_SESSION  KERNEL         UNLIMITED
DEFAULT             LOGICAL_READS_PER_CALL     KERNEL         UNLIMITED
DEFAULT             IDLE_TIME                  KERNEL         UNLIMITED
DEFAULT             CONNECT_TIME               KERNEL         UNLIMITED
DEFAULT             PRIVATE_SGA                KERNEL         UNLIMITED
DEFAULT             FAILED_LOGIN_ATTEMPTS      PASSWORD       10
DEFAULT             PASSWORD_LIFE_TIME         PASSWORD       180
DEFAULT             PASSWORD_REUSE_TIME        PASSWORD       UNLIMITED
DEFAULT             PASSWORD_REUSE_MAX         PASSWORD       UNLIMITED
DEFAULT             PASSWORD_VERIFY_FUNCTION   PASSWORD       NULL
DEFAULT             PASSWORD_LOCK_TIME         PASSWORD       1
DEFAULT             PASSWORD_GRACE_TIME        PASSWORD       7

16 rows selected.

親トピック: データベース・ユーザーおよびプロファイルのデータ・ディクショナリ・ビュー

2.7.5 各ユーザー・セッションのメモリー使用量を表示する問合せ

V$SESSION動的ビューには、各ユーザー・セッションのメモリー使用量が表示されます。

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

次の問合せを実行するとすべてのカレント・セッションがリストされ、各セッションのOracle Databaseユーザーと現在のユーザー・グローバル領域(UGA)メモリー使用が示されます。

SELECT USERNAME, VALUE || 'bytes' "Current UGA memory"
   FROM V$SESSION sess, V$SESSTAT stat, V$STATNAME name
WHERE sess.SID = stat.SID
   AND stat.STATISTIC# = name.STATISTIC#
   AND name.NAME = 'session uga memory';

USERNAME                       Current UGA memory
------------------------------ ---------------------------------------------
                               18636bytes
                               17464bytes
                               19180bytes
                               18364bytes
                               39384bytes
                               35292bytes
                               17696bytes
                               15868bytes
USERSCOTT                      42244bytes
SYS                            98196bytes
SYSTEM                         30648bytes

11 rows selected.

インスタンスの起動以降、各セッションに割り当てられた最大のUGAメモリーを表示するには、この問合せの'session uga memory'を'session uga memory max'に置き換えてください。

親トピック: データベース・ユーザーおよびプロファイルのデータ・ディクショナリ・ビュー