8 DICOMの管理の概要

この章では、Oracle Multimedia DICOMデータ・モデル・リポジトリの管理に関連するタスクの概要を説明します。

注:

DICOMのOracle Multimediaサポートは、Oracle Database 12cリリース2 (12.2)では非推奨になりました。将来のリリースではサポートされなくなる可能性があります。できるだけ早く、非推奨となった機能の使用を停止することをお薦めします。

Oracle Multimedia DICOMデータ・モデル・リポジトリでは、ユーザーによる構成が可能な一連のXMLドキュメントが集中管理されており、これらのXMLドキュメントによって、Oracle Multimedia DICOMの実行時の動作が定義されます(リポジトリ内の構成ドキュメントを参照)。Oracle Multimediaをインストールすると、Oracle Multimedia DICOMは完全に機能するため、管理者は、リポジトリを更新して特定のデータベース・インスタンスに合わせてOracle Multimedia DICOMを構成する必要がないかぎり、リポジトリにアクセスする必要はありません。各データベースには専用の構成ドキュメント・セットがあります。管理者は、構成ドキュメントを追加したり削除してリポジトリをカスタマイズできます。データ・モデル・リポジトリの変更が許可されるのは、一度に1人の管理者のみです。DICOMデータ・モデル・リポジトリの管理者には、ORDADMINロールが割り当てられます。

管理者は複数のリポジトリ管理タスクを実行できます。この章では、リポジトリのロード、リポジトリ内のコンテンツの検索、追加および削除に関するガイドラインを説明します。

DICOMデータ・モデル・リポジトリには、構成ドキュメントを管理するための管理用(PL/SQL)アプリケーション・プログラミング・インタフェース(API)が用意されています。ORD_DICOMデータ・モデル・リポジトリAPIに関するリファレンス情報は、ORD_DICOM_ADMINパッケージのリファレンスを参照してください。

この章では、次の内容を説明します。

関連項目:

  • 構成ドキュメント作成の詳細は、DICOM構成ドキュメントの記述方法を参照してください。

  • 管理者が使用できるその他のアプリケーション・プログラミング・インタフェース(API)の詳細は、表3-1を参照してください。

8.1 管理者ロールおよび権限の割当て

Oracle Multimedia DICOMをインストールすると、DICOMデータ・モデル・リポジトリの管理に必要なデータベース・システム権限を持つORDADMINロールが作成されます。

ORDADMINロールは、DICOMデータ・モデル・リポジトリの管理者に割り当てる必要があります。次に示すコードは、管理者dcmadminに対するGRANT文の例です。

GRANT ORDADMIN to dcmadmin;

データベース・ロールの動作と同様に、管理者がPL/SQL名前付きプロシージャを記述する必要のあるタスクでは、明示的な権限が必要です。次に示すコードは、dcmadminという名前の管理者に対するGRANT文の例です。

GRANT EXECUTE on ORD_DICOM_ADMIN to dcmadmin;
GRANT SELECT on orddcm_document_refs to dcmadmin;

管理者には、特定のディレクトリへの書込み権限も付与する必要があります。たとえば、構成ドキュメントをエクスポートする操作では、管理者が、構成ドキュメントの保存先のディレクトリに対する書込みアクセス権限を所有している必要があります。

ユーザーはすべて、データ・モデル・リポジトリをメモリー構造にロードして、いくつかのパブリック・ビューを表示できます。データ・モデル・リポジトリから構成ドキュメントをエクスポート、挿入または削除できるのは、管理者のみです。また、管理者専用ビューは、管理者のみが問い合せることができます。

注:

次の管理ガイドラインに留意してください。

  • editDataModel( )プロシージャを使用すると、管理者は、変更作業をしている間データ・モデルをロックできます。

  • データ・モデル・リポジトリの変更がコミットされるのは、publishDataModel( )プロシージャを使用した場合のみです。このプロシージャでは、変更のコミットの他にデータ・モデルのロック解除が行われ、他の管理者がデータ・モデルを使用できるようになります。

