Microsoft Word - J-SAP_RAC_10g_Unix.doc

(1)

Oracle 10g Release 2 Real Application Clusters のための

SAP NetWeaver の構成

オラクル・ホワイト・ペーパー 2006年4月

(2)

Oracle 10g Release 2 Real Application Clusters のための

SAP NetWeaver の構成

はじめに...3 基本セットアップ: SAP システムの準備...4 オプション 1: Oracle 10g を使用した SAP システムの新規インストール ...4 オプション 2: Oracle 9.2 単一インスタンス・データベースからのアップグレード...4 オプション 3: Oracle 9.2 RAC 対応クラスタからのアップグレード ...5 Oracle Clusterware のインストール ...5 Oracle 10.2 RAC ソフトウェアのクラスタへのインストール ...18 Oracle 10g Release 2 へのデータベースのアップグレード ...24 アップグレードの準備: サーバー・パラメータ・ファイル spfile.ora または init<dbsid>.ora...24 アップグレードの準備: 非推奨パラメータのチェック ...25 データベースの起動とアップグレード ...25 SYSTEM 表領域の拡張 ...25 SYSAUX 表領域の作成 ...26 無効なデータベース・オブジェクトのチェック ...26 アップグレードの実行...26 CATCLUST.SQL、UTLRP.SQL、OLSTRIG.SQL の実行 ...27 データベースの制御ファイルのパラメータ ...27 UNDO 表領域によるデータベースの UNDO 管理 ...29 REDO ログのグループとメンバー ...30 SAP R/3 のためのデータベース・リンクの作成 ...34 RAC のための Oracle 初期化パラメータの修正 ...34 Oracle パスワード・ファイル ...37 クラスタ・データベースの有効化とすべてのインスタンスの起動 ...37 Oracle ネットワーク構成 ...38 リスナー構成ファイル listener.ora ...38 ネットワーク構成ファイル tnsnames.ora ...44

Instant Client 使用時に TNS_ADMIN で指定された場所への tnsnames.ora のコピー...49

インスタンス・プロファイル・パラメータ local_listener と remote_listener の追加 ...50

Oracle 10g RAC 対応 SAP データベースのための CRS でのサービスの登録...51

VIP、ONS、GSD の基本 CRS リソース ...51

Oracle Clusterware での SAP データベースと RAC インスタンスの構成...54

SAP R/3 アプリケーション・インスタンスのデータベース・サービスの定義 ...54

SAP ユーザー環境 ...56

インスタンス起動のための SAP スクリプト startsap...57

SAP BR*Tools ...60

(3)

はじめに

このホワイト・ペーパーでは、Oracle 10g Release 2 Real Application Clusters のための SAP R/3 システムの構成に必要となるすべての手順を説明します。ここでの目的は、単一インスタンスのデータベースから複数インスタンスの RAC 対応データベースへの移行などに必要なすべての手順の概要を示すことです。また、各システム環境で利用可能なテンプレートの提供も意図しています。このホワイト・ペーパーでは主に、単一インスタンスの Oracle データベースから Oracle 10g Release 2 Real Application Clusters へのアップグレードと、それに伴う SAP R/3 の構成を説明します。ここに掲載された情報は、Oracle 9.2 RAC 対応の既存システムからアップグレードする場合にも適用できます。単一インスタンスの移行に関する違いについては、このドキュメントで説明します。 ここでは、UNIX と Linux 上で稼働する Oracle システムのアップグレードのみが対象です。 Windows オペレーティング・システムについては、別のドキュメントで説明します。このホワイト・ペーパーでは、クラスタ・ソリューションに使用するクラスタ・ハードウェア、オペレーティング・システム、ストレージ・サブシステムの固有のセットアップは説明しません。必須条件として、基礎となるクラスタ・ハードウェアのセットアップに必要なインストール前の手順をすべて完了する必要があります。使用するクラスタ・ハードウェアのセットアップ方法の詳細は、個々のプラットフォームやオペレーティング・システムのベンダーが提供するドキュメントを参照してください。サポートされる構成の追加情報と最新情報は、Oracle OTN から入手できます。使用するオペレーティング・システム、ストレージ・ソリューションなどの最新情報を確認することを強くお薦めします。なお、Oracle CRS、つまり Oracle 10.2 RAC に付属し、Oracle データベース・ソフトウェアと組み合せて使用する Oracle Clusterware の使用に必要な部分については、ここで説明します。また、動作確認済 SAP システムのための推奨 RAC 構成も説明します。このホワイト・ペーパーでは、SAP がサポートしていない Oracle ASM（Automatic Storage

Management）の使用法については説明しません。

重要な注意: このガイドは、RAC対応SAPシステムのセットアップを支援します。Oracleデー

タベース、Oracleネットワーク構成、Oracleインスタンス・パラメータなど、必要な変更は

すべて説明しますが、完全ではありません。『SAP Installation and Upgrade Guides for Oracle 10g Release 2』で取り上げる追加手順もすべて実行してください。また、RACに関連したす

べてのSAP Noteも参照してください。SAP OSS Note 527843から、Oracle RAC関連情報を確

(4)

基本セットアップ: SAP システムの準備

必要な準備は、Oracle 10.2 RAC に対応する SAP システムの種類によって異なります。 Oracle 10.2 RAC へ移行するには、次の 3 種類の構成があります。 - Oracle 10g を使用したシステムの新規インストール - Oracle 9.2 単一インスタンス・データベースからのアップグレード - Oracle 9.2 RAC 対応クラスタからのアップグレード実際に RAC の構成前に必要な作業は、各構成で異なります。システム間の主な違いについては適時、説明します。

オプション 1: Oracle 10g を使用した SAP システムの新規インストール

最初のシステム・インストールについては SAP のインストールと構成ガイドを参照してください。 SAP インストールの開始前に、クラスタ・ハードウェアのセットアップを完了しておく必要があります。データベース・ファイル、REDO ログ・ファイル、アーカイブ・ログ、制御ファイルをクラスタ・ファイル・システムに配置します。これにより、RAC に対応するためにデータを後で共有ストレージにコピーする必要はありません。このドキュメントでは、計画されたインストールで$ORACLE_HOME 下の投票ディスク（Voting Disk）、CRS リポジトリ、データベース・ファイル、制御ファイル、REDO ログ・ファイル、アーカイブ REDO ログ・ファイル、実行可能ファイル、ならびに/sapmnt ディレクトリ内のすべての SAP 実行可能ファイルに対し、1 つのクラスタ・ファイル・システムを使用するものとします。クラスタ・ファイル・システムへの Oracle ソフトウェアのインストールは、「共有 Oracle ホーム」によるインストールに分類されます。注意: SAPには共有Oracleホームが必要です。

SAP ソフトウェアのインストール中、ユーザー<sid>adm と ora<sid>が作成されます。クラスタ・ファイル・システムでは、これらのユーザーの HOME ディレクトリをクラスタのすべてのノード間で共有できます。

オプション 2: Oracle 9.2 単一インスタンス・データベースからのアップグレード

Oracle 8.1.7 またはそれ以前のリリースを使用している場合、このドキュメントの手順を実行する前に、9.2.x のアップグレードが必要です。RAC への移行には、すべての SAP R/3 システムで Oracle 9.2 以降を実行していることが前提であるためです。

Oracle のドキュメントは、Oracle Technology Network（OTN）の Web サイト http://otn.oracle.co.jp/index.htmlから入手できます。

