exadata software maintenance - oracle...12.1.0.2 12.2.0.1 18 19 2020年12月 2021年7月...

Copyright © 2019, Oracle and/or its affiliates.All rights reserved.

Exadataソフトウェアのメンテナンス

Doug UtzigExadataおよびMAAのベスト・プラクティス

免責条項

Copyright © 2019, Oracle and/or its affiliates.All rights reserved. 2

下記事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。マテリアルやコード、機能の提供をコミットメント（確約）するものではなく、購買を決定する際の判断材料になさらないでください。オラクルの製品に関して記載されている機能の開発、リリース、および時期については、弊社の裁量により決定されます。

パッチ適用とアップグレード Oracle Exadata

ソフトウェアのアーキテクチャ概要

ソフトウェアのメンテナンス計画

Exadataソフトウェアの更新

1

2

3






1

2

3


Q：Exadataを使用する理由A：エンジニアド・システムの価値

Oracleエンジニアド・システムは、唯一の完全にテスト済みのフルスタック構成

100 %Platinum Servicesオラクルのエンジニアが追加コストなしでリモート・パッチ・インストールを実行

簡単なメンテナンス

フル・スタックのパッチ適用フル・スタックのヘルス・チェック

PLATINUM SERVICES

Exadataコミュニティの影響

Oracle Public CloudOracle Development & Support 1000の顧客およびパートナー


Exadata Database Machineソフトウェア・アーキテクチャの確認（ベア・メタル/物理）

データベース・グリッド– Oracle DatabaseおよびGrid Infrastructure– Exadata（ファームウェア、Linux、Exadata）

ストレージ・グリッド– Exadata（ファームウェア、Linux、Exadata）

ネットワーキング– Exadata（InfiniBandスイッチ・ソフトウェア）

その他：イーサネット・スイッチ、PDU


データベース・サーバー：ベア・メタル/物理デプロイメントとOVMデプロイメントの比較

ソフトウェア・アーキテクチャの比較

OVMデータベース・サーバー

dom0

Exadata（Linux、Xen、fw）

domU-3Oracle GI/DB

ホームdomU-2Oracle GI/DB

ホームdomU-1Oracle GI/DB

ホーム

Exadata（Linux）

ベア・メタル/物理

データベース・

サーバー

Exadata（Linux、fw）

Oracle GI/DBホーム


ストレージ・グリッド、ネットワーク、その他の変更なし





1

2

3


ソフトウェア計画の推奨事項

1. バージョンの推奨事項

2. 重大な問題の開示レポート

Exachkによるソフトウェア・メンテナンスの計画Exadataの自動ヘルス・チェック - MOS 1070954.1


Exachkの重大な問題の開示レポート（サンプル）

Exadataの重大な問題（Doc ID 1270094.1）EX51 Exadataのバージョン

18.1.10、18.1.11、または18.1.12を実行し、IORMを

使用してフラッシュ・キャッシュを管理しているストレージ・サーバー

バグ29288067 - I/O Resource Management（IORM）が、スト

レージ・サーバー上でフラッシュ・キャッシュを管理するように構成されている場合、cellsrvプロセスがORA- 600 [FCGroupDesc::decLocalCnt_underflow]のエラーでクラッシュする場合があります。

Exadata18.1.13で修正。

詳しくは、ドキュメント2511918.1を参照。

最新の問題 - ホット・トピックのMOSアラート（詳細についてはMOS 793436.2を参照）

CRITICAL ストレージ・サーバー・チェックシステムはExadataの重大な問題EX51にさらされていますすべてのストレージ・サーバー表示

PASS データベース・サーバー・チェックシステムはExadataの重大な問題EX50にさらされていませんすべてのデータベース・サーバー表示


Exachkの推奨バージョン（サンプル）


コンポーネントホスト/ロケーション推奨バージョンステータス

dm01db01,dm01db02:/u01/…/dbhome_1

11.2.0.3.28 11.2.0.4.190416 11.2.0.3のエラー修正サポートが2015年8月に終了。

