3 Oracle ExadataラックのOracle Exadata Storage Serverの保守

この章のトピックは、次のとおりです:

注意:

読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。
この章のすべての手順は、Oracle Exadata Database MachineおよびOracle Exadata Storage拡張ラックに適用されます。

関連トピック

3.1 Oracle Exadata Storage Serverの保守

この項では、Oracle Exadata Storage Serverの保守を実行する方法について説明します。

関連項目:

Oracle ASMディスク修復タイマーの詳細は、『Oracle Exadata System Softwareユーザーズ・ガイド』を参照してください

3.1.1 Exadata Storage Serverのシャットダウン

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の電源の切断方法を示しています。

(オプション)次のコマンドを実行して、セルの再起動後にグリッド・ディスクがオフラインのままになるようにします。
```
CellCLI> ALTER GRIDDISK ALL INACTIVE
```
この手順は、再起動を複数回実行したり、セルを再びアクティブにするタイミングを制御する場合(計画されていた保守アクティビティが成功したことを確認してからセルを使用する場合など)に役立ちます。

注意:
この手順を実行する場合は、手順6を実行してグリッド・ディスクをアクティブにする必要があります。
次のコマンドを使用して、セル・サービスを停止します。
```
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を実行していない場合は、グリッド・ディスクは自動的にアクティブになります。
```
CellCLI> ALTER GRIDDISK ALL ACTIVE
```

関連トピック

Oracle Exadata Storage Serverの電源切断

3.1.2 Exadata Storage Serverの削除

次の手順は、Exadata Storage Serverの削除方法を示しています。

Oracle ASMから次のコマンドを使用して、物理ディスクのOracle ASMディスクを削除します。
```
SQL> ALTER DISKGROUP diskgroup_name DROP DISKS IN FAILGROUP failgroup_name;
```
Oracle ASMの正しい冗長性レベルを確認するには、先に進む前にリバランスの完了を待機します。
Exadata Storage Serverにアクセスする各データベース・サーバーのcellip.oraファイルからIPアドレス・エントリを削除します。
次のコマンドを使用して、Exadata Storage Serverから物理ディスクのグリッド・ディスク、セル・ディスクおよびセルを削除します。
```
CellCLI> DROP CELLDISK
```
Exadata Storage Server上のすべてのサービスをシャットダウンします。
セルの電源を切断します。
関連項目:
Exadata Storage Serverのシャットダウン

3.1.3 リバランス操作のステータスのチェック

ディスクの削除時または追加時に、Oracle ASMリバランス操作のステータスを確認できます。

リバランス操作が正常に完了している可能性があります。Oracle ASMアラート・ログを確認してください。
リバランス操作が現在実行されている可能性がある場合。GV$ASM_OPERATIONビューを確認して、リバランス操作が実行されているかどうか判別します。
リバランス操作が失敗した可能性がある場合。V$ASM_OPERATION.ERRORビューを確認して、リバランス操作が失敗したかどうか判別します。
交換される物理ディスクに複数のディスク・グループのOracle ASMディスクが含まれる場合、複数のディスク・グループのリバランス操作を同じクラスタの異なるOracle ASMインスタンスで実行できます。Oracle ASMインスタンスは、一度に1つのリバランス操作を実行できます。すべてのOracle ASMインスタンスがビジー状態の場合、リバランス操作がキューに入れられます。

注意:

BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata System Softwareリリース12.1.2.0を実行しているOracle Exadata Storage Serverの場合、Oracle ASMはリバランス操作のステータスについての電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。

3.1.4 Oracle Exadata Storage Serverのパッチ適用の理解

ソフトウェアの更新は、patchmgrユーティリティを使用してOracle Exadata Storage Serverに適用します。patchmgrユーティリティにより、Oracle Exadata Storage Serverに必要なすべてのソフトウェアとファームウェアがインストールおよび更新されます。patchmgrユーティリティは、My Oracle Supportからダウンロードするソフトウェア・リリースに付属しています。

注意:

Oracle Exadata Storage Serverでソフトウェアのインストール、変更、再構成または削除を実行する場合は、このガイド『Oracle Exadata System Softwareユーザーズ・ガイド』またはMy Oracle Supportに記載されている特定の指示に必ず従ってください。

Oracle Exadata Storage Serverに対する変更は、特定のOracle Exadataドキュメントに記載がないかぎりサポートされません。

注意:

My Oracle Supportノート888828.1に説明されているように、Oracle Exadata Storage Serverの通常の更新が適用できるのは、ターゲット・リリースの日付スタンプが現在実行中のリリースの日付スタンプより新しい場合のみです。ターゲット・リリースよりも新しい日付スタンプのリリースを実行しているイメージからの更新はブロックされます。

例: Oracle Exadata System Softwareリリース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ユーティリティによるソフトウェアの更新は、構成内のすべてのOracle Exadata Storage Serverが対象となります。ユーティリティでは、ソフトウェアの更新方法としてローリングと非ローリングの両方がサポートされています。ユーティリティでは、パッチ適用の完了通知やローリング/非ローリング・パッチ適用のステータス情報を電子メール・メッセージで送信できます。次に、電子メール・メッセージを送信するためのコマンドを示します。

# ./patchmgr -cells cell_group -patch [-rolling] [-ignore_alerts] [-unkey] \
           [-smtp_from "addr" -smtp_to "addr1 addr2 addr3 ..."]

前述のコマンドのaddrは送信元アドレス、addr1、addr2およびaddr3は送信先アドレスです。

この項では、Oracle Exadata Storage Serverにパッチを適用する各方法およびそれらの相違点について説明します。

関連トピック

sudoによるpatchmgr (およびdbnodeupdateオーケストレーション)の実行

3.1.4.1 ローリング更新の理解

ローリング更新は、デプロイメント全体での停止時間を伴わない方法としても知られます。

この方法の利点:

データベースの停止時間が不要です。

問題が発生した場合に影響を受けるのは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つのセルに対して実行されます。

3.1.4.2 非ローリング更新の理解

非ローリング更新は、デプロイメント全体での停止時間を伴う方法としても知られます。デプロイメント全体で停止するよう選択した場合は、パッチはすべてのセルにパラレルに適用されます。patchmgrユーティリティによりExadataセルにこの機能が提供されます。

この方法の利点:

すべてのセルがパラレルに処理されます。そのため、パッチの適用時間は、適用対象となるセルの数に関係なく、ほぼ一定です。

グリッド・ディスクの非アクティブ化と再アクティブ化に費やす時間がゼロです。
この方法に関する考慮事項:

パッチ適用プロセスの実行中はセルを使用できません。パッチの適用中は、セル・サービスを使用するすべてのデータベースを停止したままにする必要があります。

パッチの適用中にセルの1つで問題が発生した場合は、そのセルの問題が解決するまでデプロイメント全体が使用できなくなります。通常、Oracle Clusterwareを排他モードで起動し、Oracle ASMのディスク・グループをFORCEオプションによってマウントし、その後で問題のあるセルのグリッド・ディスクを削除することによって、データベースを起動することは可能です。ただし、これらの手順を実行することによって、停止時間がさらに延びます。

3.1.5 診断ISOを使用したネットワーク接続の有効化

再起動されないセルにアクセスして手動で修理する場合、診断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
address IP_address_of_cell
netmask netmask_of_cell
gateway gateway_IP_address_of_cell

次のコマンドを使用して、eth0インタフェースを起動します。
```
ifup eth0
 
```
いくつかの警告メッセージが表示される場合もありますが、インタフェースは稼働しています。
FTPまたはwgetコマンドを使用して、セルを修理するためのファイルを取得します。

3.2 Oracle Exadata Storage Serverのハード・ディスクの保守

Oracle Exadataラック内のすべてのOracle Exadata Storage Serverにシステム領域があり、その領域にOracle Exadata System Softwareシステム・ソフトウェアが常駐しています。Oracle Exadata Database Machine X7システムでは、このシステム領域は2つの内蔵M.2デバイスにあります。その他すべてのシステムでは、Oracle Exadata Storage Serverの最初の2つのディスクがシステム・ディスクとなっています。これらのシステム・ディスクの一部はシステム領域と呼ばれています。

Oracle Exadata Database Machine X7システムでは、セル内のハード・ディスクはすべてデータ・ディスクになっています。Oracle Exadata Database Machine X7より前のシステムでは、システム・ディスクのシステム領域以外の部分(データ・パーティションと呼ばれる)が通常のデータ・ストレージとして使用されます。セル内の他のディスクはすべてデータ・ディスクです。

Oracle Exadata System Softwareリリース11.2.3.2.0以降では、ディスク障害が発生すると、Oracle Exadata System Softwareによってディスクが交換可能であることを示すアラートが送信され、そのディスクの外部にすべてのデータがリバランスされた後で予測障害のあるハード・ディスクの青色のLEDが点灯します。リリース11.2.3.2.0より前のOracle Exadata System Softwareでは、ハード・ディスクに予測障害がある場合、青色のLEDではなく黄色のLEDが点灯していました。このような場合、ディスクの交換を進める前に、すべてのデータがそのディスクの外部にリバランスされたかどうかを手動でチェックする必要があります。

Oracle Exadata System Softwareリリース18.1.0.0.0以降およびOracle Exadata Database Machine X7システムでは、冗長性が低くなったことを示すDoNotService LEDが追加され、これにより、システム管理者やフィールド・エンジニアは、サービスのためにストレージ・サーバーの電源を切断することは避ける必要があることがわかります。冗長性がリストアされると、Oracle Exadata System SoftwareによりDoNotService LEDが自動的に消灯され、サービスのセルの電源を切断できることが示されます。

ハード・ディスクで障害が発生すると、ドライブの青色のLEDと黄色のLEDが両方とも点灯し、ディスクの交換を続行できることが示されます。動作はすべてのリリースで同じです。Oracle Exadata System Softwareリリース11.2.3.2.0以降ではドライブLEDが点灯しますが、それより前のリリースではドライブLEDが点滅します。

注意:

Oracle Exadata Storage Serverの物理ディスクを交換しているあいだ、Oracle Exadataラックはオンラインであり、使用可能です。

この項では、次の項目について説明します。

関連項目:

LEDステータスの説明
LIST PHYSICALDISKコマンドの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください
修復タイマーの設定の詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください
Oracle Maximum Availability Architecture (MAA) Webサイト(http://www.oracle.com/goto/maa)
Exadata環境の計算ノードのベア・メタル・リストア手順(My Oracle SupportのドキュメントID 1084360.1)

3.2.1 ハード・ディスクのステータスの監視

CellCLI LIST PHYSICALDISKコマンドを使用して属性をチェックすることによって、ハード・ディスクのステータスを監視できます。

たとえば、ハード・ディスクのステータスが障害 (以前のリリースでは、障害が発生したハード・ディスクのステータスはクリティカルでした)または警告 - 予測障害と同等の場合、問題が発生している可能性があり、交換が必要です。内部しきい値を超えると、ディスク・ファームウェアによってエラー・カウンタが保守され、ドライブはPredictive Failureとマーク付けされます。交換が必要かどうかは、セル・ソフトウェアではなくドライブによって決定されます。

CellCLIコマンドLIST PHSYICALDISKを使用すると、ハード・ディスクのステータスを調べることができます。

CellCLI> LIST PHYSICALDISK WHERE disktype=harddisk AND status!=normal DETAIL
         name:                            8:4
         deviceId:              12
           deviceName:                   /dev/sde
           diskType:                      HardDisk
         enclosureDeviceId:      8
         errOtherCount:          0
         luns:                   0_4
           makeModel:                    "HGST    H7280A520SUN8.0T"
         physicalFirmware:         PD51
         physicalInsertTime:      2016-11-30T21:24:45-08:00
         physicalInterface:     sas
         physicalSerial:            PA9TVR
         physicalSize:               7.153663907200098T
         slotNumber:                  4
         status:                        failed

ディスクI/Oエラーが発生すると、Oracle ASMはメディア・エラーによる読取りエラーの障害範囲の修理を実行します。ディスクはオンラインのままで、アラートは送信されません。Oracle ASMが物理的に対処されたメタデータ・ブロックに関する読取りエラーを取得すると、ブロックはミラーリングされず、ディスクはオフラインになります。その後、Oracle ASMはFORCEオプションを使用してディスクを削除します。

Oracle Exadata Storage Serverのハード・ディスク・ステータスは次のとおりです。

Oracle Exadata System Softwareリリース11.2.3.3以降:
- 正常
- 正常 - 交換のため切断
- 正常 - 制限されたオンライン
- 正常 - 制限されたオンライン - 交換のため切断
- 存在しない
- 失敗
- 障害 - 交換のため切断
- 障害 - 不適切なディスク・モデルのため拒否
- 障害 - 不適切なディスク・モデルのため拒否 - 交換のため切断
- 障害 - 間違ったスロットのため拒否
- 障害 - 間違ったスロットのため拒否 - 交換のため切断
- 警告 - 制限されたオンライン
- 警告 - 制限されたオンライン - 交換のため切断
- 警告 - ピア障害
- 警告 - 低いパフォーマンス
- 警告 - 低いパフォーマンス - 交換のため切断
- 警告 - 低いパフォーマンス、ライトスルー・キャッシュ
- 警告 - 予測障害、低いパフォーマンス
- 警告 - 予測障害、低いパフォーマンス - 交換のため切断
- 警告 - 予測障害、ライトスルー・キャッシュ
- 警告 - 予測障害
- 警告 - 予測障害 - 交換のため切断
- 警告 - 予測障害、低いパフォーマンス、ライトスルー・キャッシュ
- 警告 - ライトスルー・キャッシュ
Oracle Exadata System Softwareリリース11.2.3.2:
- 正常
- 正常 - 制限されたオンライン
- 存在しない
- 失敗
- 障害 - 不適切なディスク・モデルのため拒否
- 障害 - 間違ったスロットのため拒否
- 警告 - 制限されたオンライン
- 警告 - ピア障害
- 警告 - 低いパフォーマンス
- 警告 - 低いパフォーマンス、ライトスルー・キャッシュ
- 警告 - 予測障害、低いパフォーマンス
- 警告 - 予測障害、ライトスルー・キャッシュ
- 警告 - 予測障害
- 警告 - 予測障害、低いパフォーマンス、ライトスルー・キャッシュ
- 警告 - ライトスルー・キャッシュ
Oracle Exadata System Softwareリリース11.2.3.1.1以前:
- 正常
- critical
- 低いパフォーマンス
- 予測障害
- 存在しない

3.2.2 ハード・ディスク・コントローラのライトスルー・キャッシュ・モードの監視

各Oracle Exadata Storage Serverのハード・ディスク・コントローラは、定期的にコントローラのバッテリの放電と充電を実行します。操作中は、書込みキャッシュ・ポリシーにより、ライトバック・キャッシュからライトスルー・キャッシュに変更されます。

ライトスルー・キャッシュ・モードはライトバック・キャッシュ・モードより時間を要します。ただし、Oracle Exadata Storage Serverの電源が落ちたり障害が発生したりすると、ライトバック・キャッシュ・モードの場合はデータ損失のリスクがあります。Oracle Exadata System Softwareリリース11.2.1.3以前の場合は、この処理が毎月発生します。リリース11.2.1.3.0以上のOracle Exadata System 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

Oracle 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 : Charging
Voltage : 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 : No
 
Relative State of Charge: 7 %
Charger System State: 1
Charger System Ctrl: 0
Charging current: 541 mA
Absolute state of charge: 0 %
Max Error: 0 %
 
Exit Code: 0x00

3.2.3 ディスク障害によるハード・ディスクの交換

ハード・ディスクの停止により、パフォーマンスおよびデータの冗長性の低下が発生する場合があります。したがって、すぐにディスクを新しいディスクに交換する必要があります。ディスクに障害が発生すると、ハード・ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションで自動的に削除され、Oracle ASMリバランスでデータの冗長性がリストアされます。

ディスクに障害が発生すると、Exadataアラートが生成されます。アラートには、ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合、電子メールでアラートが指定したアドレスに送信されます。

ハード・ディスクを交換すると、そのスロットの前のディスクにあったグリッド・ディスクとセル・ディスクは新しいハード・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMグループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

注意:

BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata System 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が点灯していることを確認してください。
Oracle 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ファイルをチェックして確認できます。

関連項目:

Exadata Storage Serverの部品
V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
リバランス操作の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

3.2.4 ディスクの問題によるハード・ディスクの交換

ハード・ディスクが警告 - 予測障害ステータスになったために、ディスクの交換が必要になる場合もあります。

予測障害ステータスは、ハード・ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。ハード・ドライブのグリッド・ディスクに関連するOracle ASMディスクが自動的に削除され、Oracle ASMリバランスで障害が発生する可能性のあるディスクから他のディスクにデータが移動されます。

ハード・ドライブが故障する前に削除を完了できなかった場合は、「ディスク障害によるハード・ディスクの交換」を参照してください

ディスクを削除すると、アラートが送信されます。ハード・ディスクを交換すると、スロットの前のディスクにあったグリッド・ディスクとセル・ディスクは新しいハード・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

注意:

BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata System Softwareリリース12.1.2.0を実行しているOracle Exadata Storage Serverでは、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ビューの問合せを実行します。
注意:
Oracle Exadata Database Machine X7以外のすべてのシステムで、最初の2つのスロットのディスクは、オペレーティング・システムおよびOracle Exadata System Softwareを格納するシステム・ディスクになります。1つのシステム・ディスクを稼働して、サーバーを維持する必要があります。

他のシステム・ディスクを交換する前に、ALTER CELL VALIDATE CONFIGURATIONにmdadmエラーが表示されなくなり、システム・ディスクの再同期化が完了するまで待機します。
Oracle Exadata Storage Server上のハード・ディスクを交換し、3分待ちます。ハード・ディスクはホットプラグ対応で、電源の投入時に交換できます。
ディスクがオンラインであることを確認します。
交換したハード・ディスクは、RAIDコントローラによって認識されるまで使用できません。この処理にあまり時間は要しません。LIST PHYSICALDISKコマンドを使用して、ステータスがNORMALであることを確認します。
```
CellCLI> LIST PHYSICALDISK WHERE name=28:3 ATTRIBUTES status
```
ALTER CELL VALIDATE CONFIGURATIONコマンドを使用して、ファームウェアが正しいことを確認します。

関連項目:

Exadata Storage Serverの部品
V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
リバランス操作のチューニングの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
V$ASM_DISK_STATビューの問合せの詳細は、『Oracle Databaseリファレンス』を参照してください。
『Oracle Exadata System Softwareユーザーズ・ガイド』のALTER CELL VALIDATE CONFIGURATIONコマンドに関する項

3.2.5 低いパフォーマンスによるハード・ディスクの交換

1つの不良ハード・ディスクが、他の正常なディスクのパフォーマンスを低下させることがあります。不良ディスクはそのままにしないでシステムから削除する必要があります。

Oracle Exadata System Softwareリリース11.2.3.2以降では、パフォーマンスの低いディスクが自動的に識別され、アクティブな構成から削除されます。その後、Oracle Exadata Database Machineにより一連のパフォーマンス・テストが実行されます。CELLSRVでパフォーマンスの低いディスクが検出されると、セル・ディスクのステータスが正常 - 制限されたオンラインに変更され、ハード・ディスクのステータスが警告 - 制限されたオンラインに変更されます。

次の状況はディスク制限のトリガーとなります。

ディスクの応答停止。ストレージ・アラート・ログ内の原因コードは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としてマークされ、Oracle Auto Service Request (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 System Softwareリリース11.2.3.2より前のリリースでは、CALIBRATEコマンドを使用して不良ハード・ディスクを識別し、各ハード・ディスクについてスループットやIOPSが極端に低くないか調べてください。

次の手順は、不良ディスクが確認された場合のハード・ディスクの取外し方法を示しています。

次のようなコマンドを使用してハード・ドライブのサービスLEDを点灯させ、交換対象のドライブを特定します。ここで、disk_nameは交換対象のハード・ディスクの名前です(20:2など)。
```
cellcli -e 'alter physicaldisk disk_name serviceled on'
```

不良ディスクのすべてのグリッド・ディスクを確認します。

次に例を示します。

[root@exa05celadm03 ~]# cellcli -e "list physicaldisk 20:11 attributes name, id"
        20:11 RD58EA 
[root@exa05celadm03 ~]# cellcli -e "list celldisk where physicalDisk='RD58EA'"
        CD_11_exa05celadm03 normal 
[root@exa05celadm03 ~]# cellcli -e "list griddisk where cellDisk='CD_11_exa05celadm03'"
        DATA_CD_11_exa05celadm03 active
        DBFS_CD_11_exa05celadm03 active
        RECO_CD_11_exa05celadm03 active
        TPCH_CD_11_exa05celadm03 active

Oracle ASMに不良ディスクの使用をただちに停止するよう指示します。
```
SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name;
```
ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
V$ASM_DISK_STATビューの問合せを実行して、不良ディスクのグリッド・ディスクに関連するOracle ASMディスクが正しく削除されたことを確認します。
不良ディスクを取り外します。ディスクを削除すると、アラートが送信されます。
新しいディスクを使用できる場合、システムに新しいディスクを設置します。セル・ディスクおよびグリッド・ディスクが新しいハード・ディスクに自動的に作成されます。
注意:
交換したハード・ディスクは、RAIDコントローラによって認識されるまで使用できません。承認処理に時間はかかりませんが、LIST PHYSICALDISKコマンドを使用してステータスがNORMALであることを確認してください。

関連項目:

Oracle Exadata System Softwareユーザーズ・ガイド
ディスク・グループからのディスクの削除の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

3.2.6 ハード・ディスクの事前交換

Exadata Storageソフトウェアでは、ハード・ディスクで障害が発生したり、問題のあるディスクとしてフラグ付けされた場合に、自動化された一連の操作でディスクを保守できます。ただし、状況によっては、構成からハード・ディスクを事前に取り外すことが必要になります。

CellCLIのALTER PHYSICALDISKコマンドでは、drop for replacementオプションによって、データ損失のリスクなく安全に、正常に機能しているハード・ディスクを削除できるかどうかが確認されます。ただし、コマンドを実行した後、ストレージ・セルでハード・ディスクのグリッド・ディスクが非アクティブ化され、Oracle ASMディスク・グループでオフラインに設定されます。

ハード・ディスクが交換または再有効化され、後続のリバランスが完了するまで、ディスク・グループの冗長性が損なわれます。このことは、標準冗長性を使用するディスク・グループにおいて特に重要です。

ディスク・グループで十分な冗長性を確保できないリスクを抑えて、事前にハード・ディスクを交換するには、次の手順を実行します。

ハード・ディスクに関連付けられたLUN、セル・ディスクおよびグリッド・ディスクを特定します。
次のようなコマンドを使用します。ここで、X:Yは交換するドライブのハード・ディスク名を示します。
```
# cellcli –e "list diskmap" | grep 'X:Y'
```
出力は次のようになります。
```
   20:5            KEBTDJ          5                       normal  559G           
    CD_05_exaceladm01    /dev/sdf                
    "DATAC1_CD_05_exaceladm01, DBFS_DG_CD_05_exaceladm01, 
     RECOC1_CD_05_exaceladm01"