(5)

この Web サイトから、Oracle Database 10g Release 2 に関連した Oracle ソフトウェア製品の最新情報を必ず入手してください。

SAP ドキュメントの最新のアップデートは、SAP Service Marketplace の Web サイト

http://service.sap.com/instguidesに掲載されています。「Other Documentation」、「Database Upgrades」、「Oracle」の順にクリックして必要なガイドを参照してください。

また、SAP カーネルで Oracle 9.2 クライアント・ソフトウェアを使用している場合（640 カーネルまたは EXT カーネルを使用している場合）、Oracle クライアント・ソフトウェアをリリース 9.2.0.7 以降にアップグレードする必要があります。Oracle 9.2 クライアント・ソフトウェアをアップグレードしないと、Oracle Database 10g へのアップグレード後に SAP システムでコア・ダンプが出力されることがあります。

オプション 3: Oracle 9.2 RAC 対応クラスタからのアップグレード

既存の SAP システムが 9.2 RAC を使用したクラスタ構成の場合、そのアップグレードに必要なすべての手順がこのドキュメントに記載されています。データベース・ソフトウェアを Oracle 10g Release 2 にアップグレードするだけの場合は、必要なデータベースの構成変更はほぼ完了しています。SAP 用の 9.2 RAC 対応データベースでは、データベース・インスタンスの UNDO 表領域、スレッド、REDO ログ・ファイルなどは構成済です。ただし、SAP アプリケーション・インスタンスのデータベース・サービスを使用するには、Oracle ネットワーク構成の変更が必要です。省略可能な構成手順は、その都度、明記します。ノードまたはデータベース・インスタンスの数を変更する場合は、それに応じてデータベース構成を調整します。どちらの場合でも、SAP が提供するアップグレード・ガイドも参照して必須条件を確認してください。9.2 RAC から 10.2 RAC へのデータベース・アップグレードは、Oracle Release 9.2 から 10.2 への単一インスタンスのデータベース・アップグレードとほぼ同じです。

Oracle Clusterware のインストール開始前に、Oracle 9.2 RAC に使用するサード・パーティのクラスタ・ソフトウェアの更新または削除が必要か確認します。 Oracle 9.2 クライアント・ソフトウェアを使用する SAP カーネルに関する注釈も参照してください。この注釈は、RAC 対応済システムにも適用されます。

Oracle Clusterware のインストール

この作業は、Oracle RAC データベース・ソフトウェアのインストール前に完了する必要があります。Oracle Clusterware ソフトウェアは、別のユーザー・アカウントを使用してインストールします。このユーザー・アカウントは、Oracle Clusterware の所有者です。このユーザーには、ユーザー名 oracle の使用をお薦めします。クラスタ内のすべてのノードでユーザーoracle を作成します。このユーザーは、SAP ユーザー ora<sid>と SAP ユーザー<sid>adm のプライマリ・グループで、グループ dba に所属することが必要です。

注意: SAPインストール用のユーザーoracleにグループoinstallを使用しないでください。SAP データベースのすべての管理者は、グループdbaに所属する必要があります。すべての管理者が

(6)

最初のノードにユーザーoracle としてログオンします。ディレクトリ~/.ssh が存在しない場合は、そのディレクトリを作成します。次に、作成したディレクトリに移動します。

$ mkdir .ssh $ cd .ssh

RSA 認可と DSA 認可のための秘密鍵ファイルと公開鍵ファイルを作成します。

$ ssh-keygen –t rsa –f <path_to_homedirectory>/.ssh/id_rsa_<nodename>

パスフレーズは指定しないでください。入力を要求されたら、[Enter]キーを押します。 $ ssh-keygen –t dsa –f <path_to_homedirectory>/.ssh/id_dsa_<nodename>

ここでも、パスフレーズは指定しないでください。[Enter]キーを押します。この作業をすべてのノードで実行します。キーの生成はノードそのものに依存しているため、必ず各ノードにログオンしてください。すべての秘密鍵ファイルと公開鍵ファイルを生成したうえで、すべてのノードの認証ファイルの場所を記述した構成ファイルを作成します。これらの認証ファイルには、各ノードの秘密鍵が含まれています。認証ファイルはフルパス名で指定します。ファイル~/.ssh/config の例を示します。 ForwardX11 no PasswordAuthentication no Host oracx1 IdentityFile /saphome1/oracle/.ssh/id_rsa_oracx1 IdentityFile /saphome1/oracle/.ssh/id_dsa_oracx1 Host oracx2 IdentityFile /saphome1/oracle/.ssh/id_rsa_oracx2 IdentityFile /saphome1/oracle/.ssh/id_dsa_oracx2 Host oracw1 IdentityFile /saphome1/oracle/.ssh/id_rsa_oracw1 IdentityFile /saphome1/oracle/.ssh/id_dsa_oracw1 Host oracw2 IdentityFile /saphome1/oracle/.ssh/id_rsa_oracw2 IdentityFile /saphome1/oracle/.ssh/id_dsa_oracw2 すべての公開鍵をファイル authorized_keys に保存します。 $ cat *.pub > authorized_keys

ファイル権限を次のように変更します。 $chmod 600 config

$chmod 600 authorized_keys $cd

(7)

これで、パスワードを求められることなく、すべてのホストへの ssh 接続を開くことができます。次のコマンドを実行して試してください。 $ssh <nodename> date ファイル known_hosts にフィンガープリントを記録するため、この作業をすべてのノードで実行します。インストール前のその他の必須条件を Oracle のドキュメントで確認します。Oracle では、インストールに成功するための条件が満たされているか確認するツールを提供しています。このツールは cluvfy というツールで、Oracle ソフトウェアに付属しています。注意: cluvfyを使用して、必須条件がすべて満たされていることを確認してください。

ユーザーoracle としてログオンし、Oracle Universal Installer を使用してインストールを開始します。

上の図は「Welcome」画面です。Oracle 製品を初めてインストールする場合は、Oracle インベントリの場所を指定します。インベントリは、各ノードのローカル領域に配置します。

(8)

必ず、クラスタ内のノード間で共有されていないインベントリのパスを指定してください。オペレーティング・システム・グループが SAP ユーザーora<sid>のプライマリ・グループと一致する必要があります。グループ dba はすべての SAP システムで同じであるため、Oracle Clusterware の保護下で、SID が異なる複数の SAP データベース・システムを運用できます。

Oracle Clusterware には、専用の ORACLE_HOME ディレクトリが必要です。Oracle Clusterware をデータベース・ソフトウェアと同じディレクトリにインストールしないでください。各インストールで異なる ORACLE_HOME ディレクトリを使用すると、パッチやパッチ・セットを適用できます。

(9)

Oracle インストーラにより、必須条件がすべて満たされているかチェックされます。このチェックに合格しなかった場合は、インストールを続行しないでください。

注意: Oracle 10g Release 1からアップグレードしている場合は、cssdデーモンのOracle Clusterware構成情報を確実に消去する必要があります。Oracle 10g Release 1では、RACインストールの場合だけでなく単一インスタンスのインストールの場合でも、Oracle Clusterwareのこの部分が自動的にインストールされます。ユーザーrootとして、コマンドlocalconfig deleteを実行します。それにより、cssdのセットアップ情報が削除されます（SAPノート参照）。