dm01db01,dm01db02:/u01/…/dbhome_2

11.2.0.4.10 11.2.0.4.190416 11.2.0.4 BPが推奨より古い。

dm01db01,dm01db02:/u01/…/dbhome_3 18.4.0.0.181016 18.6.0.0.190416 推奨範囲内のバージョン。

Grid Infrastructure

dm01db01,dm01db02:/u01/…/grid 18.6.0.0.190416 18.6.0.0.190416 推奨範囲内のバージョン。

Exadata dm01db01,dm01db02: 18.1.14.0.0 18.1.15.0.0 推奨範囲内のバージョン。

Exadata

dm01cel01,dm01cel02 18.1.14.0.0 18.1.15.0.0 推奨範囲内のバージョン。

dm01cel03 11.2.3.3.1 18.1.15.0.0 推奨バージョンより古い。例外：ピアとバージョンが異なる。

IBスイッチファームウェア dm01sw-iba0,dm01sw-ibb0 2.2.11-2 2.2.12-2以上推奨範囲内のバージョン。

現行バージョン

ストレージ・サーバー

データベース・サーバー

データベース・ホーム

ソフトウェアのメンテナンス推奨更新スケジュール

頻度データベース/Grid Infrastructure Exadata

3～12か月四半期ごとのリリース更新月次の継続リリース

1～5年新機能のリリース新機能のリリース

ExadataのすべてのソフトウェアMOS 888828.1

セキュリティ・スキャン検索への応答MOS 1405320.1

パッチ適用の終了日

11.2.0.4 12.1.0.2 12.2.0.1 18 19

2020年12月 2021年7月 2020年11月未定 2026年3月

* パッチ適用が終了したバージョン（11.2.0.3など）から今すぐアップグレードしてください。

長期サポートのリリース


停止時間0（ゼロ）のソフトウェア・メンテナンスソフトウェアのローリング更新のサポート


更新するコンポーネント影響とリスクの軽減方法

データベース/Grid InfrastructureFleet Patching and Provisioningを使用したGI/DBのローリング更新

アプリケーションの継続的な可用性Data Guard Standby First

Exadata データベース・サーバー

データベース・サーバーのローリング更新アプリケーションの継続的な可用性とRHPhelperData Guard Standby First

Exadata Storage Serverストレージ・サーバーのローリング更新

Oracle ASMの高冗長性Data Guard Standby First

Exadata InfiniBandスイッチInfiniBandスイッチのローリング更新Data Guard Standby First

Data Guardによるリスクの軽減と停止時間の短縮Data GuardのStandby Firstパッチの適用（MOS 1265700.1）

Exa dbnode

Exaストレージ

Exaスイッチ

DBディクショナリ

GI/DBホーム

サイトA

Exa dbnode

Exaストレージ

Exaスイッチ


GI/DBホーム

サイトB

Data Guard


Standby Firstパッチの適用手順

1. サイトBのソフトウェアを更新（スタンバイ）

2. 新しいソフトウェアのテスト

3. スイッチオーバー（オプション）

4. サイトAのソフトウェアを更新

5. プライマリ・データベースでRUのSQL部分を実行

Data GuardのStandby Firstパッチ

Exa dbnode

Exaストレージ

Exaスイッチ


GI/DBホーム

サイトA

Exa dbnode

Exaストレージ

Exaスイッチ


GI/DBホーム

サイトB

Data Guard









Exa dbnode

Exaストレージ

Exaスイッチ


GI/DBホーム

サイトA

Exa dbnode

Exaストレージ

Exaスイッチ


GI/DBホーム

サイトB

Data Guard









Exa dbnode

Exaストレージ

Exaスイッチ


GI/DBホーム

サイトA

Exa dbnode

Exaストレージ

Exaスイッチ


GI/DBホーム

サイトB

Data Guard





4. スタンバイでのソフトウェア更新







1

2

3


パッチ適用時パッチ適用前の数週間

