IT系会社員がビリヤードA級を目指すブログ

自分がこのエラーを見た状況
・Oracleバージョン：8.1.7.0.0
・OS：Windows2000Server
・エクスポート時に発生

このエラーは、共有メモリが足りなかったり断片化してしまうことにより、連続したメモリ空間が確保出来ない場合に発生する模様。

対応１：
以下のSQLコマンドにて共有メモリをクリアしてから再実行

ALTER SYSTEM FLUSH SHARED_POOL;

これでエラーが回避されればベスト…なのかな？
細かく様子を見るのであれば、共有メモリの空き容量をチェックする必要もあるかと思います。ので、SQL置いときます。

SELECT POOL,NAME,BYTES FROM V$SGASTAT WHERE NAME='free memory' AND POOL='shared pool';

これを共有メモリのクリア前とクリア後に実行すると様子が分かりやすいかと。


対応２：
SHARED_POOL_SIZE初期化パラメータを大きくする

この対応しようにも物理メモリのサイズには限界があるので、出来る場合と出来ない場合があります。


対応番外編：今回のエクスポート時に取った手段
対応１では解決出来ず、メモリをいっぱいに使っていたため対応２は実施すら出来ずだったので、今回はユーザーごとにエクスポートを行いました。
というか、データ自体を持ってるのは１ユーザーだけだったので、１人分だけエクスポート。

作業自体を細かく分けられるのであれば、分けて実行してみるのも手かも知れません。

自分がこのトラブルにあった状況
Oracleバージョン：8.1.7.0.0
OS：Windows2000Server

症状：
・定期メンテナンスでサーバーを再起動したところ、DBが起動しなくなった
・今まで何度も再起動していたが、その時は問題なかった
・Windows上でのサービスは起動している
・アラートファイル(BACKGROUND_DUMP_DESTで指定)には記述なし
・OraDim.LOG(デフォルトでは%ORACLE_HOME%/database/)には
　ORA-12640: 認証アダプタの初期化に失敗しました。
　ORA-12638: 資格証明の取出しに失敗しました。
　の二種類の記述有り
　※ORA-12640は大量に、ORA-12638はサーバー再起動の時間に発生した模様
・サーバーの再起動していたらなんか動き始めた！

このトラブルは、認証まわりが原因のようです。
sqlnet.oraファイル(%ORACLE_HOME%/network/admin/)にて

SQLNET.AUTHENTICATION_SERVICES=(NTS)

となっていて、OSへのログインをドメインユーザーで行った場合に起こりうる問題だそうです。
SQLNET.AUTHENTICATION_SERVICES=(NTS)はWindowsNT固有のOS認証を使用するという設定です。
このとき、通常であれば

　OS起動→Windowsログイン→Oracleサービス起動→認証→DB起動

となるのですが、ドメインユーザーを使用していると、稀に

　OS起動→Windowsログインに時間がかかる→→→→→→→→↓
　　　↓→Oracleサービス起動→認証したいが間に合わない→→DB起動してない！

となる場合があるようです。
この場合、OS認証が出来ずに止まっているだけなので、SQL*Plus等からSTARTUPコマンドを実行してあげれば起動します。

対応としては、

・発生する度に手動でSTARTUPコマンド
・SQLNET.AUTHENTICATION_SERVICES=(NONE)として認証なしに設定
・Oracleサービスの開始を手動にし、Windows起動後に
　net start OracleServiceORCL
　srvctl start ORCL
　と記述したバッチファイルを実行するようにタスクを組む

の三パターンになるんじゃないかと。
毎回STARTUPは面倒なので、まずは認証無しに設定し、それでも引っかかることがあるようならバッチファイルの実行タスクを設定すればいいのかな。

自分がこのエラーを見た状況
・Oracleバージョン：8.1.7.0.0
・OS：Windows2000Server
・データのインポート時に発生
・該当テーブルにLONG型の列は存在しない

このエラー、どうやらインポートよりもエクスポートの問題の様です。

EXP XXX/YYY@ZZZ DIRECT=Y FILE=oraora.dmp OWNER=ORE

といった感じでエクスポートしていたのですが、該当テーブルの1レコード当たりのサイズが大きすぎて、インポート時のSQLがデフォルトのバッファサイズ(4KB)に収まらなかったようです。
ここで自分の取った手段

EXP XXX/YYY@ZZZ DIRECT=Y BUFFER=200000000 FILE=oraora.dmp OWNER=ORE

これでもエラー。当然です。
BUFFERオプションは従来型パス(指定なし、もしくはDIRECT=Nを指定)を使用した場合のバッファサイズの変更オプションなのですから。
ダイレクトパスロードを使用した場合(DIRECT=Yを指定)のバッファサイズの変更はRECORDLENGTHオプションになります。

この為、今回の正解としては

EXP XXX/YYY@ZZZ DIRECT=Y RECORDLENGTH=200000000 FILE=oraora.dmp OWNER=ORE
EXP XXX/YYY@ZZZ DIRECT=N BUFFER=200000000 FILE=oraora.dmp OWNER=ORE
EXP XXX/YYY@ZZZ BUFFER=200000000 FILE=oraora.dmp OWNER=ORE

この三種類になります。三種類のうち上二種類は実際にExp/Imp確認しました。
動かしてみた限りでは、インポートコマンドには最小限のオプションだけでいいようです。

IMP XXX/YYY@ZZZ FILE=oraora.dmp FROMUSER=ORE TOUSER=OMAE

これでDIRECTオプションの有無に関わらずインポート出来ました。


※ORACLEによると、バッファサイズが大きすぎても同じような問題が発生する為、入力バッファサイズを段階的に上げて下さい、となっております。一応、ご注意を。