次の画面で、クラスタに名前を付け、すべてのノードを指定します。「Edit」ボタンまたは「Add」ボタンを押して、各ノードの詳細に移動します。

(10)

「Public Node Name」はホストの名前です。この名前は通常、hostname コマンドの出力と同じです。「Private Node Name」はクラスタ間接続に使用される名前です。通常、プライベート・クラスタ・

ネットワークのノード名を使用します。「Virtual Host Name」は VIP が使用する名前で、ノードに障害が発生した場合に別のホストにフェイルオーバーするときに使用される仮想 IP アドレスです。Virtual Host Name と IP アドレスは、クラスタ内のすべてのノードで一意にする必要があります。

(11)

この画面では、パブリック・ネットワーク用とプライベート・ネットワーク用のネットワーク・アダプタを指定します。パブリック・ネットワークとプライベート・ネットワークが少なくとも 1 つずつ必要です。パブリック・ネットワークは VIP に使用されます。パブリック・ネットワークのサブネット・マスクは、オペレーティング・システムのネットワーク構成に含まれるサブネット・マスクと一致する必要があります。サブネット・マスクが一致しないと、仮想 IP をネットワーク・アダプタにバインドできません。ネットワーク・カードが 3 枚以上搭載されている場合、そのうち 2 枚を使用します。1 枚をプライベート・ネットワークに、もう 1 枚をパブリック・ネットワークに使用します。それ以外のネットワーク・カードには、「Do Not Use」を指定します。

(12)

次の画面では、Oracle Cluster Registry の場所を指定します。「Normal Redundancy」では、2 つの場所を指定します。この 2 つの場所は、クラスタ・ファイル・システムの別々のパーティションのファイル・システムに存在する必要があります。

投票ディスクは、「Normal Redundancy」構成の 3 方向のミラーです。投票ディスクは、クラスタ・ファイル・システムの異なるパーティションのファイル・システムに存在する必要があります。

(13)

「Summary」画面に表示される内容を確認します。すべての情報が正しければ、「Install」を押しインストールを開始します。

ソフトウェアのインストールの完了後、各ノードで 2 つのシェル・スクリプトを実行します。注意: これらのスクリプトは、各ノードで1つずつ実行することが重要です。1つのスクリプトが完了するまで、次のスクリプトを実行しないでください。

(14)

最後の画面にインストールの結果が表示されます。警告メッセージが表示された場合は、パッチ・セット 10.2.0.2 のアップグレードを実行しないでください。エラーまたは警告が表示された場合は、ここまでのインストールを取り消し、エラーの根本的な原因を取り除いたうえで再度インストールします。失敗したインストール内容を完全に削除するためのプラットフォーム固有の方法は、関連する Metalink ノートを参照してください。既存の CRS を最新のパッチ・セット（リリース 10.2.0.2 以降）にただちにアップグレードします。実行したばかりのインストールによって、クラスタ内の各ノードで CRS ソフトウェアが起動します。最新のリリースにアップグレードするには、CRS ソフトウェアを停止します。CRS ソフトウェアの停止は、ユーザーroot として実行します。クラスタ内のすべてのノードで、次のコマンドを実行します。 $ su – root # cd $CRS_HOME/bin # ./crsctl stop crs これにより、ユーザーoracle としてパッチ・セットをインストールできます。パッチ・セットは、 Oracle Universal Installer によってインストールされます。

(15)

(16)

利用可能なすべてのクラスタ・ノードはあらかじめ選択されています。この内容を変更しないでください。

「Summary」画面が表示されます。すべての要件が満たされていれば、「Install」を押します。パッチ・セットがインストールされます。

(17)

インストールの最後に表示される指示に従います。クラスタのすべてのノードで、ユーザーroot として、スクリプト root.sh を実行します。このスクリプトは複数のノードで同時に実行しないでください。1 つのノードのスクリプトが完了してから、次のノードのスクリプトを実行してください。

パッチ・セットのインストールの最後に Oracle Clusterware が起動します。これは、crs_stat コマンドを実行することで確認できます。crs_stat –t を実行し、クラスタのすべてのノードで ONS リソース、GSD リソース、VIP リソースが ONLINE になっていることを確認してください。

(18)

Oracle 10.2 RAC ソフトウェアのクラスタへのインストール

Oracle CRS ソフトウェアが正常にインストールされて起動した後に、データベース・ソフトウェアをインストールします。SAP での単一インスタンスのインストールと同様、この作業はユーザー ora<sid>として実行します。このユーザーはグループ dba のメンバーであり、SAP データベース SID のデータベース・ソフトウェアのソフトウェア所有者です。クラスタのノードにユーザー ora<sid>が作成されていない場合は、これを作成します。このユーザーはクラスタのすべてのノードで作成する必要があります。ユーザーora<sid>に、クラスタ・ファイル・システム上の共有ホーム・ディレクトリを使用します。CRS ソフトウェア用にユーザーoracle を設定したときと同様、次のようにクラスタ内のすべてのノード間にセキュアなシェル・アクセスを設定して、すべてのノードから共有ホーム・ディレクトリを使用可能にします。最初のノードにユーザーora<sid>としてログオンします。ディレクトリ~/.ssh が存在しない場合は、これを作成します。次に、作成したディレクトリに移動します。 $ mkdir .ssh $ cd .ssh RSA 認可と DSA 認可のための秘密鍵ファイルと公開鍵ファイルを作成します。

$ ssh-keygen –t rsa –f <path_to_homedirectory>/.ssh/id_rsa_<nodename>

パスフレーズは指定しないでください。入力を要求されたら、[Enter]キーを押します。 $ ssh-keygen –t dsa –f <path_to_homedirectory>/.ssh/id_dsa_<nodename>

ここでも、パスフレーズは指定しないでください。[Enter]キーを押します。この作業をすべてのノードで実行します。キーの生成はノードそのものに依存しているため、必ず各ノードにログオンしてください。すべての秘密鍵ファイルと公開鍵ファイルを生成したうえで、すべてのノードの認証ファイルの場所を記述した構成ファイルを作成します。これらの認証ファイルには各ノードの秘密鍵が含まれています。認証ファイルはフルパス名で指定する必要があります。ファイル~/.ssh/config の例を示します。 ForwardX11 no PasswordAuthentication no Host oracx1 IdentityFile /saphome1/orarac/.ssh/id_rsa_oracx1 IdentityFile /saphome1/orarac/.ssh/id_dsa_oracx1 Host oracx2 IdentityFile /saphome1/orarac/.ssh/id_rsa_oracx2 IdentityFile /saphome1/orarac/.ssh/id_dsa_oracx2 Host oracw1 IdentityFile /saphome1/orarac/.ssh/id_rsa_oracw1 IdentityFile /saphome1/orarac/.ssh/id_dsa_oracw1 Host oracw2 IdentityFile /saphome1/orarac/.ssh/id_rsa_oracw2 IdentityFile /saphome1/orarac/.ssh/id_dsa_oracw2

(19)

すべての公開鍵をファイル authorized_keys に保存します。 $ cat *.pub > authorized_keys

ファイル権限を変更します。 $chmod 600 config $chmod 600 authorized_keys $cd $chmod 700 .ssh これで、パスワードを求められることなく、すべてのホストへの ssh 接続を開くことができます。次のコマンドを実行して試してください。 $ssh <nodename> date ファイル known_hosts にフィンガープリントを記録するため、この作業をすべてのノードで実行します。インストール前のその他の必須条件を Oracle のドキュメントで確認します。Oracle では、インストールに成功するための条件が満たされているか確認するツールを提供しています。このツールは cluvfy というツールで、Oracle ソフトウェアに付属しています。注意: cluvfyを使用して必須条件がすべて満たされていることを確認してください。