ソフトウェア・メンテナンス・フローの概要

ターゲットのバージョンの

特定

Exachkのヘルス・チェック

Prereqの検証Exachkのヘルス・チェック

Prereqの検証更新Exachkのヘルス・チェック

入力

•Exachk•問題の解決

•アプリケーションの互換性

適用先


•Oracle DatabaseおよびGrid Infrastructure•データベース・グリッド、ストレージ・グリッド、ネットワーク用のExadata

Grid InfrastructureおよびDatabaseソフトウェア

• 機能のリリースと四半期ごとの更新– MOS 888828.1で指定された認定リリースのみ使用

• 新機能リリースのアップグレード– Exadataのバージョン要件が満たされていることを事前に確認

• （例 - GI/DB 18cではExadata 18.1.4が必要）

– Exadata専用のステップ・バイ・ステップ・ガイドに従う。 MOS 888828.1を参照。


Grid InfrastructureおよびDatabaseソフトウェア


Fleet Patching and Provisioning

• Fleet Patching and Provisioning（これまでの高速ホーム・プロビジョニング：RHP）

– GI/DBソフトウェアのアウトオブプレース更新を簡素化および自動化

–アプリケーションの継続的な可用性と統合

$ rhpctl move database –dbname ORCL ¥–sourcehome /u01/…/dbhome1 –patchedwc DBHOME18_190416 ¥–drain_timeout 180 …

• アウトオブプレース更新 - GI/DBホームのメンテナンス期間を短縮–メンテナンス期間から除外された更新インストールをリリース

– GIまたはDBがローカルなうちに、新しいソフトウェア・ホームを準備し、更新を適用

–新しいソフトウェア・ホームを使用するよう、GI/DBを迅速に切り替え

停止時間0（ゼロ）のソフトウェア・メンテナンス


アプリケーションの継続的な可用性

• アプリケーションを中断することのない、RACでのアプリケーションの正常なスイッチオーバー（MOS 2440719.1）– dbnodeの計画メンテナンス中にアプリケーションの中断はなし

• Grid Infrastructureソフトウェア・ホームのパッチ適用とアップグレード

• データベース・ソフトウェア・ホームのパッチ適用

• Exadataデータベース・サーバーの更新

–最新の機能と構成を使用

複数インスタンスのRACデータベース FAN対応の接続プール

Clusterwareによって管理されるサービス TNS構成



••

•

•

1. ターゲット・ノードのサービスを停止/再配置して無効化サービスは他のインスタンスに移動し、即座に新しい接続を受け入れる

既存の接続は作業を終了（drain_timeout内に）

2. 残りの長時間実行セッションを切断し、データベース・インスタンスを停止

3. 必要なメンテナンスを実行例：データベース・ホーム・ソフトウェアのパッチ適用、Grid Infrastructureホーム・ソフトウェアの更新、Exadata dbnodeの更新

4. データベース・インスタンスをターゲット・ノードで起動

5. ターゲット・ノードのサービスを有効化して起動サービスは元に移動し、新しい接続の受け入れを開始

6. 次のノードで手順を繰り返す


• 大まかな概要 - サービスの移動とセッションのドレイン

Fleet Patching and Provisioningを使用した場合、完全に自動化される

データベース・ソフトウェア


Oracle Java VMはRACのローリング・インストールが可能

• MOS 2217053.1 - "Oracle Java VMコンポーネント・データベースPSU/RU"（OJVM PSU/RU）パッチのRACローリング・インストール・プロセス

• 以下が必要–ソフトウェアのアウトオブプレース更新

– Clusterwareによって管理されるデータベース・サービス

GI/DBアップグレードが成功する秘訣


GI/DBソフトウェア・メンテナンス・ルール

アプリケーションの継続的な可用性を使用して、アプリケーションへの影響を排除

Data Guardを使用して、プライマリ・システムで使用する前に新しいソフトウェアを評価

Fleet Patching and Provisioningを使用して、パッチの適用を簡素化し、適用時間を短縮