```
LUNを取得するには、次のようなコマンドを発行します。
```
CellCLI> list lun where deviceName='/dev/sdf/'
         0_5     0_5     normal
```
通常のモードで、Oracle ASMディスク・グループからグリッド・ディスクを削除します。
```
SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name;
```
リバランスが完了するまで待ちます。
drop for replacementを実行します。
次のようなコマンドを使用します。ここで、X:Yは交換するドライブのハード・ディスク名を示します。
```
CellCLI> alter physicaldisk X:Y drop for replacement
```
ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認します。
新しいハード・ディスクに交換します。
ハード・ディスクに関連付けられたLUN、セル・ディスクおよびグリッド・ディスクが作成されていることを確認します。
```
CellCLI> list lun lun_name
CellCLI> list celldisk where lun=lun_name
CellCLI> list griddisk where celldisk=celldisk_name
```
グリッド・ディスクがOracle ASMディスク・グループに追加されたことを確認します。
次の問合せでは行が戻されません。
```
SQL> SELECT path,header_status FROM v$asm_disk WHERE group_number=0;
```
次の問合せでは、すべての障害グループのディスク数が同じかどうかが示されます。
```
SQL> SELECT group_number, failgroup, mode_status, count(*) FROM v$asm_disk
     GROUP BY group_number, failgroup, mode_status;
```

3.2.7 別のExadata Storage Serverへのすべてのドライブの移動

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に移動します。
注意:
- システム・ディスクの最初の2つのディスクが同じ最初の2つのスロットにあることを確認してください。そうしないと、Exadata Storage Serverが正常に機能しません。
- フラッシュ・カードが元のExadata Storage Serverと同じPCIeスロットに設置されていることを確認してください。
サービス・プロセッサ・インタフェースまたは電源ボタンを使用して、新しいExadata Storage Serverの電源を投入します。
サービス・プロセッサまたはKVMスイッチを使用して、コンソールにログインします。
次のディレクトリのファイルを確認します。破損している場合、バックアップからリストアします。
- /etc/hosts
- /etc/modprobe.conf
- /etc/sysconfig/network
- /etc/sysconfig/network-scripts

ifconfigコマンドを使用して、eth0、eth1、eth2およびeth3の新しい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をアクティブ化します。

関連項目:

Oracle Exadata Database Machine Oracle Auto Service Requestクイック・インストレーション・ガイド
Oracle Exadata System Softwareユーザーズ・ガイド
CellCLIユーティリティの詳細
ディスク修復時間の詳細は、Oracle Automatic Storage Management管理者ガイドを参照してください

3.2.8 ハード・ディスクの再利用

ディスクのすべてのデータを削除し、別の目的でディスクを使用できます。

ハード・ディスクを再利用する前に、ディスクのデータをコピーしてください。

システム・ディスク(ディスク0およびディスク1)に対してこの手順を使用した場合は、データ・パーティションのみが消去され、システム・パーティションは消去されません。

CellCLIのLISTコマンドを使用して、Exadata Storage Serverオブジェクトを表示します。ハード・ドライブのグリッド・ディスクおよびセル・ディスクを確認する必要があります。次に例を示します。
```
CellCLI> LIST PHYSICALDISK
         20:0   D174LX    normal
         20:1   D149R0    normal
         ...
```

次のようなコマンドを使用して、LUNのセル・ディスクおよびグリッド・ディスクを特定します。

CellCLI> LIST LUN WHERE physicalDrives='20:0' DETAIL
  name:              0_0
  deviceName:        /dev/sda
  diskType:          HardDisk
  id:                0_0
  isSystemLun:       TRUE
  lunSize:           557.861328125G
  lunUID:            0_0
  physicalDrives:    20:0
  raidLevel:         0
  lunWriteCacheMode: "WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU"
  status:            normal

セル・ディスクおよびグリッド・ディスクを取得するには、次のようなコマンドを使用します。

#cellcli -e "list diskmap" | grep 20:0

   20:0            K68DWJ          0                       normal  559G
   CD_00_burd01celadm01    /dev/sda3   
   "DATAC1_CD_00_burd01celadm01, RECOC1_CD_00_burd01celadm01"

Oracle ASMから次のコマンドを使用して、ハード・ディスクのOracle ASMディスクを削除します。
```
SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name;
```
Exadata Storage Serverから次のコマンドを使用して、ハード・ディスクのセル・ディスクおよびグリッド・ディスクを削除します。
```
CellCLI> 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
```
ホット削除するドライブを削除します。次に例を示します。
```
CellCli> ALTER PHYSICALDISK 20:0 DROP FOR REPLACEMENT
```
ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。
注意:
ドライブを取り外す前に、ディスクの青色のLEDが点灯していることを確認します。青色のLEDが消灯している場合にドライブを取り外すと、システムがクラッシュする場合があるため、取り外さないでください。
再利用するディスクを取り外し、新しいディスクを挿入します。
新しいハード・ディスクがLUNとして追加されるまで待機します。
```
CellCLI> LIST LUN
```
セル・ディスクとグリッド・ディスクが新しいハード・ディスクに自動的に作成され、グリッド・ディスクがOracle ASMグループに追加されます。

関連トピック

Oracle Exadata System Softwareユーザーズ・ガイド

3.2.9 同じハード・ディスクの取外しおよび交換

誤って意図しないハード・ディスクを取り外した場合はどうなるでしょうか。

不注意で間違ったハード・ディスクを取り外した場合、ディスクを元に戻します。Oracle ASMディスク・グループに自動的に追加され、そのデータは再同期化されます。

注意:

ディスク障害またはディスクの問題でディスクを交換すると、ディスク上でLEDが点灯し識別できます。

3.2.10 拒否されたハード・ディスクの再有効化

不適切なスロットに挿入されたことが原因で物理ディスクが拒否された場合は、ディスクを再び有効にすることができます。

次のコマンドを実行します。

注意:

次のコマンドでは、物理ディスク上のデータをすべて削除します。

CellCLI> ALTER PHYSICALDISK hard_disk_name reenable force

次に、コマンドの出力例を示します。

Physical disk 20:0 was reenabled.

3.3 Oracle Exadata Storage Serverのフラッシュ・ディスクの保守

データはExadataセル間でミラー化され、書込み操作が少なくとも2つのストレージ・セルに送信されます。Oracle Exadata Storage Serverのフラッシュ・カードに問題が発生すると、別のOracle Exadata Storage Serverのミラー化されたデータによって読取りおよび書込み操作が実行されます。アプリケーションでサービスの中断は発生しません。

フラッシュ・カードに障害が発生すると、Oracle Exadata System Softwareは残存ミラーからデータを読み取り、フラッシュ・キャッシュのデータを確認します。次に、フラッシュ・カードに障害が発生したセルにデータが書き込まれます。障害が発生したフラッシュ・キャッシュ内での損失データの場所が、Oracle Exadata System Softwareによってフラッシュの障害発生時に保存されます。損失データをミラー・コピーに置き換えることにより、復元が開始されます。復元中、グリッド・ディスクのステータスはACTIVE -- RESILVERING WORKINGになります。

3.3.1 フラッシュ・ディスク障害によるフラッシュ・ディスクの交換

Exadata Storage Serverには、それぞれフラッシュ・デバイスが付属しています。

Exadata Database Machine X7以上では、フラッシュ・デバイスはExtreme Flash (EF)セルとHigh Capacity (HC)セルの両方でホットプラグに対応しています。Exadata Database Machine X7でフラッシュ・デバイスのホットプラグ交換を実行する場合は、ディスク・ステータスが交換のため切断になり、かつフラッシュ・カードの電源LEDが消灯している必要があり、このことは、フラッシュ・ディスクのオンライン交換が可能であることを示します。

注意:

電源LEDが点灯しているカードを取り外すと、システムがクラッシュする可能性があります。障害が発生したディスクのステータスが"障害 - 交換のため切断"であるのに電源LEDがまだ点灯している場合は、Oracleサポートに連絡してください。

Exadata Database Machine X6以下では、フラッシュ・デバイスはEFセルではホットプラグに対応していますが、HCセルでは対応していません。HCセルでは、交換前にセルの電源を切る必要があります。

障害が発生したフラッシュ・ディスクを確認するには、次のコマンドを使用します。

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

次に、Oracle Flash Accelerator F160 PCIeカードからの出力例を示します。

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS=failed DETAIL

         name:                   FLASH_5_1
         deviceName:             /dev/nvme1n1
         diskType:               FlashDisk
         luns:                   5_1
         makeModel:              "Oracle Flash Accelerator F160 PCIe Card"
         physicalFirmware:       8DV1RA13
         physicalInsertTime:     2016-11-30T21:24:45-08:00
         physicalSerial:         1030M03UYM
         physicalSize:           1.4554837569594383T
         slotNumber:             "PCI Slot: 5; FDOM: 1"
         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

PCIeカードの場合、nameおよびslotNumber属性は、PCIスロットおよびFDOM番号を示します。Extreme Flashセルの場合、slotNumber属性は、前面パネルのNVMeスロットを示します。

Exadata Database Machine X7システムでは、すべてのフラッシュ・ディスクがAdd-in-Card (AIC)方式でマザーボードのPCIeスロットに挿入されます。X7システムでは、slotNumber属性は、EFセルかHCセルかを問わず、PCI番号およびFDOM番号を示します。

フラッシュ・ディスクの障害が検出されると、フラッシュ・ディスクとそのLUNで障害が発生したことを示すアラートが生成されます。アラート・メッセージには、PCIスロット番号とFDOM番号か、またはNVMeスロット番号が含まれています。これらの番号により、フィールド交換可能ユニット(FRU)が一意に識別されます。システムのアラート通知を構成している場合は、指定したアドレスにアラートが電子メール・メッセージで送信されます。

フラッシュ・ディスクの停止により、パフォーマンスの低下およびデータの冗長性が発生する場合があります。できるだけすぐに障害が発生したディスクを新しいフラッシュ・ディスクに交換する必要があります。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、セルの有効なキャッシュ・サイズが縮小します。フラッシュ・ログにフラッシュ・ディスクを使用する場合、ディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、FORCEオプションによってグリッド・ディスクに関連するOracle ASMディスクがOracle ASMディスク・グループから自動的に削除され、Oracle ASMリバランスでデータの冗長性のリストアが開始されます。

次の手順は、フラッシュ・ディスクのオンライン交換をサポートしていないHigh Capacityセルでディスク障害が発生した場合にFDOMを交換する方法を示しています。Extreme FlashセルでのNVMeドライブの交換は、物理ディスクの交換と同様に、前面パネルからNVMeドライブを取り外して新しいものを挿入するのみです。セルを停止する必要はありません。

セルを停止します。Exadata Storage Serverのシャットダウンを参照してください
PCI番号およびFDOM番号に基づいて、障害が発生したフラッシュ・ディスクを交換します。白色のセルLEDが点灯し、影響を受けているセルを特定できます。
セルの電源を投入します。セル・サービスが自動的に開始されます。セルの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にONLINEになります。
次のコマンドを使用して、すべてのグリッド・ディスクが正常にオンラインになったことを確認します。
```
CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus
         data_CD_00_testceladm10     ONLINE
         data_CD_01_testceladm10     ONLINE
         data_CD_02_testceladm10     ONLINE
         ...
