| Oracle® Exadata Database Machineメンテナンス・ガイド 12cリリース1 (12.1) E56357-08 |
|
 前 |
 次 |
この章の内容は次のとおりです。
|
注意:
|
この項では、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の電源の切断方法を示しています。
(オプション)次のコマンドを実行して、セルの再起動後にグリッド・ディスクがオフラインのままになるようにします。
ALTER GRIDDISK ALL INACTIVE
この手順は、再起動を複数回実行したり、セルを再びアクティブにするタイミングを制御する場合(計画されていた保守アクティビティが成功したことを確認してからセルを使用する場合など)に役立ちます。
次のコマンドを使用して、セル・サービスを停止します。
CellCLI> ALTER CELL SHUTDOWN SERVICES ALL
前述のコマンドでは、オフラインのディスクがないか、predictive failureステータスのディスクがないか、またはミラーにコピーする必要があるディスクがないかをチェックします。Oracle ASM冗長性が損なわれていない場合は、コマンドによりOracle ASMでグリッド・ディスクがオフラインに変更され、セル・サービスが停止されます。次のエラーが表示された場合は、冗長性が原因でディスク・グループが強制的にディスマウントされ、セル・サービスを安全に停止できない可能性があります。
Stopping the RS, CELLSRV, and MS services... The SHUTDOWN of ALL services was not successful. CELL-01548: Unable to shut down CELLSRV because disk group DATA, RECO may be forced to dismount due to reduced redundancy. Getting the state of CELLSRV services... running Getting the state of MS services... running Getting the state of RS services... running
エラーが発生した場合は、Oracle ASMディスク・グループの冗長性をリストアし、すべてのディスクのディスク・ステータスが正常に戻ってからコマンドを再試行してください。
セルを停止します。
保守の実行後、セルの電源を投入します。セル・サービスが自動的に開始されます。セルの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にONLINEになります。
次のコマンドを使用して、すべてのグリッド・ディスクが正常にオンラインになったことを確認します。
CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus
すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。
次のコマンドを使用して、グリッド・ディスクをオンラインに設定します。この手順は、手順1を実行した場合にのみ必要です。手順1を実行していない場合は、グリッド・ディスクは自動的にアクティブになります。
ALTER GRIDDISK ALL ACTIVE
次の手順は、Exadata Storage Serverの削除方法を示しています。
Oracle ASMから次のコマンドを使用して、物理ディスクのOracle ASMディスクを削除します。
ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name
Oracle ASMの正しい冗長性レベルを確認するには、先に進む前にリバランスの完了を待機します。
Exadata Storage Serverにアクセスする各データベース・サーバーのcellip.oraファイルからIPアドレス・エントリを削除します。
次のコマンドを使用して、Exadata Storage Serverから物理ディスクのグリッド・ディスク、セル・ディスクおよびセルを削除します。
DROP CELLDISK celldisk_on_this_lun FORCE
Exadata Storage Server上のすべてのサービスをシャットダウンします。
セルの電源を切断します。
ディスクを削除または追加すると、Oracle ASMリバランスが発生します。リバランスのステータスを確認するには、次の手順を実行します。
リバランス操作が正しく実行された可能性がある場合。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時間です。ローリング更新を実行した場合、所要時間が非常に長くなる可能性があり、デプロイメントの負荷も大きくなります。このような負荷条件が、パッチ適用後のセルでグリッド・ディスクをアクティブ化および再アクティブ化するのにかかる時間に加算されます。
Oracle ASMによりセルのグリッド・ディスクが削除されるのを回避するため、パッチ適用時にOracle ASMの修理タイムアウトを増やす必要があります。これらのグリッド・ディスクを再度追加することは、時間のかかる手動での作業になります。ディスク・グループのdisk_repair_timeは最低でもデフォルト値の3.6時間に設定するようにしてください。
|
注意:
|
次に、ローリング更新を使用してExadataセルにパッチを適用する手順を簡単に説明します。これらの手順は、patchmgrユーティリティにより自動的に実行されます。
1つのセル上の非アクティブ化対象のグリッド・ディスクをすべて非アクティブ化します。対象となるグリッド・ディスクのasmdeactivationoutcome属性がYesに設定されます。
非アクティブ化したディスクがOFFLINEであることを確認します。
セルにパッチを適用します。
セルを再起動し、正常に起動したら、非アクティブ化したグリッド・ディスクをアクティブ化します。
手順4でアクティブ化したグリッド・ディスクがすべてONLINEであることを確認します。
パッチの適用対象となる次のセルに移動し、同じ手順を繰り返します。
patchmgrユーティリティでは、前述の手順が一度に1つのセルに対して実行されます。
非ローリング更新は、デプロイメント全体での停止時間を伴う方法としても知られます。デプロイメント全体で停止するよう選択した場合は、パッチはすべてのセルにパラレルに適用されます。patchmgrユーティリティによりExadataセルにこの機能が提供されます。
この方法の利点:
すべてのセルがパラレルに処理されます。そのため、パッチの適用時間は、適用対象となるセルの数に関係なく、ほぼ一定です。
グリッド・ディスクの非アクティブ化と再アクティブ化に費やす時間がゼロです。
この方法に関する考慮事項:
パッチ適用プロセスの実行中はセルを使用できません。パッチの適用中は、セル・サービスを使用するすべてのデータベースを停止したままにする必要があります。
パッチの適用中にセルの1つで問題が発生した場合は、そのセルの問題が解決するまでデプロイメント全体が使用できなくなります。通常、Oracle Clusterwareを排他モードで起動し、Oracle ASMのディスク・グループをFORCEオプションによってマウントし、その後で問題のあるセルのグリッド・ディスクを削除することによって、データベースを起動することは可能です。ただし、これらの手順を実行することによって、停止時間がさらに延びます。
再起動されないセルにアクセスして手動で修理する場合、診断ISOが必要になることがあります。ISOは、すべてのExadataセルの/opt/oracle.SupportTools/diagnostics.isoにあります。USBの使用など、他のブート方法が機能しない場合は、診断ISOを使用してください。
次に、ファイルを転送してセルを修理できるように、診断ISOとのネットワーキングを有効にする手順を示します。
Webインタフェースまたはシリアル・コンソールを使用して、サービス・プロセッサで1回のCD-ROMブートを有効にします。次に、シリアル・コンソールを使用する場合のコマンドの例を示します。
set boot_device=cdrom
サービス・プロセッサ・インタフェースを使用して、diagnostics.isoのローカル・コピーをCD-ROMとしてマウントします。
rebootコマンドを使用して、セルを再起動します。
rootユーザーとして診断ISOのパスワードを使用してセルにログインします。
次のコマンドを使用してpingを回避します。
alias ping="ping -c"
/etc/networkという名前のディレクトリを作成します。
/etc/network/if-pre-up.dという名前のディレクトリを作成します。
/etc/network/interfacesファイルに次の行を追加します。
iface eth0 inet static addressIP_address_of_cellnetmasknetmask_of_cellgatewaygateway_IP_address_of_cell
次のコマンドを使用して、eth0インタフェースを起動します。
ifup eth0
いくつかの警告メッセージが表示される場合もありますが、インタフェースは稼働しています。
FTPまたはwgetコマンドを使用して、セルを修理するためのファイルを取得します。
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以下 |
正常 予測障害 低いパフォーマンス クリティカル 存在しない |
リリース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ラックはオンラインで使用可能です。 |
この項の内容は次のとおりです。
|
関連項目:
|
各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はリバランス操作のステータスについて電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。以前のリリースのリバランス操作ステータスについて、「リバランス操作のステータスのチェック」を参照してください。 |
次の手順は、ディスク障害によるディスクの交換方法を示しています。
次のコマンドを使用して、障害が発生したディスクを特定します。
CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status=failed DETAIL
次に、コマンドの出力例を示します。スロット番号はディスクの場所、ステータスはディスクに障害が発生したことを示します。
CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status=failed DETAIL
name: 28:5
deviceId: 21
diskType: HardDisk
enclosureDeviceId: 28
errMediaCount: 0
errOtherCount: 0
foreignState: false
luns: 0_5
makeModel: "SEAGATE ST360057SSUN600G"
physicalFirmware: 0705
physicalInterface: sas
physicalSerial: A01BC2
physicalSize: 558.9109999993816G
slotNumber: 5
status: failed
ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
Exadata Storage Server上の物理ディスクを交換し、3分待ちます。物理ディスクはホットプラグ対応で、電源の投入時に交換できます。
ディスクがオンラインであることを確認します。
物理ディスクを交換する場合、使用前にディスクをRAIDコントローラで承認する必要があります。この処理にあまり時間は要しません。次のようなLIST PHYSICALDISKコマンドを使用して、ステータスがNORMALであることを確認します。
CellCLI> LIST PHYSICALDISK WHERE name=28:5 ATTRIBUTES status
ALTER CELL VALIDATE CONFIGURATIONコマンドを使用して、ファームウェアが正しいことを確認します。
まれに、自動ファームウェア更新が機能せず、LUNが再構築されない場合があります。これは、ms-odl.trcファイルをチェックして確認できます。
|
関連項目:
|
ディスクが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はリバランス操作のステータスについて電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。以前のリリースのリバランス操作ステータスについて、「リバランス操作のステータスのチェック」を参照してください。 |
次の手順は、ディスクの問題によるディスクの交換方法を示しています。
次のコマンドを使用して、障害が発生したディスクを特定します。
CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status= \
"warning - predictive failure" DETAIL
次に、コマンドの出力例を示します。スロット番号はディスクの場所、ステータスはディスクに障害が発生する可能性があることを示します。
CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status= \
"warning - predictive failure" DETAIL
name: 28:3
deviceId: 19
diskType: HardDisk
enclosureDeviceId: 28
errMediaCount: 0
errOtherCount: 0
foreignState: false
luns: 0_3
makeModel: "SEAGATE ST360057SSUN600G"
physicalFirmware: 0705
physicalInterface: sas
physicalSerial: E07L8E
physicalSize: 558.9109999993816G
slotNumber: 3
status: warning - predictive failure
ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
物理ディスクのグリッド・ディスクに関連するOracle ASMディスクが正しく削除されるまで待機します。グリッド・ディスクが削除されたかどうか判別するには、Oracle ASMインスタンスのV$ASM_DISK_STATビューの問合せを実行します。
|
注意: 最初の2つのスロットのディスクは、オペレーティング・システムおよびOracle Exadata Storage Server Softwareを格納するシステム・ディスクです。1つのシステム・ディスクを稼働して、サーバーを維持する必要があります。他のシステム・ディスクを交換する前に、 |
|
関連項目: V$ASM_DISK_STATビューの問合せの詳細は、『Oracle Databaseリファレンス』 |
Exadata Storage Server上の物理ディスクを交換し、3分待ちます。物理ディスクはホットプラグ対応で、電源の投入時に交換できます。
ディスクがオンラインであることを確認します。
物理ディスクを交換する場合、使用前にディスクをRAIDコントローラで承認する必要があります。この処理にあまり時間は要しません。次のようなLIST PHYSICALDISKコマンドを使用して、ステータスがNORMALであることを確認します。
CellCLI> LIST PHYSICALDISK WHERE name=28:5 ATTRIBUTES status
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 IDdate_timeinfo "Hard disk entered confinement status. The LUN n_m changed status to warning - confinedOnline. CellDisk changed status to normal - confinedOnline. Status: WARNING - CONFINEDONLINE Manufacturer:nameModel Number:modelSize:sizeSerial Number:serial_numberFirmware:fw_releaseSlot Number:mCell Disk:cell_disk_nameGrid 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
...
次の手順は、不良ディスクが確認された場合の物理ディスクの取外し方法を示しています。
物理ドライブ・サービスLEDを点灯し、次のコマンドを使用して交換するドライブを識別します。
cellcli -e 'alter physicaldisk disk_name serviceled on'
前述のコマンドでdisk_nameは、20:2などの交換する物理ディスクの名前です。
不良ディスクのすべてのグリッド・ディスクを確認します。次のコマンドを使用して、Oracle ASMに不良ディスクの使用をただちに停止するよう指示します。
ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name
ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
V$ASM_DISK_STATビューの問合せを実行して、不良ディスクのグリッド・ディスクに関連するOracle ASMディスクが正しく削除されたことを確認します。
不良ディスクを取り外します。ディスクを削除すると、アラートが送信されます。
新しいディスクを使用できる場合、システムに新しいディスクを設置します。セル・ディスクおよびグリッド・ディスクが新しい物理ディスクに自動的に作成されます。
|
注意: 物理ディスクを交換する場合、使用前にディスクをRAIDコントローラで承認する必要があります。承認処理に時間はかかりませんが、LIST PHYSICALDISKコマンドを使用してステータスがNORMALであることを確認してください。 |
|
関連項目:
|
Exadata Storage Serverから別のExadata Storage Serverへのすべてのドライブの移動が必要になることがあります。この作業が必要になるのは、マザーボードやILOM障害などのシャーシ・レベルのコンポーネント障害がある場合またはハードウェアの問題のトラブルシューティングを行う場合です。
次の手順は、ドライブの移動方法を示しています。
次のディレクトリのファイルをバックアップします。
/etc/hosts
/etc/modprobe.conf
/etc/sysconfig/network
/etc/sysconfig/network-scripts
「Exadata Storage Serverのシャットダウン」を参照して、すべてのグリッド・ディスクを安全に無効化し、Exadata Storage Serverをシャットダウンします。別のExadata Storage Serverでグリッド・ディスクをアクティブ化する前にOracle ASMによってディスクが削除されないように、Oracle ASMのdisk_repair_time属性に十分に大きい値が設定されていることを確認してください。
物理ディスク、フラッシュ・ディスク、ディスク・コントローラおよびUSBフラッシュ・ドライブを元のExadata Storage Serverから新しいExadata Storage Serverに移動します。
|
注意:
|
サービス・プロセッサ・インタフェースまたは電源ボタンを使用して、新しいExadata Storage Serverの電源を投入します。
サービス・プロセッサまたはKVMスイッチを使用して、コンソールにログインします。
次のディレクトリのファイルを確認します。破損している場合、バックアップからリストアします。
/etc/hosts
/etc/modprobe.conf
/etc/sysconfig/network
/etc/sysconfig/network-scripts
ifconfigコマンドを使用して、eth0、eth1、eth2およびeth3の新しいMACアドレスを取得します。次に、eth0 MACアドレスを取得する例を示します。
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:14:4F:CA:D9:AE
inet addr:10.204.74.184 Bcast:10.204.75.255 Mask:255.255.252.0
inet6 addr: fe80::214:4fff:feca:d9ae/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:141455 errors:0 dropped:0 overruns:0 frame:0
TX packets:6340 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9578692 (9.1 MiB) TX bytes:1042156 (1017.7 KiB)
Memory:f8c60000-f8c80000
手順7の出力に基づいて、/etc/sysconfig/network-scriptsディレクトリのifcfg-eth0ファイル、ifcfg-eth1ファイル、ifcfg-eth2ファイルおよびifcfg-eth3ファイルを編集してHWADDR値を変更します。次に、ifcfg-eth0ファイルの例を示します。
#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.204.74.184
NETMASK=255.255.252.0
NETWORK=10.204.72.0
BROADCAST=10.204.75.255
GATEWAY=10.204.72.1
HOTPLUG=no
IPV6INIT=no
HWADDR=00:14:4F:CA:D9:AE
Exadata Storage Serverを再起動します。
次のコマンドを使用して、グリッド・ディスクをアクティブ化します。
CellCLI> ALTER GRIDDISK ALL ACTIVE
セルのディスクのOracle ASMディスクが削除されなかった場合、それらのディスクは自動的にONLINEに変更され、使用が開始されます。
次のコマンドを使用して、構成を検証します。
CellCLI> ALTER CELL VALIDATE CONFIGURATION
ASRのILOMをアクティブ化します。
|
関連項目:
|
ディスクのすべてのデータを削除し、別の目的でディスクを使用できます。これを実行する前に、ディスクのデータをコピーしてください。
次の手順は、ディスクの再利用方法を示しています。
CellCLIのLISTコマンドを使用して、Exadata Storage Serverオブジェクトを表示します。物理ドライブのグリッド・ディスクおよびセル・ディスクを確認する必要があります。例:
CellCLI> LIST PHYSICALDISK
20:0 D174LX normal
20:1 D149R0 normal
...
次のようなコマンドを使用して、LUNのセル・ディスクおよびグリッド・ディスクを特定します。
CellCLI> LIST LUN ATTRIBUTES name, cellDisk WHERE physicalDrives='20:0'
Oracle ASMから次のコマンドを使用して、物理ディスクのOracle ASMディスクを削除します。
ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name
Exadata Storage Serverから次のコマンドを使用して、物理ディスクのセル・ディスクおよびグリッド・ディスクを削除します。
DROP CELLDISK celldisk_on_this_lun FORCE
|
注意: セル・ディスクのすべてのデータを上書きするには、DROP CELLDISKコマンドでERASEオプションを使用します。このコマンドの例を次に示します。
CellCLI> DROP CELLDISK CD_03_cell01 ERASE=1pass NOWAIT CellDisk CD_03_cell01 erase is in progress 詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。 |
ホット削除するドライブを削除します。例:
CellCli> ALTER PHYSICALDISK 20:0 DROP FOR REPLACEMENT
ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
|
注意: ドライブを取り外す前に、ディスクの青色のLEDが点灯していることを確認します。青色のLEDが消灯している場合にドライブを取り外すと、システムがクラッシュする場合があるため、取り外さないでください。 |
再利用するディスクを取り外し、新しいディスクを挿入します。
新しい物理ディスクがLUNとして追加されるまで待機します。
CellCLI> LIST LUN
セル・ディスクとグリッド・ディスクが新しい物理ディスクに自動的に作成され、グリッド・ディスクがOracle ASMグループに追加されます。
不注意で間違った物理ディスクを削除した場合、ディスクを元に戻します。Oracle ASMディスク・グループに自動的に追加され、そのデータは再同期化されます。
|
注意: ディスク障害またはディスクの問題でディスクを交換すると、ディスク上でLEDが点灯し識別できます。 |
データは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には、4枚のPCIeカードが付属しています。各カードに4個のフラッシュ・ディスク(FDOM)があり、合計16個のフラッシュ・ディスクが提供されます。4枚のPCIeカードは、PCIスロット番号1、2、4および5にあります。PCIeカードはホットプラグ対応ではないため、フラッシュ・ディスクまたはカードを交換する前にExadata Storage Serverの電源を切断する必要があります。
障害が発生したフラッシュ・ディスクを確認するには、次のコマンドを使用します。
CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS=failed DETAIL
次に、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_3diskType: 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.13225793838501GslotNumber: "PCI Slot: 5; FDOM: 3"status: failed
カードのnameおよびslotNumber属性は、PCIスロットおよびFDOM番号を示します。
フラッシュ・ディスクの障害が検出されると、フラッシュ・ディスクとそのLUNで障害が発生したことを示すアラートが生成されます。アラート・メッセージには、フラッシュ・カードのPCIスロット番号および正確なFDOM番号が含まれています。これらの番号により、フィールド交換可能ユニット(FRU)が一意に識別されます。システムのアラート通知を構成している場合は、指定したアドレスにアラートが電子メール・メッセージで送信されます。
フラッシュ・ディスクの停止により、パフォーマンスの低下およびデータの冗長性が発生する場合があります。できるだけすぐに障害が発生したディスクを新しいフラッシュ・ディスクに交換する必要があります。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、セルの有効なキャッシュ・サイズが縮小します。フラッシュ・ログにフラッシュ・ディスクを使用する場合、ディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、FORCEオプションによってグリッド・ディスクに関連するOracle ASMディスクがOracle ASMディスク・グループから自動的に削除され、Oracle ASMリバランスでデータの冗長性のリストアが開始されます。
次の手順は、ディスク障害によるFDOMの交換方法を示しています。
セルを停止します。
PCI番号およびFDOM番号に基づいて、障害が発生したフラッシュ・ディスクを交換します。白色のセルLEDが点灯し、影響を受けているセルを特定できます。
セルの電源を投入します。セル・サービスが自動的に開始されます。セルの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にONLINEになります。
次のコマンドを使用して、すべてのグリッド・ディスクが正常にオンラインになったことを確認します。
CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus
すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。
新しいフラッシュ・ディスクがシステムによって自動的に使用されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。
|
関連項目:
|
Exadata Storage Serverには、4枚のPCIeカードが付属しています。各カードに4個のフラッシュ・ディスク(FDOM)があり、合計16個のフラッシュ・ディスクが提供されます。4枚のPCIeカードは、PCIスロット番号1、2、4および5にあります。PCIeカードはホットプラグ対応ではありません。フラッシュ・ディスクまたはカードを交換する前にExadata Storage Serverの電源を切断する必要があります。
ディスクが次のステータスのいすれかになるため、フラッシュ・ディスクの交換が必要な場合があります。
warning - predictive failure
warning - poor performanceステータス
warning - write-through caching
warning - peer failure
|
注意: リリース11.2.3.2.2より前のリリースでは、ステータスはnot presentです。 |
フラッシュ・ディスクのpredictive failureステータスは、フラッシュ・ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、引き続きフラッシュ・キャッシュとして使用されます。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクに関連するOracle ASMディスクが自動的に削除され、Oracle ASMリバランスで障害が発生する可能性のあるディスクから他のディスクにデータが移動されます。
フラッシュ・ディスクのpoor performanceステータスは、フラッシュ・ディスクのパフォーマンスが非常に低く、できるだけすぐに交換する必要があることを示します。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクからフラッシュ・キャッシュが削除され、Exadata Storage Serverの有効なフラッシュ・キャッシュ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、このフラッシュ・ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションによって可能な場合に自動的に削除されます。オフライン・パートナのためにDROP...FORCEが失敗した場合、通常グリッド・ディスクが自動的に削除され、Oracle ASMリバランスでパフォーマンスの低いディスクから他のディスクにデータが移動されます。
フラッシュ・ディスクのwrite-through cachingステータスは、PCIeカードのデータ・キャッシュのサポートに使用するキャパシタに障害が発生したため、できるだけすぐにカードを交換する必要があることを示します。
フラッシュ・ディスクのpeer failureステータスは、同じSun Flash Accelerator PCIeカードのいずれかのフラッシュ・ディスクに障害または問題が発生したことを示します。たとえば、FLASH5_3に障害が発生すると、FLASH5_0、FLASH5_1およびFLASH5_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属性に表示されなくなるまで待機します。
次の手順は、ディスクの問題によるフラッシュ・ディスクの交換方法を示しています。
次のコマンドを使用して、セル・サービスを停止します。
CellCLI> ALTER CELL SHUTDOWN SERVICES ALL
前述のコマンドでは、オフラインのディスクがないか、predictive failureステータスのディスクがないか、またはミラーにコピーする必要があるディスクがないかをチェックします。Oracle ASM冗長性が損なわれていない場合は、コマンドによりOracle ASMでグリッド・ディスクがオフラインに変更され、セル・サービスが停止されます。次のエラーが表示された場合は、冗長性が原因でディスク・グループが強制的にディスマウントされ、セル・サービスを安全に停止できない可能性があります。
Stopping the RS, CELLSRV, and MS services... The SHUTDOWN of ALL services was not successful. CELL-01548: Unable to shut down CELLSRV because disk group DATA, RECO may be forced to dismount due to reduced redundancy. Getting the state of CELLSRV services... running Getting the state of MS services... running Getting the state of RS services... running
エラーが発生した場合は、Oracle ASMディスク・グループの冗長性をリストアし、すべてのディスクのディスク・ステータスが正常に戻ってからコマンドを再試行してください。
セルを停止します。
PCI番号およびFDOM番号に基づいて、障害が発生したフラッシュ・ディスクを交換します。白色のセルLEDが点灯し、影響を受けているセルを特定できます。
セルの電源を投入します。セル・サービスが自動的に開始されます。セルの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にONLINEになります。
次のコマンドを使用して、すべてのグリッド・ディスクが正常にオンラインになったことを確認します。
CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus
すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。
新しいフラッシュ・ディスクがシステムによって自動的に使用されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。
|
関連項目:
|
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 IDdate_timeinfo "Hard disk entered confinement status. The LUN n_m changed status to warning - confinedOnline. CellDisk changed status to normal - confinedOnline. Status: WARNING - CONFINEDONLINE Manufacturer:nameModel Number:modelSize:sizeSerial Number:serial_numberFirmware:fw_releaseSlot Number:mCell Disk:cell_disk_nameGrid 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
...
次の手順は、不良フラッシュ・ディスクが確認された場合のフラッシュ・ドライブの取外し方法を示しています。
フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、次のコマンドを使用して、フラッシュ・ディスクの一部であるフラッシュ・キャッシュを無効化します。
CellCLI > ALTER FLASHCACHE ... FLUSH CellCLI > DROP FLASHCACHE CellCLI > CREATE FLASHCACHE CELLDISK='fd1,fd2,fd3,fd4, ...'
|
注意:
|
グリッド・ディスクにフラッシュ・ディスクを使用する場合、次のコマンドを使用して不良ディスクの使用をすぐに停止するようOracle ASMに指示します。
SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name FORCE
オフライン・パートナのため、FORCEオプションを使用したDROPコマンドに失敗する可能性があります。他のセルまたはディスク障害を修正することによってOracle ASMデータの冗長性をリストアしてDROP...FORCEコマンドを再試行するか、次のコマンドを使用してOracle ASMに不良ディスクのデータのリバランスを指示できます。
SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name NOFORCE
この不良フラッシュ・ディスクのグリッド・ディスクに関連するOracle ASMディスクが正しく削除されるまで待機します。フラッシュ・ディスクを安全に交換できるようになると、Oracle Exadata Storage Server Softwareによって自動的にアラートが送信されます。
次のコマンドを使用して、セル・サービスを停止します。
CellCLI> ALTER CELL SHUTDOWN SERVICES ALL
前述のコマンドでは、オフラインのディスクがないか、predictive failureステータスのディスクがないか、またはミラーにコピーする必要があるディスクがないかをチェックします。Oracle ASM冗長性が損なわれていない場合は、コマンドによりOracle ASMでグリッド・ディスクがオフラインに変更され、セル・サービスが停止されます。次のエラーが表示された場合は、冗長性が原因でディスク・グループが強制的にディスマウントされ、セル・サービスを安全に停止できない可能性があります。
Stopping the RS, CELLSRV, and MS services... The SHUTDOWN of ALL services was not successful. CELL-01548: Unable to shut down CELLSRV because disk group DATA, RECO may be forced to dismount due to reduced redundancy. Getting the state of CELLSRV services... running Getting the state of MS services... running Getting the state of RS services... running
前述のエラーが発生した場合は、Oracle ASMディスク・グループの冗長性をリストアし、すべてのディスクのディスク・ステータスが正常に戻ってからコマンドを再試行してください。
セルを停止します。
不良フラッシュ・ディスクを取り外して、新しいフラッシュ・ディスクと交換します。
セルの電源を投入します。セル・サービスが自動的に開始されます。セルの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にONLINEになります。
次のコマンドを使用して、新しいフラッシュ・ディスクをフラッシュ・キャッシュに追加します。
CellCLI> DROP FLASHCACHE CellCLI> CREATE FLASHCACHE ALL
次のコマンドを使用して、すべてのグリッド・ディスクが正常にオンラインになったことを確認します。
CellCLI> LIST GRIDDISK ATTRIBUTES asmmodestatus
すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。
次のようにフラッシュ・ディスクが追加されます。
グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。
これらのグリッド・ディスクがOracle ASMディスク・グループの一部であり、DROP...FORCEを手順2で使用した場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。
手順2でDROP...NOFORCEが使用された場合、グリッド・ディスクをOracle ASMディスク・グループに手動で追加する必要があります。
|
関連項目:
|
リリース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リリース2 (11.2)リリース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ホームの最小リリース要件がまとめられています。 |
ライトバック・フラッシュ・キャッシュを有効にする最初のセルにrootユーザーとしてログインします。
次のコマンドを使用して、フラッシュ・キャッシュが正常であり、フラッシュ・ディスクの機能低下やクリティカル状態が発生していないことを確認します。
# cellcli -e LIST FLASHCACHE detail
次のコマンドを使用して、セルのフラッシュ・キャッシュを削除します。
# cellcli -e DROP FLASHCACHE
次のコマンドを使用して、セルのグリッド・ディスクを非アクティブ化します。
# cellcli -e ALTER GRIDDISK ALL INACTIVE
次のコマンドを使用して、CELLSRVサービスを停止します。
# cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV
次のコマンドを使用して、flashCacheMode属性をwritebackに設定します。
# cellcli -e "ALTER CELL FLASHCACHEMODE=writeback"
次のコマンドを使用して、セル・サービスを再起動します。
# 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
flashCacheMode属性がwritebackに設定されている必要があります。
次のセルに移る前に、次のコマンドを使用して、グリッド・ディスクのasmDeactivationOutcome属性とasmModeStatus属性をチェックします。
LIST GRIDDISK ATTRIBUTES name,asmdeactivationoutcome,asmmodestatus
asmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。
次のセルに対して前述の手順を繰り返します。
属性をwritethroughからwritebackに変更する場合は、属性を変更する前にフラッシュ・キャッシュを削除する必要があります。次の手順では、ライトバック・フラッシュ・キャッシュを非ローリング形式で有効にする方法について説明します。
|
注意: ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。 |
|
関連項目: My Oracle Supportノート888828.1には、Oracle Exadata Storage Server Software、Grid InfrastructureホームおよびOracle Databaseホームの最小リリース要件がまとめられています。 |
データベース・ノードにrootユーザーとしてログインします。
次のコマンドを使用して、クラスタ全体を停止します。
# cd $GI_HOME/bin # ./crsctl stop cluster -all
次のコマンドを使用して、すべてのセルのフラッシュ・キャッシュを削除します。
# dcli -g cell_group -l root cellcli -e DROP FLASHCACHE
次のコマンドを使用して、CELLSRVサービスを停止します。
# dcli -g cell_group -l root cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV
フラッシュ・キャッシュがwritethroughモードに設定されていることを確認します。
# dcli -g cell_group -l root "cellcli -e list cell detail | grep -i flashcachemode"
次のコマンドを使用して、flashCacheMode属性をwritebackに設定します。
# dcli -g cell_group -l root cellcli -e "ALTER CELL FLASHCACHEMODE=writeback"
次のコマンドを使用して、セル・サービスを再起動します。
# dcli -g cell_group -l root cellcli -e ALTER CELL STARTUP SERVICES CELLSRV
次のコマンドを使用して、フラッシュ・キャッシュを再作成します。
# dcli -g cell_group -l root cellcli -e CREATE FLASHCACHE ALL
クラスタを再起動します。
# cd $GI_HOME/bin # ./crsctl start cluster -all
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に変更する前に、フラッシュ・キャッシュをフラッシュして削除する必要があります。フラッシュ操作が開始されると、フラッシュ・キャッシュへのすべてのキャッシュが停止されます。次の手順では、ライトバック・フラッシュ・キャッシュを非ローリング形式で無効にする方法について説明します。
|
注意:
|
ライトバック・フラッシュ・キャッシュを無効にする最初のデータベース・ノードにrootユーザーとしてログインします。
次のコマンドを使用して、フラッシュ・キャッシュ内のダーティ・データの量をチェックします。
# 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 METRICCURRENT ATTRIBUTES name, \
metricvalue WHERE NAME LIKE \'FC_BY_DIRTY.*\'"
次のコマンドを使用して、フラッシュ・ディスクのステータスをチェックします。
# dcli -g cell_group -l root cellcli -e LIST CELLDISK ATTRIBUTES name, flushstatus, flusherror | grep FD
フラッシュが完了すると、ステータスがcompletedになります。
次のコマンドを使用して、データベースとクラスタ全体を停止します。
# cd $GI_HOME/bin # ./crsctl stop cluster -all
次のコマンドを使用して、すべてのセルのフラッシュ・キャッシュを削除します。
# dcli -g cell_group -l root cellcli -e DROP FLASHCACHE
次のコマンドを使用して、CELLSRVサービスを停止します。
# dcli -g cell_group -l root cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV
次のコマンドを使用して、flashCacheMode属性をwritethroughに設定します。
# dcli -g cell_group -l root cellcli -e "ALTER CELL FLASHCACHEMODE=writethrough"
次のコマンドを使用して、セル・サービスを再起動します。
# dcli -g cell_group -l root cellcli -e ALTER CELL STARTUP SERVICES CELLSRV
次のコマンドを使用して、フラッシュ・キャッシュを再作成します。
# dcli -g cell_group -l root cellcli -e CREATE FLASHCACHE ALL
次のコマンドを使用して、セルのフラッシュ・キャッシュ・モードをチェックします。
# dcli -g cell_group -l root cellcli -e LIST CELL DETAIL | grep flashCacheMode
次のコマンドを使用して、クラスタとデータベースを再起動します。
# cd $GI_HOME/bin # ./crsctl start cluster -all
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にフラッシュ・キャッシュの圧縮機能はありません。フラッシュ・キャッシュの圧縮では、ユーザー・データがフラッシュ・キャッシュにロードされる際にデータを透過的に圧縮することによって、フラッシュ・キャッシュの論理容量が大幅に増加します。
|
注意:
|
次の手順では、フラッシュ・キャッシュの圧縮を有効にする方法について説明します。
次のコマンドを使用して、フラッシュ・セル・ディスクにユーザー・データを保存します。
# cellcli -e ALTER FLASHCACHE all flush
次のコマンドを使用して、セルからフラッシュ・キャッシュを削除します。
# cellcli -e DROP FLASHCACHE all
次のコマンドを使用して、セルからフラッシュ・ログを削除します。
# cellcli -e DROP FLASHLOG all
次のコマンドを使用して、セル・フラッシュ・ディスクを削除します。
# cellcli -e DROP CELLDISK all flashdisk
システムに応じて、次のコマンドを使用してフラッシュ・キャッシュの圧縮を有効にします。
Sun Fire X4170 Oracle Database Server、およびExadata Storage Server X4-2L Serverを使用したOracle Exadata Database Machine X3-2の場合:
# cellcli -e ALTER CELL flashcachecompress=true
Oracle Exadata Database Machine X3-2、およびExadata Storage Server X3-2 Serverを使用したOracle Exadata Database Machine X3-8フル・ラックの場合:
# cellcli -e ALTER CELL flashCacheCompX3Support=true # cellcli -e ALTER CELL flashCacheCompress=true
次のコマンドを使用して、セル・フラッシュ・ディスクを作成します。
# cellcli -e CREATE CELLDISK all flashdisk CellDisk FD_00_exampleceladm18 successfully created ... CellDisk FD_15_exampleceladm18 successfully created
次のコマンドを使用して、フラッシュ・ログを作成します。
# cellcli -e CREATE FLASHLOG all Flash log RaNdOmceladm18_FLASHLOG successfully created
次のコマンドを使用して、セルでフラッシュ・キャッシュを作成します。
# cellcli -e CREATE FLASHCACHE all Flash cache exampleceladm18_FLASHCACHE successfully created
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にフラッシュ・キャッシュの圧縮機能はありません。
|
注意:
|
次の手順では、フラッシュ・キャッシュの圧縮を無効にする方法について説明します。
次のコマンドを使用して、フラッシュ・セル・ディスクにユーザー・データを保存します。
# cellcli -e ALTER FLASHCACHE all flush
次のコマンドを使用して、セルからフラッシュ・キャッシュを削除します。
# cellcli -e DROP FLASHCACHE all
次のコマンドを使用して、セルからフラッシュ・ログを削除します。
# cellcli -e DROP FLASHLOG all
次のコマンドを使用して、セル・フラッシュ・ディスクを削除します。
# cellcli -e DROP CELLDISK all flashdisk
システムに応じて、次のコマンドを使用してフラッシュ・キャッシュの圧縮を無効にします。
Sun Fire X4170 Oracle Database Server、およびExadata Storage Server X4-2L Serverを使用したOracle Exadata Database Machine X3-2の場合:
# cellcli -e ALTER CELL flashcachecompress=false
Oracle Exadata Database Machine X3-2、およびExadata Storage Server X3-2 Serverを使用したOracle Exadata Database Machine X3-8フル・ラックの場合:
# cellcli -e ALTER CELL flashCacheCompX3Support=true # cellcli -e ALTER CELL flashCacheCompress=false
|
注意: flashCacheCompressをfalseに設定しますが、flashCacheCompX3Supportはtrueに設定する必要があります。 |
次のコマンドを使用して、セル・フラッシュ・ディスクを作成します。
# cellcli -e CREATE CELLDISK all flashdisk CellDisk FD_00_exampleceladm18 successfully created ... CellDisk FD_15_exampleceladm18 successfully created
次のコマンドを使用して、フラッシュ・ログを作成します。
# cellcli -e CREATE FLASHLOG all Flash log RaNdOmceladm18_FLASHLOG successfully created
次のコマンドを使用して、セルでフラッシュ・キャッシュを作成します。
# cellcli -e CREATE FLASHCACHE all Flash cache exampleceladm18_FLASHCACHE successfully created
フラッシュ・キャッシュの圧縮が無効になっていることを確認します。
# cellcli -e LIST CELL
flashCacheCompress属性の値がfalseに設定されている必要があります。
Oracle Exadata Database Machineのディスク・グループ・サイズの初期構成は、Oracleベスト・プラクティスおよびバックアップ・ファイルの場所に基づきます。内部バックアップの場合、割当てられる領域はDATAディスク・グループで40%、RECOディスク・グループで60%です。外部バックアップの場合、割当てられる領域はDATAディスク・グループで80%、RECOディスク・グループで20%です。ディスク・グループの割当ては、デプロイ後に変更できます。たとえば、DATAディスク・グループの割当てが60%では小さすぎるため、80%にサイズ変更する必要が生じる場合があります。
次の作業では、ストレージ・グリッド・ディスクのサイズを変更する方法について説明します。
グリッド・ディスクのサイズを変更する前に、DATAおよびRECOディスク・グループおよびグリッド・ディスクの新しいサイズを確認する必要があります。ディスク・グループのサイズおよび領域を計算するための情報とスクリプトは、My Oracle Supportノート1464809.1を参照してください。
データは、標準または高冗長性を使用してOracle ASMによって保護され、ファイル・エクステントとして保存される1つまたは2つのデータのコピーが作成されます。これらのコピーは、個別の障害グループに保存されます。1つの障害グループで障害が発生しても、ミラー・コピーには影響がないため、データにはまだアクセスできます。
障害が発生すると、アクセスできないエクステントがOracle ASMによって再ミラー化(リバランスとも呼ばれる)されるため、冗長性が再確立されます。プロセスの再ミラー化を成功するには、新しいファイル・エクステントのミラー・コピーの作成に十分な空き領域がディスク・グループに存在する必要があります。十分な空き領域がないと、一部のエクステントが再ミラー化されず、他のデータ・コピーで後で障害が発生した場合に、ディスク・グループをバックアップからリストアする必要があります。領域の不足により再ミラー化プロセスが失敗すると、Oracle ASMはエラーを送信します。
データベース管理者は、障害の発生後に再ミラー化プロセスが成功するように、ディスク・グループに十分な空き領域を常に保持する必要があります。管理者が確保する必要がある空き領域の量は、障害時の補償範囲のレベルによって異なります。このトピックの詳細は、My Oracle Supportノート1551288.1を参照してください。
|
注意: DATAおよびRECOの予約領域の割当てで計算された値よりもFREE_MBが常に大きくなるようにするには、DATAおよびRECOディスク・グループのFREE_MBメトリックをV$ASM_DISKGROUPビューで監視する必要があります。 |
この作業では、ディスク・グループのサイズ変更の方法について説明します。表3-2に、サイズ変更の方法と、それぞれの方法のメリットとデメリット、前提条件を示します。
表3-2 ディスク・グループのサイズ変更の比較
| 方法 | 利点 | デメリット | 前提条件 |
|---|---|---|---|
|
方法1: RECOグリッド・ディスクをローリング形式で再作成する |
|
|
障害グループを削除し、残りの障害グループでデータをリバランスできるようにするには、RECOディスク・グループに十分な空き領域が必要です 空き領域の最小容量は、セルの数で分割されたディスク・グループで使用される領域の容量に、その値の5%を加えた容量より大きくする必要があります。空き領域の容量は、最小値の最低2倍にする必要があり、これにより、リバランスの数は半分に削減されます。 |
|
方法2: RECOディスク・グループを削除して再作成する |
|
|
制御ファイルの移動が必要な場合は、短い停止時間が必要です。 テープへのバックアップなど、RECOディスク・グループのファイルを消去または移動できるようにする必要があります。 この手順の実行中にFRAを別のディスク・グループ(通常はDATAディスク・グループ)に移動する必要があります。 フラッシュ・バックを無効にする必要があります。これにより、すべてのフラッシュバック・ログが削除されます。 |
次の手順では、それぞれのサイズ変更の方法について説明します。
|
関連項目: 各方法のコマンドおよび詳細は、My Oracle Supportノート1467056.1を参照してください。 |
方法1: RECOグリッド・ディスクをローリング形式で再作成する
前提条件が満たされていることを確認します。
RECOとDATAディスク・グループおよびグリッド・ディスクのサイズ変更を計算します。
RECOディスク・グループのOracle ASMディスクのサイズを変更します。
リバランスが完了するまで待機してから、この手順を進めます。
最初のセルでOracle ASM RECOディスクをRECOディスク・グループから削除し、リバランス操作が完了するまで待機します。
最初のセルでRECOグリッド・ディスクを削除します。
セルのDATAグリッド・ディスクのサイズを新しい大きいサイズに変更します。
RECOグリッド・ディスクを新しいサイズで再作成し、ディスクの遅い部分のDBFS_DGの横にグリッド・ディスクが作成されていることを確認します。
新しいRECOグリッド・ディスクをRECOディスク・グループに追加し、リバランス操作が完了するまで待機します。
新しいサイズのDATAグリッド・ディスクを使用できるように、DATAディスク・グループのサイズを変更し、リバランス操作が完了するまで待機します。
すべてのディスク・グループおよびディスク・サイズを確認します。
方法2: RECOディスク・グループを削除して再作成する
高速リカバリ領域(FRA)や制御ファイルなどのRECOディスク・グループの内容を別の場所に移動します。RECOディスク・グループは空にする必要があります。
RECOディスク・グループを削除します。
すべてのセルからRECOグリッド・ディスクを削除します。
すべてのセルで、DATAグリッド・ディスクのサイズを新しいサイズに変更します。
新しいサイズのDATAグリッド・ディスクを使用できるように、DATAディスク・グループのサイズを変更し、リバランス操作が完了するまで待機します。
セルの残りの領域でRECOグリッド・ディスクを再作成します。
新しいサイズのRECOグリッド・ディスクを使用するために、RECOディスク・グループを再作成します。
必要に応じて、FRAおよびすべてのファイルをRECOディスク・グループに移動して戻します。
システム・ディスクで障害が発生した場合、オペレーティング・システムに破損したファイル・システムがある場合またはブート領域が損傷している場合、レスキュー手順が必要です。1つのシステム・ディスクのみで障害が発生した場合、リカバリにCellCLIコマンドを使用します。両方のシステム・ディスクで同時に障害が発生するまれな事例の場合、Oracle Exadata Storage Server Software CELLBOOT USBフラッシュ・ドライブで提供されるExadata Storage Serverレスキュー機能を使用する必要があります。
通常の冗長性を使用している場合、レスキューされるセルのミラー・コピーは1つだけです。レスキュー手順の実行中にこのミラーでも障害が発生すると、リカバリできないデータの損失が発生する可能性があります。ミラー・コピーでデータの完全なバックアップを作成し、すぐにミラー・コピー・セルをオフラインにしてレスキュー前の新しいデータ変更を防止することをお薦めします。これにより、レスキュー・プロセス中は、障害が発生したセルのグリッド・ディスクのすべてのデータおよびそのミラー・コピーにアクセスできなくなります。
Oracle ASMディスク修復タイマーのデフォルトの修復時間は、3.6時間です。この時間内にレスキュー手順を実行できないことがわかった場合、レスキュー手順を実行できるまで、Oracle ASMリバランス手順を使用してディスクをリバランスする必要があります。
|
関連項目: タイマーのリセットの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。 |
障害が発生したセルのすべてのグリッド・ディスクに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はリストアされます。
|
関連項目: ALTER CELLコマンドの詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドを参照してください。 |
Exadata Storage ServerのILOM構成。通常、ILOM構成は、Exadata Cellソフトウェアに障害が発生しても損われません。
レスキュー手順により、データ・ディスクまたはシステム・ディスクのデータ・パーティションの確認または再構築は行われません。グリッド・ディスクにデータの破損がある場合、レスキュー手順は使用しないでください。かわりに、Oracle DatabaseおよびOracle ASMのレスキュー手順を使用してください。
正常なレスキューの実行後、セルを再構成し、データを保存する場合はセル・ディスクをインポートする必要があります。データを保存しない場合は、新しいセル・ディスクおよびグリッド・ディスクを作成する必要があります。
|
関連項目: 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...
任意のキーを押してメニューを表示します。
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ユーザーズ・ガイド』を参照してください。 |
Oracle Exadata Storage Server Softwareリリース11.2.3.3以上では、セルのレスキュー後に追加の手順は不要です。構成を検証するには、次の手順を使用します。
別のストレージ・サーバーにある/opt/oracle.SupportTools/resourcecontrolユーティリティを、リカバリしたサーバーの/opt/oracle.SupportTools/resourcecontrolディレクトリにコピーします。
次のコマンドを使用して、ユーティリティに対して適切な権限が設定されていることを確認します。
# chmod 740 /opt/oracle.SupportTools/resourcecontrol
次のコマンドを使用して、現在の構成を検証します。コマンドの出力が表示されます。
# /opt/oracle.SupprtTools/resourcecontrol -show Validated hardware and OS. Proceed. Number of cores active: 6 Number of harddisks active: 6 Number of flashdisks active: 8
エイス・ラック構成の場合、6個のコア、6個のハード・ディスクおよび8個のフラッシュ・ディスクが有効になっている必要があります。他の値が表示された場合は、次のコマンドを使用して、エイス・ラック構成を有効にしてください。
ALTER CELL eighthRack=true
CELLBOOT USBフラッシュ・ドライブの紛失または損傷が発生した場合、次の手順を使用して新しいドライブを作成できます。
|
注意: Oracle Exadata Storage Server Softwareリリース12.1.2.1.0以上を実行するマシン用のUSBフラッシュ・ドライブを作成するには、Oracle Linux 6を実行するマシンが必要です。 |
rootユーザーとしてセルにログインします。
新しいUSBフラッシュ・ドライブを取り付けます。このフラッシュ・ドライブには、少なくとも1GBから最大8GBの容量が必要です。
システムから他のUSBフラッシュ・ドライブを取り外します。
次のコマンドを実行します:
cd /opt/oracle.SupportTools ./make_cellboot_usb -verbose -force
この項では、既存のエラスティック構成に次の変更を行う方法について説明します。
データベース・サーバーを伴う変更については、「データベース・サーバーの既存のエラスティック構成の変更」を参照してください。
このシナリオでは、ディスク・グループを含む既存の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を問い合せます。
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ストレージ・グリッドにストレージ・セルを追加します。
現在のクラスタからストレージ・セルを廃止します。これを実行するには、「既存のディスク・グループまたはストレージ・グリッドからのストレージ・セルの削除」の手順に従ってください。
目的のExadataストレージ・グリッドにストレージ・セルを追加します。これを実行するには、「セル・ノードの追加」の手順に従ってください。
最新のexachkをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。
このシナリオでは、既存のExadataストレージ・グリッドからストレージ・セルを削除します。
ASMから削除されるセルに属するディスクを削除します。
|
注意: Exadata OVMデプロイメントでは、すべてのVMクラスタから次のサブステップを実行する必要があります。 |
クラスタ内の任意のノードにログインします。
対象となるExadataセルのクラスタで使用されているグリッド・ディスクのリストを問い合せます。
$GI_HOME/bin/asmcmd lsdsk --suppressheader | grep cellName_being_removed | awk -F'/' '{print $NF}'
|
注意: 削除されるストレージ・セルからのディスクを含むすべてのディスク・グループ内の使用可能な空き領域が、そのディスク・グループに割り当てられた記憶域の少なくとも15%であることを確認してください。 |
前述のコマンドで返されたASMディスクをそれぞれのディスク・グループから削除します。
alter diskgroup diskgroup_name drop disks in failgroup cellName_being_removed;
このディスク削除操作により、デフォルトの電源レベルでリバランス操作が開始されます。次のコマンドを使用して、リバランスを監視します。
SQL> select * from gv$asm_operation;
リバランスが完了するまで、つまり、gv$asm_operationから行が返されなくなるまで待ちます。
すべてのディスク・グループが、削除されるセルのディスクを参照していないことを確認します。
SQL> select path, name, header_status, mode_status, mount_status, state, failgroup from v$asm_disk order by path;
削除されるセルに属するすべてのディスクのheader_status列は、「FORMER」と表示される必要があります。
|
注意: Exadata OVMデプロイメントでは、すべてのVMクラスタから前述のサブステップを実行する必要があります。 |
削除するセルをクリーンアップします。celladminとしてセルにログインし、次のコマンドを実行します。
各グリッド・ディスクに対して次のコマンドを実行します。
グリッド・ディスクを削除します。
cellcli -e drop griddisk all prefix=prefix_of_the_grid_disk
フラッシュ・キャッシュが存在し、セルがWriteBackフラッシュ・キャッシュ・モードの場合、削除前にフラッシュ・キャッシュをフラッシュする必要があります。
cellcli -e alter flashcache all flush
コマンドが戻るまで待機します。
フラッシュ・キャッシュを削除します。
cellcli -e drop flashcache all
セル・ディスクを削除します。
cellcli -e drop celldisk all
データを安全に消去するには、DROP CELLDISKコマンドをeraseオプションを指定して実行するか、DROP CELLコマンドをeraseオプションを指定して実行します。
DROP CELLコマンドの下の表内に消去操作の所要時間が表示されます。
クラスタ内のすべてのデータベース・サーバー・ノードの/etc/oracle/cell/network-config/cellip.oraから、削除するセルのエントリを削除します。クラスタ内の任意のデータベース・サーバー・ノードで次の手順を実行します。
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は、クラスタ内の各データベース・サーバーの名前が含まれているファイルを参照します。名前は、それぞれ別の行にあります。
最新のexachkをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。