詳細はeditDataModel()プロシージャおよびpublishDataModel( )プロシージャを参照してください。

8.2 XMLスキーマの管理

Oracle Multimedia DICOMのDICOM XMLスキーマは、Oracle DatabaseのグローバルXMLスキーマとしてOracle XML DBに登録されます。カスタムXMLスキーマを定義している場合、それらもグローバルまたはローカル・スキーマとしてOracle XML DBに登録する必要があります。ディクショナリ・ビューALL_XML_SCHEMASを問い合せることで、登録されているXMLスキーマを検索して調べることができます。

注:

ユーザー定義のマッピング・ドキュメントに関連付けられているカスタムXMLスキーマは、ローカル・スキーマとしてOracle XML DBに登録できます。カスタムXMLスキーマをローカル・スキーマとしてOracle XML DBに登録することで、それらを他のユーザーが検証に使用できないようにします。カスタムXMLスキーマをグローバル・スキーマとしてOracle XML DBに登録すると、他のユーザーがそれらを検証に使用できます。

次の各項では、DICOM XMLスキーマでXML DBを使用する方法を簡単に説明します。

関連項目:

8.2.1 XMLスキーマの登録

Oracleが提供するデフォルトの構成ドキュメントに対応するDICOM XMLスキーマは、インストール時に自動的に登録されます。(インストールされるDICOM XMLスキーマのリストは、DICOM XMLスキーマを参照してください。)Oracleでは、Oracle XML DBを使用して、ユーザー定義(カスタム)のすべてのXMLスキーマをグローバルまたはローカル・スキーマとして手動で登録する必要があります。

注:

パラメータLOCALをFALSEに設定すると、スキーマがグローバルであると指定されます。

関連項目:

カスタム・スキーマをグローバル・スキーマとして登録する方法の例は、『Oracle XML DB開発者ガイド』参照してください。

8.2.2 ユーザー定義XMLスキーマの検索

DICOMデータ・モデル・リポジトリ用のカスタムXMLスキーマを登録すると、スキーマを検索して調べることができます。ディクショナリ・ビューALL_XML_SCHEMASを問い合せて、登録済のすべてのXMLスキーマを検索します。

例8-1は、DICOMデータ・モデル・リポジトリ内のユーザー定義マッピング・ドキュメントに関連付けられているメタデータ・スキーマの名前空間を一覧表示する方法のサンプルを示します。

注:

例8-1にはsetDataModel( )プロシージャに対するコールが含まれています。このプロシージャ・コールは、必ずしもすべての状況で必要になるとはかぎりません。

詳細は、setDataModel( )プロシージャおよびデータ・モデル・リポジトリのロードを参照してください。

関連項目:

登録されたXMLスキーマの検索の詳細は、『Oracle XML DB開発者ガイド』を参照してください

例8-1 ユーザー登録されたXMLスキーマの検索

exec ord_dicom.setdatamodel;
 
select t.doc_name, xmlcast(xmlquery(
       'declare default element namespace
       "http://xmlns.oracle.com/ord/dicom/mapping_1_0"; $x//NAMESPACE'
      passing ord_dicom_admin.getdocumentcontent(t.doc_name) as "x" 
      returning content) as varchar2(4000) ) as schema_url
  from orddcm_documents  t
  where t.installed_by_oracle=0 and t.doc_type= 'MAPPING'
  order by t.doc_id asc;
 
DOC_NAME             SCHEMA_URL
-------------------- -------------------------------------
sample_map_10.xml     http://www.mycompany.com/metatest10
sample_map_11.xml     http://www.mycompany.com/metatest11

8.3 データ・モデル・リポジトリのロード

