Oracle Database 10g Real Application ClustersのためのSAP NetWeaverの構成

(1)

Oracle Database 10g Real Application Clusters のための

SAP NetWeaver の構成

10.2.0.4更新リリース − SAP J2EE構成を含む

オラクル・ホワイト・ペーパー

(2)

Oracle Database 10g Real Application Clusters のための

SAP NetWeaver の構成

はじめに ... 3 基本セットアップ: SAPシステムの準備 ... 4 オプション 1: Oracle 10gを使用したSAPシステムの新規インストール ... 4 オプション 2: Oracle 9.2 単一インスタンス・データベースからのアップグレード ... 5 オプション 3: Oracle 9.2 RAC対応クラスタからのアップグレード ... 5 Oracle Clusterwareのインストール ... 6 VIP、ONS、GSDの基本CRSリソース ... 19 SAPインストール用のOracle CRSパラメータ調整 ... 22 Oracle 10.2 RACソフトウェアのクラスタへのインストール ... 24

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

アップグレードの準備: サーバー・パラメータ・ファイルspfile.oraまたはinit<dbsid>.ora ... 31 アップグレードの準備: 非推奨パラメータのチェック ... 32 データベースの起動とアップグレード ... 32 SYSTEM表領域の拡張 ... 32 SYSAUX表領域の作成 ... 33 無効なデータベース・オブジェクトのチェック ... 33 アップグレードの実行 ... 33 CATCLUST.SQL、UTLRP.SQL、OLSTRIG.SQLの実行 ... 34 データベースの制御ファイルのパラメータ ... 34 UNDO表領域による自動UNDO管理 ... 37 REDOログのグループとメンバー ... 38 RACのためのOracle初期化パラメータの修正 ... 42 Oracleパスワード・ファイル ... 44 クラスタ・データベースの有効化とすべてのインスタンスの起動 ... 45 Oracleネットワーク構成 ... 46 リスナー構成ファイルlistener.ora ... 46 ネットワーク構成ファイルtnsnames.ora ... 53 Instant Client使用時にTNS_ADMINで指定された場所へのtnsnames.oraファイルのコピー ... 58 インスタンス・プロファイル・パラメータlocal_listenerとremote_listenerの追加 ... 59 RAC対応SAPデータベースのためのCRSでのサービスの登録 ... 60 Oracle ClusterwareでのSAPデータベースとRACインスタンスの構成 ... 60 SAP R/3 アプリケーション・インスタンスのデータベース・サービスの定義 ... 61 SAPユーザー環境 ... 63 SAPインスタンスのプロファイル ... 63 SAP STARTプロファイル ... 64 RACデータベース用SAP J2EEサーバー構成 ... 65 J2EEインスタンスのデータベース・サービスの定義 ... 67 SAP BR*Tools ... 68

(3)

はじめに

このホワイト・ペーパーでは、Oracle Database 10g Release 2 Real Application Clusters のための SAP R/3 システムの構成に必要となるすべての手順を説明します。ここでの目的は、単一インスタンスのデータベースから複数インスタンスの RAC 対応データベースへの移行などに必要なすべての手順の概要を示すことです。また、各システム環境で利用可能なテンプレートの提供も意図しています。このホワイト・ペーパーでは主に、単一インスタンスの Oracle データベースから Oracle Database 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 システムをインストールすることにより、単一インスタンスの Oracle データベースが作成されます。SAP からは、Oracle RAC 対応データベースを直接インストールする機能は提供されません。SAP システムの初期インストールが完了してから RAC への移行を実行してください。 SAP インストールの開始前に、クラスタ・ハードウェアのセットアップを完了しておく必要があります。データベース・ファイル、REDO ログ・ファイル、アーカイブ・ログ、制御ファイルをクラスタ・ファイル・システムに配置します。これにより、RAC に対応するためにデータを後で共有ストレージにコピーする必要はありません。このドキュメントでは、計画されたインストールで投票ディスク（ボーティング・ディスク）、 CRS リポジトリ、データベース・ファイル、制御ファイル、REDO ログ・ファイル、アーカイブ REDO ログ・ファイル、$ORACLE_HOME（Oracle RDBMS ソフトウェアのインストール・ディレクトリ）下の実行可能ファイル、ログ・ファイル、$CRS_HOME（Oracle CRS ソフトウェアのインストール・ディレクトリ）下の実行可能ファイル、ならびに/sapmnt ディレクトリ内のすべての SAP 実行可能ファイルに対し、1 つのクラスタ・ファイル・システムを使用するものとします。クラスタ・ファイル・システムへの Oracle ソフトウェアのインストールは、「共有 Oracle ホーム」によるインストールに分類されます。

