9 DICOMの管理の概要
この章では、Oracle Multimedia DICOMデータ・モデル・リポジトリの管理に関連するタスクの概要を説明します。
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_ADMINデータ・モデル・リポジトリAPIに関するリファレンス情報は、ORD_DICOM_ADMINパッケージのリファレンスを参照してください。
この章では、次の内容を説明します。
関連項目:
-
構成ドキュメントの記述方法の詳細は、DICOM構成ドキュメントの作成を参照してください。
-
管理者が使用可能なその他のアプリケーション・プログラミング・インタフェース(API)の詳細は、表3-1を参照してください。
9.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( )プロシージャを参照してください。
9.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に登録します。
次の各項では、XML DBをDICOM XMLスキーマとともに使用する方法について簡単に説明します。
関連項目:
-
XMLスキーマの登録の詳細は、Oracle XML DB開発者ガイドを参照してください
-
ALL_XML_SCHEMASディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください
9.2.1 XMLスキーマの登録
Oracleで提供されるデフォルトの構成ドキュメントに対応するDICOM XMLスキーマは、インストール時に自動的に登録されます。(インストールされるDICOM XMLスキーマのリストについては、DICOM XMLスキーマを参照してください。)ユーザー定義(カスタム)XMLスキーマはすべて、Oracle XML DBを使用して、グローバル・スキーマまたはローカル・スキーマとして手動で登録する必要があります。
注意:
パラメータLOCALをFALSE
に設定すると、スキーマがグローバルであることが指定されます。
関連項目:
カスタム・スキーマをグローバル・スキーマとして登録する方法の例は、Oracle XML DB開発者ガイドを参照してください。
9.2.2 ユーザー定義XMLスキーマの検索
DICOMデータ・モデル・リポジトリ用のカスタムXMLスキーマは登録されると、検索して調べることができます。ディクショナリ・ビューALL_XML_SCHEMASを問い合せると、登録済のすべてのXMLスキーマを検索できます。
例9-1は、DICOMデータ・モデル・リポジトリ内のユーザー定義マッピング・ドキュメントに関連付けられているメタデータ・スキーマの名前空間をリスト表示する方法の例を示します。
注意:
例9-1にはsetDataModel( )プロシージャのコールが含まれています。このプロシージャ・コールは、すべての状況で必要というわけではありません。
詳細は、setDataModel( )プロシージャおよびデータ・モデル・リポジトリのロードを参照してください。
関連項目:
登録されたXMLスキーマの検索の詳細は、Oracle XML DB開発者ガイドを参照してください
例9-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
9.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( )プロシージャを参照してください。
9.4 Oracle Data Guardローリング・アップグレードの影響の管理
Oracle Multimedia DICOMでは、Data Guardのローリング・アップグレード中のDICOMデータ・モデルの変更がサポートされません。具体的には、ローリング・アップグレードの進行中に管理者はリポジトリのドキュメントの挿入や削除ができません。このため、ローリング・アップグレード中は次のプロシージャのいずれもコールしないでください。
注意:
管理者は、rollbackDataModel( )をコールすることで、ローリング・アップグレード操作の開始前に始まった編集セッションを終了できます(rollbackDataModel( )プロシージャを参照)。
関連項目:
-
データベース・ローリング・アップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください
-
ローリング・アップグレードおよびその他のOracle Data Guard機能の詳細は、Oracle Data Guard概要および管理を参照してください
9.5 ビューを使用したリポジトリの参照
パブリック・ビューのいくつかは、すべてのDICOMユーザーがDICOMリポジトリの参照に使用できます。Oracle Multimedia DICOMには管理者ビューorddcm_document_refsもあり、リポジトリ内の他のドキュメントによって参照されたドキュメントがリストされます。
管理者がリポジトリに対してドキュメントの挿入、更新および削除を行う場合は、通常、orddcm_documents、orddcm_document_typesおよびorddcm_document_refsのビューを使用します。
管理者が使用できるリポジトリ・ビューのリストについては、表3-2を参照してください。
9.7 リポジトリへのドキュメントの挿入
リポジトリにドキュメントを挿入する処理では、次のプロシージャを使用します。
-
editDataModel( )
-
insertDocument( )
-
publishDataModel( )
-
rollbackDataModel( )
これらのプロシージャのリファレンス情報は、ORD_DICOM_ADMINパッケージのリファレンスを参照してください。挿入プロセスの例は、DICOMリポジトリの管理を参照してください。
次の各項では、ドキュメント・タイプ別の挿入処理について簡単に説明します。
9.7.1 匿名ドキュメント、マッピング・ドキュメントおよび制約ドキュメントの挿入
匿名ドキュメントおよびマッピング・ドキュメントの場合、挿入する順序は関係ありません。しかし、制約ドキュメントの場合は挿入する順序が重要になります。挿入する制約ドキュメントの間に依存性がある場合は、依存性のないドキュメントを先に挿入します。その後、残りのドキュメントを挿入します。
9.7.2 ディクショナリ・ドキュメントの挿入
標準ディクショナリ・ドキュメントまたはプライベート・ディクショナリ・ドキュメントの挿入では、新しいディクショナリ・ドキュメントを挿入するたびに、次のルールに従ってすべてのディクショナリ属性をマージする必要があります。
-
属性タグは一意であることが必要で、かつ既存のワイルドカード・タグと一致しないことが必要です。
-
属性タグは、他のドキュメント・タイプで使用されていないことが必要です。
また、プライベート・ディクショナリ・ドキュメントの属性タグは、既存の範囲タグのいずれにも含まれないようにする必要があります。
注意:
標準ディクショナリ・ドキュメントの挿入は、DICOM標準規格への変更または追加を反映させる目的でのみ実行することをお薦めします。
ディクショナリ・ドキュメントに含まれるDICOM属性および属性タグの詳細は、DICOM XMLスキーマに記載されているXMLスキーマordcmsd.xsd
およびordcmpv.xsd
を参照してください。
9.7.3 プリファレンス・ドキュメントおよびUID定義ドキュメントの挿入
インストールされているプリファレンス・ドキュメント(ordcmpf.xml
)によって、デフォルトのプリファレンス値が割り当てられます。管理者は、ユーザー定義のプリファレンス・ドキュメントをリポジトリに挿入し、デフォルトのプリファレンス値の一部またはすべてをオーバーライドできます。ユーザー定義のプリファレンス・ドキュメントでオーバーライドされていないプリファレンス値は、Oracleによって定義されたデフォルト値が保持されます。
また管理者は、ユーザー定義のUID定義ドキュメントを挿入して、新たにプライベートUID値を追加したりDICOM標準規格の更新内容を反映させることもできます。
ユーザー定義のプリファレンス・ドキュメントまたはUID定義ドキュメント挿入するには、次の手順を実行します。
- Oracleによって定義されたインストール済のドキュメントをエクスポートして名前を変更します。
- エクスポートされて名前変更されたドキュメントを更新し、必要に応じてパラメータ値を変更します。
- 更新したユーザー定義ドキュメントをリポジトリに挿入します。
後になってユーザー定義のプリファレンス・ドキュメントまたはUID定義ドキュメントが削除された場合は、Oracleでインストールされたドキュメントが再度適用されます。
注意:
リポジトリに挿入できるのは、1つのユーザー定義のプリファレンス・ドキュメントまたはUID定義ドキュメントのみです。
9.7.4 格納タグ・リスト・ドキュメントの挿入
管理者はgenerateTagListDocument( )ファンクションを使用して、格納タグ・リスト・ドキュメントを作成できます。格納タグ・リスト・ドキュメントはリポジトリ内の指定されたマッピング・ドキュメントおよび制約ドキュメントのセットで使用される属性タグのリストです。
格納タグ・リスト・ドキュメントはオプションのXMLドキュメントで、setProperties( )メソッドがコールされたときに、埋込みDICOMコンテンツから抽出されてORDDicomオブジェクトのXMLメタデータ属性に格納されるDICOM属性を指定します。通常、格納タグ・リスト・ドキュメントには、マッピング・ドキュメントおよび制約ドキュメントで使用される属性タグが含まれます。
詳細は、generateTagListDocument( )ファンクションを参照してください。格納タグ・リスト・ドキュメントの挿入プロセスの例は、サンプル・セッション4: 格納タグ・リスト・ドキュメントの挿入を参照してください。
9.7.5 DICOMプロトコル・ドキュメントの挿入
管理者は、insertDocument( )プロシージャ(docTypeパラメータの値としてDICOM_PROTOCOL
を指定)を使用して、新しいDICOMプロトコル・ドキュメントをデータ・モデルに挿入できます。
DICOMプロトコル・ドキュメントは、DICOM画像およびメタデータが格納されるOracle Database内の場所を制御し、ユーザーによる構成が可能なパラメータの名前付きコンテナである、XMLドキュメントです。Oracle Databaseへの接続が構成されるOracle DICOMプロトコル・アダプタの各インスタンスには、Oracle Databaseとの間で格納、問合せ、取得を実行できるようにするため、DICOMプロトコル・ドキュメントの関連付けが必要です。
詳細は、insertDocument( )プロシージャを参照してください。DICOMプロトコル・ドキュメントの挿入プロセスの例は、サンプル・セッション5: DICOMプロトコル・ドキュメントの挿入を参照してください。
関連項目:
-
DICOMプロトコル・ドキュメントの構成の詳細は、Oracle DatabaseでのDICOMプロトコルのサポートの構成を参照してください。
-
DICOMプロトコル・ドキュメントの作成の詳細は、DICOMプロトコル・ドキュメントの作成を参照してください。
9.8 リポジトリ内のドキュメントの更新
リポジトリ内のドキュメントを更新する処理では、次のプロシージャを使用します。
-
editDataModel( )
-
exportDocument( )
-
deleteDocument( )
-
insertDocument( )
-
publishDataModel( )
-
rollbackDataModel( )
これらのプロシージャのリファレンス情報は、ORD_DICOM_ADMINパッケージのリファレンスを参照してください。更新プロセスの例は、サンプル・セッション2: マッピング・ドキュメントの更新を参照してください。
次の各項では、ドキュメント・タイプ別の更新処理について簡単に説明します。
9.8.1 匿名ドキュメント、マッピング・ドキュメントおよび制約ドキュメントの更新
匿名ドキュメント、マッピング・ドキュメントおよび制約ドキュメントの更新では、同様の一連の処理を実行します。匿名ドキュメントおよびマッピング・ドキュメントの場合は、次の手順を実行します。
- 既存のドキュメントをエクスポートします。
- エクスポートしたドキュメントを編集します。
- 既存のドキュメントを削除します。
- 編集済のドキュメントを挿入します。
制約ドキュメントの更新は、制約ドキュメントの挿入とは逆の順序で処理します。また、更新する制約ドキュメントの間に依存性がある場合は、依存性がないドキュメントを先に更新します。その後、残りのドキュメントを更新します。
9.8.2 ディクショナリ・ドキュメントの更新
標準ディクショナリ・ドキュメントまたはプライベート・ディクショナリ・ドキュメントの更新では、属性タグ、およびリポジトリ内の他のドキュメントとの依存性をチェックする必要があります。標準ディクショナリ・ドキュメントおよびプライベート・ディクショナリ・ドキュメントを更新できるのは、その新しいドキュメントに定義されている属性タグが他のドキュメントで使用されていない場合のみです。他のドキュメントで使用されている属性タグを更新するには、まず、依存しているドキュメントを更新して、参照先の属性タグを削除します。その後、次のルールに従ってディクショナリ・タグを更新します。
-
属性タグは一意であることが必要で、かつ既存のワイルドカード・タグと一致しないことが必要です。
-
属性タグは、他のドキュメント・タイプで使用されていないことが必要です。
また、プライベート・ディクショナリ・ドキュメントの場合は、DICOM属性タグが既存の範囲タグのいずれにも含まれないようにする必要があります。
注意:
標準ディクショナリ・ドキュメントの更新は、DICOM標準規格への変更または追加を反映させる目的でのみ実行することをお薦めします。
ディクショナリ・ドキュメントに含まれるDICOM属性および属性タグの詳細は、DICOM XMLスキーマに記載されているXMLスキーマordcmsd.xsd
およびordcmpv.xsd
を参照してください。
9.9 リポジトリからのドキュメントの削除
リポジトリからドキュメントを削除する処理では、次のプロシージャを使用します。
-
editDataModel( )
-
exportDocument( )
-
deleteDocument( )
-
publishDataModel( )
-
rollbackDataModel( )
元のドキュメントをリポジトリから削除する前に、exportDocument( )プロシージャを使用してドキュメントのコピーを保存します。
削除できるのは、ユーザー定義のドキュメントのみです。Oracleでインストールされたドキュメントはデフォルトのドキュメントで、削除できません。また、参照先の制約に準拠するため、ドキュメントをロードした順序とは逆の順序でドキュメントを削除します。
これらのプロシージャのリファレンス情報は、ORD_DICOM_ADMINパッケージのリファレンスを参照してください。削除プロセスの例は、サンプル・セッション3: 制約ドキュメントの削除を参照してください。
次の各項では、ドキュメント・タイプ別の削除処理について簡単に説明します。
9.9.1 匿名ドキュメント、マッピング・ドキュメントおよび制約ドキュメントの削除
匿名ドキュメントおよびマッピング・ドキュメントの場合、削除する順序は関係ありません。ただし、制約ドキュメントは制約ドキュメントを挿入した順序とは逆の順序で削除する必要があります。
9.9.2 ディクショナリ・ドキュメントの削除
標準ディクショナリ・ドキュメントまたはプライベート・ディクショナリ・ドキュメントの削除では、リポジトリ内の他のドキュメントとの依存性をチェックする必要があります。たとえば、ユーザー定義のディクショナリ・ドキュメントは、他のドキュメントから参照されていない場合のみ削除できます。
9.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ユーティリティを参照してください。
9.10.1 エクスポート操作およびインポート操作のロール
Data Pumpのエクスポートとインポートの操作の多くで、管理者が次の各ロールを保持している必要があります。
-
DATAPUMP_EXP_FULL_DATABASE
-
DATAPUMP_IMP_FULL_DATABASE
関連項目:
Oracle Data Pumpのエクスポートおよびインポート・ユーティリティに必要なロールの詳細は、Oracle Databaseユーティリティを参照してください。
9.10.2 エクスポート操作およびインポート操作のモード
ユーザー表に格納されているマルチメディア・データ(BLOB列またはOracle Multimediaデータ型の列)のエクスポートおよびインポート操作は、すべてのエクスポートおよびインポート・モードでサポートされます。ただし、管理者がOracle Multimedia DICOMを使用してユーザー・ドキュメントをDICOMデータ・モデル・リポジトリに格納する場合、完全モードでのみエクスポート操作およびインポート操作がサポートされます。DICOMデータ・モデルのユーザー・ドキュメントは完全モードでのみエクスポートおよびインポートされます。
次の各項では、これらの操作について説明します。
9.10.2.1 完全モードでのエクスポート
Oracle Multimedia DICOMを使用するとき、エクスポートするユーザー・ドキュメントがDICOMデータ・モデル・リポジトリに含まれている場合は、完全モードを使用してエクスポートします。
例9-2は、完全モードのエクスポートの実行方法を示しています。
例9-2は次のパラメータと値を定義します。
パラメータおよび値 | 定義 |
---|---|
|
完全モードのエクスポートを指定します。デフォルト値はありません。 |
|
エクスポートするコンテンツを指定します。デフォルト値 |
|
ダンプ・ファイルとログ・ファイルのデフォルト・ディレクトリの場所を指定します。ディレクトリ |
|
エクスポート・ジョブ用のダンプ・ファイルの名前を指定します。 |
|
エクスポート・ジョブ用のログ・ファイルの名前を指定します。 |
関連項目:
完全モードのエクスポートの詳細は、Oracle Databaseユーティリティを参照してください。
例9-2 完全モードのエクスポート
expdp FULL=Y CONTENT=ALL DIRECTORY=DUMP_DIR DUMPFILE=exp_orddata.dmp LOGFILE=exp_orddata.log
9.10.2.2 完全モードでのインポート
Oracle Multimedia DICOMを使用するときにインポート対象のユーザー・ドキュメントがDICOMデータ・モデル・リポジトリに含まれている場合は、完全モードを使用してインポートします。
例9-3は、Oracleがお薦めするパラメータと設定を使用して、完全モードのインポートを実行する方法を示します。
例9-3は次のパラメータと値を定義します。
パラメータおよび値 | 定義 |
---|---|
|
完全モードのインポートを指定します。デフォルト値はありません。 |
|
インポートするコンテンツを指定します。デフォルト値 |
|
ダンプ・ファイルとログ・ファイルのデフォルト・ディレクトリの場所を指定します。ディレクトリ |
|
インポート・ジョブ用のダンプ・ファイルの名前を指定します。 |
|
インポート・ジョブ用のログ・ファイルの名前を指定します。 |
関連項目:
完全モードのインポートの詳細は、Oracle Databaseユーティリティを参照してください。
例9-3 完全モードのインポート
impdp FULL=Y CONTENT=ALL DIRECTORY=DUMP_DIR DUMPFILE=exp_orddata.dmp LOGFILE=imp_orddata.log