データベース・セッションを開始するたびに、管理者およびユーザーは、データベースからメモリー構造にデータ・モデル・リポジトリをロードする必要があります。ユーザーは、setDataModel( )プロシージャをコールしてデータ・モデルをロードします。管理者は、setDataModel( )プロシージャまたはeditDataModel( )プロシージャをコールして、データ・モデルをロードします。

リポジトリがメモリーにロードされると、管理者およびユーザーは、アプリケーションで新しいデータ・モデルの変更が必要になったときにいつでも、setDataModel( )プロシージャをコールできます。

注:

次のガイドラインに留意してください。

  • 管理者およびユーザーは、他のDICOMメソッド、ファンクションまたはプロシージャをコールする前に、setDataModel( )プロシージャをコールする必要があります。

  • データ・モデルに対して変更を行わない場合、管理者はsetDataModel( )プロシージャをコールできます(例: getDocumentContent( )プロシージャまたはexportDocument( )プロシージャのみをコールする場合)。

  • データ・モデルを変更する場合、管理者はeditDataModel( )プロシージャをコールできます(例: ドキュメントを挿入または削除する場合)。

詳細は、setDataModel( )プロシージャおよびeditDataModel( )プロシージャを参照してください。

ORD_DICOMパッケージのDICOMデータ・モデル・ユーティリティを使用して、管理者およびユーザーはsetDataModel( )プロシージャを次のようにコールします。

exec ord_dicom.setdatamodel;

詳細は、setDataModel( )プロシージャを参照してください。

ORD_DICOM_ADMINパッケージを使用して、管理者はeditDataModel( )プロシージャを次のようにコールします。

exec ord_dicom_admin.editDataModel();

詳細は、editDataModel( )プロシージャを参照してください。

8.4 Oracle Data Guardのローリング・アップグレードの影響の管理

Oracle Multimedia DICOMでは、Data Guardのローリング・アップグレード中のDICOMデータ・モデルの変更がサポートされません。具体的には、ローリング・アップグレードの進行中に管理者はリポジトリのドキュメントの挿入や削除ができません。このため、ローリング・アップグレード中はこれらのプロシージャのいずれもコールしないでください。

注:

管理者は、rollbackDataModel( )をコールすることで、ローリング・アップグレード操作の開始前に始まった編集セッションを終了できます(rollbackDataModel( )プロシージャを参照)。

関連項目:

8.5 ビューを使用したリポジトリの参照

パブリック・ビューのいくつかは、すべてのDICOMユーザーがDICOMリポジトリの参照に使用できます。Oracle Multimedia DICOMには管理者ビューorddcm_document_refsもあり、リポジトリ内の他のドキュメントによって参照されるドキュメントがリストされます。

管理者がリポジトリに対してドキュメントの挿入、更新および削除を行う場合は、通常、orddcm_documents、orddcm_document_typesおよびorddcm_document_refsのビューを使用します。

管理者が使用できるリポジトリ・ビューのリストは、表3-2を参照してください。

8.6 リポジトリからのドキュメントのエクスポート

リポジトリからドキュメントをエクスポートする前(および場合によっては構成ドキュメントに対して変更を行う前)に、管理者は次のタスクを実行する必要があります。

  1. 各データベース・セッションの始めにsetDataModel( )プロシージャをコールして、リポジトリをデータベースからメモリー構造内にロードします。この時点では、リポジトリをロックする必要はありません。

    管理者(および他のユーザー)は、アプリケーションで新しいデータ・モデルの変更が必要な場合も、いつでもこのプロシージャをコールできます。

    詳細は、setDataModel( )プロシージャを参照してください。

  2. getDocumentContent( )ファンクションまたはexportDocument( )プロシージャを使用して、リポジトリにある既存のドキュメントのコピーを取得します。

    getDocumentContent( )ファンクションでは、指定したドキュメントがデータ型XMLTypeとして戻されます。

    exportDocument( )プロシージャでは、管理者に書込み権限が付与されているディレクトリ内の指定したファイルに、指定したドキュメントのコンテンツが書き込まれます。

    詳細はgetDocumentContent()関数およびexportDocument( )プロシージャを参照してください。

