- PR -

Oracle インポート エクスポート方法について

投稿者投稿内容
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-11-20 19:53
はにまるです。

引用:

小僧さんの書き込み (2004-11-18 22:39) より:
・問題点
A サーバのユーザを Test1 とし、 B サーバのユーザを Test2 とすると、
Test1 の表領域が「USERS」、 Test2 の表領域が「HONBAN」となっている為、
( 使用する表領域が異なる ) インポートが上手くいかない。
→ どうやら、エクスポートしたダンプファイル内に「表領域情報」を持っていて、
自動的にエクスポートした際のユーザの表領域にインポートしようとしているようです。


どの様な状況下でどの様に実行したら、上手くいかないのですか?
また、上手くいかないとはどの様な状況を示しますか?

>「ユーザの表領域にインポートしようとしているようです?」
とは、何故そう思われたのですか?

引用:

小僧さんの書き込み (2004-11-20 11:22) より:
> オブジェクト所有者が違う場合
とありますが、つまり「ユーザが異なる」場合ですよね? ( 違ってたらごめんなさい )
今回はユーザ名も違うのですが、そのユーザが持っている表領域が異なるために
上手くインポート出来ない ( 強制的に「USERS」にインポートしてしまう ) のです。


>ユーザが持っている表領域
ユーザは表領域の所有者にはなれません。
ユーザのデフォルト表領域の事を示していますか?

またデフォルト表領域は自分の目で調べましたか?

引用:

小僧さんの書き込み (2004-11-20 11:22) より:
> MM さん
> サーバーBのユーザーに先に使用する表領域を指定して
> テーブル定義を作成する。
この方法も試したのですが、やはりエクスポートしたユーザが
持っている表領域「USERS」に、強制的にインポートしてしまうようです。
上にも書きましたが、「ignore=y」としても、やはり「USERS」にインポートしていました。


ありえません。
オブジェクトはユーザであるスキーマー毎に一意の名称になります。
もしインポートにより二重作成されたと思っているのであれば、
インポート前と後でオブジェクトの一覧をよく確認して下さい。

引用:

小僧さんの書き込み (2004-11-20 11:22) より:
> きくちゃんさん
> フツーに出来ません?
んー、出来ないと思っているのですが。
コマンドがいけないんでしょうか?
ただ、オラクルに詳しい技術者に聞いた際に
「エクスポートした際、表領域情報も一緒に持っていくので、
異なる表領域にインポート出来ない」と言われました。


これが私にとって一番の疑問であり投稿した本来の理由なのですが、
「オラクルに詳しい技術者」の返答を無視して
何故、掲示板で質問されているのですか?


[ メッセージ編集済み 編集者: はにまる 編集日時 2004-11-20 19:55 ]
小僧
会議室デビュー日: 2004/11/18
投稿数: 7
投稿日時: 2004-11-21 14:25
こんばんわ。
返信、ありがとうございます。
まとめて返信させて頂きます。

> いーたさん
> エクスポートする時にFULLや表領域モードではなく、テーブル単位でエクスポートする。
エクスポートする際に情報を持ってしまうので、ユーザ単位ではなく
テーブル単位で情報を持っているような気がするのですが。
でも、まだ試していないので明日試してみます。
アドバイスありがとうございます。

> はにまるさん
> どの様な状況下でどの様に実行したら、上手くいかないのですか?
どのような状況下、というのが良く分からないのですが・・・
環境を言っていますか?構成を言っていますか?
一応、今までも書いていると思うのですが、繰り返し。
サーバ A のデータエクスポートして、サーバ B にインポートしたい。
ただ、その際サーバ A とサーバ B のユーザのデフォルト表領域名称が異なるため、
エクスポートした際のユーザのデフォルト表領域にインポートしてしまう。

> ユーザのデフォルト表領域の事を示していますか?
言葉が正確ではなくて申し訳ありません。
仰るとおり、「ユーザのデフォルトの表領域」です。

> またデフォルト表領域は自分の目で調べましたか?
自分の環境では調べました。 ( サーバ A の「USERS」 )
相手方の環境は調べていませんが、「USERS」ではない事だけは確かです。 ( サーバ B の「HONBAN」 )