注意: RAC対応SAPシステムには、共有Oracleホームが必要です。Oracle CRSソフトウェアは

クラスタ・ファイル・システム上の共有領域にもインストールされます。

SAP ソフトウェアのインストール中、ユーザー<sid>adm と ora<sid>が作成されます。クラスタ・ファイル・システムでは、これらのユーザーの HOME ディレクトリをクラスタのすべてのノード間で共有できます。これは必須要件ではありませんが、変更がクラスタ内のすべてのノードに対して直ちに適用されるため、ユーザー・プロファイルなどに関する構成作業をより速く完了できます。すべての変更を適用するために繰り返し行う作業が省けるため、管理オーバーヘッドが軽減されます。このホワイト・ペーパーで説明する事例はすべて、共有ユーザー・ホームを使用するものとします。

(5)

オプション 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://www.oracle.com/technologyから入手できます。

この 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 9.2 から 10.2 への単一インスタンスのデータベース・アップグレードとほぼ同じです。

Oracle Clusterware のインストール開始前に、Oracle 9.2 RAC に使用するサードパーティのクラスタ・ソフトウェアの更新または削除が必要か確認します。

Oracle 9.2 クライアント・ソフトウェアを使用する SAP カーネルに関する注釈も参照してください。この注釈は、RAC 対応済システムにも適用されます。

(6)

Oracle Clusterwareのインストール

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

Oracle Clusterware ユーザーoracle のホーム・ディレクトリをクラスタ・ファイル・システムの共有領域に置くことができます。これにより管理作業が非常に楽になります。プロファイルの変更は一度の作業でクラスタ内のすべてのノードに適用されます。このホワイト・ペーパーの構成例はすべて、ユーザーoracle の共有ホーム・ディレクトリを使用するものとします。

注意: SAPインストール用のユーザーoracleにグループoinstallを使用しないでください。SAP

データベースのすべての管理者は、グループdbaに所属する必要があります。すべての管理者が CRSコマンドを使用する必要があるため、CRSプログラムもグループdbaを使用して実行する必要があります。最初のノードにユーザー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 の例を示します。

(7)

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

(8)

上の図は「Welcome」画面です。Oracle 製品を初めてインストールする場合は、Oracle インベントリの場所を指定します。インベントリは、各ノードのローカル領域に配置します。 Oracle インベントリには、ノードにインストールされたすべての Oracle ソフトウェアのメタデータ情報が保持されます。この例では、インベントリ・ディレクトリは/oracle/oraInventory です。このディレクトリはクラスタ内の各ノードのローカル・ディレクトリです。インベントリ・ディレクトリと Oracle clusterware のソフトウェア・インストール・ディレクトリとを間違えないようにしてください。このディレクトリは SAP インストール時に共有クラスタ・ファイル・システムに存在する必要があります。

(9)

必ず、クラスタ内のノード間で共有されていないインベントリのパスを指定してください。インストールを実行するユーザーが Oracle インベントリへの完全なアクセス権を持っていることを確認します。Oracle CRS の場合、ユーザーoracle がインベントリ・ディレクトリおよびすべてのサブディレクトリへの書込み権限を持っていることを確認します。すべてのノードで、「chown -R oracle:dba /oracle/oraInventory」を実行します。このチェックは、Oracle clusterware にパッチ・セットまたは単一のパッチをインストールする際にも使用します。

オペレーティング・システム・グループが SAP ユーザーora<sid>のプライマリ・グループと一致する必要があります。グループ dba はすべての SAP システムで同じであるため、Oracle Clusterware の保護下で、SID が異なる複数の SAP データベース・システムを運用できます。

