1. Database SecureFilesおよびラージ・オブジェクト開発者ガイド
  2. データベース・ファイルシステム(DBFS)
  3. DBFS SecureFilesストア

21 DBFS SecureFilesストア

DBFS SecureFilesストアを設定および使用するための特定の手順があります。

内容は次のとおりです。

21.1 SecureFilesストアの設定

SecureFilesストアの設定にはいくつかの側面があります。

この項では、SecureFilesストアの設定方法について説明します。

内容は次のとおりです。

21.1.1 権限の管理について

操作のためのコンテンツAPIおよびストアへのアクセスでは、標準のデータベース・ユーザーを使用する必要があります。

SYSまたはSYSTEMユーザーやSYSDBAまたはSYSOPERシステム権限は使用しないでください。セキュリティおよび義務の分離を強化するために、DBFSコンテンツAPIの操作を管理する機能の使用を許可するのは、信頼できる特定のユーザーに対してのみにしてください。

各ユーザーにDBFS_ROLEロールを付与する必要があります。そうでない場合、DBFSコンテンツAPIを使用する権限がユーザーに付与されません。適切な管理権限(SYSDBA)を持つユーザーが、必要に応じて追加のユーザーにロールを付与できます。

データベースでのロール、アクセス制御および定義者/実行者権限の相互作用に応じて、DBFSコンテンツAPIタイプ(DBMS_DBFS_CONTENT_ xxx接頭辞を持つSQLタイプ)およびパッケージ(通常はDBMS_DBFS_CONTENTおよびDBMS_DBFS_SFSのみ)の各種の権限(通常は実行権限)を、本来DBFS_ROLEロールを持つユーザーに明示的に付与することが必要な場合があります。

これらの明示的および直接的な付与は、一般的な必要とされる処理であり、必要またはリクエストに応じて行われます。

21.1.2 権限の作成または設定

DBFSコンテンツAPIを使用する必要があるユーザーには、DBFS_ROLEロールを付与する必要があります。

  1. DBFSコンテンツAPIターゲット・ユーザーを作成または決定します。

    この例では、ユーザーとパスワードとしてsfs_demo/passwordを使用します

    このデータベース・ユーザーは、少なくともCREATE SESSION、CREATE RESOURCEおよびCREATE VIEW権限を持つ必要があります。

  2. DBFS_ROLEロールをこのユーザーに付与します。
    CONNECT / as sysdba
GRANT dbfs_role TO sfs_demo;

これにより、DBFS_ROLEロールを持つデータベース・ユーザー用にDBFSコンテンツAPIが設定されます。

21.1.3 SecureFilesファイルシステム・ストアの作成

DBFSコンテンツAPIがアクセスするSecureFilesファイルシステム・ストアを作成する必要があります。

CREATEFILESYSTEMプロシージャは、実行の前後に自動コミットします(DDLに類似)。メソッドCREATESTOREはCREATEFILESYSTEMのラッパーです。

関連項目:

DBMS_DBFS_SFS構文の詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください

SecureFilesファイルシステム・ストアを作成するには:

  1. DBFSコンテンツAPIを使用してアクセスが必要なストアを作成します。
    DECLARE
  BEGIN
    DBMS_DBFS_SFS.CREATEFILESYSTEM(
      store_name => 'FS1',
      tbl_name => 'T1',
      tbl_tbs => null,
      use_bf => false 
    );
    COMMIT;
  END;
/

    説明:

    • store_nameは、任意のユーザー固有の名前です。

    • tbl_nameは、現在のスキーマで作成された有効な表名です。

    • tbl_tbsは、索引、LOBまたはネストした表などのストア表および依存セグメントに使用される有効な表領域の名前です。デフォルトはNULLで、現在のスキーマの表領域を指定します。

    • use_bfは、trueであればBasicFiles LOBの使用を指定し、falseであれば使用しないことを指定します。

  2. このストアを、SecureFilesストアで管理される新規ストアとしてDBFSコンテンツAPIに登録します。 
    CONNECT sfs_demo
