テスト環境構築

質問

いつもお世話になっております。
Cで開発経験が少しある程度＋MySQLを少し触った程度の人間です。
今回実機に搭載されているオラクルのテスト環境を構築するよう仰せつかりました。
しかし、オラクルなど触ったことも無く。周囲にもオラクルに詳しい人がおりません。
現在運用サーバで稼動しているオラクルのデータをそのままそっくりテストサーバへ移行しろとのことです。
調べてみたところ、exp/impで出来るという事はわかりました。
そこで以下の手順で作業を行いました。

1)テスト機(Windows 2003のSP1)へのオラクル(10.2.0.1)インストール

2)データベースコンフィギュレーションアシストよりORCL(実機側のデータベースと同名)の名前でデータベースを作成

3)インスタンスの起動

4)実機よりデータベース全体をエクスポート

5)テストサーバで　4)で取得した情報をインポート

6)エクスポートの時間よりかなり早くインポートが終了

7)テストサーバを再起動するとリソースの大半をオラクルが使用している

8)データベースを確認してみたが、サービス再起動を試みても起動せず。

希望としては、実機と全く同内容のデータをテストサーバに存在させたいのですが、
以上のexp/imp手順では不足していたのでしょうか？
データベースを作成する際のテンプレートは汎用を使用し、サンプルスキーマを作成しませんでした。
汎用ではまずいのでしょうか？
また、ユーザーや表はインポートでは移行されないのでしょうか？

実機の環境もWindows 2003のSP1とオラクル10.2.0.1です。
渡されたマニュアルは『意外と簡単!?Oracle Database　10g』です。
インターネットやこの掲示板でも移行については調べて見ましたが、詳細な部分がわかりませんでした。

勝手がわからず、的外れな質問をしていましたら、申し訳ありません。
周囲の人間に聞いてもわからず困っております。どうか手順や良いサイトなどありましたら、ご教示ください。

回答No.2

pon2pon2 · ベストアンサー

2853のエラーっていうのはよくわからないですが、
ORA-とIMP-かエラーについてたりします？
エラー内容からすると、単にインポート元のオブジェクトが既に存在するから、
インポートできないよっていっているだけのように思われます。

であれば、インポート先のオブジェクトが削除されていれば、
正常にインポートできるってことでないかと推測します。

そもそも、「既に存在している」とかってことは、「存在してても上書き」とかって、
オプション、OEMにありませんでしたでしょうか。
今、手元に実機が無いので確認できないので、なんとも。
「SYSMAN」とかっていっているところを見ると、
「OEM」関連の「SYSAUX」表領域のデータが存在しているところに、
インポートして、こけているような気も。

「存在してても上書き」ってオプションがないなら、
コマンドベースで、
「SYS,SYSTEMか、EXP_FULL_DATABASEIMP_FULL_DATABASE権限のあるユーザー」
でEXPORT,IMPORT実行してみては。
DBFULLの場合、SYSスキーマ以外のものは戻るはずなので、
データファイルはSYSTEM表領域だけあれば、いいはず。

もし、テストできるなら、データファイルをSYSTEMとUNDO、TEMPだけにしてから、
コマンドベースで試してみてはどうでしょう？

お礼

割り込みの仕事があり、お返事が遅くなりまして申し訳ありません。

IMPORT.logを見てみましたら以下のような内容が記載されていました。
本当はファイルをそのままコピペしたいのですが、何分切り離された環境なので使用できません。ですので目に付いたところだけ抜粋します。

*******************************************************************************

マスター表　SYSMAN、IMP_TESTは正常にロード/アンロードされました
SYSMAN.IMP_TESTを起動しています。
ジョブ　SYSMAN.IMP_TESTは致命的なエラーのため13:53:07で停止しました
ジョブIMP_TESTは月曜日、14　9月、2009　13:53で再オープンしました
SYSMAN.IMP_TESTを再起動しました
オブジェクト型DATABASE.EXPORT/TABLESPACEの処理中です
ORA-31684：オブジェクト型TABLESPACE：UNDOTBSTは既に存在しています
ORA-01119：データベースファイルの作成中にエラーが発生しました。
（中略）
ORA-39083：オブジェクト型ROLE_GRANTの作成が次のエラーでしっぱいしました
ORA-01917：ユーザーまたはロール” ”は存在しません

*******************************************************************************

