| Oracle® Grid Infrastructureインストレーション・ガイド 12cリリース1 (12.1) for HP-UX Itanium E52983-07 |
|
 前 |
 次 |
この付録では、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_HOME/binパスがPATH環境変数から削除されていることを確認します。
次のいずれかの方法で、Oracle Grid Infrastructureをアップグレードできます。
クラスタ内の他のノードのOracle Grid Infrastructureを停止せずに個々のノードをアップグレードする、ローリング・アップグレード
1つを除くすべてのノードを停止する、非ローリング・アップグレード。アップグレードを開始するノードでrootスクリプトが古いOracle Clusterwareスタックを停止して新しいOracle Clusterwareスタックを起動する間、クラスタ全体が停止します。アップグレードが完了した後、新しいOracle Clusterwareがすべてのノードで起動します。
1つ以上のノードがアップグレード中のときは一部のサービスが無効になります。すべてのアップグレードはアウトオブプレース・アップグレードですが、これは、以前のリリースで使用されたGridホームとは異なるGridホームにソフトウェア・バイナリが配置されることを意味します。
Oracle Grid Infrastructure 12cリリース1 (12.1)から、以前のリリースのOracle Grid Infrastructureにダウングレードできます。以前のリリースにダウングレードする場合、クラスタは以前のそのリリースの構成要件に準拠する必要があり、クラスタで利用できる機能は以前のそのリリースのOracle ClusterwareとOracle ASMで利用できる機能のみとなることに注意してください。
既存のOracle ASM 11gリリース1 (11.1)または10gリリースのインスタンスがあり、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 11gリリース2 (11.2)以上には該当しません(Oracle Grid InfrastructureホームにOracle ASMバイナリも含まれるため)。
Oracle ASM Configuration Assistant(ASMCA)を使用すると、Oracle ASMインスタンスにアウトオブプレース・アップグレードを実行できます。グラフィカル・ユーザー・インタフェースを使用する以外に、非対話型(サイレント)モードでもASMCAを実行できます。
|
注意: クラスタのバックアップ・ファイルを使用する前に、アップグレードを完了する必要があります。アップグレードが完了していないクラスタのバックアップは使用できません。 |
|
関連項目: 既存のOracle ASMインストールのアップグレードについては、『Oracle Databaseアップグレード・ガイド』および『Oracle Database Storage管理者ガイド』を参照してください。 |
Oracle Grid Infrastructure 11gからOracle Grid Infrastructure 12cへのアップグレード・オプションには次のものがあります。
クラスタ内の他のノードのOracle Grid Infrastructureを停止せずに個々のノードをアップグレードする、Oracle Grid Infrastructureのローリング・アップグレード
クラスタを停止せず、クラスタ全体をアップグレードするOracle Grid Infrastructureのローリングではないアップグレード
Oracle Grid Infrastructure 11gリリース2 (11.2)より前のリリースからOracle Grid Infrastructure 12cへのアップグレード・オプションには次のものがあります。
Oracle Grid Infrastructureのローリング・アップグレード(OCRと投票ディスクはOracle ASM以外の記憶域上にある)
Oracle Grid Infrastructureのクラスタ全体のアップグレード(停止時間、非ローリング)(OCRと投票ディスクはOracle ASM以外の記憶域上にある)
Oracle Grid Infrastructure 11gリリース2(11.2)からOracle Grid Infrastructure 12cへのアップグレード・オプションには次のものがあります。
Oracle Grid Infrastructureのローリング・アップグレード(OCRと投票ディスクはOracle ASMまたは共有ファイル・システム上にある)
Oracle Grid Infrastructureのクラスタ全体のアップグレード(停止時間、非ローリング)(OCRと投票ディスクはOracle ASMまたは共有ファイル・システム上にある)
Oracle Grid Infrastructure 12cから以前のリリースへのダウングレード・オプションには次があります。
Oracle Grid Infrastructure 11gリリース2 (11.2)へのOracle Grid Infrastructureのダウングレード
Oracle Grid Infrastructure 11gリリース2 (11.2)より前のリリースであるOracle Grid Infrastructure 11gリリース1 (11.1)、Oracle ClusterwareおよびOracle ASM 10gへのOracle Grid Infrastructureのダウングレード(OCRと投票ファイル用の記憶域がOracle ASM以外の記憶域上にある場合)
クラスタ検証ユーティリティ・ツール(CVU)を使用して、既存のOracle Grid Infrastructure 11gリリース2 (11.2)またはOracle RACデータベース11gリリース2 (11.2)のインストールをアップグレードするために必要なパッチがあるかどうかを確認することをお薦めします。
Oracle ClusterwareおよびOracle Automatic Storage Management(Oracle ASM)で構成されるOracle Grid Infrastructure環境へのアップグレードには、次の制限と変更点があることに注意してください。
Oracle Grid Infrastructure 11gまたはOracle ClusterwareおよびOracle ASM 10gリリースの標準クラスタから、Oracle Grid Infrastructure 12cリリース1 (12.1)のOracle Flex Cluster構成へのアップグレードはサポートされません。
現在のインストールのOracle Cluster Registry(OCR)および投票ファイルの場所がRAWまたはブロック・デバイス上にある場合は、Oracle Grid Infrastructure 12 cにアップグレードする前に、これらをOracle ASMディスク・グループまたは共有ファイル・システムに移行する必要があります。
Oracle Grid Infrastructure 12cリリース1 (12.1)のOracle Flex Cluster構成から標準クラスタ構成へのダウングレードはサポートされません。Oracle Grid Infrastructure 12cより前のリリースのクラスタ構成はすべて、標準クラスタ構成です。このダウングレードの制限には、Oracle Flex ClusterからOracle Grid Infrastructure 11gのクラスタまたはOracle ClusterwareおよびOracle ASM 10gのクラスタへのダウングレードが含まれます。
アップグレードした元のOracle Grid Infrastructureのリリースにダウングレードできます。たとえば、Oracle Grid Infrastructure 11gリリース2 (11.2)からOracle Grid Infrastructure 12cリリース1 (12.1)にアップグレードした場合、Oracle Grid Infrastructure 11gリリース2 (11.2)にのみダウングレードできます。
アップグレードすると、常に標準クラスタになります。クラスタ・メンバー・ノードの役割をリーフに変更するには、すべてのOracle Grid InfrastructureノードをOracle Grid Infrastructure 12cリリース1 (12.1)以上にアップグレードし、アクティブなリリースをOracle Grid Infrastructure 12cリリース1 (12.1)以上にアップグレードする必要があります。
Oracle Grid Infrastructure 11gリリース2 (11.2)より前のOracle Grid Infrastructureリリースをアップグレードするときに、OCRと投票ディスク・ファイルがRAWまたはブロック・デバイス上にあり、これらのファイルを共有ファイル・システムではなく、Oracle ASMに移行する場合は、Oracle Grid Infrastructure 12cにアップグレードする前に、Oracle Grid Infrastructure 11gリリース2 (11.2)にアップグレードする必要があります。
既存のOracle Clusterwareインストールを標準構成のOracle Grid Infrastructure 12cのクラスタにアップグレードするには、リリースがOracle Clusterware 10gリリース1 (10.1.0.5)、Oracle Clusterware 10gリリース2 (10.2.0.3)、Oracle Grid Infrastructure 11gリリース1 (11.1.0.6)、Oracle Grid Infrastructure 11gリリース2 (11.2)以上である必要があります。
既存のOracle Grid InfrastructureインストールをOracle Grid Infrastructure 11gリリース2 (11.2.0.2)から新しいリリースにアップグレードするには、パッチ11.2.0.2.3 (11.2.0.2 PSU 3)以上を適用する必要があります。
既存のOracle Grid InfrastructureインストールをOracle Grid Infrastructure 12cリリース1 (12.1)にアップグレードするには、まず、アップグレードを正常に実行するのに必須のパッチを適用する必要があるかどうかを確認する必要があります。準備状況の確認手順については、第B.6.1項を参照してください。
|
関連項目: 「Oracle 12c Upgrade Companion」(My Oracle SupportのNote 1462240.1):
|
Oracle ClusterwareおよびOracle ASMのアップグレードは、常にアウトオブプレース・アップグレードで行われます。既存のホームへのOracle ClusterwareおよびOracle ASMのインプレース・アップグレードは実行できません。
既存のOracle Clusterwareホームが共有ホームの場合、Oracle ClusterwareおよびOracle ASM 12cリリース1 (12.1)のクラスタ用Oracle Grid Infrastructureホームに、共有されていないホームを使用できます。
以前のリリースのOracle Grid Infrastructureソフトウェアを所有していた同じユーザーが、Oracle Grid Infrastructure 12cリリース1 (12.1)アップグレードを実行する必要があります。Oracle Database 11gの前は、すべてのOracleソフトウェアのインストールをOracleユーザー(通常はoracle)が所有していたか、またはOracle Databaseソフトウェアはoracleが所有し、Oracle Clusterwareソフトウェアは別のユーザー(通常はcrs)が所有していました。
Oracle ASMとOracle Clusterwareの両方がOracle Grid Infrastructureホームで実行されます。
Oracle Grid Infrastructure 12cリリース1 (12.1)へのメジャー・リリース・アップグレード中、12cリリース1 (12.1)のOracle Grid Infrastructureホームにあるソフトウェアは、アップグレードが完了するまで完全には機能しません。最終的にrootupgrade.shスクリプトが実行され、すべてのノードでアップグレードが完了するまで、新しいGridホームからのsrvctl、crsctl、その他コマンドの実行はサポートされません。
Oracle Grid Infrastructureのアップグレード中に既存の旧リリースのデータベース・ホームのデータベースを管理するには、既存のデータベース・ホームからsrvctlを使用します。
共有Oracle Clusterwareホームでアップグレードを実行できます。
Oracle Clusterwareのインストール中に、シングル・インスタンスのOracle ASMリリースがローカル・ノードに存在する場合、そのOracle ASMはクラスタ化されたOracle ASM 12cリリース1 (12.1)に変換され、Oracle ASMはすべてのノードのOracle Grid Infrastructureホームで実行されます。
ローカル・ノード(Oracle Grid Infrastructureのインストールを実行中のノード)以外のリモート・ノードにシングル・インスタンスの(クラスタ化されていない)Oracle ASMがインストールされている場合は、シングル・インスタンスのOracle ASM環境がそのまま維持されます。ただし、インストール中に、Oracle Cluster Registry(OCR)および投票ディスクのファイルをOracle ASMに置くように選択した場合は、クラスタ化されたOracle ASMのインストール環境がクラスタ内のすべてのノードに作成され、リモート・ノードにインストールされているシングル・インスタンスのOracle ASMは機能しなくなります。
|
関連項目: アップグレードの準備の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。 |
既存のOracle Clusterwareインストールがある場合は、アウトオブプレース・アップグレードを行うことにより、既存のクラスタをアップグレードします。インプレース・アップグレードは実行できません。
アップグレードを開始する前に、次の作業を行います。
各ノードで、クラスタ検証ユーティリティを使用して、インストール前の手順が完了していることを確認します。これは、サーバーの準備をするための修正スクリプトを生成することができます。また、インストーラでは、必要な前提条件をすべて満たしていることが確認されます。
次の情報を含めて、インストール時に必要な情報がすべて揃っていることを確認します。
インストールを実行するインストール所有者に関しては、既存のインストールに対して環境変数が設定済の場合は、$ORACLE_HOMEおよび$ORACLE_SIDの設定を解除します。これらの環境設定がアップグレード中に使用されてしまうからです。次に例を示します。
$ unset ORACLE_BASE $ unset ORACLE_HOME $ unset ORACLE_SID
ORAchk (Oracle RAC構成監査ツール)アップグレード準備状況評価は、Oracle Grid Infrastructure 11.2.0.3、11.2.0.4および12.1.0.1にアップグレードする際のアップグレード固有のヘルス・チェックを自動的に行うために使用できます。ORAchkアップグレード準備状況評価ツールを実行すると、手動によるアップグレード前およびアップグレード後のチェックの多くを自動化できます。
My Oracle SupportからORAchkの最新バージョンをダウンロードして実行することをお薦めします。ORAchk構成監査ツールのダウンロード、構成および実行の詳細は、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 [-rolling] -src_crshome src_Gridhome -dest_crshome dest_Gridhome -dest_version dest_release [-fixup][-method {sudo|root} [-location dir_path] [-user user_name]] [-verbose]
オプションは次のとおりです。
-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 fixupdirpath]
-fixupフラグは、クラスタのアップグレードの準備ができていることを確認するために実行が必要な必須手順に関する命令を生成することを示すために使用します。デフォルトの場所は、CVUの作業ディレクトリです。別のディレクトリに修正指示を配置する場合は、-fixupdirフラグを追加して必要な修正の指示を配置するディレクトリへのパスを指定します。
-verbose
-verboseフラグを使用すると、個々のチェックの詳細な出力が生成されます。
次のコマンドを実行すると、Oracle Clusterwareのインストールに必要な権限が構成されているかどうかを検証できます。
$ ./runcluvfy.sh stage -pre crsinst -upgrade -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 RACインスタンスは、実行したままにしておくことをお薦めします。各ノードでrootスクリプトを起動すると、そのノードのデータベース・インスタンスが停止され、rootupgrade.shスクリプトによってインスタンスは再度起動されます。Oracle Grid Infrastructure 11gリリース11.2.0.2以上をOracle Grid Infrastructureの任意の新しいリリースにアップグレードする場合は、すべてのノードがデフォルトでアップグレード対象として選択されます。
rootユーザーの自動化を使用して、アップグレード時のrootupgrade.shスクリプトの実行を自動化できます。rootの自動化を使用すると、ノードをグループ(バッチ)に分けてこれらのバッチのアップグレードを開始できます。バッチ間で、以前のリリースを実行しているノードからアップグレード済のノードにサービスを移動して、サービスがアップグレードの影響を受けないようにできます。rootの自動化を使用して、rootupgrade.shスクリプトがインスタンスを自動的に停止および起動できるようにすることをお薦めします。引き続きrootスクリプトを手動で実行することもできます。
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 ASMをアップグレードするオプションを選択します。
ノード選択ページで、すべてのノードを選択します。
指示どおりに、インストール・オプションを選択します。rootスクリプトの自動化を構成して、アップグレード中にrootupgrade.shスクリプトが自動的に実行されるようにすることをお薦めします。
rootスクリプトを自動的に、または手動で実行します。
rootスクリプトを自動的に実行する場合
rootスクリプトの自動化を構成した場合は、以前のリリースを実行しているノードから新しいリリースにサービスを再配置するために、バッチ間で一時停止を使用します。
rootスクリプトを手動で実行する場合
rootスクリプトの自動化を構成していない場合は、プロンプトに従って、アップグレードするクラスタ内の各ノードでrootupgrade.shスクリプトを実行します。
rootスクリプトを手動で実行する場合は、最初にローカル・ノードでスクリプトを実行します。このスクリプトは、前のリリースのインストール環境を停止し、新しいOracle Clusterwareリリースに置き換えて、新しいOracle Clusterwareのインストールを開始します。
スクリプトが正常に完了したら、最後のノードとして選択した1つを除いて、すべてのノード上で並行してスクリプトを実行できます。最後のノードを除いたすべてのノード上でスクリプトが正常に実行されたら、最後のノード上でスクリプトを実行します。
クラスタ内の最後のノードでrootupgrade.shスクリプトを実行した後、Oracle Grid Infrastructure 11gリリース2 (11.2.0.1)よりも前のリリースからアップグレードしている場合にASMCAというラベルのチェックボックスが選択されている(デフォルト)ままにすると、Oracle Automatic Storage Management Configuration Assistant (ASMCA)が自動的に実行し、Oracle Grid Infrastructureのアップグレードが完了します。アップグレードのインタビュー・ステージでボックスの選択を解除すると、ASMCAは自動的には実行しません。
前のリリースのOracle Automatic Storage Management(Oracle ASM)がインストールされている場合、Oracle ASMを12cリリース1 (12.1)へアップグレードするために、インストーラによってASMCAが起動されます。Oracle ASMをこのときにアップグレードするか、または後でアップグレードするか、選択することができます。
Oracle Clusterwareバイナリをアップグレードするのと同時に、Oracle ASMもアップグレードすることをお薦めします。Oracle ASMがアップグレードされるまで、Oracle ASMを使用するOracle Databaseインストールはインストールできません。Oracle ASMがアップグレードされるまで、Gridホームにある12cリリース1 (12.1)のOracle ASM管理ツール(srvctlなど)は動作しません。
Oracle Grid Infrastructureホームは、以前のOracle ClusterwareホームおよびOracle ASMホームとは異なる場所にあるため、Oracle ClusterwareホームおよびOracle ASMホームにあるユーティリティ、ライブラリなどのファイルを使用するスクリプトまたはアプリケーションを更新します。
|
注意: アップグレードの最後に、Oracle Cluster Registry (OCR)のバックアップ場所を前のリリースのOracle Clusterwareホーム(CRSホーム)に手動で設定していた場合は、新しいOracle Grid Infrastructureホーム(Gridホーム)に変更する必要があります。OCRのバックアップ場所を手動で設定しなかった場合は、アップグレード中にバックアップ場所が変更されます。Oracle Clusterwareのアップグレードはアウトオブプレース・アップグレードなので、前のリリースのOracle Clusterwareホームを現在のリリースのOCRのバックアップ場所にすることはできません。以前のOracle Clusterwareホーム内のバックアップは削除できます。 |
アップグレードの途中で一部のノードにアクセスできなくなった場合は、アクセスできないノードでアップグレード・スクリプト(rootupgrade.sh)が実行されないため、アップグレードを完了できません。アップグレードが完了していないため、Oracle Clusterwareは以前のリリースのままになります。crsctl query crs activeversionコマンドを入力すると、アップグレードが完了していないことを確認できます。
この問題を解決するには、rootupgrade.shスクリプトがすでに完了しているノードのいずれかで、-forceフラグを指定してrootupgrade.shコマンドを実行します。
Grid_home/rootupgrade -force
次に例を示します。
# /u01/app/12.1.0/grid/rootupgrade -force
このコマンドによってアップグレードが強制的に完了されます。crsctl query crs activeversionコマンドを使用して、アップグレードが完了したことを確認します。アクティブなリリースはアップグレード・リリースです。
クラスタの強制アップグレード・コマンドには、次の制限があります。
すべてのアクティブ・ノードが新しいリリースにアップグレードされる必要があります。
すべての非アクティブ・ノード(アクセス可能またはアクセス不可能)は、アップグレードされても、アップグレードされなくてもどちらでもかまいません。
強制コマンドを実行した後、アクセスできないノードには次の制限があります。
パッチ・セット・アップグレードの後は、ノードをクラスタから削除できます。ノードが後でアクセス可能になり、パッチ・リリース・アップグレードのパスがサポートされる場合は、このノードを新しいパッチ・リリースにアップグレードできます。
以前のリリースでは、アクセスできないノードを削除する必要がありましたが、Oracle Grid Infrastructure 12cからは、クラスタの強制アップグレード・コマンドの完了後にそのようなノードをクラスタに統合できます。このオプションを使用するには、Oracle Grid Infrastructure 12cリリース1 (12.1)ソフトウェアがノードにインストールされている必要があります。
アクセス不可または接続不可なノードをアップグレードするには、次の手順を実行します。
クラスタに追加するノードで、グリッド・ユーザーとしてログインします。
Oracle Grid Infrastructure 12cリリース1 (12.1)のGridホームで/crs/installディレクトリに移動します。次に例を示します。
$ cd /u01/12.1.0/grid/crs/install
次のPERLコマンドを実行します。existingnodeはコマンドを実行しているクラスタ内のノード、upgraded_nodeはクラスタに統合する、アクセスできないノードまたは到達できないノードです。
$ rootcrs.sh -join -existingnode upgraded_node
|
注意: リリース11.2.0.1.0より前のOracle Clusterwareでは、-join操作はサポートされていません。その場合はノードを削除し、addNodeコマンドを使用してクラスタウェアに追加します。 |
最初のノードにアクセスできなくなった場合、別のノードを、インストールまたはアップグレードに使用する最初のノードに強制的に設定することができます。インストール時に、最初のノードでroot.shが失敗した場合、-forceオプションを使用して、別のノードで次のコマンドを実行します。
root.sh -force -first
アップグレードするには、次のコマンドを実行します。
rootupgrade.sh -force -first
Oracle ASMのローリング・アップグレード・オプションの詳細は、次の各項を参照してください。
Oracle Grid Infrastructure 12cリリース1 (12.1)アップグレードのOracle Clusterwareの部分が完了した後、次の状況でOracle ASMを個別にアップグレードする必要がある場合があります。
Oracle ASM 10gリリース2 (10.2)またはOracle ASM 11gリリース1 (11.1)など、Oracle ASMが別のOracleホームにあるリリースからアップグレードする場合
Oracle Grid InfrastructureのアップグレードがOracle ASMの部分で失敗した場合や、他の理由でAutomatic Storage Management Configuration Assistant(asmca)が実行されなかった場合
asmcaを使用するとアップグレードを別途行うことはできますが、Oracle ASMがアップグレードされるまでsrvctlなどのOracle ASM管理ツールは機能しないため、Oracle Clusterwareのアップグレード後にすぐに行う必要があります。
|
注意: ASMCAによってローリング・アップグレードが実行されるのは、Oracle ASMの以前のリリースが11.1.0.6または11.1.0.7の場合のみです。そうでない場合、ASMCAによって通常のアップグレードが行われます。このアップグレードでは、ASMCAによって、クラスタのすべてのノードにおいて、すべてのOracle ASMインスタンスが停止され、新しいGridホームですべて再起動されます。 |
Oracle Grid Infrastructure 12cリリース1でOracle ASMをアップグレードした後、Oracle ASMの個々のパッチをOracle Automated Release Updateサイトからダウンロードしてインストールできます。
個々のパッチは個別パッチと呼ばれます。Oracle ASMの個別パッチは、特定のリリース済リリースのOracle ASM向けに用意されています。必要なパッチが使用可能である場合は、パッチをダウンロードし、OPatchユーティリティを使用してOracle ASMに適用できます。OPatchインベントリでは、Oracle ASMリリース用にインストールしたパッチが記録されます。インストール済のパッチと、適用するパッチの間に競合がある場合は、OPatchユーティリティからこれらの競合について通知されます。
Oracle Grid Infrastructureのソフトウェア・パッチ・レベルは、Oracle ASMを含むOracle Grid Infrastructureソフトウェア・リリースに適用される、すべての個別パッチのセットを表します。リリースとはリリース番号であり、メジャー、マイナー、パッチ・セットのリリースの形式です。たとえば、リリース番号が12.1.0.1である場合は、メジャー・リリースが12、マイナー・リリースが1、0.0がパッチ・セット番号です。個別パッチでは、メジャーおよびマイナー・リリースは変わりませんが、パッチ・レベルは個別パッチの適用またはロールバックのたびに変更されます。
Oracle Grid Infrastructureの標準アップグレードと同様、クラスタの正常な稼働には、どの時点でもクラスタ内のすべてのノードのソフトウェア・リリースおよびパッチ・レベルが同じである必要があります。個別パッチはローリング・アップグレードとして適用できるため、特定のソフトウェア・リリースのすべてのパッチ・レベルは相互に互換性があります。
Oracle ASMのアップグレードを個別に完了する必要がある場合は、次の要件に注意してください。
Oracle Clusterwareのアクティブなリリースは、12cリリース1 (12.1)である必要があります。アクティブなリリースを確認するには、次のコマンドを入力します。
$ crsctl query crs activeversion
シングル・インスタンスのOracle ASM環境を、クラスタ化されたOracle ASM環境へアップグレードできます。ただし、シングル・インスタンスの既存のOracle ASM環境をアップグレードできるのは、そのOracle ASM環境があるノードからインストールを実行する場合のみです。リモート・ノードにあるシングル・インスタンスのOracle ASM環境をアップグレードすることはできません。
アップグレード・プロセスを開始する前に、既存のOracle ASM環境で行われているリバランス操作が完了していることを確認する必要があります。
アップグレード・プロセスの進行中は、Oracle ASMインスタンスをアップグレード状態に変更することになります。データベース・クライアントは、Oracle ACFS上にある場合を除き、停止する必要はありません。ただし、このアップグレード状態ではOracle ASM操作が制限されるため、アップグレード・プロセスは開始してすぐに完了する必要があります。Oracle ASMインスタンスがアップグレード状態にあるときに可能な操作は、次のとおりです。
ディスク・グループのマウントとマウント解除
データベース・ファイルのオープン、クローズ、サイズ変更または削除
インスタンスのリカバリ
固定ビューおよび固定パッケージの問合せ(固定ビューの問合せと、dbms_diskgroupなどの固定パッケージを使用した匿名PL/SQLブロックの実行は可能です)
別のOracleホームにOracle ASMがインストールされたOracle ASMリリースからアップグレードする必要がある場合、またはOracle Grid InfrastructureのOracle ASMの部分が完了しなかった場合、次の作業を行います。
アップグレードを開始しようとしているノードで、環境変数ASMCA_ROLLING_UPGRADEの値をtrueにします。次に例を示します。
$ export ASMCA_ROLLING_UPGRADE=true
Oracle Grid Infrastructure 12cリリース1 (12.1)のホームから、ASMCAを起動します。次に例を示します。
$ cd /u01/12.1/grid/bin $ ./asmca
「アップグレード」を選択します。
ASM Configuration Assistantにより、クラスタ内にあるすべてのノードのOracle ASMが連続してアップグレードされます。
アップグレードが完了したら、コマンドを実行して、ASMCA_ROLLING_UPGRADE環境変数の設定を解除します。
|
関連項目: Oracle ASMのアップグレード計画の準備、およびOracle ASMアップグレードの開始、実行、停止の詳細は、『Oracle Databaseアップグレード・ガイド』および『Oracle Database Storage管理者ガイド』を参照してください。 |
Oracle Grid Infrastructure 12cリリース1 (12.1)以上では、「ローリング・パッチ」と呼ばれる新しいクラスタ状態が使用可能です。このモードは、この休止状態でOracle ASM操作が許可されるという点で、既存の「ローリング・アップグレード」モードに類似しています。
適用するパッチをMy Oracle Supportからダウンロードします。
「パッチと更新版」タブを選択してパッチを検索します。
「推奨パッチ・アドバイザ」を選択して、ご使用のソフトウェアの製品グループ、リリースおよびプラットフォームを入力することをお薦めします。My Oracle Supportに、最新のパッチ・セット更新(PSU)と重要なパッチ更新(CPU)のリストが表示されます。
/tmpなど、アクセス可能なディレクトリにパッチを配置します。
ディレクトリをGridホーム内の/opatchディレクトリに変更します。次に例を示します。
$ cd /u01/app/12.1.0/grid/opatch
適用するパッチのパッチ・ドキュメントを確認し、パッチのアップグレードを開始する前に必要な手順をすべて完了します。
Oracle Clusterware 12cリリース1 (12.1)は新しい場所(クラスタ用Oracle Grid Infrastructureホーム、またはGridホーム)でOracle Clusterwareホームをアウトオブプレース・アップグレードしたものであるため、いくつかのパラメータ・ファイルでCRS_HOMEパラメータのパスを変更する必要があります。パラメータを変更しないと、Oracle Enterprise Manager Cloud Controlで、クラスタ・ターゲットの不正などのエラーが発生します。
問題を解決するには、次の各項の説明に従って、Enterprise Manager Cloud Controlターゲットをアップグレードし、エージェントを実行している各クラスタ・メンバー・ノードでEnterprise Managerのエージェント・ベース・ディレクトリを更新します。
Enterprise Manager Cloud Controlにログインします。
「ターゲット」メニューに移動し、次に「クラスタ」ページに移動します。
アップグレードされたクラスタ・ターゲットをクリックします。
メニューで「クラスタ」→「ターゲット設定」→「監視構成」をクリックします。
「Oracleホーム」の値を新しいGridホームのパスで更新します。
更新を保存します。
エージェント・ベース・ディレクトリのbinディレクトリに移動します。
エージェント・ベース・ディレクトリは、管理エージェント・ホームが作成されるディレクトリです。これは、パスEMAgent_home/core/EMAgent_Version/binにあります。たとえば、エージェント・ベース・ディレクトリが/u01/app/gridの場合、管理エージェント・ホームは/u01/app/emagent/core/12.1.0.1.0/binのように作成されます。
binディレクトリのemctlファイルをテキスト・エディタで開きます。
CRS_HOMEパラメータを検索し、これを新しいGridホーム・パスに更新します。
Enterprise Managerエージェントを含むクラスタの各ノードで手順1-3を繰り返します。
以前のリリースからアップグレードした後、以前のリリースのOracle Grid InfrastructureのGridホームを削除する場合は、以前のリリースのGridホームの権限と所有権を変更する必要があります。このタスクは、次の手順を使用して行います。
rootとしてログインし、次のコマンド構文を使用して以前のリリースのGridホームの権限と所有権を変更します(oldGHは以前のリリースのGridホーム、swownerはOracle Grid Infrastructureのインストール所有者、oldGHParentは以前のリリースのGridホームの親ディレクトリです)。
次に例を示します。
#chmod -R 755 /u01/app/11.2.0/grid #chown -R grid /u01/app/11.2.0/grid #chown grid /u01/app/11.2.0
以前のリリースのGridホームの権限と所有権を変更した後、Oracle Grid Infrastructureインストール所有者(前述の例ではgrid)としてログインし、同じリリースのOracle Grid Infrastructureスタンドアロン削除ツールを使用して、以前のリリースのGridホーム(oldGH)を削除します。
|
注意: Oracleソフトウェアを削除するには、同じリリースの削除ツールを使用する必要があります。以前のリリースからOracleソフトウェアを削除するとき、それより新しいリリースの削除ツールは実行しないでください。たとえば、既存の11.2.0.4 OracleホームからOracleソフトウェアを削除する場合、12.1.0.1のインストール・メディアから削除ツールを実行しないでください。 |
スタンドアロン削除ツールは、次のURLから入手できます。
http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html
ご使用のオペレーティング・システム・プラットフォームに対応するダウンロードの「すべて見る」リンクをクリックして、削除ユーティリティ用のダウンロードのリストを調べます。
Oracle Clusterware 12cリリース1 (12.1)へのアップグレードが成功または失敗した後で、Oracle Clusterwareを前のリリースにリストアすることができます。この項の内容は次のとおりです。
Oracle Clusterwareをダウングレードすると、Oracle Clusterwareの構成は、Oracle Clusterware 12cリリース1 (12.1)のアップグレード前の状態にリストアされます。Oracle Grid Infrastructure 12cリリース1 (12.1)のアップグレードの最中または後で行った変更はすべて消去され、リカバリされません。
ダウンロード手順では、次の変数が使用されます。
local nodeは、rootupgradeスクリプトを実行した最初のノードです。
remote nodesは、rootupgradeスクリプトを実行したその他のすべてのノードです。
Oracle Clusterwareを以前のリリースにリストアするには、ダウングレードするリリースのダウングレード手順を使用します。
すべてのリモート・ノードで、コマンド構文Grid_home/crs/install/rootcrs.sh -downgradeを使用して12cリリース1 (12.1)リソースを停止し、Oracle Grid Infrastructure 12cリリース1 (12.1)スタックを停止します。
すべてのリモート・ノードでrootcrs.sh -downgradeスクリプトが完了した後、ローカル・ノードでコマンド構文Grid_home/crs/install/rootcrs.sh -downgrade -lastnodeを使用します。
次に例を示します。
# /u01/app/12.1.0/grid/crs/install/rootcrs.sh -downgrade -lastnode
|
注意: Oracle Grid Infrastructure 12cでは、以前のリリースのGridホームやリリース番号の場所を指定する必要がなくなりました。 |
rootupgrade.shスクリプトが正しく実行されたいずれかのクラスタ・メンバー・ノードで次を実行します。
Oracle Grid Infrastructureインストール所有者としてログインします。
次のコマンドを使用してインストーラを開始します(ここで/u01/app/12.1.0/gridは新しい(アップグレードされた)Gridホームです)。
./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=false ORACLE_HOME=/u01/app/12.1.0/grid
Gridホームが共有ホームの場合は、フラグ-cfsを追加します。
rootupgrade.shスクリプトが正しく実行されたクラスタ・メンバー・ノードで次を実行します。
Oracle Grid Infrastructureインストール所有者(grid)としてログインします。
次のコマンドを使用してインストーラを起動します(フラグORACLE_HOMEに指定したパスは以前のOracle Clusterwareインストールのホーム・ディレクトリの場所です)。
次に例を示します。
$ cd /u01/app/12.1.0/grid/oui/bin $ ./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=true ORACLE_HOME=/u01/app/crs
11.1以下のリリースにダウングレードする場合
Oracle Clusterware 11gリリース1 (11.1)以前のリリースにダウングレードするには、以前のリリースのOracle Clusterwareホームからroot.shを手動で実行し、手順bの完了後にダウングレードを完了させます。
クラスタの各メンバー・ノード上で順に、前のリリースのOracle Clusterwareインストールのホームからroot.shを手動で実行するようOUIから要求されます。この作業が終了したら、ダウングレードは完了です。
前のリリースのOracle Clusterwareインストールのホームからroot.shを実行することにより、Oracle Clusterwareスタックが再起動され、以前のリリースでOracle Clusterwareに前に登録されていたすべてのリソースが起動され、そして前のリリースのOracle Clusterwareスタックを実行するように古い初期化スクリプトが構成されます。
ダウングレードの完了後、クラスタ内の各ノードでoratabファイル(/etc/oratabまたは/var/opt/oracle/oratab)のOracle ASMインスタンスに対するエントリを次のように更新します。
+ASM<instance#>:<RAC-ASM home>:N
すべてのリモート・ノードで、コマンド構文Grid_home/crs/install/rootcrs.sh -downgradeを使用して12cリリース1 (12.1)リソースを停止し、Oracle Grid Infrastructure 12cリリース1 (12.1)スタックを停止します。
コマンド構文rootcrs.sh -downgradeを使用します。次に例を示します。
# /u01/app/12.1.0/grid/crs/install/rootcrs.sh -downgrade
すべてのリモート・ノードでrootcrs.sh -downgradeスクリプトが完了した後、ローカル・ノードでコマンド構文Grid_home/crs/install/rootcrs.sh -downgrade -lastnodeを使用します。
次に例を示します。
# /u01/app/12.1.0/grid/crs/install/rootcrs.sh -downgrade -lastnode
|
注意: Oracle Grid Infrastructure 12cリリース1 (12.1)から、以前のリリースのGridホームやリリース番号の場所を指定する必要がなくなりました。 |
rootupgrade.shスクリプトが正しく実行されたクラスタ・メンバー・ノードで次を実行します。
Oracle Grid Infrastructureインストール所有者としてログインします。
次のコマンドを使用してインストーラを開始します(ここで/u01/app/12.1.0/gridは新しい(アップグレードされた)Gridホームです)。
$ cd /u01/app/12.1.0/grid/oui/bin ./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=false ORACLE_HOME=/u01/app/12.1.0/grid
Gridホームが共有ホームの場合は、フラグ-cfsを追加します。
rootupgradeスクリプトが正しく実行されたいずれかのクラスタ・メンバー・ノードで次を実行します。
Oracle Grid Infrastructureインストール所有者としてログインします。
次のコマンドを使用してインストーラを起動します(フラグORACLE_HOMEに指定したパスは以前のOracle Clusterwareインストールのホーム・ディレクトリの場所です)。
次に例を示します。
$ cd /u01/app/12.1.0/grid/oui/bin $ ./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=true ORACLE_HOME=/u01/app/crs
11.2.0.2にダウングレードする場合
Oracle Clusterware 11gリリース1 (11.2.0.1)にダウングレードする場合、手順bの完了後、Oracle Clusterwareスタックを手動で起動する必要があります。
各ノードで、crsctl start crsコマンドを使用して前のリリースのOracle ClusterwareホームからOracle Clusterwareを起動します。たとえば、前のリリースのホームが/u01/app/11.2.0/gridである場合は、各ノードで次のコマンドを使用します。
/u01/app/11.2.0/grid/bin/crsctl start crs
12.1.0.1にダウングレードする場合
Oracle Grid Infrastructure 12cリリース1 (12.1.0.1)をダウンロードしている場合は、次のコマンドを実行してGrid Management Databaseを構成します。
すべてのノードで12.1.0.1のOracle Clusterwareスタックを起動します。
各ノードで、次のようにしてMGMTDBリソースを削除します。
12101_Grid_home/bin/srvctl remove mgmtdb
次のように、12.1.0.1Oracleホームからサイレント・モードでDBCAを実行し、Management Databaseを作成します。
12101_Grid_home/bin/dbca -silent -createDatabase -templateName MGMTSeed_Database.dbc -sid -MGMTDB -gdbName _mgmtdb -storageType ASM -diskGroupName ASM_DG_NAME -datafileJarLocation 12101_grid_home/assistants/dbca/templates -characterset AL32UTF8 -autoGeneratePasswords
12101_Grid_home/bin/mgmtcaからConfiguration Assistantを実行し、Management Databaseを構成します。