Enter password:password
DECLARE
  BEGIN
    DBMS_DBFS_CONTENT.REGISTERSTORE(
      store_name    => 'FS1',
      provider_name => 'anything',
      provider_package => 'dbms_dbfs_sfs'
    );
    COMMIT;
  END;
/

    説明:

    • store_nameは、表SFS_DEMO.T1を使用するSecureFilesストアFS1です。

    • provider_nameは無視されます。

    • provider_packageはDBMS_DBFS_SFSで、SecureFilesストアの参照プロバイダ用です。

    この操作では、SecureFilesストアFS1とDBMS_DBFS_SFSプロバイダが関連付けられます。

  3. 適切なマウント・ポイントにストアをマウントします。
    CONNECT sfs_demo
Enter password: password
DECLARE
  BEGIN
    DBMS_DBFS_CONTENT.MOUNTSTORE(
      store_name    => 'FS1',
      store_mount   => 'mnt1'
    );
    COMMIT;
  END;
/

    説明:

  4. (オプション)前述のステップの結果を確認するには、次の文を使用します。

    • SecureFilesストア表およびファイルシステムを確認するには:

      SELECT * FROM TABLE(DBMS_DBFS_SFS.LISTTABLES);
SELECT * FROM TABLE(DBMS_DBFS_SFS.LISTFILESYSTEMS);

    • ContentAPIストアおよびマウントを確認するには:

      SELECT * FROM TABLE(DBMS_DBFS_CONTENT.LISTSTORES);
SELECT * FROM TABLE(DBMS_DBFS_CONTENT.LISTMOUNTS);

    • SecureFilesストア機能を確認するには:

      var fs1f number;
exec :fs1f := dbms_dbfs_content.getFeaturesByName('FS1');
select * from table(dbms_dbfs_content.decodeFeatures(:fs1f));

    • リソースおよびプロパティ・ビューを確認するには:

      SELECT * FROM DBFS_CONTENT;
SELECT * FROM DBFS_CONTENT_PROPERTIES;

21.1.4 SecureFilesシステム・ストア・データを保持する表へのアクセス

DBMS_DBFS_SFSパッケージ・メソッドを使用する場合でも、SecureFilesストア・ファイルシステムのデータを保持する表には直接アクセスしないでください。

ファイルシステムにアクセスする正しい方法は、次のとおりです。

  • 手順を実行する場合: DBFSコンテンツAPI (DBMS_DBFS_CONTENTメソッド)を使用します。

  • SQL操作の場合: リソースとプロパティのビュー(DBFS_CONTENTおよびDBFS_CONTENT_PROPERTIES)を使用します。

21.1.5 SecureFilesストア・ファイルシステムの初期化

SecureFilesストアに関連付けられた表を切り捨てたり再初期化することができます。

  • プロシージャINITFS()を使用します。

    プロシージャの実行は、DDLに類似しています(実行の前後に自動コミット)。

次の例では、SecureFilesストアstore_nameに関連付けられたファイルシステムFS1および表SFS_DEMO.T1を使用しています。 

CONNECT sfs_demo;
Enter password: password
EXEC DBMS_DBFS_SFS.INITFS(store_name => 'FS1');

21.1.6 SecureFiles LOBとBasicFiles LOBの比較

SecureFiles LOBは、Oracle Database 11gリリース1以上でのみ使用できます。それより前のリリースでは使用できません。

自動セグメント領域管理(ASSM)で管理されていない表領域のLOB記憶域には、BasicFiles LOB記憶域を使用する必要があります。

SecureFiles LOBを使用するには、11.1.0.0以上の互換性が必要です。

また、DBMS_DBFS_SFS.CREATEFILESYSTEMで次の情報を指定する必要があります。

  • SecureFiles LOB (デフォルト)を使用するには、use_bf => falseを指定します。

  • BasicFiles LOBを使用するには、use_bf => trueを指定します。

21.2 DBFS SecureFilesストア・ファイルシステムの使用