Oracle Clusterware には、専用の ORACLE_HOME ディレクトリが必要です。Oracle Clusterware をデータベース・ソフトウェアと同じディレクトリにインストールしないでください。各インストールで異なる ORACLE_HOME ディレクトリを使用すると、パッチやパッチ・セットを適用できます。注意: Oracle CRSソフトウェアはクラスタ・ファイル・システムの共有場所にインストールしてください。これは、現在のOracle CRSリリース（10.2）におけるSAPインストール時の必須要件です。

(10)

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

注意: Oracle 10g Release 1からアップグレードしている場合は、cssdデーモンのOracle

Clusterware構成情報を確実に消去する必要があります。Oracle 10g Release 1では、RACイン

ストールの場合だけでなく単一インスタンスのインストールの場合でも、Oracle Clusterwareの

この部分が自動的にインストールされます。ユーザーrootとして、コマンドlocalconfig deleteを

実行します。それにより、cssdのセットアップ情報が削除されます。

(11)

「Public Node Name」はホストの名前です。この名前は通常、hostname コマンドの出力と同じです。「Private Node Name」はクラスタ間接続に使用される名前です。通常、プライベート・クラスタ・ネットワークのノード名を使用します。「Virtual Host Name」は VIP が使用する名前で、ノードに障害が発生した場合に別のホストにフェイルオーバーするときに使用される仮想 IP アドレスです。Virtual Host Name と IP アドレスは、クラスタ内のすべてのノードで一意にする必要があります。

(12)

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

(13)

注意: プライベート・インターコネクト用およびパブリック・ネットワーク用のアダプタのネッ

トワーク・インタフェース名はすべてのノードで同一の名称にしてください。すべてのクラスタ・ノードのシステム・セットアップで、プライベートおよびパブリック・ネットワーク用に同一のインタフェース名を使用しているか確認してください。

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

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

(14)

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

ソフトウェアのインストールの完了後、各ノードで 2 つのシェル・スクリプトを実行します。

注意: これらのスクリプトは、各ノードで1つずつ実行することが重要です。1つのスクリプトが

(15)

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

(16)

(17)

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

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

(18)

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

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

$ crs_stat –t

Name Type Target State Host

ora.oracx1.gsd application ONLINE ONLINE oracx1 ora.oracx1.ons application ONLINE ONLINE oracx1 ora.oracx1.vip application ONLINE ONLINE oracx1 ora.oracx2.gsd application ONLINE ONLINE oracx2 ora.oracx2.ons application ONLINE ONLINE oracx2 ora.oracx2.vip application ONLINE ONLINE oracx2 ora.oracw1.gsd application ONLINE ONLINE oracw1 ora.oracw1.ons application ONLINE ONLINE oracw1 ora.oracw1.vip application ONLINE ONLINE oracw1 ora.oracw2.gsd application ONLINE ONLINE oracw2 ora.oracw2.ons application ONLINE ONLINE oracw2 ora.oracw2.vip application ONLINE ONLINE oracw2

まれに基本リソース自動作成用構成アシスタントの実行に失敗する場合があります。その場合は crs_stat –t コマンドからの出力が表示されません。コマンドラインから構成アシスタント「vipca」を実行してください。詳細は次の項を参照してください。

(19)

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

これらのリソースは、Oracle Clusterware のインストール中に自動的に作成されます。OCR リポジトリ・ファイルに格納された CRS 構成が失われたり壊れた場合、インストール後でもこれらのリソースを再作成できます。

注意: リソースの再作成は、必要な場合にのみ実行してください。

リソースは、ユーザーroot としてセットアップします。リソースの作成と構成には、vipca ツール（VIP Configuration Assistant）を使用します。

$ su – root

# export PATH=$PATH:$CRS_HOME/bin # vipca

構成ツール vipca の「Welcome」画面が表示されます。

(20)

ここのツールでは、Oracle Cluster Services のインストール時に指定したノード名、IP Alias Name （VIP）、IP アドレス、サブネット・マスクを使用します。

