Enterprise Manager Cloud Control 12c リリース5 (12.1.0.5)、12c リリース4 (12.1.0.4)または12c リリース3 (12.1.0.3)を13c リリース1にアップグレードする前に、次の前提条件を満たします。
必ず『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEnterprise Manager Cloud Controlのインストールに関する章に記載されたハードウェア要件を含め、すべての前提条件を満たします。
また、必ず第2.3項に記載されたサポートされているプラットフォームでのみアップグレードを実行します。
既存のデータベースが13c リリース1に対して動作保証されているデータベースであることを確認します。動作保証されたデータベースのリストは、My Oracle Supportで入手できるEnterprise Manager動作保証マトリックスで確認できます。Enterprise Managerの動作保証マトリックスにアクセスするには、『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』に記載されている手順に従います。
既存のデータベースが13c リリース1でサポートされているリリースではない場合は、サポートされているリリースにアップグレードしてから、OMSと管理リポジトリのアップグレードを開始してください。たとえば、12c リリース3 (12.1.0.3)からアップグレードする場合、データベースのリリースが古く、13c リリース1でサポートされていない可能性があります。この場合は、まずデータベースを13c リリース1でサポートされている最低限のデータベース・リリースにアップグレードしてから、Enterprise Managerシステムを13c リリース1にアップグレードします。
データベースをアップグレードする前に、必ずデータベースに接続されている旧リリースのOMSインスタンスを停止してください。データベースのアップグレード時に、リスナー・ポートを変更した場合は、次の手順に従います。
変更後のリスナー・ポートを使用してデータベース・アップグレードを完了します。
次のコマンドを実行して、データベースに接続されている旧リリースの最初のOMSの管理サーバーを起動します。
emctl start oms -admin_only
すべてのOMSインスタンスに対して次のコマンドを実行して、最初のOMSに加えて他のOMSインスタンスも変更後のリスナー・ポートで更新します。
emctl config oms –store_repos_details -repos_conndesc <connect descriptor> -repos_user sysman
前述のコマンドを各OMSで実行すると、OMSを停止してから再起動して変更を反映するよう求められます。各OMSで、指示されたとおりに実行してください。いずれにせよ、13cへのアップグレードを開始する前に、すべて停止する必要があります。
13cへのEnterprise Managerシステム全体のアップグレードを続行します。
必ずサポートされているデータベースに最新のPSUを適用します。
必ず管理リポジトリを格納しているOracle Databaseでオプティマイザ適応機能(optimizer_adaptive_features=FALSE
)を無効にします。次の手順を実行します。
オプティマイザ適応機能を無効にするには、optimizer_adaptive_features
パラメータをFALSE
に設定します。そのためには、次のSQLコマンドを実行します。
alter system set optimizer_adaptive_features=false scope=both
データベースを再起動します。
変更が反映されていることを確認します。そのためには、次のSQLコマンドを実行します。
show parameter adaptive;
次の出力が表示されるはずです。
NAME TYPE VALUE --------------------------------------------------------------------- optimizer_adaptive_features boolean FALSE
必ずIBM AIXオペレーティング・システムで実行されている管理エージェントに次のパッチを適用します。
パッチ19154291: Oracle Management Agent 12c リリース3 (12.1.0.3)の場合
パッチ20282974: Oracle Management Agent 12c リリース4 (12.1.0.4)の場合
Oracle Management Service (OMS)で使用されているポートに1024以下の値が設定されていないことを確認します。この値以下に設定されている場合、アップグレードは失敗します。1024以下のポートは、一般にルート・ユーザー(スーパー・ユーザー)用に予約されています。このため、ポートは1024より大きくしてください。
必ず電子メール通知の受信に使用しているシステム既存のルール・セットのコピーを(「類似作成」アクションを使用して)作成します。そうしないと、ルール・セットに対して作成された電子メール・サブスクリプションが失われることになります。
コピーを作成するには、「設定」メニューから、「インシデント」、「インシデント・ルール」の順に選択します。「インシデント・ルール - すべてのエンタープライズ・ルール」ページの表で、コピーするシステム既存のルール・セットを選択します。次に、「アクション」メニューから、「ルール・セットの類似作成」を選択します。ルール・セットの類似作成ページで、必要な情報を指定して「保存」をクリックします。
必ずOMSに対して実行した次のタイプのカスタマイズを削除します。アップグレードが完了した後で、再びカスタマイズすることができます。
Weblogic Serverで構成された追加のデータ・ソース・パラメータ。
Enterprise Managerログインのためのスマート・カード認証
Oracle BI Publisherを12c リリース3 (12.1.0.3)で構成している場合、13c リリース1に直接アップグレードすることはできません。まず12c リリース4 (12.1.0.4)または12c リリース4 (12.1.0.5)にアップグレードしてから、13c リリース1にアップグレードする必要があります。Oracle BI Publisherを12cリリース3 (12.1.0.3)で構成していない場合は、13cリリース1に直接アップグレードできます。
必ず以前のリリースにデプロイされているOracle BI Publisherを停止します。そのためには、次の方式のいずれかを使用します。
Enterprise Manager Cloud Control 12c リリース5 (12.1.0.5)または12c リリース4 (12.1.0.4)からアップグレードする場合は、BI Publisher Serverを実行しているインスタンスを含め、すべてのOMSインスタンスでemctl stop oms -all
を実行します。
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以下からアップグレードする場合は、WebLogic管理コンソールを使用してBIPという名前のプライマリBI Publisher管理対象サーバーを停止します。
必ず未処理のデータベース・サービス・インスタンス作成リクエストがないか確認します。進行中のリクエストがある場合は、完了するまで待ちます。スケジュールされているリクエストについては、一時停止します。
これを行うには、次の手順を実行します。
Cloud Controlで、「エンタープライズ」メニューから、「クラウド」、「セルフ・サービス・ポータル」の順に選択します。
インフラストラクチャ・クラウド・セルフ・サービス・ポータル・ページで、ページ・タイトルのすぐ下で、「マイ・データベース」を選択してデータベース・リクエストのみを参照します。
「リクエスト」表で、進行中のリクエストについては完了するまで待ちます。スケジュールされているリクエストについては、一時停止します。
スケジュールされたリクエストを一時停止するには、リクエスト名をクリックします。「デプロイメント」タブをクリックします。そこにリストされたデプロイメント・プロシージャをクリックして、一時停止します。
管理リポジトリ内の表でスナップショットが作成されていないことを確認します。
これを確認するには、管理リポジトリにSYSMANユーザーとしてログインし、次のSQL問合せを実行します。
select master , log_table from all_mview_logs where log_owner='<EM_REPOS_USER>'
;
次に例を示します。
select master , log_table from all_mview_logs where log_owner='SYSMAN';
作成されたスナップショットが表にある場合、マスター表およびスナップショットの詳細が表示されます。次に例を示します。
SQL> master log_table
em-violations em$violation_log
スナップショットがある場合は、SYSMANユーザーとして次のコマンドを実行して削除します。
SQL> Drop snapshot log on <master>
;
次に例を示します。
SQL> Drop snapshot log on em-violations
;
Oracle Management Repositoryを格納しているOracle Databaseにログインまたはログオン・トリガー設定をしていないことを確認してください。
これを確認するには、データベースにログインして次の問合せを実行します。問合せ結果がゼロ以外の場合、または行が選択されない場合は、トリガーを手動で無効にします。アップグレード完了後に、これらを再度有効化できます。
ログイン・トリガーが設定されているかどうかを確認するには、次を実行します。
SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGIN%' AND status='ENABLED';
SQL> SELECT trigger_name FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGIN%' AND status='ENABLED';
ログオフ・トリガーが設定されているかどうかを確認するには、次を実行します。
SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';
SQL> SELECT trigger_name FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';
このようなトリガーを無効化するには、次の問合せを実行します。
SQL> alter trigger <trigger_name> disable;
次に例を示します。
SQL> alter trigger EXPFIL_ALTEREXPTAB_MAINT disable;
必ずターゲットの削除操作の監査を有効にします。
操作のリストを表示するには、次のコマンドを実行します。
emcli show_operations_list
削除操作には、ターゲットの削除、名前付き資格証明の削除、ロールの削除、ルールの削除、モニタリング・テンプレートの削除、ユーザーの削除などがあります。
現在有効になっている削除操作を確認するには、次のコマンドを実行します。
emcli show_audit_settings
ターゲットの削除操作がまで有効になっていない場合は、次のコマンドを実行して有効にします。
emcli update_audit_settings
-operations_to_enable="name_of_the_operations_to_enable._For_all_operations_use_ALL"
-audit_switch="ENABLE
-directory="db_directory_name'
(エクスポート・サービスが監査データ・ファイルをアーカイブするOSディレクトリで構成する必要があります)
-file_prefix="file_prefix"
(エクスポート・サービスによって使用され、監査データを書き込む必要がありファイル名を作成します。デフォルト値はem_auditです。すべてのサイトで標準に応じて変更できます)
-file_size="file_size (Bytes)"
(各ファイル・サイズの最小値。このデフォルト値は5000000バイトです)
-data_retention_period="data_retention_period (Days)"
(Enterprise Managerリポジトリに監査データが格納される最大期間。デフォルト値は365日です)
前述のパラメータは、保存期間後に、監査データを管理リポジトリからファイル・システムにアーカイブするために、アーカイブの場所を設定または構成するのに役に立ちます。
Enterprise Managerシステムのアップグレード中に、ジョブ・タイプが登録されます。ジョブ・タイプ登録プロセスの一環として、ジョブ・タイプに対応するアクティブな実行がすべて新しく登録されたバージョンのジョブ・タイプに自動的にアップグレードされます。このジョブ・タイプ・アップグレード・プロセスは、キューされた実行および待機中の実行すべてについてスキップされ、これによりEnterprise Managerシステムの停止時間全体が短縮されます。ただし、場合によってはEnterprise Managerシステムでかなりのバックログが発生し、このようなバックログがアップグレードの開始前に解消されないと、Enterprise Managerシステムの停止時間がずっと長くなることがあります。この問題を回避するには、停止時間の終了を待ってアップグレードされるように、特定のジョブ・タイプのアップグレードを選択してスキップまたは後回しにすることができます。
ジョブ・タイプがアップグレードされないようにスキップまたは後回しにするには、次の手順を実行します。
停止時間中のアップグレードから除外するジョブ・タイプを特定します。
そのためには、SYSMANユーザーとしてOracle Management Repositoryを格納しているデータベースにログインし、次の問合せを実行します。特に、アクティブな実行を多数保有するジョブ・タイプを探します。
SELECT job_type, COUNT(1) as n_execs
FROM MGMT_JOB_EXEC_SUMMARY
JOIN MGMT_JOB_TYPE_INFO USING (job_type_id)
WHERE status NOT IN (3,4,5,8,18,19,23)
GROUP BY job_type
HAVING COUNT(1) > 5000
ORDER BY COUNT(1) DESC;
特定した他のジョブ・タイプを除外します。
そのためには、次の問合せを実行してMGMT_PARAMETERS表からジョブ・タイプを除外します。除外するジョブ・タイプごとに、INSERT文を1つ実行する必要があります。たとえば、除外するジョブ・タイプが3つある場合、INSERT文を3回実行しますが、それぞれに除外するジョブ・タイプを指定します。
INSERT INTO MGMT_PARAMETERS(parameter_name, parameter_value) VALUES ('mgmt_job_skip_job_type_upg.1', '<job type>');
[複数OMSアップグレードの場合、最初のOMSアップグレードのみでこの手順を実行してください]
必ず既存のOMSから既存の管理リポジトリにemkeyをコピーします。これを実行するには、これからアップグレードするOMSで次のコマンドを実行します。<ORACLE_HOME>
は、OMSのOracleホームを指しています。
$<ORACLE_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>
]
次に例を示します。
/u01/software/em12c/mw/oms/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>]
emkeyがコピーされているかどうかを確認するには、これからアップグレードするOMSで次のコマンドを実行します。<ORACLE_HOME>
は、OMSのOracleホームを指しています。
$<ORACLE_HOME>/bin/emctl status emkey
次に例を示します。
/u01/software/em12c/mw/oms/bin/emctl status emkey
emkeyがコピーされている場合、次のメッセージが表示されます。
The EMKey is configured properly, but is not secure. Secure the EMKey by running "emctl config emkey -remove_from_repos".
証明書鍵の強度が1024ビット以上であることを確認します。
11g リリース1以下の場合、証明書は鍵の強度512ビットで生成され、12c リリース4 (12.1.0.4)または12c リリース(12.1.0.5)へのアップグレード、それに続く13c リリース1へのアップグレードで引き継がれます。したがって、11g リリース1以下からアップグレードする場合、証明書は512ビットのままであり、最終的に様々な通信問題につながります。そのため、証明書鍵の強度は1024ビット以上であることを確認してください。
証明書鍵の強度を1024ビット以上に設定する手順は、My Oracle Supportのノート1611578.1を参照してください。
OMSインスタンス用のデフォルトの即時利用可能なメモリー設定を変更している場合、アップグレード時に失われないように変更を保持します。
変更を保持するには、次の手順を実行します。
これからアップグレードするOMSインスタンスのすべてで、次のコマンドを実行します。<ORACLE_HOME>
は、OMSのOracleホームを指しています。
$<ORACLE_HOME>/bin/emctl set property -name 'JAVA_EM_MEM_ARGS' -value '<java_memory_arguments>'
次に例を示します。
/u01/software/em12c/mw/oms2/bin/emctl set property -name 'JAVA_EM_MEM_ARGS' -value '-Xms256m -Xmx1740m'
次のコマンドを実行して、すべてのOMSインスタンスを再起動します。<ORACLE_HOME>
は、OMSのOracleホームを指しています。
$<ORACLE_HOME>/bin/emctl stop oms -all
$<ORACLE_HOME>/bin/emctl start oms
次に例を示します。
/u01/software/em12c/mw/oms/bin/emctl stop oms -all
/u01/software/em12c/mw/oms/bin/emctl start oms
アップグレードを開始する前に、必ずEM前提条件キットを実行し、リポジトリ関連の前提条件をすべて満たします。
EM前提条件Kitを実行するには、次のコマンドを実行して表4-1に記載されているパラメータが含まれるレスポンス・ファイルを渡します。
./em13100_linux64.bin EMPREREQ_KIT=true EMPREREQKIT_PROPERTY_FILE=<absolute_path_to_reponse_file>
表4-1 EM前提条件Kitレスポンス・ファイルのパラメータ
パラメータ | 説明 |
---|---|
|
|
|
次の書式でデータベースの詳細を指定します。
|
|
データベース・ユーザー・パスワードを指定します。 |
|
|
|
|
|
|
|
EM前提条件キットの実行ログを保存できるディレクトリへの絶対パスを指定します。デフォルトの場所は |
|
前提条件チェックの結果(XMLファイル形式)を保存するディレクトリの絶対パスを指定します。 |
|
|
|
|
サンプル・レスポンス・ファイルの内容は次のとおりです。
installerMode=emprereqkit connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=explsrvc))) dbPassword=<password> dbRole=sysdba dbUser=SYS executionType=install logLoc=/u01/software/em13c/prerequisiteResults/log prereqResultLoc=/u01/software/em13c/prerequisiteResults reposUser=SYSMAN runPrerequisites=true
必ずOMS (ミドルウェア・ホームおよびインベントリ)、Oracle Management RepositoryおよびOracle Software Libraryをバックアップします。アップグレードが失敗した場合、常にバックアップを使用してリストアできます。バックアップの手順は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。
必ずこれからアップグレードするOMSと、それに接続されているその他のOMSインスタンスも停止します。
重要: ソフトウェアのみのアップグレードの方式を使用して複数OMS環境をアップグレードする場合は、この手順をスキップします。第5.3.1項または第5.4.1項に記載されているように、ソフトウェア・バイナリをインストールした後でOMSインスタンスを停止できます。
JVMDおよびADPエンジンを明示的に停止します。
グラフィック・モードでこれらを停止するには、WebLogicコンソールにアクセスし、JVMDおよびADP WebLogic管理対象サーバーを手動で停止します。
サイレント・モードで停止するには、これからアップグレードするOMSで次のコマンドを実行します。<ORACLE_HOME>
は、OMSのOracleホームを指しています。
$<ORACLE_HOME>/bin/emctl extended oms jvmd stop -all
$<ORACLE_HOME>/bin/emctl extended oms adp stop –all
次に例を示します。
/u01/software/em12c/mw/oms/bin/emctl extended oms jvmd stop -all
/u01/software/em12c/mw/oms/bin/emctl extended oms adp stop –all
これからアップグレードするOMSを停止して、これに接続されているその他のOMSインスタンスも停止します。これを行うには、次のコマンドを実行します。<ORACLE_HOME>
は、OMSのOracleホームを指しています。
$<ORACLE_HOME>/bin/emctl stop oms -all
次に例を示します。
/u01/software/em12c/mw/oms/bin/emctl stop oms -all
管理エージェントがメトリック収集のために管理リポジトリに接続しないように、必ず「管理サービスとリポジトリ」ターゲットをモニターする管理エージェントを停止します。この管理エージェントを停止しないと、OMSアップグレードが失敗する可能性があります。
重要: ソフトウェアのみのアップグレードの方式を使用して複数OMS環境をアップグレードする場合は、この手順をスキップします。第5.3.1項または第5.4.1項に記載されているように、ソフトウェア・バイナリをコピーした後で管理エージェントを停止できます。
必ずスタンドアロン管理エージェント用に構成されているプロキシを削除します。そうしないと、スタンドアロン管理エージェントのアップグレードが失敗します。この要件はむしろ管理エージェントのアップグレードに対することで、OMSのアップグレードには影響しませんが、OMSのアップグレードを開始する前に、管理エージェント側のプロキシを削除することをお薦めします。