この章では、Oracle Exadata Database Machineの一般的な保守について説明します。
注意:
読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。
この章のすべての手順は、Oracle Exadata Database MachineおよびOracle Exadata Storage拡張ラックに適用されます。
ほとんどのIT組織には、データベース管理者、システム管理者、ネットワーク管理者およびストレージ管理者のチームがあります。これらの管理者はシステム実装および操作の続行を担当します。Oracle Exadata Database Machine環境では、通常、データベース管理者がシステム管理者のサポートを受けながらOracle Exadata Database Machine管理の主要な役割を担当するようにすると、より効率的かつ効率的になります。これは、Oracle Exadata Database MachineがOracle Databaseを実行するように設計され、管理がOracle DatabaseおよびOracle Exadata Storage Server Softwareに固有であるためです。その他のチームに異なる職責を与えるか、または第2レベルとしてサポートするようにできます。
通常、初期システム・デプロイメントはOracleエンジニアが実行します。データベース管理者の主要職責は通常の操作タスクで開始されます。次の表は、Oracle Exadata Database Machine環境の管理に必要なタスクの一部を示しています。表1-1に、共通管理タスクを示します。
表1-1 Oracle Exadata Database Machine管理の共通管理タスク
タスクまたはイベント | 管理者 | アクション |
---|---|---|
パフォーマンスの低下 |
データベース管理者 システム管理者 |
Oracle Enterprise Manager Grid Controlからパフォーマンスのしきい値を超えたというアラートを受け取ります。 すべてのサーバーのシステム・パフォーマンス、CPU、メモリーおよびI/Oで異常な傾向を確認します。 データベース・パフォーマンス、待機イベント、ロック、並列処理および実行計画を確認します。 |
パッチ適用またはアップグレード |
データベース管理者 システム管理者 |
Oracle Exadata Storage Server Softwareのパッチまたはアップグレード、およびSun Datacenter InfiniBand Switch 36スイッチのファームウェアのアップグレードを適用します。 Oracle Databaseのパッチ、グリッド・インフラストラクチャのパッチまたはアップグレードを適用します。 |
システム停止または障害 |
データベース管理者 システム管理者 |
Integrated Lights Out Manager(ILOM)に接続し、現在のシステム状態を確認し、ハードウェアの問題点の識別またはシステムの再起動を行い、およびログを確認して根本的な原因分析を行います。 残存インスタンスでエラーのチェック、残存インスタンスのパフォーマンスの監視およびアプリケーション機能が損われていないことの確認を行います。 |
疑いのあるネットワークの問題点 |
データベース管理者 システム管理者 |
ネットワーク・インタフェースでエラーまたは削除されたパケットを検出し、再起動したスイッチがあるかどうかをチェックし、必要に応じてネットワーク管理チームにエスカレートします。 データベース側のパフォーマンスを検査して影響を評価します(影響がある場合)。 |
データベースのバックアップ |
データベース管理者 システム管理者 |
データベースのバックアップ・ルーチンを実行し、データベース・サーバーのバックアップが完了していることを確認します。 |
障害ディスクの交換 |
データベース管理者 システム管理者 |
ハードウェア交換に関するアラートを受け取り、自動サービス・リクエスト(ASR)がサービス・リクエストを開いたことを確認し、オペレータがデータ・センターのフィールド・サービス技術者にドライブの交換またはスペアのドライブの提供を許可していることを確認します。 |
通常、発生した問題の主担当は個人またはグループです。システムに問題が発生すると、この担当者または担当するグループがOracle Enterprise Manager Grid Control、ヘルプ・デスクまたは操作チームから最初に連絡を受けます。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に対する影響の可能性を確認する必要があります。
サーバーを不正に再起動すると、データベースが壊れる可能性があります。ストレージ・サーバーには、サーバーを再起動する前にグリッド・ディスクをオフラインにする、一度に複数のサーバーを再起動できないなど、データベースの破壊を最小化するために従う必要がある特別な手順とガイドラインがあります。
Exadata Storage Serverはデータベース・サーバーと同じように変更できません。NTPサーバーまたはDNSサーバーなどのネットワークの変更は、ipconf
ユーティリティを使用して行います。ネットワークの変更は構成ファイルを編集して手動で行うことはできません。さらに、ストレージ・サーバーにソフトウェアまたは追加パッケージをインストールすることはできません。この制約にはソフトウェアの監視が含まれます。Exadata Storage Serverシステムのアップデートは、Oracle Exadata Storage Server Softwareのアップグレードで行われます。
Exadata Storage Serverのバックアップは不要で、自己保守される内部USBドライブがあり、セルのリカバリにこれを使用できます。バックアップ・クライアントはストレージ・サーバーにインストールできません。
Exadata Storage Serverを使用するOracle Real Application ClusterデータベースのOracle待機イベントには、名前に%cell%
が付いたイベントを含めることができます。これらのイベントは、ストレージ・サーバー関連のものです。
V$CELLビューには、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
を含めると、操作の一部をExadata Storage Serverに肩がわりさせて負荷を軽減できることを示すことができます。
バックアップやリカバリなどの操作では、Oracle Recovery Manager(RMAN)が使用され、バックアップおよびリカバリ用のすべてのデータは引き続きデータベース・インスタンスを経由します。RMANのバックアップ・クライアントをOracle Exadata Database Machineのデータベース・サーバーにインストールし、従来の環境の場合と同じようにエンタープライズ・バックアップ・ソリューションとの統合を容易にする必要があります。
開発、テストおよび品質保証用の1つ以上の非本稼働環境のデプロイの実行は、Oracle Exadata Database Machine環境にも適用されます。
関連項目:
ipconf
ユーティリティの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください
この項には次のトピックが含まれます:
この項では、Oracle Exadataラックのコンポーネントの電源を正しく投入および切断する手順を説明します。この項では、次の項目について説明します。
Exadata Storage Serverの電源を投入するには、サーバー前面にある電源ボタンを押すか、ILOMインタフェースにログインしてシステムに電源を投入します。データベース・サーバーの電源が投入され、オペレーティング・システムがブートすると、Oracle Clusterwareがインストールされている場合にOracle Clusterwareが自動的に起動します。Oracle Clusterwareは、自動的に起動する構成のすべてのリソースを起動します。
電源投入の手順は次のとおりです。
ILOMインタフェースを使用して、サーバーの電源をリモートで投入できます。
Webコンソール、コマンドライン・インタフェース(CLI)、IPMIまたはSNMPを使用して、ILOMにアクセスできます。たとえば、IPMIを使用してサーバーdm01cel01
に電源を投入するには、電源を投入するサーバーのILOMのホスト名がdm01cel01-ilom
の場合、IPMItoolがインストールされているサーバーから次のコマンドを実行します。
# ipmitool -I lanplus -H dm01cel01-ilom -U root chassis power on
前述のコマンドにより、システムのパスワードの入力が要求されます。
Linux shutdown
コマンドを使用して、Exadata Storage Serverの電源を切断し、再起動します。次のコマンドを使用して、Exadata Storage Serverを直接停止します。
# shutdown -h now
Exadata Storage Serverの電源を切断すると、すべてのストレージ・サービスが自動的に停止します。
次のコマンドを使用して、Exadata Storage Serverを直接再起動します。
# shutdown -r now
Exadata Storage Serverの電源を切断する際は、次の点に注意してください。
複数のExadata Storage Serverを停止する前に、すべてのデータベースおよびOracle Clusterwareプロセスを停止する必要があります。
1つのExadata Storage Serverの電源を切断しても、実行中のデータベース・プロセスまたはOracle ASMに影響しません。
Exadata Storage Serverの電源切断または再起動により、データベースの可用性に影響を与える場合があります。
shutdown
コマンドを使用して、データベース・サーバーの電源切断または再起動を実行できます。
関連項目:
Exadata Storage Serverの電源を切断してデータベースまたはOracle Clusterwareを稼働したままにする場合は、「Exadata Storage Serverのシャットダウン」を参照してください。
詳細は、SHUTDOWN(8)マニュアル・ページを参照してください。
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ラックの電源をすぐに停止してください。次のような緊急時に、Oracle Exadataラックの電源切断が必要となります。
地震、洪水、ハリケーン、竜巻、またはサイクロンなどの自然災害の場合。
マシンから異常な騒音、臭い、または煙が発生した場合。
人の安全を脅かす場合。
緊急時にOracle Exadataラックの電源切断手順を実行するには、ブレーカの電源を切断するか、コンピュータ・ルームの緊急時の電源切断スイッチを切ってください。その後、Oracleサポート・サービスに連絡してマシンの電源を元に戻します。
Oracle Exadataラックには、次の注意事項と警告が適用されます。
この製品の高圧電力を使用する部分には触れないでください。触れた場合、重傷を負う可能性があります。
緊急時以外は、Oracle Exadataラックの電源を切断しないでください。緊急時は、「緊急時の電源切断の手順」に従ってください。
キャビネットの前のドアと後のドアを閉めた状態にしてください。扉を閉めないと、システム障害や、ハードウェア・コンポーネントの破損が生じることがあります。
空気が適切に循環し、コンポーネントが過熱しないように、キャビネットの上部、前部および後部に障害物がない状態にしてください。
付属のハードウェア以外は使用しないでください。
自動サービス・リクエスト(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.
関連トピック
ASRは、Oracle SolarisまたはLinuxを実行しているスタンドアロン・サーバーにインストールすることをお薦めします。
インストールが完了したら、Oracle Exadata Database Machineのサーバーに対して障害の遠隔測定情報の送信先を構成します。Oracle Exadata Database Machineのサーバーは、初期構成時に設定できます。Oracle Exadata Database Machine Deployment Assistantで構成情報を収集し、サーバーを構成します。
注意:
ILOMアラート設定を構成する場合、ルール・リストの上部にあるルールを削除しないでください。新しいルールを追加するには、ルール・リストの一番下にルールを入力します。
関連項目:
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サポート・サービスへの連絡」を参照してください。
最初のデータベース・サーバーにOracle Enterprise Manager Cloud Controlエージェントを配置したOracle Enterprise Manager Cloud ControlおよびExadata Storage ServerのOracle System Monitoring Plug-Inを使用して、Oracle Exadata Database Machineを監視できます。各Exadata Storage Serverは、Oracle Enterprise Manager Cloud Controlの単一のターゲットとして監視されます。Oracle Exadata Database Machineのシステム・ダッシュボードにサーバーがグループ化されるので、グループ単位で監視できます。Oracle Enterprise Managerのセットアップの自動化キットのエージェント・キットでは、単純な1つのコマンドを使用して、Oracle Management Agentsおよび必要なすべてのプラグインをOracle Exadata Databaseの一部であるすべての計算ノードにデプロイできます。
Exadata Storage Serverメトリックは、管理サーバー(MS)によって収集および管理されます。Oracle Enterprise Manager Cloud Controlと一緒に使用すると、Oracle Enterprise Manager Cloud Controlメトリックとしてメトリックが示されます。
SNMPにより、すべてのExadata Storage ServerアラートがOracle Enterprise Manager Cloud Controlに配信されます。Exadata Storage ServerとOracle Enterprise Manager Cloud Control間の通信は、Exadata Storage ServerのOracle System Monitoring Plug-Inで実行されます。Exadata Storage Serverのサーバー・アラートのタイプは、次のとおりです。
ハードウェア・コンポーネントは、ILOMによって監視されます。ハードウェア・コンポーネントが障害またはしきい値を超えたことを報告した場合、ILOMはSNMPトラップとして障害をMSに報告します。MSは、トラップを処理してアラートを作成し、アラートをOracle Enterprise Manager Cloud Controlに配信します。
注意:
ILOMアラート設定を構成する場合、ルール・リストの上部にあるルールを削除しないでください。新しいルールを追加するには、ルール・リストの一番下にルールを入力します。
ハードウェアおよびソフトウェア・コンポーネントもMSによって直接監視されます。障害またはしきい値を超えると、MSは、トラップを処理してアラートを作成し、アラートをOracle Enterprise Manager Cloud Controlに配信します。
エンドユーザーの観点から、2つのタイプのアラートに違いはありません。アラート・メッセージには、アラートを解決する訂正処理が含まれています。
関連項目:
Oracle Enterprise Manager Cloud Controlのインストールの詳細は、『Oracle Exadata Database Machineインストレーションおよび構成ガイド』を参照してください
Exadata用のOracle Enterprise Managerのセットアップの自動化キットの取得(My Oracle SupportのドキュメントID 1440951.1)
修復の実行時に不要なアラートを回避するブラックアウトの使用方法の詳細は、Oracle Enterprise Manager管理を参照してください。
Oracle Configuration Managerは、構成情報を収集してOracleリポジトリにアップロードします。
構成情報が毎日アップロードされると、Oracleサポート・サービスでデータを分析して適切なサービスを提供できます。サービス・リクエストが記録されると、構成データがサービス・リクエストに関連付けられます。次に、Oracle Configuration Managerの利点の一部を示します。
問題解決の時間の短縮
事前の問題回避
ベスト・プラクティスおよびOracleナレッジ・ベースのアクセスの向上
お客様のビジネス・ニーズの詳細な理解
一貫したレスポンスおよびサービス
サーバーの各ORACLE_HOME
ディレクトリに、Oracle Configuration Managerソフトウェアがインストールおよび構成されます。クラスタ化されたデータベースには、Oracle Configuration Managerに1つのインスタンスのみが構成されます。構成スクリプトは、サーバーのすべてのデータベースで実行されます。Oracle Configuration Managerコレクタが集中管理されているOracleリポジトリにデータを送信します。
関連トピック
コンポーネントのパスワードは、初期構成後に変更できます。この項には次のトピックが含まれます:
ユーザー・アカウントとGRUBのパスワードは、データベース・サーバーで変更できます。データベース・サーバーのデフォルトのユーザー・アカウントはroot
およびソフトウェア所有者のアカウントです。通常、ソフトウェア所有者のアカウントはoracle
またはgrid
です。
データベース・サーバーでユーザー・アカウントを変更するには、オペレーティング・システム・プロンプトで次のコマンドを使用します。
passwd user_name
前述のコマンドのuser_nameは、変更対象のアカウントの名前です。
Exadata Storage Serverのデフォルトのユーザー・アカウントはroot
、celladmin
およびcellmonitor
です。
配電ユニット(PDU)のデフォルトのユーザー・アカウントはadmin
です。次の手順では、PDUのパスワードを変更する方法について説明します。
admin
ユーザーとしてログインします。 Integrated Lights Out Manager (ILOM)のデフォルトのユーザー・アカウントはroot
です。次の手順では、ILOMのパスワードを変更する方法について説明します。
この手順では、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
)スイッチへのシリアル・ポート・アクセスとSSHアクセスの両方のパスワードを変更できます。
スイッチにアクセスするには、2つの異なる方法があります。1つはシリアル・ポートを使用し、もう1つはssh
を使用します。シリアル・ポート・アクセスを使用する場合は、ユーザー・アカウントがないため、enable
パスワードのみが必要となります。ssh
を介してスイッチにアクセスする場合は、パスワードを変更する前に、ユーザー・アカウントとパスワードを指定する必要があります。システムのインストール中にadmin
ユーザーが作成されるため、このユーザーを使用してssh
でスイッチにアクセスできます。
シリアル・ポート・アクセスのパスワードの変更
telnet
、ssh
またはシリアル・ポートを使用してスイッチにアクセスします。アクセスにシリアル・ポートを使用する場合は、プロンプトが表示されるのみで、ユーザー名またはパスワードが要求されることはありません。
次に例を示します。
my_host> ssh admin@my_switch Using keyboard-interactive authentication. Password:
注意:
Oracle Linux 5 Update 5以上では、セキュリティ上の理由から、telnet
が削除されました。telnet
を使用してスイッチにアクセスするには、事前に計算ノードにTelnetクライアント・パッケージをインストールする必要がある場合があります。
SSHを使用してスイッチにアクセスする前に、「Configuring SSH on Cisco Catalyst 4948 Ethernet Switch」(My Oracle SupportのドキュメントID 1415044.1)で説明されている手順に従ってスイッチでSSHを有効化する必要があります。
次のコマンドを使用して、有効モードに変更します。
Switch> enable
次のようにパスワードを設定します。
Switch# configure terminal
Enter configuration commands,one per line.End with CNTL/Z.
Switch(config)# no enable password
Switch(config)# enable secret new_password
Switch(config)# end
Switch# write memory
*Sep 15 14:25:05.893:%SYS-5-CONFIG_I:Configured from console by console
Building configuration...
Compressed configuration from 2502 bytes to 1085 bytes [OK ]
次のコマンドを使用して、現在の構成を保存します。
Switch# copy running-config startup-config
セッションを終了します。
Switch# exit
TelnetまたはSSHアクセスのユーザー・パスワードを変更する手順
セル・サーバーまたはデータベース・サーバーのモデルを判別するには、次のコマンドを使用します。
/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 X6-2 |
Oracle Server X6-2 Database Server
|
Exadata Storage Server X6-2L Server
|
Oracle Exadata Database Machine X6-8 |
Oracle Server X5-8 5U Database Server
|
Exadata Storage Server X6-2L Server
|
Oracle Exadata Database Machine X5-2 |
Oracle Server X5-2 Database Server
|
Exadata Storage Server X5-2L Server
|
Oracle Exadata Database Machine X5-8 |
Oracle Server X5-8 Database Server
|
Exadata Storage Server X5-2L Server
|
Oracle Exadata Database Machine X4-2 |
Sun Server X4-2 Oracle Database Server
|
Exadata Storage Server X4-2L Server
|
Oracle Exadata Database Machine X3-2 |
Sun Server X3-2 Oracle Database Server
|
Exadata Storage Server X3-2 Server
|
Oracle Exadata Database Machine X2-2 |
Sun Fire X4170 M2 Oracle Database Server
|
Sun Fire X4270 M2 Serverを使用したExadata Storage Server
|
Oracle Exadata Database Machine X4-8フル・ラック |
Sun Server X4-8 Oracle Database Server
|
Exadata Storage Server X4-2L Server
|
Oracle Exadata Database Machine X3-8フル・ラック |
Sun Server X2-8 Oracle Database Server
|
Exadata Storage Server X3-2 Server
|
Oracle Exadata Database Machine X2-8フル・ラック |
Sun Fire X4800 Oracle Database ServerまたはSun Server X2-8 Oracle Database Server
|
Sun Fire X4270 M2 Serverを使用したExadata Storage Server
|
Oracle Exadata Database Machine |
Sun Fire X4170 Oracle Database Server
|
Sun Fire X4275 Serverを使用したExadata Storage Server
|
環境温度条件を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
出力が周囲温度範囲外の場合は、問題を調査して是正します。次の項目をチェックする必要があります。
ラックに十分な通気がある
室温が指定範囲内にある
ラックの背面に障害物がない
ディスク・コントローラ・バッテリ・バックアップ・ユニット(ディスク・コントローラBBU)は、データベースおよびExadata Storage Serverのドライブ・トレイにあります。ディスク・コントローラBBUは、サーバーおよびサーバー上で実行されているアプリケーションの停止時間なしで交換できます。次の手順では、ディスク・コントローラBBUを交換する方法について説明します。
注意:
この項の手順は、コントローラに内蔵のバッテリ・バックアップ・ユニットには適用されません。これらのユニットを交換する場合は、システムを開いてコントローラ・カードにアクセスするため、システムを停止する必要があります。
この項では、データベース・サーバーのディスク・コントローラBBUを交換する方法について説明します。高度な手順は次のとおりです。
注意:
保守手順の終了後は常にExachkツールを使用することをお薦めします。このツールはMy Oracle Supportノート1070954.1から入手できます。
特定のX3-2、X4-2およびX4-8データベース・ノード、X3-2、X4-2、およびX3-8、X4-8ストレージ・サーバーでは、BBUはリモートでマウントされ、アクセスするのにシステムのシャットダウンは不要です。ただし、ディスク・ボリュームへのデータ破損を回避するには、RAID HBAから取り外せるように準備する必要があります。X3-8データベース・ノードのリモート・マウントBBUオプションはありません。
システムにリモート・マウントBBUがある場合は、「リモート・マウントBBUがあるシステムの場合」の手順に従います。システムにリモート・マウントBBUがない場合は、「リモート・マウントBBUがないシステムの場合」を参照してください。
リモート・マウントBBUがあるシステムの場合
次の手順は、リモート・マウントBBUがあるシステム用です。システムにリモート・マウントBBUがない場合は、「リモート・マウントBBUがないシステムの場合」を参照してください。
root
ユーザーとしてログインします。
サービスを必要とするラックのサーバーで実行されているイメージのバージョンを取得します。
# imageinfo -ver 11.2.3.2.1.130302
例の最初の5つの部分の"11.2.3.2.1"はバージョンです。最後の部分はイメージの日付です。
ディスク・コントローラBBUの取り外しの準備。
バージョン12.1.2.1.0以上を実行している場合:
交換対象のディスク・コントローラBBUを削除します。
DBMCLI> alter dbserver bbu drop for replacement
次のことを確認します。
DBMCLI> list dbserver attributes bbustatus - dropped for replacement
バージョン11.2.3.3.0から12.1.2.1.0を実行している場合:
交換対象のディスク・コントローラBBUを削除します。
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -drop_bbu_for_replacement
次のことを確認します。
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -list_bbu_status BBU status: 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
デフォルトのキャッシュ・ポリシーは、すべてのボリュームで"ライトバック"です。バッテリが正常に機能している場合、現在のキャッシュ・ポリシーは"ライトバック"としてレポートされます。ただし、障害は発生した場合、現在のキャッシュ・ポリシーは"ライトスルー"としてレポートされることがあります。
すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モード(バッテリを使用しない)に設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルーになっていることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
リモート・マウントBBUがないシステムの場合
次の手順は、リモート・マウントBBUがないシステム用です。システムにリモート・マウントBBUがある場合は、「リモート・マウントBBUがあるシステムの場合」を参照してください。
リモート・マウントされたバッテリがシステムに取り付けられていない場合は、バッテリの交換が必要なノードをシャットダウンする必要があります。
すべてのRAIDディスク・ボリュームをライトスルー・モードに戻し、RAIDキャッシュ・メモリーのすべてのデータがディスクにフラッシュされ、バッテリの交換時にデータの損失が発生しないことを確認します。
すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モードに設定します。
注意:
Solarisで実行している場合は、次のコマンドの/opt/MegaRAID/MegaCli/MegaCli64
の代わりに/opt/MegaRAID/MegaCli
を使用します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルー(バッテリーを使用しない)になっていることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
サーバー・オペレーティング・システムをシャットダウンします。
My Oracle Supportノート1093890.1「Exadata構成でExadataおよびRDBMSサービスおよびセル/計算ノードをシャットダウン/起動する手順」の手順を実行します。
データベース・ノードの電源を切断する前に、CRSサービスを停止します。次のコマンドをrootユーザーとして実行します。
# . oraenv ORACLE_SID = [root] ? +ASM1 The Oracle base for ORACLE_HOME=/u01/app/11.2.0/grid is /u01/app/oracle
前述の出力例では、+ASM1
の1
はデータベース・ノード番号を指します。たとえば、ノード3のデータベースでは、値は+ASM3
になります。
# $ORACLE_HOME/bin/crsctl stop crs
または
# <GI_HOME>/bin/crsctl stop crs
<GI_HOME>は、通常は/u01/app/11.2.0/grid
に設定されますが、設定によって変わる場合があります。
CRSが停止していることを確認します。実行中のCRSプロセスはありません。
# ps -ef | grep css
サーバー・オペレーティング・システムをシャットダウンします。
Linux:
# shutdown -hP now
Solaris:
# shutdown -y -i 5 -g 0
この手順では、古いディスク・コントローラ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のラベルが付いたシャーシの背面の左上隅のスロットです。
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: ディスク・コントローラ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インスタンスのレコードと各データベースのレコードが返されます。
この項では、Exadata Storage Serverのディスク・コントローラBBUを交換する方法について説明します。手順の概要は次のとおりです。
注意:
保守手順の終了後は常にExachkツールを使用することをお薦めします。このツールはMy Oracle Supportノート1070954.1から入手できます。
特定の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
デフォルトのキャッシュ・ポリシーは、すべてのボリュームで"ライトバック"です。バッテリが正常に機能している場合、現在のキャッシュ・ポリシーは"ライトバック"としてレポートされます。ただし、障害は発生した場合、現在のキャッシュ・ポリシーは"ライトスルー"としてレポートされることがあります。
すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モード(バッテリを使用しない)に設定します。
# /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 now
Exadata Storage Serverの電源を切断すると、すべてのストレージ・サービスが自動的に停止します。
「手順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の同期化が完了します。このプロセスは、個別のサーバーが修復のために停止している間マシンがビジー、またはビジーであった状態に応じて時間がかかる場合があります。
リリース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を時間内に送信できなくなり、データベース・ノードで破損が発生し、リカバリが遅延する場合があります。
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-5は、構成変更中にセル・ノードとデータベース・ノードをオフラインとオンラインのどちらにしておく必要があるかを示しています。
表1-5 操作時のセルおよびデータベース・ノードの状態
操作 | セル・ノード | データベース・ノード |
---|---|---|
DNSサーバーの更新 |
オンライン |
オンライン |
NTPサーバーの更新 |
オンライン |
オンライン |
タイム・ゾーンの更新 |
オフライン |
オンライン |
管理ネットワークのIPアドレス、ネットマスク、ゲートウェイ、ホスト名の変更 |
オフライン |
オンライン |
クライアント・ネットワークのIPアドレス、ネットマスク、ゲートウェイ、ホスト名の変更 |
オフライン |
オンライン |
ILOM IPアドレスの変更 |
オフライン |
|
その他のILOMパラメータの変更 |
|
|
InfiniBand IP、ネットマスク、ホスト名の変更 |
オフライン |
オンライン |
pkeyの変更 |
オフライン |
オンライン |
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
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」メニュー項目は、ストレージ・サーバーに対して実行した場合にのみ使用できます。「アラート履歴」メニュー項目は、要求した時間枠にアラートが発生した場合にのみ使用できます。
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のチャートを示します。
各チャートの下に、チャート内の特定の時間のドリルダウンに使用できる範囲セレクタがあります。いずれかのチャートの範囲セレクタを移動すると、ページ上のすべてのチャートに影響します。
注意:
範囲セレクタは、スクリーン・リーダーにアクセスできません。また、チャートに表示されるすべての値がスクリーン・リーダーにアクセスできるわけではありません。それぞれのチャートのデータ・ポイントの最初の値のみが該当します。範囲セレクタを使用すると、表示されるチャートが変更されて、範囲セレクタで指定した時間枠のデータのみが表示されます。
IOStat詳細には、ストレージ・サーバーの各ディスクのパフォーマンスが示されます。このページには、次のチャートが表示されます。
表1-7 IO統計詳細の統計
統計 | 説明 |
---|---|
フラッシュ・サービス時間 ハード・ディスク・サービス時間 |
待機時間の範囲に対する、ディスクごとの平均サービス時間。 |
フラッシュ待機時間 ハード・ディスク待機時間 |
ディスクごとの平均待機時間 |
デフォルトでは、チャートには、サーバー上のすべてのディスクの平均を示す線が含まれます。影付きのバックグラウンド・イメージは、統計の最小と最大の範囲を示しています。ドロップダウン・セレクタを使用して、個別のディスクを表示することを選択できます。
バックグラウンド・イメージの範囲が広い場合は、ディスク・パフォーマンスに差異がある可能性があることを示します。このメトリックを使用して、ストレージ・サーバーの個々のディスクをより詳細に確認することで、不均衡が発生しているかどうかを知ることができます。バックグラウンド・イメージの範囲が狭い場合は、ディスクのパフォーマンスが似ていることを示します。
また、ストレージ・サーバーの個別のディスクのIOPとMB/sをデータ・シートの数値と比較して、ディスクが最大容量に達した可能性があるかどうかを確認することもできます。
セル・サーバー統計は、Exadata Storage Serverに固有の機能を追跡する場合に役立ちます。このページには、スマート・フラッシュ・キャッシュおよびスマートIOに関連する統計が示されます。