(21)

次の画面に最終結果が表示されます。

注意: VIP Configuration Assistantでエラーが表示された場合は、処理を続行しないでください。

その場合は、ユーザーroot として、次のコマンドでリソースを削除します。

# crs_stop –f <リソース名> # crs_unregister <リソース名>

(22)

SAPインストール用のOracle CRSパラメータ調整

エラー検知およびヘルス・チェック用に使用されるタイミング関連のパラメータは、特にネットワークやディスク I/O などのコンポーネントの動作時間が平均値からの偏差が高く確定的でない場合、複雑な環境でのシステム設定においてデフォルト構成が過度に積極的な（パラメータ設定値がタイト過ぎる）場合があります。

Oracle Clusterware における重要なタイミング関連のパラメータは misscount、disktimeout、 reboottime および diagwait です。 パラメータ disktimeout は OCR リポジトリおよび投票ディスクへの読込み/書込みアクセスの最大 I/O 完了時間を指定します。時間単位は秒です。ノードは 1 つ以上の OCR リポジトリおよび 1 つ以上の投票ディスクにアクセス可能なことが必要です。そうでない場合は、ノードはリブートを発行しクラスタから隔離されます。 パラメータ misscount は、ネットワーク接続を介して実行されるノード間の通信チェックの最大時 間を秒単位で指定します。これによりネットワークの健全度をチェックします。ノードが、 misscount で指定された時間（秒）以内に他のノードに到達できない場合は、スプリット・ブレイ ン解決策を開始し、場合によってはリブートを実行して強制的にクラスタから除外されます。 パラメータ reboottime は推定リブート時間を保持します。デフォルトの値は 3 秒です。これはノー ドが完全に停止するのに必要な推定時間です。 パラメータ diagwait はノードの停止後、再構成が安全に開始できるまでの待機時間（秒）です。 このパラメータは oprocd タイミング値と連携している必要があります。残りのノードが再構成を安全に開始するまでに、停止またはブロックされたノードが oprocd によって（ファスト・リブートを介して）隔離される必要があるためです。ノード停止前に再構成を開始するとデータ整合性が損なわれることがあります。

『Oracle Metalink Note 294430.1「CSS Timeout Computation in RAC 10g (10g Release 1 and 10g release2)」』を参照しパラメータおよびパラメータの相互関係について常に最新の情報を入手し

てください。

crsctl コマンドを実行することで問合せができます。ユーザーroot に切替え、次のコマンドを発行してパラメータの現在値を問い合せます。

% $CRS_HOME/bin/crsctl get css disktimeout

次のコマンドを使用してパラメータを設定します。 % $CRS_HOME/bin/crsctl set css disktimeout 200

パラメータを有効にするには、すべてのノードで CRS を再起動する必要があります。すべてのノードをリブートする方法が最も簡単な方法です。

(23)

まれに OS のスケジュール時間が長いため、Oracle プロセス oprocd のデフォルトのタイミング制約と合わないことがありますが、これにより間違ったノード隔離が行われる原因となることがあります（oprocd によりノードがリブートされます）。

疑わしい場合は、diagwait パラメータを使用して、このプログラムのタイムアウト値を変更することができます（Metalink Note 559365.1 を参照）。oprocd のみでなく Clusterware スタックも、すべてのノードで停止する必要があります。diagwait に対する修正は、crsctl を使用して実行し、 Clusterware を再起動する必要があります。oprocd は、diagwait-reboottime の値をもって起動されます（reboottime のデフォルト値は 3 秒です）。Clusterware の misscount は diagwait よりも大きい値になるようにしてください。diagwait の推奨値は 13 です。

(24)

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

