環境
OS:RHELRedHatEnterpriseLinux AS 4.0 EM64T
Oracle:10gR2 SE-RAC
記憶域:ストレージ上のLUNでOCR/Voting/Data領域を分けた

現象
1)preroot.sh実行時に以下のように表示される
　# /hogehoge/clusterware/rootpre/rootpre.sh
　No OraCM running
　
2)root.sh実行時に以下のWARNINGが表示される
　# /opt/app/oracle/product/10.2.0/crs/root.sh
　WARNING: directory '/opt/app/oracle/product/10.2.0' is not owned by root
　WARNING: directory '/opt/app/oracle/product' is not owned by root
　WARNING: directory '/opt/app/oracle' is not owned by root
　WARNING: directory '/opt/app' is not owned by root
　
3)root.sh実行時に以下で止まる
　Checking to see if Oracle CRS stack is already configured
　/etc/oracle does not exist. Creating it now.
　Setting the permissions on OCR backup directory
　Setting up NS directories
　Failed to upgrade Oracle Cluster Registry configuration

原因
1)OraCMについて
OraCMとはOracle9iにおけるクラスタプロセスなので、「No OraCM running」と表示されるのが正常。

2)表示されたWARNINGについて
単純にrootの所有物じゃないと言っているだけです。（見れば分かるか）
通常、rootの所有物でなくてもrootは全権限を持ってるはず。なんで、別に問題なし。
というか、大抵の場合は所有者をoracleとかに変更してるだろうから仕方ないっちゃ仕方ないのかも？

3)OCRのアップグレードに失敗したとのメッセージについて
これが一番やっかいでした。
なにせ情報が少ない！日本語ではほとんど情報がなく、英語サイトでどうにか1件BugNoの乗っている情報を発見しただけでしたもの。
んでエラーについてですが、ocrconfig_xxxxx.logを見ると、以下の記述がありました。

　[ OCRCONF][2538045120]csetskgfrblock0: clsfmt returned with error [4].
　[ OCRCONF][2538045120]Failure in setting block0 [-1]
　[ OCRCONF][2538045120]OCR block 0 is not set !
　[ OCRCONF][2538045120]Exiting [status=failed]...

clsfmtがエラーを返してるのが分かると思います。
Oracleバージョン10.2.0.1のclsfmtは、ディスクの一番初めの部分から書き込みを行おうとするようです。
で、書き込みできない場合上記エラーが発生するようです。
なので、以下の環境ではエラーが発生する場合があります。

・ストレージとの接続がマルチパス設定の場合
　この場合、マルチパス設定時に構成されるSuperblockが邪魔になる場合があるようです
　
・マルチパス構成でなくても、ディスクがLUNで分けられている場合
　この場合、ディスクヘッダ部分が邪魔になる場合があるようです

なので、マルチパスが原因でない場合は、LUNで分けるのでなくパーティションで分けると回避出来る可能性が高いのかな？
マルチパスが原因の場合、clsfmtの差し替えが必要っぽいです。
10.2.0.3では対応されているようですが、インストール時にPSRからのファイル差し替えは難しいと思います。
ので、metalink上に対応パッチ（というか差し替えclsfmt）がありますので、ダウンロードして差し替えすることになります。（Bug#4679769･･･あれ？Patch#4679769？）


>日本オラクル様
Metalink情報に触れてしまっているので、もし上記の情報の掲載がまずいようであれば削除致しますので、その場合はコメント等にでも御連絡頂けますよう宜しくお願い致します。

【OCR領域の作成に失敗】
まず一つ目、OCR領域の作成に失敗しました。
インストールログでは、なにかのプロセスのSTEP5で停止していた記憶があります。

OS：Windows2003
環境：Oracle10gR2 SE-RAC
インストールユーザ：ネットワークADMINユーザ

この原因は、恐らくネットワークADMINユーザがDiskマネージャにアクセスする権限を持たなかった為だと思われます。
発生した時には、ローカルADMINでインストール完了させました。

