社内SEの徒然なる日記

OracleのimpdpでORA-39126とか致命的なエラー連発!

■ Oracleのリストア

基幹システムのリプレースに合わせて、新環境で色々とテストしていたのですが、その中でexpdpで抜いたデータをimpdpで戻すテストを行いました。

エクスポート、インポートともに、対象はスキーマ全体です。

さて、エクスポートは正常に動いて、そのままインポートを実行したのですが、これがいつまでたっても終わりません。

待ち続けて3時間、夜も更けてきたので音を上げて帰宅したのですが、翌朝結果を見ると見たことのない凄いエラーを吐いて異常終了していました。

■ impdpのログ

実際にエラーが出た個所のログはこんな感じ。ここまで大量にエラーが吐かれると、いろいろと諦めがつきます。



ORA-39126: KUPW$WORKER.STATS_LOAD [MARKER]でワーカーに予期しない致命的なエラーが発生しました
ORA-29913: ODCIEXTTABLEOPENコールアウトの実行中にエラーが発生しました。
ORA-29400: データ・カートリッジ・エラーが発生しました
KUP-11011: 次のファイルはこのロード操作には無効です
KUP-11013: ファイル/backup/expdp.dmpのヘッダーの内部番号が無効です
ORA-06512: "SYS.DBMS_SYS_ERROR", 行95
ORA-06512: "SYS.KUPW$WORKER", 行11259
----- PL/SQL Call Stack -----
object line object
handle number name
51bf79980 27116 package body SYS.KUPW$WORKER
51bf79980 11286 package body SYS.KUPW$WORKER
51bf79980 24286 package body SYS.KUPW$WORKER
51bf79980 20690 package body SYS.KUPW$WORKER
51bf79980 4545 package body SYS.KUPW$WORKER
51bf79980 12063 package body SYS.KUPW$WORKER
51bf79980 2081 package body SYS.KUPW$WORKER
52eec0d20 2 anonymous block
DBMS_METADATA_UTIL.FETCH_STAT
DBMS_METADATA_UTIL.FETCH_STAT
KUPD$DATA.OPEN
KUPD$DATA.SET_PARAMETER - common
KUPD$DATA.SET_PARAMETER - common
KUPD$DATA.SET_PARAMETER - LOAD
KUPD$DATA.SET_PARAMETER - LOAD
KUPD$DATA.SET_PARAMETER - flags
KUPD$DATA.START_JOB
In procedure DETERMINE_FATAL_ERROR with ORA-29913: ODCIEXTTABLEOPENコールアウトの実行中にエラーが発生しました。
ORA-29400: データ・カートリッジ・エラーが発生しました
KUP-11011: 次のファイルはこのロード操作には無効です
KUP-11013: ファイル/backup/expdp.dmpのヘッダーの内部番号が無効です
ORA-39126: KUPW$WORKER.STATS_LOAD [MARKER]でワーカーに予期しない致命的なエラーが発生しました
ORA-29913: ODCIEXTTABLEOPENコールアウトの実行中にエラーが発生しました。
ORA-29400: データ・カートリッジ・エラーが発生しました
KUP-11011: 次のファイルはこのロード操作には無効です
KUP-11013: ファイル/backup/expdp.dmpのヘッダーの内部番号が無効です
ORA-06512: "SYS.DBMS_SYS_ERROR", 行95
ORA-06512: "SYS.KUPW$WORKER", 行11259
----- PL/SQL Call Stack -----
object line object
handle number name
51bf79980 27116 package body SYS.KUPW$WORKER
51bf79980 11286 package body SYS.KUPW$WORKER
51bf79980 24286 package body SYS.KUPW$WORKER
51bf79980 20690 package body SYS.KUPW$WORKER
51bf79980 4545 package body SYS.KUPW$WORKER
51bf79980 12063 package body SYS.KUPW$WORKER
51bf79980 2081 package body SYS.KUPW$WORKER
52eec0d20 2 anonymous block
DBMS_METADATA_UTIL.FETCH_STAT
DBMS_METADATA_UTIL.FETCH_STAT
KUPD$DATA.OPEN
KUPD$DATA.SET_PARAMETER - common
KUPD$DATA.SET_PARAMETER - common
KUPD$DATA.SET_PARAMETER - LOAD
KUPD$DATA.SET_PARAMETER - LOAD
KUPD$DATA.SET_PARAMETER - flags
KUPD$DATA.START_JOB
In procedure DETERMINE_FATAL_ERROR with ORA-29913: ODCIEXTTABLEOPENコールアウトの実行中にエラーが発生しました。
ORA-29400: データ・カートリッジ・エラーが発生しました
KUP-11011: 次のファイルはこのロード操作には無効です
KUP-11013: ファイル/backup/expdp.dmpのヘッダーの内部番号が無効です
ジョブ"********"."*****"は致命的なエラーのため ************ elapsed 0 03:23:44で停止しました



■ 原因

一体何が起こったのかと頭を抱えたのですが、結局原因はインポート中にダンプファイルが壊れたことが原因でした。