Oracle CRS ソフトウェアが正常にインストールされて起動した後、データベース・ソフトウェアをインストールします。SAP での単一インスタンスのインストールと同様、この作業はユーザー ora<sid>として実行します。このユーザーはグループ dba のメンバーであり、SAP データベース SID のデータベース・ソフトウェアのソフトウェア所有者です。クラスタのノードにユーザーora<sid>が作成されていない場合は、これを作成します。このユーザーはクラスタのすべてのノードで作成することが必要です。ユーザーora<sid>に、クラスタ・ファイル・システム上の共有ホーム・ディレクトリを使用します。これにより管理作業が非常に楽になります。プロファイルの変更は一度の作業でクラスタ内のすべてのノードに適用されます。このホワイト・ペーパーの構成例はすべて、ユーザーora<sid>の共有ホーム・ディレクトリを使用するものとします。前回の SAP インストールによりローカル・ファイル・システム上に、ユーザー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]キーを押します。

この作業をすべてのノードで実行します。キーの生成はノードそのものに依存しているため、必ず各ノードにログオンしてください。すべての秘密鍵ファイルと公開鍵ファイルを生成したうえで、すべてのノードの認証ファイルの場所を記述した構成ファイルを作成します。

(25)

これらの認証ファイルには各ノードの秘密鍵が含まれています。認証ファイルはフルパス名で指定する必要があります。ファイル~/.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 すべての公開鍵を含むファイルをファイル authorized_keys に連結します。 $ cat *.pub > authorized_keys

ファイル権限を変更します。 $chmod 600 config $chmod 600 authorized_keys $cd $chmod 700 .ssh $chmod 755 ∼ これで、パスワードを求められることなく、すべてのホストへの ssh 接続を開くことができます。次のコマンドを実行して試してください。 $ssh <nodename> date ファイル known_hosts にフィンガープリントを記録するため、この作業をすべてのノードで実行します。インストール前のその他の必須条件を Oracle のドキュメントで確認します。Oracle では、インストールに成功するための条件が満たされているか確認するツールを提供しています。このツールは cluvfy というツールで、Oracle ソフトウェアに付属しています。注意: cluvfyを使用して必須条件がすべて満たされていることを確認してください。 Oracle データベース・ソフトウェアのインストールの場合、ユーザーora<sid>がインベントリ・ディレクトリおよびすべてのサブディレクトリへの書込み権限を持っていることを確認してください。すべてのノードで、「chown -R ora<sid>:dba /oracle/oraInventory」を実行してください。このチェックは、Oracle データベース・ソフトウェアにパッチ・セットまたは単一のパッチをインストールする際にも使用します。

(26)

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

インストールを開始します。「Welcome」画面が開きます。

(27)

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

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

(28)

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

(29)

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

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

(30)

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

ここで、データベース・ソフトウェアを最新のパッチ・セットにアップグレードします。現時点での最新のパッチ・セットはリリース 10.2.0.4 です。Oracle Universal Installer により、Oracle Clusterware 用の 10.2.0.4 パッチ・セットをインストールしたときと同じ順序で画面が表示されます。ここまでに示したすべてのスクリーン・ショットを参照してください注意: 共有ORACLE Homeソフトウエア・インストール・ディレクトリを保持するクラスタ・ファイル・システムは、メモリ・マップ・ファイルをサポートすることが必要です。メモリ・マップ・ファイルはCRSによって、実行中のOracleインスタンス健全度の監視に使用されます。プラットフォーム上のクラスタ・ファイル・システムがメモリ・マップ・ファイルをサポートしない場合、メモリ・マップ・ファイルをサポートするローカル・ファイル・システムにシンボリック・リンクを作成してください。メモリ・マップ・ファイルの名称は hc_<INSTANCE_NAME>.dat です。このファイルはディレクトリ$ORACLE_HOME/dbs にあります。ソフトウェアのインストール後、すべてのノードのローカル・ファイル・システム上にローカル・ディレクトリを作成します。ファイル$ORACLE_HOME/dbs/hc_<INSTNAME>.dat をローカル・ディレクトリにコピーします。これをクラスタ内のすべてのノードに対して実行します。その後、ファイル$ORACLE_HOME/dbs/hc_<INSTNAME>.dat を削除します。クラスタ内のすべてのノードに対して、ローカル・ファイル・システムのコピー元を指すシンボリック・リンクを $ORACLE_HOME/dbs に作成します。 ln -s /<local>/hc_<INSTNAME>.dat $ORACLE_HOME/dbs/hc_<INSTNAME>.dat