データベースファイルの作成をしようとしているパスにフォルダが無くてオープン出来ない旨が記載されて
いましたので、これからファイルを作成して再度インポートしてみようと思います。
しかし、全くデータがない（つもり）なのに既にオブジェクトが存在して作成されないと言うのが良くわかっていません…。

>そもそも、「既に存在している」とかってことは、「存在してても上書き」とかって、
>オプション、OEMにありませんでしたでしょうか。
この部分がたぶん以下の設定だと思います

>>オブジェクトアクションをチェックし、オブジェクトアクションの項目を置換に設定しました。

インポートする時のユーザーなのですが、ログイン時の接続モードをNORMALに設定せねば、Managerから怒られてしまいます。
SYSやSYSTEMではNORMALではログイン出来ないようで、『意外と簡単な～』のテキストにもSYSMANでログインするように指示があったのですが、
SYSMANだとまずいのでしょうか？（すみません、その辺りからわかっておりません。）

お手数おかけいたしますが、ご教示よろしくお願いいたします。

回答No.8

pon2pon2

参考までに、
なぜ、「dba_free_space」
を確認するようにいったかというと、
「（「DBA_FREE_SPACE最大BLOCK_ID」- 1) × 8K」
がデータファイルのResize可能サイズなので。
(8Kは初期化パラメータのブロックサイズと同じ値を随時設定）。

上記で出した値をMBにして以下を実行すれば、
alter database datafile 'x:\xxxx\xxxx.dbf' resize xxM;
データファイルの縮小が可能なので、
あまり大きくなりすぎてたら、縮小（DatafileのResize）もいいかと
思ったので。

お礼

ご連絡が遅くなり申し訳ありません。
ao108の代理のものです。本人が交通事故に遭い、ようやく意識を取り戻したところです。
まだまだ復帰には時間がかかりますので、本人よりお礼と共に、必要であれば改めて質問させてくださいとのことでした。

お手数かけ、申し訳ありませんが、このような状況ですので一旦質問を締め切らせていただきたいと思います。
ありがとうございました。

回答No.7

pon2pon2

SYSAUXには、AWRなどの履歴情報などが入っています。
ただ最初は情報量もすくないので少なくて問題ありません。
これから徐々に増加していきます。
----------------------------------------------------------
大きくなった表領域ですが、
表領域中のセグメント情報（表とかINDEX)の数と
セグメント（表やINDEX）ごとのサイズを確認されましたでしょうか。
select SEGMENT_NAME,TABLESPACE_NAME,BYTES from dba_segments
where TABLESPACE_NAME = 'xxxx'　order by BYTES;
比較しないとどの表やIndexが大きくなったのか、また、
不要な表がImportされていないかわからないですよね。

もしかすると、Dropしたテーブルとかもそのままインポートされてたり
するかもしれませんね。
一度、どんな表やINDEXが存在するのか、違いのあるセグメントは
どれかを比較するとよいかと思います。
----------------------------------------------------------
「ORA-00942」ということは、「dba_free_space」表が見つからないってことですね。
多分、スキーマの問題なのでは。
「as sysdba」権限つけて（connect / as sysdbaとか）
実施してみたらどうでしょ？
普通の一般スキーマ（DBユーザー）からは、権限ふらないと、
自分の所有していない表は見えないので。
試してみるとよいかと。
----------------------------------------------------------

回答No.6

pon2pon2

できれば、最初に大きいデータファイルを用意しておくのはなく、
想定容量のデータファイルと、
それ以上に大きくなった場合用に、1GBで自動拡張ON、MAX32GBのファイルを
いくつか用意しておくと、実際どの程度のファイルが必要だったのか
わかりやすいのではないかと思いますが、
もうインポート済みで、再度実施するのは大変だと思いますので、

まずは、
表領域の使用サイズは？
各データファイルのHWMまでの値は？
セグメント単位で、移動元と移動先を比較して、どのセグメントが
どれだけ使用するようになったのかを確認すると、
問題切り分けできるのではないかと。

■表領域の使用サイズ
----------------------------------
select b.file_id,b.tablespace_name,b.bytes,
(b.bytes - sum(nvl(a.bytes,0))) "#used",
sum(nvl(a.bytes,0)) "#free"
from sys.dba_free_space a, sys.dba_data_files b
where a.file_id(+) = b.file_id
group by b.tablespace_name, b.file_id, b.bytes
order by b.tablespace_name;
----------------------------------

■セグメントごとのサイズ
----------------------------------
select SEGMENT_NAME,TABLESPACE_NAME,BYTES from dba_segments
where TABLESPACE_NAME = 'xxxx'　order by BYTES;
----------------------------------