>>> サーバーBのユーザーに先に使用する表領域を指定して
>>> テーブル定義を作成する。
>>この方法も試したのですが、やはりエクスポートしたユーザが
>>持っている表領域「USERS」に、強制的にインポートしてしまうようです。
>>上にも書きましたが、「ignore=y」としても、やはり「USERS」にインポートしていました。
>ありえません。
???
サーバ B のユーザにオブジェクトがない状態で、上記の条件でインポートをすると、出来ました。
なので「二重作成」ではなく、「新規作成」だと思っているのですが。
そして、「ありえません」というのは、「二重作成」が、ですよね?
でしたら、私も「ありえないと思います」という意見です。

> これが私にとって一番の疑問であり投稿した本来の理由なのですが、
> 「オラクルに詳しい技術者」の返答を無視して
> 何故、掲示板で質問されているのですか?
えーと、認識の相違である事を願っているのですが、私がこの掲示板に書き込んだ初期の目的は
-----
・やりたい事
A サーバと B サーバのデータを毎日同期を取る。
同期は夜間、バッチで行うので、処理時間はある程度長くても大丈夫です。
そして、対象は DB の中身全てではなく、ある 1 ユーザのデータのみです。
-----
であって、
エクスポートしたユーザのデフォルト表領域とインポートするユーザのデフォルト表領域が
異なる場合、上手くインポートが出来ない
→これが解決出来ればいいんだけどなぁ
というのは「単なる私の愚痴」です。

なので、「オラクルに詳しい技術者」の返答を無視して投稿しているのではなく、
話の流れ上「表領域の問題があるので、単純インポートは出来ないんですよぉ」という話題が出てきただけです。
( というか私はそう思っています )

後、表領域の問題は、私は「出来ない」と思っているのですが、他の方から「出来る」という
意見もあるようなので、「本当の所はどうなの?出来るの???」と希望を持ちつつ
返信している所もあります。
これで疑問は解決したでしょうか?

長くなってしまいましたが、宜しくお願いいたします。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-11-21 22:30
はにまるです。
私は技術系質問スレッドで頻繁に行われる遣り取りされる形式が
あまり好きでは無いので、他の方のような返答は望まないで下さい。

取敢えず問題解決をしたいならば、
実状と憶測、知っている知識と憶測を別けて話、
実状及び行動した事をそのまま話して下さい。


先に『どの様な状況下でどの様に実行したら、上手くいかないのですか? 』の
質問をした理由を述べると、
この問いは私が小僧さんの技術知識を判断するために行いました。
問題に関連する情報を面倒臭がって書かない人がいるので、
その様な方との切り分けの為、確認させて頂きました。

では本題。

『上手くいかないとはどの様な状況を示しますか? 』の返答が、
引用:

エクスポートした際のユーザのデフォルト表領域にインポートしてしまう。


と仰っていますが、その判断はどうやってやったんですか?
引用:

自分の環境では調べました。 ( サーバ A の「USERS」 )
相手方の環境は調べていませんが、「USERS」ではない事だけは確かです。 ( サーバ B の「HONBAN」 )


と片方で仰ている以上のその発言に信頼性がありません。

私が期待しているのは、
「xxxをしたらログファイルにxxxメッセ−ジが記録されておりxxxにxxxが出来ていました。
 その結果xxxと予測しました。」という返答です。
実状と憶測を別けて欲しいのです。

引用:

>>> サーバーBのユーザーに先に使用する表領域を指定して
>>> テーブル定義を作成する。
>>この方法も試したのですが、やはりエクスポートしたユーザが
>>持っている表領域「USERS」に、強制的にインポートしてしまうようです。
>>上にも書きましたが、「ignore=y」としても、やはり「USERS」にインポートしていました。
>ありえません。
???
サーバ B のユーザにオブジェクトがない状態で、上記の条件でインポートをすると、出来ました。
なので「二重作成」ではなく、「新規作成」だと思っているのですが。
そして、「ありえません」というのは、「二重作成」が、ですよね?
でしたら、私も「ありえないと思います」という意見です。


MMさんの発言は理解しておらず、確認する手段を知らない様ですね。

(1)サーバAとサーバBにて同期を取るテーブルを事前にサーバBの任意の表領域へ
 CREATE TABLE文によって作成します。

# 訂正しました。(誤:テーブルB→正:サーバB)

(2)次にサーバAのダンプファイルをignore=Yオプションを用いてサーバBにインポートします。

とMMさんは仰っているのですよ?
この状態で何が別の表領域(1.の任意の表領域以外)にインポートされるのですか?
テーブル構成無きレコード?表領域を移動する?別名で同一構造が作成される?
って事?

引用:

> またデフォルト表領域は自分の目で調べましたか?
自分の環境では調べました。 ( サーバ A の「USERS」 )
相手方の環境は調べていませんが、「USERS」ではない事だけは確かです。 ( サーバ B の「HONBAN」 )


この発言を再度引用しますが、つまり
小僧さんの受持つ環境はエクスポート側のサーバAであり
インポート側のサーバBでは無いのですね?

様は現状の問題はサーバBの担当者から発言を受けたって事ですか?

引用:

> これが私にとって一番の疑問であり投稿した本来の理由なのですが、
> 「オラクルに詳しい技術者」の返答を無視して
> 何故、掲示板で質問されているのですか?
えーと、認識の相違である事を願っているのですが、私がこの掲示板に書き込んだ初期の目的は


そんな話ではありません、人間性を確認しただけです。
もしここで親切な人が返答をし、それを受けた小僧さんが誤った知識と誤認識で
実行した所、障害が発生した場合に、
「@IT会議室の奴等がこんな事いっていたんですよ〜」と云いかねん人だなと思ったからです。

普通の人間であれば、「質問して疑うなら最初から自分で調べろ!」と思うものです。


イジメテばかりでは何なので結論からいえば、言葉どおり受取れる要件は実現出来ます。
解決したいなら、したいなりの言動する様に心がけましょう。


[ メッセージ編集済み 編集者: はにまる 編集日時 2004-11-22 09:38 ]
せん
ぬし
会議室デビュー日: 2002/03/04
投稿数: 397
投稿日時: 2004-11-22 03:59
# はにまる さんの書き込みとだぶるかもしれませんが、やった事は正確に。
# インポート文をみて、そりゃ出来んわ。と思いました。

「なぜか必ず USERS 表領域へインポートされてしまう件」についての仮説

『Oracle8i ユーティリティ・ガイド』によれば、
デフォルトでは、表は、元の表領域にインポートされる、とのこと。
ですが、以下の場合はインポート対象のユーザのデフォルト表領域が使用されます。

  1. 表領域が存在しない場合
  2. ユーザがその(元の表領域)への十分な権限をもっていない場合
  3. 他にもいろいろ(あとはマニュアル参照)


てなわけで、インポート対象であるユーザの権限がありすぎるのではないでしょうか?
インポート対象である サーバBのユーザから、「USERS」表領域へ書き込めないような
権限の再設定を行なえば、希望するような事が行なえるかとおもいます。
# 詳しい設定は、社内のORACLEに詳しい人に聞いてください。
小僧
会議室デビュー日: 2004/11/18
投稿数: 7
投稿日時: 2004-12-04 10:17
お世話になります。

まず、返信が遅れた事、申し訳なく思います。
掲題の件ですが、前提条件として
「デフォルト表領域が異なるユーザ間でデータをエクスポート、インポートしたい」
というものだったのですが、先方に
「なんでデフォルト表領域が異なるんですか?」と聞いたところ、
「前に作ったユーザが"USERS"以外だったので」との事だったので、
先方システムの DB のユーザのデフォルト表領域を"USERS"に変更して頂きました。
その為、皆様から出してただいた方法を使う場所がなくなってしまいました。

また、本来ならはにまる様、せん様の回答に関する返答をするのが筋ですが、
投稿頂いた内容を検証する時間がありませんでした。

お時間頂いたのにも関わらず、中途半端な結末になってしまい申し訳ありませんでした。
今後とも宜しくお願いいたします。



たけち
会議室デビュー日: 2005/09/26
投稿数: 1
投稿日時: 2005-09-26 23:17
はじめまして。

気になったので今更ながら投稿だけ。(なげやり)

私も同じ様な状況にありました。
私の場合、サーバー、DBは同じです。
スキーマを丸々コピーして別スキーマにしたかったのです。
そして表領域もまた別に管理したい。

ですが、表領域を引き継いでしまう為、
上手くインポートできずに悩んでいましたが、
苦肉の策として、引き継いでくる表領域を一時的に「読み込み専用」にして、
新たにインポートするスキーマのデフォルト表領域へ作らせる
なんて方法を見つけました。

XMLデータのフィールドを持つ場合、
そのテーブルが上手くインポートできない現象が課題としてありますが、
それ以外のテーブルは問題なくインポートできました。

運用していく手段としては、有効ではないですが、
こんな方法もある程度で。

スキルアップ/キャリアアップ(JOB@IT)