(31)

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

Oracle Universal Installer によるソフトウェアのインストールの終了後、データベース自体を Oracle Database 10g Release 2 に手動でアップグレードします。前述のチェックの目的は、実際のアップグレード開始前にすべての必須条件が満たされていることを確認して、アップグレード時間を短縮することです。この手順により、アップグレード中にエラーが発生するリスクを低減します。

注意: 使用中のSAPシステムをOracle Database 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/nls/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 に設定されていることを確認します。

RAC 対応の SAP が必要とする単一のサーバー・パラメータ・ファイル spfile.ora を使用している場合は、sqlplus を使用してパラメータの設定を変更します。

$ sqlplus / as sysdba SQL> startup nomount

(32)

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

インスタンスの起動前にパラメータの現在の設定をチェックします。インスタンスをスムーズにエラーなく起動するため、パラメータ・ファイルの非推奨パラメータやサポート対象外のパラメータをすべてコメントアウトします。

これらのパラメータの一覧は、オンライン・ドキュメントのCDにも含まれています。

注意: Oracleネットワーク構成ファイルtnsnames.ora（LOCAL_LISTENERなど）を参照するす

べてのパラメータも、アップグレード実行時にコメントアウトしてください。

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

次のように、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;

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

(33)

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 autoextend on extent management local segment space management auto

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

アップグレードの実行

データベースの Oracle 10g Release 2 へのアップグレードには、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

(34)

このスクリプトが完了すると、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.2 RACに対応済の場合は、この作業を省略できます。 MAXINSTANCES は、将来の拡張を考慮しクラスタ内のノードと同数、またはそれより大きい数に設定します。 MAXLOGFILES は、データベース内で作成できる REDO ログ・ファイル・グループの最大数です。 SAP ソフトウェアのログ・ファイル・グループとメンバーの命名規則に従って、この値は REDO ログ・ファイル・グループの最大の GROUP 値より大きい数値に設定します。

(35)

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

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 の値を修正します。現在のパラメータの値で十分な場合は、制御ファイルのセットを新しく作成する必要はありません。十分でない場合には、パラメータを調整します。パラメータを変更した場合は、トレース・ログ・ファイルに示す手順に従って制御ファイルのセットを新しく作成します。

(36)

例: 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 #

# 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;

(37)

UNDO表領域による自動UNDO管理

オラクルと SAP では、RAC 環境で UNDO 表領域を使用することをお薦めします。ロールバック・セグメントは将来非サポートになる可能性があるため、SAP での RAC 構成では避けてください。

注意: このセクションの内容は、単一インスタンスのデータベースからアップグレードする場合

にのみ適用されます。既存のシステムがOracle 9.2 RACに対応済で、UNDO表領域を使用する

場合は、この作業を省略できます。

次に示す SAP が使用する命名規則に従い、SAP インストールで自動 UNDO 管理を使用する準備をします。

クラスタのインスタンス数に応じて、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 管理とロールバック・セグメントは相互に排他的です。2 つの方法を組み合せて使用できません。自動UNDO表領域を使用するには、クラスタでインスタンスをまったく構成しないか、またはすべてのインスタンスを構成します。注意: UNDO 表領域を使用する場合は、古いロールバック・セグメントを保持する表領域をすべて削除します。これらの表領域をオフライン・モードにはできません。オフライン・モードにした場合、データベースがハングアップする可能性があります。

(38)

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

注意: このセクションの内容は、単一インスタンスのデータベースからアップグレードする場合

にのみ適用されます。既存のシステムがOracle 9.2 RACに対応済の場合は、この作業を省略でき

ます。

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

(39)

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´,

(40)

新しいスレッドを使用するには、それらのスレッドを有効にする必要があります。 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 への問合せを再度実行します。 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 レベルで削除してください。

(41)

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

(42)

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

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

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

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

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

はデフォルトの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 に容易に移行できるからです。計画された 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’;

(43)

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 の有効後に設定注意: 前述の表のパラメータは、データベースのアップグレード後に調整します。アップグレード中は、古い設定を使用します。

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