ステップ1: ディスク・コントローラBBUの取り外しの準備

1.9.2.1 ステップ1: ディスク・コントローラBBUの取り外しの準備

特定のX3-2、X4-2およびX4-8データベース・ノード、X3-2、X4-2、およびX3-8、X4-8ストレージ・サーバーでは、BBUはリモートでマウントされ、アクセスするのにシステムのシャットダウンは不要です。ただし、ディスク・ボリュームへのデータ破損を回避するには、RAID HBAから取り外せるように準備する必要があります。X3-8データベース・ノードのリモート・マウントBBUオプションはありません。

リモート・マウントBBUがあるシステムの場合

システムにリモート・マウントBBUがある場合は、この項のステップを実行します。システムにリモート・マウントBBUがない場合は、「リモート・マウントBBUがないシステムの場合」のステップを実行します。

rootユーザーとしてログインします。
サービスを必要とするラックのサーバーで実行されているイメージのバージョンを取得します。
```
# cellcli -e LIST CELL ATTRIBUTES releaseVersion
11.2.3.2.1
```
ディスク・コントローラBBUを削除します。
バージョン11.2.3.3.0以上を実行している場合:
1. 交換対象のディスク・コントローラBBUを削除します。次のコマンドをcelladminまたはrootユーザーとして実行します。
```
# cellcli -e ALTER CELL BBU DROP FOR REPLACEMENT
HDD disk controller battery has been dropped for replacement
```
2. 交換対象のBBUが削除されたことを確認します。
```
# cellcli -e LIST CELL ATTRIBUTES bbustatus
dropped for replacement.
```
バージョン11.2.3.2.xを実行している場合:
1. サービス対象のラックのサーバーを特定し、インジケータ・ライトをオンにします。
  Exadata Storage Serverは、1から18の番号で識別され、RU2に取り付けられたラックの最下段のStorage Serverが1で、ラックの上部に向かって番号が順に上がっていきます。
  
  Exadata Database Nodeは、1から8の番号で識別され、RU16に取り付けられたラックの最下段のデータベース・ノードが1です。
  
  サービス対象のサーバーを簡単に識別できるように、検出インジケータ・ライトをオンにします。サーバーの番号が確認されたら、前面パネルの検出ボタンを押すことができます。
  
  インジケータ・ライトをリモートでオンにし、次の方法を使用します。
  
  Exadata Storage ServerのCellCliにログイン:
```
CellCli> ALTER CELL LED ON
```
  サーバーのILOMにログイン:
```
-> set /SYS/LOCATE value=Fast_Blink
```
  サーバーのrootアカウントにログイン:
```
# ipmitool chassis identify force
Chassis identify interval: indefinite
```
2. HBAでバッテリと現在のステータスを表示できることを確認します。
  
  ノート:
  
  Solarisで実行している場合は、次のコマンドの/opt/MegaRAID/MegaCli/MegaCli64の代わりに/opt/MegaRAID/MegaCliを使用します。
```
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
```
  デフォルトの出力には、バッテリがまだ表示されていることが表示されますが、障害に応じて低電圧またはその他の問題が表示される場合もあります。BBUに重大な障害が発生し、HBAにアクセスできなくなった場合、BBUの読取りエラーが返されることがあります。
3. すべての論理ボリュームで現在のキャッシュ・ポリシーを確認します。
```
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
```
  デフォルトのキャッシュ・ポリシーは、すべてのボリュームでWriteBackです。バッテリが正常に機能している場合、現在のキャッシュ・ポリシーはWriteBackとしてレポートされます。ただし、障害が発生した場合、現在のキャッシュ・ポリシーはWriteThroughとしてレポートされることがあります。
4. すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モード(バッテリを使用しない)に設定します。
```
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
```
5. すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルーになっていることを確認します。
```
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
```

リモート・マウントBBUがないシステムの場合

システムにリモート・マウントBBUがない場合は、この項のステップを実行します。システムにリモート・マウントBBUがある場合は、「リモート・マウントBBUがあるシステムの場合」を参照してください。

リモート・マウントされたバッテリがシステムに取り付けられていない場合は、バッテリの交換が必要なノードをシャットダウンする必要があります。

ノート:

Oracle Exadata System Software 19.0以上を実行している場合は、次のコマンドで/opt/MegaRAID/MegaCli/MegaCli64を/opt/MegaRAID/storcli/storcli64に置き換えます。

