1 一般的な保守情報
この章では、Oracle Exadata Database Machineの一般的な保守について説明します。
注意:
-
読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。
-
この章のすべての手順は、Oracle Exadata Database MachineおよびOracle Exadata Storage拡張ラックに適用されます。
関連トピック
1.1 役割および職責の概要
発生した問題の解決責任がある個人またはグループを判別する必要があります。
ほとんどのIT組織には、データベース管理者、システム管理者、ネットワーク管理者およびストレージ管理者のチームがあります。これらの管理者はシステム実装および操作の続行を担当します。Oracle Exadata Database Machine環境では、通常、データベース管理者がシステム管理者のサポートを受けながらOracle Exadata Database Machine管理の主要な役割を担当するようにすると、より効率的かつ効率的になります。これは、Oracle Exadata Database MachineがOracle Databaseを実行するように設計され、管理がOracle DatabaseおよびOracle Exadata System Softwareに固有であるためです。その他のチームに異なる職責を与えるか、または第2レベルとしてサポートするようにできます。
通常、初期システム・デプロイメントはOracleエンジニアが実行します。データベース管理者の主要職責は通常の操作タスクで開始されます。次の表は、Oracle Exadata Database Machine環境の管理に必要になる一般的なタスクの一部を示しています。
表1-1 Oracle Exadata Database Machine管理の共通管理タスク
| タスクまたはイベント | 管理者 | アクション |
|---|---|---|
|
パフォーマンスの低下 |
データベース管理者 システム管理者 |
Oracle Enterprise Manager Cloud Controlからパフォーマンスのしきい値を超えたというアラートを受け取ります。 すべてのサーバーのシステム・パフォーマンス、CPU、メモリーおよびI/Oで異常な傾向を確認します。 データベース・パフォーマンス、待機イベント、ロック、並列処理および実行計画を確認します。 |
|
パッチ適用またはアップグレード |
データベース管理者 システム管理者 |
Oracle Exadata System Softwareのパッチまたはアップグレード、およびSun Datacenter InfiniBand Switch 36スイッチのファームウェアのアップグレードを適用します。 Oracle Databaseのパッチ、Oracle Grid Infrastructureのパッチまたはアップグレードを適用します。 |
|
システム停止または障害 |
データベース管理者 システム管理者 |
Integrated Lights Out Manager (ILOM)に接続し、現在のシステム状態を確認し、ハードウェアの問題点の識別またはシステムの再起動を行い、およびログを確認して根本的な原因を分析します。 残存インスタンスでエラーのチェック、残存インスタンスのパフォーマンスの監視およびアプリケーション機能が損われていないことの確認を行います。 |
|
疑いのあるネットワークの問題点 |
データベース管理者 システム管理者 |
ネットワーク・インタフェースでエラーまたは削除されたパケットを検出し、再起動したスイッチがあるかどうかをチェックし、必要に応じてネットワーク管理チームにエスカレートします。 データベース側のパフォーマンスを検査して影響を評価します(影響がある場合)。 |
|
データベースのバックアップ |
データベース管理者 システム管理者 |
データベースのバックアップ・ルーチンを実行し、データベース・サーバーのバックアップが完了していることを確認します。 |
|
障害ディスクの交換 |
データベース管理者 システム管理者 |
ハードウェア交換に関するアラートを受け取り、Oracle Auto Service Request (ASR)がサービス・リクエストを開いたことを確認し、オペレータがデータ・センターのフィールド・サービス技術者にドライブの交換またはスペアのドライブの提供を許可していることを確認します。 |
通常、発生した問題の主担当は個人またはグループです。システムに問題が発生すると、この担当者または担当するグループがOracle Enterprise Manager Cloud Control、ヘルプ・デスクまたは操作チームから最初に連絡を受けます。Oracle Exadata Database Machineの場合、通常、主に連絡を担当するのはデータベース管理者です。データベース管理者が問題解決に別のチームのサポートを必要とする場合は、協力して問題を解決します。問題の担当者を明確にしておく必要があります。
1.1.1 Oracle Exadata Database Machineでの管理面の差異の理解
Oracle Exadata Database Machineのサーバー上でのほとんどの管理タスクは、従来のデータベース・サーバーおよびストレージ・サーバーと似ています。ただし、違いがいくつかあります。
次のリストは、Oracle Exadata Database Machineサーバーの相違点と例外を示しています。
-
Oracle Exadata Database Machineのデータベース・サーバー、Sun Datacenter InfiniBand Switch 36およびその他のコンポーネントの構成は、テストおよびパフォーマンス基準に基づいて設定されています。会社の方針またはその他の理由により、データベース・サーバーのファームウェアまたはカーネル・パラメータなどの構成設定を変更する場合は、Oracle Exadata Database Machineに対する影響の可能性を確認する必要があります。
-
サーバーを不正に再起動すると、データベースが壊れる可能性があります。ストレージ・サーバーには、サーバーを再起動する前にグリッド・ディスクをオフラインにする、一度に複数のサーバーを再起動できないなど、データベースの破壊を最小化するために従う必要がある特別な手順とガイドラインがあります。
-
Oracle Exadata Storage Serverはデータベース・サーバーと同じ方法では変更できません。NTPサーバーまたはDNSサーバーなどのネットワークの変更は、
ipconfユーティリティを使用して行います。ネットワークの変更は構成ファイルを編集して手動で行うことはできません。さらに、ストレージ・サーバーにソフトウェアまたは追加パッケージをインストールすることはできません。この制約にはソフトウェアの監視が含まれます。Oracle Exadata Storage Serverシステムのアップデートは、Oracle Exadata System Softwareのアップグレードで行われます。 -
Oracle Exadata Storage Serverのバックアップは不要です。セルのリカバリには、自己保守される内部USBドライブまたはM.2デバイスが使用できます。ストレージ・サーバーには、バックアップ・クライアントをインストールできません。
-
Oracle Exadata Storage Serverを使用する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 Exadata Storage Serverに肩がわりさせて負荷を軽減できることを示すことができます。 -
バックアップやリカバリなどの操作ではOracle Recovery Manager (RMAN)が使用されます。バックアップおよびリカバリ用のすべてのデータは引き続きデータベース・インスタンスを経由します。RMANのバックアップ・クライアントをOracle Exadata Database Machineのデータベース・サーバーにインストールし、従来の環境の場合と同じようにエンタープライズ・バックアップ・ソリューションとの統合を容易にする必要があります。
-
開発、テストおよび品質保証用の1つ以上の非本稼働環境のデプロイの実行は、Oracle Exadata Database Machine環境にも適用されます。
関連項目:
-
ipconfユーティリティの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください
1.2 Oracle Exadataラックの電源の投入および切断
この項には次のトピックが含まれます:
1.2.1 非緊急時の電源の投入と切断の手順
この項では、Oracle Exadataラックのコンポーネントの電源を正しく投入および切断する手順を説明します。この項では、次の項目について説明します。
1.2.1.1 Oracle Exadataラックの電源の投入
Exadata Storage Serverの電源を投入するには、サーバー前面にある電源ボタンを押すか、ILOMインタフェースにログインしてシステムに電源を投入します。データベース・サーバーの電源が投入され、オペレーティング・システムがブートすると、Oracle Clusterwareがインストールされている場合にOracle Clusterwareが自動的に起動します。Oracle Clusterwareは、自動的に起動する構成のすべてのリソースを起動します。
電源投入の手順は次のとおりです。
1.2.1.1.1 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.2 Oracle Exadataラックの電源の切断
- データベース・サーバー(Oracle Exadata Database Machineのみ)。
- Exadata Storage Server。
- ラック(スイッチを含む)。
1.2.1.2.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
Oracle Exadata Storage Serverの電源を切断する際は、次の点に注意してください。
-
複数のOracle Exadata Storage Serverを停止する前に、すべてのデータベースおよびOracle Clusterwareプロセスを停止する必要があります。
-
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)マニュアル・ページを参照してください。
1.2.1.2.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
-
ラックから電源を切断します。
1.2.2 緊急時の電源切断の考慮事項
緊急時には、Oracle Exadataラックの電源をすぐに停止してください。次のような緊急時に、Oracle Exadataラックの電源切断が必要となります。
-
地震、洪水、ハリケーン、竜巻、またはサイクロンなどの自然災害の場合。
-
マシンから異常な騒音、臭い、または煙が発生した場合。
-
人の安全を脅かす場合。
1.2.2.1 緊急時の電源切断の手順
緊急時にOracle Exadataラックの電源切断手順を実行するには、ブレーカの電源を切断するか、コンピュータ・ルームの緊急時の電源切断スイッチを切ってください。その後、Oracleサポート・サービスに連絡してマシンの電源を元に戻します。
1.2.3 注意事項と警告
Oracle Exadataラックには、次の注意事項と警告が適用されます。
-
この製品の高圧電力を使用する部分には触れないでください。触れた場合、重傷を負う可能性があります。
-
緊急時以外は、Oracle Exadataラックの電源を切断しないでください。緊急時は、「緊急時の電源切断の手順」に従ってください。
-
キャビネットの前のドアと後のドアを閉めた状態にしてください。扉を閉めないと、システム障害や、ハードウェア・コンポーネントの破損が生じることがあります。
-
空気が適切に循環し、コンポーネントが過熱しないように、キャビネットの上部、前部および後部に障害物がない状態にしてください。
-
付属のハードウェア以外は使用しないでください。
1.3 「自動サービス・リクエストの理解」
自動サービス・リクエスト(ASR)は、特定のOracle Exadataラックのハードウェアに障害が発生すると自動的にサービス・リクエストを開くように設計されています。
この機能を有効にするには、ハードウェア障害の遠隔測定情報をASRマネージャ・ソフトウェアに送信するように、Oracle Exadataラック・コンポーネントを構成する必要があります。このサービスでは、ディスクやフラッシュ・カードなどのExadata Storage ServerおよびOracle Database Serverのコンポーネントが対象となります。
Oracle Exadataラックの接続、およびHTTPSまたはHTTPSプロキシを使用したアウトバウンド・インターネット接続が可能なサーバーに、ASRマネージャをインストールする必要があります。Oracle Exadataラックの外部のサーバーにASRマネージャをインストールすることをお薦めします。推奨理由の一部は、次のとおりです。
-
ASRマネージャがインストールされたサーバーがダウンすると、ASRマネージャはOracle Exadata Database Machineのその他のコンポーネントには使用できません。設置場所にASRを使用するOracle Exadata Database Machineが複数ある場合、これは非常に重要です。
-
サービス・リクエスト(SR)を送信するには、サーバーがインターネットにアクセスできる必要があります。
注意:
ASRでは管理ネットワークのみを使用できます。ASRを実行できるように管理ネットワークが設定されていることを確認してください。
ハードウェアの問題が検出されると、ASRマネージャはサービス・リクエストをOracleサポート・サービスに送信します。多くの場合、データベース管理者が問題を認識する前に、Oracleサポート・サービスで問題の解決作業を開始できます。
ASRを使用する前に、次を設定する必要があります。
-
Oracle Premier Support for SystemまたはOracle/Sun Limited Warranty
-
Oracle Exadataラックの技術担当窓口
-
Oracle Exadataラック部品の有効な発送先
電子メールメッセージが技術担当窓口に送信され、アクティブ化されたアセットでサービス・リクエストの作成が通知されます。次に、ディスク障害が発生した場合にASRマネージャに送信されるSimple Network Management Protocol (SNMP)トラップの例を示します。
注意:
-
ASRはコンポーネントの障害のみに適用されます。すべてのコンポーネント障害が対象となるわけではありませんが、ディスク、ファン、電源などのほとんどの共通コンポーネントは対象となります。
-
ASRは、SMTP、SNMPアラートなど、カスタマ・データ・センター内のその他の監視メカニズムに代わるものではありません。ASRは、交換ハードウェアの発送を促進および簡素化する補完メカニズムです。ASRは、高優先度システムのダウンタイム・イベントに使用することはできません。高優先度イベントの場合は、Oracleサポート・サービスまで直接ご連絡ください。
-
サービス・リクエストが自動的に送信されない場合があります。これは、SNMPプロトコルの低い信頼性やASRマネージャの接続解除により発生する可能性があります。システムの障害について継続的に監視して、サービス・リクエストが自動的に提出されたことを示す通知が送られてこない場合は、Oracleサポート・サービスに問い合せることをお薦めします。
-
ASRは、リリース11.2.3.3.0以上を実行しているOracle Exadata Database Machineの、ファームウェア・リリース2.1.2以上のSun Datacenter InfiniBand Switch 36スイッチを監視できます。フィールド・エンジニアによるスイッチへのエンタイトルメント・シリアル番号の設定が必要になる場合があります。
例1-2 Exadata Storage Server SNMPトラップの例
この例は、Exadata Storage Serverディスク障害の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.1 ASRのインストールおよび構成
Oracle ASRは、Oracle SolarisまたはLinuxを実行しているスタンドアロン・サーバーにインストールすることをお薦めします。
インストールが完了したら、Oracle Exadata Database Machineのサーバーに対して障害の遠隔測定情報の送信先を構成します。Oracle Exadata Database Machineのサーバーは、初期構成時に設定できます。Oracle Exadata Database Machine Deployment Assistantで構成情報を収集し、サーバーを構成します。
注意:
ILOMアラート設定を構成する場合、ルール・リストの上部にあるルールを削除しないでください。新しいルールを追加するには、ルール・リストの一番下にルールを入力します。
- 初期構成後にOracleASRをインストールして構成する方法の詳細は、Oracle Auto Service Request Oracle Exadata Database Machineクイック・インストレーション・ガイドに記載されているインストールおよび構成の情報を参照してください。
関連項目:
-
Oracle Exadata Database Machine Oracle Auto Service Requestクイック・インストレーション・ガイド
-
Oracle Exadata Deployment AssistantのASRの構成ページの詳細は、『Oracle Exadata Database Machineインストレーションおよび構成ガイド』を参照してください
-
Oracle Auto Service Requestのユーザー・ドキュメント(
http://www.oracle.com/technetwork/systems/asr/documentation/index.html) -
Oracleサポート・サービスへの連絡の詳細は、「Oracleサポート・サービスへの連絡」を参照してください。
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 コンポーネントのパスワードの変更
コンポーネントのパスワードは、初期構成後に変更できます。
1.6.1 データベース・サーバーのパスワードの変更
ユーザー・アカウントとGRUBのパスワードは、データベース・サーバーで変更できます。データベース・サーバーのデフォルトのユーザー・アカウントはrootおよびソフトウェア所有者のアカウントです。通常、ソフトウェア所有者のアカウントはoracleまたはgridです。
1.6.2 Exadata Storage Serverのパスワードの変更
Exadata Storage Serverのデフォルトのユーザー・アカウントはroot、celladminおよびcellmonitorです。
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イーサネット・スイッチのパスワードの変更」
イーサネット・スイッチのパスワードを変更するには、スイッチに接続してスイッチに対してコマンドを実行する必要があります。
1.6.6.1 Cisco 4948イーサネット・スイッチのパスワードの変更
スイッチへのシリアル・ポート・アクセスとSSHアクセスの両方のパスワードを変更できます。
スイッチにアクセスするには、2つの異なる方法があります。1つはシリアル・ポートを使用し、もう1つはsshを使用します。シリアル・ポート・アクセスを使用する場合は、ユーザー・アカウントがないため、enableパスワードのみが必要となります。sshを介してスイッチにアクセスする場合は、パスワードを変更する前に、ユーザー・アカウントとパスワードを指定する必要があります。システムのインストール中にadminユーザーが作成されるため、このユーザーを使用してsshでスイッチにアクセスできます。
1.7 サーバー・モデルの判別
セル・サーバーまたはデータベース・サーバーのモデルを判別するには、次のコマンドを使用します。
/usr/sbin/exadata.img.hw --get model
各Oracle Exadata Database Machineのサーバー・モデル番号は、次の表を参照してください。
表1-2 Oracle Exadata Database Machineのサーバー・モデル
| Oracle Exadata Database Machine | データベース・サーバーのモデル | Exadata Storage Serverのモデル |
|---|---|---|
|
Oracle Exadata Database Machine X7-2 |
|
|
|
Oracle Exadata Database Machine X7-8 |
|
|
|
Oracle Exadata Database Machine X6-2 |
|
|
|
Oracle Exadata Database Machine X6-8 |
|
|
|
Oracle Exadata Database Machine X5-2 |
|
|
|
Oracle Exadata Database Machine X5-8 |
|
|
|
Oracle Exadata Database Machine X4-2 |
|
|
|
Oracle Exadata Database Machine X4-8フル・ラック |
|
|
|
Oracle Exadata Database Machine X3-2 |
|
|
|
Oracle Exadata Database Machine X3-8フル・ラック |
|
|
|
Oracle Exadata Database Machine X2-2 |
|
|
|
Oracle Exadata Database Machine X2-8フル・ラック |
|
|
|
Oracle Exadata Database Machine |
|
|
1.8 サーバーの周囲温度の監視
環境温度条件をOracle Exadataラックの設計仕様内に維持すると、最大限の効率化とコンポーネント・サービスの目標存続期間の達成に役立ちます。周囲温度範囲の検証による影響は最小です。是正処置による影響は、環境条件によって異なります。
摂氏21から23度(華氏70から74度)の外部周囲温度は、Oracle Exadataラックのすべてのコンポーネントに影響し、パフォーマンス上の問題が発生し、サービス存続期間が短くなることがあります。
次のコマンドをクラスタの最初のデータベース・サーバーの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を交換する方法について説明します。
注意:
この項の手順は、コントローラに内蔵のバッテリ・バックアップ・ユニットには適用されません。これらのユニットを交換する場合は、システムを開いてコントローラ・カードにアクセスするため、システムを停止する必要があります。
1.9.1 データベース・サーバーのディスク・コントローラBBUの交換
この項では、データベース・サーバーのディスク・コントローラBBUを交換する方法について説明します。高度な手順は次のとおりです。
注意:
保守手順の終了後は常にExachkツールを使用することをお薦めします。このツールはMy Oracle Supportノート1070954.1から入手できます。
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がないシステムの準備」の手順を実行します。
1.9.1.1.1 リモート・マウントBBUがあるシステムの準備
リモート・マウントBBUがあるシステムのディスク・コントローラBBUを取り外す際の準備方法について説明します。
システムにリモート・マウントBBUがない場合は、「リモート・マウントBBUがないシステムの準備」を参照してください。
1.9.1.1.2 リモート・マウントBBUがないシステムの準備
このトピックでは、リモート・マウントBBUがないシステムのディスク・コントローラBBUを取り外す際の準備方法について説明します。
リモート・マウントされたバッテリがシステムに取り付けられていない場合は、バッテリの交換が必要なノードをシャットダウンする必要があります。
システムにリモート・マウントBBUがある場合は、「リモート・マウント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データベース・マシン計算ノード
これらの手順は、X2-8サーバー(旧称x4800m2)に基づいたExadataノードに関連します。
-
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の取り外しの準備」の終了時にシステムはシャットダウンされていません。
イメージ・バージョン11.2.3.3.0以上を使用している場合:
-
ルート・ユーザーとしてログインします。
-
ディスク・コントローラ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およびディスク・キャッシュを再有効化します。
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -reenable_bbu HDD disk controller battery has been reenabled.
-
ディスク・コントローラBBUのバッテリ状態がOperationalであることを確認します。
# /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を有効にします。
-
電源ボタンを押して、サーバーの電源を入れます。
-
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になります。 -
インスタンスが実行中であることを検証します。
# ps -ef |grep pmon
ASMインスタンスのレコードと各データベースのレコードが返されます。
-
1.9.2 Exadata Storage Serverのディスク・コントローラBBUの交換
この項では、Exadata Storage Serverのディスク・コントローラBBUを交換する方法について説明します。手順の概要は次のとおりです。
注意:
保守手順の終了後は常に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があるシステムの場合」を参照してください。
リモート・マウントされたバッテリがシステムに取り付けられていない場合は、バッテリの交換が必要なノードをシャットダウンする必要があります。
-
すべての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... -
すべてのディスクがオフラインになり、非アクティブになると、セルをシャットダウンできます。
# shutdown -hP nowExadata Storage Serverの電源を切断すると、すべてのストレージ・サービスが自動的に停止します。
-
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サービスの概要
-
リリース12.1.2.1.2以上の場合
12.1.2.1.2リリース以上では、データベース・ノードの管理サーバー(MS)でsudoが使用されなくなりました。つまり、sudoersの構成は必要なくなりました。
-
12.1.2.1.2より前のリリースの場合
セキュリティ上の理由から、データベース・ノードの管理サーバーはrootとして実行されません。ただし、ディスク・ステータス、ILOM、電源ユニットなど、システムを監視する特定のユーティリティを実行し、ASRおよびアラートを送信するには、root権限が必要になります。これを達成するために、sudoers構成ファイルの
dbmsvc_sudo_confが追加され、dbmmgmtユーザーがroot権限でユーティリティを実行できるようになっています。dbmmgmtサービスまたはdbserverdを無効にしたり、sudoers構成ファイルを編集したりしないでください。ファイルのエントリが削除されると、dbmmgmtサービスでシステムの一部の部分を監視できなくなる場合があります。たとえば、ディスクに障害が発生すると、ASRを時間内に送信できなくなり、データベース・ノードで破損が発生し、リカバリが遅延する場合があります。
1.11 dbmsrvのユーザーIDおよびグループIDの変更
Oracle Exadata Database Machine 12.1.2.1.0以降:
-
データベース・ノードで管理サーバー(MS)が実行されるようになりました。以前のMSは、ストレージ・ノードでのみ実行されていました。
-
データベース・マシン・サービス(dbmsrv)という名前の新しいサービスがデータベース・ノードで実行されるようになりました。この新しいサービスがベースとするMSは、ストレージ・サーバー上で実行され、データベース・ノードに拡張管理機能を提供します。
新しいdbmsrvサービスを管理するために、新しいユーザーとグループが追加されました。
表1-3 dbmsrvのユーザー
| ユーザー | デフォルトのユーザーID |
|---|---|
|
dbmsvc |
12137 |
|
dbmadmin |
12138 |
|
dbmmonitor |
12139 |
表1-4 dbmsrvのグループ
| グループ | デフォルトのグループID |
|---|---|
|
dbmsvc |
11137 |
|
dbmadmin |
11138 |
|
dbmmonitor |
11139 |
|
dbmusers |
11140 |
デフォルト値と競合が発生している場合(たとえば、LDAPまたは別のディレクトリを使用している場合、または、デフォルト値と異なる値を必要とするセッション管理ツールを使用している場合)、DBMユーザーのユーザーIDとグループIDを変更できます。
これらの手順は、DBMサービスのユーザーとグループのみに固有です。これらを使用して、他のOracle製品のユーザーとグループを変更しないでください。
デフォルトのDBMユーザーおよびグループIDを変更する手順:
1.12 サーバーにリモートにアクセスするユーザーのパスワードの有効期限の構成
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.13 構成変更中のセルおよびデータベース・ノードの状態
表1-5は、構成変更中にセル・ノードとデータベース・ノードをオフラインとオンラインのどちらにしておく必要があるかを示しています。
表1-5 操作時のセルおよびデータベース・ノードの状態
| 操作 | セル・ノード | データベース・ノード |
|---|---|---|
|
DNSサーバーの更新 |
オンライン |
オンライン |
|
NTPサーバーの更新 |
オンライン |
オンライン |
|
タイム・ゾーンの更新 |
オフライン |
オンライン |
|
管理ネットワークのIPアドレス、ネットマスク、ゲートウェイ、ホスト名の変更 |
オフライン |
オンライン |
|
クライアント・ネットワークのIPアドレス、ネットマスク、ゲートウェイ、ホスト名の変更 |
オフライン |
オンライン |
|
ILOM IPアドレスの変更 |
オフライン |
|
|
その他のILOMパラメータの変更 |
|
|
|
InfiniBand IP、ネットマスク、ホスト名の変更 |
オフライン |
オンライン |
|
pkeyの変更 |
オフライン |
オンライン |
1.14 レスキュー計画
12.2.1.1.0より前のExadataリリースでは、ストレージ・サーバーまたはデータベース・サーバーのレスキュー後に、複数のコマンドを再実行して、IORMプラン、しきい値、ストレージ・サーバーおよびデータベース・サーバーの通知設定などの項目を構成する必要があります。
Oracle Exadataリリース12.2.1.1.0では、cellとdbserverの各オブジェクトにrescuePlanという新しい属性があります。データベース・サーバーとストレージ・サーバーの構成が完了したとき、rescuePlan属性の値をファイルに保存する必要があります。レスキューされたサーバーのデータはレスキュー時に消去されるため、ファイルをリモート・サーバーに保存する必要があります。サーバーのレスキュー後に、リモート・サーバーからファイルを取得し、ファイルを実行して設定をリストアできます。次の例3を参照してください。
セキュリティ上の理由から、レスキュー計画には、パスワードを必要とする構成は含めません。
例1-4 ストレージ・セルのレスキュー計画
ストレージ・サーバーの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-5 データベース・サーバーのレスキュー計画
データベース・サーバーの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-6 セルのレスキュー計画スクリプトの作成
次のコマンドで、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-7 データベース・サーバーのレスキュー計画スクリプトの作成
次のコマンドで、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.15 ExaWatcherチャート
ExaWatcherは、Exadataシステムのストレージ・サーバーおよびデータベース・サーバーのパフォーマンス・データを収集するユーティリティです。収集されるデータには、iostat、セル統計(cellsrvstat)、ネットワーク統計などのオペレーティング・システム統計情報が含まれます。
ExaWatcherで収集されたデータを抽出するには、GetExaWatcherResults.shを実行して、対象の時間範囲の開始時間と終了時間を指定します。結果は、ExtractedResultsというディレクトリの圧縮アーカイブ・ファイルに配置されます。
次に例を示します。
$ GetExaWatcherResults.sh --from 08/24/2016_17:00:00 --to 08/25/2016_17:00:00注意:
GetExaWatcherResults.shで-cまたは--scpのオプションを使用して、結果のアーカイブ・ファイルを別の場所にコピーできます。
リリース12.2.1.1.0では、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ページを表示するには、インターネットにアクセスできるローカル・ブラウザを持つマシンにアーカイブ・ファイルを移動する必要があります。ファイルは、bz2圧縮ファイルを解凍してから、tar -xvfを使用してtarファイルを解凍する必要があります。その後、ブラウザでCharts.ExaWatcher.<hostname>/<timestamp>_<duration>/index.htmlを開くことができます。そのページの左パネルには、次のメニューが表示されます。
注意:
スクリーン・リーダーのユーザーは、メニュー項目は上下の矢印キーを使用してナビゲートし、スペース・バーを使用してアクティブ化します。[Tab]キーを使用すると、右側のフレームに移動します。「CellSrvStat」メニュー項目は、ストレージ・サーバーに対して実行した場合にのみ使用できます。「アラート履歴」メニュー項目は、要求した時間枠にアラートが発生した場合にのみ使用できます。
1.15.1 IOチャート
1.15.1.1 IO統計サマリー
IOStatサマリーには、サーバー全体のIOパフォーマンスのサマリーが示されます。このページには次の4つのチャートが表示されます。
表1-6 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のチャートを示します。
各チャートの下に、チャート内の特定の時間のドリルダウンに使用できる範囲セレクタがあります。いずれかのチャートの範囲セレクタを移動すると、ページ上のすべてのチャートに影響します。
注意:
範囲セレクタは、スクリーン・リーダーにアクセスできません。また、チャートに表示されるすべての値がスクリーン・リーダーにアクセスできるわけではありません。それぞれのチャートのデータ・ポイントの最初の値のみが該当します。
範囲セレクタを使用すると、表示されるチャートが変更されて、範囲セレクタで指定した時間枠のデータのみが表示されます。
1.15.1.2 I/O統計詳細
IOStat詳細には、ストレージ・サーバーの各ディスクのパフォーマンスが示されます。このページには、次のチャートが表示されます。
表1-7 IO統計詳細の統計
| 統計 | 説明 |
|---|---|
|
フラッシュ・サービス時間 ハード・ディスク・サービス時間 |
待機時間の範囲に対する、ディスクごとの平均サービス時間。 |
|
フラッシュ待機時間 ハード・ディスク待機時間 |
ディスクごとの平均待機時間 |
デフォルトでは、チャートには、サーバー上のすべてのディスクの平均を示す線が含まれます。影付きのバックグラウンド・イメージは、統計の最小と最大の範囲を示しています。ドロップダウン・セレクタを使用して、個別のディスクを表示することを選択できます。
バックグラウンド・イメージの範囲が広い場合は、ディスク・パフォーマンスに差異がある可能性があることを示します。このメトリックを使用して、ストレージ・サーバーの個々のディスクをより詳細に確認することで、不均衡が発生しているかどうかを知ることができます。バックグラウンド・イメージの範囲が狭い場合は、ディスクのパフォーマンスが似ていることを示します。
また、ストレージ・サーバーの個別のディスクのIOPとMB/sをデータ・シートの数値と比較して、ディスクが最大容量に達した可能性があるかどうかを確認することもできます。
1.15.4 セル・サーバー・チャート
セル・サーバー統計は、Exadata Storage Serverに固有の機能を追跡する場合に役立ちます。このページには、スマート・フラッシュ・キャッシュおよびスマートIOに関連する統計が示されます。