8.7 リポジトリへのドキュメントの挿入

リポジトリにドキュメントを挿入する処理では、次のプロシージャを使用します。

  • editDataModel( )

  • insertDocument( )

  • publishDataModel( )

  • rollbackDataModel( )

これらのプロシージャの詳細は、ORD_DICOM_ADMINパッケージのリファレンスを参照してください。挿入プロセスの例は、DICOMリポジトリの管理を参照してください。

次の各項では、ドキュメント・タイプ別の挿入プロセスについて簡単に説明します。

8.7.1 匿名ドキュメント、マッピング・ドキュメントおよび制約ドキュメントの挿入

匿名ドキュメントおよびマッピング・ドキュメントの場合、挿入する順序は関係ありません。しかし、制約ドキュメントの場合は挿入する順序が重要になります。挿入する制約ドキュメントの間に依存性がある場合は、依存性のないドキュメントを先に挿入します。その後、残りのドキュメントを挿入します。

8.7.2 ディクショナリ・ドキュメントの挿入

標準ディクショナリ・ドキュメントまたはプライベート・ディクショナリ・ドキュメントの挿入では、新しいディクショナリ・ドキュメントを挿入するたびに、次のルールに従ってすべてのディクショナリ属性をマージする必要があります。

  • 属性タグは一意であることが必要で、かつ既存のワイルドカード・タグと一致しないことが必要です。

  • 属性タグは、他のドキュメント・タイプで使用されていないことが必要です。

また、プライベート・ディクショナリ・ドキュメントの属性タグは、既存の範囲タグのいずれにも含まれないようにする必要があります。

注:

標準ディクショナリ・ドキュメントの挿入は、DICOM標準規格への変更または追加を反映させる目的でのみ実行することをお薦めします。

ディクショナリ・ドキュメントに含まれるDICOM属性および属性タグの詳細は、DICOM XMLスキーマのXMLスキーマordcmsd.xsdおよびordcmpv.xsdを参照してください。

8.7.3 プリファレンス・ドキュメントおよびUID定義ドキュメントの挿入

インストールされているプリファレンス・ドキュメント(ordcmpf.xml)では、デフォルトのプリファレンス値が割り当てられます。管理者は、ユーザー定義のプリファレンス・ドキュメントをリポジトリに挿入し、デフォルトプリファレンス値の一部またはすべてをオーバーライドできます。ユーザー定義のプリファレンス・ドキュメントでオーバーライドされていないプリファレンス値は、Oracleによって定義されたデフォルト値を保持します。

管理者は、ユーザー定義のUID定義ドキュメントを挿入することで、新たにプライベートUID値を追加したりDICOM標準規格の更新内容を反映させることもできます。

ユーザー定義のプリファレンス・ドキュメントまたはUID定義ドキュメントを挿入するには、次の手順を実行します。

  1. インストールされた、Oracleによる定義のドキュメントをエクスポートして、名前を変更します。
  2. エクスポートされ、名前が変更されたドキュメントを更新し、必要に応じてパラメータ値を変更します。
  3. 更新したユーザー定義ドキュメントをリポジトリに挿入します。

後になってユーザー定義のプリファレンス・ドキュメントまたはUID定義ドキュメントが削除された場合は、Oracleでインストールされたドキュメントが再度適用されます。

注:

リポジトリに挿入できるのは、1つのユーザー定義のプリファレンス・ドキュメントまたはUID定義ドキュメントのみです。

8.7.4 ストアド・タグ・リスト・ドキュメントの挿入

管理者は、generateTagListDocument( )関数を使用して、ストアド・タグ・リスト・ドキュメントを作成できます。これは、リポジトリ内の指定されたマッピング・ドキュメントと制約ドキュメントのセットで使用される属性タグのリストです。

