• 締切済み

Oracle インスタンスの exp について

Oracle9iR2(9.2.0.8) EE を使用しています。(OS は HP-UX 64bit) テストの為、開発環境でインスタンスの定義の exp を行ったところ数分で終了しました。 ところが、いざ本番環境で同様の作業を行ったところ、3時間以上たっても終了しませんでした。 この2環境の差 ・初期化パラメータの差はアーカイブログモードか否か。(本番がアーカイブログモード) ・データ量が本番(150GB程度) >> 開発(30GB程度) 本番環境での exp 中 40MB 程度の dmp を出力するのに 60GB 程度のアーカイブログを出力しており、 event を確認すると log file sync が頻繁に発生していました。 (サイズは中断したので最終的にはもっと増える可能性が有りました。) 作業中 DB アクセスは本 exp のみで他の作業は行っていませんでした。 また、本作業中サーバの vmstat を確認していたのですが、ほぼ常時 idle 80% を占めていました。 disk 上の空容量も十分にある状態でした。 実行した exp のコマンドは下記のとおりです。(開発、本番両環境共) exp system/password@sid file=instance_def.dmp log=instance_def.log full=y compress=n rows=n direct=y 上記 exp コマンドのパフォーマンス劣化を解消する方法についてご教示願います。 インスタンスの設定を no archive log モードに変更する必要が有ったのでしょうか? または、他に何か懸念される設定や、データ量の差等の影響が有りますでしょうか。 よろしくお願いいたします。

  • Oracle
  • 回答数2
  • ありがとう数0

みんなの回答

  • entree
  • ベストアンサー率55% (405/735)
回答No.2

ディスクI/O が遅いとかそんなことはないでしょうか? vmstat, iostat, sar などでexp 中に出力先のディスク・ボリュームの稼働状況 に問題がないかチェックしてみてください。 > 作業中 DB アクセスは本 exp のみで他の作業は行っていませんでした。 No.1 の方が指摘されていますが、それは考えにくいですね。 log file sync が頻繁しているということはトランザクションが存在していることを 意味しているからです。 業務をやっていなかったということであれば、統計情報取得などのバックグラウンド ・ジョブやバッチ処理の実行時間と被っていなかったか確認が必要です。 > インスタンスの設定を no archive log モードに変更する必要が有ったのでしょ > うか? ありません。それよりも、リスナー経由にしなければならない理由があったので しょうか? ローカル接続の方が fork だけで済むのでオーバーヘッドが少ない でしょう。 exp system/password file=instance_def.dmp log=instance_def.log full=y \ compress=n rows=n direct=y

  • muyoshid
  • ベストアンサー率72% (230/318)
回答No.1

こんにちわ。 先ず、exp 時に対象DB をNo Archive Log モードに変更する必要はありません。 > 作業中 DB アクセスは本 exp のみで他の作業は行っていませんでした。 この状態で、3時間で60GB もArchive Log が出力される事は 考えにくいです。 Archive Log はDB 更新が行われている証拠です。 > event を確認すると log file sync が頻繁に発生していました。 これは、Commit/Rollback によるものです。 この事も、exp 以外の処理が行われていた事を示しています。 > exp system/password@sid ・・・ @sid の指定が気になります。 tnsnames.ora の指定によっては、意図しないインスタンスに接続して exp が実行されている可能性があります。