ユーザーora<sid>としてログオンし、Oracle Universal Installer を使用してインストールを開始します。

(20)

次の画面で、インストールのタイプとして「Enterprise Edition」を選択します。

データベース・ソフトウェアは専用の ORACLE_HOME にインストールする必要があります。 Oracle Clusterware と同じ場所を選択しないでください。

(21)

利用可能なクラスタ・ノードが自動的に検出されます。インストール先としてすべてのノードを選択します。インストーラにより、クラスタ・ファイル・システム上の共有 Oracle Home が検出され、ソフトウェアが 1 度だけインストールされます。

Oracle インストーラにより、必須条件がすべて満たされているか確認されます。このチェックに合格しなかった場合は、インストールを続行しないでください。

(22)

データベース・ソフトウェアだけをインストールします。

「Summary」画面に表示される内容を確認します。すべての情報が正しければ、「Install」を押しインストールを開始します。

(23)

ソフトウェアのインストールが完了後、すべてのノードでユーザーroot として root.sh を実行します。

最後の画面にインストールの結果が表示されます。警告メッセージが表示された場合は、パッチ・セット 10.2.0.2 によるアップグレードを実行しないでください。

ここで、データベース・ソフトウェアを最新のパッチ・セットにアップグレードします。現時点での最新のパッチ・セットはリリース 10.2.0.2 です。Oracle Universal Installer により、Oracle Clusterware 用の 10.2.0.2 パッチ・セットをインストールしたときと同じ順序で画面が表示されます。ここまでに示したすべてのスクリーン・ショットを参照してください。

(24)

Oracle 10g Release 2 へのデータベースのアップグレード

Oracle Universal Installer によるソフトウェアのインストールの終了後、データベース自体を Oracle10g Release 2 に手動でアップグレードします。前述のチェックの目的は、実際のアップグレード開始前にすべての必須条件が満たされていることを確認して、アップグレード時間を短縮することです。この手順により、アップグレード中にエラーが発生するリスクを低減します。注意: 使用中のSAPシステムをOracle 10g Release 2とともに最近インストールした場合は、このアップグレード手順を省略できます。制御ファイルのパラメータの確認に進んでください。システムにユーザーora<dbsid>としてログオンします。ここで重要な点は、新しい Oracle 10g ソフトウェア・リリースへの変更がユーザーora<dbsid>の環境に反映されたことです。Oracle の新しい実行可能ファイルを使用したデータベースの起動前に、環境変数を次のように設定または修正することが必要です。変数値 ORACLE_HOME /oracle/<dbsid>/1020_64 ORACLE_SID <dbsid> ORACLE_BASE /oracle/<dbsid> ORA_NLS10 $ORACLE_HOME/ocommon/nls/admin/data NLS_LANG 古いシステムと同じ

また、$PATH 変数と$LD_LIBRARY_PATH 変数に新しい Oracle 実行可能ファイルのパスを追加する必要があります。

アップグレードの準備: サーバー・パラメータ・ファイル spfile.ora または

init<dbsid>.ora

古い$ORACLE_HOME/dbs ディレクトリのすべてのファイルを新しい$ORACLE_HOME/dbs ディレクトリにコピーします。ほとんどの SAP システムで採用しているネーミング規則によると、新しい$ORACLE_HOME は/oracle/<dbsid>/1020_64 です。古いファイルで ifile パラメータを使用している場合は、このパラメータで参照されるファイルもコピーする必要があります。

注意: Oracle 9.2 RACからアップグレードしている場合、Oracle 10.2へのアップグレードのすべての作業を単一インスタンス環境の場合と同様に実行する必要があります。そのためには、初期化パラメータcluster_databaseをfalseに設定します。インスタンスの起動に pfile init<SID>.ora を使用している場合は、テキスト・エディタでこのファイルを開き、パラメータ cluster_database が false に設定されていることを確認します。 SAP とオラクルがお薦めする単一のサーバー・パラメータ・ファイル spfile.ora を使用している場合は、sqlplus を使用してパラメータの設定を変更します。 $ sqlplus / as sysdba SQL> startup nomount

SQL> alter database set parameter cluster_database=’false’ scope=spfile; SQL> shutdown immediate;

(25)

アップグレードの準備: 非推奨パラメータのチェック

インスタンスの起動前にパラメータの現在の設定をチェックします。インスタンスをスムーズにエラーなく起動するため、パラメータ・ファイルの非推奨パラメータやサポート対象外のパラメータをすべてコメントにします。これらのパラメータの一覧は、オンライン・ドキュメントのCDにも含まれています。

データベースの起動とアップグレード

次のように、SQL*Plus を使用してデータベースを開きます。 $ sqlplus /nolog SQL> connect / as sysdba connected to an idle instance SQL> startup upgrade;

SYSTEM 表領域の拡張

SYSTEM 表領域には、アップグレードのための十分な空き領域が必要です。その領域を確認するには、SQL*Plus から次のコマンドを実行します。

SQL> select sum(bytes), sum(blocks) from dba_free_space where tablespace_name = `SYSTEM’;

領域が十分でない場合は、次のいずれかのコマンドを使用して空き領域を増やします。

- 追加のファイルを作成して領域を増やす。

SQL> alter tablespace system add datafile `<full-path-of-datafile>’ size 80M autoextend on next 10M maxsize unlimited;

- SYSTEM 表領域の既存のファイルで AUTOEXTEND 機能を設定する。

SQL> alter database datafile `filename` autoextend on;

- 既存のファイルのサイズを直接変更する。

(26)

SYSAUX 表領域の作成

注意: Oracle 10g Release 1からアップグレードしている場合は、この手順を省略できます。

Oracle 10g Release 1 からアップグレードしている場合を除き、アップグレード・スクリプトの起動前に、新しい表領域 SYSAUX を作成する必要があります。SYSAUX 表領域の詳細は『Oracle Database Administrator‘s Guide』を参照してください。

SQL> create tablespace SYSAUX

datafile ‘/oracle/<SID>/sapdataX/sysaux01.dbf' size 500M reuse extent management local

segment space management auto autoextend on online;

無効なデータベース・オブジェクトのチェック

データベース内の無効なオブジェクトはアップグレード後も残ります。アップグレードしても無効なオブジェクトは削除されません。次の SQL 文を実行すると、無効なオブジェクトの一覧を取得できます。 SQL> spool /var/tmp/Check4InvObj.log

SQL> select count(*) from dba_objects where status = `INVALID’; SQL> select comp_id, version, status from dba_registry;

これらの SQL 文の出力が 0 以外の場合は、次のようにして無効なオブジェクトを特定します。 SQL> select owner, object_name, object_type from dba_objects where

status = `INVALID’; SQL> spool off SQL> shutdown immediate

アップグレードの実行

データベースのアップグレードには、SQL スクリプトを使用します。システムにユーザー ora<dbsid>としてログオンします。現在の作業ディレクトリを$ORACLE_HOME/rdbms/admin に変更します。次のようにスクリプト catupgrd.sql を実行します。これにより、古いリリースが Oracle10g Release 2 にアップグレードされます。 sqlplus /nolog SQL> connect / as sysdba connected to an idle instance SQL> startup upgrade;