```
すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

新しいフラッシュ・ディスクがシステムによって自動的に使用されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

関連項目:

フラッシュ・ディスクのホットプラグ交換の実行
交換部品情報およびサービス・ガイドのリンクは、「Exadata Storage Serverの部品」を参照してください
Oracle DatabaseリファレンスのV$ASM_OPERATION
『Oracle Automatic Storage Management管理者ガイド』のASM_POWER_LIMITに関する項
「関連ドキュメント」に記載されている、ご使用のシステムに適したPCIeカード・ユーザーズ・ガイド

3.3.2 フラッシュ・ディスクの問題によるフラッシュ・ディスクの交換

Exadata Storage Serverには、4枚のPCIeカードが付属しています。各カードに4個のフラッシュ・ディスク(FDOM)があり、合計16個のフラッシュ・ディスクが提供されます。4枚のPCIeカードは、PCIスロット番号1、2、4および5にあります。Exadata Database Machine X7以上では、セルの電源を切断しなくてもPCIeカードを交換できます。フラッシュ・ディスクのホットプラグ交換の実行を参照してください。

Exadata Database Machine X6以下のシステムでは、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によりアラートが送信されます。

X7システムでは、High CapacityとExtreme Flashの両方のセル上の各フラッシュ・カードはフィールド交換可能ユニット(FRU)です。フラッシュ・カードはホットプラグにも対応しており、セルを停止しなくても取り外すことができます。

X5およびX6システムでは、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:               FLASH_1_1
         deviceName:         /dev/nvme3n1
         diskType:           FlashDisk
         luns:               1_1
         makeModel:          "Oracle Flash Accelerator F160 PCIe Card"
         physicalFirmware:   8DV1RA13
         physicalInsertTime: 2016-11-30T21:24:45-08:00
         physicalSerial:     CVMD519000251P6KGN
         physicalSize:       1.4554837569594383T
         slotNumber:         "PCI Slot: 1; FDOM: 1"
         status:             warning - predictive failure

poor performanceのフラッシュ・ディスクを確認するには、次のコマンドを使用します。

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS= \
'warning - poor performance' DETAIL

         name:                FLASH_1_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 X6以下のセルでのフラッシュ・ディスクの交換方法を示しています。

注意:

Extreme Flash X6セルおよびすべてのX7セルでは、前面パネルからフラッシュ・ディスクを取り外して新しいものを挿入するのみです。セルを停止する必要はありません。

次のコマンドを使用して、セル・サービスを停止します。
```
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パラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

関連項目:

フラッシュ・ディスクの問題によるフラッシュ・ディスクの交換
Exadata Storage Serverのシャットダウン
部品番号情報およびサービス・ガイドのリンクは、「Exadata Storage Serverの部品」を参照してください。
V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
ASM_POWER_LIMITの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
CellCLIユーティリティの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください
「関連ドキュメント」に記載されている、ご使用のシステムに適したPCIeカード・ユーザーズ・ガイド

3.3.3 フラッシュ・ディスクのホットプラグ交換の実行

Exadata Database Machine X7以上では、フラッシュ・ディスクはExtreme Flash (EF)セルとHigh Capacity (HC)セルの両方でホットプラグに対応しています。

Exadata Database Machine X6以下では、フラッシュ・デバイスはEFセルではホットプラグに対応していますが、HCセルでは対応していません。Exadata Database Machine X6以下のシステムのHCセルでは、セルの電源を切断してから、フラッシュ・ディスクを交換する必要があります。

フラッシュ・ディスクの交換が可能かどうかを調べます。

Exadata Database Machine X7でフラッシュ・デバイスのホットプラグ交換を実行する場合は、ディスク・ステータスが交換のため切断になっている必要があり、このことは、フラッシュ・ディスクのオンライン交換が可能であることを示します。

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS LIKE '.*dropped 
for replacement.*' DETAIL

         name:               FLASH_6_1
         deviceName:         /dev/nvme0n1
         diskType:           FlashDisk
         luns:               6_0
         makeModel:          "Oracle Flash Accelerator F640 PCIe Card"
         physicalFirmware:   QDV1RD09
         physicalInsertTime: 2017-08-11T12:25:00-07:00
         physicalSerial:     PHLE6514003R6P4BGN-1
         physicalSize:       2.910957656800747T
         slotNumber:         "PCI Slot: 6; FDOM: 1"
         status:             failed - dropped for replacement

PCI番号およびFDOM番号に基づいて、障害が発生したフラッシュ・ディスクを特定します。
白色のセルLEDが点灯し、影響を受けているセルを特定できます。黄色の注意LEDが点灯し、影響を受けているフラッシュ・カードが示されます。
カードの電源LEDが消灯していることを確認します。
注意:
電源LEDが点灯しているカードを取り外すと、システムがクラッシュする可能性があります。障害が発生したディスクのステータスが"障害 - 交換のため切断"であるのに電源LEDがまだ点灯している場合は、Oracleサポートに連絡してください。
障害が発生したフラッシュ・ディスクを取り外して交換します。

3.3.4 ソフトウェア・バージョン11.2.3.3.1以上のライトバック・フラッシュ・キャッシュの有効化および無効化

リリース11.2.3.2.1以上では、Exadataスマート・フラッシュ・キャッシュにより、頻繁にアクセスするデータを高速のソリッド状態の記憶装置に透過的にキャッシュして、問合せの応答時間とスループットを向上させることができます。ディスクではなくフラッシュによって処理される書込み操作は、「ライトバック・フラッシュ・キャッシュ」と呼ばれます。この機能は必要に応じて有効または無効にできます。フラッシュ・キャッシュ・モードを変更する場合は、次の点に注意してください。

ストレージ・セル・ソフトウェアのリリース11.2.3.3.1以上では、セルのサービスを停止する必要も、グリッド・ディスクを非アクティブ化する必要もありません。
ライトバック・フラッシュ・キャッシュを使用するには、GridホームとOracle DatabaseホームがOracle Database 11gリリース11.2.0.3 BP9以上であることが必要です。

注意:

フラッシュ・キャッシュを削除し、再作成すると、キャッシュがウォームアップするまで、データベースの再起動の際にパフォーマンスに影響を与える可能性があります。

この項では、次の項目について説明します。

3.3.4.1 11.2.3.3.1以上でのライトバック・フラッシュ・キャッシュの有効化

ストレージ・サーバーでのライトバック・フラッシュ・キャッシュを有効にして、問合せの応答時間とスループットを向上させます。

注意:

リリース11.2.3.3.1以上では、cellsrvプロセスを停止する必要も、グリッド・ディスクを非アクティブ化する必要もありません。
アプリケーションのパフォーマンスへの影響を抑えるには、ワークロードが低い期間にライトバック・フラッシュ・キャッシュを有効化します。

フラッシュ・キャッシュを変更する前に、すべての物理ディスクが正常な状態であることを検証します。
次のコマンドでは行が戻されません。
```
# dcli –l root –g cell_group cellcli –e “list physicaldisk attributes name,status”|grep –v NORMAL
```

フラッシュ・キャッシュを削除します。

# dcli –l root –g cell_group cellcli -e drop flashcache

flashCacheMode属性をwritebackに設定します。

# dcli –l root – g cell_group cellcli -e "alter cell flashCacheMode=writeback"

フラッシュ・キャッシュを再作成します。

# dcli –l root –g cell_group cellcli -e create flashcache all

flashCacheModeがwritebackに設定されていることを確認します。

# dcli –l root –g cell_group cellcli -e list cell detail | grep flashCacheMode

グリッド・ディスク属性のcachingPolicyとcachedbyを検証します。
```
# cellcli –e list griddisk attributes name,cachingpolicy,cachedby
```

3.3.4.2 11.2.3.3.1以上でのライトバック・フラッシュ・キャッシュの無効化

ストレージ・サーバーでのライトバック・フラッシュ・キャッシュを無効にする必要がある場合は、次の手順を使用します。

注意:

リリース11.2.3.3.1以上では、cellsrvプロセスを停止する必要も、グリッド・ディスクを非アクティブ化する必要もありません。
アプリケーションのパフォーマンスへの影響を抑えるには、ワークロードが低い期間にライトバック・フラッシュ・キャッシュを無効化します。

フラッシュ・キャッシュを変更する前に、すべての物理ディスクが正常な状態であることを検証します。
次のコマンドでは行が戻されません。
```
# dcli –l root –g cell_group cellcli –e “LIST PHYSICALDISK ATTRIBUTES name,status”|grep –v NORMAL
```

フラッシュ・キャッシュ内のダーティ・データの量を確認します。

# 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"

フラッシュ・キャッシュのフラッシュの進捗状況をチェックします。
FC_BY_DIRTYが0MBになると、フラッシュ・プロセスは完了します。
```
# dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES name,metricvalue WHERE name LIKE \'FC_BY_DIRTY.*\' " 
```
属性flushstatusがCompletedに設定されたかどうかを確認することもできます。
```
# dcli -g cell_group -l root cellcli -e "LIST CELLDISK ATTRIBUTES name, flushstatus, flusherror" | grep FD 
```
フラッシュ・キャッシュのフラッシュが完了した後、フラッシュ・キャッシュを削除します。
```
# dcli -g cell_group -l root cellcli -e drop flashcache 
```

flashCacheMode属性をwritethroughに設定します。

# dcli -g cell_group -l root cellcli -e "ALTER CELL flashCacheMode=writethrough"

フラッシュ・キャッシュを再作成します。

# dcli –l root –g cell_group cellcli -e create flashcache all

flashCacheModeがwritethroughに設定されていることを確認します。

# dcli –l root –g cell_group cellcli -e list cell detail | grep flashCacheMode

3.3.5 11.2.3.3.1より前のソフトウェア・バージョンでのライトバック・フラッシュ・キャッシュの有効化および無効化

flashCacheMode属性を変更する前に、セル・サービスをシャットダウンする必要があります。セル・サービスは、ローリング形式または全体シャットダウンとしてシャットダウンできます。
変更をローリング形式で行う場合は、セル・サービスの再同期が完了していることを確認してから、次のセルを変更してください。
フラッシュ・キャッシュ・モードをローリング形式で変更する場合は、次のセルに移る前に、現在のセルのすべてのグリッド・ディスクでasmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。グリッド・ディスクの属性をチェックするには、次のコマンドを使用します。
```
LIST GRIDDISK ATTRIBUTES asmDeactivationOutcome, asmModeStatus
```
変更を非ローリング形式で行う場合は、クラスタ全体を停止してから、変更を開始してください。
フラッシュ・キャッシュ・モードを非ローリング形式で変更する場合は、Oracle Clusterware CRSとすべてのデータベースを含め、クラスタ全体を停止してください。
ライトバック・フラッシュ・キャッシュを使用するには、GridホームとOracle DatabaseホームがOracle Database 11gリリース11.2.0.3 BP9以上であることが必要です。

注意:

この項では、次の項目について説明します。

3.3.5.1 ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

フラッシュ・キャッシュの属性をwritethroughからwritebackに変更するには、まず、そのフラッシュ・キャッシュを削除しておく必要があります。

ライトバック・フラッシュ・キャッシュは、ローリング形式で有効化できます。

注意:

ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。

関連項目:

My Oracle Supportノート888828.1には、Oracle Exadata System Software、Oracle 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属性をチェックします。
```
CellCLI> LIST GRIDDISK ATTRIBUTES name,asmdeactivationoutcome,asmmodestatus
```
asmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。
次のセルに対して前述の手順を繰り返します。

3.3.5.2 非ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

属性をwritethroughからwritebackに変更する場合は、属性を変更する前にフラッシュ・キャッシュを削除する必要があります。次の手順では、ライトバック・フラッシュ・キャッシュを非ローリング形式で有効にする方法について説明します。

注意:

関連項目:

データベース・ノードにrootユーザーとしてログインします。

クラスタ全体を停止します。

# cd $Grid_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 $Grid_home/bin
# ./crsctl start cluster -all

3.3.5.3 ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