メンテナンスの数週間前にパッチの競合を確認

メンテナンス準備の適格性評価 - exachkとprereqのチェックがクリーンな場合にのみアップグレード

Exadata データベース・サーバーdbnodeのシンプルな更新手順

• Exachkのヘルス・チェック

• –nomodify_at_prereqを使用して最初の前提条件チェックを実行

– patchmgr -dbnode -precheck -nomodify_at_prereq

• -backupフラグを使用して“バックアップのみ”の実行を実施

– patchmgr -dbnodes dbs_group –backup

• 2つ目の前提条件チェックを実行

– patchmgr -dbnodes dbs_group –precheck

• データベース・サーバーを更新

– patchmgr -dbnode -dbnode_upgrade -nobackup [-rolling]

* dom0とdomUの手順は同じですが、別々に実行する必要があります





• RHPhelperを使用して、計画メンテナンス中のExadataの停止時間を最小化（Doc ID 2385790.1）– Exadataの更新中はPatchmgrがOracle Clusterwareの停止と起動を管理

– dbnodeの計画メンテナンス中にアプリケーションの中断はなし• Grid Infrastructureソフトウェア・ホームのパッチ適用とアップグレード

• データベース・ソフトウェア・ホームのパッチ適用

• Exadataデータベース・サーバーの更新

データベース・サーバーのOracle Ksplice更新重要なLinuxの修正プログラムをリブートせずにインストール

• 重要なOracle Linuxカーネルのセキュリティ、安定性、パフォーマンスの修正プログラムを

リブートせずにデータベース・サーバーにインストール

• Exadataの継続リリース間に修正プログラムをインストールすることを予定

例：

1. 四半期ごと - Exadataの継続リリースをインストール

2. 毎月 - Oracle Linuxカーネルのセキュリティ・コンプライアンス用のKsplice更新をインストール

• Kspliceのオフライン・クライアント・プロシージャ

1. uptrackを更新するRPMを取得（ミラー化されたULNリポジトリ、またはULNからのダウンロード）

2. yum / rpmコマンドを使用してインストール（リブートはしない）

• ハウツー：Exadataデータベース・ノードのkspliceカーネル更新のインストール（Doc ID 2207063.1）

1月 Exadataの更新

2月 Kspliceの更新

3月 Kspliceの更新

4月 Exadataの更新


データベース・サーバー - 標準構成とカスタム構成の比較


データベース・サーバー用のExadataの標準構成

ソフトウェアOracle Linuxパッケージとそのバージョン、およびファームウェア・バージョンの一覧

構成ベスト・プラクティスの構成（sysctl、ネットワーク、ssh、pam、モジュール、ドライバなど）

ディスクRAID、論理ボリューム（LVM）、およびファイル・システムの構成

• 標準構成

– Oracle DatabaseおよびGrid Infrastructureを実行するためのベスト・プラクティスの構成

– 意図的に最小限に構成

– リリース前のテストをすべてカバー

• 予測可能な低リスクの更新

• カスタム構成

– デプロイメント後に顧客固有の変更をデータベース・サーバーに適用

– （特定の環境で必要な場合などに）可能。ただしできるだけ回避し、テスト、追跡、自動化を行う

– リリース前のテスト範囲を限定/最小化

– 管理コストとリスクが増大

データベース・サーバーのカスタム構成カスタマイズ例と更新への影響


Exadataの標準構成（カスタマイズなし）

VGExaDbの空き領域をすべて使用

カスタマイズしたファイル・システム – マウント・ポイントが異なる

現在のExadataイメージに付属しているパッケージの更新

追加のrpmパッケージのインストール（Exadata以外）

カスタマイズ構成ファイル、基本的なOS機能の削除/変更

rpm以外の追加パッケージのインストール（Exadata以外）

インタラクティブなシェル・プロファイル/メニューの設定

LVMレイアウトの変更

更新への影響

なし

小

小

小

小

中

中

高

高

データベース・サーバーのカスタマイズ