DBFSコンテンツAPIには、SecureFilesストア・ファイルシステムに移入したり、あるいはファイルシステムを管理するためのメソッドが用意されています。

内容は次のとおりです。

21.2.1 DBFSコンテンツAPIの操作の例

SecureFilesストア・ファイルシステムに移入するための新しいファイルおよびディレクトリ要素を作成できます。

「SecureFilesストアの設定」のステップを実行して、DBFSコンテンツAPI権限を設定し、少なくとも1つのSecureFilesストア参照ファイルシステムを作成し、マウント・ポイント/mnt1の下にマウントした場合、例21-1のようにして新しいファイルおよびディレクトリ要素を作成できます。

例21-1 DBFSコンテンツAPIの操作

CONNECT tjones
Enter password: password
 
DECLARE
   ret integer;
   b   blob;
   str varchar2(1000)  := '' || chr(10) ||
 
'#include <stdio.h>' || chr(10) ||
'' || chr(10) ||
'int main(int argc, char** argv)' || chr(10) ||
'{' || chr(10) ||
'    (void) printf("hello world\n");' || chr(10) ||
'    RETURN 0;' || chr(10) ||
'}' || chr(10) ||
'';
 
    BEGIN
        ret := dbms_fuse.fs_mkdir('/mnt1/FS1');
        ret := dbms_fuse.fs_creat('/mnt1/FS1/hello.c', content => b);
        dbms_lob.writeappend(b, length(str), utl_raw.cast_to_raw(str));
        COMMIT;
    END;
    /
    SHOW ERRORS;
 
    -- verify newly created directory and file
    SELECT pathname, pathtype, length(filedata),
        utl_raw.cast_to_varchar2(filedata)
        FROM dbfs_content
            WHERE pathname LIKE '/mnt1/FS1%'
            ORDER BY pathname;

ファイルシステムは、DBMS_DBFS_CONTENTを使用してPL/SQLから移入およびアクセスできます。ファイルシステムは、dbfs_contentおよびdbfs_content_propertiesビューを使用してSQLから読取り専用でアクセスできます。

また、ファイルシステムは、FUSEを使用してマウントされているときは通常のファイルシステムAPIおよびUNIXユーティリティで、またはスタンドアロンのdbfs_clientツール(FUSEが使用不可または設定されていない環境)によって、移入およびアクセスできます。

21.2.2 SecureFilesストア・ファイルシステムの削除

unmountStoreメソッドを使用して、SecureFilesストア・ファイルシステムを削除できます。

このメソッドにより、ファイルシステムを参照するすべてのストアがメタデータ表から削除され、基礎となるファイルシステム表が削除されます。プロシージャの実行は、DDLに類似しています(実行の前後に自動コミット)。

  1. ストアをアンマウントします。
    CONNECT sfs_demo
Enter password: password
DECLARE
  BEGIN
    DBMS_DBFS_CONTENT.UNMOUNTSTORE(
      store_name    => 'FS1',
      store_mount   => 'mntl';
    );
    COMMIT;
END;
/

    説明:

    • store_nameは、表SFS_DEMO.T1を使用するSecureFilesストアFS1です。

    • store_mountはマウント・ポイントです。

  2. ストアを登録解除します。
    CONNECT sfs_demo
