| Oracle® Grid Infrastructureインストレーション・ガイド 12cリリース1 (12.1) for Linux B71324-15 |
|
 前 |
 次 |
この付録では、Oracle ClusterwareおよびOracle Automatic Storage Management (Oracle ASM)のアップグレードの実行方法について説明します。
Oracle Clusterwareのアップグレードでは、ローリング・アップグレードが可能です。ローリング・アップグレードでは、他のノードはアクティブなまま、ノードのサブセットを停止してアップグレードします。Oracle ASM 12cリリース1 (12.1)のアップグレードでは、ローリング・アップグレードが可能です。ノードのサブセットをアップグレードする場合は、アップグレードの対象として選択しなかった既存のクラスタ・ノードでソフトウェアのみのインストールが実行されます。
この付録の内容は次のとおりです。
Oracleソフトウェアを変更する前に、Oracleソフトウェアおよびデータベースのバックアップを作成することをお薦めします。
次のいずれかの方法で、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 Automatic Storage Management管理者ガイド』を参照してください。 |
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 11gリリース2 (11.2)より前のOracle Grid Infrastructureリリースをアップグレードするときに、OCRと投票ファイルがRAWまたはブロック・デバイス上にあり、これらのファイルを共有ファイル・システムではなく、Oracle ASMに移行する場合は、Oracle Grid Infrastructure 12cにアップグレードする前に、Oracle Grid Infrastructure 11gリリース2 (11.2)にアップグレードする必要があります。
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 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)以上を適用する必要があります。
Gridホームのディレクトリは削除しないでください。たとえば、Grid_home/Opatchディレクトリを削除しないでください。このディレクトリを削除すると、グリッド・インフラストラクチャ・インストール所有者がOPatchを使用してGridホームにパッチを適用することができなくなり、OPatchの「checkdirエラー: Grid_home/OPatchを作成できません」というエラー・メッセージが表示されます。
既存のOracle Grid InfrastructureインストールをOracle Grid Infrastructure 12cリリース1 (12.1)にアップグレードするには、まず、アップグレードを正常に実行するのに必須のパッチを適用する必要があるかどうかを確認する必要があります。準備状況の確認手順については、第B.6項を参照してください。
|
関連項目: 「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 Grid Infrastructureをアップグレードする前に実行する手順を示します。
アップグレードを開始する前に、次の作業を行います。
各ノードで、クラスタ検証ユーティリティを使用して、インストール前の手順が完了していることを確認します。これは、サーバーの準備をするための修正スクリプトを生成することができます。また、インストーラでは、必要な前提条件をすべて満たしていることが確認されます。
次の情報を含めて、インストール時に必要な情報がすべて揃っていることを確認します。
インストールを実行するインストール所有者に関しては、既存のインストールに対して環境変数が設定済の場合は、$ORACLE_HOMEおよび$ORACLE_SIDの設定を解除します。これらの環境設定がアップグレード中に使用されてしまうからです。次に例を示します。
$ unset ORACLE_BASE $ unset ORACLE_HOME $ unset ORACLE_SID
クラスタを以前に強制的にアップグレードした場合は、次のアップグレードを開始する前に、アクセスできないノードをすべてクラスタから削除しているか、クラスタに参加させていることを確認してください。たとえば、11.2.0.3から12.1.0.1に強制的にアップグレードした場合、次のリリース、たとえば12.1.0.2にアップグレードする前に、アクセスできないノードをすべてクラスタから削除しているか、クラスタに参加させていることを確認してください。
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環境変数から削除されていることを確認します。
ORAchk (Oracle RAC構成監査ツール)アップグレード準備状況評価は、Oracle Grid Infrastructure 11.2.0.3、11.2.0.4、12.1.0.1および12.1.0.2にアップグレードする際のアップグレード固有のヘルス・チェックを自動的に行うために使用できます。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
クラスタ検証ユーティリティ(CVU)を使用すると、アップグレードを開始する前準備として、システムをチェックできます。CVUによって適切なシステム・チェックが自動的に実行され、問題の修正を求めるプロンプトが表示されるか、またはアップグレードを進める前にクラスタ内のすべてのノード上で実行するための修正スクリプトが提供されます。
この項の内容は次のとおりです。
アップグレード検証は、次の2種類の方法で実行できます。
OUIを実行して、CVU検証がシステム・チェックを実行し修正スクリプトを生成する、OUIに構成されるようにします。
CVUの手動スクリプトのcluvfy.shスクリプトを実行して、システム・チェックを実行し、修正スクリプトを生成します。
OUIを使用してインストール前チェックを実行し、修正スクリプトを生成するには、通常行うようにインストールを実行します。OUIによってCVUが開始され、インストール・プロセスの一部としてシステム・チェックが実行されます。インストール前チェックが完了し、システム構成がインストールの最小要件を満たすことを確認したい場合には、これらのチェックの実行にはOUIが最適です。
CVUのcluvfy.shコマンドライン・スクリプトを使用するには、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_release
-dest_versionフラグは、パッチセットを含む、アップグレードのリリース番号を指定します。リリース番号には、リリースをプラットフォーム固有のパッチのレベルに指定する5つの数字を含める必要があります。たとえば、12.1.0.1.0です。
-fixup [-method {sudo|root} [-location dir_path] [-user user_name]
-fixupフラグは、クラスタがアップグレードできる状態であることを確認するのに実行する必要がある手順の指示を生成することを指定します。デフォルトの場所は、CVUの作業ディレクトリです。
-fixup -methodフラグは、rootスクリプトの実行方法を定義します。-methodフラグには、次のオプションのいずれかが必要です。
sudo: sudoersリスト内のユーザーとして実行します。
root: rootユーザーとして実行します。
sudoを選択した場合は、-locationフラグを入力してサーバー上のsudoへのパスを指定し、-userフラグを入力してsudo権限を持つユーザー・アカウントを指定します。
-verbose
-verboseフラグを使用すると、個々のチェックの詳細な出力が生成されます。
次のようなコマンドを実行すると、Oracle Clusterwareのインストールに必要な権限が構成されているかどうかを検証できます。
$ ./runcluvfy.sh stage -pre crsinst -upgrade -rolling -src_crshome /u01/app/11.2.0/grid -dest_crshome /u01/app/12.1.0/grid -dest_version 12.1.0.1 -fixup -verbose
|
関連項目: 『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 ASMをアップグレードするオプションを選択します。
ノード選択ページで、すべてのノードを選択します。
指示どおりに、インストール・オプションを選択します。rootスクリプトの自動化を構成して、アップグレード中にrootupgrade.shスクリプトが自動的に実行されるようにすることをお薦めします。
rootスクリプトを自動的に、または手動で実行します。
rootスクリプトを自動的に実行する場合
rootスクリプトの自動化を構成した場合は、以前のリリースを実行しているノードから新しいリリースにサービスを再配置するために、バッチ間で一時停止を使用します。
rootスクリプトを手動で実行する場合
rootスクリプトの自動化を構成していない場合は、プロンプトに従って、アップグレードするクラスタ内の各ノードでrootupgrade.shスクリプトを実行します。
rootスクリプトを手動で実行する場合は、最初にローカル・ノードでスクリプトを実行します。このスクリプトは、前のリリースのインストール環境を停止し、新しいOracle Clusterwareリリースに置き換えて、新しいOracle Clusterwareのインストールを開始します。
スクリプトが正常に完了したら、最後のノードとして選択した1つを除いて、すべてのノード上で並行してスクリプトを実行できます。最後のノードを除いたすべてのノード上でスクリプトが正常に実行されたら、最後のノード上でスクリプトを実行します。
12.1.0.1のOracle Flex Clusterからアップグレードする場合は、リーフ・ノードで実行する前にすべてのハブ・ノードでrootupgrade.shスクリプトを実行することをお薦めします。
クラスタ内の最後のノードでrootupgrade.shスクリプトを実行した後、Oracle Grid Infrastructure 11gリリース2 (11.2.0.2)よりも前のリリースからアップグレードしている場合に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 Grid Infrastructure 12cリリース1 (12.1)のホーム(例: srvctl)内のOracle ASMの管理ツールは動作しません。
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コマンドを実行します。
Grid_home/rootupgrade.sh -force
次に例を示します。
# /u01/app/12.1.0/grid/rootupgrade.sh -force
このコマンドによってアップグレードが強制的に完了されます。crsctl query crs activeversionコマンドを使用して、アップグレードが完了したことを確認します。アクティブなリリースはアップグレード・リリースです。
クラスタの強制アップグレードには、次の制限があります。
すべてのアクティブ・ノードが新しいリリースにアップグレードされる必要があります。
すべての非アクティブ・ノード(アクセス可能またはアクセス不可能)は、アップグレードされても、アップグレードされなくてもどちらでもかまいません。
アクセス不可なノードは、パッチ・セットのアップグレード後にクラスタから削除できます。ノードが後でアクセス可能になり、パッチ・バージョン・アップグレードのパスがサポートされる場合は、このノードを新しいパッチ・バージョンにアップグレードできます。
クラスタを以前に強制的にアップグレードした場合は、アップグレードを開始する前に、アクセスできないノードをすべてクラスタから削除しているか、クラスタに参加させていることを確認してください。
Oracle Grid Infrastructure 12cから、クラスタの強制アップグレード後、アクセス不可なノードを削除するのではなく、以前のリリースで求められていた、クラスタにノードを参加させることが可能になりました。このオプションを使用するには、Oracle Grid Infrastructure 12cリリース1 (12.1)ソフトウェアがすでにノードにインストールされている必要があります。
アクセスまたは到達できないノードのアップグレードを完了する手順:
クラスタに追加するノードで、Gridユーザーとしてログインします。
Oracle Grid Infrastructure 12cリリース1 (12.1)のGridホームで/crs/installディレクトリに移動します。次に例を示します。
$ cd /u01/12.1.0/grid/crs/install
次のPERLコマンドを実行します(existingnodeはオプションの名前、upgraded_nodeは正常にアップグレードされ、現在クラスタの一部であるノードです)。
$ rootupgrade.sh -join -existingnode upgraded_node
|
注意: リリース11.2.0.1.0より前のOracle Clusterwareでは、-join操作はサポートされていません。その場合はノードを削除し、addNodeコマンドを使用してOracle Clusterwareに追加します。 |
Oracle ASMの完全リリースまたはソフトウェア・パッチ・レベルのローリング・アップグレードを実行する場合は、次の点に注意してください。
Oracle Clusterwareのアクティブなリリースは、12cリリース1 (12.1)である必要があります。アクティブなリリースを確認するには、次のコマンドを入力します。
$ crsctl query crs activeversion
アップグレード・プロセスまたはパッチ・プロセスを開始する前に、既存のOracle ASM環境で行われているリバランス操作が完了していることを確認する必要があります。
アップグレード・プロセスまたはローリング・パッチ・プロセス中に、Oracle ASMインスタンスをアップグレード状態に変更できます。データベース・クライアントは、Oracle ACFS上にある場合を除き、停止する必要はありません。ただし、このアップグレード状態ではOracle ASM操作が制限されるため、アップグレード・プロセスは開始してすぐに完了する必要があります。Oracle ASMインスタンスがアップグレード状態にあるときに可能な操作は、次のとおりです。
ディスク・グループのマウントとマウント解除
データベース・ファイルのオープン、クローズ、サイズ変更または削除
インスタンスのリカバリ
固定ビューおよび固定パッケージの問合せ(固定ビューの問合せと、dbms_diskgroupなどの固定パッケージを使用した匿名PL/SQLブロックの実行は可能です)
データベース・クライアントは、Oracle ACFS上にある場合を除き、停止する必要はありません。
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は、これ以外の場合はクラスタの全ノードのOracle ASMインスタンスをすべてシャットダウンし、各ノードのOracle ASMを新しいOracle Grid Infrastructureホームから起動する非ローリング・アップグレードを実行します。 |
Oracle Grid Infrastructure 12cリリース1でOracle ASMをアップグレードした後、Oracle ASMの個々のパッチをOracle Automated Release Updateサイトからダウンロードしてインストールできます。ASMCAを使用したOracle ASMの個別のアップグレードの詳細は、第B.9項「Oracle ASMのアップグレードおよびパッチ適用に関する制限およびガイドライン」を参照してください。
Oracle ASMが別のOracleホームにインストールされる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 Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle Grid Infrastructure 12cリリース1でOracle ASMのアップグレードが完了したら、My Oracle SupportからOracle ASMの個別パッチをダウンロードしてインストールできます。
この項では、Oracle ASMのパッチを次の内容で説明します。
個々のパッチは個別パッチと呼ばれます。Oracle ASMの個別パッチは、特定のリリース済リリースのOracle ASM向けに用意されています。必要なパッチが使用可能である場合は、パッチをダウンロードし、OPatchユーティリティを使用してOracle ASMに適用できます。ご使用のOracle ASMリリースのインストール済パッチは、OPatchインベントリでトラッキングされています。インストール済のパッチと適用したいパッチ間で競合が発生する場合、OPatchユーティリティよりこれらの競合に関する通知があります。OPatchユーティリティを使用してOracle ASMにパッチを適用する方法の詳細は、第B.11.3項「特定のソフトウェア・パッチ・レベルへのOracle ASMへのパッチの適用」を参照してください。
Oracle Grid Infrastructureのソフトウェア・パッチ・レベルは、Oracle ASMを含むOracle Grid Infrastructureソフトウェア・リリースに適用されている一連のすべての個別パッチを示します。リリースとは、メジャー、マイナー、パッチ・セットのリリース番号の形式のリリース番号です。たとえば、リリース番号が12.1.0.1である場合は、メジャー・リリースが12、マイナー・リリースが1、0.0がパッチ・セット番号です。個別パッチでは、メジャーおよびマイナー・リリースは変わりませんが、パッチ・レベルは個別パッチの適用またはロールバックのたびに変更されます。
Oracle Grid Infrastructureの標準アップグレードと同様、クラスタの正常な稼働には、どの時点でもクラスタ内のすべてのノードのソフトウェア・リリースおよびパッチ・レベルが同じである必要があります。個別パッチはローリング・アップグレードとして適用できるため、特定のソフトウェア・リリースのすべてのパッチ・レベルは相互に互換性があります。
|
関連項目:
|
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 Grid Infrastructure 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ディレクトリに移動します。
エージェント・ベース・ディレクトリとは、管理エージェントのホームが作成されるディレクトリです。管理エージェント・ホームのパスは、Agent_Base_Directory/core/EMAgent_Versionです。たとえば、エージェント・ベース・ディレクトリが/u01/app/emagentの場合、管理エージェント・ホームは/u01/app/emagent/core/12.1.0.1.0のように作成されます。
/u01/app/emagent/core/12.1.0.1.0/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ホームの権限と所有権を変更した後、インストール所有者(前述の例ではgrid)としてログインし、同じリリースのOracle Grid Infrastructure削除ツールを使用して、以前のリリースのGridホーム(oldGH)を削除します。
|
注意: Oracleソフトウェアを削除するには、同じリリースの削除ツールを使用する必要があります。以前のリリースからOracleソフトウェアを削除するとき、それより新しいリリースの削除ツールは実行しないでください。たとえば、既存の11.2.0.4 OracleホームからOracleソフトウェアを削除する場合、12.1.0.1のインストール・メディアから削除ツールを実行しないでください。 |
IPD/OSを使用する以前のリリースからOracle Grid Infrastructureにアップグレードする場合は、クラスタ状態モニターのリポジトリ・サイズ(CHMリポジトリ)を確認します。CHMリポジトリの要件を確認し、より大規模なCHMリポジトリを保持する場合はリポジトリ・サイズを大きくすることをお薦めします。
|
注意: Oracle Grid Infrastructureのインストール時に各ノードでroot.shスクリプトを実行すると、以前のIPD/OSリポジトリは削除されます。
クラスタ状態モニターは、IBM: Linux on System z構成では使用できません。 |
デフォルトでは、CHMリポジトリのサイズは、最小で1GBまたは3600秒(1時間)です。クラスタのサイズにかかわらず、CHMリポジトリは1GBです。
CHMリポジトリを大きくするには、次のコマンド構文を使用します(retention_timeはCHMリポジトリのサイズ(秒数)です)。
oclumon manage -repos changeretentiontime retention_time
retention_timeは、3600(1時間)より大きく、259200(3日)より小さい値である必要があります。CHMリポジトリ・サイズを大きくする場合は、クラスタのノードごとに選択するリポジトリ・サイズに使用できるローカル領域があることを確認する必要があります。十分な領域がない場合は、リポジトリを共有ストレージに移動できます。
たとえば、リポジトリ・サイズを4時間に設定するとします。
$ oclumon manage -repos changeretentiontime 14400
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)のアップグレードの最中または後で行った変更はすべて消去され、リカバリされません。
ダウンロード手順では、次の変数が使用されます。
firstノードは、rootupgradeスクリプトが正常に完了した最初のノードです。
non-firstノードは、rootupgradeスクリプトが正常に完了したノード以外のすべてのノードです。
Oracle Clusterwareを以前のリリースにリストアするには、ダウングレードするリリースのダウングレード手順を使用します。
|
注意: アップグレードが失敗した後でダウングレードするとき、ノードにrootcrs.shが存在しない場合は、rootcrs.shではなくperl rootcrs.plを使用します。 |
Oracle Clusterwareをダウングレードするには、次の手順を実行します。
rootupgradeスクリプトがノードで失敗した場合は、アップグレードが失敗したノードをダウングレードします。
rootcrs.sh -downgrade
rootupgradeスクリプトが正常に完了した他のすべてのノードで、コマンド構文Grid_home/crs/install/rootcrs.sh -downgradeを使用して12cリリース1 (12.1)リソースを停止し、Oracle Grid Infrastructure 12cリリース1 (12.1)スタックを停止します。
rootcrs.sh -downgrade
すべてのnon-firstノードでrootcrs.sh -downgradeスクリプトが完了した後、firstノードでコマンド構文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ホームやリリース番号の場所を指定する必要がなくなりました。 |
Oracle Grid Infrastructureのインストール・ユーザーに対して書込み権限のあるディレクトリから、このコマンドを実行します。
rootcrsスクリプトが正しく実行されたいずれかのクラスタ・メンバー・ノードで次を実行します。
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
次の手順に従って、Oracle Grid Infrastructureをダウングレードします。
すべてのリモート・ノードで、コマンド構文Grid_home/crs/install/rootcrs.sh -downgradeを使用して12cリリース1 (12.1)リソースを停止し、Oracle Grid Infrastructure 12cリリース1 (12.1)スタックを停止します。
# /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ホームやリリース番号の場所を指定する必要がなくなりました。 |
Oracle Grid Infrastructureのインストール・ユーザーに対して書込み権限のあるディレクトリから、このコマンドを実行します。
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.2)にダウングレードする場合、手順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を構成します。
