1 一般的な保守情報
この章では、Oracle Exadata Database Machineの一般的な保守について説明します。
ノート:
- この章のすべての手順は、Oracle ExadataおよびOracle Exadata Storage拡張ラックに適用されます。
- 読みやすさを考慮して、Oracle ExadataとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。
- 役割および職責の概要
発生した問題の解決責任がある個人またはグループを判別する必要があります。 - Oracle Exadataラックの電源の投入および切断
この項では、Oracle Exadataラックのコンポーネントの電源を正しく投入および切断する手順を説明します。 - ハードウェア障害を管理するための自動サービス・リクエストの使用
自動サービス・リクエスト(ASR)は、特定のOracle Exadataラックのハードウェアに障害が発生すると自動的にサービス・リクエストを開くように設計されています。 - Oracle Enterprise Manager Cloud Controlを使用したシステムの監視
- Oracle Configuration Managerを使用したシステムの監視
Oracle Configuration Managerは、構成情報を収集してOracleリポジトリにアップロードします。 - コンポーネントのパスワードの変更
コンポーネントのパスワードは、初期構成後に変更できます。 - サーバー・モデルの判別
セル・サーバーまたはデータベース・サーバーのモデルを判別するには、exadata.img.hw
コマンドを使用します。 - サーバーの周囲温度の監視
- 「ディスク・コントローラ・バッテリ・バックアップ・ユニットの交換」
- dbmsrvサービスの概要
- サーバーにリモートにアクセスするユーザーのパスワードの有効期限の構成
DBSERVER
属性を構成して、ユーザー・パスワードを期限切れにできます。 - 構成変更時のストレージ・サーバーとデータベース・サーバーの状態
構成の変更前に、データベース・サーバーとストレージ・サーバーをオフラインまたはオンラインにする必要があるかどうかを判断します。 - レスキュー計画
- ExaWatcherチャートを使用したOracle Exadataのパフォーマンスの監視
ExaWatcherは、Exadataシステムのストレージ・サーバーおよびデータベース・サーバーのパフォーマンス・データを収集するユーティリティです。収集されるデータには、iostat、セル統計(cellsrvstat)、ネットワーク統計などのオペレーティング・システム統計情報が含まれます。
1.1 役割および職責の概要
発生した問題の解決責任がある個人またはグループを判別する必要があります。
ほとんどのIT組織には、データベース管理者、システム管理者、ネットワーク管理者およびストレージ管理者のチームがあります。これらの管理者はシステム実装および操作の続行を担当します。Oracle Exadata環境では、通常、データベース管理者がシステム管理者のサポートを受けながらOracle Exadata管理の主要な役割を担当するようにするのがより効率的かつ効果的です。これは、Oracle ExadataがOracle Databaseを実行するように設計され、管理がOracle DatabaseおよびOracle Exadata System Softwareを明確に対象にしているためです。その他のチームに異なる職責を与えるか、または第2レベルとしてサポートするようにできます。
通常、発生した問題の主担当は個人またはグループです。システムに問題が発生すると、この担当者または担当するグループがOracle Enterprise Manager Cloud Control、ヘルプ・デスクまたは操作チームから最初に連絡を受けます。Oracle Exadataの場合、通常、主に連絡を担当するのはデータベース管理者です。データベース管理者が問題解決に別のチームのサポートを必要とする場合は、協力して問題を解決します。問題の担当者を明確にしておく必要があります。
- Oracle Exadata管理の共通管理タスク
通常、初期システム・デプロイメントはOracleエンジニアが実行します。データベース管理者の主要職責は通常の操作タスクで開始されます。 - Oracle Exadataでの管理面の差異の理解
Oracle Exadataのサーバー上でのほとんどの管理タスクは、従来のデータベース・サーバーおよびストレージ・サーバーと似ています。ただし、違いがいくつかあります。
親トピック: 一般的な保守情報
1.1.1 Oracle Exadata管理の共通管理タスク
通常、初期システム・デプロイメントはOracleエンジニアが実行します。データベース管理者の主要職責は通常の操作タスクで開始されます。
表1-1 Oracle Exadata管理の共通管理タスク
タスクまたはイベント | 管理者 | アクション |
---|---|---|
パフォーマンスの低下 |
データベース管理者 システム管理者 |
Oracle Enterprise Manager Cloud Controlからパフォーマンスのしきい値を超えたというアラートを受け取ります。 すべてのサーバーのシステム・パフォーマンス、CPU、メモリーおよびI/Oで異常な傾向を確認します。 データベース・パフォーマンス、待機イベント、ロック、並列処理および実行計画を確認します。 |
パッチ適用またはアップグレード |
データベース管理者 システム管理者 |
Oracle Exadata System Softwareのパッチを適用するかアップグレードして、RDMAネットワーク・ファブリック・スイッチのファームウェアをアップグレードします。 Oracle Databaseのパッチ、Oracle Grid Infrastructureのパッチまたはアップグレードを適用します。 |
システム停止または障害 |
データベース管理者 システム管理者 |
Integrated Lights Out Manager (ILOM)に接続し、現在のシステム状態を確認し、ハードウェアの問題点の識別またはシステムの再起動を行い、およびログを確認して根本的な原因を分析します。 実行インスタンスでのエラーのチェック、実行インスタンスのパフォーマンス監視を行い、アプリケーション機能が損われていないことを確認します。 |
疑いのあるネットワークの問題点 |
データベース管理者 システム管理者 |
ネットワーク・インタフェースでエラーまたは削除されたパケットを検出し、再起動したスイッチがあるかどうかをチェックし、必要に応じてネットワーク管理チームにエスカレートします。 データベース側のパフォーマンスを検査して影響を評価します(影響がある場合)。 |
データベースのバックアップ |
データベース管理者 システム管理者 |
データベースのバックアップ・ルーチンを実行し、データベース・サーバーのバックアップが完了していることを確認します。 |
障害ディスクの交換 |
データベース管理者 システム管理者 |
ハードウェア交換に関するアラートを受け取り、Oracle Auto Service Request (ASR)がサービス・リクエストを開いたことを確認し、オペレータがデータ・センターのフィールド・サービス技術者にドライブの交換またはスペアのドライブの提供を許可していることを確認します。 |
親トピック: ロールおよび職責の概要
1.1.2 Oracle Exadataでの管理面の差異の理解
Oracle Exadataのサーバー上でのほとんどの管理タスクは、従来のデータベース・サーバーおよびストレージ・サーバーと似ています。ただし、違いがいくつかあります。
次のリストは、Oracle Exadataサーバーの相違点と例外を示しています:
-
Oracle Exadataのデータベース・サーバー、RDMAネットワーク・ファブリックのスイッチおよびその他のコンポーネントの構成は、テストおよびパフォーマンス基準に基づいて設定されています。会社の方針またはその他の理由により、データベース・サーバーのファームウェアまたはカーネル・パラメータなどの構成設定を変更する場合は、Oracle Exadataに対する影響の可能性を確認する必要があります。
-
サーバーを不正に再起動すると、データベースが壊れる可能性があります。ストレージ・サーバーには、サーバーを再起動する前にグリッド・ディスクをオフラインにする、一度に複数のサーバーを再起動できないなど、データベースの破壊を最小化するために従う必要がある特別な手順とガイドラインがあります。
-
ストレージ・サーバーは、データベース・サーバーと同じ方法では変更できません。NTPサーバーまたはDNSサーバーなどのネットワークの変更は、
ipconf
ユーティリティを使用して行います。ネットワークの変更は構成ファイルを編集して手動で行うことはできません。さらに、ストレージ・サーバーにソフトウェアまたは追加パッケージをインストールすることはできません。この制約にはソフトウェアの監視が含まれます。ストレージ・サーバー・システムのアップデートは、Oracle Exadata System Softwareのアップグレードで行われます。 -
ストレージ・サーバーにバックアップは必要ありません。セルのリカバリには、自己保守される内部USBドライブまたはM.2デバイスが使用できます。ストレージ・サーバーには、バックアップ・クライアントをインストールできません。
-
ストレージ・サーバーを使用するOracle Real Application Clusters (Oracle RAC)データベースのOracle待機イベントには、名前に
%cell%
が付いたイベントが含まれていることがあります。これらのイベントは、ストレージ・サーバー関連のものです。 -
Oracle Databaseの
V$CELL
ビューには、Oracle Exadata Storage Serverを使用するデータベースの行が含まれています。 -
Oracle Automatic Storage Management (Oracle ASM)ディスクのパス名の形式は
o/cell_ip_address/cell_griddisk_name
です。たとえば、次のようになります。o/192.168.10.1/data_CD_01_dm01cel01
-
SQL計画に
storage
を含めると、操作の一部をストレージ・サーバーに肩がわりさせて負荷を軽減できることを示すことができます。 -
バックアップやリカバリなどの操作ではOracle Recovery Manager (RMAN)が使用されます。バックアップおよびリカバリ用のすべてのデータは引き続きデータベース・インスタンスを経由します。RMANのバックアップ・クライアントをOracle Exadataのデータベース・サーバーにインストールし、従来の環境の場合と同じようにエンタープライズ・バックアップ・ソリューションとの統合を容易にする必要があります。
-
開発、テストおよび品質保証用の1つ以上の非本稼働環境のデプロイのプラクティスは、Oracle Exadata環境にも適用されます。
親トピック: ロールおよび職責の概要
1.2 Oracle Exadataラックの電源の投入および切断
この項では、Oracle Exadataラックのコンポーネントの電源を正しく投入および切断する手順を説明します。
- 非緊急時の電源の投入と切断の手順
計画された停止の際には、この手順を使用して、Oracle Exadataラックのコンポーネントの電源投入と切断を正しい順序で実行します。 - 緊急時の電源切断の考慮事項
- 注意事項と警告
親トピック: 一般的な保守情報
1.2.1 非緊急時の電源の投入と切断の手順
計画された停止の際には、この手順を使用して、Oracle Exadataラックのコンポーネントの電源投入と切断を正しい順序で実行します。
- Oracle Exadataラックの電源の投入
- ILOMを使用したリモート・サーバーの電源投入
Integrated Lights Out Manager (ILOM)インタフェースを使用して、サーバーの電源をリモートで投入できます。 - Oracle Exadataラックの電源切断
Oracle Exadataラックのコンポーネントの電源は正しい順序で切断します。 - ネットワーク・スイッチの電源の投入および切断
親トピック: Oracle Exadataラックの電源の投入および切断
1.2.1.1 Oracle Exadataラックの電源の投入
Exadata Storage Serverの電源を投入するには、サーバー前面にある電源ボタンを押すか、ILOMインタフェースにログインしてシステムに電源を投入します。データベース・サーバーの電源が投入され、オペレーティング・システムがブートすると、Oracle Clusterwareがインストールされている場合にOracle Clusterwareが自動的に起動します。Oracle Clusterwareは、自動的に起動する構成のすべてのリソースを起動します。
電源投入の手順は次のとおりです。
親トピック: 非緊急時の電源の投入と切断の手順
1.2.1.2 ILOMを使用したリモート・サーバーの電源投入
Integrated Lights Out Manager (ILOM)インタフェースを使用して、サーバーの電源をリモートで投入できます。
Webコンソール、コマンドライン・インタフェース(CLI)、IPMIまたはSNMPを使用して、ILOMにアクセスできます。たとえば、IPMIを使用してサーバーdm01cel01
に電源を投入するには、電源を投入するサーバーのILOMのホスト名がdm01cel01-ilom
の場合、IPMItoolがインストールされているサーバーから次のコマンドを実行します。
# ipmitool -I lanplus -H dm01cel01-ilom -U root chassis power on
前述のコマンドにより、システムのパスワードの入力が要求されます。
1.2.1.3 Oracle Exadataラックの電源の切断
Oracle Exadataラックのコンポーネントの電源は正しい順序で切断します。
Oracle Exadataラックの電源切断順序は、次のとおりです。
- データベース・サーバー(Oracle Exadataのみ)。
- Exadata Storage Server。
- ラック(スイッチを含む)。
- データベース・サーバーの電源切断
- Oracle Exadata Storage Serverの電源切断
Linuxのshutdown
コマンドを使用して、Oracle Exadata Storage Serverの電源を切断し、再起動します。 - 複数のサーバーの一括電源切断
親トピック: 非緊急時の電源の投入と切断の手順
1.2.1.3.1 データベース・サーバーの電源切断
データベース・サーバーの電源を切断する場合、データベース・サーバーを再起動または停止する前にOracle Clusterwareを停止する必要があります。次のコマンドを使用して、Oracle Clusterwareを停止します。
crsctl stop cluster
次の手順は、データベース・サーバーの推奨されている停止手順になります。
親トピック: Oracle Exadataラックの電源の切断
1.2.1.3.2 Oracle Exadata Storage Serverの電源切断
Linux shutdown
コマンドを使用して、Oracle Exadata Storage Serverの電源を切断し、再起動します。
次のコマンドを使用して、Oracle Exadata Storage Serverを直接停止します。
# shutdown -h now
Oracle Exadata Storage Serverの電源を切断すると、すべてのストレージ・サービスが自動的に停止します。
-r
オプションを使用する場合、shutdown
コマンドを使用してOracle Exadata Storage Serverを停止してから、再起動します。-now
オプションは、サーバーを即座に停止するかどうかを示します。
# shutdown -r now
reboot
コマンドは、サーバーを再起動するためのもう1つのシステム・コマンドです。ただし、サーバーの再起動には、shutdown -r now
コマンドを使用するようにしてください。Oracle Exadata Storage Serverをシャットダウンするために、reboot -f
コマンドは使用しないでください。
ノート:
シャットダウンまたは再起動のコマンドを連続で実行しないでください。これは、reboot -f
と本質的に同じことです。
Oracle Exadata Storage Serverの電源を切断する際は、次の点に注意してください。
-
複数のOracle Exadata Storage Serverを停止する前に、すべてのデータベースおよびOracle Exadata Storage Serverプロセスを停止する必要があります。
-
1つのOracle Exadata Storage Serverの電源を切断しても、実行中のデータベース・プロセスまたはOracle Automatic Storage Management (Oracle ASM)に影響しません。
-
Oracle Exadata Storage Serverの電源切断または再起動により、データベースの可用性に影響を与える場合があります。
-
shutdown
コマンドは、Oracle Exadata Storage Serverを電源切断または再起動するために使用できます。
関連項目:
-
Oracle Exadata Storage Serverの電源を切断してデータベースまたはOracle Clusterwareを稼働したままにする場合は、「Exadata Storage Serverのシャットダウン」を参照してください
-
詳細は、SHUTDOWN(8)マニュアル・ページを参照してください。
親トピック: Oracle Exadataラックの電源の切断
1.2.1.3.3 複数のサーバーの一括電源切断
dcliユーティリティを使用すると、複数のサーバーで同時にshutdown
コマンドを実行できます。停止するサーバーでdcliユーティリティを実行しないでください。たとえば、dcliユーティリティを使用してすべてのExadata Storage Serverを停止するには、データベース・サーバーからコマンドを実行します。次に、コマンドの構文を示します。
# dcli -l root -g group_name shutdown -h now
前述の構文のgroup_nameは、すべてのExadata Storage Serverリストのcell_group
またはデータベース・サーバー・リストのdbs_group
を含むファイルです。
次のコマンドは、同時にすべてのExadata Storage Serverを停止する構文を示しています。
# dcli -l root -g cell_group shutdown -h now
例1-1に、dcliユーティリティを使用して同時に複数のサーバーを停止する場合のOracle Exadataラックの電源切断手順を示します。コマンドはデータベース・サーバーから実行されます。
例1-1 dcliユーティリティを使用したOracle Exadataラックの電源切断
-
次のコマンドを使用して、すべてのデータベース・サーバーのOracle Clusterwareを停止します。
# GRID_HOME/grid/bin/crsctl stop cluster -all
-
次のコマンドを使用して、すべてのリモート・データベース・サーバーを停止します。
# dcli -l root -g remote_dbs_group shutdown -h now
前述のコマンドの
remote_dbs_group
は、すべてのリモート・データベース・サーバーのリストを含むファイルです。 -
次のコマンドを使用して、すべてのExadata Storage Serverを停止します。
# dcli -l root -g cell_group shutdown -h now
前述のコマンドの
cell_group
は、すべてのExadata Storage Serverのリストを含むファイルです。 -
次のコマンドを使用して、ローカル・データベース・サーバーを停止します。
shutdown -h now
-
ラックから電源を切断します。
親トピック: Oracle Exadataラックの電源の切断
1.2.1.4 ネットワーク・スイッチの電源の投入および切断
ネットワーク・スイッチには電源スイッチがありません。配電ユニット(PDU)やデータ・センターのブレーカを介して電力が投入されなくなると、これらの電源は切断されます。
親トピック: 非緊急時の電源の投入と切断の手順
1.2.2 緊急時の電源切断の考慮事項
緊急時には、Oracle Exadataラックの電源をすぐに停止してください。次のような緊急時には、Oracle Exadataラックの電源切断が必要です。
-
地震、洪水、ハリケーン、竜巻、またはサイクロンなどの自然災害の場合。
-
マシンから異常な騒音、臭い、または煙が発生した場合。
-
人の安全を脅かす場合。
1.2.2.1 緊急時の電源切断の手順
緊急時にOracle Exadataラックの電源切断手順を実行するには、ブレーカの電源を切断するか、コンピュータ・ルームの緊急時の電源切断スイッチを切ってください。その後、Oracleサポート・サービスに連絡してマシンの電源を元に戻します。
親トピック: 緊急時の電源切断の考慮事項
1.2.2.2 緊急時の電源切断スイッチ
緊急時の電源切断(EPO)スイッチは、5分より長く750を超えるボルトアンペアを供給できるバッテリがコンピュータ機器に含まれる場合に必要になります。このようなバッテリがシステムで使用される場合、そのシステムには、サイトのEPOスイッチまたはリレーに接続するための内部EPOハードウェアがあります。EPOスイッチを使用すると、Oracle Exadataラックに電力が投入されなくなります。
親トピック: 緊急時の電源切断の考慮事項
1.2.3 注意事項と警告
Oracle Exadataラックには、次の注意事項と警告が適用されます。
-
この製品の高圧電力を使用する部分には触れないでください。触れた場合、重傷を負う可能性があります。
-
緊急時以外は、Oracle Exadataラックの電源を切断しないでください。緊急時は、「緊急時の電源切断の手順」に従ってください。
-
キャビネットの前のドアと後のドアを閉めた状態にしてください。扉を閉めないと、システム障害や、ハードウェア・コンポーネントの破損が生じることがあります。
-
空気が適切に循環し、コンポーネントが過熱しないように、キャビネットの上部、前部および後部に障害物がない状態にしてください。
-
付属のハードウェア以外は使用しないでください。
親トピック: Oracle Exadataラックの電源の投入および切断
1.3 ハードウェア障害を管理するための自動サービス・リクエストの使用
自動サービス・リクエスト(ASR)は、特定のOracle Exadataラックのハードウェアに障害が発生すると自動的にサービス・リクエストを開くように設計されています。
- 自動サービス・リクエストの理解
ハードウェアの問題が検出されると、Oracle ASRマネージャはOracleサポート・サービスにサービス・リクエストを送信します。 - ASRのインストールおよび構成
Oracle Auto Service Request (ASR)は、Oracle SolarisまたはOracle Linuxを実行しているスタンドアロン・サーバーにインストールすることをお薦めします。
親トピック: 一般的な保守情報
1.3.1 「自動サービス・リクエストの理解」
この機能を有効にするには、ハードウェア障害の遠隔測定情報をOracle ASRマネージャ・ソフトウェアに送信するように、Oracle Exadataのコンポーネントを構成する必要があります。このサービスは、ディスクやフラッシュ・カードなどのストレージ・サーバーと、Oracle Databaseサーバーのコンポーネントが対象になります。
Oracle Exadataへの接続があるサーバーと、HTTPSまたはHTTPSプロキシを使用したアウトバウンド・インターネット接続が可能なサーバーに、Oracle ASRマネージャをインストールする必要があります。Oracle Exadataの外部のサーバーにOracle ASR マネージャをインストールすることをお薦めします。推奨理由の一部は、次のとおりです。
-
Oracle ASR Managerを含むサーバーまたはラックがダウンすると、Oracle ASR Managerは、それがサポートするすべてのOracle Exadataコンポーネントで使用できなくなります。複数のOracle ExadataシステムがOracle ASR Managerを使用する場合は、このことを考慮することが非常に重要になります。
-
サービス・リクエスト(SR)を送信するには、サーバーがインターネットにアクセスできる必要があります。
ノート:
Oracle ASRでは管理ネットワークのみを使用できます。Oracle ASRを実行できるように管理ネットワークが設定されていることを確認してください。Oracle ASRを使用する前に、次を設定する必要があります。
-
Oracle Premier Support for SystemまたはOracle/Sun Limited Warranty
-
Oracle Exadataの技術担当窓口
-
Oracle Exadata部品の有効な発送先
電子メールメッセージが技術担当窓口に送信され、アクティブ化されたアセットでサービス・リクエストの作成が通知されます。次に、ディスク障害が発生した場合にOracle ASRマネージャに送信されるSimple Network Management Protocol (SNMP)トラップの例を示します。
ノート:
-
Oracle ASRはコンポーネントの障害のみに適用されます。すべてのコンポーネント障害が対象となるわけではありませんが、ディスク、ファン、電源などのほとんどの共通コンポーネントは対象となります。
-
Oracle ASRは、SMTP、SNMPアラートなど、カスタマ・データ・センター内のその他の監視メカニズムに代わるものではありません。Oracle ASRは、交換ハードウェアの発送を促進および簡素化する補完メカニズムです。Oracle ASRは、高優先度システムのダウンタイム・イベントに使用することはできません。高優先度イベントの場合は、Oracleサポート・サービスまで直接ご連絡ください。
-
サービス・リクエストが自動的に送信されない場合があります。これは、SNMPプロトコルの低い信頼性やOracle ASRマネージャの接続解除により発生する可能性があります。システムの障害について継続的に監視して、サービス・リクエストが自動的に提出されたことを示す通知が送られてこない場合は、Oracleサポート・サービスに問い合せることをお薦めします。
-
Oracle ASRは、Oracle Exadata System Softwareリリース11.2.3.3.0以降を実行しているOracle Exadataシステムの、ファームウェア・リリース2.1.2以降のSun Datacenter InfiniBand Switch 36スイッチを監視できます。フィールド・エンジニアによるスイッチへのエンタイトルメント・シリアル番号の設定が必要になる場合があります。
例1-2 Exadata Storage Server SNMPトラップの例
この例は、ストレージ・サーバーのディスク障害のSNMPトラップを示しています。対応するハードウェア・アラート・コードは強調表示されています。
2011-09-07 10:59:54 server1.example.com [UDP: [192.85.884.156]:61945]:
RFC1213-MIB::sysUpTime.0 = Timeticks: (52455631) 6 days, 1:42:36.31
SNMPv2-SMI::snmpModules.1.1.4.1.0 = OID: SUN-HW-TRAP-MIB::sunHwTrapHardDriveFault
SUN-HW-TRAP-MIB::sunHwTrapSystemIdentifier = STRING: Sun Oracle Database Machine
1007AK215C
SUN-HW-TRAP-MIB::sunHwTrapChassisId = STRING: 0921XFG004
SUN-HW-TRAP-MIB::sunHwTrapProductName = STRING: SUN FIRE X4270 M2 SERVER
SUN-HW-TRAP-MIB::sunHwTrapSuspectComponentName = STRING: SEAGATE ST32000SSSUN2.0T;
Slot: 0SUN-HW-TRAP-MIB::sunHwTrapFaultClass = STRING: NULL
SUN-HW-TRAP-MIB::sunHwTrapFaultCertainty = INTEGER: 0
SUN-HW-TRAP-MIB::sunHwTrapFaultMessageID = STRING: HALRT-02001
SUN-HW-TRAP-MIB::sunHwTrapFaultUUID = STRING: acb0a175-70b8-435f-9622-38a9a55ee8d3
SUN-HW-TRAP-MIB::sunHwTrapAssocObjectId = OID: SNMPv2-SMI::zeroDotZero
SUN-HW-TRAP-MIB::sunHwTrapAdditionalInfo = STRING: Exadata Storage Server:
cellname Disk Serial Number: E06S8K
server1.example.com failure trap.
例1-3 Oracle Database Server SNMPトラップ
この例は、Oracle Database Serverのディスク障害からのSNMPトラップを示しています。対応するハードウェア・アラート・コードは強調表示されています。
2011-09-09 10:59:54 dbserv01.example.com [UDP: [192.22.645.342]:61945]:
RFC1213-MIB::sysUpTime.0 = Timeticks: (52455631) 6 days, 1:42:36.31
SNMPv2-SMI::snmpModules.1.1.4.1.0 = OID: SUN-HW-TRAP-MIB::sunHwTrapHardDriveFault
SUN-HW-TRAP-MIB::sunHwTrapSystemIdentifier = STRING: Sun Oracle Database Machine
1007AK215C
SUN-HW-TRAP-MIB::sunHwTrapChassisId = STRING: 0921XFG004
SUN-HW-TRAP-MIB::sunHwTrapProductName = STRING: SUN FIRE X4170 M2 SERVER
SUN-HW-TRAP-MIB::sunHwTrapSuspectComponentName = STRING: HITACHI H103030SCSUN300G
Slot: 0SUN-HW-TRAP-MIB::sunHwTrapFaultClass = STRING: NULL
SUN-HW-TRAP-MIB::sunHwTrapFaultCertainty = INTEGER: 0
SUN-HW-TRAP-MIB::sunHwTrapFaultMessageID = STRING: HALRT-02007
SUN-HW-TRAP-MIB::sunHwTrapFaultUUID = STRING: acb0a175-70b8-435f-9622-38a9a55ee8d3
SUN-HW-TRAP-MIB::sunHwTrapAssocObjectId = OID: SNMPv2-SMI::zeroDotZero
SUN-HW-TRAP-MIB::sunHwTrapAdditionalInfo = STRING: Exadata Database Server: db03
Disk Serial Number: HITACHI H103030SCSUN300GA2A81019GGDE5E
dbserv01.example.com failure trap.
1.3.2 ASRのインストールおよび構成
Oracle Auto Service Request (ASR)は、Oracle SolarisまたはOracle Linuxを実行しているスタンドアロン・サーバーにインストールすることをお薦めします。
インストールが完了したら、Oracle Exadataのサーバーに対して障害の遠隔測定情報の送信先を構成します。Oracle Exadataのサーバーは、初期構成時に設定できます。Oracle Exadata Deployment Assistant (OEDA) で構成情報を収集し、サーバーを構成します。
ノート:
Integrated Lights Out Manager (ILOM)アラート設定を構成する場合、ルール・リストの上部にあるルールを削除しないでください。新しいルールを追加するには、ルール・リストの一番下にルールを入力します。- 初期構成後にOracle ASRをインストールして構成する方法の詳細は、『Oracle Auto Service Request Oracle Exadata Database Machineクイック・インストレーション・ガイド』に記載されているインストールおよび構成の情報を参照してください。
関連項目:
-
Oracle Exadata Database Machine Oracle Auto Service Requestクイック・インストレーション・ガイド
-
OEDAのOracle ASR構成ページの詳細は、『Oracle Exadata Database Machineインストレーションおよび構成ガイド』を参照してください
-
Oracle Auto Service Requestのユーザー・ドキュメント(
http://www.oracle.com/technetwork/systems/asr/documentation/index.html
)
1.4 Oracle Enterprise Manager Cloud Controlを使用したシステムの監視
Oracle Exadata Database Machineは、Oracle Enterprise Manager Cloud ControlエージェントでOracle ExadataプラグインおよびOracle Systems Infrastructureプラグインを使用して監視できます。Oracle Exadata Database Machineは、Oracle Enterprise Manager Cloud Controlでシステム・ターゲットとして検出および監視されます。個々のデータベース・サーバー、ストレージ・サーバーおよびスイッチがOracle Exadata Database Machineのシステム・ターゲットにグループ化されるので、グループ単位で監視できます。
Oracle Exadata Storage Serverメトリックは、管理サーバー(MS)によって収集および管理されます。Oracle Enterprise Manager Cloud Controlと一緒に使用すると、Oracle Enterprise Manager Cloud Controlメトリックとしてメトリックが示されます。
SNMPにより、すべてのExadataサーバー・アラートがOracle Enterprise Manager Cloud Controlに配信されます。Exadataハードウェアおよびソフトウェア・コンポーネントは、Integrated Lights Out Manager (ILOM)およびOracle Exadata System Softwareで次のように監視されます。
-
ハードウェア・コンポーネントは、ILOMによって監視されます。ハードウェア・コンポーネントが障害またはしきい値を超えたことを報告した場合、ILOMはSNMPトラップとして障害をMSに報告します。MSは、トラップを処理してアラートを作成し、アラートをOracle Enterprise Manager Cloud Controlエージェントに配信します。
-
ハードウェアおよびソフトウェア・コンポーネントもMSによって直接監視されます。障害またはしきい値を超えると、MSは、トラップを処理してアラートを作成し、アラートをOracle Enterprise Manager Cloud Controlエージェントに配信します。
エンドユーザーの観点から、2つのタイプのアラートに違いはありません。アラート・メッセージには、アラートを解決するための是正処置が含まれています。
関連項目:
-
Oracle Enterprise Manager Cloud Controlのインストールの詳細は、『Oracle Exadata Database Machineインストレーションおよび構成ガイド』を参照してください
-
修復の実行時に不要なアラートを回避するブラックアウトの使用方法の詳細は、Oracle Enterprise Manager Cloud Control管理者ガイドを参照してください
-
Enterprise ManagerとExadataの管理性のベスト・プラクティスは、Enterprise ManagerのMAAベスト・プラクティスの分野(http://www.oracle.com/goto/maa)を参照してください。
親トピック: 一般的な保守情報
1.5 Oracle Configuration Managerを使用したシステムの監視
Oracle Configuration Managerは、構成情報を収集してOracleリポジトリにアップロードします。
構成情報が毎日アップロードされると、Oracleサポート・サービスでデータを分析して適切なサービスを提供できます。サービス・リクエストが記録されると、構成データがサービス・リクエストに関連付けられます。次に、Oracle Configuration Managerの利点の一部を示します。
-
問題解決の時間の短縮
-
事前の問題回避
-
ベスト・プラクティスおよびOracleナレッジ・ベースのアクセスの向上
-
お客様のビジネス・ニーズの詳細な理解
-
一貫したレスポンスおよびサービス
サーバーの各ORACLE_HOME
ディレクトリに、Oracle Configuration Managerソフトウェアがインストールおよび構成されます。クラスタ化されたデータベースには、Oracle Configuration Managerに1つのインスタンスのみが構成されます。構成スクリプトは、サーバーのすべてのデータベースで実行されます。Oracle Configuration Managerコレクタが集中管理されているOracleリポジトリにデータを送信します。
1.6 コンポーネントのパスワードの変更
コンポーネントのパスワードは、初期構成後に変更できます。
- データベース・サーバーのパスワードの変更
- Exadata Storage Serverのパスワードの変更
root
ユーザーとして、passwd
コマンドを使用して、Exadata Storage Serverのオペレーティング・システムのユーザー・パスワードを変更します。 - 配電ユニットのパスワードの変更
- ILOMのパスワードの変更
- InfiniBandスイッチのパスワードの変更
この手順では、InfiniBandスイッチのパスワードを変更する方法について説明します。 - Cisco管理ネットワーク・スイッチまたはRoCEネットワーク・ファブリック・スイッチのパスワードの変更
Cisco管理ネットワーク・スイッチまたはRDMA over Converged Ethernet (RoCE)スイッチのパスワードを変更するには、スイッチに接続してスイッチに対してコマンドを実行する必要があります。 - KVMのパスワードの変更
親トピック: 一般的な保守情報
1.6.1 データベース・サーバーのパスワードの変更
ユーザー・アカウントとGRUBのパスワードは、データベース・サーバーで変更できます。データベース・サーバーのデフォルトのユーザー・アカウントはroot
およびソフトウェア所有者のアカウントです。通常、ソフトウェア所有者のアカウントはoracle
またはgrid
です。
- データベース・サーバーでのユーザー・アカウントのパスワードの変更
root
ユーザーとして、passwd
コマンドを使用して、オペレーティング・システムのユーザー・パスワードを変更します。 - データベース・サーバーでのGRUBアカウントのパスワードの変更
データベース・サーバーのGRUBアカウントのパスワードを変更するには、host_access_control
スクリプトを使用します。
親トピック: コンポーネントのパスワードの変更
1.6.1.1 データベース・サーバーでのユーザー・アカウントのパスワードの変更
root
ユーザーとして、passwd
コマンドを使用して、オペレーティング・システムのユーザー・パスワードを変更します。
オペレーティング・システム・プロンプトで次のコマンドを使用します。ここで、user_nameは、変更するユーザー・アカウントを示します。
# passwd user_name
関連トピック
親トピック: データベース・サーバーのパスワードの変更
1.6.1.2 データベース・サーバーでのGRUBアカウントのパスワードの変更
データベース・サーバーのGRUBアカウントのパスワードを変更するには、host_access_control
スクリプトを使用します。
次のコマンドをroot
ユーザーとして実行し、データベース・サーバーのGRUBアカウントのパスワードを変更します。
# /opt/oracle.cellos/host_access_control grub-password
親トピック: データベース・サーバーのパスワードの変更
1.6.2 Exadata Storage Serverのパスワードの変更
root
ユーザーとして、passwd
コマンドを使用して、Exadata Storage Serverのオペレーティング・システムのユーザー・パスワードを変更します。
Exadata Storage Serverのデフォルトのユーザー・アカウントはroot
、celladmin
およびcellmonitor
です。
オペレーティング・システム・プロンプトで次のコマンドを使用します。ここで、user_nameは、変更するユーザー・アカウントを示します。
# passwd user_name
親トピック: コンポーネントのパスワードの変更
1.6.3 配電ユニットのパスワードの変更
配電ユニット(PDU)のデフォルトのユーザー・アカウントはadmin
です。次の手順では、PDUのパスワードを変更する方法について説明します。
- Webブラウザのアドレス行にPDUメーター・ユニットのIPアドレスを入力して、ユニットにアクセスします。現在の測定ページが表示されます。
- ページの左上の「ネットワーク構成」をクリックします。
- PDUメーター・ユニットに
admin
ユーザーとしてログインします。 - 管理/ユーザー・フィールドを探します。ユーザー名とパスワードには、アルファベットと数字のみを使用できます。
- 管理/ユーザー・フィールドにユーザーとパスワードを最大で5つまで入力します。
- 各ユーザーを管理者またはユーザーとして指定します。
- 「送信」をクリックして、ユーザーとパスワードを設定します。
親トピック: コンポーネントのパスワードの変更
1.6.4 ILOMのパスワードの変更
Integrated Lights Out Manager (ILOM)のデフォルトのユーザー・アカウントはroot
です。次の手順では、ILOMのパスワードを変更する方法について説明します。
親トピック: コンポーネントのパスワードの変更
1.6.5 InfiniBandスイッチのパスワードの変更
この手順では、InfiniBandスイッチのパスワードを変更する方法について説明します。
InfiniBandスイッチのデフォルトのユーザー・アカウントはroot
、ilom-admin
、ilom-user
、ilom-operator
およびnm2user
です。
関連項目:
Sun Datacenter InfiniBand Switch 36ファームウェア・バージョン2.1管理ガイド(http://docs.oracle.com/cd/E36265_01/html/E36266/gentextid-2626.html#scrolltoc
)親トピック: コンポーネントのパスワードの変更
1.6.6 Cisco管理ネットワーク・スイッチまたはRoCEネットワーク・ファブリック・スイッチのパスワードの変更
Cisco管理ネットワーク・スイッチまたはRDMA over Converged Ethernet (RoCE)スイッチのパスワードを変更するには、スイッチに接続してスイッチに対してコマンドを実行する必要があります。
- Cisco 93xxスイッチのパスワードの変更
change-password
コマンドを使用して、Cisco Nexus 93108-1G、Cisco Nexus 9348またはCisco Nexus 9336C-FX2スイッチのパスワードを変更します。 - Cisco 4948イーサネット・スイッチのパスワードの変更
スイッチへのシリアル・ポート・アクセスとSSHアクセスの両方のパスワードを変更できます。
親トピック: コンポーネントのパスワードの変更
1.6.6.1 Cisco 93xxスイッチのパスワードの変更
change-password
コマンドを使用して、Cisco Nexus 93108-1G、Cisco Nexus 9348またはCisco Nexus 9336C-FX2スイッチのパスワードを変更します。
1.6.6.2 Cisco 4948イーサネット・スイッチのパスワードの変更
スイッチへのシリアル・ポート・アクセスとSSHアクセスの両方のパスワードを変更できます。
スイッチにアクセスするには、2つの異なる方法があります。1つはシリアル・ポートを使用し、もう1つはssh
を使用します。
-
シリアル・ポート: シリアル・ポート・アクセスを使用する場合は、ユーザー・アカウントがないため、
enable
パスワードのみが必要となります。 -
ssh
:ssh
を介してスイッチにアクセスする場合は、パスワードを変更する前に、ユーザー・アカウントとパスワードを指定する必要があります。
admin
ユーザーが作成されるため、このユーザーを使用してssh
でスイッチにアクセスできます。
- シリアル・ポート・アクセス用のCisco 4948イーサネット・スイッチのパスワードの変更
スイッチへのシリアル・ポート・アクセスとSSHアクセスの両方のパスワードを変更できます。 - TelnetまたはSSHアクセス用のCisco 4948イーサネット・スイッチのパスワードの変更
スイッチへのシリアル・ポート・アクセスとSSHアクセスの両方のパスワードを変更できます。
1.6.6.2.1 シリアル・ポート・アクセス用のCisco 4948イーサネット・スイッチのパスワードの変更
スイッチへのシリアル・ポート・アクセスとSSHアクセスの両方のパスワードを変更できます。
1.6.7 KVMのパスワードの変更
KVMのデフォルトのユーザー・アカウントはAdmin
です。次の手順では、KVMのパスワードを変更する方法について説明します。
- ラックの前面からKVMトレイを引き出して、ハンドルを使用して開きます。
- タッチ・パッドに触れます。
- マウスのダブルクリックと同じように左側の[Ctrl]キーを2回押して、ホストとKVMインタフェースを切り替えます。
- ユーザー・アカウントから「ローカル」を選択します。
- ユーザーの下の「管理」をクリックします。
Admin
アカウントのパスワードを設定します。他のパラメータを変更しないでください。- 「保存」をクリックします。
親トピック: コンポーネントのパスワードの変更
1.7 サーバー・モデルの判別
セル・サーバーまたはデータベース・サーバーのモデルを判別するには、exadata.img.hw
コマンドを使用します。
/usr/sbin/exadata.img.hw --get model
Oracle Exadataのサーバー・モデル名および番号は、次の表を参照してください。
表1-2 Oracle Exadataのサーバー・モデル
Oracle Exadata | データベース・サーバーのモデル | Exadata Storage Serverのモデル |
---|---|---|
Oracle Exadata X10M |
|
|
Oracle Exadata X9M-2 |
|
|
Oracle Exadata X9M-8 |
|
|
Oracle Exadata X8M-2 |
|
|
Oracle Exadata X8-2 |
|
|
Oracle Exadata X8M-8 |
|
|
Oracle Exadata X8-8 |
|
|
Oracle Exadata X7-2 |
|
|
Oracle Exadata X7-8 |
|
|
Oracle Exadata X6-2 |
|
|
Oracle Exadata X6-8 |
|
|
Oracle Exadata X5-2 |
|
|
Oracle Exadata X5-8 |
|
|
Oracle Exadata X4-2 |
|
|
Oracle Exadata X4-8フル・ラック |
|
|
Oracle Exadata X3-2 |
|
|
Oracle Exadata X3-8フル・ラック |
|
|
Oracle Exadata X2-2 |
|
|
Oracle Exadata X2-8フル・ラック |
|
|
親トピック: 一般的な保守情報
1.8 サーバーの周囲温度の監視
環境温度条件をOracle Exadataラックの設計仕様内に維持すると、最大限の効率化とコンポーネント・サービスの目標存続期間の達成に役立ちます。周囲温度範囲の検証による影響は最小です。是正処置による影響は、環境条件によって異なります。
Oracle Exadata Rackの動作時の周囲温度範囲は摂氏5から32度(華氏41から89.6度)です。ただし、効率性とコンポーネントの寿命を最大にするための最適な温度範囲は摂氏21から23度(華氏70から74度)です。詳細は、温度および湿度要件を参照してください。
次のコマンドをクラスタの最初のデータベース・サーバーのroot
ユーザーとして使用し、クラスタのすべてのサーバーの温度を検証します。
dcli -g /opt/oracle.SupportTools/onecommand/all_group -l root 'ipmitool sunoem cli "show /SYS/T_AMB" | grep value'
次に、コマンドの出力例を示します。
dm01db01: value = 21.440 degree C
dm01db02: value = 21.440 degree C
dm01db03: value = 22.190 degree C
...
dm01db08: value = 21.940 degree C
dm01cel01: value = 22.000 degree C
dm01cel02: value = 22.000 degree C
dm01cel03: value = 23.000 degree C
...
dm01cel14: value = 22.080 degree C
出力が周囲温度範囲外の場合は、問題を調査して是正します。次の項目をチェックする必要があります。
-
ラックに十分な通気がある
-
室温が指定範囲内にある
-
ラックの背面に障害物がない
親トピック: 一般的な保守情報
1.9 「ディスク・コントローラ・バッテリ・バックアップ・ユニットの交換」
ディスク・コントローラ・バッテリ・バックアップ・ユニット(ディスク・コントローラBBU)は、データベースおよびExadata Storage Serverのドライブ・トレイにあります。ディスク・コントローラBBUは、サーバーおよびサーバー上で実行されているアプリケーションの停止時間なしで交換できます。
ノート:
この項の手順は、コントローラに内蔵のバッテリ・バックアップ・ユニットには適用されません。これらのユニットを交換する場合は、システムを開いてコントローラ・カードにアクセスするため、システムを停止する必要があります。- データベース・サーバーのディスク・コントローラBBUの交換
- Exadata Storage Serverのディスク・コントローラBBUの交換
この項では、Exadata Storage Serverのディスク・コントローラBBUを交換する方法について説明します。
親トピック: 一般的な保守情報
1.9.1 データベース・サーバーのディスク・コントローラBBUの交換
この項では、データベース・サーバーのディスク・コントローラBBUを交換する方法について説明します。
ノート:
保守手順の終了後は、常にOracle EXAchkツールを使用することをお薦めします。このツールはMy Oracle Supportノート1070954.1から入手できます。
高度なステップは次のとおりです。
- ステップ1: ディスク・コントローラBBUの取外しの準備
ディスク・コントローラBBUの取外し方法は、Oracle Exadata Database Machineモデルによって異なります。 - ステップ2: ディスク・コントローラBBUの交換
- ステップ3: 新しいディスク・コントローラBBUの有効化および確認
1.9.1.1 ステップ1: ディスク・コントローラBBUの取り外しの準備
ディスク・コントローラBBUの取り外し方法は、Oracle Exadata Database Machineモデルによって異なります。
特定のOracle Exadata Database Machine X3-2、X4-2およびX4-8データベース・ノード、Oracle Exadata Database Machine X3-2、X4-2、X3-8およびX4-8ストレージ・サーバーでは、BBUはリモートでマウントされ、アクセスするためにシステムのシャットダウンは不要です。ただし、ディスク・ボリュームへのデータ破損を回避するには、RAID HBAから取り外せるように準備する必要があります。
ノート:
Oracle Exadata Database Machine X3-8データベース・ノードには、リモート・マウントBBUのオプションがありません。- リモート・マウントBBUがあるシステムの準備
リモート・マウントBBUがあるシステムのディスク・コントローラBBUを取り外す際の準備方法について説明します。 - リモート・マウントBBUがないシステムの準備
このトピックでは、リモート・マウントBBUがないシステムのディスク・コントローラBBUを取り外す際の準備方法について説明します。
1.9.1.1.1 リモート・マウントBBUがあるシステムの準備
リモート・マウントBBUがあるシステムのディスク・コントローラBBUを取り外す際の準備方法について説明します。
システムにリモート・マウントBBUがない場合は、「リモート・マウントBBUがないシステムの準備」を参照してください。
親トピック: ステップ1: ディスク・コントローラBBUの取外しの準備
1.9.1.1.2 リモート・マウントBBUがないシステムの準備
このトピックでは、リモート・マウントBBUがないシステムのディスク・コントローラBBUを取り外す際の準備方法について説明します。
リモート・マウントされたバッテリがシステムに取り付けられていない場合は、バッテリの交換が必要なノードをシャットダウンする必要があります。
システムにリモート・マウントBBUがある場合は、「リモート・マウントBBUがあるシステムの準備」を参照してください。
親トピック: ステップ1: ディスク・コントローラBBUの取外しの準備
1.9.1.2 ステップ2: ディスク・コントローラBBUの交換
このステップでは、古いディスク・コントローラBBUを取り外し、新しいBBUと交換します。
リモート・バッテリを装着したExadata X3-2、X4-2またはX4-8計算ノード、およびX3-2、X3-8、X4-2またはX4-8ストレージ・セル・ノード
これらのステップは、リモート・バッテリが取り付けられたX3-2、X4-2、X4-8およびX3-2L、X4-2Lサーバーに基づいたExadataノードに適用されます。
-
オレンジ色と白色のBBUラベルのマークが付いたバッテリを特定します。
X3-2およびX4-2計算ノード: BBUのラベルが付いたシャーシの前面の右上隅のスロットです(以前に指定した"HDD7")。
X4-8計算ノード: BBUというラベルの付いたシャーシの背面の下側にあるスロットの左から2番目にあります。
X3-2LおよびX4-2Lストレージ・セル: BBUのラベルが付いた、PS1の上のシャーシ背面の右側のスロットです(以前に指定した"REAR HDD 1")。
-
ラッチを解除し、古いBBUキャリアをスライドさせて慎重に引き出します。
-
新しいBBUキャリアを挿入して慎重にスライドさせ、ラッチで固定して閉じます。
リモート・バッテリのないExadata X3-2LまたはX4-2Lストレージ・セル・ノード
Supportノート1561949.1に詳細に記載されているCAPに従い、既存のHBA BBUとリモート・マウントされたバッテリ・キット(部品番号7060020)を交換します。
リモート・バッテリのないExadata X3-2またはX4-2データベース・マシン計算ノード
Supportノート1561949.1に詳細に記載されているCAPに従い、既存のHBA BBUとリモート・マウントされたバッテリ・キット(部品番号7060020)を交換します。
Exadata X3-8データベース・マシン計算ノード
ノート:
Exadata X3-8データベース・マシン計算ノードは、X2-8サーバーに基づいています。表1-2を参照してください-
CMOD0をサーバーから取り外し、平らな静電気防止面の上に置きます。
-
CMODの上部カバーを取り外します。
-
BBUが取り付けられているHBA REMを取り外します。
-
REMイジェクタ・ハンドルを持ち上げ、開位置まで回転します。
-
REMのコネクタの端を持ち上げ、前面の支持金具の固定クリップからREMを引き抜きます。
-
-
古いBBUをREMから取り外します。
-
プラスのねじ回し(Phillipsの1番)を使用して、バッテリをREMカードに固定している3本の留めねじを外します。REMとバッテリ・パックの上側のねじは外さないでください。これらのねじは、底部にねじ穴のある支持具を固定しており、バッテリ・パックに付けたままにしておく必要があります。
-
回路基板を含むバッテリ・パックを、回路基板コネクタからゆっくり持ち上げ、REMから取り外します。
-
-
新しいBBUをREMに取り付けます。
-
バッテリ・パックの回路基板コネクタを取り付け、REMのコネクタに接続します。
-
プラスのねじ回し(Phillipsの1番)を使用して、バッテリをREMに固定します。BBUに新しいねじのパッケージが付属している場合は、それらのねじを使用し、古いBBUアタッチメントのねじは再利用しないでください。
-
-
BBUが取り付けられているHBA REMを元どおりに取り付けます。
-
REMイジェクタ・レバーが閉位置になっていることを確認します。レバーはREM支持金具と平らになっている必要があります。
-
バッテリが下を向いており、コネクタとマザーボードのコネクタの位置が合うように、REMの位置を合わせます。
-
REMの反対の端を前面の支持金具の固定クリップの下に滑らせ、REMの端のノッチが金具の位置合せポストの周囲に位置していることを確認します。
-
REMがマザーボードのコネクタに接する位置まで、REMのコネクタの端を慎重に押し下げ、コネクタの位置が合っていることを確認します。コネクタを固定するには、レベル位置までREMを慎重に押し込みます。
-
-
カバーをCMODに取り付けます。
-
CMODをCMOD0スロットのユニットに戻します。
1.9.1.3 ステップ3: 新しいディスク・コントローラBBUの有効化および確認
ステップ1: ディスク・コントローラBBUの取外しの準備と同様、このステップには2つのサブ項目があります。
リモート・マウントBBUがあるシステムの場合
リモート・マウントBBUがあるシステムの場合、ステップ1: ディスク・コントローラBBUの取外しの準備の終了時にはシステムがシャットダウンされませんでした。
Oracle Exadata System Softwareバージョン11.2.3.3.0以降を使用している場合:
ノート:
Oracle Exadata System Software 19.1.0以上を実行している場合は、次のコマンドで/opt/MegaRAID/MegaCli/MegaCli64
を/opt/MegaRAID/storcli/storcli64
に置き換えます。
-
ルート・ユーザーとしてログインします。
-
ディスク・コントローラBBUのバッテリ状態が存在し、RAIDコントローラで表示されていることを確認します。新しいBBUバッテリが検出されるまでに数分かかる場合があります。
ノート:
Solarisで実行している場合は、次のコマンドの/opt/MegaRAID/MegaCli/MegaCli64
の代わりに/opt/MegaRAID/MegaCli
を使用します。# /opt/MegaRAID/MegaCli/MegaCli64 -AdpAllInfo -a0 | grep BBU BBU : Present BBU : Yes Cache When BBU Bad : Disabled
-
ディスク・コントローラBBUおよびディスク・キャッシュを再有効化します。
-
Oracle Exadata System Softwareバージョン12.1.2.1.0以降を実行している場合:
DBMCLI> ALTER DBSERVER BBU REENABLE
-
Oracle Exadata System Software 12.1.2.1.0より前のバージョンを実行している場合:
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -reenable_bbu HDD disk controller battery has been reenabled.
-
-
ディスク・コントローラBBUのバッテリ状態がOperationalであることを確認します。
-
Oracle Exadata System Softwareバージョン12.1.2.1.0以降を実行している場合:
DBMCLI> LIST DBSERVER ATTRIBUTES bbustatus
-
Oracle Exadata System Software 12.1.2.1.0より前のバージョンを実行している場合:
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -list_bbu_status BBU status: present
-
-
現在の論理ディスク・ドライブのキャッシュ・ポリシーでライトバック・モードが使用されていることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep -i bbu Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU ... <repeated for each logical volume present>
-
現在のキャッシュ・ポリシーがライトスルー・モードで、ライトバックでない場合は、バッテリのステータスをチェックします。
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -getbbustatus -a0|grep Battery BatteryType: iBBU08 Battery State : Operational Battery Pack Missing : No Battery Replacement required : No
バッテリの状態が"Operational"または"Optimal" (正確な用語はイメージ・バージョンによって異なります)以外の場合は、続行する前に問題を調査して修正します。
次に示すイメージ・バージョンは、"Optimal"および"Operational"を使用しています。
Exadata image version Battery State Raid f/w version --------------------- ------------------- ----------------- X4 12.1.2.1.0 Optimal 12.12.0-0178 X4 12.1.1.1.1 Optimal 12.12.0-0178 X3 11.2.3.3.0 Optimal 12.12.0-0178 X3 11.2.3.2.2 Optimal 12.12.0-0178 X3 11.2.3.2.1 Operational 12.12.0-0140
イメージ・バージョン11.2.3.2.xを使用している場合:
-
ルート・ユーザーとしてログインします。
-
サーバーの検出LEDをオフにします。
# ipmitool chassis identify off Chassis identify interval: off
-
HBAが認識され、新しいBBUと通信を開始するまで、約5分間待機します。
-
HBAバッテリ・ステータスがOperationalで、充電中であることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
-
すべての論理ドライブのキャッシュ・ポリシーをライトバック・キャッシュ・モードに設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0
-
すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep -i bbu Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU ... <repeated for each logical volume present>
リモート・マウントBBUがないシステムの場合
リモート・マウントBBUがないシステムの場合、ステップ1: ディスク・コントローラBBUの取外しの準備の終了時にシステムをシャットダウンします。この項では、システムを再起動して新しいBBUを有効にします。
ノート:
Oracle Exadata System Software 19.1.0以上を実行している場合は、次のコマンドで/opt/MegaRAID/MegaCli/MegaCli64
を/opt/MegaRAID/storcli/storcli64
に置き換えます。
- 電源ボタンを押して、サーバーの電源を入れます。
- ILOMが起動したら、電源ボタンを押してサーバーの電源を入れ、サーバーのコンソールに接続します。
ILOM Webブラウザからコンソールに接続する手順(推奨): リモート制御→リダイレクト・タブにアクセスし、リモート・コンソールの起動ボタンをクリックします。ILOM 3.1.xシステムでは、コンソール・ボタンは最初の「サマリー情報」画面から起動できます。
ILOM CLIからコンソールに接続するには:
> start /SP/console
- サーバーのコンソールから、システム・ブートを監視します。特に、ロード中のLSIコントローラのBIOSを監視してください。保存されているキャッシュがあるドライブに関する警告メッセージが表示される場合、"D"を選択すると、キャッシュを破棄して続行されます。ASMによる起動後に、ディスクが再同期されるため、これは問題ではありません。バッテリ低下によりライトスルー・モードになっているドライブに関する警告メッセージが表示される場合は、選択して続行します。
その後、Exadataの起動が正常に続行されると、Exadataのブート・スプラッシュ画面が表示され、通常のOSブート・メッセージが引き続き表示されます。後続の起動ステップ中に、ILOMシリアル・コンソールの画面出力の間の停止時間が長くなる場合がありますが、これは、デフォルトのコンソールがグラフィックで、Exadataブート・スプラッシュ画面が表示されないためです。
- 起動がすべて完了したら、rootユーザーとしてログインし、新しいバッテリが表示されて充電中であることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
- すべての論理ドライブのキャッシュ・ポリシーを、バッテリを使用するライトバック・キャッシュ・モードに設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0
- すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
- データベース・サービスが自動的に開始されたことを確認します。
- CRSが実行中であることを確認します。
前述の出力では、# . oraenv ORACLE_SID = [root] ? +ASM1 The Oracle base for ORACLE_HOME=/u01/app/11.2.0/grid is /u01/app/oracle # crsctl check crs CRS-4638: Oracle High Availability Services is online CRS-4537: Cluster Ready Services is online CRS-4529: Cluster Synchronization Services is online CRS-4533: Event Manager is online
+ASM1
の1
はデータベース・ノード番号を指します。たとえば、ノード#3のデータベースでは、値は+ASM3
になります。 - インスタンスが実行中であることを検証します。
ASMインスタンスのレコードと各データベースのレコードが返されます。# ps -ef |grep pmon
- CRSが実行中であることを確認します。
1.9.2 Exadata Storage Serverのディスク・コントローラBBUの交換
この項では、Exadata Storage Serverのディスク・コントローラBBUを交換する方法について説明します。
ノート:
保守手順の終了後は、常にOracle EXAchkツールを使用することをお薦めします。このツールはMy Oracle Supportノート1070954.1から入手できます。高度なステップは次のとおりです。
1.9.2.1 ステップ1: ディスク・コントローラBBUの取り外しの準備
特定のX3-2、X4-2およびX4-8データベース・ノード、X3-2、X4-2、およびX3-8、X4-8ストレージ・サーバーでは、BBUはリモートでマウントされ、アクセスするのにシステムのシャットダウンは不要です。ただし、ディスク・ボリュームへのデータ破損を回避するには、RAID HBAから取り外せるように準備する必要があります。X3-8データベース・ノードのリモート・マウントBBUオプションはありません。
リモート・マウントBBUがあるシステムの場合
システムにリモート・マウントBBUがある場合は、この項のステップを実行します。システムにリモート・マウントBBUがない場合は、「リモート・マウントBBUがないシステムの場合」のステップを実行します。
root
ユーザーとしてログインします。- サービスを必要とするラックのサーバーで実行されているイメージのバージョンを取得します。
# cellcli -e LIST CELL ATTRIBUTES releaseVersion 11.2.3.2.1
- ディスク・コントローラBBUを削除します。
バージョン11.2.3.3.0以上を実行している場合:
- 交換対象のディスク・コントローラBBUを削除します。次のコマンドを
celladmin
またはroot
ユーザーとして実行します。# cellcli -e ALTER CELL BBU DROP FOR REPLACEMENT HDD disk controller battery has been dropped for replacement
- 交換対象のBBUが削除されたことを確認します。
# cellcli -e LIST CELL ATTRIBUTES bbustatus dropped for replacement.
バージョン11.2.3.2.xを実行している場合:
- サービス対象のラックのサーバーを特定し、インジケータ・ライトをオンにします。
Exadata Storage Serverは、1から18の番号で識別され、RU2に取り付けられたラックの最下段のStorage Serverが1で、ラックの上部に向かって番号が順に上がっていきます。
Exadata Database Nodeは、1から8の番号で識別され、RU16に取り付けられたラックの最下段のデータベース・ノードが1です。
サービス対象のサーバーを簡単に識別できるように、検出インジケータ・ライトをオンにします。サーバーの番号が確認されたら、前面パネルの検出ボタンを押すことができます。
インジケータ・ライトをリモートでオンにし、次の方法を使用します。
Exadata Storage ServerのCellCliにログイン:
CellCli> ALTER CELL LED ON
サーバーのILOMにログイン:
-> set /SYS/LOCATE value=Fast_Blink
サーバーのrootアカウントにログイン:
# ipmitool chassis identify force Chassis identify interval: indefinite
-
HBAでバッテリと現在のステータスを表示できることを確認します。
ノート:
Solarisで実行している場合は、次のコマンドの
/opt/MegaRAID/MegaCli/MegaCli64
の代わりに/opt/MegaRAID/MegaCli
を使用します。# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
デフォルトの出力には、バッテリがまだ表示されていることが表示されますが、障害に応じて低電圧またはその他の問題が表示される場合もあります。BBUに重大な障害が発生し、HBAにアクセスできなくなった場合、BBUの読取りエラーが返されることがあります。
-
すべての論理ボリュームで現在のキャッシュ・ポリシーを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
デフォルトのキャッシュ・ポリシーは、すべてのボリュームで
WriteBack
です。バッテリが正常に機能している場合、現在のキャッシュ・ポリシーはWriteBack
としてレポートされます。ただし、障害が発生した場合、現在のキャッシュ・ポリシーはWriteThrough
としてレポートされることがあります。 -
すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モード(バッテリを使用しない)に設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
-
すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルーになっていることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
- 交換対象のディスク・コントローラBBUを削除します。次のコマンドを
リモート・マウントBBUがないシステムの場合
システムにリモート・マウントBBUがない場合は、この項のステップを実行します。システムにリモート・マウントBBUがある場合は、「リモート・マウントBBUがあるシステムの場合」を参照してください。
リモート・マウントされたバッテリがシステムに取り付けられていない場合は、バッテリの交換が必要なノードをシャットダウンする必要があります。
ノート:
Oracle Exadata System Software 19.0以上を実行している場合は、次のコマンドで/opt/MegaRAID/MegaCli/MegaCli64
を/opt/MegaRAID/storcli/storcli64
に置き換えます。
- すべてのRAIDディスク・ボリュームをライトスルー・モードに戻し、RAIDキャッシュ・メモリーのすべてのデータがディスクにフラッシュされ、バッテリの交換時にデータの損失が発生しないことを確認します。
- すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モードに設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
- すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルー(バッテリーを使用しない)になっていることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
- すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モードに設定します。
- サーバー・オペレーティング・システムをシャットダウンします。
Exadata Storage Serverの電源を切断する際は、次の点に注意してください。
- ディスク障害が発生したストレージ・サーバーが他にないことを確認します。別のディスクで障害が発生中にストレージ・サーバーをシャットダウンすると、データベース・プロセスおよびOracle ASMがクラッシュする場合がありますが、その可能性があるのは、サーバーのディスクがオフラインになったときに、パートナー・ペアの両方のディスクが失われる場合です。
- ラックの残りにディスクの障害が発生していない1つのExadata Storage Serverの電源を切断しても、実行中のデータベース・プロセスまたはOracle ASMには影響しません。
- 複数のExadata Storage Serverを停止する前に、すべてのデータベースおよびOracle Clusterwareプロセスを停止する必要があります。これが必要な場合の詳細は、Exadataオーナーズ・ガイドを参照してください。
オフラインに切り替えられるとすぐに、ディスクはASMによって削除されます。リストア対象のASMディスクの修復タイマーよりも長い時間ストレージ・サーバーがオフラインの場合、Exadata Storage Serversの電源を切断するか再起動すると、データベースのパフォーマンスが影響を受けることがあります。デフォルトの
DISK_REPAIR_TIME
属性値は3.6時間で、コンポーネントの交換には適切ですが、長い時間が必要な場合は、変更が必要になることがあります。- ASMにログインして次の問合せを実行し、ディスクの修復時間を確認します。
SQL> SELECT dg.name,a.value FROM v$asm_attribute a, v$asm_diskgroup dg WHERE a.name = 'disk_repair_time' AND a.group_number = dg.group_number;
交換対象のコンポーネントの交換に十分な値の場合は、変更する必要はありません。
変更する必要がある場合は、次の文を使用できます。
SQL> ALTER DISKGROUP DATA SET ATTRIBUTE 'disk_repair_time'='8.5H';
- ASMが問題なく、グリッド・ディスクがオフラインになるかどうかを確認します。次のコマンドは、リストされているグリッド・ディスクで
Yes
を返します。# cellcli -e LIST GRIDDISK ATTRIBUTES name,asmmodestatus,asmdeactivationoutcome ...sample ... DATA_CD_09_cel01 ONLINE Yes DATA_CD_10_cel01 ONLINE Yes DATA_CD_11_cel01 ONLINE Yes RECO_CD_00_cel01 ONLINE Yes RECO_CD_01_cel01 ONLINE Yes ...repeated for all griddisks....
1つ以上のディスクで
asmdeactivationoutcome='Yes'
が返されない場合は、各ディスク・グループを確認し、そのディスク・グループのデータ冗長性をリストアします。ディスク・グループのデータ冗長性が完全にリストアされたら、コマンドを再実行して、すべてのグリッド・ディスクでasmdeactivationoutcome='Yes'
になっていることを確認します。すべてのディスクでasmdeactivationoutcome='Yes'
が返されたら、次のステップに進みます。ノート:
1つ以上のグリッド・ディスクが
asmdeactivationoutcome='Yes'
を返さない場合に、セル・サービスを停止すると、影響を受けるディスク・グループがOracle ASMによってディスマウントされ、データベースが突然停止します。 -
保守用に電源を切断する必要があるセルのすべてのグリッド・ディスクを非アクティブ化します。これは、最大で10分以上になる場合があります。
# cellcli ...sample ... CellCLI> ALTER GRIDDISK ALL INACTIVE GridDisk DATA_CD_00_dmorlx8cel01 successfully altered GridDisk DATA_CD_01_dmorlx8cel01 successfully altered GridDisk DATA_CD_02_dmorlx8cel01 successfully altered GridDisk RECO_CD_00_dmorlx8cel01 successfully altered GridDisk RECO_CD_01_dmorlx8cel01 successfully altered GridDisk RECO_CD_02_dmorlx8cel01 successfully altered ...repeated for all griddisks...
-
グリッド・ディスクがオフラインになったことを確認します。ディスクがオフラインになり、ASMで非アクティブなると、出力には、
asmmodestatus='UNUSED'
または'OFFLINE'
、およびasmdeactivationoutcome=Yes
がすべてのグリッド・ディスクで表示されます。CellCLI> LIST GRIDDISK ATTRIBUTES name,status,asmmodestatus,asmdeactivationoutcome DATA_CD_00_dmorlx8cel01 inactive OFFLINE Yes DATA_CD_01_dmorlx8cel01 inactive OFFLINE Yes DATA_CD_02_dmorlx8cel01 inactive OFFLINE Yes RECO_CD_00_dmorlx8cel01 inactive OFFLINE Yes RECO_CD_01_dmorlx8cel01 inactive OFFLINE Yes RECO_CD_02_dmorlx8cel01 inactive OFFLINE Yes ...repeated for all griddisks...
- すべてのディスクがオフラインになり、非アクティブになると、セルをシャットダウンできます。
Exadata Storage Serverの電源を切断すると、すべてのストレージ・サービスが自動的に停止します。# shutdown -hP now
1.9.2.3 ステップ3: 新しいディスク・コントローラBBUの有効化
「ステップ1: ディスク・コントローラBBUの取り外しの準備」と同様、この項には2つのサブ項目があります。
リモート・マウントBBUがあるシステムの場合
システムにリモート・マウントBBUがある場合は、この項のステップを実行します。このシナリオでは、「ステップ1: ディスク・コントローラBBUの取り外しの準備」の終了時にシステムはシャットダウンされていません。
イメージ・バージョン11.2.3.3.0以上を実行している場合:
-
celladminまたはrootユーザーとしてログインします。
-
BBUを再有効化します。
# cellcli -e alter cell bbu reenable HDD disk controller battery has been reenabled
-
ディスク・コントローラBBUのバッテリ状態がOperationalであることを確認します。
# cellcli -e list cell attributes bbustatus normal
"BBUステータス"が"normal"以外の場合は、続行する前に問題を調査して修正してください。
イメージ・バージョン11.2.3.2.xを実行している場合:
-
ルート・ユーザーとしてログインします。
-
サーバーの検出LEDをオフにします。
# ipmitool chassis identify off Chassis identify interval: off
-
HBAが認識され、新しいBBUと通信を開始するまで、約5分間待機します。
-
HBAバッテリ・ステータスがOperationalで、充電中であることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
-
すべての論理ドライブのキャッシュ・ポリシーをライトバック・キャッシュ・モードに設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0
-
すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep -i bbu Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU ... <repeated for each logical volume present>
リモート・マウントBBUがないシステムの場合
「ステップ1: ディスク・コントローラBBUの取り外しの準備」の終了時に、リモート・マウントBBUがないシステムはシャットダウンされています。システムを再起動する必要があります。
-
電源ボタンを押して、サーバーの電源を入れます。
-
ILOMが起動したら、電源ボタンを押してサーバーの電源を入れ、サーバーのコンソールに接続します。
ILOM Webブラウザからコンソールに接続する手順(推奨): リモート制御→リダイレクト・タブにアクセスし、リモート・コンソールの起動ボタンをクリックします。ILOM 3.1.xシステムでは、コンソール・ボタンは最初の「サマリー情報」画面から起動できます。
ILOM CLIからコンソールに接続するには:
> start /SP/console
-
サーバーのコンソールから、システム・ブートを監視します。特に、ロード中のLSIコントローラのBIOSを監視してください。保存されているキャッシュがあるドライブに関する警告メッセージが表示される場合、"D"を選択すると、キャッシュを破棄して続行されます。ASMによる起動後に、ディスクが再同期されるため、これは問題ではありません。バッテリ低下によりライトスルー・モードになっているドライブに関する警告メッセージが表示される場合は、選択して続行します。
その後、Exadataの起動が正常に続行されると、Exadataのブート・スプラッシュ画面が表示され、通常のOSブート・メッセージが引き続き表示されます。後続の起動ステップ中に、ILOMシリアル・コンソールの画面出力の間の停止時間が長くなる場合がありますが、これは、デフォルトのコンソールがグラフィックで、Exadataブート・スプラッシュ画面が表示されないためです。
-
起動がすべて完了したら、rootユーザーとしてログインし、新しいバッテリが表示されて充電中であることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
-
すべての論理ドライブのキャッシュ・ポリシーを、バッテリを使用するライトバック・キャッシュ・モードに設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0
-
すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
-
セルをサービスに戻します。
-
グリッド・ディスクをアクティブ化します。
# cellcli CellCLI> alter griddisk all active GridDisk DATA_CD_00_dmorlx8cel01 successfully altered GridDisk DATA_CD_01_dmorlx8cel01 successfully altered GridDisk DATA_CD_02_dmorlx8cel01 successfully altered GridDisk RECO_CD_00_dmorlx8cel01 successfully altered GridDisk RECO_CD_01_dmorlx8cel01 successfully altered GridDisk RECO_CD_02_dmorlx8cel01 successfully altered ...etc...
-
すべてのディスクがアクティブになっていることを確認します。
CellCLI> list griddisk DATA_CD_00_dmorlx8cel01 active DATA_CD_01_dmorlx8cel01 active DATA_CD_02_dmorlx8cel01 active RECO_CD_00_dmorlx8cel01 active RECO_CD_01_dmorlx8cel01 active RECO_CD_02_dmorlx8cel01 active ...etc...
-
すべてのグリッド・ディスクが正常にオンラインになったことを確認します。すべてのグリッド・ディスクで"asmmodestatus"のステータスが"ONLINE"になるまで待機します。アクティブ化プロセスの最初の出力の例を次に示します。
CellCLI> list griddisk attributes name,status,asmmodestatus,asmdeactivationoutcome DATA_CD_00_dmorlx8cel01 active ONLINE Yes DATA_CD_01_dmorlx8cel01 active ONLINE Yes DATA_CD_02_dmorlx8cel01 active ONLINE Yes RECO_CD_00_dmorlx8cel01 active SYNCING Yes RECO_CD_01_dmorlx8cel01 active ONLINE Yes ...etc...
'RECO_CD_00_dmorlx8cel01'の上の例は、まだ'SYNCING'プロセスの実行中です。すべてのグリッド・ディスクが'asmmodestatus=ONLINE'を示したときに、Oracle ASMの同期化が完了します。このプロセスは、個別のサーバーが修復のために停止している間マシンがビジー、またはビジーであった状態に応じて時間がかかる場合があります。
-
1.10 dbmsrvサービスの概要
Oracle Exadata System Softwareリリース12.1.2.1.0以降:
- データベース・ノードで管理サーバー(MS)が実行されるようになりました。以前のMSは、ストレージ・ノードでのみ実行されていました。
- データベース・マシン・サービス(
dbmsrv
)という名前の新しいサービスが、データベース・ノードで実行されるようになりました。この新しいサービスがベースとするMSは、ストレージ・サーバー上で実行され、データベース・ノードに拡張管理機能を提供します。 - Oracle Exadata System Softwareリリース12.1.2.1.2以降では、データベース・ノードの管理サーバー(MS)で
sudo
が使用されなくなります。つまり、sudoersの構成は必要なくなりました。
Oracle Exadata System Softwareリリース12.1.2.1.2より前:
-
セキュリティ上の理由から、データベース・ノードの管理サーバーは
root
として実行されません。ただし、ディスク・ステータス、ILOM、電源ユニットなど、システムを監視する特定のユーティリティを実行し、Oracle Auto Service Request (ASR)メッセージおよびアラートを送信するには、root
権限が必要になります。これを達成するために、sudoers構成ファイルのdbmsvc_sudo_conf
が追加され、データベース・ノードの管理サーバー・ユーザーがroot
権限でユーティリティを実行できるようになっています。dbmsrv
サービスまたはdbserverd
を無効にしたり、sudoers構成ファイルを編集したりしないでください。ファイルのエントリが削除されると、dbmsrv
サービスでシステムの一部の部分を監視できなくなる場合があります。たとえば、ディスクに障害が発生すると、Oracle ASRメッセージを時間内に送信できなくなり、データベース・ノードで破損が発生し、リカバリが遅延する場合があります。
Oracle Exadata System Softwareリリース12.1.2.1.0以降のデータベース・ノード・サービスで新しい管理サーバーを管理するために、新しいユーザーおよびグループが追加されました。
ユーザーおよびそのIDは次のとおりです。
dbmsvc: 12137
dbmadmin: 12138
dbmmonitor: 12139
新しいグループおよびそのIDは次のとおりです。
dbmsvc: 11137
dbmadmin: 11138
dbmmonitor: 11139
dbmusers: 11140
次の各トピックでは、このサービスのユーザーIDを変更する方法について説明します。
- スクリプトを使用したdbmsrvのユーザーIDおよびグループIDの変更
Oracle Exadata System Softwareリリース18.1.12および19.1.2以降では、migrate_ids.sh
スクリプトを使用して、dbmsrvユーザーのユーザーIDおよびグループIDを変更できます。 - dbmsrvのユーザーIDおよびグループIDの手動での変更
migrate_ids.sh
スクリプトが導入されたOracle Exadata System Softwareリリース18.1.12および19.1.2より前のリリースでは、dbmsrvユーザーのユーザーIDおよびグループIDを手動で変更する必要があります。
親トピック: 一般的な保守情報
1.10.1 スクリプトを使用したdbmsrvのユーザーIDおよびグループIDの変更
Oracle Exadata System Softwareリリース18.1.12および19.1.2以降では、migrate_ids.sh
スクリプトを使用して、dbmsrvユーザーのユーザーIDおよびグループIDを変更できます。
デフォルト値と競合が発生している場合(たとえば、LDAPを使用している場合、または、デフォルト値と異なる値を必要とするセッション管理ツールを使用している場合)、dbmsrvサービス・ユーザーのユーザーIDとグループIDを変更できます。
これらのステップは、dbmsrvサービスのユーザーとグループのみに固有です。これらを使用して、他のOracle製品のユーザーとグループを変更しないでください。
このスクリプトは、すべてのディレクトリを検索し、移行されるuidまたはgidを使用するファイルを見つけて、新しいuidまたはgidを使用するように所有者またはグループのアクセス権を更新します。-skipdirs
オプションを使用すると、検索する必要がないディレクトリを指定できます。指定したディレクトリおよびその配下のファイルは、uid値およびgid値の変更中にスキップされます。
-skipdirs
オプションは、移行を高速化するためにスキップさせたい大きいNFSディレクトリがある場合に便利です。ただし、スキップされるディレクトリに移行しているuidまたはgidを使用するファイルがある場合、それらのファイルは更新されません。IDの移行を確実に成功させるためには、このオプションでスキップされるディレクトリにこのようなファイルが含まれていないことを確認する必要があります。
例1-4 新しいユーザーIDへのdbmadminユーザーの移行
この例では、ユーザーdbmadminのuidのみを3001に移行する方法を示します。
migrate_ids.sh -uid dbmadmin 3001
例1-5 新しいグループIDへのdbmusersグループの移行
この例では、グループdbmusersのgidのみを4001に移行する方法を示します。
migrate_ids.sh -gid dbmusers 4001
例1-6 すべてのdbmsrvユーザーおよびグループを新しい値に移行する
この例では、dbmsrvのすべてのユーザーIDとグループIDを新しい値に移行する方法を示します。
migrate_ids.sh -uid dbmsvc 3001 -gid dbmsvc 4001
migrate_ids.sh -uid dbmadmin 3002 -gid dbmadmin 4002
migrate_ids.sh -uid dbmmonitor 3003 -gid dbmmonitor 4003
migrate_ids.sh -gid dbmusers 4004
例1-7 ディレクトリをスキップしてユーザーIDを移行する
この例では、/proc
または/sys
ディレクトリ内のファイルを検索せずに、ユーザーdbmadminのユーザーIDを3001に移行する方法を示します。
migrate_ids.sh -uid dbmadmin 3001 -skipdirs /proc,/sys
関連トピック
Parent topic: dbmsrvサービスの概要
1.10.2 dbmsrvのユーザーIDおよびグループIDの手動での変更
migrate_ids.sh
スクリプトが導入されたOracle Exadata System Softwareリリース18.1.12および19.1.2より前のリリースでは、dbmsrvユーザーのユーザーIDおよびグループIDを手動で変更する必要があります。
デフォルト値と競合が発生している場合(たとえば、LDAPを使用している場合、または、デフォルト値と異なる値を必要とするセッション管理ツールを使用している場合)、dbmsrvサービス・ユーザーのユーザーIDとグループIDを変更できます。
可能な場合は、最新バージョンのOracle Exadata System Softwareにアップグレードし、手動の手順を使用するかわりにmigrate_ids.sh
スクリプトを使用してください。
これらのステップは、dbmsrvサービスのユーザーとグループのみに固有です。これらを使用して、他のOracle製品のユーザーとグループを変更しないでください。
関連トピック
Parent topic: dbmsrvサービスの概要
1.11 サーバーにリモートにアクセスするユーザーのパスワードの有効期限の構成
DBSERVER
属性を構成して、ユーザー・パスワードを期限切れにできます。
Oracle Exadata System Softwareリリース19.1.0では、REST APIまたはExaCLIなど、Oracle Exadata System Softwareサーバーにリモートでアクセスするユーザーに対してパスワード・セキュリティを構成するための新しいDBSERVER
属性があります。これらの属性によって、ユーザーがリモートで、パスワード、ユーザー・パスワードが期限切れになるまでの時間、およびユーザーが警告メッセージを受け取るパスワード有効期限の前の日数を変更できるかどうかが決まります。デフォルトの構成では、ユーザー・パスワードは期限切れになりません。
ノート:
パスワードの有効期限のDBSERVER属性は、Oracle Exadata System Softwareで作成されたユーザーにのみ適用されます。パスワードの有効期限は、LIST USERコマンド
で表示されるユーザーにのみ適用され、dbmadmin
やoracle
などのオペレーティング・システム・ユーザーには適用されません。
親トピック: 一般的な保守情報
1.12 構成変更時のストレージ・サーバーとデータベース・サーバーの状態
構成の変更前に、データベース・サーバーとストレージ・サーバーをオフラインまたはオンラインにする必要があるかどうかを判断します。
表1-3 操作に対応するストレージ・サーバーとデータベース・サーバーの状態
操作 | ストレージ・サーバー | データベース・サーバー |
---|---|---|
DNSサーバーの更新 |
オンライン |
オンライン |
NTPサーバーの更新 |
オンライン |
オンライン |
タイム・ゾーンの更新 |
オフライン |
オンライン |
管理ネットワークのIPアドレス、ネットマスク、ゲートウェイ、ホスト名の変更 |
オフライン |
オンライン |
クライアント・ネットワークのIPアドレス、ネットマスク、ゲートウェイ、ホスト名の変更 |
オフライン |
オンライン |
Integrated Lights Out Manager (ILOM) IPアドレスの変更 |
オフライン |
|
その他のILOMパラメータの変更 |
|
|
RDMAネットワーク・ファブリックのIPアドレス、ネットマスクまてゃホスト名の変更 |
オフライン |
オンライン |
パーティション・キー(pkey)の変更 |
オフライン |
オンライン |
親トピック: 一般的な保守情報
1.13 レスキュー計画
12.2.1.1.0より前のExadataリリースでは、ストレージ・サーバーまたはデータベース・サーバーのレスキュー後に、複数のコマンドを再実行して、IORMプラン、しきい値、ストレージ・サーバーおよびデータベース・サーバーの通知設定などの項目を構成する必要があります。
Oracle Exadataリリース12.2.1.1.0では、cell
とdbserver
の各オブジェクトにrescuePlan
という新しい属性があります。データベース・サーバーとストレージ・サーバーの構成が完了したとき、rescuePlan
属性の値をファイルに保存する必要があります。レスキューされたサーバーのデータはレスキュー時に消去されるため、ファイルをリモート・サーバーに保存する必要があります。サーバーのレスキュー後に、リモート・サーバーからファイルを取得し、ファイルを実行して設定をリストアできます。次の例3を参照してください。
セキュリティ上の理由から、レスキュー計画には、パスワードを必要とする構成は含めません。
例1-8 ストレージ・セルのレスキュー計画
ストレージ・サーバーのrescuePlan
属性は、次のようになります。
$ cellcli -e list cell attributes rescuePlan
CREATE ROLE "admin"
GRANT PRIVILEGE all actions ON diagpack all attributes WITH all options TO ROLE "admin"
CREATE ROLE "diagRole"
GRANT PRIVILEGE download ON diagpack all attributes WITH all options TO ROLE "diagRole"
GRANT PRIVILEGE create ON diagpack all attributes WITH all options TO ROLE "diagRole"
GRANT PRIVILEGE list ON diagpack all attributes WITH all options TO ROLE "diagRole"
ALTER CELL accessLevelPerm="remoteLoginEnabled", diagHistoryDays="7", metricHistoryDays="7", notificationMethod="mail,snmp",
notificationPolicy="warning,critical,clear", snmpSubscriber=((host="localhost", port=162, community="public", type=asr)),
bbuLearnCycleTime="2016-10-17T02:00:00-07:00", bbuLearnSchedule="MONTH 1 DATE 17 HOUR 2 MINUTE 0",
alertSummaryStartTime="2016-09-21T17:00:00-07:00", alertSummaryInterval=weekly,
hardDiskScrubInterval=biweekly, hardDiskScrubFollowupIntervalInDays="14"
ALTER IORMPLAN objective=basic
例1-9 データベース・サーバーのレスキュー計画
データベース・サーバーのrescuePlan
属性は、次のようになります。
$ dbmcli -e list dbserver attributes rescuePlan
CREATE ROLE "listdbserverattrs"
GRANT PRIVILEGE list ON dbserver ATTRIBUTES bbuStatus, coreCount WITH all options TO ROLE "listdbserverattrs"
ALTER DBSERVER diagHistoryDays="7", metricHistoryDays="7", bbuLearnSchedule="MONTH 1 DATE 17 HOUR 2 MINUTE 0",
alertSummaryStartTime="2016-09-26T08:00:00-07:00", alertSummaryInterval=weekly, pendingCoreCount="128" force
例1-10 セルのレスキュー計画スクリプトの作成
次のコマンドで、rescuePlan
属性のコマンドが、リモート・サーバー上のrescue.cli
というファイルに格納されます。
$ cellcli -e list cell attributes rescuePlan >& /location/on/remote/server/rescue_cell.cli
サーバーをレスキューする必要がある場合は、サーバーのレスキュー後にスクリプトを実行して設定をリストアできます。次のコマンドでは、CellCLIのstart
コマンドを使用してrescue_cell.cli
ファイルを実行します。
$ cellcli -e start /location/on/remote/server/rescue_cell.cli
例1-11 データベース・サーバーのレスキュー計画スクリプトの作成
次のコマンドで、rescuePlan
属性のコマンドが、リモート・サーバー上のrescue_db.cli
というファイルに格納されます。
$ dbmcli -e list dbserver attributes rescuePlan >& /location/on/remote/server/rescue_db.cli
サーバーをレスキューする必要がある場合は、サーバーのレスキュー後にスクリプトを実行して設定をリストアできます。次のコマンドでは、CellCLIのstart
コマンドを使用してrescue_cell.cli
ファイルを実行します。
$ dbmcli -e start /location/on/remote/server/rescue_db.cli
親トピック: 一般的な保守情報
1.14 ExaWatcherチャートを使用したOracle Exadataのパフォーマンスの監視
ExaWatcherは、Exadataシステムのストレージ・サーバーおよびデータベース・サーバーのパフォーマンス・データを収集するユーティリティです。収集されるデータには、iostat、セル統計(cellsrvstat)、ネットワーク統計などのオペレーティング・システム統計情報が含まれます。
- ExaWatcherチャートについて
ExaWatcherは、Oracle Exadataのストレージ・サーバーとデータベース・サーバーについて指定期間のパフォーマンス・データを収集して提示します。 - ExaWatcherチャートを使用するための要件
HTMLページを表示するには、インターネットにアクセスできるローカル・ブラウザを持つマシンに、生成されたアーカイブ・ファイルを移動する必要があります。 - IOチャート
IOチャートには、サーバー全体またはストレージ・サーバーの個別のディスクのIOパフォーマンスが示されます。 - CPUチャート
CPUチャートには、サーバーのCPU使用率が示されます。これらの統計は、iostat
(avg-cpu: %user、%system、%iowait)に基づきます。 - CPU詳細
CPU詳細チャートには、CPU IDごとのCPUの平均使用率などの、CPU使用状況の詳細情報が示されます。これらの統計は、mpstat
に基づきます。 - セル・サーバー・チャート
セル・サーバー統計は、Exadata Storage Serverに固有の機能を追跡する場合に役立ちます。このページには、スマート・フラッシュ・キャッシュおよびスマートIOに関連する統計が示されます。 - アラート履歴
親トピック: 一般的な保守情報
1.14.1 ExaWatcherチャートについて
ExaWatcherは、Oracle Exadataのストレージ・サーバーとデータベース・サーバーについて指定期間のパフォーマンス・データを収集して提示します。
ExaWatcherで収集されたデータを抽出するには、GetExaWatcherResults.sh
を実行して、対象の時間範囲の開始時間と終了時間を指定します。結果は、指定したディレクトリの場所に書き込むことができる圧縮アーカイブ・ファイルに含まれます。
たとえば:
$ GetExaWatcherResults.sh --from 08/24/2023_17:00:00 --to 08/25/2023_17:00:00 --resultdir /var/log/oracle/ExaWatcherResults
ノート:
GetExaWatcherResults.sh
で-c
または--scp
のオプションを使用して、結果のアーカイブ・ファイルを別の場所にコピーすることもできます。
GetExaWatcherResults.sh
で、IO、CPU使用率、セル・サーバー統計およびアラート履歴のチャートを含むHTMLページも生成されます。IOとCPU使用率のチャートではiostat
からのデータが使用され、CPUの詳細ではmpstat
からのデータが使用され、セル・サーバー統計ではcellsrvstat
からのデータが使用されます。アラート履歴は、指定した時間枠を対象として取得されます。
結果のアーカイブ・ファイルには、新しいチャートがあります。アーカイブ・ファイルには、Charts.ExaWatcher.<hostname>/<timestamp>_<duration>/
(たとえば、Charts.ExaWatcher.xxxxceladm13.oracle.com/2016_08_24_17_00_00_01h00m00s_0
)という名前のサブディレクトリがあります。
HTMLページを表示するには、インターネットにアクセスできるローカル・ブラウザを持つマシンでアーカイブ・ファイルを抽出する必要があります。その後、ブラウザでCharts.ExaWatcher.<hostname>/<timestamp>_<duration>/index.html
を開きます。そのページの左パネルには、次のメニューが表示されます。
ノート:
スクリーン・リーダーのユーザーは、メニュー項目は上下の矢印キーを使用してナビゲートし、スペース・バーを使用してアクティブ化します。[Tab]キーを使用すると、右側のフレームに移動します。「CellSrvStat」メニュー項目は、ストレージ・サーバーに対して実行した場合にのみ使用できます。「アラート履歴」メニュー項目は、要求した時間枠にアラートが発生した場合にのみ使用できます。
1.14.2 ExaWatcherチャートを使用するための要件
HTMLページを表示するには、インターネットにアクセスできるローカル・ブラウザを持つマシンに、生成されたアーカイブ・ファイルを移動する必要があります。
ExaWatcherチャートは複雑であるため、Oracle Exadataラックが制限付き環境に存在し、かつ、生成されたHTMLファイルまたはアーカイブ・ファイルを、インターネットにアクセスできる環境に移動できない場合は、ExaWatcherチャートを表示できません。
1.14.3 IOチャート
IOチャートには、サーバー全体またはストレージ・サーバーの個別のディスクのIOパフォーマンスが示されます。
IO統計に使用可能なページは次のとおりです。
1.14.3.1 IO統計サマリー
IOStatサマリーには、サーバー全体のIOパフォーマンスのサマリーが示されます。このページには次の4つのチャートが表示されます。
表1-4 IOStatサマリーの統計
統計 | 説明 |
---|---|
フラッシュIOP ハード・ディスクIOP |
サーバーの1秒当たりの読取りの合計数、1秒当たりの書込みの合計数および1秒当たりのIOの合計数(1秒当たりの読取り数 + 1秒当たりの書込み数)。 ここでは、 |
フラッシュMB/s ハード・ディスクMB/s |
1秒当たりの読取りの合計量(MB)、1秒当たりの書込みの合計量(MB)および1秒当たりのIOの合計量(MB)。 ここでは、 |
統計は、適用可能な場合にフラッシュおよびハード・ディスクに対して表示されます。Exadata Extreme Flashには、ハード・ディスクはありません。データベース・サーバーには、フラッシュ・デバイスはありません。
I/Oのパフォーマンスの問題が疑われる場合は、ストレージ・サーバーのIOPとMB/sの統計をデータ・シートと比較して、ストレージが最大容量に達したかどうかを特定できます。データベースの確認された読取り回数が多い場合は、それをiostatからのサービス時間および平均待機時間と比較して、ストレージ・サーバーが原因で読取り回数が多い可能性があるかどうかを特定することもできます。通常、このデータベースでの回数には、フラッシュ・キャッシュおよびハード・ディスクで対応されたIOが含まれます。また、これらのチャートでは、時間枠内のピークをビジュアル化できます。
次の部分的なスクリーンショットに、フラッシュおよびハード・ディスクのIOPとMB/sのチャートを示します。
各チャートの下に、チャート内の特定の時間のドリルダウンに使用できる範囲セレクタがあります。いずれかのチャートの範囲セレクタを移動すると、ページ上のすべてのチャートに影響します。
ノート:
範囲セレクタは、スクリーン・リーダーにアクセスできません。また、チャートに表示されるすべての値がスクリーン・リーダーにアクセスできるわけではありません。それぞれのチャートのデータ・ポイントの最初の値のみが該当します。範囲セレクタを使用すると、表示されるチャートが変更されて、範囲セレクタで指定した時間枠のデータのみが表示されます。
親トピック: IOチャート
1.14.3.2 I/O統計詳細
IOStat詳細には、ストレージ・サーバーの各ディスクのパフォーマンスが示されます。このページには、次のチャートが表示されます。
表1-5 IO統計詳細の統計
統計 | 説明 |
---|---|
フラッシュ・サービス時間 ハード・ディスク・サービス時間 |
待機時間の範囲に対する、ディスクごとの平均サービス時間。 |
フラッシュ待機時間 ハード・ディスク待機時間 |
ディスクごとの平均待機時間 |
デフォルトでは、チャートには、サーバー上のすべてのディスクの平均を示す線が含まれます。影付きのバックグラウンド・イメージは、統計の最小と最大の範囲を示しています。ドロップダウン・セレクタを使用して、個別のディスクを表示することを選択できます。
バックグラウンド・イメージの範囲が広い場合は、ディスク・パフォーマンスに差異がある可能性があることを示します。このメトリックを使用して、ストレージ・サーバーの個々のディスクをより詳細に確認することで、不均衡が発生しているかどうかを知ることができます。バックグラウンド・イメージの範囲が狭い場合は、ディスクのパフォーマンスが似ていることを示します。
また、ストレージ・サーバーの個別のディスクのIOPとMB/sをデータ・シートの数値と比較して、ディスクが最大容量に達した可能性があるかどうかを確認することもできます。
親トピック: IOチャート
1.14.6 セル・サーバー・チャート
セル・サーバー統計は、Exadata Storage Serverに固有の機能を追跡する場合に役立ちます。このページには、スマート・フラッシュ・キャッシュおよびスマートIOに関連する統計が示されます。