flashCacheMode属性をwritebackからwritethroughに変更したときに、既存のフラッシュ・キャッシュが存在していると、エラーが表示されます。属性をwritethroughに変更する前に、フラッシュ・キャッシュをフラッシュして削除する必要があります。フラッシュ操作が開始されると、フラッシュ・キャッシュへのすべてのキャッシュが停止されます。次の手順では、ライトバック・フラッシュ・キャッシュをローリング形式で無効にする方法について説明します。

注意:

ライトバック・フラッシュ・キャッシュを無効にする最初のセルに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)を実行した後、別のセルにそれらを実行します。
1. 次のコマンドを使用して、フラッシュ・キャッシュを削除します。
```
# cellcli -e DROP FLASHCACHE
```
2. 次のコマンドを使用して、セルのグリッド・ディスクをすべて非アクティブ化します。
```
# cellcli -e ALTER GRIDDISK ALL INACTIVE
```
3. 次のコマンドを使用して、CELLSRVサービスを停止します。
```
# cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV
```
4. 次のコマンドを使用して、flashCacheMode属性をwritethroughに設定します。
```
# cellcli -e "ALTER CELL FLASHCACHEMODE=writethrough"
```
5. 次のコマンド使用して、セル・サービスを再起動します。
```
# cellcli -e ALTER CELL STARTUP SERVICES CELLSRV
```
6. 次のコマンドを使用して、セルのグリッド・ディスクを再アクティブ化します。
```
# cellcli -e ALTER GRIDDISK ALL ACTIVE
```
7. 次のコマンドを使用して、フラッシュ・キャッシュを再作成します。
```
# cellcli -e CREATE FLASHCACHE ALL
```
8. 次のコマンドを使用して、セルのステータスをチェックします。
```
# cellcli -e LIST CELL DETAIL | grep flashCacheMode
```
9. 次のコマンドを使用して、グリッド・ディスクのasmDeactivationOutcome属性とasmModeStatus属性をチェックします。
```
# cellcli -e LIST GRIDDISK ATTRIBUTES name,status,asmdeactivationoutcome,asmmodestatus
```
  asmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。
  
  ディスク・ステータスがSYNCINGの場合は、続行せずにACTIVEになるまで待ちます。

3.3.5.4 非ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

flashCacheMode属性をwritebackからwritethroughに変更したときに、既存のフラッシュ・キャッシュが存在していると、エラーが表示されます。属性をwritethroughに変更する前に、フラッシュ・キャッシュをフラッシュして削除する必要があります。フラッシュ操作が開始されると、フラッシュ・キャッシュへのすべてのキャッシュが停止されます。次の手順では、ライトバック・フラッシュ・キャッシュを非ローリング形式で無効にする方法について説明します。

注意:

ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。
フラッシュ・キャッシュのフラッシュ操作は、クラスタ全体を停止する前に実行できます。

ライトバック・フラッシュ・キャッシュを無効にする最初のデータベース・ノードに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
```

3.3.6 フラッシュ・キャッシュの圧縮の有効化

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拡張圧縮オプションが必要です。
フラッシュ・キャッシュの圧縮を有効にした場合、ユーザー・データは保持されません。

次の手順では、フラッシュ・キャッシュの圧縮を有効にする方法について説明します。

この手順は、ライトバック・フラッシュ・キャッシュが有効化されている場合にのみ実行します。ライトバック・フラッシュ・キャッシュが無効の場合は、この手順をスキップします。ライトバック・フラッシュ・キャッシュが無効の場合にこの手順を実行すると、エラー・メッセージが表示される場合があります。次のコマンドを実行してフラッシュ・キャッシュ・モードを確認できます。
```
# cellcli -e LIST CELL DETAIL | grep flashCacheMode
```
ライトバック・フラッシュ・キャッシュが有効化されている場合は、フラッシュ・セル・ディスクにユーザー・データを保存します。
```
# cellcli -e ALTER FLASHCACHE ALL FLUSH
```
フラッシュ操作の進行中は、flushstatus属性の値がworkingになります。フラッシュ操作が正常に完了すると、値がcompleteに変更されます。グリッド・ディスクの属性cachedbyはnullである必要があります。また、フラッシュが完了すると、ダーティ・バッファ(フラッシュされていないもの)の数が0になります。
```
# cellcli -e LIST METRICCURRENT FC_BY_DIRTY
          FC_BY_DIRTY     FLASHCACHE      0.000 MB
```
セルからフラッシュ・キャッシュを削除します。
```
# cellcli -e DROP FLASHCACHE ALL
```
セルからフラッシュ・ログを削除します。
```
# cellcli -e DROP FLASHLOG ALL
```
フラッシュ・ディスク上のセル・ディスクを削除します。
```
# cellcli -e DROP CELLDISK ALL FLASHDISK
```
システムに応じて、次のコマンドを使用してフラッシュ・キャッシュの圧縮を有効にします。
- Oracle Exadata System Softwareリリース11.2.3.3.1以降を使用したOracle Exadata Database Machine X3-2、Oracle Exadata Database Machine X3-8およびOracle Exadata Database Machine X4-2のストレージ・サーバーの場合:
```
# cellcli -e ALTER CELL flashcachecompress=true
```
- Oracle Exadata System Softwareリリース11.2.3.3.0を使用したOracle Exadata Database Machine X3-2のストレージ・サーバーの場合:
```
# cellcli -e ALTER CELL flashCacheCompX3Support=true
# cellcli -e ALTER CELL flashCacheCompress=true
```
物理ディスクのサイズが増えていることを確認します。
```
# cellcli -e LIST PHYSICALDISK attributes name,physicalSize,status WHERE disktype=flashdisk
```
ステータスは正常である必要があります。次の情報を使用して、圧縮をオンにしたときの想定サイズを検証します。
- Aura 2.0/F40/X3:
  - 物理ディスク・サイズ: 93.13G (オフ)または186.26G (オン)
  - フラッシュ・キャッシュ・サイズ: 1489G (オフ)または2979G (オン)
- Aura 2.1/F80/X4:
  - 物理ディスク・サイズ: 186.26G (オフ)または372.53G (オン)
  - フラッシュ・キャッシュ・サイズ: 2979G (オフ)または5959G (オン)

フラッシュ・ディスク上にセル・ディスクを作成します。

# 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

3.3.7 フラッシュ・キャッシュの圧縮の無効化

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
```
グリッド・ディスクの属性cachedbyはnullである必要があります。また、フラッシュが完了すると、ダーティ・バッファ(フラッシュされていないもの)の数が0になります。
```
# cellcli -e LIST METRICCURRENT FC_BY_DIRTY
          FC_BY_DIRTY     FLASHCACHE      0.000 MB
```
セルからフラッシュ・キャッシュを削除します。
```
# cellcli -e DROP FLASHCACHE ALL
```
セルからフラッシュ・ログを削除します。
```
# cellcli -e DROP FLASHLOG ALL
```
フラッシュ・ディスク上のセル・ディスクを削除します。
```
# cellcli -e DROP CELLDISK ALL FLASHDISK
```
システムに応じて、次のコマンドを使用してフラッシュ・キャッシュの圧縮を無効にします。
- Exadata Storage Cell Serverイメージが11.2.3.3.1以上で、Exadata Storage CellがX3-2またはX4-2である場合:
```
# cellcli -e ALTER CELL flashcachecompress=false
```
- Exadata Storage Cell Serverイメージが11.2.3.3.0で、Exadata Storage CellがX3-2である場合:
```
# cellcli -e ALTER CELL flashCacheCompX3Support=true
# cellcli -e ALTER CELL flashCacheCompress=false
```
  注意:
  flashCacheCompressをfalseに設定しますが、flashCacheCompX3Supportはtrueに設定する必要があります。
セルの属性を表示して、フラッシュ・キャッシュの圧縮が無効になっていることを確認できます。
```
# cellcli -e LIST CELL attributes name,flashCacheCompress
```
正しい値はFALSEまたはnull文字列です。
物理ディスクのサイズが減っていることを確認します。
```
# cellcli -e LIST PHYSICALDISK attributes name,physicalSize,status WHERE disktype=flashdisk
```
ステータスは正常である必要があります。次の情報を使用して、圧縮をオフにしたときの想定サイズを検証します。
- Aura 2.0/F40/X3:
  - 物理ディスク・サイズ: 93.13G (オフ)または186.26G (オン)
  - フラッシュ・キャッシュ・サイズ: 1489G (オフ)または2979G (オン)
- Aura 2.1/F80/X4:
  - 物理ディスク・サイズ: 186.26G (オフ)または372.53G (オン)
  - フラッシュ・キャッシュ・サイズ: 2979G (オフ)または5959G (オン)

フラッシュ・ディスク上にセル・ディスクを作成します。