ベスト・プラクティス

• カスタマイズを避け、必要な場合は最小限に抑える

• ファームウェア

– Exadataの更新プロセス中に自動的にメンテナンスされるため、カスタマイズしない

• Linuxパッケージ（RPM）

– 供給されたパッケージの新しいバージョンへの更新を容認（ULNまたはpublic-yum）

• カーネルおよびブート関連のパッケージは除く

– 新規パッケージの追加を容認

• インストール/削除を自動化 - 一部のExadata更新では、カスタム・パッケージの削除/再インストールが必要

• 導入される新規パッケージの依存関係は、顧客による管理が必要

• 32ビットのパッケージ、または誤ったOLリリースのパッケージ（OL7のOL6 RPMなど）はインストールしない




• システム構成–カーネル・パラメータの変更を回避

• 標準のLinuxサーバー設定は多くの場合適合しない

–ドライバ/モジュール構成の変更は行わない

–実行中のサービスを停止しない

–カスタマイズを詳細に追跡• Exadataの更新で新しいベスト・プラクティスが適用される場合がある（カスタマイズを上書き）

• カスタマイズ後にシステムが適切にブートされるようにする（不適切なブート→アップグレードの失敗）

–シェル・プロファイルはインタラクティブであってはならない




• ローカル・ディスクのRAID、LVM、ファイルシステムの構成– RAID構成の変更は行わない

–供給されたLVM構成の変更は行わない• ボリュームの追加を容認

• dbnodeupdate.shバックアップ・スナップショットに空き領域を残しておく

–供給されたファイルシステム構成の変更は行わない• ファイルシステムの追加を容認

• Oracle Databaseのソフトウェアを/opt/oracleに配置しない

データベース・サーバーのアップグレード成功のための重要点

データベース・サーバー・ソフトウェアのメンテナンス・ルール

アプリケーションの継続的な可用性を使用して、アプリケーションへの影響を排除

カスタマイズは可能だが避ける - 変更をテストし、パッチ適用が失敗する可能性を回避

カスタマイズを確実に追跡し、構築と分解を自動化

メンテナンス準備の適格性評価 - exachkとprereqのチェックがクリーンな場合にのみアップグレード

必ず最新のpatchmgrを使用（Doc ID 1553103.1）


Exadata Storage Serverセルのシンプルな更新手順

• Exachkのヘルス・チェック

• Prereqの検証

# patchmgr -cells -patch_check_prereq [-rolling]

• すべてのストレージ・サーバーの更新

# patchmgr -cells -patch [-rolling]


ストレージ・サーバーの更新フロー非ローリングおよびローリング

非ローリング

データベース/CRSは停止

すべてのセルをパラレルにアップグレード

patc

hmgr

アップグレードセル1

アップグレードセルn



patc

hmgr

ASMのオフライン化アップグレードASMのオンライン化/再同期

セル1


セル2


セル3


セルn

準備すべてのセル


ローリング

データベース/CRSは稼働

1回に1つのセルをアップグレード

patchmgrでASMのオフライン/オンラインを管理

手順 Scope サービスの全セルか?

prereqのチェックすべてのセルをパラレルにはい

新しいソフトウェアのコピーとステージングすべてのセルをパラレルにはい

ディスクの非アクティブ化 1回に1つのセルいいえ

新しいパーティションへのリブート 1回に1つのセルいいえ

ソフトウェア更新の完了 1回に1つのセルいいえ

ファームウェアの更新 1回に1つのセルいいえ

検証 1回に1つのセルいいえ

ディスクのアクティブ化と再同期 1回に1つのセルはい

更新の完了 - 次のセルに移動 1回に1つのセルはい

ストレージ・サーバーのローリング更新大まかなフロー




ASMの高冗長性

• 高冗長性を備えたASMディスク・グループのDATAおよびRECOを定義– OEDA構成中に定義

• デプロイメント後に変更するにはデータの再ロードが必要

• ストレージ・サーバーのローリング更新中に最適な保護を実現するには高冗長性を使用

