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
ロールを付与する必要があります。
これにより、DBFS_ROLE
ロールを持つデータベース・ユーザー用にDBFSコンテンツAPIが設定されます。
21.1.3 SecureFilesファイルシステム・ストアの作成
DBFSコンテンツAPIがアクセスするSecureFilesファイルシステム・ストアを作成する必要があります。
CREATEFILESYSTEM
プロシージャは、実行の前後に自動コミットします(DDLに類似)。メソッドCREATESTORE
はCREATEFILESYSTEM
のラッパーです。
関連項目:
DBMS_DBFS_SFS
構文の詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください
SecureFilesファイルシステム・ストアを作成するには:
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.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およびプロパティなどのメタデータはリレーショナル表内の列として格納されます。
関連項目:
-
DBMS_DBFS_SFS
パッケージの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください。 -
DBMS_DBFS_CONTENT_SPI
に定義されているプロバイダSPIの詳細は、「独自のDBFSストアの作成」およびOracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください。 -
SecureFiles LOBの拡張機能の詳細は、「SecureFiles LOB記憶域」を参照してください。
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
を使用します。
ノート:
この機能はOra
SDK/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
がロックを取得し、その後は同様に続いていきます。