# 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 LIST FLASHLOG DETAIL
```
セル上にフラッシュ・キャッシュを作成します。
```
# cellcli -e CREATE FLASHCACHE ALL
Flash cache exampleceladm18_FLASHCACHE successfully created
```
フラッシュ・キャッシュが通常のモードであることを確認します。
```
# cellcli -e LIST FLASHCACHE DETAIL
```
フラッシュ・キャッシュの圧縮が無効になっていることを確認します。
```
# cellcli -e LIST CELL
```
flashCacheCompress属性の値がfalseに設定されている必要があります。

3.4 Oracle Exadata Storage ServerのM.2ディスクの保守

Oracle Exadata Database Machine X7システムには、システム領域を含む2つの内蔵M.2デバイスが付属しています。以前のすべてのシステムでは、Oracle Exadata Storage Serverの最初の2つのディスクがシステム・ディスクで、これらのシステム・ディスクの一部がシステム領域と呼ばれています。

注意:

Oracle ExadataラックおよびOracle Exadata Storage Serverは、M.2ディスクの交換中もオンライン状態で使用可能です。

この項では、次の項目について説明します。

3.4.1 M.2ディスクのステータスの監視

CellCLI LIST PHYSICALDISKコマンドを使用して属性をチェックすることによって、M.2ディスクのステータスを監視できます。

ディスク・ファームウェアによってエラー・カウンタが保守され、ディスクで障害が発生しそうになると、ドライブに予測障害というマークが付けられます。交換が必要かどうかは、セル・ソフトウェアではなくドライブによって決定されます。

CellCLIコマンドLIST PHSYICALDISKを使用すると、M.2ディスクのステータスを調べることができます。

CellCLI> LIST PHYSICALDISK WHERE disktype='M2Disk' DETAIL
         name:                           M2_SYS_0
           deviceName:                  /dev/sdm
           diskType:                      M2Disk
           makeModel:                    "INTEL SSDSCKJB150G7"
         physicalFirmware:         N2010112
         physicalInsertTime:      2017-07-14T08:42:24-07:00
         physicalSerial:            PHDW7082000M150A
         physicalSize:               139.73558807373047G
         slotNumber:                  "M.2 Slot: 0"
         status:                failed

         name:                  M2_SYS_1        
         deviceName:            /dev/sdn
         diskType:              M2Disk
         makeModel:             "INTEL SSDSCKJB150G7"
         physicalFirmware:      N2010112
         physicalInsertTime:    2017-07-14T12:25:05-07:00
         physicalSerial:        PHDW708200SZ150A
         physicalSize:          139.73558807373047G
         slotNumber:            "M.2 Slot: 1"
         status:                normal

Exadata Storage ServerのM.2ディスク・ステータスは次のとおりです。

正常
正常 - 交換のため切断
存在しない
失敗
障害 - 交換のため切断
警告 - 予測障害
警告 - 予測障害 - 交換のため切断

3.4.2 障害またはその他の問題によるM.2ディスクの交換

M.2ディスクで障害が発生すると、システム領域の冗長性が低くなり、パッチ適用、イメージ化およびシステムのレスキューに影響を及ぼす場合があります。したがって、すぐにディスクを新しいディスクに交換する必要があります。M.2ディスクで障害が発生すると、非アクティブなシステム・ディスクに格納されているソフトウェアを使用するようにストレージ・サーバーが自動的かつ透過的に切り替わり、そのシステム・ディスクがアクティブになります。

M.2ディスクに障害が発生すると、Exadataアラートが生成されます。アラートには、ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合、電子メールでアラートが指定したアドレスに送信されます。

M.2ディスクはホットプラグ対応で、電源の投入時に交換できます。

M.2ディスクの交換後、Oracle Exadata System Softwareによって新しいデバイスが自動的にシステム・パーティションに追加され、再構築プロセスが開始されます。

障害が発生したM.2ディスクを特定します。

CellCLI> LIST PHYSICALDISK WHERE diskType=M2Disk AND status!=normal DETAIL
         name:                      M2_SYS_0
           deviceName:              /dev/sda
           diskType:                M2Disk
           makeModel:              "INTEL SSDSCKJB150G7"
         physicalFirmware:          N2010112
         physicalInsertTime:        2017-07-14T08:42:24-07:00
         physicalSerial:            PHDW7082000M150A
         physicalSize:              139.73558807373047G
         slotNumber:                "M.2 Slot: 0"
         status:                    failed - dropped for replacement

白色のLEDが点灯しているセルを特定します。
シャーシを開き、手順1のスロット番号でM.2ディスクを特定します。サービスが必要な場合は、このディスクの黄色のLEDが点灯します。
M.2ディスクはホットプラグに対応しているため、セルの電源を切断しなくてもディスクを交換できます。
M.2ディスクを取り外します。
1. ライザー・ボードの両方のソケット・イジェクタを上方外側いっぱいまで回転させます。
  ソケット・イジェクタを開くと、ライザー・ボードの緑色の電源LEDが消灯します。
2. ライザー・ボードをまっすぐ上に慎重に持ち上げて、ソケットから取り外します。
交換用のM.2ディスクを挿入します。
1. 交換用のフラッシュ・ライザー・ボードを開封し、静電気防止マットに置きます。
2. 交換用のライザー・ボードのノッチをコネクタ・ソケットのコネクタ・キーに合わせます。
3. コネクタ・ソケットにしっかりと固定されるまで、ライザー・ボードをソケットに押し込みます。
  注意:
  ライザー・ボードがコネクタ・ソケットに楽に入っていかない場合は、ライザー・ボードのノッチとコネクタ・ソケットのコネクタ・キーが合っているかどうか確認してください。ノッチが合っていないと、ライザーボードが損傷する可能性があります。
4. ライザー・ボードの両方のソケット・イジェクタを内側に回転し、イジェクタのタブによってライザー・ボードの位置が固定されるようにします。
  ソケット・イジェクタを閉じると、ライザー・ボードの緑色の電源LEDが点灯します。

M.2ディスクが交換されたことを確認します。

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=M2Disk DETAIL
     name:                  M2_SYS_0 
    deviceName:            /dev/sdm   
   diskType:              M2Disk   
   makeModel:             "INTEL SSDSCKJB150G7"   
   physicalFirmware:      N2010112    
   physicalInsertTime:    2017-08-24T18:55:13-07:00   
   physicalSerial:        PHDW708201G0150A   
   physicalSize:          139.73558807373047G   
   slotNumber:            "M.2 Slot: 0"   
   status:                normal   

   name:                  M2_SYS_1   
   deviceName:            /dev/sdn   
   diskType:              M2Disk   
   makeModel:             "INTEL SSDSCKJB150G7"    
   physicalFirmware:      N2010112   
   physicalInsertTime:    2017-08-24T18:55:13-07:00   
   physicalSerial:        PHDW708200SZ150A   
   physicalSize:          139.73558807373047G   
   slotNumber:            "M.2 Slot: 1"   
   status:                normal

システム・ディスク・アレイがactive syncステータスになっているか、再構築中であることを確認します。

# mdadm --detail /dev/md[2-3][4-5]
/dev/md24:
      Container : /dev/md/imsm0, member 0
     Raid Level : raid1
     Array Size : 104857600 (100.00 GiB 107.37 GB)
  Used Dev Size : 104857600 (100.00 GiB 107.37 GB)
   Raid Devices : 2
  Total Devices : 2

               State  : active
 Active Devices  : 2
Working Devices  : 2
 Failed Devices  : 0
   Spare Devices : 0  

            UUUID : 152f728a:6d294098:5177b2e5:8e0d766c
   Number    Major    Minor    RaidDevice    State
       1           8         16             0            active sync  /dev/sdb
       0           8           0            1            active sync  /dev/sda
/dev/md25:
      Container : /dev/md/imsm0, member 1
     Raid Level : raid1
     Array Size : 41660416 (39.73 GiB 42.66 GB)
  Used Dev Size : 41660544 (39.73 GiB 42.66 GB)
   Raid Devices : 2
  Total Devices : 2

               State  : clean
 Active Devices  : 2
Working Devices  : 2
 Failed Devices  : 0
   Spare Devices : 0  

             UUID : 466173ba:507008c7:6d65ed89:3c40cf23
   Number    Major    Minor    RaidDevice    State
       1           8         16             0            active sync  /dev/sdb
       0           8       0             1            active sync  /dev/sda

3.5 ストレージ・サーバーのRAMキャッシュの管理

セルのRAMキャッシュはフラッシュ・キャッシュの直前にあるキャッシュとして、データベース・キャッシュを拡張します。フラッシュ・キャッシュよりも高速ですが、容量が小さくなります。

セルのRAMキャッシュ機能は、Oracle Exadata Storage Server Softwareリリース18c (18.1.0.0.0)で導入されました。セルのRAMキャッシュはデフォルトでは無効になっています(ramCacheModeがautoに設定されています)。

3.5.1 セルのRAMキャッシュについて

セルのRAMキャッシュは、オンライン・トランザクション処理(OLTP)読取りのIO待機時間を大幅に短縮します。

OLTPワークロードでは通常、cell single block physical readの待機統計がデータベース処理時間の上位コンシューマとして表示されます。これらの読取りをセルのRAMキャッシュから調達できる場合、待機時間を大幅に短縮し、これらの読取りのIO待機時間を短縮し、OLTPアプリケーションのパフォーマンスを向上させることができます。

または、データベース・バッファ・キャッシュの拡張機能としてセルのRAMキャッシュを参照することもできます。バッファ・キャッシュ・ミスはセルのRAMキャッシュとなり、バッファ・キャッシュとセルのRAMキャッシュの能力の組合せによってより多くのキャッシュ・ヒットを取得できるため、OLTPのパフォーマンスが向上します。

3.5.2 セルのRAMキャッシュのサイズ指定に関する推奨事項

ピークのOLTPワークロード時の自動ワークロード・リポジトリ(AWR)レポートのバッファ・プール・アドバイザ・セクションを使用して、セルのRAMキャッシュの推奨サイズを決定します。

メモリー拡張キットを使用しないExadata Storage Server上のセルのRAMキャッシュのデフォルトのサイズは比較的限定されているため、アクセラレーションの利点を活かすには、最初にストレージ・サーバーでメモリー拡張キットをインストールする必要があります。

ピークのOLTPワークロード中にAWRレポートのバッファ・プール・アドバイザ・セクションを使用すると、セルのRAMキャッシュをどのように構成するかを決定するのに役立ちます。次に例を示します。

GUID-5A49660F-CE70-4FBD-B3E6-A8330F29F2A1-default.pngの説明が続きます

図GUID-5A49660F-CE70-4FBD-B3E6-A8330F29F2A1-default.pngの説明

前述のレポートでは、現在のバッファ・キャッシュ・サイズ(1.00のサイズ係数)を使用すると、データベースでは約338,000,000回の物理読取りが実行されます。バッファ・キャッシュを87% (1.87のサイズ係数)増やすと、物理読取りが約12,000,000回に減少します。

バッファ・キャッシュ・サイズの87%であるセルのRAMキャッシュを作成した場合、338,431,000回の読取り - 11,971,000回の読取り、つまり、約326,000,000回の読取りがセルのRAMキャッシュによって満たされることになります。セルのRAMキャッシュは、セルのRAMキャッシュを活用するOLTP読取りの回数に基づいてサイズ設定できます。

Oracle Real Application Clusters (Oracle RAC)データベースが複数のデータベース・インスタンスを使用して設定されている場合、各データベース・インスタンスにはそれぞれのAWRレポート内に独立したバッファ・プール・アドバイザを持ちます。物理読取りの削減回数は、インスタンスによって異なる場合があります。このレポートでは、バッファ・キャッシュ・ミスが別のインスタンスからのキャッシュ・フュージョン・ブロック転送によって満たされる場合がすでに考慮されています。そのため、バッファ・プール・アドバイザ・レポートでは、キャッシュ・フュージョン・ブロックの転送回数をあらかじめ計算に入れた後の実際のストレージの読取り回数のみ推定されます。Oracle RACのセルのRAMキャッシュのサイズ設定方法は非常に簡潔です。各インスタンスに必要な追加領域がどのくらいであるかを確認し、それらの値を加算します。その合計は、プロビジョニングする必要のあるセルのRAMキャッシュの量です。

同様に、複数のデータベースが同じセルセットを共有している場合は、データベースごとに追加のバッファ・キャッシュ・サイズを合計できます。その合計は、セルでプロビジョニングする必要があるセルのRAMキャッシュの合計量です。

必要なセルのRAMキャッシュのサイズがわかったら、どのメモリー拡張キットがニーズに対して最適であるかを決定できます。データベース・サーバーとストレージ・サーバーの両方に追加メモリーを追加することにより、サーバーを任意の順序でアップグレードできます。

データベース・サーバー・メモリーを展開すると、指定されたサーバー上でより多くのメモリーが提供され、より大容量のSGAやPGAなどに加えて、より大きいバッファ・キャッシュを潜在的に持つことが可能になります。
ストレージ・サーバー・メモリーを展開すると、セルのRAMキャッシュはすべてのデータベース・サーバーで共有されます。追加のメモリーは、すべてのOracle Virtual Machine (Oracle VM)およびデータベース・インスタンス全体にわたって利用できます。

様々なデータベース・サーバーまたはOracle VMで異なるタイミングで様々なワークロードを実行する場合、または複数のデータベースを持つ統合環境を実行している場合、ストレージ・サーバー・メモリーを展開すると、メモリーをすべてのデータベースで共有できるため、追加メモリーの使用量をより柔軟に最大化できる可能性があります。

3.5.3 セルのRAMキャッシュの有効化

セルのRAMキャッシュ機能を有効にするには、各Oracle Exadata Storage ServerでramCacheModeセル属性をonに設定します。

セルのRAMキャッシュ機能はデフォルトでは無効になっています(ramCacheModeがautoに設定されています)。ストレージ・サーバーのramCacheModeをonに変更すると、ストレージ・サーバー上でセルのRAMキャッシュを作成するために可能なかぎり使用可能な空きメモリーが自動的に使用されます。

各セルでramCacheMode属性の値を変更します。
dcliを使用して単一のコマンドで複数のセルを変更したり、各Oracle Exadata Storage Serverで次のコマンドを実行したりできます。
```
CellCLI> ALTER CELL ramCacheMode=on
Cell host03celadm10 successfully altered
```

CellSrvを再起動します。

CellCLI> ALTER CELL RESTART SERVICES CELLSRV

3.5.4 セルのRAMキャッシュのサイズの表示

ramCacheMode属性をonに設定した後、ストレージ・サーバーでセルのRAMキャッシュを作成するために可能なかぎり使用可能な空きメモリーが自動的に使用されます。

RAMキャッシュの作成はバックグラウンドで非同期に行われます。この機能を有効にした直後にセルのRAMキャッシュのサイズを問い合せても、正確なサイズは表示されません。セルのalert.logを監視すると、セルのRAMキャッシュの作成の進行状況を追跡できます。

セルのRAMキャッシュの現在のステータスを確認するには、セルのramCacheMode、ramCacheSizeおよびramCacheMaxSize属性を取得します。
```
CellCLI> LIST CELL ATTRIBUTES ramCacheMaxSize,ramCacheMode, ramCacheSize 
     18.875G         On          18.875G
```

3.5.5 セルのRAMキャッシュのサイズ変更

ストレージ・サーバーでセルのRAMキャッシュを作成するために可能なかぎり使用可能な空きメモリーが自動的に使用されます。

セルのRAMキャッシュ機能を有効にしても、Oracle Exadata Storage ServerでセルのRAMキャッシュを作成するために可能なかぎり使用可能な空きメモリーが自動的に使用されます。セルのRAMキャッシュのサイズは、CellCLI LIST CELL ramCacheSizeコマンドを使用することで判別できます。

ramCacheMaxSize属性により、セルのRAMキャッシュに使用できるメモリーの最大量が決まります。

セルのRAMキャッシュのサイズを制限するには、各ストレージ・サーバーでramCacheMaxSize属性の値を変更します。

exadcliを使用して単一のコマンドで複数のストレージ・サーバーを変更したり、各Oracle Exadata Storage Serverで次のコマンドを実行したりできます。

CellCLI> ALTER CELL ramCacheMaxSize=1G
Cell host03celadm10 successfully altered

例3-1 セルのRAMキャッシュのサイズ制限

セルのRAMキャッシュの最大サイズを1GBに制限するには、次のコマンドを使用して、複数のOracle Exadata Storage Serverを変更します。

exadcli -c cell01,cell02,cell03 -l celladministrator alter cell ramCacheMaxSize=1G

関連トピック

セルのRAMキャッシュのサイズ指定に関する推奨事項

3.5.6 セルのRAMキャッシュの無効化

セルのRAMキャッシュ機能を無効にするには、各Oracle Exadata Storage ServerでramCacheMode属性をoffに設定します。

注意:

セルのRAMキャッシュ機能はデフォルトでは無効になっています(ramCacheModeがautoに設定されています)。

各セルでramCacheMode属性の値を変更します。
dcliを使用して単一のコマンドで複数のセルを変更したり、各Oracle Exadata Storage Serverで次のコマンドを実行したりできます。
```
CellCLI> ALTER CELL ramCacheMode=off
Cell host03celadm10 successfully altered
```

CellSrvを再起動します。

CellCLI> ALTER CELL RESTART SERVICES CELLSRV

3.6 グリッド・ディスクのサイズ変更

グリッド・ディスクおよび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 System Softwareリリース12.1.2.1.0以上を使用しているか、バグ19695225用のパッチがソフトウェアに適用されている必要があります。

グリッド・ディスクのサイズを変更するこの手順は、ベア・メタルおよび仮想マシン(VM)デプロイメントに適用されます。

関連トピック

3.6.1 使用可能な領域の容量の判別

ディスク・グループ内のディスクのサイズを増やすには、未割当てのディスク領域があるか、別のディスク・グループが現在使用している領域を再割当てする必要があります。

また、Exadataの新規グリッド・ディスクおよびディスク・グループのサイズを計算するためのスクリプト(My Oracle Supportのドキュメント ID 1464809.1)で使用可能なスクリプトを使用すると、ディスク・グループを縮小するために使用可能な空き領域の量の判別に役立ちます。

ディスク・グループによって現在使用されている領域を表示します。
```
SELECT name, total_mb, free_mb, total_mb - free_mb used_mb, round(100*free_mb/total_mb,2) pct_free
FROM v$asm_diskgroup
ORDER BY 1;

NAME                             TOTAL_MB    FREE_MB    USED_MB   PCT_FREE
------------------------------ ---------- ---------- ---------- ----------
DATAC1                           68812800    9985076   58827724      14.51
RECOC1                           94980480   82594920   12385560      86.96
```
この例では、DATAC1ディスク・グループには空き領域が約15%しかありませんが、RECOC1ディスク・グループには約87%の空きディスク領域があります。ここに表示されているPCT_FREEは未加工の空き領域です。使用できる空き領域ではありません。リバランス操作のためには追加の領域が必要です。

サイズを変更しようとするディスク・グループについて、ディスク・グループによって使用される障害グループの数とステータスを表示します。

SELECT dg.name, d.failgroup, d.state, d.header_status, d.mount_mode, 
 d.mode_status, count(1) num_disks
FROM V$ASM_DISK d, V$ASM_DISKGROUP dg
WHERE d.group_number = dg.group_number
AND dg.name IN ('RECOC1', 'DATAC1')
GROUP BY dg.name, d.failgroup, d.state, d.header_status, d.mount_status,
  d.mode_status
ORDER BY 1, 2, 3;

NAME       FAILGROUP      STATE      HEADER_STATU MOUNT_S  MODE_ST  NUM_DISKS
---------- -------------  ---------- ------------ -------- -------  ---------
DATAC1     EXA01CELADM01  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM02  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM03  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM04  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM05  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM06  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM07  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM08  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM09  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM10  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM11  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM12  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM13  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM14  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM01  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM02  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM03  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM04  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM05  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM06  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM07  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM08  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM09  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM10  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM11  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM12  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM13  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM14  NORMAL     MEMBER        CACHED  ONLINE   12

この例は、フル・ラック(DATAC1とRECOC1に対して14個のセルと14個の障害グループがある)のものです。障害グループごとに、NORMAL状態のディスクが12個以上あることを確認します(num_disks)。MISSINGと表示されているディスクがある、または予期しない数のディスクが構成されている場合は、問題を解決するまで手順を進めないでください。

Extreme Flashシステムでは、num_disksのディスク数は12ではなく8になります。

各セルと各障害グループに関連付けられた対応するグリッド・ディスクを表示して、サイズ変更するグリッド・ディスクを確認します。

SELECT dg.name, d.failgroup, d.path
FROM V$ASM_DISK d, V$ASM_DISKGROUP dg
WHERE d.group_number = dg.group_number
AND dg.name IN ('RECOC1', 'DATAC1')
ORDER BY 1, 2, 3;

NAME        FAILGROUP      PATH
----------- -------------  ----------------------------------------------
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_00_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_01_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_02_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_03_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_04_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_05_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_06_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_07_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_08_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_09_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_10_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_11_exa01celadm01
DATAC1      EXA01CELADM02  o/192.168.74.44/DATAC1_CD_00_exa01celadm01
DATAC1      EXA01CELADM02  o/192.168.74.44/DATAC1_CD_01_exa01celadm01
DATAC1      EXA01CELADM02  o/192.168.74.44/DATAC1_CD_02_exa01celadm01
...
RECOC1      EXA01CELADM13  o/192.168.74.55/RECOC1_CD_00_exa01celadm13
RECOC1      EXA01CELADM13  o/192.168.74.55/RECOC1_CD_01_exa01celadm13
RECOC1      EXA01CELADM13  o/192.168.74.55/RECOC1_CD_02_exa01celadm13
...
RECOC1      EXA01CELADM14  o/192.168.74.56/RECOC1_CD_09_exa01celadm14
RECOC1      EXA01CELADM14  o/192.168.74.56/RECOC1_CD_10_exa01celadm14
RECOC1      EXA01CELADM14  o/192.168.74.56/RECOC1_CD_11_exa01celadm14  

168 rows returned.

使用可能な空き領域をセル・ディスクで調べます。
セル・ディスク上の空き領域は、DATAC1グリッド・ディスクのサイズを増やすために使用できます。DATAC1グリッド・ディスクを拡張するために十分な空き領域がない場合は、RECOC1グリッド・ディスクを縮小して、DATAC1グリッド・ディスクの望ましいサイズを実現するために空き領域を提供する必要があります。
```
[root@exa01adm01 tmp]# dcli -g ~/cell_group -l root "cellcli -e list celldisk \
  attributes name,freespace" 