SQL> spool upgrade.log SQL> @catupgrd.sql

(27)

このスクリプトが完了すると、10.2 へのアップグレードが完了します。スクリプト utlu102s.sql を実行してアップグレードの結果を確認します。 SQL> @utlu102s.sql SQL> spool off アップグレード後、インスタンスがスムーズに起動することを確認します。 SQL> shutdown immediate SQL> startup

CATCLUST.SQL、UTLRP.SQL、OLSTRIG.SQL の実行

次のように$ORACLE_HOME/rdbms/admin/catclust.sql を実行します。これにより、データ・ディクショナリにクラスタ関連のビューが作成されます。 SQL> @catclust.sql SQL> @utlrp.sql SQL> @olstrig.sql スクリプト utlrp.sql は、PL/SQL や Java の残りのプロシージャを再コンパイルします。スクリプト olstrig.sql は、Oracle Label Security ポリシーによって、表にあるすべての DML トリガーを再作成します。最後の 2 つのスクリプトは、通常、SAP 環境では必要ありません。これで、データベースを RAC 対応にするためのその他の変更を実行できます。

データベースの制御ファイルのパラメータ

既存のデータベースを RAC 対応にする場合は、特にデータベース・パラメータの MAXINSTANCES、MAXLOGFILES、MAXLOGMEMBERS に注意が必要です。これらのパラメータは Oracle 制御ファイルの一部であり、初期のデータベース作成時に指定されています。一般に、 R/3 システムの最初のインストール以降これらのパラメータが変更されることはありません。注意: このセクションの内容は、古い単一インスタンスのデータベースからアップグレードする場合にのみ適用されます。既存のシステムがOracle 9.2RACに対応している場合は、この作業を省略できます。 MAXINSTANCES は、将来の拡張を考慮しクラスタ内のノードと同数、またはそれより大きい数に設定します。 MAXLOGFILES は、データベース内で作成できる REDO ログ・ファイル・グループの最大数です。 SAP ソフトウェアのログ・ファイル・グループとメンバーのネーミング規則に従って、この値は REDO ログ・ファイル・グループの最大の GROUP 値より大きい数値に設定します。 MAXLOGMEMBERS は、1 つの REDO ログ・ファイル・グループのメンバー（つまり、同じコピー）の最大数です。SAP システムのデフォルト値は 2 です。

(28)

計画された構成に対して現在の値が十分でない場合、制御ファイルのセットを新しく作成する必要があります。そのためには、次のようにして現在の設定をトレース・ファイルにダンプします。

SQL> alter database backup controlfile to trace;

制御ファイルの新しいセットを生成するためのヒントと SQL 文が現在のデータベース・トレース・ファイルに出力されます。このファイルのディレクトリの場所は、次のように SQL*Plus で調べることができます。

SQL> show parameter user_dump_dest

SAP のネーミング規則が使用されている場合、このファイルのデフォルト・ディレクトリは /oracle/<SID>/saptrace/usertrace です。最新のデータベース・トレース・ファイルには、必要な情報がすべて含まれています。このトレース・ファイルの該当部分を一時ファイルに保存し、パラメータを適切な値に変更します。次のコマンドでファイルのリストを表示します。 ls –lr 最新のログ・ファイルは、リストの最後にあります。最新のトレース・ファイルを一時ファイルにコピーします。このファイルを開き、必要に応じて MAXLOGFILES、MAXLOGMEMBERS、MAXINSTANCES の値を修正します。現在のパラメータの値で十分な場合は、制御ファイルのセットを新しく作成する必要はありません。十分でない場合には、パラメータを調整します。パラメータを変更した場合は、トレース・ログ・ファイルに示す手順に従って制御ファイルのセットを新しく作成します。例: SAP での以前の RAC 対応システムで出力されたトレース・ファイルからの抜粋 . . .

# Below are two sets of SQL statements, each of which creates a new # control file and uses it to open the database. The first set opens

# the database with the NORESETLOGS option and should be used only if

# the current versions of all online logs are available. The second # set opens the database with the RESETLOGS option and should be used

# if online logs are unavailable.

# The appropriate set of statements can be copied from the trace into

# a script file, edited as necessary, and executed when there is a # need to re-create the control file.

#

# Set #1. NORESETLOGS case #

(29)

# The following commands will create a new control file and use it # to open the database.

# Data used by the recovery manager will be lost. Additional logs may

# be required for media recovery of offline data files. Use this # only if the current version of all online logs are available. STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE "RAC" NORESETLOGS NOARCHIVELOG -- SET STANDBY TO MAXIMIZE PERFORMANCE

MAXLOGFILES 255 MAXLOGMEMBERS 3 MAXDATAFILES 254 MAXINSTANCES 50 MAXLOGHISTORY 65535 LOGFILE GROUP 11 ( '/oracle/RAC/origlogA/log_g11m1.dbf', '/oracle/RAC/mirrlogA/log_g11m2.dbf' ) SIZE 20M, . . . GROUP 44 ( '/oracle/RAC/origlogB/log_g44m1.dbf', '/oracle/RAC/mirrlogB/log_g44m2.dbf' ) SIZE 20M -- STANDBY LOGFILE DATAFILE '/oracle/RAC/sapdata1/system_1/system.data1', . . . '/oracle/RAC/sapdata1/user1d_2/user1d.data2' CHARACTER SET WE8DEC

;

# Recovery is required if any of the datafiles are restored backups,

# or if the last shutdown was not normal or immediate. RECOVER DATABASE

# Database can now be opened normally. ALTER DATABASE OPEN;

. . .

UNDO 表領域によるデータベースの UNDO 管理

オラクルと SAP では、RAC 環境で UNDO 表領域を使用することをお薦めします。ロールバックセグメントは将来非サポートになる可能性があるため、SAP の RAC 構成では避けてください。注意: このセクションの内容は、単一インスタンスのデータベースからアップグレードする場合にのみ適用されます。既存のシステムがOracle 9.2 RACに対応済で、UNDO表領域を使用する場合は、この作業を省略できます。

(30)

表領域の名前は次のようにしてください。

クラスタのインスタンス数に応じて、PSAPUNDO、PSAPUNDO_002…PSAPUNDO_n のような名前を付けます。できれば、これらの表領域のデータ・ファイルはそれぞれ別のディスクに配置します。

表領域は、次のサンプル SQL スクリプトを使用して作成することもできます。 create undo tablespace PSAPUNDO datafile

'/oracle/<dbsid>/sapdataX/undo/undo.data1 ' size 1000m reuse; create undo tablespace PSAPUNDO_002 datafile

'/oracle/<dbsid>/sapdataX/undo_002/undo_002.data1 ' size 1000m reuse;

. . .

create undo tablespace PSAPUNDO_00n datafile

'/oracle/<dbsid>/sapdata4/undo_00n/undo_00n.data1 ' size 1000m reuse; 注意: 自動 UNDO 管理を利用するには、インスタンスの初期化ファイルも変更する必要があります。ロールバック・セグメントのエントリを削除するか、またはコメントにします。インスタンス固有の初期化ファイルに次の行を追加します。 *:undo_management = auto <dbsid>001:undo_tablespace = PSAPUNDO <dbsid>002:undo_tablespace = PSAPUNDO_002 <dbsid>00n:undo_tablespace = PSAPUNDO_00n クラスタ内のインスタンスで使用する自動 UNDO 管理とロールバック・セグメントは相互に排他的です。ふたつの方法を組み合せて使用できません。自動UNDO表領域を使用するには、クラスタでインスタンスをまったく構成しないか、またはすべてのインスタンスを構成します。注意: UNDO 表領域を使用する場合は、古いロールバック・セグメントを保持する表領域をすべて削除します。これらの表領域をオフライン・モードにはできません。オフライン・モードにした場合、データベースがハングアップする可能性があります。