Enter password: password
EXEC DBMS_DBFS_CONTENT.UNREGISTERSTORE(store_name => 'FS1');
COMMIT;

    store_nameは、表SFS_DEMO.T1を使用するSecureFilesストアFS1です。

  3. ファイルシステムを削除します。
    CONNECT sfs_demo/******;
EXEC DBMS_DBFS_SFS.DROPFILESYSTEM(store_name => 'FS1');
COMMIT;

    store_nameは、表SFS_DEMO.T1を使用するSecureFilesストアFS1です。

21.3 DBFS SecureFilesストア・パッケージDBMS_DBFS_SFSについて

DBFS SecureFilesストア・パッケージ(DBMS_DBFS_SFS)は、DBMSコンテンツのSecureFiles LOB記憶域をサポートするDBMS_DBFS_CONTENTのストア・プロバイダです。

DBMS_DBFS_SFSパッケージを使用するには、DBFS_ROLEロールが付与されている必要があります。

SecureFilesストア・プロバイダは、DBFSコンテンツAPIのデフォルトの実装(また、プロバイダSPIに準拠するストア・プロバイダの標準的な例)であり、スキーマ内の列としてLOBをすでに使用しているアプリケーションがBLOB列にアクセスできるようにするためのものです。これにより既存のアプリケーションは容易にPL/SQLプロバイダ実装を追加して、スキーマやビジネス・ロジックを変更することなくDBFSコンテンツAPIを通じてアクセスできます。

さらに、標準DBFSコンテンツAPIインタフェースを介して、別の(サード・パーティの)ストアに格納されたコンテンツをアプリケーションで読取りおよび書込みできます。

SecureFilesストアでは、基礎となるユーザー・データはSecureFiles LOBに格納され、パス名、IDおよびプロパティなどのメタデータはリレーショナル表内の列として格納されます。

関連項目:

21.4 データベース・ファイルシステム(DBFS)— POSIXファイル・ロック

Oracle Database 12c リリース2 (12.2)より、データベース・ファイルシステムPOSIXのファイル・ロック機能がサポートされます。DBFSでは、ファイル・ロックのサポートを次に対して提供します。

  • DBFSに対するフロントエンド・インタフェースとしてDBFS_CLIENTを(マウント・モードで)使用するPOSIXアプリケーション。

  • DBFSに対するインタフェースとしてPL/SQLを使用するアプリケーション。

ノート:

Oracleは、DBFSの完全なファイル・ロックのみサポートします。完全ファイル・ロックは、バイト・ゼロのオフセットからファイルの終わりまでファイル全体をロックすることを意味します。

内容は次のとおりです。

21.4.1 アドバイザ・ロックについて

アドバイザ・ロックは、1つのプロセスのファイルをロックするファイル・ロック・メカニズムです。

ファイル・ロック・メカニズムでは、どの形式のロックも個別に強制できず、関連プロセスからのサポートが必要になります。たとえば、プロセスP1でファイルF1に対するwriteロックが設定されている場合、ロックAPIまたはオペレーティング・システムによって、他のプロセスP2によるファイルF1でのreadまたはwriteシステム・コールの実行を回避するためのアクションは一切実行されません。ファイル・ロック・メカニズムのこの動作は、他のファイルシステムの操作にも適用できます。(ファイル・ロック・メカニズムに)関連するプロセスは、ユーザー・レベルのライブラリにより適切なAPIフォームで提供されるロックまたはロック解除プロトコルに従う必要があります。ファイル・ロックのセマンティクスの機能は保証されていますが、プロセスにロック・プロトコルの推奨される使用方法が取り込まれ、APIコールの結果が重視されることが必要です。

21.4.2 必須ロックについて

必須ロックは、関連プロセスからサポートを取得するファイル・ロック・メカニズムです。

必須ロックは、ロックAPIを共同で使用している、または従っている関連のプロセスに依存しない強制的なロック・スキームです。たとえば、プロセスP1がファイルF1に対するwriteロックを取得し、別のプロセスP2がファイルF1に対してread/writeシステム・コール(あるいは他のファイルシステム操作)を実行しようとすると、該当のファイルはプロセスP1で排他的にロックされるため要求はブロックされます。

21.4.3 ファイル・ロックのサポート

ファイル・ロック・メカニズムを有効にすると、アプリケーションでファイルでの様々なファイルシステム操作をブロックできます。

UNIXおよびLINUXでのfcntl()、lockf()、およびflock()システム・コールによって、ファイル・ロックのサポートが提供されます。これらのシステム・コールにより、アプリケーションはdbfs_client-FUSEコールバック・インタフェースを通じてファイル・ロック機能を使用できます。fcntl()が提供するファイル・ロックはPOSIXファイル・ロックとして広く知られており、flock()で提供されるファイル・ロックはBSDファイル・ロックとして知られています。POSIXおよびBSDのファイル・ロックでは、セマンティクスと動作がそれぞれ異なります。fcntl()とflock()を通じて同じファイルに設定されるロックは相互に直行です。DBFSで設計および実装されているファイル・ロック機能のセマンティクスは、POSIXファイル・ロックと似ています。DBFSでは、flock()システム・コールを通じて設定されるファイル・ロックのセマンティクスは、POSIXファイル・ロック(fcntl()など)に似ており、BSDファイル・ロックとは異なります。lockf()は、ほとんどのUNIXシステムでfcntl()システム・コールを介してラッパーとして実装されるライブラリ・コールであり、POSIXファイル・ロックのセマンティクスを提供します。DBFSでは、fcntl()、flock()、およびlockf()システム・コールを通じて設定されるファイル・ロックは、POSIXファイル・ロックと同種の動作とセマンティクスを提供します。

ノート:

BSDファイル・ロックのセマンティクスはサポートされていません。

21.4.4 データベース・ファイルシステムの互換性と移行要因—ファイル・ロック

データベース・ファイルシステムのファイル・ロック機能は、RDBMSとのDBFSおよびSFSストア・プロバイダの互換性に影響しません。

DBFS_CLIENTはスタンドアロンのOCIクライアントで、OCIコールとDBMS_FUSE APIを使用します。

ノート:

この機能はOraSDK/RSFと互換します。

21.4.5 データベース・ファイルシステムの例—ファイル・ロック

次の例は、アドバイザ・ロックと、UNIXベースのシステムで使用できるロック機能を示しています。次の例では、2つの実行中のプロセス、プロセスAとプロセスBを使用します。

例21-2 ロックなし

プロセスAで次のファイルが開きます。

file_desc = open(“/path/to/file”, O_RDONLY); 
/* Reads data into bufffers */ 
read(fd, buf1, sizeof(buf)); 
read(fd, buf2, sizeof(buf));
close(file_desc);

