- PR -

Oracleのインポートエクスポート

1
投稿者投稿内容
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2005-07-19 11:40
環境：
[マシンA]
　Solaris9
　Oracle9i

[マシンB]
　Solaris9
　Oracle9i

私のOracle知識は初級程度です。

前提：
・マシンA,B上のOracleには既にスキーマ・テーブルが構築されている
・マシンA,B上のOracleの差異はデータの量だけである。
　# ある時期までマシンAを使用していたが、ある時期からマシンBを使っている

経緯：
　今回、マシンBのOracleからマシンAのOracleへデータを同期することになった。

質問：
　マシンBからマシンAへのデータ移行でimp,expユーティリティを使用としようと
　考えています。その際、以下の方法で行おうと思うのですが注意点などはありま
　すでしょうか。

　1.スキーマごっそりエクスポート
　　exp ***/*** direct=y owner=*** statistics=none file=***.dmp log=***.log

　2.スキーマごっそりインポート
　　imp ***/*** fromuser=*** touser=*** ignore=y statistics=none file=***.dmp log=***.log

　現運用環境で使用しているオブジェクトには以下のようなものがあります。
　・テーブル/インデックス
　・シーケンス
　・プロシージャ
　・ファンクション

　【疑問点】
　　・上記方法(exp,imp)で行う場合、既存テーブルが既にあり、かつ何らか
　　　のデータも格納されている場合、データはimpによって上書きされるで
　　　しょうか？
　　　# Oracle9iユーティリティガイドを参照しましたが、ignore=yでオブジ
　　　# ェクト作成エラーを無視すると記述されていますが既にオブジェクト
　　　# があった場合、データ自体は上書きされるのでしょうか。無視だから
　　　# 何もしないのでしょうか。

　　・テーブル同様、シーケンス・プロシージャ・ファンクションなども上書
　　　きされるでしょうか？
　　　# 上記同様に上書きされない？

　　・このようなやり方の場合、注意せねばならない観点などはありますでしょ
　　　うか？
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2005-07-19 11:54
自己レス。

投稿してから掲示板を検索しました。。

http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=15525&forum=26

どうやら、imp,expで簡単には行かないようですね。
ユーザ単位でdrop,createしてから、インポートする方が確実なのでしょうか。
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2005-07-19 11:56
確か私の記憶では・・・
引用:

(株)ぽちさんの書き込み (2005-07-19 11:40) より:
　【疑問点】
　　・上記方法(exp,imp)で行う場合、既存テーブルが既にあり、かつ何らか
　　　のデータも格納されている場合、データはimpによって上書きされるで
　　　しょうか？
　　　# Oracle9iユーティリティガイドを参照しましたが、ignore=yでオブジ
　　　# ェクト作成エラーを無視すると記述されていますが既にオブジェクト
　　　# があった場合、データ自体は上書きされるのでしょうか。無視だから
　　　# 何もしないのでしょうか。
引用:

テーブルの構成は上書きされない。データは一意制約エラーなど、データ書き込み時にエラーにならない限り追加される。既存のデータを上書きするわけではないので注意。ただし、エラーを出しながら動作させると遅いので、現実的に出来るかどうかはデータ量やエラーの量と相談することになるかと。

　　・テーブル同様、シーケンス・プロシージャ・ファンクションなども上書
　　　きされるでしょうか？
　　　# 上記同様に上書きされない？

上記同様、上書きされないはず。
引用:

　　・このようなやり方の場合、注意せねばならない観点などはありますでしょ
　　　うか？

とりあえず、試験環境作って試すぐらいのことはしようぜ。

素直にマシンAのスキーマを削除してからimpじゃ駄目なのか？
同期する(マシンBと同じ状態にする)のであれば、削除してからimpした方が確実だと思うのだけど。
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2005-07-19 11:58


[ メッセージ編集済み 編集者: 甕星 編集日時 2005-07-19 12:00 ]
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2005-07-19 13:18
ありがとうございます。

やはりユーザ削除からが一番手っ取り早そうですか。


その際、どこからやりなおさなければならないか、なのですが。

例えば、ユーザをcreateする時には以下を指定しています。
・default tablespace
・temporary tablespace
・grant

これらの設定に関してはエクスポートで得たdmpファイルを
インポートした時点で継承されるものなのでしょうか。



＊検証環境はあるにはあるのですが（というかターゲットと
している環境が検証環境）、これもお客様環境ゆえ(使ってる)
ある程度確信を得てからやりたいと思いまして。。

他に環境がないというのも問題なのですが。
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2005-07-19 16:08
調査していたら、実はOracleローカル検証環境があった
(windowsですが)ということが判明し、さきほどやって
みました。

1.旧DB export
2.drop user(cascade付き)
3.create user (テーブルスペース指定とか本来の状態で)
　# 考えてみれば、テーブルスペース指定などはユーザ作成の
　# 一環であり当たり前ですよね。。
4.新DB import

見かけうまく行っているように見えます。

ただ、このローカル検証環境、DBだけあってアプリがないので
動作試験までできないのですが。。

上記手順で、「それやばくない？」というものがありましたら
お願いします。とりあえず現状これで行ってみようと思います。
せん
ぬし
会議室デビュー日: 2002/03/04
投稿数: 397
投稿日時: 2005-07-19 22:28
  • DBの構成にもよりますが、コピー元のDBにおいて、データの増加により
    表領域のデータファイル追加は行なっていないでしょうか。
    もし、行なっているのであればインポート前にコピー先での追加作業が必要と思われます。
  • DBの構成と、データ量にもよりますが、インポート時に commit=y を付けると
    早くなるかもしれません。
  • 大前提を覆すようですが、コピー元のコールドバックアップをそのまま、
    コピー先へ持っていけば、何も考えずにデータの同期は可能です。
    もちろん、条件として、
    　　　コピー元が停止できること
    　　　コピー元、コピー先が全く同一の構成であること
    が必須ですが。
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2005-07-20 11:34
引用:

せんさんの書き込み (2005-07-19 22:28) より:
  • DBの構成にもよりますが、コピー元のDBにおいて、データの増加により
    表領域のデータファイル追加は行なっていないでしょうか。
    もし、行なっているのであればインポート前にコピー先での追加作業が必要と思われます。
  • DBの構成と、データ量にもよりますが、インポート時に commit=y を付けると
    早くなるかもしれません。
  • 大前提を覆すようですが、コピー元のコールドバックアップをそのまま、
    コピー先へ持っていけば、何も考えずにデータの同期は可能です。
    もちろん、条件として、
    　　　コピー元が停止できること
    　　　コピー元、コピー先が全く同一の構成であること
    が必須ですが。



ありがとうございます。

知識もあまりないもので、これから調べつつやっていきます。

その中で、まず

・表領域のデータファイル追加

とは具体的に言うと、テーブルスペース指定時にAUTOEXTENDをONに
している場合に発生する自動拡張のことを指しているのでしょうか？
その場合、検証環境ではAUTOEXTEND OFFでいっぱいいっぱい容量を
確保し運用していますので、大丈夫かと思われます。

・コピー元のコールドバックアップ

こちらについては、初めて聞く言葉ですので、これから調べたいと
思います。お手軽そうでしたら、こっちの解もアリかと思います。
1

スキルアップ／キャリアアップ（JOB@IT）