REDO ログのグループとメンバー

注意: このセクションの内容は、単一インスタンスのデータベースからアップグレードする場合にのみ適用されます。既存のシステムがOracle 9.2 RACに対応済の場合は、この作業を省略できます。

標準の SAP システムでは、Oracle トランザクション・ログ・ファイル（REDO ログ・ファイル）のグループが 4 つあります。デフォルトでは、オリジナルの REDO ログ・ファイルとミラー化された REDO ログ・ファイルが各グループに 1 つずつ含まれます。REDO ログ・ファイルをハードウェアまたはオペレーティング・システムを利用してミラー化する場合、各グループは 1 つのオリジナルの REDO ログ・ファイルのみで構成します。単一インスタンスのデータベース・システムの場合、グループはデフォルトで次のように編成されます。

(31)

• GROUP 101 (redo1) /oracle/<dbsid>/origlogA/log_g101m1.dbf /oracle/<dbsid>/mirrlogA/log_g101m2.dbf • GROUP 102 (redo2) /oracle/<dbsid>/origlogB/log_g102m1.dbf /oracle/<dbsid>/mirrlogB/log_g102m2.dbf • GROUP 103 (redo3) /oracle/<dbsid>/origlogA/log_g103m1.dbf /oracle/<dbsid>/mirrlogA/log_g103m2.dbf • GROUP 104 (redo4) /oracle/<dbsid>/origlogB/log_g104m1.dbf /oracle/<dbsid>/mirrlogB/log_g104m2.dbf

ログ・ファイルは、REDO ログ log_g101m<number>.dbf から REDO ログ log_g104m<number>.dbf に定期的に書き込まれます。使用中の REDO ログとアーカイブ中の REDO ログは常に別のセットに所属します。つまり、GROUP 101 と GROUP 103 はセット A に所属し、GROUP 102 と GROUP 104 はセット B に所属します。

複数のインスタンスを持つ Oracle RAC 構成では、各データベース・インスタンスで独自の REDO ログ・ファイルのグループが必要です。これらの追加のログ・ファイル・グループではネーミング規約が多少異なります。たとえば、2 番目のインスタンス（スレッド 2）は GROUP 21 と GROUP 23 が所属する REDO ログのセット A と、GROUP 22 と GROUP 24 が所属するセット B を使用します。さらに、3 番目のインスタンスではセット A とセット B を使用する、という具合です。データベースの新しいインスタンスのために REDO ログ・ファイルを追加作成する場合は、次の例のように SQL スクリプトを使用して実行できます。この例では、Oracle RAC ソリューションで 4 つのデータベース・インスタンスを 4 つ使用しています。

alter database add logfile thread 1 group 11 (´/oracle/<dbsid>/origlogA/log_g11m1.dbf´,

´/oracle/<dbsid>/mirrlogA/log_g11m2.dbf´) size 200M reuse; alter database add logfile thread 1 group 12

(´/oracle/<dbsid>/origlogB/log_g12m1.dbf´,

´/oracle/<dbsid>/mirrlogB/log_g12m2.dbf´) size 200M reuse; alter database add logfile thread 1 group 13

(´/oracle/<dbsid>/origlogA/log_g13m1.dbf´,

´/oracle/<dbsid>/mirrlogB/log_g14m2.dbf´) size 200M reuse;

(32)

新しいスレッドを使用するには、それらのスレッドを有効にする必要があります。 SQL> alter database enable public thread 1;

SQL> alter database enable public thread 2; SQL> alter database enable public thread 3; SQL> alter database enable public thread 4;

ファイルとグループを作成後、古い REDO ログ・ファイルのセットを削除できます。v$log への問合せを実行して、カレントになっているログ・ファイル・グループを確認します。

SQL> select group#, archived, status from v$log; GROUP# ARC STATUS

--- --- 101 YES INACTIVE 102 NO CURRENT 103 YES INACTIVE 104 YES INACTIVE 11 NO UNUSED 12 NO UNUSED 13 NO UNUSED . . . . . 44 NO UNUSED 新しく作成したグループのログがカレント・ログになるように、ログの切替えを必要なだけ実行します。カレントかどうかわからない場合は、v$log への問合せを再度実行します。

(33)

SQL> alter system switch logfile; SQL> alter system switch logfile; SQL> alter system switch logfile; SQL> alter system switch logfile;

この作業が完了すると、古いログ・ファイル・グループを安全に削除できます。 SQL> alter database drop logfile group 101;

SQL> alter database drop logfile group 102; SQL> alter database drop logfile group 103; SQL> alter database drop logfile group 104;

グループ 101～104 のログ・ファイルを必ず OS レベルで削除してください。

前述の例では、ログ・ファイルのミラー化にハードウェアを使用していないものとします。

SAP では、パフォーマンス上の理由から、1 つのログ・ファイル・グループに所属するファイルをそれぞれ別のディスクに配置することを推奨しています。上の図は、REDO ログ・ファイルのすべてのセットが個別のディスクまたはディスク・ボリュームに存在する最適な構成です。

(34)

SAP R/3 のためのデータベース・リンクの作成

SAP R/3 ソフトウェアは、クラスタ化されたデータベース・ソリューションのための準備がある程度完了しています。R/3 システム内からクラスタ・データベースを監視、管理するためには、インスタンス間のデータベース・リンクを定義する必要があります。

インスタンス間のリンクを作成するには、SQL*Plus を使用します。create 文の using 句では、 tnsnames.ora ネットワーク構成ファイルで指定されているとおりにインスタンスのネット・サービス名を指定します。リンク名自体はローカル・インスタンスのインスタンス名です。すべてのインスタンスについてこの文を実行します。

create public database link instance_name_1 using instance_name_1; create public database link instance_name_2 using instance_name_2;

. . .

create public database link instance_name_n using instance_name_n;

リンクの定義が誤っていると、SAP トランザクション SM66（Global Work Process Overview）が SAPGUI にウィンドウを表示します。すべての構成変更が完了し、SAP システムがデータベースに再度接続された後で、これを確認します。

RAC のための Oracle 初期化パラメータの修正

RACクラスタ・データベース環境を正しく運用するためには、データベース初期化パラメータを

変更する必要があります。単一インスタンスのOracleデータベースには、ディレクトリ

$ORACLE_HOME/dbsにパラメータ・ファイルinit<dbsid>.oraが1つだけ存在します。RACクラ

スタ・データベース構成を運用している場合は、各データベース・インスタンスで、そのインスタンスのスタートアップのためのinit<dbsid>という名前の個別のパラメータ・ファイルまたはデ

フォルトのinit.oraファイルが必要です。SAP環境ではSPFILEがサポートされているため、容易

に修正してそれを使用できます。

注意: 共有$ORACLE_HOME が使用されている場合、サーバーのパラメータ・ファイルも共有場所に存在します。

SAPは、構成ファイルにも$ORACLE_HOME/dbsを使用します。つまり、BR*SPACEツールセッ