日々のバックアップのために、夜間にexpdpをスケジュール実行していたのですが、これを止めるのを忘れてしまったため、インポート中のダンプに上書きする形でエクスポートが実行されていました。

そりゃ、失敗しますよね。

幸いなことに、ダンプファイルを別の場所に退避していたので、それを使って再度インポートを実行したところ、今度は成功しました。

■ 後書き

今回のimpdpは、オプションとして、CONTENT=ALL、TABLE_EXISTS_ACTION=REPLACE を指定していたのですが、これを設定すると異様に時間が掛かりました。

もうちょっと性能が落ちる環境で、CONTENT=DATA_ONLY、TABLE_EXISTS_ACTION=TRUNCATE で実行した時は1時間程度だったので、長くても1時間30分くらいなんだろうなと思ってたのですが、実際には3時間以上かかりました。

ログを見ると、テーブルにデータを入れる部分については1時間程度だったのですが、「オブジェクト型SCHEMA_EXPORT/TABLE/INDEX/INDEXの処理中です」と表示されてからが長かった・・・

インポートの時間の大半ってテーブルのデータを突っ込む部分だと思っていたのですが、そうでもないようです。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end --- スポンサードリンク

PageTop

Symantecの警告画面を始めてみた

■ Symantec

ウィルス対策ソフトとして、随分と長いことSymantecを使用しています。普段はあまり意識していないのですが、先日、働いているところを確認できました。

ファイラーとして As/R というソフトを使用しています。まめFile というファイラーの後継ソフトなのですが、先日アップデートしようとインストーラーをダウンロードして実行しようとすると、このような警告が表示されました。
Symantecの警告画面1

Symantecの警告画面2

As/Rのホームページには、「毎回のようにウィルススキャンソフトによる誤検出が発生して、しばらくしてから誤検出として解除されるケースが続いています。」という警告文がデカデカと表示されていたので、いつか引っかかるとは思っていましたが、ようやく見ることが出来ました。

■ 後書き

一昔前までは、こいつ(Norton)が原因で、異様にパソコンが遅くなったりと苦労させられましたが、最近は随分と安定してきた気がします。

そのせいで、ごく稀に発生するウィルス対策ソフトに起因する障害対応の初期対応に悩むことがあります。

昔は通信や印刷など動きが妙だと思った時にはウィルス対策ソフトが原因かと早い段階で疑ったものですが、普段意識しない分、これが原因だと思いつくまでの時間が長くなった気がします。

便利なのは良いのですが、それはそれで困ることがあるようです。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end --- スポンサードリンク

PageTop

jarを実行できない(Solaris)【解決!】

■ jar

前回は、Windowsでjarを使う方法を書きました(jarを実行できない(Windows)【解決!】)。

そこで作成したjarファイルをアプリケーションサーバ(Solaris)に転送して解凍しようとしたのですが、ここでも動かない。


jarが実行できない(Solaris) - 1



この時点で、アプリケーションサーバでシステムは動いているのだから、どっかにjarくらい入っていそうな気がします。

環境変数のpathの値を確認(echo $path)して、そこにjarが無いかlsコマンドで確認してみたのですが、想像通り見当たりません。


jarが実行できない(Solaris) - 2



では、どっかにjarが転がっていないか検索(find / -name jar)したのですが、そこそこ入っていました。


jarが実行できない(Solaris) - 3



後は環境変数「path」に値を追加すれば良いだけです。

■ 設定と確認

前回のWindows編では、きちんとシステム全体にパスを通したのですが、正直、Soralisの方は出来るだけ環境を触りたくありません。

なので、ログインしているセッションにだけ環境変数を追加するようにしました(コマンドは、使っているシェルの種類で変わります)。
export PATH=/usr/sbin:/usr/bin:/opt/FJSVawjbk/jdk6/bin/

jarが実行できない(Solaris) - 5

一時的な利用なら、これでOKです。

なお、実際にはシェルの中で実行するので、シェルに環境変数を設定する処理を追加しました。
jarが実行できない(Solaris) - 4

■ 後書き

本当なら、Solarisの環境変数の設定とか、JDKのインストール方法とかをきちんと書いた方が良いのでしょうが、書きません。書かないというか、Solarisは詳しくないので書けないというのが正しいのですが。

きちんと勉強しないといけないのは分かるのですが、ミッションクリティカルなシステムが動いているアプリケーションサーバで実験したくないし。

・・・いや、これは言い訳ですね。

前回:jarを実行できない(Windows)【解決!】

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end --- スポンサードリンク

PageTop

jarを実行できない(Windows)

■ jar

Windowsでjarで圧縮しようとしたのですが、どうも動きません。何故だろうと思ったのですが、PowerShellでjarと入力して実行するとエラーになることから、どうやら環境変数が設定されていないようです。
jarが実行できない(Windows) - 1



jar : 用語 'jar' は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。
名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しいことを確認してから、再試行してください