exa01celadm01: CD_00_exa01celadm01 0 
exa01celadm01: CD_01_exa01celadm01 0 
exa01celadm01: CD_02_exa01celadm01 0 
exa01celadm01: CD_03_exa01celadm01 0 
exa01celadm01: CD_04_exa01celadm01 0 
exa01celadm01: CD_05_exa01celadm01 0 
exa01celadm01: CD_06_exa01celadm01 0 
exa01celadm01: CD_07_exa01celadm01 0 
exa01celadm01: CD_08_exa01celadm01 0 
exa01celadm01: CD_09_exa01celadm01 0 
exa01celadm01: CD_10_exa01celadm01 0 
exa01celadm01: CD_11_exa01celadm01 0 
...
```
この例では空き領域がないため、最初にRECOC1グリッド・ディスクを縮小してDATAC1グリッド・ディスクのための領域を提供する必要があります。構成に使用可能な空き領域が豊富にある場合は、RECOC1グリッド・ディスクを縮小するかわりにその空き領域を使用できます。
RECOC1ディスク・グループと各グリッド・ディスクを縮小する領域の容量を計算します。
ディスク・グループとそのグリッド・ディスクを安全に縮小できる許容最小サイズは、次の要素を考慮して判断する必要があります。
- 現在使用中の領域(USED_MB)
- 想定される増加のための領域(GROWTH_MB)
- ディスク障害の場合にリバランスに必要な領域(DFC_MB)。通常は合計ディスク・グループ・サイズの15%
上の要素を考慮した最小サイズ計算は次のようになります。
```
Minimum DG size (MB) = (USED_MB + GROWTH_MB ) * 1.15 
```
- USED_MBは、V$ASM_DISKGROUPのTOTAL_MB - FREE_MBを計算することによって導出できます。
- GROWTH_MBは、ディスク・グループの将来の使用量に固有の見積もりとなり、増加パターンの履歴をその基礎とする必要があります
手順1で示されたRECOC1ディスク・グループの領域の使用量から、増加がないと仮定して、最小で、次のサイズまで縮小できることがわかります。

RECOC1の最小サイズ = (TOTAL_MB - FREE_MB + GROWTH_MB) * 1.15

= (94980480 - 82594920 + 0) * 1.15 = 14243394MB = 13,910GB

手順1に表示されている出力例では、RECOC1には豊富な空き領域があり、DATAC1の空き領域は15%未満でした。そこで、RECOC1を縮小して、解放されたディスク領域をDATAC1に提供します。RECOC1を現在のサイズの半部に縮小する場合、新しいサイズは94980480 / 2 = 47490240MBになります。このサイズは、RECOC1ディスク・グループに対して上で計算した最小サイズを大きく上回るため、この値まで縮小しても安全です。

手順2の問合せでは、14個のセルとセルごとに12個のディスクがあるため、RECOC1には168個のグリッド・ディスクがあります(14 * 12 = 168)。RECOC1ディスク・グループの各グリッド・ディスクの新しいサイズの見積もりは、47490240 / 168すなわち282,680MBです。

新しいグリッド・ディスク・サイズに最も近い16MBごとの境界を調べます。このチェックを実行しない場合は、セルにより、グリッド・ディスクのサイズが最も近い16MB境界に自動的に切り捨てられるため、Oracle ASMディスクとグリッド・ディスクのサイズが一致しなくなる可能性があります。
```
SQL> SELECT 16*TRUNC(&new_disk_size/16) new_disk_size FROM dual;
Enter value for new_disk_size: 282680

NEW_DISK_SIZE
-------------
       282672
```
前述の結果に基づいて、RECOC1ディスク・グループのグリッド・ディスクの新しいサイズとして282672MBを選択することをお薦めします。グリッド・ディスクのサイズを変更すると、RECOC1ディスク・グループのサイズは47488896MBになります。
DATAC1ディスク・グループの各グリッド・ディスクのサイズをどれだけ増やすかを計算します。
Oracle ASMディスクのサイズとグリッド・ディスクのサイズがディスク・グループ全体で一致することを確認します。次の問合せによって、各ディスク・グループのディスク・サイズの組合せが表示されます。すべてのディスクのサイズが同じで、Oracle ASM (total_mb)ディスクとグリッド・ディスク(os_mb)のサイズが一致しているのが理想です。
```
SELECT dg.name, d.total_mb, d.os_mb, count(1) num_disks
FROM v$asm_diskgroup dg, v$asm_disk d
WHERE dg.group_number = d.group_number
GROUP BY dg.name, d.total_mb, d.os_mb;

NAME                             TOTAL_MB      OS_MB  NUM_DISKS
------------------------------ ---------- ---------- ----------
DATAC1                             409600     409600        168
RECOC1                             565360     565360        168
```
RECOC1のグリッド・ディスクを縮小した後で、DATAC1の各ディスクに次の領域が提供されます。

DATAC1ディスクの追加領域 = RECOC1_current_size - RECOC1_new_size
                                                       = 565360 - 282672 = 282688MB

DATAC1ディスク・グループの新しいサイズを計算するには、次を使用します。

DATAC1のディスクの新しいサイズ  = DATAC1_ disks_current_size + new_free_space_from_RECOC1
                                          = 409600 + 282688 = 692288MB

新しいグリッド・ディスク・サイズに最も近い16MBごとの境界を調べます。このチェックを実行しない場合は、セルにより、グリッド・ディスクのサイズが最も近い16MB境界に自動的に切り捨てられるため、Oracle ASMディスクとグリッド・ディスクのサイズが一致しなくなる可能性があります。
```
SQL> SELECT 16*TRUNC(&new_disk_size/16) new_disk_size FROM dual;
Enter value for new_disk_size: 692288

NEW_DISK_SIZE
-------------
       692288
```
問合せの結果に基づいて、DATAC1ディスク・グループのディスクについて計算したサイズ692288MBを使用できます。このサイズは16MBごとの境界に合っています。問合せの結果が指定した値と異なる場合は、問合せから返された値を使用する必要があります。セルによってこの値のグリッド・ディスク・サイズに切り上げ(または切り捨て)られるためです。

新しいグリッド・ディスク・サイズの計算値から、DATAC1ディスク・グループの合計サイズは116304384MB (168ディスク * 692288MB)になります。

3.6.2 ドナー・ディスク・グループのOracle ASMディスクの縮小

セル・ディスク上に使用可能な空き領域がない場合は、あるディスク・グループが使用する領域を減らして、別のディスク・グループに追加のディスク領域を提供することができます。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。

ディスク・グループのサイズを変更する前に、領域を減らすディスク・グループに十分な空き領域があることを確認します。

RECOディスク・グループ用のOracle ASMディスクをすべてのディスクの新しいサイズに縮小します。
「使用可能な領域量の確認」の手順5で計算したRECOディスク・グループのディスクの新しいサイズを使用します。
```
SQL> ALTER DISKGROUP recoc1 RESIZE ALL SIZE 282672M REBALANCE POWER 64;
```
注意:
ALTER DISKGROUPコマンドが完了するまで数分かかることがあります。この処理が完了するまで、SQLプロンプトは表示されません。

リバランスが終了するまで待機してから、ビューGV$ASM_OPERATIONをチェックします。
```
SQL> set lines 250 pages 1000
SQL> col error_code form a10
SQL> SELECT dg.name, o.*
  2  FROM gv$asm_operation o, v$asm_diskgroup dg
  3  WHERE o.group_number = dg.group_number;
```
GV$ASM_OPERATIONへの問合せで、変更中のディスク・グループの行が表示されない場合のみ、次の手順に進みます。

次の問合せを使用してASMディスクの新しいサイズを確認します。

SQL> SELECT name, total_mb, free_mb, total_mb - free_mb used_mb,
  2   ROUND(100*free_mb/total_mb,2) pct_free
  3  FROM v$asm_diskgroup
  4  ORDER BY 1;

NAME                             TOTAL_MB    FREE_MB    USED_MB   PCT_FREE
------------------------------ ---------- ---------- ---------- ----------
DATAC1                           68812800    9985076   58827724      14.51
RECOC1                           47488896   35103336   12385560      73.92

SQL> SELECT dg.name, d.total_mb, d.os_mb, COUNT(1) num_disks
  2  FROM v$asm_diskgroup dg, v$asm_disk d
  3  WHERE dg.group_number = d.group_number
  4  GROUP BY dg.name, d.total_mb, d.os_mb;

NAME                             TOTAL_MB      OS_MB  NUM_DISKS
------------------------------ ---------- ---------- ----------
DATAC1                             409600     409600        168
RECOC1                             282672     565360        168

前述の問合せの例では、RECOC1ディスク・グループのディスクのサイズが各々変更されて282672MGになり、ディスク・グループの合計サイズが47488896MBになったことが表示されます。

関連トピック

使用可能な領域の容量の判別

3.6.3 ドナー・ディスク・グループのグリッド・ディスクの縮小

Oracle ASMディスク・グループのディスクを縮小した後、各セルのグリッド・ディスクのサイズを縮小します。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。

「ドナー・ディスク・グループのOracle ASMディスクの縮小」のタスクを完了しておく必要があります。

すべてのセルのRECOディスク・グループに関連付けられたグリッド・ディスクを新しいサイズに縮小します。

「使用可能な領域量の確認」の手順3で確認されたストレージ・セルごとに、前の作業で縮小したOracle ASMディスクのサイズに合わせてグリッド・ディスクを縮小します。次のようなコマンドを使用します。

dcli -c exa01celadm01 -l root "cellcli -e alter griddisk RECOC1_CD_00_exa01celadm01 \
,RECOC1_CD_01_exa01celadm01 \
,RECOC1_CD_02_exa01celadm01 \
,RECOC1_CD_03_exa01celadm01 \
,RECOC1_CD_04_exa01celadm01 \
,RECOC1_CD_05_exa01celadm01 \
,RECOC1_CD_06_exa01celadm01 \
,RECOC1_CD_07_exa01celadm01 \
,RECOC1_CD_08_exa01celadm01 \
,RECOC1_CD_09_exa01celadm01 \
,RECOC1_CD_10_exa01celadm01 \
,RECOC1_CD_11_exa01celadm01 \
size=282672M "

dcli -c exa01celadm02 -l root "cellcli -e alter griddisk RECOC1_CD_00_exa01celadm02 \
,RECOC1_CD_01_exa01celadm02 \
,RECOC1_CD_02_exa01celadm02 \
,RECOC1_CD_03_exa01celadm02 \
,RECOC1_CD_04_exa01celadm02 \
,RECOC1_CD_05_exa01celadm02 \
,RECOC1_CD_06_exa01celadm02 \
,RECOC1_CD_07_exa01celadm02 \
,RECOC1_CD_08_exa01celadm02 \
,RECOC1_CD_09_exa01celadm02 \
,RECOC1_CD_10_exa01celadm02 \
,RECOC1_CD_11_exa01celadm02 \
size=282672M "

...

dcli -c exa01celadm14 -l root "cellcli -e alter griddisk RECOC1_CD_00_exa01celadm14 \
,RECOC1_CD_01_exa01celadm14 \
,RECOC1_CD_02_exa01celadm14 \
,RECOC1_CD_03_exa01celadm14 \
,RECOC1_CD_04_exa01celadm14 \
,RECOC1_CD_05_exa01celadm14 \
,RECOC1_CD_06_exa01celadm14 \
,RECOC1_CD_07_exa01celadm14 \
,RECOC1_CD_08_exa01celadm14 \
,RECOC1_CD_09_exa01celadm14 \
,RECOC1_CD_10_exa01celadm14 \
,RECOC1_CD_11_exa01celadm14 \
size=282672M "

次のコマンドを使用してグリッド・ディスクの新しいサイズを確認します。

[root@exa01adm01 tmp]# dcli -g cell_group -l root "cellcli -e list griddisk attributes name,size where name like \'RECOC1.*\' "

exa01celadm01: RECOC1_CD_00_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_01_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_02_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_03_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_04_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_05_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_06_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_07_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_08_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_09_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_10_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_11_exa01celadm01 276.046875G  
...

前述の例では、RECOC1ディスク・グループのディスクのサイズが各々変更されて282672MB (276.046875 * 1024)になったことが表示されます。

3.6.4 使用可能な領域によるグリッド・ディスクのサイズの拡張

割り当てられていないディスク領域がすでに使用可能か、異なるOracle ASMディスク・グループが使用する領域を縮小して使用可能にした場合、グリッド・ディスクが使用するサイズを増やすことができます。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。既存のディスク・グループを拡張するために十分な領域がすでにある場合は、別のディスク・グループの領域を再割当てする必要はありません。

セル・ディスクに必要な量の空き領域があることを確認します。

Oracle ASMディスクとグリッド・ディスクを縮小するタスクを完了している場合、セル・ディスクの空き領域は次のように表示されます。

[root@exa01adm01 tmp]# dcli -g ~/cell_group -l root "cellcli -e list celldisk \
attributes name,freespace"

exa01celadm01: CD_00_exa01celadm01 276.0625G
exa01celadm01: CD_01_exa01celadm01 276.0625G
exa01celadm01: CD_02_exa01celadm01 276.0625G
exa01celadm01: CD_03_exa01celadm01 276.0625G
exa01celadm01: CD_04_exa01celadm01 276.0625G
exa01celadm01: CD_05_exa01celadm01 276.0625G
exa01celadm01: CD_06_exa01celadm01 276.0625G
exa01celadm01: CD_07_exa01celadm01 276.0625G
exa01celadm01: CD_08_exa01celadm01 276.0625G
exa01celadm01: CD_09_exa01celadm01 276.0625G
exa01celadm01: CD_10_exa01celadm01 276.0625G
exa01celadm01: CD_11_exa01celadm01 276.0625G 
...

ストレージ・セルごとにDATAグリッド・ディスクのサイズを目標の新しいサイズに増やします。

「使用可能な領域の容量の判別」で計算したサイズを使用します。

dcli -c exa01celadm01 -l root "cellcli -e alter griddisk DATAC1_CD_00_exa01celadm01 \
,DATAC1_CD_01_exa01celadm01 \
,DATAC1_CD_02_exa01celadm01 \
,DATAC1_CD_03_exa01celadm01 \
,DATAC1_CD_04_exa01celadm01 \
,DATAC1_CD_05_exa01celadm01 \
,DATAC1_CD_06_exa01celadm01 \
,DATAC1_CD_07_exa01celadm01 \
,DATAC1_CD_08_exa01celadm01 \
,DATAC1_CD_09_exa01celadm01 \
,DATAC1_CD_10_exa01celadm01 \
,DATAC1_CD_11_exa01celadm01 \
size=692288M "
...
dcli -c exa01celadm14 -l root "cellcli -e alter griddisk DATAC1_CD_00_exa01celadm14 \
,DATAC1_CD_01_exa01celadm14 \
,DATAC1_CD_02_exa01celadm14 \
,DATAC1_CD_03_exa01celadm14 \
,DATAC1_CD_04_exa01celadm14 \
,DATAC1_CD_05_exa01celadm14 \
,DATAC1_CD_06_exa01celadm14 \
,DATAC1_CD_07_exa01celadm14 \
,DATAC1_CD_08_exa01celadm14 \
,DATAC1_CD_09_exa01celadm14 \
,DATAC1_CD_10_exa01celadm14 \
,DATAC1_CD_11_exa01celadm14 \
size=692288M "

次のコマンドを使用して、DATAC1ディスク・グループに関連付けられているグリッド・ディスクの新しいサイズを確認します。

dcli -g cell_group -l root "cellcli -e list griddisk attributes name,size \ 
where name like \'DATAC1.*\' "

exa01celadm01: DATAC1_CD_00_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_01_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_02_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_03_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_04_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_05_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_06_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_07_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_08_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_09_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_10_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_11_exa01celadm01 676.0625G

DATAディスク・グループのサイズを増やすかわりに、新たに解放された空き領域を使用して新しいディスク・グループを作成することや、将来使用するために空き領域のままにしておくこともできます。一般的には、必要な最小限の数のディスク・グループ(通常はDATA、RECOおよびDBFS_DG)を使用して、高い柔軟性と管理のしやすさを実現することをお薦めします。ただし、場合によっては、仮想マシンを使用するとき、または多数のデータベースを統合するときなど、追加のディスク・グループや将来のための使用可能な空き領域が必要になる可能性があります。

将来のためにグリッド・ディスクに空き領域を残しておく場合は、後から既存のディスク・グループに空き領域を割り当てる手順について「My Oracle Support Note 1684112.1」を参照してください。

関連トピック

3.6.5 Oracle ASMディスクのサイズの拡張

関連するグリッド・ディスクに割り当てられる領域を増やした後、Oracle ASMディスクが使用するサイズを増やすことができます。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。

対応するOracle ASMディスク・グループのサイズを変更する前に、グリッド・ディスクのサイズを変更する作業を完了する必要があります。

DATAC1ディスク・グループのOracle ASMディスクをストレージ・セルのグリッド・ディスクの新しいサイズまで増やします。
```
SQL> ALTER DISKGROUP datac1 RESIZE ALL;
```
このコマンドにより、Oracle ASMディスクのサイズがグリッド・ディスクのサイズと一致するように変更されます。
注意:
指定したディスク・グループでディスク・グループ内にquorumディスクが構成されている場合、ALTER DISKGROUP ... RESIZE ALLコマンドはエラーORA-15277で失敗することがあります。quorumディスクが構成されるのは、『Oracle Exadata Database Machineメンテナンス・ガイド』に記載されている要件が満たされる場合です。

対処方法としては、ストレージ・サーバー障害グループ名(FAILURE_TYPEが"REGULAR"であり、"QUORUM"ではない)をSQLコマンドに明示的に指定してください。次に例を示します。
```
SQL> ALTER DISKGROUP datac1 RESIZE DISKS IN FAILGROUP exacell01, exacell02, exacell03;
```
リバランス操作が完了するまで待機します。
```
SQL> set lines 250 pages 1000 
SQL> col error_code form a10 
SQL> SELECT dg.name, o.* FROM gv$asm_operation o, v$asm_diskgroup dg 
     WHERE o.group_number = dg.group_number;