すべてのRAIDディスク・ボリュームをライトスルー・モードに戻し、RAIDキャッシュ・メモリーのすべてのデータがディスクにフラッシュされ、バッテリの交換時にデータの損失が発生しないことを確認します。
1. すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モードに設定します。
```
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
```
2. すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルー(バッテリーを使用しない)になっていることを確認します。
```
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
```
サーバー・オペレーティング・システムをシャットダウンします。
Exadata Storage Serverの電源を切断する際は、次の点に注意してください。
- ディスク障害が発生したストレージ・サーバーが他にないことを確認します。別のディスクで障害が発生中にストレージ・サーバーをシャットダウンすると、データベース・プロセスおよびOracle ASMがクラッシュする場合がありますが、その可能性があるのは、サーバーのディスクがオフラインになったときに、パートナー・ペアの両方のディスクが失われる場合です。
- ラックの残りにディスクの障害が発生していない1つのExadata Storage Serverの電源を切断しても、実行中のデータベース・プロセスまたはOracle ASMには影響しません。
- 複数のExadata Storage Serverを停止する前に、すべてのデータベースおよびOracle Clusterwareプロセスを停止する必要があります。これが必要な場合の詳細は、Exadataオーナーズ・ガイドを参照してください。
オフラインに切り替えられるとすぐに、ディスクはASMによって削除されます。リストア対象のASMディスクの修復タイマーよりも長い時間ストレージ・サーバーがオフラインの場合、Exadata Storage Serversの電源を切断するか再起動すると、データベースのパフォーマンスが影響を受けることがあります。デフォルトのDISK_REPAIR_TIME属性値は3.6時間で、コンポーネントの交換には適切ですが、長い時間が必要な場合は、変更が必要になることがあります。
1. ASMにログインして次の問合せを実行し、ディスクの修復時間を確認します。
```
SQL> SELECT dg.name,a.value FROM v$asm_attribute a, v$asm_diskgroup dg
 WHERE a.name = 'disk_repair_time' AND a.group_number = dg.group_number;
```
  交換対象のコンポーネントの交換に十分な値の場合は、変更する必要はありません。
  
  変更する必要がある場合は、次の文を使用できます。
```
SQL> ALTER DISKGROUP DATA SET ATTRIBUTE 'disk_repair_time'='8.5H';
```
2. ASMが問題なく、グリッド・ディスクがオフラインになるかどうかを確認します。次のコマンドは、リストされているグリッド・ディスクでYesを返します。
```
# cellcli -e LIST GRIDDISK ATTRIBUTES name,asmmodestatus,asmdeactivationoutcome
...sample ...
DATA_CD_09_cel01 ONLINE Yes
DATA_CD_10_cel01 ONLINE Yes
DATA_CD_11_cel01 ONLINE Yes
RECO_CD_00_cel01 ONLINE Yes
RECO_CD_01_cel01 ONLINE Yes
...repeated for all griddisks....
```
  1つ以上のディスクでasmdeactivationoutcome='Yes'が返されない場合は、各ディスク・グループを確認し、そのディスク・グループのデータ冗長性をリストアします。ディスク・グループのデータ冗長性が完全にリストアされたら、コマンドを再実行して、すべてのグリッド・ディスクでasmdeactivationoutcome='Yes'になっていることを確認します。すべてのディスクでasmdeactivationoutcome='Yes'が返されたら、次のステップに進みます。
  
  ノート:
  
  1つ以上のグリッド・ディスクがasmdeactivationoutcome='Yes'を返さない場合に、セル・サービスを停止すると、影響を受けるディスク・グループがOracle ASMによってディスマウントされ、データベースが突然停止します。
3. 保守用に電源を切断する必要があるセルのすべてのグリッド・ディスクを非アクティブ化します。これは、最大で10分以上になる場合があります。
```
# cellcli
...sample ...
CellCLI> ALTER GRIDDISK ALL INACTIVE
GridDisk DATA_CD_00_dmorlx8cel01 successfully altered
GridDisk DATA_CD_01_dmorlx8cel01 successfully altered
GridDisk DATA_CD_02_dmorlx8cel01 successfully altered
GridDisk RECO_CD_00_dmorlx8cel01 successfully altered
GridDisk RECO_CD_01_dmorlx8cel01 successfully altered
GridDisk RECO_CD_02_dmorlx8cel01 successfully altered
...repeated for all griddisks...
```
4. グリッド・ディスクがオフラインになったことを確認します。ディスクがオフラインになり、ASMで非アクティブなると、出力には、asmmodestatus='UNUSED'または'OFFLINE'、およびasmdeactivationoutcome=Yesがすべてのグリッド・ディスクで表示されます。
```
CellCLI> LIST GRIDDISK ATTRIBUTES name,status,asmmodestatus,asmdeactivationoutcome
DATA_CD_00_dmorlx8cel01 inactive OFFLINE Yes
DATA_CD_01_dmorlx8cel01 inactive OFFLINE Yes
DATA_CD_02_dmorlx8cel01 inactive OFFLINE Yes
RECO_CD_00_dmorlx8cel01 inactive OFFLINE Yes
RECO_CD_01_dmorlx8cel01 inactive OFFLINE Yes
RECO_CD_02_dmorlx8cel01 inactive OFFLINE Yes
...repeated for all griddisks...
```
5. すべてのディスクがオフラインになり、非アクティブになると、セルをシャットダウンできます。
```
# shutdown -hP now
```
  Exadata Storage Serverの電源を切断すると、すべてのストレージ・サービスが自動的に停止します。

親トピック: Exadata Storage Serverのディスク・コントローラBBUの交換