ストアド・タグ・リスト・ドキュメントは、オプションのXMLドキュメントで、setProperties( )メソッドがコールされたときに埋込みDICOMコンテンツから抽出され、ORDDicomオブジェクトのXMLメタデータ属性に格納されるDICOM属性を指定します。一般に、ストアド・タグ・リスト・ドキュメントは、マッピング・ドキュメントおよび制約ドキュメントで使用される属性タグを含みます。

詳細は、generateTagListDocument( )関数を参照してください。ストアド・タグ・リスト・ドキュメントの挿入プロセスの例は、サンプル・セッション4: ストアド・タグ・リスト・ドキュメントの挿入を参照してください。

8.8 リポジトリ内のドキュメントの更新

リポジトリ内のドキュメントを更新する処理では、次のプロシージャを使用します。

  • editDataModel( )

  • exportDocument( )

  • deleteDocument( )

  • insertDocument( )

  • publishDataModel( )

  • rollbackDataModel( )

これらのプロシージャの詳細は、ORD_DICOM_ADMINパッケージのリファレンスを参照してください。更新プロセスの例は、サンプル・セッション2: マッピング・ドキュメントの更新を参照してください。

次の各項では、ドキュメント・タイプ別の更新プロセスについて簡単に説明します。

8.8.1 匿名ドキュメント、マッピング・ドキュメントおよび制約ドキュメントの更新

匿名ドキュメント、マッピング・ドキュメントおよび制約ドキュメントの更新では、同様の一連の処理を実行します。匿名ドキュメントおよびマッピング・ドキュメントの場合は、次の手順を実行します。

  1. 既存のドキュメントをエクスポートします。
  2. エクスポートしたドキュメントを編集します。
  3. 既存のドキュメントを削除します。
  4. 編集済のドキュメントを挿入します。

制約ドキュメントの更新は、制約ドキュメントの挿入とは逆の順序で処理します。また、更新する制約ドキュメントの間に依存性がある場合は、依存性がないドキュメントを先に更新します。その後、残りのドキュメントを更新します。

8.8.2 ディクショナリ・ドキュメントの更新

標準ディクショナリ・ドキュメントまたはプライベート・ディクショナリ・ドキュメントの更新では、属性タグ、およびリポジトリ内の他のドキュメントとの依存性をチェックする必要があります。標準ディクショナリ・ドキュメントおよびプライベート・ディクショナリ・ドキュメントを更新できるのは、その新しいドキュメントに定義されている属性タグが他のドキュメントで使用されていない場合のみです。他のドキュメントで使用されている属性タグを更新するには、まず、依存しているドキュメントを更新して、参照先の属性タグを削除します。その後、次のルールに従ってディクショナリ・タグを更新します。

  • 属性タグは一意であることが必要で、かつ既存のワイルドカード・タグと一致しないことが必要です。

  • 属性タグは、他のドキュメント・タイプで使用されていないことが必要です。

また、プライベート・ディクショナリ・ドキュメントの場合は、DICOM属性タグが既存の範囲タグのいずれにも含まれないようにする必要があります。

注:

標準ディクショナリ・ドキュメントの更新は、DICOM標準規格への変更または追加を反映させる目的でのみ実行することをお薦めします。

ディクショナリ・ドキュメントに含まれるDICOM属性および属性タグの詳細は、DICOM XMLスキーマのXMLスキーマordcmsd.xsdおよびordcmpv.xsdを参照してください。

8.8.3 プリファレンス・ドキュメントおよびUID定義ドキュメントの更新

既存のユーザー定義のプリファレンス・ドキュメントまたはUID定義ドキュメントを更新するには、次の手順を実行します。

  1. ユーザー定義のドキュメントをエクスポートします。
  2. エクスポートしたドキュメントを編集します。
  3. 既存のユーザー定義のドキュメントを削除します。
  4. 編集済のドキュメントを挿入します。