```
変更されたディスク・グループについて問合せから行が戻されなくなるまで、次の手順に進まないでください。

Oracle ASMディスクおよびディスク・グループの新しいサイズが必要なサイズになっていることを確認します。

SQL> SELECT name, total_mb, free_mb, total_mb - free_mb used_mb, 
     ROUND(100*free_mb/total_mb,2) pct_free
     FROM v$asm_diskgroup
     ORDER BY 1;

NAME                             TOTAL_MB    FREE_MB    USED_MB   PCT_FREE
------------------------------ ---------- ---------- ---------- ----------
DATAC1                          116304384   57439796   58864588      49.39
RECOC1                           47488896   34542516   12946380      72.74

SQL>  SELECT dg.name, d.total_mb, d.os_mb, COUNT(1) num_disks
      FROM  v$asm_diskgroup dg, v$asm_disk d
      WHERE dg.group_number = d.group_number
      GROUP BY dg.name, d.total_mb, d.os_mb;
 
NAME                             TOTAL_MB      OS_MB  NUM_DISKS
------------------------------ ---------- ---------- ----------
DATAC1                             692288     692288        168
RECOC1                             282672     282672        168

問合せの結果は、RECOC1およびDATAC1ディスク・グループとディスクのサイズが変更されたことを示します。

関連トピック

使用可能な領域の容量の判別

3.7 Oracle Exadata System Softwareのレスキュー手順の使用

システム・ディスクで障害が発生した場合、オペレーティング・システムに破損したファイル・システムがある場合またはブート領域が損傷している場合、レスキュー手順が必要です。1つのシステム・ディスクのみで障害が発生した場合、リカバリにCellCLIコマンドを使用します。両方のシステム・ディスクで同時に障害が発生するまれな事例の場合、Oracle Exadata System Software CELLBOOT USBフラッシュ・ドライブで提供されるOracle Exadata Storage Serverレスキュー機能を使用する必要があります。

通常の冗長性を使用している場合、レスキューされるセルのミラー・コピーは1つだけです。レスキュー手順の実行中にこのミラーでも障害が発生すると、リカバリできないデータの損失が発生する可能性があります。ミラー・コピーでデータの完全なバックアップを作成し、すぐにミラー・コピー・セルをオフラインにしてレスキュー前の新しいデータ変更を防止することをお薦めします。これにより、レスキュー手順の実行中は、障害が発生したセルのグリッド・ディスクのすべてのデータおよびそのミラー・コピーにアクセスできなくなります。

Oracle ASMディスク修復タイマーのデフォルトの修復時間は、3.6時間です。この時間内にレスキュー手順を実行できないことがわかった場合、レスキュー手順を実行できるまで、Oracle ASMリバランス手順を使用してディスクをリバランスする必要があります。

障害が発生したセルのすべてのグリッド・ディスクにOracle ASMの複数のミラー・コピーがある場合など、高い冗長性のディスク・グループを使用している場合、障害が発生したセルをオフラインにします。構成したOracle ASMのタイムアウト後に、Oracle ASMにより、障害が発生したセルのグリッド・ディスクが自動的に削除され、ミラー・コピーを使用したデータのリバランスが開始されます。デフォルトのタイムアウトは2時間です。セルのレスキューに2時間以上かかる場合、Oracle ASMのレスキュー・セルのグリッド・ディスクを再作成する必要があります。

注意:

十分に注意してレスキュー手順を使用してください。誤って手順を使用すると、データの損失が発生する可能性があります。

レスキュー手順を使用する場合、次の点に注意してください。

レスキュー手順により、セルの一部またはすべてのディスクが書き換えられる可能性があります。この場合、リカバリできずにそれらのディスクのすべての内容を失う可能性があります。

この手順を使用する場合は十分に注意し、プロンプトを確認してください。レスキュー手順は、Oracleサポート・サービスの支援を受ける場合や、一部または全部のディスクのデータを失っても問題がない場合にのみ使用してください。
レスキュー手順の実行中に明示的に選択しないかぎり、レスキュー手順により、データ・ディスクの内容またはシステム・ディスクのデータ・パーティションの内容は破棄されません。
Oracle Exadata System Softwareリリース11.2以降では、レスキュー手順によりOracle Exadata System Softwareが同じリリースにリストアされます。これには、最後に正常にブートしたときのセルのパッチが含まれます。レスキュー手順の使用に関して、次の点に注意してください。
- セル構成情報(アラート構成、SMTP情報、管理者の電子メール・アドレスなど)はリストアされません。
- /usr/local/bin/ipconfユーティリティの実行が最後に成功したときに存在したネットワーク構成はリストアされます。
- セルのSSH IDと、root、celladminおよびcellmonitorユーザーは復元されます。
- Oracle Exadata Storage ServerのILOM構成はリストアされません。通常、ILOM構成は、Oracle Exadata System Softwareに障害が発生しても損なわれません。
レスキュー手順により、データ・ディスクまたはシステム・ディスクのデータ・パーティションの確認または再構築は行われません。グリッド・ディスクにデータの破損がある場合、レスキュー手順は使用しないでください。かわりに、Oracle DatabaseおよびOracle ASMのレスキュー手順を使用してください。

正常なレスキューの実行後、セルを再構成し、データを保存する場合はセル・ディスクをインポートする必要があります。データを保存しない場合は、新しいセル・ディスクおよびグリッド・ディスクを作成する必要があります。

この項では、次の項目について説明します。

関連項目:

タイマーのリセットの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください
ALTER CELLコマンドの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください
CellCLIユーティリティを使用したセル、セル・ディスクおよびグリッド・ディスクの構成の詳細は、『Oracle Exadata System Softwareユーザーズ・ガイド』を参照してください

3.7.1 CELLBOOT USBフラッシュ・ドライブを使用したレスキューの実行

レスキュー手順の実行には、CELLBOOT USBフラッシュ・ドライブを使用できます。

コンソールを使用して、Oracle Exadata Storage Serverに接続します。
Oracle 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.
```
Oracle Exadata System Softwareの古いバージョンの場合は、"Oracle Exadata"スプラッシュ画面が表示されます。スプラッシュ画面が表示されたら、キーボードの任意のキーを押します。スプラッシュ画面の表示は、5秒間のみです。
ブート・オプションの表示リストで、最後のオプションCELL_USB_BOOT_CELLBOOT_usb_in_rescue_modeまで下にスクロールして、[Enter]を押します。
レスキュー・オプションを選択して、レスキュー手順に進みます。
レスキューの最初のフェーズの最後に、システムの再起動またはシェルへの移行を要求された場合は、次の手順を実行します。
1. 選択して、シェルを入力します。システムの再起動は選択しないでください。
2. レスキューのrootパスワードを使用してシェルにログインします。
3. シェルからrebootコマンドを実行します。
4. シェルが再起動したら、Oracle Exadataスプラッシュ画面が表示される前に[F8]を押します。
  F8キーを押すと、起動デバイス選択メニューが開きます。
5. 起動デバイスとして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;
```
注意:
- ディスクがすでに強制削除されているため、コマンドが失敗する場合は、ディスクをOracle 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 System Softwareユーザーズ・ガイド』を参照してください
メトリックしきい値の設定の詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

3.7.1.1 Oracle Exadata Database Machineエイス・ラックのストレージ・サーバーのレスキュー後の構成

セル・レスキューの実行後に、構成を検証します。

Oracle Exadata System 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
```
エイス・ラック構成の場合、出力はハードウェア・モデルによって異なります。
- X3ストレージ・サーバー: 6個のアクティブCPU、6個のハード・ディスクおよび8個のフラッシュ・ディスクが有効になっている必要があります
- X4ストレージ・サーバー: 6個のアクティブCPUコア、6個のハード・ディスクおよび8個のフラッシュ・ディスクが有効になっている必要があります
- X5 HCストレージ・サーバー: 8個のアクティブCPUコア、6個のハード・ディスクおよび2個のフラッシュ・ディスクが有効になっている必要があります
- X5 EFストレージ・サーバー: 8個のアクティブCPUコアおよび4個のフラッシュ・ディスクが有効になっている必要があります
- X6 HCストレージ・サーバー: 10個のアクティブCPUコア、6個のハード・ディスクおよび2個のフラッシュ・ディスクが有効になっている必要があります
- X6 EFストレージ・サーバー: 10個のアクティブCPUコアおよび4個のフラッシュ・ディスクが有効になっている必要があります
- X7 HCストレージ・サーバー: 10個のアクティブCPUコア、6個のハード・ディスクおよび2個のフラッシュ・ディスクが有効になっている必要があります
- X7 EFストレージ・サーバー: 10個のアクティブCPUコアおよび4個のフラッシュ・ディスクが有効になっている必要があります
この構成のすべてのコアおよびディスクが使用可能と表示されている場合は、エイス・ラック構成を有効にします。
```
CellCLI> ALTER CELL eighthRack=true
```

3.7.2 損傷したCELLBOOT USBフラッシュ・ドライブの再作成

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

3.8 「ストレージ・セルの既存のエラスティック構成の変更」

この項では、既存のエラスティック構成に次の変更を行う方法について説明します。

関連トピック

データベース・サーバーの既存のエラスティック構成の変更

3.8.1 セル・ノードの追加

このシナリオでは、ディスク・グループを含む既存のOracle Exadata Database Machineに新しいストレージ・サーバー(またはセル)を追加する必要があります。

これが新しいストレージ・サーバーである場合、次の手順を実行します。
1. 目的のストレージ・グリッドで新しいストレージ・サーバーを利用できるようにするために、必要なすべてのケーブル接続要件を完了します。
  Oracle Exadata Database Machineインストレーションおよび構成ガイドを参照してください。
2. 適切なOracle Exadata System Softwareイメージを使用してストレージ・サーバーをイメージ化し、IPアドレスの入力を求めるプロンプトが表示されたら適切な情報を入力します。
3. 手順3にスキップします。
ラック内の既存のストレージ・サーバーをInfiniBandネットワーク内の別のクラスタに割り当てる場合は、追加するストレージ・サーバーのInfiniBandインタフェース(ib0およびib1)に割り当てられているIPアドレスをメモします。
クラスタ内の任意のデータベース・サーバー上で次の手順を実行します。
1. cd /etc/oracle/cell/network-config
2. cp cellip.ora cellip.ora.orig
3. cp cellip.ora cellip.ora-bak
4. /etc/oracle/cell/network-config/cellip.ora-bakに新しいエントリを追加します。
5. 次のコマンドを使用して、編集後のファイルをすべてのデータベース・ノードのcellip.oraファイルにコピーします。ここで、database_nodesは、クラスタ内の各データベース・サーバーの名前が個別の行として含まれたファイルを指します。
```
/usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d /etc/oracle/cell/network-config/cellip.ora
```
すべてのOracle RACノードの/etc/oracle/cell/network-config/cellip.oraファイルに、前述の手順からのIPアドレスを追加します。
既存のストレージ・サーバーにOracle Auto Service Request (ASR)のアラートが設定されていた場合は、追加するストレージ・サーバー用にセルのOracle ASRアラートを構成します。
1. いずれかの既存のストレージ・サーバーから、セルのsnmpsubscriber属性をリストします。
```
cellcli -e LIST CELL ATTRIBUTES snmpsubscriber
```
2. 次のコマンドをcelladminユーザーとして実行して、同じsnmpsubscriber属性値を新しいストレージ・サーバーに適用します。この際、snmpsubscriberを前のコマンドの値に置き換えてください。
```
cellcli -e "ALTER CELL snmpsubscriber=snmpsubscriber"
```
3. 既存のストレージ・サーバーから、セルのアラートを構成するために必要なセルの属性をリストします。
```
cellcli -e LIST CELL ATTRIBUTES
 notificationMethod,notificationPolicy,smtpToAddr,smtpFrom,
 smtpFromAddr,smtpServer,smtpUseSSL,smtpPort
```
4. 次のコマンドをcelladminユーザーとして実行して、同じ値を新しいストレージ・サーバーに適用します。この際、プレースホルダを既存のストレージ・サーバーから検出された値に置き換えてください。
```
cellcli -e "ALTER CELL
 notificationMethod='notificationMethod',
 notificationPolicy='notificationPolicy',
 smtpToAddr='smtpToAddr',
 smtpFrom='smtpFrom',
 smtpFromAddr='smtpFromAddr',
 smtpServer='smtpServer',
 smtpUseSSL=smtpUseSSL,
 smtpPort=smtpPort"
```
追加するセルのセル・ディスクを作成します。
1. celladminとしてセルにログインし、次のコマンドを実行します。
```
cellcli -e CREATE CELLDISK ALL
```
2. デフォルトでフラッシュ・ログが作成されたことを確認します。
```
cellcli –e LIST FLASHLOG
```
  フラッシュ・ログの名前が表示されます。cellnodename_FLASHLOGのような名前で、ステータスがnormalになっていることを確認してください。
  
  フラッシュ・ログが存在しない場合は作成します。
