| Oracle® Grid Infrastructureインストレーション・ガイド 11gリリース2 (11.2) for Linux B56271-15 |
|
 前 |
 次 |
この付録では、Oracle ClusterwareおよびOracle Automatic Storage Managementのアップグレードの実行方法について説明します。
Oracle Clusterwareのアップグレードでは、ローリング・アップグレードが可能です。ローリング・アップグレードでは、他のノードはアクティブなまま、ノードのサブセットを停止してアップグレードします。Oracle Automatic Storage Management 11gリリース2(11.2)のアップグレードでは、ローリング・アップグレードが可能です。ノードのサブセットをアップグレードする場合は、アップグレードの対象として選択しなかった既存のクラスタ・ノードでソフトウェアのみのインストールが実行されます。
この付録の内容は次のとおりです。
Oracleソフトウェアを変更する前に、Oracleソフトウェアおよびデータベースのバックアップを作成することをお薦めします。
Oracle環境変数の設定を削除します。
環境変数にORA_CRS_HOMEを設定した場合は、Oracleサポートの指示に従ってから、インストールまたはアップグレードを開始する前にその設定を削除します。Oracleサポートから明示的に指示がないかぎり、ORA_CRS_HOMEを環境変数として使用しないでください。
インストール所有者のログイン・シェル・プロファイル(.profileや.cshrcなど)にORA_CRS_HOMEが設定されていないことを確認します。
システムに既存のインストールがある場合で、同じユーザー・アカウントを使用してこのインストールを行う場合は、ORA_CRS_HOME、ORACLE_HOME、ORA_NLS10、TNS_ADMIN、およびOracleソフトウェア・ホームに接続されているOracleインストール・ユーザーに設定されているその他の環境変数の設定を削除します。
以前のリリースでは、Oracle Automatic Storage Management(Oracle ASM)はOracle Databaseインストールの一部としてインストールされました。Oracle Database 11gのリリース2(11.2)では、Oracle ASMはOracle Grid Infrastructureコンポーネントをインストールするときにインストールされ、Oracle RACやスタンドアロン・サーバーでOracle RestartとともにクラスタにインストールされたときにOracle ClusterwareとOracleホームを共有します。
既存のOracle ASMインスタンスがある場合は、Oracle Grid Infrastructureをインストールするとき、またはインストール後にOracle ASM Configuration Assistant(ASMCA)を使用してアップグレードできます。ただし、Oracle ASMをアップグレードするまで、多数のOracle ASM機能が無効であることに注意してください。また、Oracle ASMがアップグレードされるまで、Oracle ASMのOracle Clusterware管理は正しく機能しません。これは、Oracle Grid Infrastructureホームで実行されているときのみ、Oracle ClusterwareはOracle ASMを管理するためです。このことから、Oracle Clusterwareのアップグレードと同時にOracle ASMをアップグレードしない場合は、Oracle ASMを直後にアップグレードすることをお薦めします。
Oracle ASM Configuration Assistant(ASMCA)を使用すると、Oracle ASMインスタンスにアウトオブプレース・アップグレードを実行できます。Graphic User Interfaceを使用する以外に、非対話型(サイレント)モードでもASMCAを実行できます。
以前のリリースでは、Oracle DatabaseまたはOracle ASMにアップグレードするためにDatabase Upgrade Assistant(DBUA)を使用できました。現在では使用できません。DBUAを使用できるのは、Oracle Databaseインスタンスをアップグレードするときのみです。Oracle ASMをアップグレードするには、Oracle ASM Configuration Assistant(ASMCA)を使用します。
|
関連項目: 既存のOracle ASMインストールのアップグレードについては、『Oracle Databaseアップグレード・ガイド』および『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
CVUを使用して、既存のOracle Grid Infrastructure 11gリリース2またはOracle RACデータベース11gリリース2のインストールをアップグレードするのに必要なパッチがあるかどうかを確認することをお薦めします。
Oracle ClusterwareおよびOracle Automatic Storage Management (Oracle ASM)で構成されるOracle Grid Infrastructure環境へのアップグレードには、次の制限と変更点があることに注意してください。
既存のOracle ClusterwareインストールをOracle Grid Infrastructure 11gにアップグレードするには、リリースが10.1.0.5、10.2.0.3、11.1.0.6、11.2以上である必要があります。
既存のOracle Grid Infrastructureインストールを11.2.0.2から新しいリリースにアップグレードするには、パッチ11.2.0.2.1(11.2.0.2 PSU 1)以上を適用する必要があります。
Oracle Grid Infrastructure 11g リリース2(11.2.0.1)にOracle ACFSファイル・システムがある場合は、Oracle Grid Infrastructureを新しいバージョン(11.2.0.2または11.2.0.3)にアップグレードし、冗長インターコネクトを使用して、1つ以上のプライベート・インタフェースをプライベート・ネットワークに追加し、その後、アップグレードされた各クラスタ・メンバー・ノードでOracle ASMインスタンスを再起動する必要があります。
Gridホームのディレクトリは削除しないでください。たとえば、Grid_home/OPatchを削除しないでください。このディレクトリを削除すると、グリッド・インフラストラクチャ・インストール所有者はOPatchを使用してGridホームにパッチを適用できず、OPatchによって「checkdirエラー: Grid_home/OPatchを作成できません」というエラーが表示されます。
既存の11.2.0.1 Oracle Grid InfrastructureインストールをOracle Grid Infrastructure 11.2.0.2にアップグレードするには、まず、アップグレードを正常に実行するのに必須のパッチを適用する必要があるかどうかを確認する必要があります。準備状況の確認手順については、第F.6項を参照してください。
既存のOracle Grid Infrastructureを11.2.0.2から11.2.0.3以上にアップグレードするには、パッチ11.2.0.2.1(11.2.0.2 PSU 1)以上を適用する必要があります。
既存の11.1のOracle ClusterwareインストールをOracle Grid Infrastructure 11.2.0.3以上にアップグレードするには、リリース11.1のOracle Clusterwareホームにバグ7308467のパッチを適用する必要があります。
Oracle ClusterwareおよびOracle ASMのアップグレードは、常にアウトオブプレース・アップグレードで行われます。11gリリース2(11.2)では、Oracle ClusterwareおよびOracle ASMのインプレース・アップグレードを既存のホームに対して実行することはできません。
既存のOracle Clusterwareホームが共有ホームの場合、Oracle ClusterwareおよびOracle ASM 11gリリース2(11.2)のクラスタ用Oracle Grid Infrastructureホームに、共有されていないホームを使用できます。
Oracle Clusterware 11g リリース1以上では、Oracle Clusterware 10g ソフトウェアを所有していた同じユーザーがOracle Clusterware 11g のアップグレードを実行する必要があります。Oracle Database 11gより前は、すべてのOracleソフトウェアのインストールをOracleユーザー(通常はoracle)が所有していたか、またはOracle Databaseソフトウェアはoracleが所有し、Oracle Clusterwareソフトウェアは別のユーザー(通常はcrs)が所有していました。
Oracle ASMとOracle Clusterwareの両方がOracle Grid Infrastructureホームで実行されます。
11gリリース2(11.2)へのメジャー・バージョン・アップグレード中、11gリリース2(11.2)のOracle Grid Infrastructureホームにあるソフトウェアは、アップグレードが完了するまで完全には機能しません。最終的にrootupgrade.shスクリプトが実行され、すべてのノードでアップグレードが完了するまで、11gリリース2 (11.2)ホームからのsrvctl、crsctl、その他コマンドの実行はサポートされません。
Oracle Grid Infrastructureのアップグレード中に既存の旧バージョン(リリース10.xまたは11.1)のデータベース・ホームを管理するには、既存のデータベース・ホームからsrvctlを使用します。
Oracle Clusterwareのインストール中に、シングル・インスタンスのOracle ASMがローカル・ノードに存在する場合、そのOracle ASMはクラスタ化されたOracle ASM 11gリリース2(11.2)に変換され、Oracle ASMはすべてのノードのOracle Grid Infrastructureホームで実行されます。
Oracle Clusterware 11gリリース2 (11.2)以上では、共有のOracle Clusterwareホームでアップグレードを実行できます。
ローカル・ノード(Oracle Grid Infrastructureのインストールを実行中のノード)以外のリモート・ノードにシングル・インスタンスの(クラスタ化されていない)Oracle ASMがインストールされている場合は、シングル・インスタンスのOracle ASM環境がそのまま維持されます。ただし、インストール中に、Oracle Cluster Registry(OCR)および投票ディスクのファイルをOracle ASMに置くように選択した場合は、クラスタ化されたOracle ASMのインストール環境がクラスタ内のすべてのノードに作成され、リモート・ノードにインストールされているシングル・インスタンスのOracle ASMは機能しなくなります。
Oracle DatabaseおよびOracle RAC 11gリリース2(11.2)では、Database Configuration Assistantまたはインストーラを使用して、ブロック・デバイスまたはRAWデバイス上にOracle ClusterwareまたはOracle Databaseファイルを格納する処理がサポートされなくなりました。
既存のOracle RACデータベースをアップグレードする場合、またはOracle ASMインスタンスを使用するOracle RACデータベースをアップグレードする場合は、既存のRAWデバイスまたはブロック・デバイスのパーティションを使用して、既存のインストールをローリング・アップグレードできます。ブロック・デバイスまたはRAWデバイスを使用した、新しいインストールは実行できません。
|
関連項目: 『Oracle Databaseアップグレード・ガイド』 |
既存のOracle Clusterwareインストールがある場合は、アウトオブプレース・アップグレードを行うことにより、既存のクラスタをアップグレードします。インプレース・アップグレードは実行できません。
この項の内容は次のとおりです。
アップグレードを開始する前に、次の作業を行います。
各ノードで、クラスタ検証ユーティリティを使用して、インストール前の手順が完了していることを確認します。これは、サーバーの準備をするための修正スクリプトを生成することができます。また、インストーラでは、必要な前提条件をすべて満たしていることが確認されます。
次の情報を含めて、インストール時に必要な情報がすべて揃っていることを確認します。
Oracle ClusterwareのOracleベースの場所。
既存のOracle Clusterwareの場所とは異なる、Oracle Grid Infrastructureホームの場所。
SCANアドレス。
Oracle ASMデータ・ファイルへのアクセス権(ASMグループのOSDBA)、Oracle ASMインスタンスに対する管理権限(OSASMグループ)、Oracle ASMインスタンスに対する管理権限のサブセット(ASMグループのOSOPER)を付与する権限を持つユーザー・オペレーティング・システム・グループ。
インストール中にrootとしてスクリプトを実行するためのrootユーザー・アクセス。
インストールを実行するインストール所有者に関しては、既存のインストールに対して環境変数が設定済の場合は、$ORACLE_HOMEおよび$ORACLE_SIDの設定を解除します。これらの環境設定がアップグレード中に使用されてしまうからです。次に例を示します。
$ unset ORACLE_BASE $ unset ORACLE_HOME $ unset ORACLE_SID
RACcheck (Oracle RAC構成監査ツール)アップグレード準備状況評価は、Oracle Grid Infrastructure 11.2.0.3、11.2.0.4および12.1.0.1にアップグレードする際のアップグレード固有のヘルス・チェックを自動的に行うために使用できます。RACcheck準備状況評価ツールを実行すると、多数のアップグレード前およびアップグレード後のチェックを自動化できます。
My Oracle SupportからRACcheckの最新バージョンをダウンロードして実行することをお薦めします。RACcheck構成監査ツールのダウンロード、構成および実行の詳細は、My Oracle SupportのNote 1457357.1を参照してください(次のURLから入手可能)。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1457357.1
クラスタがアップグレードできる状態であることを検証するには、この項の内容を確認します。
runcluvfy.shコマンドがあるアップグレードのステージング領域に移動し、runcluvfy.sh stage -pre crsinst -upgradeコマンドを実行してアップグレードに対するOracle Clusterwareインストールの準備状況を確認します。-pre crsinst -upgradeフラグを指定してruncluvfy.shを実行すると、既存のクラスタウェア・インストールのアップグレードに対してクラスタが適切な状態にあるかどうかを確認するためのシステム・チェックが実行されます。
このコマンドでは次の構文を使用します。可変的な内容はイタリック体で示されています。
runcluvfy.sh stage -pre crsinst -upgrade [-n node_list] [-rolling] -src_crshome src_Gridhome -dest_crshome dest_Gridhome -dest_version dest_version [-fixup [-fixupdir path]] [-verbose]
オプションは次のとおりです。
-n nodelist
-nフラグはクラスタ・メンバー・ノードを示し、nodelistはアップグレード前の検証を実行する非ドメイン修飾ノード名のカンマ区切りのリストを示します。検証コマンドに-nフラグを追加しない場合は、クラスタ内のすべてのノードが検証されます。runcluvfy.shが実行されているノードでクラスタウェアが停止している場合、-nフラグを追加する必要があります。
-rolling
このフラグを使用すると、ローリング・アップグレードに対する準備状況が検証されます。
-src_crshome src_Gridhome
このフラグは、アップグレードするソースOracle ClusterwareまたはGridホームの場所を指定します(src_Gridhomeはアップグレードするホームへのパス)。
-dest_crshome dest_Gridhome
このフラグは、アップグレードGridホームの場所を指定します(dest_ GridhomeはGridホームへのパス)。
-dest_version dest_version
dest_versionフラグは、パッチセットを含む、アップグレードのリリース番号を指定します。リリース番号には、リリースをプラットフォーム固有のパッチのレベルに指定する5つの数字を含める必要があります。たとえば、11.2.0.2.0などです。
-fixup [-fixupdir path]
-fixupフラグは、クラスタがアップグレードできる状態であることを確認するのに実行する必要がある手順の指示を生成することを指定します。デフォルトの場所は、CVUの作業ディレクトリです。別のディレクトリに修正指示を配置する場合は、-fixupdirフラグを追加して、必要な修正指示を配置するディレクトリ・パスを指定します。
-verbose
-verboseフラグを使用すると、個々のチェックの詳細な出力が生成されます。
次のコマンドを実行すると、Oracle Clusterwareのインストールに必要な権限が、ノードnode1およびnode2で構成されているかどうかを検証できます。
$ ./runcluvfy.sh stage -pre crsinst -upgrade -n node1,node2 -rolling -src_crshome /u01/app/grid/11.2.0.1 -dest_crshome /u01/app/grid/11.2.0.2 -dest_version 11.2.0.3.0 -fixup -fixupdir /home/grid/fixup -verbose
クラスタ検証ユーティリティを使用すると、データベースのアップグレードを開始する前準備として、システムをチェックできます。インストーラによって適切なCVUチェックが自動的に実行され、問題の修正を求めるプロンプトが表示されるか、またはアップグレードを進める前にクラスタ内のすべてのノード上で実行するための修正スクリプトが提供されます。
|
関連項目: 『Oracle Databaseアップグレード・ガイド』 |
Oracle ClusterwareまたはOracle Automatic Storage Managementをアップグレードするには、次の手順を実行します。
|
注意: Oracle Clusterware 11gリリース2(11.2)にアップグレードすると、Oracle Automatic Storage Management(Oracle ASM)がOracle Clusterwareと同じホームにインストールされます。このホームは、Oracleドキュメントでは、Oracle Grid InfrastructureホームまたはGridホームと呼ばれます。また、ローリング・アップグレード中に、ノードをクラスタに追加する操作はサポートされていません。 |
Oracle Clusterwareを前のリリースから新しいリリースにアップグレードするには、次の手順を実行します。
|
注意: Oracle RACインスタンスは、実行したままにしておくことをお薦めします。各ノードでrootスクリプトを起動すると、そのノードのインスタンスが停止され、rootupgrade.shスクリプトによって再度起動されます。リリース11.2.0.1から新しいバージョン(11.2.0.2または11.2.0.3)にアップグレードする場合は、すべてのノードがデフォルトで選択されます。ノードを選択したり、選択解除することはできません。
クラスタ上のシングル・インスタンスのOracle Databaseは、Oracle ASMを使用する場合のみ、停止が必要です。リスナーを停止する必要はありません。 |
インストーラを起動し、インストールされている既存のOracle ClusterwareおよびOracle ASMをアップグレードするオプションを選択します。
ノード選択ページで、すべてのノードを選択します。
指示どおりに、インストール・オプションを選択します。
プロンプトが表示されたら、アップグレードするクラスタ内の各ノード上でrootupgrade.shスクリプトを実行します。
まず、ローカル・ノード上でスクリプトを実行します。このスクリプトは、前のリリースのインストール環境を停止し、新しいOracle Clusterwareリリースに置き換えて、新しいOracle Clusterwareのインストールを開始します。
スクリプトが正常に完了したら、最後のノードとして選択した1つを除いて、すべてのノード上で並行してスクリプトを実行できます。最後のノードを除いたすべてのノード上でスクリプトが正常に実行されたら、最後のノード上でスクリプトを実行します。
クラスタの最後のノードでrootupgrade.shスクリプトを実行した後、11.2.0.1より前のリリースからアップグレードする場合で、チェック・ボックスでASMCAがマークされている(デフォルト)ままにすると、Oracle ASM Configuration Assistantが自動的に実行し、Oracle Clusterwareのアップグレードが完了します。アップグレードのインタビュー・ステージでボックスのマークを外すと、ASMCAは自動的には実行しません。
前のバージョンのOracle Automatic Storage Managementがインストールされている場合、Oracle ASMを11gリリース2(11.2)へアップグレードするために、インストーラによってOracle ASM Configuration Assistantが起動されます。Oracle ASMをこのときにアップグレードするか、または後でアップグレードするか、選択することができます。
Oracle Clusterwareバイナリをアップグレードするのと同時に、Oracle ASMもアップグレードすることをお薦めします。Oracle ASMがアップグレードされるまで、Oracle ASMを使用するOracle Databaseは作成できません。Oracle ASMがアップグレードされるまで、Gridホームにある11gリリース2(11.2)のOracle ASM管理ツール(srvctlなど)は動作しません。
Oracle Grid Infrastructureホームは、以前のOracle ClusterwareホームおよびOracle ASMホームとは異なる場所にあるため、Oracle ClusterwareホームおよびOracle ASMホームにあるユーティリティ、ライブラリなどのファイルを使用するスクリプトまたはアプリケーションを更新します。
|
注意: アップグレードの最後に、OCRのバックアップ場所を前のリリースのOracle Clusterwareホーム(CRSホーム)に手動で設定していた場合は、Oracle Grid Infrastructureホーム(Gridホーム)に変更する必要があります。OCRのバックアップ場所を手動で設定しなかった場合は、この問題は関係がありません。Oracle Clusterwareのアップグレードはアウトオブプレース・アップグレードなので、前のリリースのOracle ClusterwareホームをOCRのバックアップ場所にすることはできません。前のOracle Clusterwareホームにあるバックアップは、削除されることがあります。 |
アップグレードの途中で一部のノードにアクセスできなくなった場合は、アクセスできないノードでアップグレード・スクリプト(rootupgrade.sh)が実行されないため、アップグレードを完了できません。アップグレードが完了していないため、Oracle Clusterwareは以前のリリース・バージョンのままになります。crsctl query crs activeversionコマンドを入力すると、アップグレードが完了していないことを確認できます。
この問題を解決するには、次の構文を使用し、-forceフラグを指定してrootupgrade.shコマンドを実行します。
Grid_home/rootupgrade -force
次に例を示します。
# /u01/app/11.2.0/grid/rootupgrade -force
このコマンドによってアップグレードが強制的に完了されます。crsctl query crs activeversionコマンドを使用して、アップグレードが完了したことを確認します。アクティブなバージョンがアップグレード・リリースになります。
Oracle Clusterware 11gリリース2(11.2)のアップグレードが完了した後、Oracle Clusterwareのアップグレード時にOracle ASMのアップグレードをしなかった場合は、Oracle Automatic Storage Managementコンフィギュレーション・アシスタント(asmca)を使用して、ローリング・アップグレードを別途行うことができます。
asmcaを使用してアップグレードを別途行うことはできますが、Oracle Clusterwareのアップグレード後すぐに行う必要があります。Oracle ASMがアップグレードされるまでsrvctlなどのOracle ASM管理ツールが機能しないためです。
|
注意: 前のバージョンのOracle ASMが11.1.0.6または11.1.0.7の場合のみ、ASMCAによってローリング・アップグレードが行われます。そうでない場合、ASMCAによって通常のアップグレードが行われますが、このアップグレードでは、ASMCAによって、クラスタのすべてのノードにおいて、すべてのOracle ASMインスタンスが停止され、新しいGridホームですべて再起動されます。 |
Oracle ASMのローリング・アップグレードを実行する場合は、次の点に注意してください。
Oracle Clusterwareのアクティブなバージョンが、11gリリース2(11.2)である必要があります。次のコマンドを入力して、アクティブなバージョンを確認します。
$ crsctl query crs activeversion
シングル・インスタンスのOracle ASM環境を、クラスタ化されたOracle ASM環境へアップグレードできます。ただし、シングル・インスタンスの既存のOracle ASM環境をアップグレードできるのは、そのOracle ASM環境があるノードからインストールを実行する場合のみです。リモート・ノードにあるシングル・インスタンスのOracle ASM環境をアップグレードすることはできません。
アップグレード・プロセスを開始する前に、既存のOracle ASM環境で行われているリバランス操作が完了していることを確認する必要があります。
アップグレード・プロセスの進行中は、Oracle ASMインスタンスをアップグレード状態に変更することになります。このアップグレード状態ではOracle ASM操作が制限されるため、アップグレード・プロセスは開始してすぐに完了する必要があります。Oracle ASMインスタンスがアップグレード状態にあるときに可能な操作は、次のとおりです。
ディスク・グループのマウントとマウント解除
データベース・ファイルのオープン、クローズ、サイズ変更または削除
インスタンスのリカバリ
固定ビューおよび固定パッケージの問合せ(固定ビューの問合せと、dbms_diskgroupなどの固定パッケージを使用した匿名PL/SQLブロックの実行は可能です)
Oracle ASMをアップグレードするには、次の手順を実行します。
アップグレードを開始しようとしているノードで、環境変数ASMCA_ROLLING_UPGRADEの値をtrueにします。次に例を示します。
$ export ASMCA_ROLLING_UPGRADE=true
Oracle Grid Infrastructure 11gリリース2(11.2)のホームから、ASMCAを起動します。次に例を示します。
$ cd /u01/11.2/grid/bin $ ./asmca
「アップグレード」を選択します。
ASM Configuration Assistantにより、クラスタ内にあるすべてのノードのOracle ASMが連続してアップグレードされます。
アップグレードが完了したら、コマンドを実行して、ASMCA_ROLLING_UPGRADE環境変数の設定を解除します。
|
関連項目: Oracle ASMのアップグレード計画の準備、およびOracle ASMアップグレードの開始、実行、停止の詳細は、『Oracle Databaseアップグレード・ガイド』および『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle Clusterwareリリース2(11.2)は新しい場所(クラスタ用Oracle Grid Infrastructureホーム、またはGridホーム)でOracle Clusterwareホームをアウトオブプレース・アップグレードしたものであるため、いくつかのパラメータ・ファイルでCRS_HOMEパラメータのパスを変更する必要があります。パラメータを変更しないと、DB ControlまたはGrid Controlで、クラスタ・ターゲットの不正などのエラーが発生します。
この問題を解決するには、次の手順を実行します。
dbconsoleまたはgridconsoleにログインします。
「クラスタ」タブに移動します。
「監視構成」をクリックします。
「Oracleホーム」の値を新しいGridホームのパスで更新します。
以前のリリースからアップグレードした後に、以前のリリースのOracle Grid InfrastructureのGridホームを削除する場合は、まず、以前のリリースのGridホームの権限と所有権を変更する必要があります。このタスクは、次の手順を使用して行います。
rootとしてログインし、次のコマンド構文を使用して以前のリリースのGridホームの権限と所有権を変更します(oldGHは以前のリリースのGridホーム、swownerはOracle Grid Infrastructureインストール所有者、oldGHParentは以前のリリースのGridホームの親ディレクトリです)。
次に例を示します。
#chmod -R 755 /u01/app/11.2.0.1/grid #chown -R grid /u01/app/11.2.0.1/grid #chown grid /u01/app/11.2.0.1
以前のリリースのGridホームの権限と所有権を変更した後、Oracle Grid Infrastructureインストール所有者(前述の例ではgrid)としてログインし、11.2.0.2.0のスタンドアロン削除ツールを使用して、以前のリリースのGridホーム(oldGH)を削除します。
スタンドアロン削除ツールは、次のURLから入手できます。
http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html
ご使用のオペレーティング・システム・プラットフォームに対応するダウンロードの「すべて見る」リンクをクリックして、削除ユーティリティ用のダウンロードのリストを調べます。
Oracle Clusterware 11gリリース2 (11.2)へのアップグレードが成功または失敗した後で、Oracle Clusterwareを前のバージョンにリストアすることができます。
この項のリストア手順では、Oracle Clusterwareの構成をOracle Clusterware 11gリリース2 (11.2)にアップグレードする前の状態にリストアします。Oracle Grid Infrastructure 11gリリース2 (11.2)のアップグレードの最中または後で行った変更はすべて消去され、リカバリされません。
次の手順にあるローカル・ノードは、rootupgradeスクリプトが実行された最初のノードです。リモート・ノードは、アップグレードされたその他のすべてのノードです。
Oracle Clusterwareを前のリリースにリストアするには、次の手順を実行します。
ダウングレード先のリリース用のダウングレード手順を使用します。
11gリリース2(11.2.0.1)より前のリリースにダウングレードする場合:
すべてのリモート・ノード上で、コマンド構文Grid_home/perl/bin/perl rootcrs.pl -downgrade [-force]を使用して、11gリリース2(11.2)リソースを停止し、11gリリース2(11.2)スタックを停止します。
|
注意: このコマンドによってOCRがリセットされたり、ocr.locが削除されたりすることはありません。 |
コマンド構文は次のとおりです。
# /u01/app/11.2.0/grid/perl/bin/perl rootcrs.pl -downgrade -oldcrshome -version
次に例を示します。
# /u01/app/11.2.0/grid/perl/bin/perl rootcrs.pl -downgrade -oldcrshome /u01/app/crs -version 11.1.0.1.0
|
注意: Oracle Clusterwareのバージョン・フォーマットが正しく指定されているようにします。たとえば、11.1.0.1.0です。 |
11gリリース2 (11.2)の部分的なインストールまたは失敗したインストールを停止し、Oracle Clusterwareの以前のリリースをリストアするには、このコマンドで-forceフラグを使用します。
11.2.0.1以上のリリースにダウングレードする場合:
コマンド構文Grid_home/perl/bin/perl rootcrs.pl -downgrade -oldcrshome oldGridHomePath -version oldGridversionを使用します(oldGridhomepathは以前のリリースのOracle Grid Infrastructureホームへのパス、oldGridversionはダウングレード先のリリース)。次に例を示します。
# /u01/app/11.2.0/grid/perl/bin/perl rootcrs.pl -downgrade -oldcrshome /u01/app/11.2.0/grid -version 11.2.0.1.0
11gリリース2(11.2)の部分インストールまたは失敗したインストールを停止して、以前のリリースのOracle Clusterwareをリストアする場合は、このコマンドで-forceフラグを使用します。
rootcrs.pl -downgradeスクリプトをすべてのリモート・ノードで実行し終わったら、ローカル・ノードでコマンド構文Grid_home/crs/install/rootcrs.pl -downgrade -lastnode -oldcrshome pre11.2_crs_home -version pre11.2_crs_version [-force]を使用します。pre11.2_crs_homeは前のOracle Clusterwareインストールのホーム、pre11.2_crs_versionは前のOracle Clusterwareインストールのリリース番号です。
次に例を示します。
# /u01/app/11.2.0/grid/perl/bin/perl rootcrs.pl -downgrade -lastnode -oldcrshome /u01/app/crs -version 11.1.0.6.0
このスクリプトは、OCRをダウングレードします。11gリリース2 (11.2)の部分的なインストールまたは失敗したインストールを停止し、Oracle Clusterwareの以前のリリースをリストアするには、このコマンドで-forceフラグを使用します。
グリッド・インフラストラクチャのインストール所有者としてログインし、次のコマンドを実行します(/u01/app/gridは新しい(アップグレードされた) Gridホーム(11.2)です)。
.Grid_home/oui/bin/runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=false ORACLE_HOME=/u01/app/grid
グリッド・インフラストラクチャのインストール所有者として、コマンド./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=true ORACLE_HOME=pre11.2_crs_homeを実行します(pre11.2_crs_homeは以前のOracle Clusterwareインストールのホーム・ディレクトリを表します)。
次に例を示します。
.Grid_home/oui/bin/runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=true ORACLE_HOME=/u01/app/crs
11.2以上のリリースにダウングレードする場合
Oracle Grid Infrastructureリリース2 (11.2.0.4)を以前のリリースの11.2にダウングレードする場合、すべてのクラスタ・ノードでrootupgrade.shの実行を完了し、次のコマンドを11.2.0.4 Gridホームから実行します。
acfsroot uninstall
以前のリリースのGridホームから、特権ユーザー(root)として次のコマンドを実行します。
acfsroot install
各ノードで、crsctl start crsコマンドを使用して前のリリースのOracle ClusterwareホームからOracle Clusterwareを起動します。たとえば、前のリリースのホームがcrshome11202である場合は、各ノードで次のコマンドを使用します。
crshome11202/bin/crsctl start crs
11.1以下のリリースにダウングレードする場合
クラスタの各メンバー・ノード上で順に、前のリリースのOracle Clusterwareインストールのホームからroot.shを実行するようプロンプトが表示されます。この作業が終了したら、ダウングレードは完了です。
前のリリースのOracle Clusterwareインストールのホームからroot.shを実行することにより、Oracle Clusterwareスタックが再起動され、以前に古いバージョンでOracle Clusterwareに登録されていたすべてのリソースが起動され、そして前のリリースのOracle Clusterwareスタックを実行するように古い初期化スクリプトが構成されます。
次の環境変数がダウングレード先のリリースのディレクトリを指定するように変更します。
ORACLE_HOME
PATH
oratabファイル、およびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、ダウングレードされたOracleホームを指していることを確認する必要があります。
IPD/OSを使用する以前のリリースからOracle Grid Infrastructureリリース2(11.2.0.2以上)にアップグレードする場合は、クラスタ状態モニターのリポジトリ・サイズ(CHMリポジトリ)を確認する必要があります。CHMリポジトリの要件を確認し、より大規模なCHMリポジトリを保持する場合はリポジトリ・サイズを大きくすることをお薦めします。
|
注意: Oracle Grid Infrastructureのインストール時に各ノードでroot.shスクリプトを実行すると、以前のIPD/OSリポジトリは削除されます。
クラスタ状態モニターは、IBM: Linux on System z構成では使用できません。 |
デフォルトでは、リリース11.2.0.3以上のCHMリポジトリのサイズは、最小で1GBまたは3600秒(1時間)です。リリース11.2.0.2および11.2.0.3の場合、クラスタのサイズにかかわらず、CHMリポジトリは1GBです。
CHMリポジトリを大きくするには、次のコマンド構文を使用します。RETENTION_TIMEはCHMリポジトリのサイズ(秒数)です。
oclumon manage -repos resize RETENTION_TIME
RETENTION_TIMEは、3600(1時間)より大きく、259200(3日)より小さい値である必要があります。CHMリポジトリ・サイズを大きくする場合は、クラスタのノードごとに選択するリポジトリ・サイズに使用できるローカル領域があることを確認する必要があります。十分な領域がない場合は、リポジトリを共有ストレージに移動できます。
たとえば、リポジトリ・サイズを4時間に設定するとします。
$ oclumon manage -repos resize 14400