注:

OracleまたはDICOM標準規格で定義されているUID値は、変更しないでください。

8.9 リポジトリからのドキュメントの削除

リポジトリからドキュメントを削除する処理では、次のプロシージャを使用します。

  • editDataModel( )

  • exportDocument( )

  • deleteDocument( )

  • publishDataModel( )

  • rollbackDataModel( )

元のドキュメントをリポジトリから削除する前に、exportDocument( )プロシージャを使用してドキュメントのコピーを保存します。

削除できるのは、ユーザー定義のドキュメントのみです。Oracleでインストールされたドキュメントはデフォルトのドキュメントで、削除できません。また、参照先の制約に準拠するため、ドキュメントをロードした順序とは逆の順序でドキュメントを削除します。

これらのプロシージャの詳細は、ORD_DICOM_ADMINパッケージのリファレンスを参照してください。削除プロセスの例は、サンプル・セッション3: 制約ドキュメントの削除を参照してください。

次の各項では、ドキュメント・タイプ別の削除プロセスについて簡単に説明します。

8.9.1 匿名ドキュメント、マッピング・ドキュメントおよび制約ドキュメントの削除

匿名ドキュメントおよびマッピング・ドキュメントの場合、削除する順序は関係ありません。ただし、制約ドキュメントは、挿入した順序と反対の順序で削除する必要があります。

8.9.2 ディクショナリ・ドキュメントの削除

標準ディクショナリ・ドキュメントまたはプライベート・ディクショナリ・ドキュメントの削除では、リポジトリ内の他のドキュメントとの依存性をチェックする必要があります。たとえば、ユーザー定義のディクショナリ・ドキュメントは、他のドキュメントから参照されていない場合のみ削除できます。

8.9.3 プリファレンス・ドキュメントおよびUID定義ドキュメントの削除

ユーザー定義のプリファレンス・ドキュメントを削除すると、プリファレンス・パラメータの値は、デフォルトのOracle定義のプリファレンス・ドキュメント(ordcmpf.xml)でインストールされた値に戻ります。同様に、UID定義ドキュメントを削除すると、UID値はデフォルトのOracle定義のUID定義ドキュメント(ordcmui.xml)でインストールされた値に戻ります。

8.10 Oracle Multimedia DICOMに対するOracle Data Pumpユーティリティのサポート

Oracle Data Pumpを使用したエクスポートおよびインポート操作は『Oracle Databaseユーティリティ』で説明されています。この項では、Oracle Data Pumpコマンドexpdpおよびimpdpを使用して、Oracle Multimedia DICOMに対するエクスポートとインポートの操作を実行するためのガイドラインと例を示します。

ユーザー表に格納されているDICOMデータは、Oracle Data Pumpによって自動的に処理されます。DICOMデータ・モデル・リポジトリには表が含まれ、この表にはORDDATAスキーマ内に格納されているOracleインストールによるキュメントとユーザー提供のドキュメントから移入されます。全体モードのエクスポートおよびインポート操作では、ORDDATAスキーマに格納されているユーザー提供のドキュメントがエクスポートおよびインポートされます。ORDDATAスキーマに格納されているOracleによりインストールされたドキュメントはすでにソース・データベースおよびターゲット・データベースに存在しているため、これらの操作ではエクスポートもインポートもされません。

この項の例では、コマンドexpdpおよびimpdpが使用されます。ユーザー名と適切なパラメータを使用してコマンドを入力すると、パスワードの入力を求められます。この項の例では、これらのプロンプトは表示されません。

次の各項では、DICOMデータ・モデル・リポジトリに対するエクスポートとインポートの操作のロールとモードに関する詳細を説明します。

関連項目:

Oracle Data Pumpおよびそのコマンドライン・クライアントexpdpおよびimpdpの詳細は、『Oracle Databaseユーティリティ』を参照してください

8.10.1 エクスポート操作およびインポート操作のロール

