Oracle Developer Tools for Visual Studio

追記です。

[調査した事項]

3）alert_orcl.log の確認

インポート時間前後では、次のログが多発している程度で、目立ったエラーはありません。

Mon Dec 26 12:05:43 2011
Private_strands 7 at log switch
Thread 1 advanced to log sequence 40
Current log# 3 seq# 40 mem# 0: C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO03.LOG
Mon Dec 26 12:05:54 2011
Private_strands 7 at log switch
Thread 1 advanced to log sequence 41
Current log# 1 seq# 41 mem# 0: C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO01.LOG
Mon Dec 26 12:06:09 2011
Private_strands 7 at log switch
Thread 1 advanced to log sequence 42
Current log# 2 seq# 42 mem# 0: C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO02.LOG

上記が多発していることから、REDOログがいっぱいになっていることを疑った次第です。


4）インポートログの確認

コマンド実行時に指定したインポートログに、以下のエラーが出力されておりました。

IMP-00017: 次の文は、Oracleエラー2264で失敗しました:
"ALTER TABLE "HOGEHOGE" ADD CONSTRAINT "SYS_C006678" PRIMARY KEY "
"("AAA", "BBB", "CCC", "DDD", "EEE","FFF", "GGG", "HHH, "III", "JJJ", "KKK", "LLL")
"USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 S"
"TORAGE(INITIAL 65536 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TAB"
"LESPACE "USERS" LOGGING ENABLE "
IMP-00003: Oracleエラー2264が発生しました。
ORA-02264: 既存の制約によってすでに使用されている名前です。

※一部、テーブル名やフィールド名等はマスクさせていただいております。

ただ、インポートそのものは成功しているようなので影響が無いような気もしていますが、まだ調査中です。

引き続きよろしくお願いいたします

・tables指定で最後のテーブルのみインポートして成功しますか？
・SHOW=Y ROWS=Nでログを出力してみておかしなところはありませんか？

など確認してみてください。

また、エラーメッセージダンプファイルに入っているテーブルの
プライマリーキーに対し自動生成されたものが
インポート先既存オブジェクトに対し自動生成された制約とバッティングしているものですので
テーブル作成スクリプトががあれば空テーブルを作っておいてIGNORE=Yでインポートするのがおすすめです。

アドバイスありがとうございます。

ご提供いただいた情報を基に、いくつか検証を進めました。

1）SHOW=Yでの実行
dmpの中を確認しましたが、特に問題がありそうな項目はありませんでした。
インポート時にエラーが発生していたCONSTRAINTですが、CREATE UNIQUE INDEXでINDEXを作成した後に、先のALTER文でテーブルに制約を追加しているだけです。
特に失敗する要素は見当たらないのですが、何故かエラーで止まります。


2）ROWS=Nでの実行
データインポート無しで検証を行いましたが、同じ現象が発生しました。
データインポート有りの時と同じ状態（viewやprocedureが一部分だけ作成される）でインポートが停止してしまいます。
データ量が原因なわけではありませんでした。


3）IGNORE=Yでの実行
エラー無視で実行しても、同じ現象で停止します。
ご提供いただいた情報の通り、事前にテーブルを作成してから実行しても同じ結果でした。


REDOログのサイズや数を拡張せずに、ROWS=Nでインポートしても同じ結果になりますので、「REDOログがいっぱいになった」という原因は除外しております。

現状、怪しいのは発生しているエラーで、VIEWやPROCEDUREが上手く生成されない可能性を考えておりますので、
次は、CONSTRAINTS=N や INDEXES=N を指定して実行検証中です。

その他、何か情報がございましたら、引き続きよろしくお願いいたします。

停止している（ように見える）状態で、V$SESSIONから、実際待機が発生しているかを確認してみては？
インポートのセッションは、確か PROGRAM 列が「imp」となっていたかと思いますので、それで絞れるかと思います。

例）

select sid, serial#, program
from v$session
where program like '%imp%';

select event, seq#, wait_time, seconds_in_wait
from v$session
where sid = <SID>
  and serial# = <SERIAL#>;

後者のSQLを数秒おきに実行し、SEQ#列の値が変わらないままSECONDS_IN_WAIT列が増えていっている状況なら、そのイベントで待機していることを示します。

アドバイスありがとうございます。

ご提供いただいた情報から、インポートの状況を確認したところ、新たな状況が発覚いたしました。
SECONDS_IN_WAIT列の値を監視してみたところ、最初は、値が増加していくだけでしたのでプロセスが待機しているのかと思いきや、110を超えたあたりで0に戻りました。
つまり、何かのプロセスが完了したことを意味したと思い、OBJECT BROWSER経由でOBJECTの状況を確認しました。

インポートされたはずのテーブルが、SECONDS_IN_WAIT列の値が0に戻る度に1つずつ減っていっています。
（確認時は495個あったテーブルが、494個に減っていました。）
逆にSNAPSHOTが1つずつ増えていっています。
（当初確認時は5個あったSNAPSHOTが、6個に増えていました。）

impコマンドの詳細な実行方法については明るくないのですが、impコマンドは、SNAPSHOTを一度テーブルとしてインポートしてからSNAPSHOTに張り替える(？)のでしょうか。
そもそも、SNAPSHOTのインポートは膨大に時間がかかってしまうものなのでしょうか。
SNAPSHOTのインポートについてもう少し調査を進めてみます。


ちなみに、新たな情報として、dmpファイルをエクスポートした際のコマンドは以下になります。

exp direct=y compress=y userid=xxx/xxx file=[export_file] log=[log_file]

引き続きよろしくお願いいたします。

あれから色々調査しましたが、やはりマテリアライズドビューのインポートに時間がかかっているようです。
また、インポートに成功したマテリアライズドビューは、データ内容を参照することができません。

上記結果が判明しましたので、現場で別途対策を検討することになりました。
※今回の件は、サーバ移行にともなうOracleのデータベース移行が目的でした。
　VIEWやPROCEDURE等は、dmp移行を使用せず、スクリプトで再生成することになりました。
お二人の助言で、上記結果を得ることができましたので非常に助かりました。
ありがとうございます。

以上で、当スレッドをクローズとさせていただきます。