Japanese

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

import処理が途中で停止してしまうが、原因がわかりません。

907441Dec 26 2011 — edited Dec 27 2011

[やりたいこと]
AサーバでexportされたdmpファイルをBサーバにimportしたい。

[発生している問題]
importコマンド実行中にOracleが反応せず、importが途中で停止してしまう

[停止していると判断した理由]
インポート処理そのものは、データが大きいので数時間かかることは認識しています
(2～3時間程度は要します)

エクスポートコマンドから実行したのですが、コマンドプロンプト上で最後のテーブルがインポートされ終わった状態から進みません。

．．表　　"xxxxxxxxxx"をインポートしています。　0行インポートされました。

上記コマンドが表示された状態で止まっています。
(※テーブル名はマスクさせていただいております。)　

上記状態で、Oracleが稼動しているサーバのCPU使用率を確認すると、0%に近い値をウロウロしています。
HDDのアクセスランプも点灯/点滅していないので停止していると判断しました。

が、OBJECT BROWSER経由でインポート状況を確認すると、テーブル以降のオブジェクト（viewやprocedure等）が、それぞれ一部ずつインポートされています。

[調査した事項]

1）表領域情報の不足

以前、表領域のサイズが不足したため失敗した経験があったのでインポート先ユーザが使用している表領域の容量を確認したところ、サイズは20GB確保しており、使用済サイズが9GBでした。
11GBの空きがあるので、サイズ不足で書き込みが停止していることは無いと思います。

※ただし、以下の表領域は、ほぼいっぱいです。
　* SYSAUX
　* SYSTEM
　* TEMP
　* UNDOTBS1

2）アーカイブログモードの確認

次のSQLを発行してデータベースのアーカイブログモードは確認しました。

SELECT log_mode FROM v$database
　↓
NOARCHIVELOG

アーカイブログは出力していないので、アーカイブログの出力待ちではないと思います。

[調査中の事項]

1）REDOログ

調べた中に「REDOログがいっぱいになるとハングアップする」という情報がありました。
「ハングアップ」というと、CPUを使い切って落ちるようなイメージがあるので、はずれかと思いましたが、一応、新しいREDOログを3つ作成し、サイズを100MBにして検証中です。

2）その他の表領域

先に記載しましたが、次の表領域がいっぱいなので何か関係あるでしょうか。
　* SYSAUX
　* SYSTEM
　* TEMP
　* UNDOTBS1

何かその他思い当たる原因がございますでしょうか。
ご助力をお願いいたします。

以下、現在の環境情報です。
不足等ありましたらご指摘ください。
　
[Oracleバージョン]
　Oracle Database 10g Release 10.1.0.2.0
[インストールOS]
　Windows Server 2003 R2 x86 SP1
[Oracleインストール先]
　C:/oracle/product/10.1.0
[Oracleインストール先の容量]
　Cドライブ：100GB
[importを実行したコマンド]
　imp [user]@[service] file=[filepath] log=[logfilepath] full=y commit=y

907441

追記です。

[調査した事項]

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: 既存の制約によってすでに使用されている名前です。

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

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

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

hamadeguchi

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

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

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

907441

hamadeguchi様

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

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

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 を指定して実行検証中です。

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

Blueloco

停止している（ように見える）状態で、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列が増えていっている状況なら、そのイベントで待機していることを示します。

907441

Blueloco様

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

ご提供いただいた情報から、インポートの状況を確認したところ、新たな状況が発覚いたしました。
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]

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

907441

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

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

hamadeguchi様
Blueloco様

お二人の助言で、上記結果を得ることができましたので非常に助かりました。
ありがとうございます。

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

1 - 6

Locked Post

New comments cannot be posted to this locked post.

Locked on Jan 24 2012

Added on Dec 26 2011

#import, #データベース, #バックアップ-リカバリ

6 comments

49,909 views

Japanese

import処理が途中で停止してしまうが、原因がわかりません。

Comments

Post Details