その後分かったのですが、ネットワークADMINグループがローカルのAdministratorsに追加されていても、ユーザ個別に追加されていないとDiskマネージャが開けないようです。（場合によるかも）

なので、ユーザを個別にローカルのAdministratorsグループに追加してやれば良さそうです。
ただし、混乱を避けるのであれば全てのインストールが完了してからドメイン参加・ユーザ追加等する方がいいようです。
理由は次の二つ目のエラーが発生するかもしれないから。


【EVMServiceの起動に失敗】
二つ目、インストール途中でのEVMServiceの起動に失敗しました。

OS：Windows2003
環境：Oracle10gR2 SE-RAC

インストールユーザはローカルもネットワークも試しましたが、どちらも発生。

調べてみると、コンピュータ名に「.」が入っているとインストール時にエラー発生するようです。
で、ドメイン参加するとフルコンピュータ名が「Computer.kaisya.co.jp」とかになるので、そのせいか？と思いサフィックス（フルコンピュータ名の.kaisya.co.jpの部分)を空欄に設定したらインストールできました。

でも、このときに確か他の対策も一緒にやったんですよね・・・そっちの可能性も捨て切れません。

これと同じようにサフィックスの設定で切り抜けてもいいですが、ドメイン参加はインストール終わってからにした方が無難そうです。

かれこれ一月以上前に設定したもの（ここ参照）なのですが、今更気づきました。

EXP XXX/YYY@ZZZ DIRECT=N BUFFER=200000000 FILE=oraora.dmp OWNER=ORE

なら問題は無いんだけど、

EXP XXX/YYY@ZZZ DIRECT=Y RECORDLENGTH=200000000 FILE=oraora.dmp OWNER=ORE

これはOUT（というか修正される）ということが発覚。
これ実行すると、"RECORDLENGTHは65535に切り捨てられます"とかいうメッセージが出てました。

ので、DIRECT=Yオプションを付ける時はRECORDLENGTHは65535以下にしましょう。
なわけで、

EXP XXX/YYY@ZZZ DIRECT=Y RECORDLENGTH=65535 FILE=oraora.dmp OWNER=ORE

とするのが正しかったようです。

すぐ忘れてしまうので。

SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

今回はこんな感じでやってみます。

移行元
Enterprise上AdventureWorks
移行先
Express上

方法１・BACKUP→RESTORE

バックアップコマンドはこんな感じ

osql -U sa -P password -S Enterprise
BACKUP DATABASE AdventureWorks
TO DISK='C:\backup\AdventureWorks.bak'
GO

んで、作成されたAdventureWorks.bakを移行先のサーバへ移動して

osql -U sa -P password -S Express
RESTORE DATABASE AdventureWorks
FROM DISK='C:\backup\AdventureWorks.bak'
GO

これで！と思ったら、エラー。メッセージを見ると、どうもディレクトリ構造が異なるせいらしい。
というのも、Express側には何度もインスタンス作成していたので＾＾；
（MSSQL.5まであった笑）
移行元と移行先のディレクトリ構造が同じなら上のコマンドでOKなはずです。

んで、ディレクトリ構造を変更するのにMOVE句を使用するのだけど、論理ファイル名と物理ファイル名の両方が必要になります。そこで、

RESTORE FILELISTONLY
FROM DISK='C:\backup\AdventureWorks.bak'
GO

と叩きました。これでLogicalNameとPhysicalName両方が表示されます。
論理ファイル名がAdventureWorks_DataとAdventureWorks_Log、物理ファイル名がAdventureWorks.mdfとAdventureWorks.ldfと分かったので、MOVE句を追加して再度RESTOREコマンドを叩いてみます。

RESTORE DATABASE AdventureWorks
FROM DISK='C:\backup\AdventureWorks.bak'
WITH MOVE 'AdventureWorks_Data' TO 'C:\Program Files\Microsoft SQL Server\MSSQL.5\MSSQL\Data\AdventureWorks.mdf'
, MOVE 'AdventureWorks_Log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL.5\MSSQL\Data\AdventureWorks.ldf'
GO

