| Oracle® Exadata Database Machineメンテナンス・ガイド 12c リリース2 (12.2) E84907-03 |
|
 前 |
 次 |
この章のトピックは、次のとおりです:
注意:
読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。
この章のすべての手順は、Oracle Exadata Database MachineおよびOracle Exadata Storage拡張ラックに適用されます。
この項では、Exadata Storage Serverの保守を実行する方法について説明します。次の項目が含まれます。
関連項目:
Oracle ASMディスク修復タイマーの詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドを参照してください。
Exadata Storage Serverの保守を実行する場合、セルの電源切断または再起動が必要になることがあります。1つ以上のデータベースの実行中にExadata Storage Serverを停止する場合、Exadata Storage ServerのオフラインによるOracle ASMディスク・グループおよびデータベース可用性への影響がないことを確認してください。データベース可用性に影響を与えないでExadata Storage Serverをオフラインにする機能は、影響するディスク・グループで使用されるOracle ASM冗長性のレベルおよびオフラインにするExadata Storage Serverのデータのミラー・コピーを含む他のExadata Storage Serverのディスクの現在のステータスによって異なります。
次の手順は、Exadata Storage Serverの電源の切断方法を示しています。
関連トピック
リバランス操作が正しく実行された可能性がある場合。Oracle ASMアラート・ログを確認してください。
リバランス操作が現在実行されている可能性がある場合。GV$ASM_OPERATIONビューを確認して、リバランス操作が実行されているかどうか判別します。
リバランス操作が失敗した可能性がある場合。V$ASM_OPERATION.ERRORビューを確認して、リバランス操作が失敗したかどうか判別します。
交換される物理ディスクに複数のディスク・グループのASMディスクが含まれる場合、複数のディスク・グループのリバランス操作を同じクラスタの異なるOracle ASMインスタンスで実行できます。Oracle ASMインスタンスは、一度に1つのリバランス操作を実行できます。すべてのOracle ASMインスタンスがビジー状態の場合、リバランス操作がキューに入れられます。
注意:
BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata Storage Server Softwareリリース12.1.2.0を実行しているストレージ・サーバーで、Oracle ASMはリバランス操作のステータスについて電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。
ソフトウェアの更新は、patchmgrユーティリティを使用してExadata Storage Serverに適用されます。patchmgrユーティリティにより、Exadata Storage Serverに必要なすべてのソフトウェアとファームウェアがインストールおよび更新されます。patchmgrユーティリティは、My Oracle Supportからダウンロードするソフトウェア・リリースに付属しています。
注意:
Exadata Storage Serverのソフトウェアをインストール、変更、再構成または削除する場合は、このガイド、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』またはMy Oracle Supportに記載されているOracle Exadata固有の指示に必ず従ってください。Exadata Storage Serverに対する変更は、特定のOracle Exadataドキュメントに記載がないかぎりサポートされません。
注意:
My Oracle Supportノート888828.1に説明されているように、Oracle Exadata Cellの通常の更新が適用できるのは、ターゲット・リリースの日付スタンプが現在実行中のリリースの日付スタンプより新しい場合のみです。ターゲット・リリースよりも新しい日付スタンプのリリースを実行しているイメージからの更新はブロックされます。
例: Exadataリリース12.1.2.1.0は、リリース番号に基づいた12.1.1.1.2よりも新しく思えますが、12.1.1.1.2.1 (日付スタンプが150411)の日付スタンプは、12.1.2.1.0 (141206)よりも新しいため、12.1.1.1.2.150411から12.1.2.1.0.141206.1の更新はブロックされます。このような状況では、同じメジャー・リリースで日付スタンプが新しいメンテナンス・リリースに更新する必要があります。
patchmgrユーティリティによるソフトウェアの更新は、構成内のすべてのExadataセルが対象となります。ユーティリティでは、ソフトウェアの更新方法としてローリングと非ローリングの両方がサポートされています。ユーティリティでは、パッチ適用の完了通知やローリング/非ローリング・パッチ適用のステータス情報を電子メール・メッセージで送信できます。次に、電子メール・メッセージを送信するためのコマンドを示します。
# ./patchmgr -cells cell_group -patch [-rolling] [-ignore_alerts] [-unkey] \
[-smtp_from "addr" -smtp_to "addr1 addr2 addr3 ..."]
前述のコマンドのaddrは送信元アドレス、addr1、addr2およびaddr3は送信先アドレスです。
この項では、Exadataセルにパッチを適用する各方法およびそれらの違いについて説明します。この項では、次の項目について説明します。
ローリング更新は、デプロイメント全体での停止時間を伴わない方法としても知られます。
この方法の利点:
データベースの停止時間が不要です。
問題が発生した場合に影響を受けるのは1つのセルのみです。
この方法に関する考慮事項:
非ローリング更新よりもはるかに時間がかかります。セルは一度に1つずつ順番に処理されます。パッチの適用に最低限かかる概算時間は、非ローリング更新で1つのセルにパッチを適用するのにかかる時間にセルの数をかけたものになります。非ローリング更新で1つのセルの更新にかかる時間は約1時間です。ローリング更新を実行した場合、所要時間が非常に長くなる可能性があり、デプロイメントの負荷も大きくなります。このような負荷条件が、パッチ適用後のセルでグリッド・ディスクをアクティブ化および再アクティブ化するのにかかる時間に加算されます。
注意:
patchmgrユーティリティを起動するときは、ソフトウェア更新通知をサブスクライブすることをお薦めします。管理者ユーザーは、ソフトウェア更新がいつ完了するかを確実に知らせる電子メール通知を自動的に受信します。これにより、管理者が手動でセルのリブートを早く行い、ソフトウェア更新プロセスを中断することがなくなります。
Oracle ASMによりセルのグリッド・ディスクが削除されるのを回避するため、パッチ適用時にOracle ASMの修理タイムアウトを増やす必要があります。これらのグリッド・ディスクを再度追加することは、時間のかかる手動での作業になります。ディスク・グループのdisk_repair_timeは最低でもデフォルト値の3.6時間に設定するようにしてください。
注意:
patchmgrユーティリティで-rollingオプションを指定してローリング更新またはロールバックを実行する場合は、My Oracle Supportノート1485475.1に列挙されている修正を事前にOracle Database 11gデータベースに適用してください。修正が必要なデータベース・リリースは、ノートに明記されています。
次に、ローリング更新を使用してExadataセルにパッチを適用する手順を簡単に説明します。これらの手順は、patchmgrユーティリティにより自動的に実行されます。
1つのセル上の非アクティブ化対象のグリッド・ディスクをすべて非アクティブ化します。対象となるグリッド・ディスクのasmdeactivationoutcome属性がYesに設定されます。
非アクティブ化したディスクがOFFLINEであることを確認します。
セルにパッチを適用します。
セルを再起動し、正常に起動したら、非アクティブ化したグリッド・ディスクをアクティブ化します。
Oracle ASMの再同期処理が完了するまで待機し、手順4でアクティブ化したグリッド・ディスクがONLINEになっていることを確認します。
パッチの適用対象となる次のセルに移動し、同じ手順を繰り返します。
patchmgrユーティリティでは、前述の手順が一度に1つのセルに対して実行されます。
非ローリング更新は、デプロイメント全体での停止時間を伴う方法としても知られます。デプロイメント全体で停止するよう選択した場合は、パッチはすべてのセルにパラレルに適用されます。patchmgrユーティリティによりExadataセルにこの機能が提供されます。
この方法の利点:
すべてのセルがパラレルに処理されます。そのため、パッチの適用時間は、適用対象となるセルの数に関係なく、ほぼ一定です。
グリッド・ディスクの非アクティブ化と再アクティブ化に費やす時間がゼロです。
この方法に関する考慮事項:
パッチ適用プロセスの実行中はセルを使用できません。パッチの適用中は、セル・サービスを使用するすべてのデータベースを停止したままにする必要があります。
パッチの適用中にセルの1つで問題が発生した場合は、そのセルの問題が解決するまでデプロイメント全体が使用できなくなります。通常、Oracle Clusterwareを排他モードで起動し、Oracle ASMのディスク・グループをFORCEオプションによってマウントし、その後で問題のあるセルのグリッド・ディスクを削除することによって、データベースを起動することは可能です。ただし、これらの手順を実行することによって、停止時間がさらに延びます。
Exadata Storage Serverの最初の2枚のディスクは、システム・ディスクです。Oracle Exadata Storage Server Softwareシステム・ソフトウェアは、各システム・ディスクに割り当てられます。システム・ディスクのこの割り当てられた部分は、システム領域と呼ばれます。システム・ディスクのシステム領域以外は、データ・パーティションと呼ばれ、通常のデータ・ストレージに使用されます。セルの他のすべてのディスクは、データ・ディスクと呼ばれます。
CellCLI LIST PHYSICALDISKコマンドで属性を確認して、物理ディスクを監視できます。たとえば、物理ディスクのステータスが"failed" (以前のリリースでは、障害が発生した物理ディスクのステータスは"critical"でした)または"warning - predictive failure"と同等の場合、問題が発生している可能性があり、交換が必要です。内部しきい値を超えると、ディスク・ファームウェアによってエラー・カウンタが保守され、ドライブはPredictive Failureとマーク付けされます。交換が必要かどうかは、セル・ソフトウェアではなくドライブによって決定されます。
ディスクI/Oエラーが発生すると、Oracle ASMはメディア・エラーによる読取りエラーの障害範囲の修理を実行します。ディスクはオンラインのままで、アラートは送信されません。Oracle ASMが物理的に対処されたメタデータ・ブロックに関する読取りエラーを取得すると、ブロックはミラーリングされず、ディスクはオフラインになります。Oracle ASMは強制的にディスクを削除します。
表3-1に、Exadata Storage Serverの物理ディスク・ステータスを示します。
表3-1 Exadata Storage Serverの物理ディスク・ステータス
| Oracle Exadata Storage Server Softwareリリース | 物理ディスク・ステータス |
|---|---|
リリース11.2.3.3以上 |
正常 正常 - 交換のため切断 正常 - 制限されたオンライン 正常 - 制限されたオンライン - 交換のため切断 存在しない 失敗 障害 - 交換のため切断 障害 - 不適切なディスク・モデルのため拒否 障害 - 不適切なディスク・モデルのため拒否 - 交換のため切断 障害 - 間違ったスロットのため拒否 障害 - 間違ったスロットのため拒否 - 交換のため切断 警告 - 制限されたオンライン 警告 - 制限されたオンライン - 交換のため切断 警告 - ピア障害 警告 - 低いパフォーマンス 警告 - 低いパフォーマンス - 交換のため切断 警告 - 低いパフォーマンス、ライトスルー・キャッシュ 警告 - 予測障害、低いパフォーマンス 警告 - 予測障害、低いパフォーマンス - 交換のため切断 警告 - 予測障害、ライトスルー・キャッシュ 警告 - 予測障害 警告 - 予測障害 - 交換のため切断 警告 - 予測障害、低いパフォーマンス、ライトスルー・キャッシュ 警告 - ライトスルー・キャッシュ |
リリース11.2.3.2 |
正常 正常 - 制限されたオンライン 存在しない 失敗 障害 - 不適切なディスク・モデルのため拒否 障害 - 間違ったスロットのため拒否 警告 - 制限されたオンライン 警告 - ピア障害 警告 - 低いパフォーマンス 警告 - 低いパフォーマンス、ライトスルー・キャッシュ 警告 - 予測障害、低いパフォーマンス 警告 - 予測障害、ライトスルー・キャッシュ 警告 - 予測障害 警告 - 予測障害、低いパフォーマンス、ライトスルー・キャッシュ 警告 - ライトスルー・キャッシュ |
リリース11.2.3.1.1以下 |
正常 予測障害 低いパフォーマンス critical 存在しない |
リリース11.2.3.2.0以上のOracle Exadata Storage Server Softwareでは、ディスクが交換可能であることを示すアラートが送信され、ディスクの外部にすべてのデータがリバランスされた後にそのディスクが予測障害を持つ場合、青色のLEDが点灯します。11.2.3.2.0より前のリリースでは、ディスクが予測障害を持つ場合、青色のLEDではなく、黄色のLEDが点灯しました。このような場合、ディスクの交換を進める前に、すべてのデータがそのディスクの外部にリバランスされたかどうかを手動でチェックする必要があります。
ディスクで障害が発生すると、ドライブの青色のLEDと黄色のLEDが両方とも点灯し、この場合、ディスクの交換を進めてもかまいません。動作はすべてのリリースで同じです。ただし、ドライブのLEDはリリース11.2.3.2.0では点灯したままになるのに対し、以前のリリースでは点滅します。
注意:
Exadata Storage Serverの物理ディスクを交換中、Oracle Exadataラックはオンラインで使用可能です。
この項では、次の項目について説明します。
関連項目:
予測障害および低いパフォーマンスのLEDステータス・ライトの詳細は、「LEDステータスの説明」を参照してください。
LIST PHYSICALDISKコマンドの詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドを参照してください。
修復タイマーの設定の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。
保守のベスト・プラクティスの詳細は、http://www.oracle.com/goto/maaのOracle Maximum Availability Architecture(MAA)Webサイトを参照してください。
My Oracle Supportノート1084360.1のExadata環境の計算ノードのベア・メタル・リストア手順に関する項
各Exadata Storage Serverのハード・ディスク・コントローラは、定期的にコントローラのバッテリの放電と充電を実行します。操作中は、書込みキャッシュ・ポリシーにより、ライトバック・キャッシュからライトスルー・キャッシュに変更されます。ライトスルー・キャッシュ・モードはライトバック・キャッシュ・モードより時間を要します。ただし、Exadata Storage Serverの電源が落ちたり障害が発生したりすると、ライトバック・キャッシュ・モードの場合はデータ損失のリスクがあります。リリース11.2.1.3より前のExadata Storage Serverリリースの場合、この処理は毎月発生します。リリース11.2.1.3.0以上のOracle Exadata Storage Server Softwareの場合、この処理は3か月ごとに発生します(例: 1月、4月、7月、10月の17日の01:00時)。学習サイクルの開始時間を変更するには、次のようなコマンドを使用します。サイクルが終了すると、時間はデフォルト学習時間に戻ります。
CellCLI> ALTER CELL bbuLearnCycleTime="2013-01-22T02:00:00-08:00"
次の学習サイクル時間を確認するには、次のコマンドを使用します。
CellCLI> LIST CELL ATTRIBUTES bbuLearnCycleTime
Exadata Storage Serverによって、次のようなセル上の論理ドライブのキャッシュ・モードの状態に関するアラート情報が生成されます。
HDD disk controller battery on disk contoller at adapter 0 is going into a learn cycle. This is a normal maintenance activity that occurs quarterly and runs for approximately 1 to 12 hours. The disk controller cache might go into WriteThrough caching mode during the learn cycle. Disk write throughput might be temporarily lower during this time. The message is informational only, no action is required.
バッテリのステータスを確認するには、次のコマンドを使用します。
# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -a0
次に、コマンドの出力例を示します。
BBU status for Adapter: 0 BatteryType: iBBU08 Voltage: 3721 mV Current: 541 mA Temperature: 43 C BBU Firmware Status:Charging Status : ChargingVoltage : OK Temperature : OK Learn Cycle Requested : No Learn Cycle Active : No Learn Cycle Status : OK Learn Cycle Timeout : No I2c Errors Detected : No Battery Pack Missing : No Battery Replacement required : No Remaining Capacity Low : Yes Periodic Learn Required : No Transparent Learn : No Battery state: GasGuageStatus: Fully Discharged : No Fully Charged : No Discharging : No Initialized : No Remaining Time Alarm : Yes Remaining Capacity Alarm: No Discharge Terminated : No Over Temperature : No Charging Terminated : No Over Charged : NoRelative State of Charge: 7 %Charger System State: 1 Charger System Ctrl: 0 Charging current: 541 mAAbsolute state of charge: 0 %Max Error: 0 % Exit Code: 0x00
物理ディスクの停止により、パフォーマンスの低下およびデータの冗長性が発生する場合があります。したがって、すぐにディスクを新しいディスクに交換する必要があります。ディスクに障害が発生すると、物理ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションで自動的に削除され、Oracle ASMリバランスでデータの冗長性がリストアされます。
ディスクに障害が発生すると、Exadataアラートが生成されます。アラートには、ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合、電子メールでアラートが指定したアドレスに送信されます。
物理ディスクを交換すると、そのスロットの前のディスクにあったグリッド・ディスクとセル・ディスクは新しい物理ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMグループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。
注意:
BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata Storage Server Softwareリリース12.1.2.0を実行しているストレージ・サーバーで、Oracle ASMはリバランス操作のステータスについて電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。
以前のリリースについては、「リバランス操作のステータスのチェック」の説明に従ってリバランス操作ステータスをチェックしてください。
まれに、自動ファームウェア更新が機能せず、LUNが再構築されない場合があります。これは、ms-odl.trcファイルをチェックして確認できます。
関連項目:
V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
リバランス操作の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
ディスクがwarning - predictive failureステータスのため、物理ディスクの交換が必要な場合があります。predictive failureステータスは、物理ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。物理ドライブのグリッド・ディスクに関連するOracle ASMディスクが自動的に削除され、Oracle ASMリバランスで障害が発生する可能性のあるディスクから他のディスクにデータが移動されます。
物理ドライブが故障する前に削除を完了できなかった場合は、「ディスク障害による物理ディスクの交換」を参照してください。
ディスクを削除すると、アラートが送信されます。物理ディスクを交換すると、スロットの前のディスクにあったグリッド・ディスクとセル・ディスクは新しい物理ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。
注意:
BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata Storage Server Softwareリリース12.1.2.0を実行しているストレージ・サーバーで、Oracle ASMはリバランス操作のステータスについて電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。
以前のリリースについては、「リバランス操作のステータスのチェック」の説明に従ってリバランス操作ステータスをチェックしてください。
次の手順は、ディスクの問題によるディスクの交換方法を示しています。
関連項目:
V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
リバランス操作のチューニングの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
V$ASM_DISK_STATビューの問合せの詳細は、『Oracle Databaseリファレンス』を参照してください。
『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』のALTER CELL VALIDATE CONFIGURATIONコマンドに関する項
1つの不良物理ディスクが、他の正常なディスクのパフォーマンスを低下させることがあります。不良ディスクはそのままにしないでシステムから削除する必要があります。リリース11.2.3.2以上では、パフォーマンスの低いディスクが自動的に識別され、アクティブな構成から削除されます。その後、Oracle Exadata Database Machineにより一連のパフォーマンス・テストが実行されます。CELLSRVでパフォーマンスの低いディスクが検出されると、セル・ディスクのステータスがnormal - confinedOnlineに変更され、物理ディスクのステータスがwarning - confinedOnlineに変更されます。次の状況はディスク制限のトリガーとなります。
ディスクの応答停止。ストレージ・アラート・ログ内の原因コードはCD_PERF_HANGです。
セル・ディスクの速度低下。次に例を示します。
サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_ABS)
相対的サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_RLTV)
読取りまたは書込みでの長期待機時間。次に例を示します。
書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_WT)
読取りでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RD)
読取りおよび書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RW)
頻繁に発生する個々のI/Oでの絶対的待機時間が非常に長い(原因コードCD_PERF_SLOW_LAT_ERR)
I/Oエラーなどのエラー(原因コードCD_PERF_IOERR)。
ディスクの問題が一時的なものであり、テストに合格した場合は、そのディスクは構成に戻されます。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、ASRによりディスク交換のためのサービス・リクエストが送信されます。可能な場合は、Oracle ASMによりグリッド・ディスクがテスト用にオフラインに変更されます。Oracle ASMがディスクをオフラインに変更できない場合、セル・ディスクのステータスは、ディスクを安全にオフラインに変更できるようになるまで、normal - confinedOnlineのまま変わりません。
ディスクのステータスの変更は、セルのアラート履歴にある次のエントリに関連付けられています。
MESSAGE ID date_time info "Hard disk entered confinement status. The LUN n_m changed status to warning - confinedOnline. CellDisk changed status to normal - confinedOnline. Status: WARNING - CONFINEDONLINE Manufacturer: name Model Number: model Size: size Serial Number: serial_number Firmware: fw_release Slot Number: m Cell Disk: cell_disk_name Grid Disk: grid disk 1, grid disk 2 ... Reason for confinement: threshold for service time exceeded"
ストレージ・セルのアラート・ログには次の情報が記録されます。
CDHS: Mark cd health state change cell_disk_name with newState HEALTH_BAD_
ONLINE pending HEALTH_BAD_ONLINE ongoing INVALID cur HEALTH_GOOD
Celldisk entering CONFINE ACTIVE state with cause CD_PERF_SLOW_ABS activeForced: 0
inactiveForced: 0 trigger HistoryFail: 0, forceTestOutcome: 0 testFail: 0
global conf related state: numHDsConf: 1 numFDsConf: 0 numHDsHung: 0 numFDsHung: 0
...
次の手順は、不良ディスクが確認された場合の物理ディスクの取外し方法を示しています。
関連項目:
Oracle Exadata Storage Server Softwareユーザーズ・ガイド
ディスク・グループからのディスクの削除の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
Exadata Storageソフトウェアには、物理ディスクで障害が発生したか、問題のあるディスクとしてフラグが付けられた場合に物理ディスクを保守するための、自動化された完全な一連の操作が備えられています。ただし、物理ディスクを事前に構成から取り外す必要がある場合があります。
CellCLIのALTER PHYSICALDISKコマンドでは、drop for replacementオプションによって、データ損失のリスクなく安全に、正常に機能している物理ディスクを削除できるかどうかが確認されます。ただし、コマンドを実行した後、ストレージ・セルで物理ディスクのグリッド・ディスクが非アクティブ化され、Oracle ASMディスク・グループでオフラインに設定されます。
物理ディスクが交換または再有効化され、後続のリバランスが完了するまで、ディスク・グループの冗長性が損なわれます。このことは、標準冗長性を使用するディスク・グループにおいて特に重要です。
ディスク・グループで十分な冗長性を確保できないリスクを抑えて、事前に物理ディスクを交換するには、次の手順を実行します。
Exadata Storage Serverから別のExadata Storage Serverへのすべてのドライブの移動が必要になることがあります。この作業が必要になるのは、マザーボードやILOM障害などのシャーシ・レベルのコンポーネント障害がある場合またはハードウェアの問題のトラブルシューティングを行う場合です。
次の手順は、ドライブの移動方法を示しています。
関連項目:
Oracle Exadata Database Machine Oracle Auto Service Requestクイック・インストレーション・ガイド
Oracle Exadata Storage Server Softwareユーザーズ・ガイド
CellCLIユーティリティの詳細ディスク修復時間の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
ディスクのすべてのデータを削除し、別の目的でディスクを使用できます。これを実行する前に、ディスクのデータをコピーしてください。
次の手順は、ディスクの再利用方法を示しています。
関連トピック
データはExadataセル間でミラー化され、書込み操作が少なくとも2つのストレージ・セルに送信されます。1つのExadata Storage Serverのフラッシュ・カードに問題が発生すると、別のExadata Storage Serverのミラー化されたデータによって読取りおよび書込み操作が実行されます。アプリケーションでサービスの中断は発生しません。
フラッシュ・カードに障害が発生すると、Oracle Exadata Storage Server Softwareは、残存ミラーからデータを読み取り、フラッシュ・キャッシュのデータを確認します。次に、フラッシュ・カードに障害が発生したセルにデータが書き込まれます。障害が発生したフラッシュ・キャッシュ内での損失データの場所が、Oracle Exadata Storage Server Softwareによってフラッシュの障害発生時に保存されます。損失データをミラー・コピーに置き換えることにより、復元が開始されます。復元中、グリッド・ディスクのステータスはACTIVE -- RESILVERING WORKINGになります。
この項では、フラッシュ・ディスクの保守を実行する方法について説明します。次の項目が含まれます。
Exadata Storage Serverには、それぞれフラッシュ・デバイスが付属しています。フラッシュ・デバイスはExtreme Flashセルではホットプラグ対応ですが、High Capacityセルでは対応していません。High Capacityセルでは、交換前にセルの電源を切る必要があります。
障害が発生したフラッシュ・ディスクを確認するには、次のコマンドを使用します。
CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS=failed DETAIL
Extreme Flashセルからの出力例を次に示します。
name: NVME_10
deviceName: /dev/nvme7n1
diskType: FlashDisk
luns: 0_10
makeModel: "Oracle NVMe SSD"
physicalFirmware: 8DV1RA13
physicalInsertTime: 2016-09-28T11:29:13-07:00
physicalSerial: CVMD426500E21P6LGN
physicalSize: 1.4554837569594383T
slotNumber: 10
status: failed
次に、Sun Flash Accelerator F20 PCIeカードからの出力例を示します。
CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS=failed DETAIL
name: FLASH_5_3
diskType: FlashDisk
luns: 5_3
makeModel: "Sun Flash Accelerator F20 PCIe Card"
physicalFirmware: D20Y
physicalInsertTime: 2012-05-14T17:44:14-07:00
physicalSerial: 1030M03UYM
physicalSize: 22.8880615234375G
slotNumber: "PCI Slot: 5; FDOM: 3"
status: failed
次に、Sun Flash Accelerator F40 PCIeカードからの出力例を示します。
name: FLASH_5_3
diskType: FlashDisk
luns: 5_3
makeModel: "Sun Flash Accelerator F40 PCIe Card"
physicalFirmware: TI35
physicalInsertTime: 2012-07-13T15:40:59-07:00
physicalSerial: 5L002X4P
physicalSize: 93.13225793838501G
slotNumber: "PCI Slot: 5; FDOM: 3"
status: failed
F20およびF40 PCIeカードの場合、nameおよびslotNumber属性は、PCIスロットおよびFDOM番号を示します。
Extreme Flashセルの場合、slotNumber属性は、前面パネルのNVMeスロットを示します。
フラッシュ・ディスクの障害が検出されると、フラッシュ・ディスクとそのLUNで障害が発生したことを示すアラートが生成されます。アラート・メッセージには、PCIスロット番号とFDOM番号か、またはNVMeスロット番号が含まれています。これらの番号により、フィールド交換可能ユニット(FRU)が一意に識別されます。システムのアラート通知を構成している場合は、指定したアドレスにアラートが電子メール・メッセージで送信されます。
フラッシュ・ディスクの停止により、パフォーマンスの低下およびデータの冗長性が発生する場合があります。できるだけすぐに障害が発生したディスクを新しいフラッシュ・ディスクに交換する必要があります。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、セルの有効なキャッシュ・サイズが縮小します。フラッシュ・ログにフラッシュ・ディスクを使用する場合、ディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、FORCEオプションによってグリッド・ディスクに関連するOracle ASMディスクがOracle ASMディスク・グループから自動的に削除され、Oracle ASMリバランスでデータの冗長性のリストアが開始されます。
次の手順は、High Capacityセルでの、ディスク障害によるFDOMの交換方法を示しています。Extreme FlashセルでのNVMeドライブの交換は、物理ディスクの交換と同様に、前面パネルからNVMeドライブを取り外して新しいものを挿入するのみです。セルを停止する必要はありません。
新しいフラッシュ・ディスクがシステムによって自動的に使用されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。
関連項目:
部品情報およびサービス・ガイドのリンクは、「Exadata Storage Serverの部品」を参照してください。
V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
ASM_POWER_LIMITの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
CellCLIユーティリティの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください
「関連ドキュメント」に記載されている、ご使用のシステムに適したPCIeカード・ユーザーズ・ガイド
Exadata Storage Serverには、4枚のPCIeカードが付属しています。各カードに4個のフラッシュ・ディスク(FDOM)があり、合計16個のフラッシュ・ディスクが提供されます。4枚のPCIeカードは、PCIスロット番号1、2、4および5にあります。PCIeカードはホットプラグ対応ではありません。フラッシュ・ディスクまたはカードを交換する前にExadata Storage Serverの電源を切断する必要があります。
ディスクが次のステータスのいすれかになるため、フラッシュ・ディスクの交換が必要な場合があります。
警告 - 予測障害
警告 - 低いパフォーマンス
警告 - ライトスルー・キャッシュ
警告 - ピア障害
注意:
リリース11.2.3.2.2より前のリリースでは、ステータスはnot presentです。
フラッシュ・ディスクのpredictive failureステータスは、フラッシュ・ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、引き続きフラッシュ・キャッシュとして使用されます。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクに関連するOracle ASMディスクが自動的に削除され、Oracle ASMリバランスで障害が発生する可能性のあるディスクから他のディスクにデータが移動されます。
フラッシュ・ディスクのpoor performanceステータスは、フラッシュ・ディスクのパフォーマンスが非常に低く、できるだけすぐに交換する必要があることを示します。リリース11.2.3.2以上では、パフォーマンスの低いディスクが自動的に識別され、アクティブな構成から削除されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクからフラッシュ・キャッシュが削除され、Exadata Storage Serverの有効なフラッシュ・キャッシュ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、このフラッシュ・ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションによって可能な場合に自動的に削除されます。オフライン・パートナのためにDROP...FORCEが失敗した場合、通常グリッド・ディスクが自動的に削除され、Oracle ASMリバランスでパフォーマンスの低いディスクから他のディスクにデータが移動されます。
その後、Oracle Exadata Database Machineにより一連のパフォーマンス・テストが実行されます。CELLSRVでパフォーマンスの低いディスクが検出されると、セル・ディスクのステータスがnormal - confinedOnlineに変更され、物理ディスクのステータスがwarning - confinedOnlineに変更されます。次の状況はディスク制限のトリガーとなります。
ディスクの応答停止。ストレージ・アラート・ログ内の原因コードはCD_PERF_HANGです。
セル・ディスクの速度低下。次に例を示します。
サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_ABS)
相対的サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_RLTV)
読取りまたは書込みでの長期待機時間。次に例を示します。
書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_WT)
読取りでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RD)
読取りおよび書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RW)
頻繁に発生する個々のI/Oでの絶対的待機時間が非常に長い(原因コードCD_PERF_SLOW_LAT_ERR)
I/Oエラーなどのエラー(原因コードCD_PERF_IOERR)。
ディスクの問題が一時的なものであり、テストに合格した場合は、そのディスクは構成に戻されます。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、ASRによりディスク交換のためのサービス・リクエストが送信されます。可能な場合は、Oracle ASMによりグリッド・ディスクがテスト用にオフラインに変更されます。Oracle ASMがディスクをオフラインに変更できない場合、セル・ディスクのステータスは、ディスクを安全にオフラインに変更できるようになるまで、normal - confinedOnlineのまま変わりません。
ディスクのステータスの変更は、セルのアラート履歴にある次のエントリに関連付けられています。
MESSAGE ID date_time info "Hard disk entered confinement status. The LUN n_m changed status to warning - confinedOnline. CellDisk changed status to normal - confinedOnline. Status: WARNING - CONFINEDONLINE Manufacturer: name Model Number: model Size: size Serial Number: serial_number Firmware: fw_release Slot Number: m Cell Disk: cell_disk_name Grid Disk: grid disk 1, grid disk 2 ... Reason for confinement: threshold for service time exceeded"
ストレージ・セルのアラート・ログには次の情報が記録されます。
CDHS: Mark cd health state change cell_disk_name with newState HEALTH_BAD_
ONLINE pending HEALTH_BAD_ONLINE ongoing INVALID cur HEALTH_GOOD
Celldisk entering CONFINE ACTIVE state with cause CD_PERF_SLOW_ABS activeForced: 0
inactiveForced: 0 trigger HistoryFail: 0, forceTestOutcome: 0 testFail: 0
global conf related state: numHDsConf: 1 numFDsConf: 0 numHDsHung: 0 numFDsHung: 0
...
注意:
11.2.3.2より前のリリースでは、CALIBRATEコマンドを使用して不良フラッシュ・ディスクを識別し、各フラッシュ・ディスクについてスループットやIOPSが極端に低くないか調べてください。
フラッシュ・ディスクのパフォーマンスが非常に低い場合、poor performanceとしてマークされます。該当するフラッシュ・ディスクのフラッシュ・キャッシュが自動的に無効になり、そのフラッシュ・ディスクのグリッド・ディスクがOracle ASMディスク・グループから自動的に削除されます。
フラッシュ・ディスクのwrite-through cachingステータスは、PCIeカードのデータ・キャッシュのサポートに使用するキャパシタに障害が発生したため、できるだけすぐにカードを交換する必要があることを示します。
フラッシュ・ディスクのpeer failureステータスは、同じSun Flash Accelerator PCIeカードのいずれかのフラッシュ・ディスクに障害または問題が発生したことを示します。たとえば、FLASH_5_3に障害が発生すると、FLASH_5_0、FLASH_5_1およびFLASH_5_2がpeer failureステータスになります。次に、例を示します。
CellCLI> LIST PHYSICALDISK
36:0 L45F3A normal
36:1 L45WAE normal
36:2 L45WQW normal
...
FLASH_5_0 5L0034XM warning - peer failure
FLASH_5_1 5L0034JE warning - peer failure
FLASH_5_2 5L002WJH warning - peer failure
FLASH_5_3 5L002X4P failed
CellSRVにより、ライトバック・フラッシュ・キャッシュに使用されているフラッシュ・ディスクで予測障害またはピア障害が検出され、不良FDOMが1つのみの場合は、その不良FDOMのデータが復元され、残りの3つのFDOMのデータはフラッシュされます。その後、有効なグリッド・ディスクが存在する場合、CellSRVはディスクに対してOracle ASMリバランスが開始します。不良ディスクは、作業が完了するまで交換できません。ディスク交換が可能になると、MSによりアラートが送信されます。
X5以降のシステムでは、High Capacity上の各フラッシュ・カードおよびExtreme Flash上の各フラッシュ・ドライブはFRUです。これは、これらのシステムにはピア障害がないことを意味します。
X3およびX4システムでは、フラッシュ・カード自体がFRUであるため、いずれかのFDOMが失敗した場合、セル・ソフトウェアによってそのカード上の残りのFDOMが自動的にピア障害に設定され、フラッシュ・カードの交換の準備のためにデータを移動することができます。
V2およびX2システムでは、各FDOMはFRUです。これらのシステムのフラッシュにはピア障害がありません。
フラッシュ・ディスクが1つのため、フラッシュ・ディスクがpredictive failureになると、データがコピーされます。グリッド・ディスクにフラッシュ・ディスクを使用する場合、Oracle ASMと関連パートナが再びパートナになり、リバランスが実行されます。ライトバック・フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクからグリッド・ディスクにデータがフラッシュされます。
predictive failureのフラッシュ・ディスクを確認するには、次のコマンドを使用します。
CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS= \
'warning - predictive failure' DETAIL
name: FLASH1_2
diskType: FlashDisk
luns: 1_2
makeModel: "Sun Flash Accelerator F20 PCIe Card"
physicalFirmware: D20Y
physicalInsertTime: 2012-09-27T13:11:16-07:00
physicalSerial: 508002000092e70FMOD2
physicalSize: 22.8880615234375G
slotNumber: "PCI Slot: 1; FDOM: 2"
status: warning - predictive failure
poor performanceのフラッシュ・ディスクを確認するには、次のコマンドを使用します。
CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS= \
'warning - poor performance' DETAIL
name: FLASH1_4
diskType: FlashDisk
luns: 1_4
makeModel: "Sun Flash Accelerator F20 PCIe Card"
physicalFirmware: D20Y
physicalInsertTime: 2012-09-27T13:11:16-07:00
physicalSerial: 508002000092e70FMOD2
physicalSize: 22.8880615234375G
slotNumber: "PCI Slot: 1; FDOM: 3"
status: warning - poor performance
フラッシュ・ディスクがpredictive failure、poor performance、write-through cachingまたはpeer failureステータスの場合、アラートが生成されます。アラートには、フラッシュ・ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合、電子メール・メッセージでアラートが指定したアドレスに送信されます。
ディスク交換にいつ進むかの決定は、次に示されているように、リリースによって異なります。
11.2.3.2より前のリリースの場合:
フラッシュ・ディスクの交換に進む前にV$ASM_DISK_STATビューの問合せを実行してOracle ASMディスクが正常に削除されるまで待機します。フラッシュ・ディスクで障害が発生する前に通常の削除を完了できなかった場合、FORCEオプションによってOracle ASMディスク・グループからOracle ASMディスクが自動的に削除されます。フラッシュ・ディスクで障害が発生する前にDROPコマンドが完了しなかった場合は、「フラッシュ・ディスク障害によるフラッシュ・ディスクの交換」を参照してください。
リリース11.2.3.2以上の場合:
Oracle ASMディスクが削除されている場合は、アラートが送信され、フラッシュ・ディスクを安全に交換できます。フラッシュ・ディスクをライトバック・フラッシュ・キャッシュに使用する場合、フラッシュ・ディスクによってキャッシュされるグリッド・ディスクがなくなるまで待機します。すべてのグリッド・ディスクのcachedBy属性をチェックするには、次のコマンドを使用します。フラッシュ・ディスクのセル・ディスクは、グリッド・ディスクのcachedBy属性には表示されません。
CellCLI> LIST GRIDDISK ATTRIBUTES name, cachedBy
フラッシュ・ディスクをグリッド・ディスクとフラッシュ・キャッシュの両方に使用する場合は、アラートを受信し、セル・ディスクがグリッド・ディスクのcachedBy属性に表示されなくなるまで待機します。
次の手順は、ディスクの問題によるHigh Capacityセルでのフラッシュ・ディスクの交換方法を示しています。Extreme Flashセルでは、前面パネルからドライブを取り外して新しいものを挿入するのみです。セルを停止する必要はありません。
新しいフラッシュ・ディスクがシステムによって自動的に使用されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。
関連項目:
部品番号情報およびサービス・ガイドのリンクは、「Exadata Storage Serverの部品」を参照してください。
V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
ASM_POWER_LIMITの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
CellCLIユーティリティの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください
「関連ドキュメント」に記載されている、ご使用のシステムに適したPCIeカード・ユーザーズ・ガイド
リリース11.2.3.2.1以上では、Exadataスマート・フラッシュ・キャッシュにより、頻繁にアクセスするデータを高速のソリッド状態の記憶装置に透過的にキャッシュして、問合せの応答時間とスループットを向上させることができます。ディスクではなくフラッシュによって処理される書込み操作は、「ライトバック・フラッシュ・キャッシュ」と呼ばれます。この機能は必要に応じて有効または無効にできます。フラッシュ・キャッシュ・モードを変更する場合は、次の点に注意してください。
ストレージ・セル・ソフトウェアのリリース11.2.3.3.1以上では、セルのサービスを停止する必要も、グリッド・ディスクを非アクティブ化する必要もありません。
ライトバック・フラッシュ・キャッシュを使用するには、GridホームとOracle DatabaseホームがOracle Database 11gリリース11.2.0.3 BP9以上であることが必要です。
注意:
フラッシュ・キャッシュを削除し、再作成すると、キャッシュがウォームアップするまで、データベースの再起動の際にパフォーマンスに影響を与える可能性があります。
この項では、次の項目について説明します。
リリース11.2.3.2.1以上では、Exadataスマート・フラッシュ・キャッシュにより、頻繁にアクセスするデータを高速のソリッド状態の記憶装置に透過的にキャッシュして、問合せの応答時間とスループットを向上させることができます。ディスクではなくフラッシュによって処理される書込み操作は、「ライトバック・フラッシュ・キャッシュ」と呼ばれます。この機能は必要に応じて有効または無効にできます。フラッシュ・キャッシュ・モードを変更する場合は、次の点に注意してください。
flashCacheMode属性を変更する前に、セル・サービスをシャットダウンする必要があります。セル・サービスは、ローリング形式または全体シャットダウンとしてシャットダウンできます。
変更をローリング形式で行う場合は、セル・サービスの再同期が完了していることを確認してから、次のセルを変更してください。
フラッシュ・キャッシュ・モードをローリング形式で変更する場合は、次のセルに移る前に、現在のセルのすべてのグリッド・ディスクでasmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。グリッド・ディスクの属性をチェックするには、次のコマンドを使用します。
LIST GRIDDISK ATTRIBUTES asmDeactivationOutcome, asmModeStatus
変更を非ローリング形式で行う場合は、クラスタ全体を停止してから、変更を開始してください。
フラッシュ・キャッシュ・モードを非ローリング形式で変更する場合は、Oracle Clusterware CRSとすべてのデータベースを含め、クラスタ全体を停止してください。
ライトバック・フラッシュ・キャッシュを使用するには、GridホームとOracle DatabaseホームがOracle Database 11gリリース11.2.0.3 BP9以上であることが必要です。
注意:
フラッシュ・キャッシュを削除し、再作成すると、キャッシュがウォームアップするまで、データベースの再起動の際にパフォーマンスに影響を与える可能性があります。
この項では、次の項目について説明します。
属性をwritethroughからwritebackに変更する場合は、属性を変更する前にフラッシュ・キャッシュを削除する必要があります。次の手順では、ライトバック・フラッシュ・キャッシュをローリング形式で有効にする方法について説明します。
注意:
ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。
関連項目:
My Oracle Supportノート888828.1には、Oracle Exadata Storage Server Software、Grid InfrastructureホームおよびOracle Databaseホームの最小リリース要件がまとめられています。
属性をwritethroughからwritebackに変更する場合は、属性を変更する前にフラッシュ・キャッシュを削除する必要があります。次の手順では、ライトバック・フラッシュ・キャッシュを非ローリング形式で有効にする方法について説明します。
注意:
ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。
関連項目:
My Oracle Supportノート888828.1には、Oracle Exadata Storage Server Software、Grid InfrastructureホームおよびOracle Databaseホームの最小リリース要件がまとめられています。
flashCacheMode属性をwritebackからwritethroughに変更したときに、既存のフラッシュ・キャッシュが存在していると、エラーが表示されます。属性をwritethroughに変更する前に、フラッシュ・キャッシュをフラッシュして削除する必要があります。フラッシュ操作が開始されると、フラッシュ・キャッシュへのすべてのキャッシュが停止されます。次の手順では、ライトバック・フラッシュ・キャッシュをローリング形式で無効にする方法について説明します。
注意:
ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。
ライトバック・フラッシュ・キャッシュを無効にする最初のセルにrootユーザーとしてログインします。
次のコマンドを使用して、セルのすべてのグリッド・ディスクのasmDeactivationOutcome属性がyesになっていることを確認します。
# dcli -g cell_group -l root cellcli -e "LIST GRIDDISK WHERE \ asmdeactivationoutcome != 'Yes' attributes name, asmdeactivationoutcome, \ asmmodestatus"
グリッド・ディスクが返された場合は、手順を進める前にこの問題を解決する必要があります。
次のコマンドを使用して、フラッシュ・キャッシュ内のダーティ・データの量をチェックします。
# dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES \ name,metricvalue WHERE name LIKE \'FC_BY_DIRTY.*\'"
次のコマンドを使用して、フラッシュ・キャッシュをフラッシュします。
# dcli -g cell_group -l root cellcli -e ALTER FLASHCACHE ALL FLUSH
次のコマンドを使用して、フラッシュ・キャッシュのステータスをチェックします。
# dcli -g cell_group -l root cellcli -e LIST CELLDISK ATTRIBUTES name, \ flushstatus, flusherror | grep FD
フラッシュが完了すると、ステータスがcompletedになります。
1セルずつ、すべてのセルに次の一連の手順を実行します。つまり、すべてのセルが完了するまで、1つのセルに手順(a)から(i)を実行した後、別のセルにそれらを実行します。
次のコマンドを使用して、フラッシュ・キャッシュを削除します。
# cellcli -e DROP FLASHCACHE
次のコマンドを使用して、セルのグリッド・ディスクをすべて非アクティブ化します。
# cellcli -e ALTER GRIDDISK ALL INACTIVE
次のコマンドを使用して、CELLSRVサービスを停止します。
# cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV
次のコマンドを使用して、flashCacheMode属性をwritethroughに設定します。
# cellcli -e "ALTER CELL FLASHCACHEMODE=writethrough"
次のコマンド使用して、セル・サービスを再起動します。
# cellcli -e ALTER CELL STARTUP SERVICES CELLSRV
次のコマンドを使用して、セルのグリッド・ディスクを再アクティブ化します。
# cellcli -e ALTER GRIDDISK ALL ACTIVE
次のコマンドを使用して、フラッシュ・キャッシュを再作成します。
# cellcli -e CREATE FLASHCACHE ALL
次のコマンドを使用して、セルのステータスをチェックします。
# cellcli -e LIST CELL DETAIL | grep flashCacheMode
次のコマンドを使用して、グリッド・ディスクのasmDeactivationOutcome属性とasmModeStatus属性をチェックします。
# cellcli -e LIST GRIDDISK ATTRIBUTES name,status,asmdeactivationoutcome,asmmodestatus
asmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。
ディスク・ステータスがSYNCINGの場合は、続行せずにACTIVEになるまで待ちます。
flashCacheMode属性をwritebackからwritethroughに変更したときに、既存のフラッシュ・キャッシュが存在していると、エラーが表示されます。属性をwritethroughに変更する前に、フラッシュ・キャッシュをフラッシュして削除する必要があります。フラッシュ操作が開始されると、フラッシュ・キャッシュへのすべてのキャッシュが停止されます。次の手順では、ライトバック・フラッシュ・キャッシュを非ローリング形式で無効にする方法について説明します。
注意:
ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。
フラッシュ・キャッシュのフラッシュ操作は、クラスタ全体を停止する前に実行できます。
Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X3-8フル・ラックの各システムでは、フラッシュ・キャッシュの圧縮を有効にできます。Oracle Exadata Database Machine X5-2およびX5-8にフラッシュ・キャッシュの圧縮機能はありません。フラッシュ・キャッシュの圧縮では、ユーザー・データがフラッシュ・キャッシュにロードされる際にデータを透過的に圧縮することによって、フラッシュ・キャッシュの論理容量が大幅に増加します。
注意:
フラッシュ・キャッシュ圧縮を有効にするには、Oracle拡張圧縮オプションが必要です。
フラッシュ・キャッシュの圧縮を有効にした場合、ユーザー・データは保持されません。
次の手順では、フラッシュ・キャッシュの圧縮を有効にする方法について説明します。
Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X3-8フル・ラックの各システムでは、フラッシュ・キャッシュの圧縮を無効にできます。Oracle Exadata Database Machine X5-2およびX5-8にフラッシュ・キャッシュの圧縮機能はありません。
注意:
フラッシュ・キャッシュの圧縮を無効にした場合、ユーザー・データは保持されません。
次の手順では、フラッシュ・キャッシュの圧縮を無効にする方法について説明します。
グリッド・ディスクとOracle ASMディスク・グループのサイズを変更して、空き領域が多すぎるディスクはサイズを減らしたり、最大容量に近いディスクはサイズを増やしたりできます。
Oracle Exadata Database Machineのディスク・グループ・サイズの初期構成は、Oracleベスト・プラクティスおよびバックアップ・ファイルの場所に基づきます。内部バックアップの場合、割当てられる領域はDATAディスク・グループで40%、RECOディスク・グループで60%です。外部バックアップの場合、割当てられる領域はDATAディスク・グループで80%、RECOディスク・グループで20%です。ディスク・グループの割当ては、デプロイ後に変更できます。たとえば、DATAディスク・グループの割当てが60%では小さすぎるため、80%にサイズ変更する必要が生じる場合があります。
システムで、セル・ディスクに空き領域がないが、1つのディスク・グループ(たとえばRECO)には十分な空き領域がある場合、RECOディスク・グループのサイズを小さくして、空き領域をDATAディスク・グループに再割当てすることができます。RECOディスク・グループを縮小した後で得られる空き領域は、DATAディスク・グループの既存の領域割当てとは連続しないオフセットにあります。グリッド・ディスクは、セル・ディスク上のどこにある領域でも使用することができ、連続している必要はありません。
グリッド・ディスクを拡張しようとするとき、十分な領域がセル・ディスクにすでにあり、既存のグリッド・ディスクを拡張できる場合には、最初に既存のディスク・グループをサイズ変更する必要はありません。RECOディスク・グループとグリッド・ディスクの縮小について説明している手順2と3は省略することもできます(ただし、DATAグリッド・ディスクを拡張する前に十分な空き領域があることを確認する必要はあります)。管理者が確保する必要がある空き領域の量は、障害時の補償範囲のレベルによって異なります。
グリッド・ディスクのサイズを縮小する場合は、ミラー化のために領域を確保する方法を理解する必要があります。データは、標準または高冗長性を使用してOracle ASMによって保護され、ファイル・エクステントとして保存される1つまたは2つのデータのコピーが作成されます。これらのコピーは、個別の障害グループに保存されます。1つの障害グループで障害が発生しても、ミラー・コピーには影響がないため、データにはまだアクセスできます。障害が発生すると、アクセスできないエクステントがOracle ASMによって再ミラー化(リバランスとも呼ばれる)されるため、冗長性が再確立されます。プロセスの再ミラー化を成功するには、新しいファイル・エクステントのミラー・コピーの作成に十分な空き領域がディスク・グループに存在する必要があります。十分な空き領域がないと、一部のエクステントが再ミラー化されず、他のデータ・コピーで後で障害が発生した場合に、ディスク・グループをバックアップからリストアする必要があります。領域の不足により再ミラー化プロセスが失敗すると、Oracle ASMはエラーを送信します。
Oracle Exadata Storage Server Softwareリリース12.1.2.1.0以上を使用するか、Oracle Bug#19695225のパッチをソフトウェアに適用する必要があります。
グリッド・ディスクのサイズを変更するこの手順は、ベア・メタルおよび仮想マシン(VM)デプロイメントに適用されます。
セル・ディスク上に使用可能な空き領域がない場合は、あるディスク・グループが使用する領域を減らして、別のディスク・グループに追加のディスク領域を提供することができます。
Oracle ASMディスク・グループのディスクを縮小したら、各セルのグリッド・ディスクのサイズを縮小できます。
未割当てのディスク領域(すでに使用可能な領域、または別のOracle ASMディスク・グループで使用されている領域を縮小することで使用可能になった領域)がある場合は、グリッド・ディスクで使用されるサイズを増やすことができます。
DATAディスク・グループのサイズを増やすかわりに、新たに解放された空き領域を使用して新しいディスク・グループを作成することや、将来使用するために空き領域のままにしておくこともできます。一般的には、必要な最小限の数のディスク・グループ(通常はDATA、RECOおよびDBFS_DG)を使用して、高い柔軟性と管理のしやすさを実現することをお薦めします。ただし、場合によっては、仮想マシンを使用するとき、または多数のデータベースを統合するときなど、追加のディスク・グループや将来のための使用可能な空き領域が必要になる可能性があります。
将来のためにグリッド・ディスクに空き領域を残しておく場合は、後から既存のディスク・グループに空き領域を割り当てる手順について「My Oracle Support Note 1684112.1」を参照してください。
システム・ディスクで障害が発生した場合、オペレーティング・システムに破損したファイル・システムがある場合またはブート領域が損傷している場合、レスキュー手順が必要です。1つのシステム・ディスクのみで障害が発生した場合、リカバリにCellCLIコマンドを使用します。両方のシステム・ディスクで同時に障害が発生するまれな事例の場合、Oracle Exadata Storage Server Software CELLBOOT USBフラッシュ・ドライブで提供されるExadata Storage Serverレスキュー機能を使用する必要があります。
通常の冗長性を使用している場合、レスキューされるセルのミラー・コピーは1つだけです。レスキュー手順の実行中にこのミラーでも障害が発生すると、リカバリできないデータの損失が発生する可能性があります。ミラー・コピーでデータの完全なバックアップを作成し、すぐにミラー・コピー・セルをオフラインにしてレスキュー前の新しいデータ変更を防止することをお薦めします。これにより、レスキュー・プロセス中は、障害が発生したセルのグリッド・ディスクのすべてのデータおよびそのミラー・コピーにアクセスできなくなります。
Oracle ASMディスク修復タイマーのデフォルトの修復時間は、3.6時間です。この時間内にレスキュー手順を実行できないことがわかった場合、レスキュー手順を実行できるまで、Oracle ASMリバランス手順を使用してディスクをリバランスする必要があります。
障害が発生したセルのすべてのグリッド・ディスクにOracle ASMの複数のミラー・コピーがある場合など、高い冗長性のディスク・グループを使用している場合、障害が発生したセルをオフラインにします。構成したOracle ASMのタイムアウト後に、Oracle ASMにより、障害が発生したセルのグリッド・ディスクが自動的に削除され、ミラー・コピーを使用したデータのリバランスが開始されます。デフォルトのタイムアウトは2時間です。セルのレスキューに2時間以上かかる場合、Oracle ASMのレスキュー・セルのグリッド・ディスクを再作成する必要があります。
注意:
十分に注意してレスキュー手順を使用してください。誤って手順を使用すると、データの損失が発生する可能性があります。
レスキュー手順を使用する場合、次の点に注意してください。
レスキュー手順により、セルの一部またはすべてのディスクが書き換えられる可能性があります。この場合、リカバリできずにそれらのディスクのすべての内容を失う可能性があります。
この手順を使用する場合は十分に注意し、プロンプトを確認してください。一部またはすべてのディスクのデータを損失してもかまわない場合にOracleサポート・サービスの支援だけでレスキュー手順を使用することが理想的です。
レスキュー手順の実行中に明示的に選択しないかぎり、レスキュー手順により、データ・ディスクの内容またはシステム・ディスクのデータ・パーティションの内容は破棄されません。
Oracle Exadata Storage Server Software 11gリリース2(11.2)以降、レスキュー手順により、Exadata Storage Serverソフトウェアが同じリリースにリストアされます。これには、最後に正常にブートしたときのセルのパッチが含まれます。レスキュー手順を使用しても、次の項目はリストアされません。
アラート構成、SMTP情報、管理者の電子メール・アドレスなど、セルの構成。ただし、最後に/usr/local/bin/ipconfユーティリティの実行が成功したときに存在したネットワーク構成はリストアされます。セル、root、celladminおよびcellmonitorユーザーのSSH IDはリストアされます。
Exadata Storage ServerのILOM構成。通常、ILOM構成は、Exadata Storage Serverソフトウェアに障害が発生しても損われません。
レスキュー手順により、データ・ディスクまたはシステム・ディスクのデータ・パーティションの確認または再構築は行われません。グリッド・ディスクにデータの破損がある場合、レスキュー手順は使用しないでください。かわりに、Oracle DatabaseおよびOracle ASMのレスキュー手順を使用してください。
正常なレスキューの実行後、セルを再構成し、データを保存する場合はセル・ディスクをインポートする必要があります。データを保存しない場合は、新しいセル・ディスクおよびグリッド・ディスクを作成する必要があります。
この項では、次の項目について説明します。
関連項目:
タイマーのリセットの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください
ALTER CELLコマンドの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください
CellCLIユーティリティを使用したセル、セル・ディスクおよびグリッド・ディスクの構成の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください
CELLBOOT USBフラッシュ・ドライブを使用して、次の手順を実行します。
コンソールを使用して、Exadata Storage Serverに接続します。
Exadata Storage Serverを起動します。次のように表示されます。
Press any key to enter the menu Booting Exadata_DBM_0: CELL_USB_BOOT_trying_C0D0_as_HD1 in 4 seconds... Booting Exadata_DBM_0: CELL_USB_BOOT_trying_C0D0_as_HD1 in 3 seconds... Press any key to see the menu.
Exadataソフトウェアの古いバージョンの場合、"Oracle Exadata"スプラッシュ画面が表示されます。スプラッシュ画面が表示されたら、キーボードの任意のキーを押します。スプラッシュ画面の表示は、5秒間のみです。
ブート・オプションの表示リストで、最後のオプションのCELL_USB_BOOT_CELLBOOT_usb_in_rescue_modeまで下にスクロールし、[Enter]を押します。
レスキュー・オプションを選択して、レスキュー手順に進みます。
システムの再起動を要求されたら、次の手順を実行するか、またはレスキューの最初のフェーズの最後にシェルを入力します。
選択して、シェルを入力します。システムの再起動は選択しないでください。
レスキューのrootパスワードを使用してシェルにログインします。
シェルからrebootコマンドを実行します。
シェルが再起動したら、Oracle Exadataスプラッシュ画面が表示される前に[F8]を押します。F8キーを押すと、起動デバイス選択メニューが開きます。
起動デバイスとしてRAIDコントローラを選択します。これにより、セルがハード・ディスクからブートされるようになります。
注意:
機能が制限されたレスキュー・モードのLinuxログイン・シェルを入力できる追加オプションを使用できる場合があります。Oracleサポート・サービスから提供されたパスワードを使用してrootユーザーとしてシェルにログインして、セルの追加診断および修復を手動で実行できます。詳細は、オンラインで入手できるこのリリースのリリース・ノートまたは最新のドキュメントを参照するか、Oracleサポート・サービス担当者に問い合せてください。
レスキューが成功した後、セルを構成する必要があります。データ・パーティションを維持した場合は、レスキュー手順の実行時にセル・ディスクが自動的にインポートされています。
レスキュー手順の実行中に交換されたディスクのセル・ディスクおよびグリッド・ディスクを再作成します。
グリッド・ディスクのステータスをチェックします。非アクティブの場合、次のコマンドを実行してアクティブ化します。
CellCLI> ALTER GRIDDISK ALL ACTIVE
Oracle ASMインスタンスにログインし、次のコマンドを使用して各ディスク・グループのディスクをONLINEに設定します。
SQL> ALTER DISKGROUP disk_group_name ONLINE DISKS IN FAILGROUP \
cell_name WAIT;
注意:
ディスクがすでに強制削除されているため、コマンドが失敗する場合は、ディスクをASMディスク・グループに強制追加する必要があります。
注意:
グリッド・ディスクのasmmodestatus属性とasmdeactivationoutcome属性は、ALTER DISKGROUP文が完了するまで正しく報告されません。
ALTER CELLコマンドを使用して、セルを再構成します。次に、最も一般的なパラメータの例を示します。
CellCLI> ALTER CELL smtpServer='my_mail.example.com', - smtpFromAddr='john.doe@example.com', - smtpPwd=email_address_password, - smtpToAddr='jane.smith@example.com', - notificationPolicy='critical,warning,clear', - notificationMethod='mail,snmp'
I/Oリソース管理(IORM)プランを再作成します。
メトリックしきい値を再作成します。
関連項目:
IORMプランの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください
メトリックしきい値の設定の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください
この項では、既存のエラスティック構成に次の変更を行う方法について説明します。
関連トピック
このシナリオでは、ディスク・グループを含む既存のExadataストレージ・グリッドに新しいセルを追加します。
新しいセルの場合は、次の手順を実行します。
目的のストレージ・グリッドで新しいストレージ・セルを利用できるようにするために、必要なすべてのケーブル接続要件を完了します。『Oracle Exadata Database Machineインストレーションおよび構成ガイド』を参照してください。
適切なOSSイメージでセルをイメージ化し、IPアドレスの入力を求められたときに適切な入力を提供します。
手順3にスキップします。
ラック内の既存のセルをInfiniBandネットワーク内の別のクラスタに割り当てる場合は、追加するセルのInfiniBandインタフェース(ib0およびib1)に割り当てられているIPアドレスをメモします。
すべてのOracle RACノードの/etc/oracle/cell/network-config/cellip.oraファイルに、前述の手順からのIPアドレスを追加します。これを行うには、クラスタ内の任意のデータベース・サーバー上で次の手順を実行します。
cd /etc/oracle/cell/network-config
cp cellip.ora cellip.ora.orig
cp cellip.ora cellip.ora-bak
/etc/oracle/cell/network-config/cellip.ora-bakに新しいエントリを追加します。
/usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d /etc/oracle/cell/network-config/cellip.ora
database_nodesは、クラスタ内の各データベース・サーバーの名前が含まれているファイルを参照します。名前は、それぞれ別の行にあります。
既存のストレージ・セルにASRアラートが設定されていた場合は、追加するセルのためにセルのASRアラートを構成します。
セルのASRアラートを構成するために必要なセルの属性をリストします。いずれかの既存のストレージ・グリッド・セルから、次のコマンドを実行します。
cellcli -e list cell attributes snmpsubscriber
celladminユーザーとして次のコマンドを実行して、新しいセルに同じSNMP値を適用します。
cellcli -e "alter cell snmpsubscriber=snmpsubscriber"
snmpsubscriberを前述のコマンドからの値に置き換えます。
追加するセルのセル・アラートを構成します。
セル・アラートを構成するために必要なセルの属性をリストします。いずれかの既存のストレージ・グリッド・セルから、次のコマンドを実行します。
cellcli -e list cell attributes notificationMethod,notificationPolicy,smtpToAddr,smtpFrom, smtpFromAddr,smtpServer,smtpUseSSL,smtpPort
celladminユーザーとして次のコマンドを実行して、新しいセルに同じ値を適用します。
cellcli -e "alter cell notificationMethod='notificationMethod', notificationPolicy='notificationPolicy', smtpToAddr='smtpToAddr', smtpFrom='smtpFrom', smtpFromAddr='smtpFromAddr', smtpServer='smtpServer', smtpUseSSL=smtpUseSSL, smtpPort=smtpPort"
プレースホルダを既存のセルから検出された値に置き換えます。
追加するセルのセル・ディスクを作成します。
celladminとしてセルにログインし、次のコマンドを実行します。
cellcli -e create celldisk all
デフォルトでフラッシュ・ログが作成されたことを確認します。
cellcli –e list flashlog
フラッシュ・ログの名前が表示されます。cellnodename_FLASHLOGのような名前で、ステータスが"normal"になっていることを確認してください。
フラッシュ・ログが存在しない場合は、次を使用して作成します。
cellcli -e create flashlog all
現在のフラッシュ・キャッシュ・モードを、既存セルのフラッシュ・キャッシュ・モードと比較します。
cellcli -e list cell attributes flashcachemode
フラッシュ・キャッシュ・モードを変更して既存のセルのフラッシュ・キャッシュ・モードに一致させるには、次の手順を実行します。
i.フラッシュ・キャッシュが存在し、セルがWriteBackフラッシュ・キャッシュ・モードの場合、フラッシュ・キャッシュを最初にフラッシュする必要があります。
cellcli –e alter flashcache all flush
コマンドが戻るまで待機します。
ii.フラッシュ・キャッシュを削除します。
cellcli -e "drop flashcache all"
iii.フラッシュ・キャッシュ・モードを変更します。
cellcli -e "alter cell flashCacheMode=writeback_or_writethrough"
flashCacheMode属性の値は、writebackまたはwritethroughのいずれかです。クラスタ内の他のストレージ・セルと同じフラッシュ・キャッシュ・モードになるように、値を設定する必要があります。
iv.フラッシュ・キャッシュを作成します。
cellcli -e create flashcache all
追加するセルのグリッド・ディスクを作成します。
既存のセルからの既存のグリッド・ディスクのsizeとcachingpolicyを問い合せます。
CellCLI> list griddisk attributes name,asmDiskGroupName,cachingpolicy,size,offset
前述のコマンドで検出された各ディスク・グループについて、クラスタに追加する新しいセルのグリッド・ディスクを作成します。前述のコマンドで報告されたその特定のディスク・グループの既存のグリッド・ディスクのsizeとcachingpolicyを一致させます。既存のセルと同様のレイアウトおよびパフォーマンス特性になるように、グリッド・ディスクはオフセットの昇順で作成する必要があります。たとえば、"list griddisk"コマンドで次のような出力が返されたとします。
DATAC1 default 2.15625T 32M DBFS_DG default 33.796875G 2.695465087890625T RECOC1 none 552.109375G 2.1562957763671875T
グリッド・ディスクを作成するときには、DATAC1、RECOC1、DBFS_DGの順序で次のコマンドを使用して作成します。
cellcli -e create griddisk PREFIX=matching_prefix_of_the_corresponding_existing_diskgroup, size=size_followed_by_G_or_T, cachingPolicy=\'value_from_command_above_for_this_disk_group\', comment =\"Cluster cluster_name diskgroup diskgroup_name\"
警告: 次のように、EXACTサイズを単位(TまたはG)とともに指定してください。
新しく作成されたグリッド・ディスクがOracle RACノードから参照できることを確認します。各Oracle RACノードにログインし、次のコマンドを実行します。
$GI_HOME/bin/kfod op=disks disks=all | grep cellName_being_added
前述の手順7で作成したすべてのグリッド・ディスクがリストされる必要があります。
新しく作成されたグリッド・ディスクをそれぞれの既存のASMディスク・グループに追加します。
alter diskgroup disk_group_name add disk 'comma_separated_disk_names';
comma_separated_disk_namesは、disk_group_nameに対応する手順5のディスク名を指します。
このコマンドはデフォルトの電源レベルでASMリバランス操作を開始します。gv$asm_operationの問合せにより、リバランスの進捗状況を監視します。
SQL> select * from gv$asm_operation;
リバランスが完了すると、Oracle RACへのセルの追加は完了です。
最新のexachkをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。
このシナリオでは、Exadataラック内にExadataストレージ・セルが存在し、最も拡張の必要なExadataストレージ・グリッドにストレージ・セルを追加します。
