Javaを使用してOracleデータポンプを使用しようとしています。Javaを使用してOracleからデータをエクスポートし、同じダンプファイルを取得するにはどうすればよいですか?

指定したパスに expdp ファイルを保存するようにユーザー名とパスを要求するシェル スクリプトが必要です。私を助けてください。以下は私のスクリプトです。

あるサーバーにあるデータベースから、別のサーバーにある別のデータベースにテーブルをエクスポートしたいと考えています。

これが私のセットアップです：

1. Oracle 11g データベース: internal@10.0.0.1
2. Oracle 11g XE: external@10.0.0.50

私が見つけたコマンドは、同じデータベース内のテーブルをエクスポート/インポートするために使用されます:

これを解決する方法に関するアイデアやヒントはありますか?

同様の方法でOracleデータポンプを使用しています：

私の質問は次のとおりです。私のテーブルには 15 行あり、内部にはほとんどデータがありません。ログ ファイルに、毎回数千行がエクスポートされていると表示されるのはなぜですか? エクスポートされた 29000 行以上が表示されます。また、それが作成する湿ったファイルは、クエリを実行するたびに大きくなり続けます。数 KB から開始し、エクスポートを何度も実行した後、500 MB 以上のログファイルを作成するところまで到達しました。それは私にとって合理的ではありません。これは、データのアーカイブなどと関係がありますか? もしそうなら、どうすればそれを止めて、それほど大きなダンプファイルを生成しないようにできますか?

ローカル マシンからリモートの Oracle サーバーに接続し、すべてのテーブルを db スキーマの 1 つに削除しました。ここで、同じリモート マシンにある dmp ファイルを自分のマシンからインポートする必要があります。どうすればそれを達成できますか？

注 - サーバーへの RDC はオプションではありません。

impdp はローカル マシンで使用できないため、使用できません。

助けてください

データ ポンプを使用してダンプ ファイルを同じサーバー上の別の DB_B にインポートしました。サーバーには、ダンプ ファイルと同様の内容を持つ同じ DB_A が既に含まれています。DB_A を使用して次のコマンド (以下) を実行したところ、完全に機能しましたが、DB_B を作成するために使用したときに、最も顕著ないくつかのエラーが発生しました。別の目的で DB_A が必要で、DB_B にも目的がありますが、サーバーが不足しているため、両方を 1 つのサーバーに配置する必要がありました。このエラーにより、DB_A が既に使用している一部のファイルが上書きされることはわかっています。しかし、独自のファイル セットを持ち、DB_A によって共有されていない別の DB_B インスタンスを作成するにはどうすればよいでしょうか? これに関するアドバイスは大歓迎です。ありがとう

インポート コマンド

エラーログ

アップデート

私が望んでいたことに解決策がないとは思いません。このサイトは、私が欲しいものについて何かを説明していることがわかりました。現時点で唯一のオプションは、Oracle データベース 11g 以降をホストする VM を作成し、ダンプ ファイルをその VM にインポートすることです。次に、ネットワーク オプションを構成して、他のユーザーがデータベースを表示できるようにします。このようにして、全体を再マッピングしたり名前を変更したりすることなく、同じテーブルスペース、スキーマ、ユーザーなどを保持できます。このリンクは、DB をインポートできる Oracle DB VM をダウンロードします。提案があればまだ受け付けていますが:)

ORA_ROWSCN 疑似列を使用して、最近変更された行を特定し、選択した詳細を別のデータ ソースにレプリケートします。この列の「おおよその」性質を認識しており、ブロック内の行の 1 つのみが変更された場合、ブロック内の行のバッチ全体が SCN でマークされており、それで問題ありません。誤検知の比較的小さなバッチです。問題ありません。

ただし、「フローティング」ORA_ROWSCN 値を持つように見える多数の行が観察されています。これらは確かにまったく変更されていない何百万もの行ですが、Oracle との新しいコンソール セッションを開始するたびに、行のブロックは毎回最新の SCN を取得します。以下は、数分間の 3 つの個別のコンソール セッションを示しています。

セッション #1 - SCN 27501512の下の 400 万行:

セッション #2 - SCN 27501522の下の 400 万行:

セッション #3 - SCN 27501528の下の 400 万行:

これはテスト データベースであり、行を変更する他のプロセスはありません。私たちの理論では、この 400 万のブロック内の行には、何らかの理由で専用の「SCN」がありません。これらの行は、Oracle Data Pump ツールを使用してこのデータベースに転送されたため、おそらくそれらを含むブロックには適切な SCN がありません。割り当てられた SCN。オラクルは、他に使用可能な値がないため、おそらく現在の SCN 値に対応する、これらの行の可能な限り高い SCN を提供するしかありません。これらの行を UPDATE すると、無意味であっても、400 万の「フローティング」SCN のブロックから移動し、固定 SCN 番号を取得します。残りの行は移動し続けます。

A.これは実際に私たちが見ているものであり、B.おそらくこれがOracle Pumpユーティリティの既知の効果であり、C.これらの行を新しいUPDATEでマークすると、永久に移動することを確認できますか? 「フローティング」SCNから抜けて、問題を解決しますか?

ノート：

1. SCN は正確ではなく、ブロック単位であることはわかっています。

2. 「なぜ代替手段Xを使わないのか」には興味がありません。答え、私たちは他のテクニックを知っており、決定した場合はそれらを使用します。私たちはこの正確な動作を理解しようとしています.