OSスケジュールに従って、プロセスBはいつでも開始でき、ファイル・データの整合性に影響を与えるwriteシステム・コールを実行できます。

例21-3 アドバイザリ・ロックは使用されているがプロセスBはプロトコルに従っていない

プロセスAで次のファイルが開きます。

file_desc = open(“/path/to/file”, O_RDONLY); 
ret = AcquireLock(file_desc, RD_LOCK); 
if(ret) 
{ 
	read(fd, buf1, sizeof(buf)); 
	read(fd, buf2, sizeof(buf)); 
	ReleaseLock(file_desc); 
} 
close(file_desc);

OSスケジュールに従って、プロセスBはいつでも開始でき、プロセスAがすでにreadロックを保持していることを無視してwriteシステム・コールも実行できます。

プロセスBで次のファイルが開きます。

file_desc1 = open(“/path/to/file”, O_WRONLY); 
write(file_desc1, buf, sizeof(buf)); 
close(file_desc1);

前述のコードが実行されると、ファイルでデータの不整合が生じます。

例21-4 アドバイザリ・ロックの使用とプロトコルに従うプロセス

プロセスAで次のファイルが開きます。

file_desc = open(“/path/to/file”, O_RDONLY); 
ret = AcquireLock(file_desc, RD_LOCK); 
if(ret) 
{
	read(fd, buf1, sizeof(buf)); 
	read(fd, buf2, sizeof(buf)); 
	ReleaseLock(file_desc);
}
close(file_desc);

プロセスBで次のファイルが開きます。

file_desc1 = open(“/path/to/file”, O_WRONLY); 
ret = AcquireLock(file_desc1, WR_LOCK); 
/* The above call will take care of checking the existence of a lock */ 
if(ret) 
{ 
	write(file_desc1, buf, sizeof(buf)); 
	ReleaseLock(file_desc1); 
} close(file_desc1);

プロセスBはロックAPIに従います。このAPIによってプロセスはロックを取得せずにファイルにwriteを実行することはありません。