```
cellcli -e CREATE FLASHLOG ALL
```
3. 現在のフラッシュ・キャッシュ・モードを、既存セルのフラッシュ・キャッシュ・モードと比較します。
```
cellcli -e LIST CELL ATTRIBUTES flashcachemode
```
  フラッシュ・キャッシュ・モードを変更して既存のセルのフラッシュ・キャッシュ・モードに一致させるには、次の手順を実行します。
  1. フラッシュ・キャッシュが存在し、セルがWriteBackフラッシュ・キャッシュ・モードの場合、フラッシュ・キャッシュを最初にフラッシュする必要があります。
```
cellcli –e ALTER FLASHCACHE ALL FLUSH
```
    コマンドが戻るまで待機します。
  2. フラッシュ・キャッシュを削除します。
```
cellcli -e DROP FLASHCACHE ALL
```
  3. フラッシュ・キャッシュ・モードを変更します。
    
    flashCacheMode属性の値は、writebackまたはwritethroughのいずれかです。クラスタ内の他のストレージ・セルと同じフラッシュ・キャッシュ・モードになるように、値を設定する必要があります。
```
cellcli -e "ALTER CELL flashCacheMode=writeback_or_writethrough"
```
  4. フラッシュ・キャッシュを作成します。
```
cellcli -e CREATE FLASHCACHE ALL
```
4. celladminとしてセルにログインし、次のコマンドを実行します。
```
cellcli -e CREATE CELLDISK ALL
```
5. celladminとしてセルにログインし、次のコマンドを実行します。
```
cellcli -e CREATE CELLDISK ALL
```
追加するセルのグリッド・ディスクを作成します。
1. 既存のセルからの既存のグリッド・ディスクのsizeとcachingpolicy属性を問い合せます。
```
CellCLI> LIST GRIDDISK ATTRIBUTES name,asmDiskGroupName,cachingpolicy,size,offset
```
2. 前述のコマンドで検出された各ディスク・グループについて、クラスタに追加する新しいセルのグリッド・ディスクを作成します。
  前述のコマンドで報告されたその特定のディスク・グループの既存のグリッド・ディスクの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 ALL HARDDISK
 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ノードから参照できることを確認します
次の例では、Grid_homeは、Oracle Grid Infrastructureソフトウェアがインストールされているディレクトリを指します。
```
$Grid_home/bin/kfod op=disks disks=all | grep cellName_being_added
```
kfodコマンドでは、前述の手順6で作成したすべてのグリッド・ディスクがリストされる必要があります。
新しく作成されたグリッド・ディスクをそれぞれの既存のOracle ASMディスク・グループに追加します。
この例では、comma_separated_disk_namesは、disk_group_nameに対応する手順6のディスク名を指します。
```
SQL> ALTER DISKGROUP disk_group_name ADD DISK 'comma_separated_disk_names';
```
このコマンドはデフォルトの電源レベルでOracle ASMリバランス操作を開始します。
GV$ASM_OPERATIONの問合せにより、リバランスの進捗状況を監視します。
```
SQL> SELECT * FROM GV$ASM_OPERATION;
```
リバランスが完了すると、Oracle RACクラスタへのセルの追加は完了です。
Oracle EXAchkの最新バージョンをダウンロードして実行し、結果の構成にOracle Exadata Database Machineの最新のベスト・プラクティスが実装されたことを確認します。

3.8.2 エイス・ラック・クラスタへの新規セル・ノードの追加

既存のOracle Exadata Database Machine X7エイス・ラックに新しいOracle Exadata Database Machine X7ストレージ・サーバーを追加するには、次の手順を実行します。

新しいストレージ・サーバーで、フラッシュ・キャッシュ、フラッシュ・ログおよびセル・ディスクを削除します。
```
cellcli -e drop flashcache all
cellcli -e drop flashlog all
cellcli -e drop celldisk all
```
新しいストレージ・サーバーで、eighthrack属性を有効にします。
```
cellcli -e alter cell eighthRack=true
```
新しいストレージ・サーバーで、セル・ディスクを作成します。
```
cellcli -e create celldisk all
```
新しいストレージ・サーバーで、フラッシュ・ログを作成します。
```
cellcli -e create flashlog all
```
既存のストレージ・サーバーで、セル属性flashcachemodeの値を取得します。
```
cellcli -e list cell attributes flashcachemode
```
新しいストレージ・サーバー上のflashcachemode属性はデフォルトでWriteThroughに設定されます。すべてのストレージ・サーバーでは、同じflashcachemode属性が設定されている必要があります。

既存のストレージ・サーバーがWriteBackモードを使用している場合は、次に示すように、新しいストレージ・サーバーで属性flashcachemodeを変更する必要があります。
```
cellcli -e alter cell flashcachemode=writeback
```
新しいストレージ・サーバーで、フラッシュ・キャッシュを作成します。
```
cellcli -e create flashcache all
```
既存のストレージ・サーバーで、グリッド・ディスクの構成に関する情報を取得します。
```
cellcli -e list griddisk attributes name,offset,size,cachingpolicy
```
新しいストレージ・サーバーで、グリッド・ディスクを作成します(既存のセルの構成と一致するよう一連のグリッド・ディスクごとに手順を繰り返します)。
次のコマンドでは、斜体文字を、手順7で取得した対応する値に置き換えます。
```
cellcli -e CREATE GRIDDISK ALL HARDDISK 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\"
```
新しいストレージ・サーバーで、(手順7で取得した情報と比較することにより)グリッド・ディスクの構成が既存のストレージ・サーバーのグリッド・ディスクの構成と同じであることを検証します。
```
cellcli -e list griddisk attributes name,offset,size,cachingpolicy
```
環境内にパーティション鍵(pkey)が実装されている場合、InfiniBandインタフェースのpkeyを構成します。このタスクについては、「ExadataでのOVM RACクラスタ間のInfiniBandパーティションの実装」(My Oracle Supportのドキュメント ID 2075398.1)の手順6を参照してください。
新しいストレージ・サーバーで、両方のInfiniBandのポートのIPアドレスを識別します。
```
cellcli -e list cell attributes name,ipaddress1,ipaddress2
```
すべての計算ノードの/etc/oracle/cell/network-config/cellip.oraファイルに、手順11のIPアドレスを追加します。
クラスタ内の任意のデータベース・サーバー上で次の手順を実行します。
1. cd /etc/oracle/cell/network-config
2. cp cellip.ora cellip.ora.orig
3. cp cellip.ora cellip.ora-bak
4. /etc/oracle/cell/network-config/cellip.ora-bakに新しいエントリを追加します。
5. 次のコマンドを使用して、編集後のファイルをすべてのデータベース・ノードのcellip.oraファイルにコピーします。ここで、database_nodesは、クラスタ内の各データベース・サーバーの名前が個別の行として含まれたファイルを指します。
```
/usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d /etc/oracle/cell/network-config/cellip.ora
```

任意のOracle ASMインスタンスに接続し、新しいストレージ・サーバーのグリッド・ディスクが検出可能であることを確認してください。

SQL> set pagesize 30
SQL> set linesize 132
SQL> col path format a70
SQL> SELECT inst_id,path FROM gv$asm_disk WHERE header_status='CANDIDATE' 
  2> ORDER BY inst_id,path;

INST_ID    PATH
---------- ----------------------------------------------------------------------
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_00_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_01_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_02_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_03_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_04_celadm11
         1 o/192.168.17.235;192.168.17.236/DATAC1_CD_05_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_00_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_01_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_02_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_03_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_04_celadm11
         1 o/192.168.17.235;192.168.17.236/RECOC1_CD_05_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_00_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_01_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_02_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_03_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_04_celadm11
         2 o/192.168.17.235;192.168.17.236/DATAC1_CD_05_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_00_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_01_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_02_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_03_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_04_celadm11
         2 o/192.168.17.235;192.168.17.236/RECOC1_CD_05_celadm11

Oracle ASMインスタンスの1つに接続し、新規ディスクを既存のディスク・グループに追加します。
```
SQL> ALTER DISKGROUP datac1 ADD DISK ‘o/192.168.17.235;192.168.17.
236/DATAC1*’;
SQL> ALTER DISKGROUP recoc1 ADD DISK ‘o/192.168.17.235;192.168.17.
236/RECOC1*’;
```
注意:
ディスクの追加によってトリガーされたリバランス操作は、デフォルトのOracle Maximum Availability Architecture (MAA)ベスト・プラクティス電源(4になります)で実行されます。アプリケーションのサービス・レベルのパフォーマンスに問題がない場合、高速リバランスのために電源を大きくすることを検討します。

障害グループごとにディスク数のレポートを取得します。High Capacity (HC) Storage Serverでは障害グループごとに6台のディスクが予想され、Extreme Flash (EF) Storage Serverでは障害グループごとに4台のディスクが予想されます。

SQL> SELECT d.group_number,dg.name,failgroup,mode_status,COUNT(*)
  2> FROM v$asm_disk d,v$asm_diskgroup dg
  3> WHERE d.group_number=dg.group_number
  4> AND failgroup_type='REGULAR'
  5> GROUP BY d.group_number,dg.name,failgroup,mode_status;

GROUP_NUMBER NAME                FAILGROUP            MODE_ST COUNT(*)
------------ ------------------- -------------------- ------- --------
           1 DATAC1              CELADM08             ONLINE         6
           1 DATAC1              CELADM09             ONLINE         6
           1 DATAC1              CELADM10             ONLINE         6
           1 DATAC1              CELADM11             ONLINE         6
           2 RECOC1              CELADM08             ONLINE         6
           2 RECOC1              CELADM09             ONLINE         6
           2 RECOC1              CELADM10             ONLINE         6
           2 RECOC1              CELADM11             ONLINE         6

既存のストレージ・サーバーにOracle Auto Service Request (ASR)のアラートが設定されていた場合は、追加するストレージ・サーバー用にセルのOracle ASRアラートを構成します。
1. いずれかの既存のストレージ・サーバーから、セルのsnmpsubscriber属性をリストします。
```
cellcli -e LIST CELL ATTRIBUTES snmpsubscriber
```
2. 次のコマンドをcelladminユーザーとして実行して、同じsnmpsubscriber属性値を新しいストレージ・サーバーに適用します。この際、snmpsubscriberを前のコマンドの値に置き換えてください。
```
cellcli -e "ALTER CELL snmpsubscriber=snmpsubscriber"
```
3. 既存のストレージ・サーバーから、セルのアラートを構成するために必要なセルの属性をリストします。
```
cellcli -e LIST CELL ATTRIBUTES
 notificationMethod,notificationPolicy,smtpToAddr,smtpFrom,
 smtpFromAddr,smtpServer,smtpUseSSL,smtpPort
```
4. 次のコマンドをcelladminユーザーとして実行して、同じ値を新しいストレージ・サーバーに適用します。この際、プレースホルダを既存のストレージ・サーバーから検出された値に置き換えてください。
```
cellcli -e "ALTER CELL
 notificationMethod='notificationMethod',
 notificationPolicy='notificationPolicy',
 smtpToAddr='smtpToAddr',
 smtpFrom='smtpFrom',
 smtpFromAddr='smtpFromAddr',
 smtpServer='smtpServer',
 smtpUseSSL=smtpUseSSL,
 smtpPort=smtpPort"
```

3.8.3 既存のExadataストレージ・グリッドの拡張

このシナリオでは、Exadataラック内にExadataストレージ・セルが存在し、最も拡張の必要なExadataストレージ・グリッドにストレージ・セルを追加します。

現在のクラスタからストレージ・セルを廃止します。これを実行するには、「既存のディスク・グループまたはストレージ・グリッドからのストレージ・セルの削除」の手順に従ってください。
目的のExadataストレージ・グリッドにストレージ・セルを追加します。これを実行するには、「セル・ノードの追加」の手順に従ってください。
最新のexachkをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

3.8.4 既存のディスク・グループまたはストレージ・グリッドからのストレージ・セルの削除

既存のOracle Exadataストレージ・グリッドからストレージ・セルを削除できます。

Oracle ASMから削除されるセルに属するディスクを削除します。
注意:
Oracle Exadata Oracle VMデプロイメントでは、すべてのVMクラスタから次のサブステップを実行する必要があります。
1. クラスタ内の任意のノードにログインします。
2. 対象となるExadataセルのクラスタで使用されているグリッド・ディスクのリストを問い合せます。
```
Grid_home/bin/asmcmd  lsdsk --suppressheader | grep cellName_being_removed | awk -F'/' '{print $NF}'
```
  注意:
  削除されるストレージ・セルからのディスクを含むすべてのディスク・グループ内の使用可能な空き領域が、そのディスク・グループに割り当てられた記憶域の少なくとも15%であることを確認してください。
3. 前述のコマンドで返されたOracle ASMディスクをそれぞれのディスク・グループから削除します。
```
SQL> ALTER DISKGROUP diskgroup_name DROP DISKS IN FAILGROUP cellName_being_removed;
```
4. このディスク削除操作により、デフォルトの電源レベルでリバランス操作が開始されます。次のコマンドを使用して、リバランスを監視します。
```
SQL> SELECT * FROM gv$asm_operation;
```
  リバランスが完了するまで、つまり、gv$asm_operationから行が返されなくなるまで待ちます。
5. すべてのディスク・グループが、削除されるセルのディスクを参照していないことを確認します。
```
SQL> SELECT path, name, header_status, mode_status, mount_status, state,
 failgroup FROM v$asm_disk ORDER BY path;
```
  削除されるセルに属するすべてのディスクのheader_status列は、「FORMER」と表示される必要があります。
  
  注意:
  Exadata Oracle VMデプロイメントでは、すべてのOracle VMクラスタから前述のサブステップを実行する必要があります。
削除するセルをクリーンアップします。
celladminとしてセルにログインし、次のコマンドを実行します。各グリッド・ディスクに対して次のコマンドを実行します。
1. グリッド・ディスクを削除します。
```
cellcli -e drop griddisk all prefix=prefix_of_the_grid_disk
```
2. フラッシュ・キャッシュが存在し、セルがWriteBackフラッシュ・キャッシュ・モードの場合、削除前にフラッシュ・キャッシュをフラッシュする必要があります。
```
cellcli -e alter flashcache all flush
```
  コマンドが戻るまで待機します。
3. フラッシュ・キャッシュを削除します。
```
cellcli -e drop flashcache all
```
4. セル・ディスクを削除します。
```
cellcli -e drop celldisk all
```
  データを安全に消去するには、DROP CELLDISKコマンドをeraseオプションを指定して実行するか、DROP CELLコマンドをeraseオプションを指定して実行します。
  
  DROP CELLコマンドの下の表内に消去操作の所要時間が表示されます。
クラスタ内のすべてのデータベース・サーバー・ノードの/etc/oracle/cell/network-config/cellip.oraから、削除するセルのエントリを削除します。
クラスタ内の任意のデータベース・サーバー・ノードで次の手順を実行します。
1. cd /etc/oracle/cell/network-config
2. cp cellip.ora cellip.ora.orig
3. cp cellip.ora cellip.ora-bak
4. 削除するセルのエントリを/etc/oracle/cell/network-config/cellip.ora-bakから削除します。
5. /usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d /etc/oracle/cell/network-config/cellip.ora
  database_nodesは、クラスタ内の各データベース・サーバーの名前が含まれているファイルを参照します。名前は、それぞれ別の行にあります。
Oracle ExaCHKの最新バージョンをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。