■HWMまでの使用サイズ
----------------------------------
select * from dba_free_space where tablespace_name = 'xxxx';
----------------------------------

お礼

毎回ご丁寧にありがとうございます。
確認してみたところ、SYSAUXが元環境のサイズが432.7MBに対し、新環境が291.4MBでした。
また、ある表領域が元環境のサイズが704MBに対し、新環境が1679MBとなり、大きく違っております。
大きく違っていたのはこの2箇所のみでした。

HWMまでの使用サイズは
select * from dba_free_space where tablespace_name = '表領域名';
で、宜しいですか？表領域の所有ユーザで何度もやってみたのですが、ORA-00942が表示されてしまいます。

※数日経ってからインスタンスを起動させてみたら、起動しました。
　書き込みした際は、何度起動させても失敗していたのですが。
　現在は可用性100％が続いています。

テスト環境を作るよう指示された時は、入れ物を作ってそこにデータをドンと入れてしまえば良いと簡単に考えていたのですが、やはりオラクルはそう簡単にはいかないのですね…。

回答No.5

lond_nag

>ユーザー(の情報が格納されている部分？)はインポートされないってことなのでしょうか。

その通りです。スキーマ・表単位だと仰っている意味のユーザ情報はインポートされません。

難易度が下がるかどうかは一概には言えない部分もあります。
それは、インポートされない部分（ユーザの情報・・権限やDB自体の例えばデータファイル配置等）の設定が必須の場合、そこを自分の作業で実施しなければいけなくなるからです。
ただ、少なくとも全体でインポートするとき実施されてしまう表領域の情報、データファイルの再利用等、DBのシステムに関わる部分が無くなり、ユーザとか表とかいうレベルの部分に影響が限定されるので、

>今現在、インポートに失敗するとその後ORCLのデータベースが立ち上がらなくなります。

で、再インストールを繰り返す・・というようなところは回避出来るかと思ってのコメントでした。
ちなみに

>確認してみると、リスナーと接続がうまくいかなくなっているようではあるのですが。

については、インスタンス（DB）とリスナーはプロセス的に全く別なので、リスナーとの通信が上手くいかないからと言ってDBが立ち上がらない、ということでは無いと思います。
リスナーが落ちていてもDBは起動します。

もしかしたらDBは起動しているけどリスナーの問題でつながらない、ということなのか・・

>データベースが立ち上がらなくなります。

というのは、どういう操作・現象でアラートLOGの起動失敗時の記録はどうなっているんでしょうか？

お礼

遅くなりまして申し訳ありません。

補足に書き込みした、環境を全て削除し、DBの構築から再度おこなってみました。
その際、ユーザーと表領域を作成し、スキーム毎のインポートにしたところ、成功いたしました。
しかし、java.long.Exception:IOException～と言うエラーが出て、インスタンスの起動が失敗すると言う状況になっております。

以前の手順の際のエラーも気になりますが、スキーム毎にしたことによって、格段にエラーが減ったのは良いのですが。何故インスタンスが繋がらないのかわかりません…。

補足

ご丁寧にありがとうございます。
回避できるようにと教えていただいた手法を用いず、回避できていなくて申し訳ありません。
これからまた外出せねばならないので現在の状況だけお知らせしたいと思います。

・フォルダにアクセスできないため、インポート出来なかったようなので該当箇所にフォルダを作成後データベース全体のインポート実施
・エラーは発生したものの、インポートは完了した
　（PLS-00302　コンポーネントOPERATOR_NONFを宣言してください）
　（PLS-00201　識別子SYS.DBMS_DEFER_IMPORT_INTERNALを宣言してください　等）
・元データにあったユーザがインポート先のユーザー一覧から確認できる。
・インポート後はCPU使用率が100％となる(oracleで90％くらい占有しています)
・仮想メモリーを大量に消費していると警告が出る
　（ホストオペレーティングシステムに大量のページングが発生しています）
・java.long.Exception:No Such Targetと表示される
・Oracleホーム・ターゲットの欄が「ターゲットが見つかりません」となっている。
　（正常なものはホームターゲット欄にリスナーなどの情報が記載されている）

状況のみのご報告で申し訳ありません。
戻りましたら、再度確認させていただきます。よろしくお願いいたします。

回答No.4

lond_nag