これでExpress側にAdventureWorksが移行されました。
ただし、データベースユーザーに関してはログインとの関連付けがSIDで行われる為、同じ名前のログイン名を用意しても関連付けが出来ません。

これ（Microsoft SQL Server 2005 Tips and Tips）

を見てもらうのが手っ取り早いのですが、掻い摘んで書いてみると

USE AdventureWorks
EXEC sp_change_users_login 'Report'
GO

で、ログインにマッピングされていないユーザーを洗い出し
(今回は自分で追加したtestuserがいました)

EXEC sp_change_users_login 'Update_One'
'tesruser','test_login'
GO

でユーザーを再マッピングできます。もちろん、この場合のログイン（test_login）はプロシージャ実行前に用意して下さい。

もしくは、ここ（上のTipsからもリンク有）にあるスクリプトを実行し

EXEC master..sp_help_revlogin
GO

と叩くと、インスタンスに存在するログインをそっくりそのまま作成するCREATE文が出力されるので、移行先でそのCREATE文を実行するとユーザーがマッピングされます。
全部のログインではなく、必要なログインのみ作成した方が良いと思います。というかDROPしないと全部は作成できないような。。。

CREATE文がいくつも出力されるので、ManagementStudioで実行するか、コマンドプロンプト使用の場合はファイルに書き出すようにしないと大変かもしれません。

SQL Server 7.0/2000ではsp_help_revloginはこれだったようです。
2005用のが7.0/2000でも使用出来るかは確認してないので、ご注意を。

sp_help_revloginでやっていることを手打ちで実行したいという人はここが非常に参考になると思います。


とまあ、こんな感じで移行出来ました。
一番最後に載せたリンクを見ると、

>通常は、DTSなどを使って、ログイン情報も転送します。

･･･DTSなんてシーラネ（お

データベースとかって一回入れるとアンインストールが面倒ですよね。特にOracleとかOracleとか。
なんで、検証用にVMwareを使っていたのですが、ことWindows上でならVirtualServerが使いやすそうだったので、使ってみました。
んで、インストール編です。

この辺（Microsoftダウンロードセンター）からVirtual Server 2005 R2 をダウンロードします。

インストールするマシンにIISが追加されていることを確認します。
確認方法はサービスで確認するか、「プログラムの追加と削除」の「Windowsコンポーネントの追加と削除」あたりで出来ます。
追加されていなければ、「Windowsコンポーネントの追加と削除」から追加しましょう。最低限WWWサービスがあれば良いようです。

IISが追加できたら、ダウンロードしたファイルからインストールしましょう。うん、それだけなんだけどね。
特に悩むところは無かった気がするので、インストールはこんなもんで。

そうそう、こんなページよりもこことか見ると良いと思う。

これ、自分は理解に時間がかかってしまいました。
というのも、Oracleではユーザー=スキーマで、ログインもユーザー単位だったので、ログインと別にユーザーを用意して、さらにそこにスキーマを割り当てるという考え方に慣れなかったのです。
ネットを調べまくった後、本屋で立ち読みまでしましたよ（笑）

で、自分の理解した内容をメモ程度に。

・ログインは名前の通りログインのみを担当
・データへのアクセス権限等はユーザーが担当
・１ユーザーに対応付けられるデータベースは１つのみ
・データベースが異なれば同じユーザー名の作成は可能
・ログインに対してユーザーを対応付ける
・ログインに対応付け可能なユーザーは１データベースにつき１ユーザー

分かりにくいねorz
つまり

LOGIN_A
　→USER_A(←DB_A)
　→USER_A(←DB_B)
　→USER_B(←DB_C)
　×USER_C(←DB_C)

という対応付けです。で、権限・ロールはユーザーに付与すると。
しかも、ユーザー名と異なるスキーマを対応付けることも出来ると。
便利そうではあるけど、管理がめんどくさそうな気もするなあ…