– 高冗長性 – データは3つのセルでミラー化、標準冗長性 – データは2つのセルでミラー化

– 高冗長性の場合、ディスク障害に耐えることができるが、更新時のストレージ・サーバーはオフライン

• 標準冗長性の場合、ASMディスク・グループがオフラインになり、データ損失を招く可能性がある

ストレージ・サーバー更新の監視patchmgrの進捗状況の電子メール通知


大規模なストレージ・サーバー・ソフトウェア更新（Exadata 18）自動更新のスケジューリング

• セル・ソフトウェアの更新（Exadataのドキュメントを参照）1. セルがソフトウェア・ストアURL（HTTPロケーション）を指すようにする

2. ストアの新しいセル・ソフトウェア更新をステージング

3. セルに更新が自動適用される時間を設定• prereqの検証がスケジュールされた時刻の前に自動的に実行

4. 後続のセル更新を実行 – ステップ2と3を繰り返す

• セルはASMの冗長性チェックを使用して、安全にグリッド・ディスクを非アクティブ化し、セルを更新できるタイミングを判断– 大規模なシステム（フル・ラックなど）では、複数のセルが同時に更新される


ストレージ・サーバーの更新が成功する秘訣


ストレージ・サーバー・ソフトウェアのメンテナンス・ルール

サポートされていない構成変更を行わない

メンテナンス準備の適格性評価 - exachkがクリーンな場合にのみ更新

ASMの高冗長性（またはDG）により、ローリング更新のディスク障害リスクを軽減

Exadata InfiniBandスイッチ

スイッチのシンプルな更新手順1. Exachkのヘルス・チェック

2. Prereqの検証

# patchmgr -ibswitch -ibswitch_precheck

3. すべてのInfiniBandスイッチの更新

# patchmgr -ibswitch -upgrade

メソッド Patchmgrオーケストレーションデータベースの停止時間

ローリング 1回に更新されるスイッチは1個なし


InfiniBandスイッチの更新が成功する秘訣


InfiniBandスイッチ・ソフトウェアのメンテナンス・ルール

サポートされていない構成変更を行わない

メンテナンス準備の適格性評価 - exachkがクリーンな場合にのみ更新

Enterprise Manager Cloud Control 13cを使用した更新Database Lifecycle Management Pack

• すべてのExadataソフトウェアのパッチ適用– Grid InfrastructureおよびDatabaseホーム

• ローリングまたは非ローリング

• インプレースまたはアウトオブプレース

– Exadata Storage Server、データベース・サーバー、InfiniBandスイッチ• ローリングまたは非ローリング

• 四半期フル・スタック・ダウンロード・パッチ（QFSDP）に基づく推奨事項のパッチ適用


まとめExadataの計画メンテナンスのベスト・プラクティス

• Exachkを利用したシンプルなソフトウェア計画

• 利用可能な機能を使用して影響とリスクを緩和–アプリケーションの継続的な可用性

– Data Guard Standby First–ソフトウェアのアウトオブプレース更新

– ASMの高冗長性

• Exadataエンジニアドのデフォルト設定を利用 –カスタマイズを回避


Exadataソフトウェアのメンテナンス


MOS参考資料

• MOS 888828.1 - サポートされるバージョンと推奨されるバージョン

• MOS 1270094.1 - 重大な問題

• MOS 1405320.1 - 一般的なセキュリティ・スキャン検索への応答

• MOS 1553103.1 - データベース・サーバーの更新ツール

• MOS 1070954.1 - Exachk

• MOS 1262380.1 - ソフトウェア・メンテナンスの概要とガイドライン

• MOS 2207063.1 - ハウツー：Exadataデータベース・ノードのkspliceカーネル更新のインストール

• MOS 2440719.1 - アプリケーションを中断することのない、RACでのアプリケーションの正常なスイッチオーバー

exadata software maintenance - oracle...12.1.0.2 12.2.0.1 18 19 2020年12月 2021年7月...

Documents