Preparing Systems with Remote Mount BBU

1.9.1.1.1 Preparing Systems with Remote Mount BBU

Describes how to prepare to remove the disk controller BBU on systems with remote mount BBU.

If your system does not have a remote mount BBU, see Preparing Systems That Do Not Have a Remote Mount BBU.

Log in as the root user.
Get the version of the image that is running on the server in the rack that requires service.
```
# imageinfo -ver
11.2.3.2.1.130302
```
The version is the first five parts, such as 11.2.3.2.1 in the example. The last part is the image date.
Prepare the disk controller BBU for removal.

If you are running version 12.1.2.1.0 or later:
1. Drop the disk controller BBU for replacement:
```
DBMCLI> alter dbserver bbu drop for replacement
```
2. Verify the BBU status has been updated.
```
DBMCLI> list dbserver attributes bbustatus -
         dropped for replacement
```
If you are running versions between 11.2.3.3.0 and 12.1.2.1.0:
1. Drop the disk controller BBU for replacement.
```
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -drop_bbu_for_replacement
```
2. Verify the status has been updated.
```
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -list_bbu_status
BBU status: dropped for replacement.
```
If you are running version 11.2.3.2.x:
1. Locate the server in the rack being serviced, and turn on the indicator light.
  Exadata Storage Servers are identified by a number 1 through 18, where 1 is the lowest Storage Server in the rack installed in RU2, counting up to the top of the rack.
  
  Exadata Database Nodes are identified by a number 1 through 8, where 1 is the lowest most database node in the rack installed in RU16.
  
  Turn on the locate indicator light for easier identification of the server being serviced. If the server number has been identified, then the Locate Button on the front panel may be pressed. To turn on the indicator light remotely, use any of the following methods:
  - From a login to the CellCli on Exadata Storage Servers:
```
CellCli> alter cell led on
```
  - From a login to the server's ILOM:
```
-> set /SYS/LOCATE value=Fast_Blink
```
  - From a login to the server's root account:
```
# ipmitool chassis identify force
Chassis identify interval: indefinite
```
2. Check that HBA can see the battery and its current status.
  
  Note:
  
  If you are running on Solaris, use /opt/MegaRAID/MegaCli in place of /opt/MegaRAID/MegaCli/MegaCli64 in the commands below.
```
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
```
  The default output should show that the battery is still visible and may show low voltage or other issues depending on the fault. It may return an error reading the BBU if it is hard failed and no longer accessible to the HBA.
3. Verify the current cache policy for all logical volumes.
```
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
```
  The default cache policy should be WriteBack for all volumes. If the battery is functioning normally it will report as current cache policy WriteBack. However if it is failed it may report current cache policy as WriteThrough.
4. Set the cache policy for all logical volumes to WriteThrough cache mode, which does not use the battery.
```
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
```
5. Verify the current cache policy for all logical volumes is now WriteThrough.
```
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
```

Parent topic: Step 1: Prepare the Disk Controller BBU for Removal