発生場所 行:1 文字:1
+ jar
+ ‾‾‾
+ CategoryInfo : ObjectNotFound: (jar:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException



jarを使おうと思ったらJDKをインストールするのが筋なのでしょうが、同じ環境でEclipse(pleiades)を使っているので、そっちから引っ張ってくることにしました。

私の場合、場所は「D:¥Eclipse¥java¥6¥bin」でした。
jarが実行できない(Windows) - 2

「システムのプロパティ」を表示(「コントロール パネル」-「システムとセキュリティ」-「システム」)して、「表示」を選択して「環境変数」をクリック。
jarが実行できない(Windows) - 3

システム環境変数の一覧から「Path」を選択して、「編集」をクリック。
jarが実行できない(Windows) - 4

変数値の最後尾に、「;D:¥Eclipse¥java¥6¥bin」を追加入力して「OK」をクリック。
※ 当然ですが、このパスはjar.exeの場所で変わります。
jarが実行できない(Windows) - 5

これで設定は終わりなので、残っている画面は「OK」や「×」で終了します。

■ jar

新たにPowerShellを起動して、jarと入力すると良い感じになりました。
jarが実行できない(Windows) - 6

■ 後書き

敢えてJDKをインストールしなかったのは、Oracle絡みのソフトって妙な動きをするので、出来るだけ入れたくなかったからです。それと、私のパソコンのディスクがSSDのため、ちとディスク容量に不安があったという事情もあります。

jarを使おうとしたのは、Subversionで管理しているjavaのシステムをアプリケーションサーバに配布するためです。javaの配布なので、自然とjarで圧縮しようとしたのですが動かない。

それが、全ての始まりでした。

次回:jarを実行できない(Solaris)【解決!】

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end --- スポンサードリンク

PageTop

EclipseでJava総称型のワーニングの黄色を消したい(java1.4 → java1.6)

■ Javaのバージョンアップ

10年ほど前(2002年〜2006年辺り)に開発したシステムがあります。そのシステムのハード更新が必要になったのですが、使っているアプリケーションサーバがついにJava1.4(JDK1.4と言うべきか)に対応しなくなりました。

ってことで、やむなく1.6に上げることになりました。

■ Eclipseのワーニング

それはそれで良いのですが、Eclipseの設定を弄ってコンパイラー準拠レベルを1.6にしたところ、大量のワーニングが発生しました。
総称型のワーニング対応 - 1

ソースを見てみると、酷い状態になっています。
総称型のワーニング対応 - 2

エラーの内容は、「ArrayList は raw 型です。総称型 ArrayListへの参照は、パラメーター化する必要があります」です。

ちなみに、ほぼ同じエラーがHashMapでも発生しています。こっちは「HashMap は raw 型です。総称型 HashMapへの参照は、パラメーター化する必要があります」ですね。
総称型のワーニング対応 - 3

別に、こっちは必要としていないのですが、それは・・・

私がシステムのお守りを引き継いだ時には結構な数のワーニングが残っていて、それが目障りで頑張って削って綺麗にしてきたので、こうも警告がたくさん出ると心が折れそうです(--;)

理想は総称型とやらに対応するようにソースを書きなおせば良いのでしょうし、個人的にはそうしたいのですが、そんな余力はありません。それに、直さなくても動くのでコストを掛けてまで対応する理由がないのも痛い所です。

しかし、こんな大量のワーニングが出たままだと今後のメンテナンスが辛いです。ってことで、Eclipseの設定を弄って対応することにしました。

■ Eclipseの設定変更

Eclipseではコンパイル時のエラーや警告の表示を変更することが出来ます。その設定は、Eclipse全体に設定する方法と、プロジェクト個別に設定する方法の2通りがあります。

Eclipse自体の設定は、「ウィンドウ」-「設定」を選択。
総称型のワーニング対応 - 4

左側のリストから「Java」-「コンパイラー」-「エラー/警告」を選択して、画面右側で「総称型」を表示。表示されたリストを全て「無視」に変えて、「OK」を選択します。
総称型のワーニング対応 - 5

フル・ビルドの要求が出てきたので、ここで「はい」を選択。
総称型のワーニング対応 - 6

すると、警告件数がグッと少なくなりました!

思う所は色々とあるけど、とりあえずこれで良しとしましょう。

■ プロジェクト個別の設定

複数のプロジェクトを走らせている場合、プロジェクトごとに設定を変えることが出来るようです(まぁ、それが出来ないと複数のシステムを管理している人は困るので、出来て当然なのでしょうが)。

その場合は、プロジェクトを選択した状態で「プロジェクト」-「プロパティー」を選択。
総称型のワーニング対応 - 7

左側のリストから「Javaコンパイラー」-「エラー/警告」を選択して、画面右側で「総称型」を表示。表示されたリストを全て「無視」に変えて、「OK」を選択します。
総称型のワーニング対応 - 8

※ 上記の図では「警告」のままになっていますが、本当は「無視」に変えます。

■ 後書き

ちなみに、Javaのバージョンを1.7とか1.8じゃなくて1.6に留めたのは、移行を依頼したベンダーの希望でした。何でも、実績がないのでトラブル時に対応が厳しいと。

先の事を考えると一気に上げたいのですが、Javaの他にも結構色々と環境を弄るので冒険が出来なかった。それが、ちと心残りです。

さて、この判断が吉と出るか凶と出るか・・・

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end --- スポンサードリンク

PageTop