トの構成ファイルはこのディレクトリに存在します。これらのファイルとOracleサーバー・パラ

メータ・ファイルをSAPツールで管理するには、共有場所が必要です。構成ファイルを各ノード

のローカル・ディスクに配置する分散構成はサポートされていません。オラクルと SAP では、RAC 環境で SPFILE の使用をお薦めします。

注意: 次のセクションは、既存のSAPシステムをアップグレードしPFILE init<SID>.oraを使用する場合に、適用されます。オリジナルの初期化ファイル init<dbsid>.ora を古いディレクトリから新しいディレクトリ $ORACLE_HOME/dbs にコピーする必要があります。古いファイルで IFILE パラメータが使用さ れている場合、その中で参照されるファイルも新しい場所にコピーします。この include メカニズ ムをデータベースの初期化に使用している場合、今後はその使用を避けてください。これは SAP でも推奨しており、Oracle 10g への通常のアップグレードにも該当します。これにより、将来のリリースでバイナリの SPFILE に容易に移行できるからです。

(35)

計画された RAC 環境では、各 Oracle データベース・インスタンスでプライベートな初期化ファイル init<dbsid><thread>.ora が必要です。インスタンス固有のファイルを継続して使用する場合、最適な方法の 1 つは、このファイルをインスタンス固有の設定にのみ使用し、すべてのインスタンスに共通の情報は icommon.ora というファイルに含めます。

注意: SPFILEを使用している場合は、判読可能なpfile init.oraを作成し、テキスト・エディタを使用して構成を調整できます。

既存の spfile を変更する場合は、sqlplus コマンド「alter system set parameter=…」を使用します。例: インスタンス RAC001 に対してインスタンス番号 1 を設定する

SQL> alter system set instance_number = 1 scope spfile sid = ‘RAC001’;

初期化ファイルのインスタンス固有の部分は次のようになります。 instance_number = <thread>

thread = <thread>

instance_name = <dbsid><thread>