関連するQ&A

  • oracle8.1.6 expのdirectコマンドについて

    Oracle8.1.6でのdmpファイルのエクスポートについて御伺いしたい事があります。 現在、dmpファイルのエクスポート時間の高速化を検討しております。 手法の1つとしてdirectコマンドを用いる方法を考えており、 試した結果は処理時間がおよそ1/3程度まで短縮できました。 directコマンドにてエクスポートしたdmpファイルを再度インポートし、問題無かった所まで確認したのですが1つ疑問点があります。 directコマンドの使用有無によってエクスポートしたdmpファイルのサイズが異なっているのは何が違いなのでしょうか? エクスポートの手法が異なるだけであり、吐き出し情報は相違無いと思っていたので。。 よろしくお願い致します。 EXP ****/****@**** FILE=C:\EXP.DMP FULL=N dmpファイルサイズ=4,345,638(KB) EXP ****/****@**** FILE=C:\EXP.DMP FULL=N DIRECT=Y dmpファイルサイズ=4,318,878(KB)

  • oracle ダンプファイルのサイズとインポート先の表領域の使用サイズ

    oracle ダンプファイルのサイズとインポート先の表領域の使用サイズの関係 あるダンプファイル(2.5GB)をオラクルDBへimportしたら、 そのDBの表領域が10GBほど使用されました。 2.5GBのものをimportしたのに、なぜここまで表領域を消費するのでしょうか? (これまでこのようなことはありませんでした。) 表領域の使用サイズをもっと少なくするにはどうすればよいのでしょうか? エクスポート時のコマンド exp aaaa/aaaa file=bbbb.dmp log=exp_cccc.log consistent=y インポート時のコマンド imp aaaa/aaaa file=bbbb.dmp log=imp_cccc.log エクスポート時に「compress=n」をつけたり、 インポート時に「ignore=y」をつけたりしたのですが、 とくに変化はありませんでした。

  • Exp.exeに指定するparfileパラメータについて

    検索させていただきましたが見つからなかったので質問させていただきます。 表題の件、以下の様にコマンドライン実行したとします。 exp parfile=C:\PARFILE.par --ParFile.par内-- userid=XXX/YYY@DB full=y file=C:\EXPFILE.DMP ----------------- 上記の場合、正しく実行されると思います。 質問は次のパターンの場合、正しく機能するのかという所です。 exp parfile=C:\PARFILE.par full=y file=C:\EXPFILE.DMP --ParFile.par内-- userid=XXX/YYY@DB ----------------- このように、parfileを指定しているにも関わらず別のパラメータをコマンドライン上で一緒に指定する事は可能なのでしょうか? 自分で試す事が出来れば一番良いのですが、手元に環境がなくて困っています。 ご回答よろしくお願いいたします。

  • ORACLEでのexportのbatファイルの記述

    Windows2000ServerでOracle8.1.7を使用しています。 定期的にバックアップを取りたいため、exportを行う Batファイルを以下のように記述しましたが、うまくいきません。 ■batファイル----------------------- exp user/password parfile=EXP.TXT ----------------------------------- ■EXP.TXT owner=owner file=d:\back\exp.dmp log=d:\back\backup.log grants=y indexes=y ----------------------------------- このbatファイルを実行すると、文章ではうまく表現できないのですが 「exp user/password parfile=EXP.TXT」 の部分がDOS窓上で永遠に何行もスクロールしていっこうに コマンドが実行されません。 ただ「exp user/password parfile=EXP.TXT」と dos窓をあけて手入力するときちんと実行されます。 oracle7.3.4でも「exp73」で行えばこのbatファイルで きちんとexportが始まります。 ORACLEというよりはdosの知識かと思われますが どなたか、きちんと実行できる方法を教えてください。

  • EXPORTファイルのINITIAL EXTENTサイズについて

    本番環境で、初期データが100M。将来の増分を見込んでテーブルのSTORAGE句のINITIAL値を500Mに設定。 本番のデータをEXPORTして開発環境に構築したいのですが、開発環境は本番の容量を確保できないので、500Mではなく、実サイズの100MでEXPORTしたものをIMPORTしたいと思っています。 EXPORTコマンドでCOMPRESS=Yにしても、実サイズをINITIALには設定してくれないようです。 どのようにすれば、実サイズ分のEXPORT DMPファイルを作成できますか?

  • oracleのテーブルExportについて

    oracle10gを使用しております。 テーブルに億桁のレコードが登録してある場合、 テーブルExportを行うと時間がかかってしまう&出力dumpファイルが 大きくなってしまうといった弊害があると思うのですが、 テーブルレコードを数万単位に分割してExportすることは可能でしょうか? また、その分割したファイルをImportする際は、Export前と同じく 一つのテーブルでレコードを管理することが可能でしょうか。 大雑把な質問で申し訳ありませんが、宜しくお願いします。 また、今回Export時に使用するコマンドは以下になります。 exp スキーマ名/パスワード constraints=y grants=y indexes=y tables=テーブルA file= テーブルA.dmp log=テーブルA.log

  • oracleのimpdpでORA-39166

    ORALCEのexpdpおよびimpdpの勉強のために自宅環境で操作していたところ、 impdpにてORA-39166(オブジェクトが見つからない)が発生してしまいした。 いろいろ調べてみたのですが、解決に至ってないためお力添えをお願いいたします。 【環境】 OS : linux ※CentOS(64bit) ORALCE11gXE 【やりたいこと】 studyスキーマのTEST1テーブルをexpdpでエクスポート(content=data_only)し、 同じスキーマ内のTEST2テーブルにimpdpにてデータを入れる。 【発生までの操作】 1.expdp system/パスワード@XE directory=test_dir tables=study.TEST1 log=test_exp.log content=data_only 2.impdp system/パスワード@XE directory=test_dir dumpfile=expdat.dmp log=test_imp.log tables=study.TEST2 content=data_only 2の操作をしたタイミングで以下のメッセージ。 ORA-39002: invalid operation ORA-39166: Object STUDY.TEST2 was not found. 【備考】 ・TEST1およびTEST2はまったく同じテーブル構造です。studyユーザで作成してます。 ・STUDY.TEST2は存在します。 (「sqlplus study/パスワード@XE」でログインしdesc TEST2で確認できるため) ・exdpは正常に終了しており、dumpファイルは「expdat.dmp」で作成されています。 以上です。 ご教授のほどよろしくお願いいたします。

  • SVNシェル

    開発環境から本番環境へシェルでデプロイさせたいのですが、概念程度でかまわないので、教えてもらえないでしょうか? 開発環境も本番環境も同じサーバ内です。

  • 開発環境の作り方はどうしたらいいでしょうか?(本番大容量→開発小容量)

    お世話になります。 いい知恵や参考文献などありましたら、ご教授下さい。 開発環境の作り方はどうしたらいいでしょうか? サーバーはSQLServer2005です。 サーバーの用途は基幹系ではなく情報系として使用しており、実績がたくさん入っています。 そして本番環境から開発環境を簡単に作成したいと考えています。 方法として考えられるのはデータベースのコピー(バックアップファイルからの戻し)ですが、 これでは本番環境と同じ容量の開発環境が必要になってしまいます。 開発環境は本番環境よりも容量が小さく、本番環境にはすぐには使わない古い実績も入っているため、 それらは開発環境には必要ありません。 理想としては、データベースのコピーをする際に、オプション機能として、 ●特定のテーブルの件数を指定する。 ●WHETE文(年月が2008/4以降)の条件式を加える。 ができればいいのですが・・・。 何かいい方法はありませんでしょうか? 時間はかけたくないので、30分ほどの準備作業で終わらせたいです。 尚、以下は考えておりません。 ●ソースからテーブルやストアドなどを順に作成して、データを移す。 ●本番環境のデータを開発環境に合わせて絞ってもつ。 ●開発環境を本番環境と同じものにする。 何年もDBを触っていながら素人同然の質問ですが、よろしくお願いします。

  • 内部統制と本番環境

    内部統制について質問です。わたしはECサイトを運営する会社の、情報システム部の ような立場です。先日ある人より、  「運営やリリース作業・障害調査を含め、開発会社が本番環境にアクセスできては   ならない」 と指示されました。 「運営」については納得ですが、「リリース作業」「障害調査」は疑問に思っています。 この指示をそのままうのみにすると、開発会社からソースをもらって、技術に疎い 自社社員がリリース作業を行わなければならくなるかもしれません。ソース置き換え だけならともかく、DB のテーブル構成変更などを慣れない作業者が行うと何が起こるか わかりません。 リリース作業や障害調査など必要な作業を開発会社が本番環境で作業できるように するためには、内部統制をどのようにクリアすればよいのでしょうか。 内部統制には全く詳しくないのですが、ログの取得と管理・情報漏洩を防止する誓約書・ リリース許可書などで対応すればよいのではないかと考えているのですが甘いでしょうか。 なお、開発会社は外部におります。コスト的に社内常駐は困難です。