# Oracle DB インスタンスのその他のタスクの実行
次に、Oracle を実行している Amazon RDS DB インスタンスでその他の DBA タスクを実行する方法を示します。マネージド型サービスの操作性を実現するために、Amazon RDS では DB インスタンスへのシェルアクセスは提供していません。また、上位の権限を必要とする特定のシステムプロシージャやシステムテーブルへのアクセスが制限されます。
**Topics**
+ [主要データストレージ領域でのディレクトリの作成と削除](#Appendix.Oracle.CommonDBATasks.NewDirectories)
+ [DB インスタンスディレクトリ内のファイルのリスト化](#Appendix.Oracle.CommonDBATasks.ListDirectories)
+ [DB インスタンスディレクトリ内のファイルの読み取り](#Appendix.Oracle.CommonDBATasks.ReadingFiles)
+ [Opatch ファイルへのアクセス](#Appendix.Oracle.CommonDBATasks.accessing-opatch-files)
+ [アドバイザータスクの管理](#Appendix.Oracle.CommonDBATasks.managing-advisor-tasks)
+ [テーブルスペースの転送](rdsadmin_transport_util.md)
## 主要データストレージ領域でのディレクトリの作成と削除
ディレクトリを作成するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.create_directory` を使用します。最大 10,000 個のディレクトリを作成でき、すべてメインデータストレージ領域に配置されます。ディレクトリを作成するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.drop_directory` を使用します。
`create_directory` および `drop_directory` プロシージャには、以下の必須パラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_directory_name` | VARCHAR2 | — | はい | ディレクトリの名前。 |
次の例では、新しいディレクトリ `PRODUCT_DESCRIPTIONS` を作成します。
```
EXEC rdsadmin.rdsadmin_util.create_directory(p_directory_name => 'product_descriptions');
```
データディクショナリは、ディレクトリ名を大文字で保存します。`DBA_DIRECTORIES` を照会することで、ディレクトリを一覧表示できます。システムによって実際のホストパス名が自動的に選択されます。以下の例では、`PRODUCT_DESCRIPTIONS` という名前のディレクトリのディレクトリパスを取得しています。
```
SELECT DIRECTORY_PATH
FROM DBA_DIRECTORIES
WHERE DIRECTORY_NAME='PRODUCT_DESCRIPTIONS';
DIRECTORY_PATH
----------------------------------------
/rdsdbdata/userdirs/01
```
DB インスタンスのマスターユーザー名には、新しいディレクトリでの読み取りおよび書き込み権限があり、他のユーザーにアクセスを許可できます。`EXECUTE` 権限は、DB インスタンス上のディレクトリでは使用できません。ディレクトリはメインデータストレージ領域に作成され、領域および I/O 帯域幅を消費します。
以下の例では、`PRODUCT_DESCRIPTIONS` という名前のディレクトリを削除します。
```
EXEC rdsadmin.rdsadmin_util.drop_directory(p_directory_name => 'product_descriptions');
```
**注記**
Oracle SQL コマンド `DROP DIRECTORY` を使用してディレクトリを削除することもできます。
ディレクトリを削除してもその内容は削除されません。`rdsadmin.rdsadmin_util.create_directory` プロシージャはパス名を再利用できるため、削除されたディレクトリのファイルが新たに作成されたディレクトリに存在する可能性があります。ディレクトリを削除する前に、`UTL_FILE.FREMOVE` を使用してディレクトリからファイルを削除することをお勧めします。詳細については、Oracle ドキュメントの「[FREMOVE プロシージャ](https://docs.oracle.com/database/121/ARPLS/u_file.htm#ARPLS70924)」を参照してください。
## DB インスタンスディレクトリ内のファイルのリスト化
ディレクトリ内のファイルを一覧表示するには、Amazon RDS プロシージャ `rdsadmin.rds_file_util.listdir` を使用します。このプロシージャは Oracle レプリカではサポートされていません。`listdir` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_directory` | varchar2 | — | はい | 一覧表示するディレクトリの名前。 |
次の例では、ディレクトリ `PRODUCT_DESCRIPTIONS` に対する読み取り/書き込み権限をユーザー `rdsadmin` に付与し、このディレクトリ内のファイルを一覧表示します。
```
GRANT READ,WRITE ON DIRECTORY PRODUCT_DESCRIPTIONS TO rdsadmin;
SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'PRODUCT_DESCRIPTIONS'));
```
## DB インスタンスディレクトリ内のファイルの読み取り
テキストファイルを読み取るには、Amazon RDS プロシージャ `rdsadmin.rds_file_util.read_text_file` を使用します。`read_text_file` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_directory` | varchar2 | — | はい | ファイルを含むディレクトリの名前。 |
| `p_filename` | varchar2 | — | はい | 読み取るファイルの名前。 |
次の例では `rice.txt` ディレクトリの `PRODUCT_DESCRIPTIONS` ファイルを読み取ります。
```
declare
fh sys.utl_file.file_type;
begin
fh := utl_file.fopen(location=>'PRODUCT_DESCRIPTIONS', filename=>'rice.txt', open_mode=>'w');
utl_file.put(file=>fh, buffer=>'AnyCompany brown rice, 15 lbs');
utl_file.fclose(file=>fh);
end;
/
```
次の例では、ディレクトリ `rice.txt` からファイル `PRODUCT_DESCRIPTIONS` を読み取ります。
```
SELECT * FROM TABLE
(rdsadmin.rds_file_util.read_text_file(
p_directory => 'PRODUCT_DESCRIPTIONS',
p_filename => 'rice.txt'));
```
## Opatch ファイルへのアクセス
Opatch は、Oracle ソフトウェアへのパッチの適用とロールバックを可能にする Oracle ユーティリティです。データベースに適用されているパッチを判別するための Oracle のメカニズムは、`opatch lsinventory` コマンドです。Bring Your Own License (BYOL) の顧客のサービスリクエストを開くために、Oracle サポートは `lsinventory` ファイルをリクエストします。Opatch によって生成される `lsinventory_detail` ファイルをリクエストする場合もあります。
マネージドサービスエクスペリエンスを提供するために、Amazon RDS には Opatch へのシェルアクセスは用意されていません。代わりに、BDUMP ディレクトリの`lsinventory-dbv.txt`には、現在のエンジンのバージョンに関連するパッチ情報が含まれています。マイナーアップグレードまたはメジャーアップグレードを実行すると、Amazon RDS はパッチを適用してから 1 時間以内に`lsinventory-dbv.txt`を更新します。適用されたパッチを確認するには、`lsinventory-dbv.txt`を読み取ります。このアクションは、`opatch lsinventory`コマンドの実行に似ています。
**注記**
このセクションの例では、BDUMP ディレクトリ名を `BDUMP` としています。リードレプリカでは、BDUMP ディレクトリ名が異なります。BDUMP 名を取得するためにリードレプリカに対してクエリ `V$DATABASE.DB_UNIQUE_NAME` を実行する方法については、「[ファイルのリスト化](USER_LogAccess.Concepts.Oracle.md#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.ViewingBackgroundDumpDest)」を参照してください。
インベントリファイルは Amazon RDS 命名規則 `lsinventory-dbv.txt` および `lsinventory_detail-dbv.txt` を使用します。ここで、*dbv* は DB バージョンの完全な名前です。`lsinventory-dbv.txt` ファイルはすべての DB バージョンで使用できます。対応する `lsinventory_detail-dbv.txt` は、19.0.0.0、ru-2020-01.rur-2020-01.r1 以降で利用できます。
例えば、DB のバージョンが 19.0.0.0.ru-2021-07.rur-2021-07.r1 の場合、インベントリファイルは以下の名前になります。
```
lsinventory-19.0.0.0.ru-2021-07.rur-2021-07.r1.txt
lsinventory_detail-19.0.0.0.ru-2021-07.rur-2021-07.r1.txt
```
DB エンジンの現在のバージョンと一致するファイルをダウンロードしてください。
### コンソール
**コンソールを使用してインベントリファイルをダウンロードするには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. 表示するログファイルのある DB インスタンスの名前を選択します。
1. [**ログとイベント**] タブを選択します。
1. [**ログ**] セクションまで下にスクロールします。
1. [**ログ**] セクションで、`lsinventory` を検索します。
1. アクセスするファイルを選択し、[**ダウンロード**] を選択します。
### SQL
SQL クライアントで `lsinventory-dbv.txt` を読み取るには、`SELECT` ステートメントを使用できます。この手法では、`rdsadmin` 関数として `rdsadmin.rds_file_util.read_text_file` または `rdsadmin.tracefile_listing` のいずれかを使用します。
以下のサンプルクエリでは、*dbv* を Oracle DB のバージョンに置き換えます。例えば、DB のバージョンは 19.0.0.0.ru-2020-04.rur-2020-04.r1 です。
```
SELECT text
FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'lsinventory-dbv.txt'));
```
### PL/SQL
SQL クライアントで `lsinventory-dbv.txt` を読み取るには、PL/SQL プログラムを作成します。このプログラムは、`utl_file` を使用してファイルを読み取り、`dbms_output` を使用して出力します。これらは、Oracle が提供するパッケージです。
以下のサンプルプログラムでは、*dbv* を Oracle DB のバージョンに置き換えます。例えば、DB のバージョンは 19.0.0.0.ru-2020-04.rur-2020-04.r1 です。
```
SET SERVEROUTPUT ON
DECLARE
v_file SYS.UTL_FILE.FILE_TYPE;
v_line VARCHAR2(1000);
v_oracle_home_type VARCHAR2(1000);
c_directory VARCHAR2(30) := 'BDUMP';
c_output_file VARCHAR2(30) := 'lsinventory-dbv.txt';
BEGIN
v_file := SYS.UTL_FILE.FOPEN(c_directory, c_output_file, 'r');
LOOP
BEGIN
SYS.UTL_FILE.GET_LINE(v_file, v_line,1000);
DBMS_OUTPUT.PUT_LINE(v_line);
EXCEPTION
WHEN no_data_found THEN
EXIT;
END;
END LOOP;
END;
/
```
または、`rdsadmin.tracefile_listing` をクエリし、出力をファイルにスプールします。以下の例では、出力を `/tmp/tracefile.txt` にスプールします。
```
SPOOL /tmp/tracefile.txt
SELECT *
FROM rdsadmin.tracefile_listing
WHERE FILENAME LIKE 'lsinventory%';
SPOOL OFF;
```
## アドバイザータスクの管理
Oracle Database には、多数のアドバイザーが含まれています。各アドバイザーは、自動タスクと手動タスクをサポートします。`rdsadmin.rdsadmin_util` パッケージ内のプロシージャを使用して、いくつかのアドバイザータスクを管理できます。
アドバイザータスク手順は、次のエンジンバージョンで使用できます。
+ Oracle Database 21c (21.0.0)
+ Version 19.0.0.0.ru-2021-01.rur-2021-01.r1 以上の Oracle Database 19c バージョン
詳細については、「*Amazon RDS for Oracle リリースノート*」の「[バージョン 19.0.0.0.ru-2021-01.rur-2021-01.r1](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/oracle-version-19-0.html#oracle-version-RU-RUR.19.0.0.0.ru-2021-01.rur-2021-01.r1)」を参照してください。
**Topics**
+ [アドバイザータスクのパラメータの設定](#Appendix.Oracle.CommonDBATasks.setting-task-parameters)
+ [AUTO\$1STATS\$1ADVISOR\$1TASK を無効にする](#Appendix.Oracle.CommonDBATasks.dropping-advisor-task)
+ [AUTO\$1STATS\$1ADVISOR\$1TASK を再度有効にする](#Appendix.Oracle.CommonDBATasks.recreating-advisor-task)
### アドバイザータスクのパラメータの設定
一部のアドバイザータスクのパラメータを設定するには、Amazon RDS 手順 `rdsadmin.rdsadmin_util.advisor_task_set_parameter` を使用します。`advisor_task_set_parameter` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_task_name` | varchar2 | — | はい | パラメータを変更するアドバイザータスクの名前。以下の値が有効です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Misc.html) |
| `p_parameter` | varchar2 | — | はい | タスクパラメータの名前。アドバイザータスクの有効なパラメータを検索するには、次のクエリを実行します。*p\$1task\$1name* を `p_task_name` の有効な値に置き換えます: COL PARAMETER_NAME FORMAT a30
COL PARAMETER_VALUE FORMAT a30
SELECT PARAMETER_NAME, PARAMETER_VALUE
FROM DBA_ADVISOR_PARAMETERS
WHERE TASK_NAME='p_task_name'
AND PARAMETER_VALUE != 'UNUSED'
ORDER BY PARAMETER_NAME;
|
| `p_value` | varchar2 | — | はい | タスクパラメータの値。タスクパラメータの有効な値を検索するには、次のクエリを実行します。*p\$1task\$1name* を `p_task_name` の有効な値に置き換えます: COL PARAMETER_NAME FORMAT a30
COL PARAMETER_VALUE FORMAT a30
SELECT PARAMETER_NAME, PARAMETER_VALUE
FROM DBA_ADVISOR_PARAMETERS
WHERE TASK_NAME='p_task_name'
AND PARAMETER_VALUE != 'UNUSED'
ORDER BY PARAMETER_NAME;
|
次の PL/SQL プログラムは `ACCEPT_PLANS` を `FALSE` の `SYS_AUTO_SPM_EVOLVE_TASK` に設定します。SQL Plan Management の自動化タスクでは、プランが検証され、その結果のレポートが生成されますが、プランを自動的には進化させません。レポートを使用して、新しい SQL 計画ベースラインを識別し、手動で受け入れることができます。
```
BEGIN
rdsadmin.rdsadmin_util.advisor_task_set_parameter(
p_task_name => 'SYS_AUTO_SPM_EVOLVE_TASK',
p_parameter => 'ACCEPT_PLANS',
p_value => 'FALSE');
END;
```
次の PL/SQL プログラムは `EXECUTION_DAYS_TO_EXPIRE` を `10` の `AUTO_STATS_ADVISOR_TASK` に設定します。事前定義されたタスク `AUTO_STATS_ADVISOR_TASK` は、メンテナンスウィンドウで 1 日 1 回自動的に実行されます。この例では、タスク実行の保持期間を 10 日に設定します。
```
BEGIN
rdsadmin.rdsadmin_util.advisor_task_set_parameter(
p_task_name => 'AUTO_STATS_ADVISOR_TASK',
p_parameter => 'EXECUTION_DAYS_TO_EXPIRE',
p_value => '10');
END;
```
### AUTO\$1STATS\$1ADVISOR\$1TASK を無効にする
`AUTO_STATS_ADVISOR_TASK` を無効にするには、Amazon RDS 手順 `rdsadmin.rdsadmin_util.advisor_task_drop` を使用します。`advisor_task_drop` 手順は、次のパラメータを受け付けます。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_task_name` | varchar2 | — | はい | 無効にするアドバイザータスクの名前。唯一の有効な値は `AUTO_STATS_ADVISOR_TASK` です。 |
次のコマンドは `AUTO_STATS_ADVISOR_TASK` をドロップします。
```
EXEC rdsadmin.rdsadmin_util.advisor_task_drop('AUTO_STATS_ADVISOR_TASK')
```
`rdsadmin.rdsadmin_util.dbms_stats_init` を使用して `AUTO_STATS_ADVISOR_TASK` を再度有効にすることができます。
### AUTO\$1STATS\$1ADVISOR\$1TASK を再度有効にする
`AUTO_STATS_ADVISOR_TASK` を再度有効にするには、Amazon RDS 手順 `rdsadmin.rdsadmin_util.dbms_stats_init` を使用します。`dbms_stats_init` 手順では、パラメータは使用しません。
次のコマンドは `AUTO_STATS_ADVISOR_TASK` を再度有効にします。
```
EXEC rdsadmin.rdsadmin_util.dbms_stats_init()
```
# テーブルスペースの転送
Amazon RDS パッケージ `rdsadmin.rdsadmin_transport_util` を使用して、オンプレミスの Oracle データベースから RDS for Oracle DB インスタンスにテーブルスペースのセットをコピーします。物理レベルでは、この転送可能テーブルスペース機能は、ソースデータファイルとメタデータファイルをターゲットインスタンスに増分的にコピーします。ファイルは、Amazon EFS または Amazon S3 のいずれかを使用して転送できます。詳細については、「[Oracle トランスポータブル表領域を使用した移行](oracle-migrating-tts.md)」を参照してください。
**Topics**
+ [転送されたテーブルスペースを DB インスタンスにインポートする](rdsadmin_transport_util_import_xtts_tablespaces.md)
+ [転送可能テーブルスペースメタデータを DB インスタンスにインポートする](rdsadmin_transport_util_import_xtts_metadata.md)
+ [テーブルスペースのインポート後の孤立ファイルを一覧表示する](rdsadmin_transport_util_list_xtts_orphan_files.md)
+ [テーブルスペースのインポート後に孤立したデータファイルを削除する](rdsadmin_transport_util_cleanup_incomplete_xtts_import.md)
# 転送されたテーブルスペースを DB インスタンスにインポートする
プロシージャ `rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces` を使用して、ソース DB インスタンスから以前にエクスポートしたテーブルスペースを復元します。トランスポートフェーズでは、読み取り専用のテーブルスペースをバックアップし、Data Pump メタデータをエクスポートし、これらのファイルをターゲット DB インスタンスに転送して、テーブルスペースをインポートします。詳細については、「[フェーズ 4: 表領域をトランスポートする](oracle-migrating-tts.md#oracle-migrating-tts.final-br-phase)」を参照してください。
## 構文
```
FUNCTION import_xtts_tablespaces(
p_tablespace_list IN CLOB,
p_directory_name IN VARCHAR2,
p_platform_id IN NUMBER DEFAULT 13,
p_parallel IN INTEGER DEFAULT 0) RETURN VARCHAR2;
```
## パラメータ
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_tablespace_list` | `CLOB` | — | はい | インポートするテーブルスペースのリスト。 |
| `p_directory_name` | `VARCHAR2` | — | はい | テーブルスペースのバックアップを含むディレクトリ。 |
| `p_platform_id` | `NUMBER` | `13` | いいえ | バックアップフェーズで指定したものと一致するプラットフォーム ID を指定します。プラットフォームのリストを検索するには、`V$TRANSPORTABLE_PLATFORM` をクエリします。デフォルトのプラットフォームは Linux x86 64 ビットで、これはリトルエンディアンです。 |
| `p_parallel` | `INTEGER` | `0` | いいえ | 並列処理の度合い。デフォルトでは、並列処理は無効になっています。 |
## 例
以下の例では、表領域*TBS1*、*TBS2*、および *TBS3* をディレクトリ *DATA\$1PUMP\$1DIR* からインポートします。ソースプラットフォームは AIX ベースのシステム (64 ビット) で、プラットフォーム ID は `6` です。プラットフォーム ID は、`V$TRANSPORTABLE_PLATFORM` をクエリすることで確認できます。
```
VAR task_id CLOB
BEGIN
:task_id:=rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces(
'TBS1,TBS2,TBS3',
'DATA_PUMP_DIR',
p_platform_id => 6);
END;
/
PRINT task_id
```
# 転送可能テーブルスペースメタデータを DB インスタンスにインポートする
プロシージャ `rdsadmin.rdsadmin_transport_util.import_xtts_metadata` を使用して、転送可能テーブルスペースメタデータを RDS for Oracle DB インスタンスにインポートします。操作中、メタデータのインポートのステータスがテーブル `rdsadmin.rds_xtts_operation_info` に表示されます。詳細については、「[ステップ 5: ターゲット DB インスタンスに表領域メタデータをインポートする](oracle-migrating-tts.md#oracle-migrating-tts.transport.import-dmp)」を参照してください。
## 構文
```
PROCEDURE import_xtts_metadata(
p_datapump_metadata_file IN SYS.DBA_DATA_FILES.FILE_NAME%TYPE,
p_directory_name IN VARCHAR2,
p_exclude_stats IN BOOLEAN DEFAULT FALSE,
p_remap_tablespace_list IN CLOB DEFAULT NULL,
p_remap_user_list IN CLOB DEFAULT NULL);
```
## パラメータ
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_datapump_metadata_file` | `SYS.DBA_DATA_FILES.FILE_NAME%TYPE` | — | はい | 転送可能テーブルスペースのメタデータを含む Oracle Data Pumpファイルの名前。 |
| `p_directory_name` | `VARCHAR2` | — | はい | Data Pump ファイルを含むディレクトリ。 |
| `p_exclude_stats` | `BOOLEAN` | `FALSE` | いいえ | 統計を除外するかどうかを示すフラグ。 |
| `p_remap_tablespace_list` | `CLOB` | NULL | いいえ | メタデータのインポート中に再マップされるテーブルスペースのリスト。形式 `from_tbs:to_tbs` を使用します。例えば、`users:user_data` と指定します。 |
| `p_remap_user_list` | `CLOB` | NULL | いいえ | メタデータのインポート中に再マップされるユーザースキーマのリスト。形式 `from_schema_name:to_schema_name` を使用します。例えば、`hr:human_resources` と指定します。 |
## 例
この例では、ディレクトリ *DATA\$1PUMP\$1DIR* にあるファイル *xttdump.dmp* からテーブルスペースメタデータをインポートします。
```
BEGIN
rdsadmin.rdsadmin_transport_util.import_xtts_metadata('xttdump.dmp','DATA_PUMP_DIR');
END;
/
```
# テーブルスペースのインポート後の孤立ファイルを一覧表示する
`rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files` プロシージャを使用して、テーブルスペースのインポート後に孤立したデータファイルを一覧表示します。データファイルを特定したら、`rdsadmin.rdsadmin_transport_util.cleanup_incomplete_xtts_import` を呼び出して削除できます。
## 構文
```
FUNCTION list_xtts_orphan_files RETURN xtts_orphan_files_list_t PIPELINED;
```
## 例
次の例では、`rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files` プロシージャを呼び出します。出力には、孤立した 2 つのデータファイルが表示されます。
```
SQL> SELECT * FROM TABLE(rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files);
FILENAME FILESIZE
-------------- ---------
datafile_7.dbf 104865792
datafile_8.dbf 104865792
```
# テーブルスペースのインポート後に孤立したデータファイルを削除する
`rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files` プロシージャを使用して、テーブルスペースのインポート後に孤立したデータファイルを削除します。このコマンドを実行すると、`BDUMP` ディレクトリに、名前形式 `rds-xtts-delete_xtts_orphaned_files-YYYY-MM-DD.HH24-MI-SS.FF.log` を使用するログファイルが生成されます。プロシージャ `rdsadmin.rdsadmin_transport_util.cleanup_incomplete_xtts_import` を使用して、孤立したファイルを見つけます。プロシージャ `rdsadmin.rds_file_util.read_text_file` を呼び出することによって、ログファイルを読み取ることができます。詳細については、「[フェーズ 6: 残ったファイルをクリーンアップする](oracle-migrating-tts.md#oracle-migrating-tts.cleanup)」を参照してください。
## 構文
```
PROCEDURE cleanup_incomplete_xtts_import(
p_directory_name IN VARCHAR2);
```
## パラメータ
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_directory_name` | `VARCHAR2` | — | はい | 孤立したデータファイルを含むディレクトリ。 |
## 例
次の例では、*DATA\$1PUMP\$1DIR* にある孤立したデータファイルを削除します。
```
BEGIN
rdsadmin.rdsadmin_transport_util.cleanup_incomplete_xtts_import('DATA_PUMP_DIR');
END;
/
```
次の例では、前のコマンドで生成されたログファイルを読み取ります。
```
SELECT *
FROM TABLE(rdsadmin.rds_file_util.read_text_file(
p_directory => 'BDUMP',
p_filename => 'rds-xtts-delete_xtts_orphaned_files-2023-06-01.09-33-11.868894000.log'));
TEXT
--------------------------------------------------------------------------------
orphan transported datafile datafile_7.dbf deleted.
orphan transported datafile datafile_8.dbf deleted.
```