service_names = (<dbsid>, <dbsid><thread> undo_management = auto

undo_tablespace=<tablespacename>

すべてのインスタンスのデータベースにUNDO表領域を作成する必要があります。UNDO表領域

のセクションの自動UNDO管理に関する説明を参照してください。

オラクルと SAP では、RAC 環境で UNDO 表領域の使用をお薦めします。

ファイル icommon.ora には、その他の初期化パラメータがすべて含まれています。これらのパラメータは、すべてのインスタンスで有効です。RAC 環境では、アップグレード後、特に次の表に示すパラメータに注意が必要です。

パラメータ値コメント

db_domain WORLD 他の値がない場合は WORLD に設定

Compatible 10.2 cluster_database True 10g へのアップグレード後に設定 remote_login_passwordfile Exclusive remote_os_authent True local_listener LISTENER_<SID>_ <HOSTNAME> ネットワーク構成ファイル tnsnames.ora の有効後に設定 remote_listener REMOTE_LISTENER_ <SID>_<HOSTNAME> ネットワーク構成ファイル tnsnames.ora の有効後に設定

(36)

注意: 前述の表のパラメータは、データベースのアップグレード後に調整します。アップグレード中は、古い設定を使用します。

RAC 対応データベースへの移行が完了後、複数の init<dbsid>.ora ファイルではなく単一の init.ora 初期化ファイルを作成します。インスタンス固有の値は、パラメータの前にインスタンス名を付けます。インスタンス名は ORACLE_SID 環境変数から得られます。単一の init.ora ファイルの例（抜粋） <dbsid>001:instance_number = 001 <dbsid>002:instance_number = 002 <dbsid>001:thread = 001 <dbsid>002:thread = 002 <dbsid>001:instance_name = <dbsid>001 <dbsid>002:instance_name = <dbsid>002

<dbsid>001:service_names = (<dbsid>, <dbsid>001)

*:undo_management = auto <dbsid><thread>: undo_tablespace=<tablespacename> <dbsid>001:local_listener = LISTENER_<SID>_<hostname1> <dbsid>002:local_listener = LISTENER_<SID>_<hostname2> <dbsid>001:remote_listener = REMOTE_LISTENER_<SID>_<hostname1> <dbsid>002:remote_listener = REMOTE_LISTENER_<SID>_<hostname2> すべてのインスタンスで有効なパラメータは、先頭に「*」が付きます。共通パラメータの場合は「*」を省略できます。 $ORACLE_HOME/dbs ディレクトリから初期化ファイル init<dbsid>.ora または init<dbsid><thread>.ora をすべて削除します。

sqlplus を使用してバイナリ SPFILE を（spfile.ora というファイル名で）作成します。

connect “/ as sysdba”

SQL> create spfile=’spfile.ora’ from pfile=’init<dbsid>.ora’;

注意: この作業は、RACへの移行に成功してから実行してください。

バイナリ SPFILE は、Oracle Enterprise Manager を RAC 環境で使用するときの前提条件です。 $ORACLE_HOME/dbs ディレクトリから初期化ファイル init<dbsid>.ora または

(37)

Oracle パスワード・ファイル

注意: Oracle 9i RACシステムからアップグレードしている場合は、古いパスワード・ファイルをこれまでの9i RACの$ORACLE_HOME/dbsディレクトリから新しい10g RACの

$ORACLE_HOME/dbsディレクトリにコピーします。単一インスタンスの SAP R/3 構成では、デフォルトでパスワード・ファイルは使用しません。ただし、RAC 環境ではパスワード・ファイルが必要です。データベース・インスタンスは、このファイルを使用して、DBA や OPER の権限を持つユーザーを識別します。パスワード・ファイルを使用するには、ユーザーora<dbsid>としてログオンします。他のユーザー・アカウントを使用すると、パスワード・ファイルが使用できなくなります。ファイル自体は、データベース初期化ファイルと同じディレクトリ（$ORACLE_HOME/dbs）に存在します。次のコマンドを使用してパスワード・ファイルを作成します。 orapwd file=<fname> password=<password> entries=<users>

file パラメータはファイル名を指定します。これは必須のパラメータです。password パラメータでは、データベース・ユーザーSYS のパスワードを入力します。entries パラメータは省略することができます。このパラメータは、DBA 権限や OPER 権限を持つユーザーの数を示します。

クラスタ・データベースの有効化とすべてのインスタンスの起動

Oracle 10g RAC へのアップグレードが完了し、ここで説明したデータベースの変更がすべて終了したら、クラスタ・データベースを有効にします。SAP とオラクルがお薦めする単一のサーバー・パラメータ・ファイル spfile.ora を使用している場合は、sqlplus を使用してクラスタ・データベース・パラメータの設定を変更します。 $ sqlplus / as sysdba SQL> startup nomount

SQL> alter system set parameter cluster_database=’true’ scope=spfile; SQL> shutdown immediate; クラスタ内の各ノードにユーザーora<sid>としてログオンします。環境変数 ORACLE_SID を、クラスタ・ノードでの実行を意図したインスタンスの独自の値に設定します。sqlplus を使用して各ノードで Oracle データベース・インスタンスを起動します。 $ export ORACLE_SID=<DBSID><THREAD> $sqlplus / as sysdba

connected to an idle instance SQL> startup

注意: データベースとインスタンスはまだOracle Clusterwareに認識されていません。データベース・インスタンスの起動には、sqlplusを使用する必要があります。構成の完了後は、srvctlツールがデータベース・インスタンスのコントロールに適しています。

(38)

Oracle ネットワーク構成

SAP R/3 システムと様々な管理ツールをスムーズにエラーなく運用するには、クラスタ・ノード内外のネットワーク構成を正しく設定することが不可欠です。実際の運用環境の具体的なニーズや、基礎となるオペレーティング・システム、同じ場所にインストールされた他の Oracle 製品に応じて、Oracle ネットワーク構成ファイルを異なる場所に置くことができます。このドキュメントでは、これらのネットワーク構成ファイルがクラスタ・ファイル・システムに存在するものとします。これは特に、$ORACLE_HOME/network/admin ディレクトリがクラスタ化されたファイル・システムにある場合に該当します。この場合、クラスタ内のすべてのノードが同じディレクトリにアクセスして Oracle ネットワーク構成を取得します。注意: Oracle 9i RACシステムからアップグレードしている場合は、ネットワーク構成ファイルとログ・ファイルのローカル・コピーを指すシンボリック・リンクを削除します。

クラスタ・ファイル・システムの共有$ORACLE_HOME を使用する場合、Oracle 9i RAC を使用した SAP R/3 のセットアップでは、共有ディレクトリにある構成ファイルとログ・ファイルから、ローカル・ディスクにあるこれらのファイルのノード固有のローカル・コピーへのシンボリック・リンクが必要です。詳細は、『Configuring SAP R/3 4.6D for Use with Oracle Real Application Clusters』を参照してください。Oracle 10g RAC で、SAP R/3 アプリケーション・サーバーのすべてのインスタンスに任意のデータベース・サービスを使用する場合、このシンボリック・リンクは必要ありません。クラスタ内外のすべてのノードが同じネットワーク構成ファイルを使用できます。そのため、構成ファイルは共有クラスタ・ファイル・システムに問題なく存在できます。

リスナー構成ファイル listener.ora

Oracle データベース・インスタンスを実行するすべてのクラスタ・ノードに、クライアントからの接続要求を処理するリスナー・プロセスが必要です。注意: SAPの規則では、クラスタで実行される各SAPシステムに専用のリスナー・プロセスを構成する必要があります。この規則は、各ノードにリスナーが1つずつ存在するOracleのデフォルトのセットアップとは異なります。様々なリスナーを個別にするために、すべての SAP システムで接続要求に対し専用のポート番号を使用する必要があります。Oracle のデフォルトのポートは 1521 です。SAP ではデフォルトでポート番号 1527 を使用します。クラスタで複数の SAP システムが稼働している場合は、システムごとに異なるポート番号を使用します。クラスタ内のすべてのノードが SAP システムの listener.ora 構成ファイルを共有できます。クラスタ・ノードで実行されるリスナー・プロセスごとに、個別ファイルを用意する必要はありません。エントリを区別するため、リスナーには、リテラル文字列「LISTENER」、SID、ノード名を「_」文字で区切った名前（LISTENER_<SID>_<nodename>）を付けます。このネーミング規則に従うことで、CRS 内に複数のリスナー・リソースを登録できます。CRS リソースの名前は、 ora.LISTENER_<SID>_<NODENAME>.lsnr になります。

Oracle 10g のリスナー・プロセスは、クラスタ・ノードの VIP に依存します。VIP に障害が発生した場合や必要に応じて VIP を再配置する場合は、該当するノードのリスナー・プロセスを停止する必要があります。このためには、すべてのノードのリスナーを CRS フレームワーク内にサービスとして登録します。この点は Oracle の以前のリリースと異なります。以前のリリースでは、リスナー・プロセスを手動で開始する必要がありました。リスナーを手動で登録する方法とテンプ

(39)

注意: CRSでのリソースの手動登録はお薦めしません。これはリスナーの構成にも該当します。リスナーの構成には、構成ツールnetcaを使用してください。例: netca を使用したリスナーの構成ユーザーora<sid>として、$ORACLE_HOME の設定が正しいか確認します。netca を起動します。「Cluster configuration」を選択します。次に示すように、クラスタ内のすべてのノードを選択します。

(40)

「Listener configuration」を選択します。

構成を最初から行う場合は「Add」を、既存の listener.ora を$ORCACLE_HOME/network/admin にコピーした場合は「Reconfigure」を選択します。

リスナーの名前を選択します。推奨される名前が表示されます。名前は LISTENER_<SID>の形式です。先に選択したすべてのノードのノード名が自動的に追加されます。

(41)

使用するプロトコルを選択します。TCP を選択してください。IPC も選択できますが、現在は推奨しておりません。

使用するポート番号を選択します。SAP のデフォルトのポートは 1527 です。クラスタで複数の Oracle データベースを実行する場合は、すべてのデータベースで、リスナー間で共有しない独自のポート番号を使用します。

(42)

クラスタで別の Oracle データベースを実行していない場合、構成はこれで終了です。「Finish」を選択します。ツールにより、リスナー構成ファイル listener.ora が作成され、CRS リポジトリにリスナーのリソースが作成されます。次のコマンドの出力から、リソースの作成結果を確認できます。 $ crs_stat -p ora.<nodename>.LISTENER_<SID>_<nodename>.lsnr ファイル$ORACLE_HOME/network/admin/listener.ora の内容を確認します。最もシンプルなケースでは、listener.ora ファイルの内容は次のようになります。この例は、4 つのノードを使用した構成です。

(43)

STARTUP_WAIT_TIME_LISTENER = 0 CONNECT_TIMEOUT_LISTENER = 10 TRACE_LEVEL_LISTENER = OFF

LISTENER_RAC_ORACX1 = (ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = oracx1_vip ) (PORT = 1527)(IP = FIRST)) )

LISTENER_RAC_ORACX2 = (DESCRIPTION_LIST = (DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = oracx2_vip) (PORT = 1527)(IP = FIRST)) )

)

LISTENER_RAC_ORACW1 = (DESCRIPTION_LIST = (DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = oracw1_vip) (PORT = 1527)(IP = FIRST)) )

)

LISTENER_RAC_ORACW2 = (DESCRIPTION_LIST = (DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = oracw2_vip) (PORT = 1527)(IP = FIRST)) ) ) 注意: リスナーのサービス名は、スタートアップ・プロファイルで指定したOracleデータベース・インスタンス・パラメータlocal_listenerの名前と一致する必要があります。tnsnames.oraファイルに必要なものは、パラメータのネットワーク・サービス名とremote_listenerのみです。提供されたサービスをクライアントに公開するために、Oracle データベース・インスタンスをリスナー・プロセスに登録する必要があります。登録は、インスタンスの起動時に自動的に実行されます。SAP システムの場合、使用するデフォルトのポート番号が Oracle のデフォルト値と異なります。インスタンス・プロファイル・パラメータ local_listener と remote_listener の正しいエントリを指定してください。さもないと、サービスの自動登録に失敗します。注意: Oracle 9i RACインストレーションからアップグレードしている場合、インスタンス・パラメータremote_listenerを設定する必要があります。このパラメータは、SAP用のOracle 9i RAC では設定しません。

リスナーの開始と停止には、CRS コマンドを使用します。lsnrctl start/stop コマンドを使用してリスナーをコントロールしないでください。

リスナーを手動で開始するには、次のコマンドを使用します。 $ crs_start ora.<nodename>.LISTENER_<SID>_<nodename>.lsnr