21.4.6 ファイル・ロックの動作

The DBFSファイル・ロック機能により、次の動作が行われます。

  • DBFSのファイル・ロックが冪等機能で実装されます。1つのプロセスで同じファイルに対して"N"回readまたはwriteロック・コールが実行された場合、1回目のコールのみ有効で、以降の"N-1"回のコールは冗長として処理され、No Operation (NOOP)が返されます。

  • ファイルは1回だけロック解除できます。1つのプロセスで同じファイルに対して"N"回unlockコールが実行された場合、1回目のコールのみ有効で、以降の"N-1"回のコールは冗長として処理され、NOOPが返されます。

  • readからwriteへのロック変換のみサポートされます。1つのプロセスPでファイルFにreadロックが設定されている場合(またPがreadロックを保持する唯一のプロセスである場合)、ファイルFでのPによるwriteロック要求によって、readロックはexclusive/writeロックに変換されます。

21.4.7 ファイル・ロックのスケジュール設定

DBFSファイル・ロック機能はロックのスケジュール設定をサポートします。この機能はDBFSクライアント側にのみ実装されます。ロック要求スケジュール設定は、クライアント・アプリケーションがそのfcntl()、lockf()、およびflock()コールでブロッキング・コール・セマンティクスを使用している場合に必要です。

次の2種類のスケジュール設定があります。

Oracleは、スケジュール動作の切り替えに関して次のコマンド・ライン・オプションを提供しています。

Mount -o lock_sched_option = lock_sched_option Value;

表21-1 lock_sched_option値の説明

値 説明
1 スケジュールのタイプをグリーディ・スケジュールに設定します。(デフォルト)
2 スケジュールのタイプをフェア・スケジュールに設定します。

ノート:

ロック要求のスケジュール設定は、DBFSクライアントのマウント単位でのみ機能します。たとえば、ロック要求は同じファイル・システムの複数のマウントでスケジュール設定されません。
21.4.7.1 グリーディ・スケジュール

このスケジュール手法では、ファイル・ロック要求は保証された順序に従いません。

ノート:

これは、DBFSクライアントで提供されるデフォルトのスケジュール・オプションです。

ファイルFがプロセスP1でreadロックされている場合、およびプロセスP2とP3がファイルFでのブロックwriteロック要求をサブミットする場合、プロセスP2とP3は(スピン・ロックの形式を使用して)ブロックされ、ロックを取得するまで順番に待機します。待機中、プロセスP4がファイルFでreadロック要求(ブロック・コールまたは非ブロック・コール)を送信すると、writeロックの取得を待機しているプロセスが2つ(P2とP3)ある場合でも、P4にreadロックが付与されます。P1とP4の両方がそれぞれのreadロックを解除すると、P2およびP3のいずれがロックを取得できます。ただし、プロセスP2とP3がロックを取得する順序は決定されません。プロセスP2が最初に要求しても、プロセスP3の要求がロック解除されてロックを取得し、プロセスP2はP3がロックを解除するまで待機する必要がある場合もあります。

21.4.7.2 フェア・スケジュール

このスケジュール設定手法は、ファイル単位でキューイング・メカニズムを使用して実装されます。たとえば、ファイルFがプロセスP1で読取りロックされ、プロセスP2とP3がファイルFでのブロック書込みロック要求を送信した場合、これら2つのプロセスは(スピン・ロックの形式を使用して)ブロックされ、ロックの取得を待機します。要求はDBFSクライアントで受信された順序でキューイングされます。プロセスP4がファイルFに対する読取りロック要求(ブロック・コールまたは非ブロック・コール)を送信すると、このプロセスに対して読取りロックが付与できる場合でもこの要求はキューイングされます。

DBFSクライアントによって、P1がその読取りロックを解放した後、ロック要求が受け付けられる順序はP2->P3 -> P4になります。

つまり、P2が最初にロックを取得します。P2がそのロックを解除した後に、P3がロックを取得し、その後は同様に続いていきます。