Data Pump のエクスポートとインポートの操作の多くで、管理者が次の各ロールを保持している必要があります。

  • DATAPUMP_EXP_FULL_DATABASE

  • DATAPUMP_IMP_FULL_DATABASE

関連項目:

Oracle Data PumpのExportおよびImportユーティリティに必要なロールの詳細は、『Oracle Databaseユーティリティ』を参照してください

8.10.2 エクスポート操作およびインポート操作のモード

ユーザー表(BLOB列またはOracle Multimediaのデータ型の列のいずれか)に格納されているマルチメディア・データのエクスポートおよびインポート操作は、すべてのエクスポートおよびインポート・モードでサポートされます。ただし、管理者がOracle Multimedia DICOMを使用してDICOMデータ・モデル・リポジトリにユーザー・ドキュメントを格納している場合は、全体モードでのみエクスポートおよびインポート操作がサポートされます。DICOMデータ・モデルのユーザー・ドキュメントは、全体モードでのみエクスポートおよびインポートされます。

次の各項では、これらの操作について説明します。

8.10.2.1 全体モードでのエクスポート

Oracle Multimedia DICOMを使用し、DICOMデータ・リポジトリにエクスポート対象のユーザー・ドキュメントが存在する場合は、全体モードを使用してエクスポートします。

例8-2は、全体モード・エクスポートを実行する方法を示しています。

例8-2では、次のパラメータと値が定義されます。

パラメータと値 説明

FULL=Y

全体モード・エクスポートを指定します。デフォルト値はありません。

CONTENT=ALL

エクスポートするコンテンツを指定します。デフォルト値ALLは、データとメタデータのエクスポートを指定します。

DIRECTORY=DUMP_DIR

ダンプ・ファイルとログ・ファイルのデフォルトのディレクトリの場所を指定します。ディレクトリDUMP_DIRは既存である必要があり、その場所へのアクセス権を保持している必要があります。

DUMPFILE=exp_orddata.dmp

エクスポート・ジョブのダンプ・ファイルの名前を指定します。

LOGFILE=exp_orddata.dmp

エクスポート・ジョブのログ・ファイルの名前を指定します。

関連項目:

全体モード・エクスポートの詳細は、『Oracle Databaseユーティリティ』を参照してください

例8-2 全体モード・エクスポート

expdp FULL=Y CONTENT=ALL DIRECTORY=DUMP_DIR 
  DUMPFILE=exp_orddata.dmp LOGFILE=exp_orddata.log
8.10.2.2 全体モードでのインポート

Oracle Multimedia DICOMを使用し、DICOMデータ・リポジトリにインポート対象のユーザー・ドキュメントが存在する場合は、全体モードを使用してインポートします。

例8-3は、Oracleで推奨されているパラメータと設定を使用して、全体モード・インポートを実行する方法を示しています。

例8-3は次のパラメータと値を定義します。

パラメータと値 説明

FULL=Y

全体モード・インポートを指定します。デフォルト値はありません。

CONTENT=ALL

インポートするコンテンツを指定します。デフォルト値ALLは、データとメタデータのインポートを指定します。

DIRECTORY=DUMP_DIR

ダンプ・ファイルとログ・ファイルのデフォルトのディレクトリの場所を指定します。ディレクトリDUMP_DIRは既存である必要があり、その場所へのアクセス権を保持している必要があります。

DUMPFILE=exp_orddata.dmp

インポート・ジョブのダンプ・ファイルの名前を指定します。

LOGFILE=imp_orddata.log

インポート・ジョブのログ・ファイルの名前を指定します。

関連項目:

全体モード・インポートの詳細は、『Oracle Databaseユーティリティ』を参照してください

例8-3 全体モード・インポート

impdp FULL=Y CONTENT=ALL DIRECTORY=DUMP_DIR DUMPFILE=exp_orddata.dmp 
  LOGFILE=imp_orddata.log