エラーと内容に関してはpon2pon2さんの意見と大体同じですが、ちょっと説明の敷居が高そうなので補足を。
（但し、私も詳細が判らないのとEnterprise Manager使わないので参考ですが）
ORACLEにはエクスポート,インポートにそれぞれ全体、スキーマ（ユーザ単位、と考えましょう）、表単位、表領域単位の４つのモードがあり（Data Pump Exportは５つですが）、
表領域を除いて基本的に今、表記した順で左のモードは右のモードのデータを内包してます。だから全体でエクスポートされていればユーザ単位でも表単位でもインポート出来ます。

で、取り込みたい表の、元のDBの持ち主（ユーザ）はSYSとかSYSTEMユーザじゃない、という前提が成り立つなら、「データベースコンフィギュレーションアシスト」で作ったDBに
インポート用または元のDBの持ち主と同じ名前でインポート権限があるユーザを作って、スキーマ（ユーザ単位）モードでインポートすることをオススメします。
新規に作ったユーザなら、何も持ってないから、重複エラーも無いでしょうしね。失敗したらユーザの持っているオブジェクトごとCASCADEオプション使ってユーザを消したり、
作り直したり出来ますしね。
この場合、汎用とかサンプルスキーマとかいう話ではなく、インポート権限や表・索引領域のDisk配置、サイジングといったところがデータ量によって性能に大きなインパクト
を与える可能性があります。また、これはデータ（表）とその表を持っているユーザのオブジェクトだけに関する話です。
テスト環境、と仰っているのでデータだけ、というわけでもないのかも知れませんが。あ、ちなみに全く違うユーザに取り込んでも、シノニム（別名）付けてやれば環境合わせることは
可能です。まぁその場合はいろいろ権限が絡むので敷居が高くなっちゃいますけど、上手く使えばデータ環境の切替やセキュリティの実装に役だったりします。
もしかしたらEnterprise Managerでその辺りを考慮した手順があるかもしれません。・・・あまり参考にならなかったらごめんなさい、ってことで。

お礼

仰るとおり、オラクルに関する記事はどれを見ても私には敷居が高く、頭が混乱しておりました。
丁寧にご説明いただきありがとうございます。
ユーザーを作ってからスキーマモードでのインポートということは、やはりユーザー(の情報が格納されている部分？)はインポートされないってことなのでしょうか。
単にその方が難易度が下がりますよってことでしょうか。

今現在、インポートに失敗するとその後ORCLのデータベースが立ち上がらなくなります。
確認してみると、リスナーと接続がうまくいかなくなっているようではあるのですが。
何故インポート出来ていないはずなのに、他の所に不具合が生じるのでしょうか…。

回答No.3

pon2pon2

もし、実機と同じSID、同じファイル構成でってことなら、
COLD BACKUPとって、
普通に同じSIDでDBCAで同じ名前のDBを作成したら、
（サービスは作成しておく必要があるので。）

で、作成後、いったん停止して、
COLDBACKUPとっておいたファイル
（制御ファイル、初期パラ、各種データファイル、
　名前あわせるのが面倒なので、REDOやTEMP、UNDOも）
どんと、戻して起動した方が早いような気もするような。

ま、ディレクトリ構成やらディスク配置が違うなら、
制御ファイルいじらないといけないので、
あまり、詳しくないのなら、EXPORT,IMPORTの方がいいかもしれません。

お礼

SIDは同じものにしておりますし、構成も特に指定がないのでその方法でも問題は無いのと思うのですが、
現在COLD BACKUPをとるのが難しい状況です。
簡単な方法で出来るのが一番良いのですが…。

回答No.1

pon2pon2

インポート時にlog=xx.logってつけてインポート実施してますでしょうか？
log=xx.logで指定したインポート時のログに、エラーは出てませんでしょうか？
インポートの権限のあるユーザSYSとかSYSTEMで実行してますでしょうか？
まず、このあたりから調査でしょうか。

お礼

お返事ありがとうございます。

実機でエクスポートしたファイルを、一度テストサーバの方へコピーし、
Enterprise Managerのファイルからインポートを利用してインポートしました。
コピーしたファイルを指定し、インポートオプションの画面でもインポート対象を『すべて』、オブジェクトアクションをチェックし、オブジェクトアクションの項目を置換に設定しました。

インポート時のログには2853のエラーが出ています。
そのほとんどが、『オブジェクト型TYPE～が既に存在しています』というものと、『表SYSMAN～が存在します』というものでした。
あまりにもエラーが出るため、そもそもの手順が間違っているのかと思い、お聞きした次第です。

インポートはSYSMANで実行しました。