Sun Microsystems, Inc.  Sun System Handbook - ISO 4.1 October 2012 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-71-1390836.1
Update Date:2012-08-10
Keywords:

Solution Type  Technical Instruction Sure

Solution  1390836.1 :   How to Replace a Hard Drive in an Exadata Storage Server (Predictive Failure)  


Related Items
  • Exadata Database Machine X2-2 Half Rack
  •  
  • Exadata Database Machine X2-8
  •  
  • Exadata Database Machine X2-2 Qtr Rack
  •  
  • Exadata Database Machine X2-2 Hardware
  •  
  • Exadata Database Machine X2-2 Full Rack
  •  
  • Exadata Database Machine V2
  •  
  • Oracle Exadata Storage Server Software
  •  
Related Categories
  • PLA-Support>Sun Systems>Sun_Other>Sun Collections>SN-OTH: x64-CAP VCAP
  •  
  • .Old GCS Categories>ST>Server>Engineered Systems>Exadata>Hardware
  •  
  • .Old GCS Categories>Sun Microsystems>Specialized Systems>Database Systems
  •  




Applies to:

Exadata Database Machine X2-8 - Version Not Applicable and later
Exadata Database Machine X2-2 Qtr Rack - Version Not Applicable and later
Exadata Database Machine V2 - Version Not Applicable to Not Applicable [Release N/A]
Oracle Exadata Storage Server Software - Version 11.2.1.2.0 to 11.2.3.1.1 [Release 11.2]
Exadata Database Machine X2-2 Hardware - Version Not Applicable to Not Applicable [Release N/A]
Information in this document applies to any platform.

Goal

How to Replace a Hard Drive in an Exadata Storage Server (Cell) (Predictive Failure)
(For Hard Failure, please see Doc ID 1386147.1)

Fix

DISPATCH INSTRUCTIONS:
The customer may choose to use the on-site spare disk provided for Exadata Storage Servers and do the replacement themselves. In this case, the spares should be replenished using a parts-only dispatch.

The following information will be required prior to dispatch of a replacement:

  • Type of Exadata (V2 or X2) / Exadata Storage Expansion Rack
  • Type of storage cell/Node (V2=x4275 / X2 =x4270m2)
  • Size of failed drive and part number
  • Name/location of storage cell
  • Slot number of failed drive
  • Image Version (output of "/opt/oracle.cellos/imageinfo -all")

How to identify which Exadata disk FRU part number to order , based on image and vendor and mixed disk support status - Note 1416303.1

WHAT SKILLS DOES THE ENGINEER NEED:
The engineer must be Exadata trained, have familiarity with the storage cells and replacing hard drives.

TIME ESTIMATE: 60 minutes

Complete process may take longer depending on rebalance time that may be required.

TASK COMPLEXITY: 0
CRU-optional; default is FRU with Task Complexity: 2


FIELD ENGINEER INSTRUCTIONS:
PROBLEM OVERVIEW:
Failed hard drive in Exadata.

This document is specific to hard drives in "predictive failure" state. There are situations where a drive will be flagged at first as a predictive failure but the drive will hard fail (go into "critical" status) before the rebalance operation has completed.  In such cases, please reference Doc ID 1386147.1 for replacement steps.

WHAT STATE SHOULD THE SYSTEM BE IN TO BE READY TO PERFORM THE RESOLUTION ACTIVITY?:
It is expected that the Exadata Machine is up and running and the storage cell containing the failed drive is booted and available.

If there are multiple drives to be replaced within an Exadata machine (or between an Exadata interconnected with another Exadata or Expansion Cabinet), it is critical that only ONE DRIVE BE REPLACED AT A TIME to avoid the risk of data loss.  This is particularly important in the case of disks running in predictive failure status. Before replacing another disk in Exadata, ensure the rebalance operation has completed from the first replacement.

Before proceeding, confirm the part number of the part in hand (either from logistics or an on-site spare) matches the part number dispatched for replacement (especially important in cases where the customer has multiple racks of different drive types/sizes). 

It is expected that the customer's DBA has completed these steps prior to arriving to replace the disk. The following commands are provided as guidance in case the customer needs assistance checking the status of the system prior to replacement.  If the customer or the FSE requires more assistance prior to the physical replacement of the device, EEST/TSC should be contacted.

1. Confirm the drive needing replacement based on the output provided ("name" or "slotNumber" value) and LED status of drive.  For a predictive failure, the LED for the failed drive should have the "Service Action Required" amber LED illuminated/flashing.

For example, follow Doc ID 1112995.1 to determine the failed drive.

CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status="predictive failure" DETAIL
name: 20:3
deviceId: 19
diskType: HardDisk
enclosureDeviceId: 20
errMediaCount: 0
errOtherCount: 0
foreignState: false
luns: 0_3
makeModel: "SEAGATE ST360057SSUN600G"
physicalFirmware: 0805
physicalInterface: sas
physicalSerial: E07L8E
physicalSize: 558.9109999993816G
slotNumber: 3
status: predictive failure


In the output above, both the "name:" value (following the ":") and the "slotNumber" provide the slot of the physical device requiring replacement where the "status" field is "predictive failure" status.  In the above example, the slot is determined to be slot 3.  (slotNumber: 3 AND name: 20:3)

2. The Oracle ASM disks associated with the grid disks on the physical drive are automatically dropped, and an Oracle ASM rebalance will relocate the data from the predictively failed disk to other disks. This may take some time depending on the ASM rebalance power paramater setting, and how active the database is. Ensure the "status" of the disk is "predictive failure" AND that ASM has completed rebalancing before replacing the disk. If the rebalance is still in progress, then the disk is still in use for data and the replacement of the disk should wait until the rebalance has completed.

To verify the disk is succesfully dropped from ASM, do the following:

a. Login to a database node with the username for the owner of Oracle Grid Infrastructure home. Typically this is the 'oracle' user.

edx2db01 login: oracle
Password:
Last login: Thu Jul 12 14:43:10 on ttyS0
[oracle@edx2db01 ~]$

b. Select the ASM instance for this DB node and connect to SQL Plus:

[oracle@edx2db01 ~]$ . oraenv
ORACLE_SID = [oracle] ? +ASM1
The Oracle base has been set to /u01/app/oracle
[oracle@edx2db01 ~]$ sqlplus ' / as sysasm'

SQL*Plus: Release 11.2.0.2.0 Production on Thu Jul 12 14:45:20 2012

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options

SQL>

In the above output the “1” of “+ASM1” refers to the DB node number. For example, DB node #3 the value would be +ASM3.

c. Run this ASM query to check if a rebalance is in progress:

SQL> select group_number,name,state from v$asm_diskgroup;
SQL> select * from gv$asm_operation where state='RUN';

If there are active rows returned, then a rebalance is in progress or it failed. Wait and re-run the query until such time as no rows are returned.

If there are no rebalance operations in progress, the result will be:

no rows selected.

If the ASM rebalance failed with an error check the output ofGV$ASM_OPERATION.ERROR. If this returns a value then contact the SR owner for further guidance.

3. Verify the grid disks from that physical disk are no longer part of the ASM diskgroups:
a. Login to the cell server and enter the CellCLI interface

edx2cel01 login: celladmin
Password:
[celladmin@edx2cel01 ~]$ cellcli
CellCLI: Release 11.2.2.4.2 - Production on Mon Jul 23 16:21:17 EDT 2012

Copyright (c) 2007, 2009, Oracle.  All rights reserved.
Cell Efficiency Ratio: 1,000

CellCLI>

b. Identify the name of the diskgroups used by that disk:
CellCLI> list celldisk where lun=0_3 detail
         name:                   CD_03_edx2cel01
         comment:
         creationTime:           2012-05-18T11:41:53-04:00
         ...
         status:                 normal

CellCLI> list griddisk where celldisk=CD_03_edx2cel01
         DATA_Q1_CD_03_edx2cel01   active
         DBFS_DG_CD_03_edx2cel01   active
         RECO_Q1_CD_03_edx2cel01   active

CellCLI>

c. From the DB node, run the following ASM query:

SQL> set linesize 132
SQL> col path format a50
SQL> select group_number,path,header_status,mount_status,mode_status,name from V$ASM_DISK where path like '%CD_03_edx2cel01';

GROUP_NUMBER PATH                                               HEADER_STATU MOUNT_S MODE_ST NAME
------------ -------------------------------------------------- ------------ ------- ------- ------------------------------
           0 o/192.168.9.9/DBFS_DG_CD_03_edx2cel01              FORMER       CLOSED  ONLINE
           0 o/192.168.9.9/DATA_Q1_CD_03_edx2cel01              FORMER       CLOSED  ONLINE
           0 o/192.168.9.9/RECO_Q1_CD_03_edx2cel01              FORMER       CLOSED  ONLINE

SQL>

The group_number column should be '0',  and name field should be blank (or NULL).

If this is showing a different output including the name field bein populated, then  grid disks are still part of the ASM diskgroup, then they need to dropped.  To drop the grid disks:

SQL>alter diskgroup dbfs_dg drop disk DBFS_DG_CD_03_edx2cel01 rebalance power 4;
SQL>alter diskgroup reco_q1 drop disk RECO_q1_cd_03_edx2cel01 rebalance power 4;
SQL>alter diskgroup data_q1 drop disk DATA_Q1_CD_03_edx2cel01 rebalance power 4;

After dropping the disks, then repeat the above steps to check the rebalance status and wait for it to complete, then re-validate it has been dropped succesfully.

4. The Cell Management Server daemon monitors and takes action on replacement disks to automatically bring the new disk into the configuration. Verify the status of the msStatus is running on the Storage cell before replacing the disk, using the cell's CellCLI interface:

CellCLI> list cell attributes cellsrvStatus,msStatus,rsStatus detail
cellsrvStatus: running
msStatus: running
rsStatus: running

5. If the predictive failed drive is one of the system boot drives (slots 0 or 1), then the disk is a system disk that contains the running OS. Verify the root volume is in 'clean' state before hot replacing a system disk. If it is 'active' and the disk is hot removed, the OS may crash making the recovery more difficult.

a. Login as 'root' on the Storage Cell, and use 'df' to determine the md device name for "/" volume.

[root@dbm1cel1 /]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md5              10317752   2906660   6886980  30% /
tmpfs                 12265720         0  12265720   0% /dev/shm
/dev/md7               2063440    569452   1389172  30% /opt/oracle
/dev/md4                118451     37567     74865  34% /boot
/dev/md11              2395452     74228   2199540   4% /var/log/oracle

b. Use 'mdadm' to determine the volume status:

[root@dbm1cel1 ~]# mdadm -Q --detail /dev/md5
/dev/md5:
        Version : 0.90
  Creation Time : Wed May 16 20:37:31 2012
     Raid Level : raid1
     Array Size : 10482304 (10.00 GiB 10.73 GB)
  Used Dev Size : 10482304 (10.00 GiB 10.73 GB)
   Raid Devices : 2
  Total Devices : 3
Preferred Minor : 5
    Persistence : Superblock is persistent

    Update Time : Mon Jul 23 16:46:37 2012
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0

           UUID : 6de571d0:61eaac33:7050abfe:00bc6417
         Events : 0.348

    Number   Major   Minor   RaidDevice State
       0       8        5        0      active sync   /dev/sda5
       1      65      213        1      active sync   /dev/sdad5

       2       8       21        -      faulty spare
[root@edx2cel03 ~]# mdadm -Q --detail /dev/md5
/dev/md5:
        Version : 0.90
  Creation Time : Thu Mar 17 23:19:42 2011
     Raid Level : raid1
     Array Size : 10482304 (10.00 GiB 10.73 GB)
  Used Dev Size : 10482304 (10.00 GiB 10.73 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 5
    Persistence : Superblock is persistent

    Update Time : Wed Jul 18 11:53:34 2012
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : e75c1b6a:64cce9e4:924527db:b6e45d21
         Events : 0.108

    Number   Major   Minor   RaidDevice State
       0       8        5        0      active sync   /dev/sda5
       1       8       21        1      active sync   /dev/sdb5


The Devices section may or may not show as 'failed' with an extra disk "2" showing as "faulty spare. This is dependent on the state of the OS when the device went predicted failed.  The most important aspect is whether the state is "clean" or "active". "clean" is safe to hot remove, "active" is actively syncing the disk mirrors and should wait until it is "clean" before hot removing the disk.


WHAT ACTION DOES THE ENGINEER NEED TO TAKE:

Confirm the drive needing replacement based on the output provided ("name" or "slotNumber" value) and LED status of the drive.  For a predictive failure, the LED for the failed drive should have the "Service Action Required" amber LED illuminated/flashing. The cell server within the rack can be determined from the hostname usually, and the known default Exadata server numbering scheme. The server should also have its LOCATE white LED illuminated/flashing. 

Perform the physical replacement of the disk following the directions from the service manual of the respective server (see REFERENCE INFORMATION below):

Slot locations for Exadata Storage Servers based on Sun Fire X4275 and Sun Fire X4270M2 servers:
View from the front:

HDD2 HDD5 HDD8 HDD11
HDD1 HDD4 HDD7 HDD10
HDD0 HDD3 HDD6 HDD9

 

1. If it is not already, turn on the service LED for the device with the following command, where <ID> is the "name" value provided in the action plan (such as 20:3 in the example above):

CellCLI> alter physicaldisk <ID> serviceled on
CellCLI> alter physicaldisk 20:3 serviceled on

This will cause the disk's Amber fault LED to blink rapidly as a locate indication.

2. On the drive you plan to remove, push the storage drive release button to open the latch.

3. Grasp the latch and pull the drive out of the drive slot (Caution: The latch is not an ejector. Do not bend it too far to the right. Doing so can damage the latch. Also, whenever you remove a storage drive, you should replace it with another storage drive or a filler panel, otherwise the server might overheat due to improper airflow.)

4. Wait three minutes for the MS daemon to recognize the removal of the old drive.

5. Slide the new drive into the drive slot until it is fully seated.

6. Close the latch to lock the drive in place.

7. Verify the "OK/Activity" Green LED begins to flicker as the system recognizes the new drive. The other two LEDs for the drive should no longer be illuminated.

8. Wait three minutes for the MS daemon to start rebuilding the virtual drives before proceeding. Note: Do not run any controller commands in the service manual when replacing the disk. 

9. The server's locate and disk's service LED locate blinking function should automatically turn off. If it does not, it can be manually turned off for the device if it was turned on in step 1, using the same "<ID>" value:

CellCLI> alter physicaldisk 20:3 serviceled off

 

OBTAIN CUSTOMER ACCEPTANCE
- WHAT ACTION DOES THE CUSTOMER NEED TO TAKE TO RETURN THE SYSTEM TO AN OPERATIONAL STATE:

It is expected that the engineer stay on-site until the customer has given the approval to depart.  After the drive has been physically replaced, the system will automatically perform required actions to bring the drive active within ASM and mdadm if applicable.  The customer should check the status of the drive after replacement.  The following commands are provided as guidance in case the customer needs assistance checking the status of the system following replacement.  If the customer or the FSE requires more assistance following the physical replacement of the device, EEST/TSC should be contacted.

After replacing the physical disk on Exadata Storage Server, wait for three minutes before running any commands to query the device from the server.  CellCLI (examples below) should be the principle tool to query the drives.  If that is unsuccessful you can use "lsscsi" and "/opt/MegaRAID/MegaCli/MegaCli64 -PDList -a0" to verify the drive from an OS perspective.
 
1. When you replace a physical disk, first the disk must be acknowledged by the RAID controller before the rest of the system can access it. Login to the cell server and enter the CellCLI interface, and run the following command, where <ID> is the "name" value provided in the action plan:

CellCLI> LIST PHYSICALDISK <ID> detail
CellCLI> list physicaldisk 20:3 detail
         name:                   20:3
         ...
         luns:                   0_3
         ...
         physicalInsertTime:     2012-07-23T19:11:58-04:00
         ...
         slotNumber:             3
         status:                 normal
The "status" field should report "normal". Note also that the physicalInsertTime should be current date and time, and not an earlier time. If they are not, then the old disk entries may still be present and the disk replacement did not complete succesfully. If this is the case, refer to the SR owner for further assistance.

2. The firmware of the drive will be automatically upgraded to match the other disks in the system when the new drive is inserted, if it is below the supported version of the current image. If it is above the minimum supported version then no action will be taken, and the newer firmware will remain. This can be validated by the following command:

CellCLI> alter cell validate configuration

3. After the physical disk is replaced, a lun should be automatically created, and the grid disks and cell disks that existed on the previous disk in that slot are automatically re-created on the new physical disk. If those grid disks were part of an Oracle ASM group, then they will be added back to the disk group and the data will be rebalanced on them, based on the disk group redundancy and asm_power_limit parameter values.

Grid disks and cell disks can be verified with the following CellCLI command, where the lun name is reported in the physicaldisk output from step 1 above ("0_3" in this example"): 

CellCLI> list lun 0_3 detail
         name:                   0_3
         cellDisk:               CD_03_edx2cel01
         ...
         status:                 normal

CellCLI> list celldisk where lun=0_3 detail
         name:                   CD_03_edx2cel01
         comment:
         creationTime:           2012-07-23T19:12:04-04:00
         ...
         status:                 normal

CellCLI> list griddisk where celldisk=CD_03_edx2cel01 detail
         name:                   DATA_Q1_CD_03_edx2cel01
         availableTo:
         cellDisk:               CD_03_edx2cel01
         comment:
         creationTime:           2012-07-23T19:13:24-04:00
         diskType:               HardDisk
         errorCount:             0
         id:                     8cd3556f-ee21-4497-9e0d-10b7ed9b4e74
         offset:                 32M
         size:                   423G
         status:                 active

         name:                   DBFS_DG_CD_03_edx2cel01
         availableTo:
         cellDisk:               CD_03_edx2cel01
         comment:
         creationTime:           2012-07-23T19:14:08-04:00
         diskType:               HardDisk
         errorCount:             0
         id:                     26d6729c-9d24-44de-b8d9-91831e2010d2
         offset:                 528.734375G
         size:                   29.125G
         status:                 active

         name:                   RECO_Q1_CD_03_edx2cel01
         availableTo:
         cellDisk:               CD_03_edx2cel01
         comment:
         creationTime:           2012-07-23T18:15:31-04:00
         diskType:               HardDisk
         errorCount:             0
         id:                     09f3859b-2e2c-4b68-97ea-96570d1ded29
         offset:                 423.046875G
         size:                   105.6875G
         status:                 active

Status should be normal for the cell disks and active for the grid disks. All of the creation times should also match the insertion time of the replacement disk.  If they are not, then the old disk entries may still be present and the disk replacement did not complete succesfully. If this is the case, refer to the SR owner for further assistance.

Note: The lun name attribute will also be shown in the original alert generated by the storage cell.

4. To confirm that the status of the rebalance, connect to the ASM instance on a database node, and validate the disks were added back to the ASM diskgroups and a rebalance is running:

SQL> set linesize 132
SQL> col path format a50
SQL> select group_number,path,header_status,mount_status,name from V$ASM_DISK where path like '%CD_03_edx2cel01';

GROUP_NUMBER PATH                                         HEADER_STATU MOUNT_S NAME
------------ -------------------------------------------- ------------ ------- ------------------------------
           1 o/192.168.9.9/DATA_Q1_CD_03_edx2cel01         MEMBER       CACHED  DATA_Q1_CD_03_edx2cel01
           2 o/192.168.9.9/DBFS_DG_CD_03_edx2cel01         MEMBER       CACHED  DBFS_DG_CD_03_edx2cel01 
           3 o/192.168.9.9/RECO_Q1_CD_03_edx2cel01         MEMBER       CACHED  RECO_Q1_CD_03_edx2cel01

SQL> select * from gv$asm_operation;

   INST_ID GROUP_NUMBER OPERA STAT      POWER     ACTUAL      SOFAR   EST_WORK   EST_RATE
---------- ------------ ----- ---- ---------- ---------- ---------- ---------- ----------
EST_MINUTES ERROR_CODE
----------- --------------------------------------------
         2            3 REBAL WAIT         10

         1            3 REBAL RUN          10         10       1541       2422
      7298           0

An active rebalance operation can be identified by STATE=RUN. The column group_number and inst_id provide the diskgroup number of the diskgroup been rebalanced and the instance number where the operation is running.  The rebalance operation is complete when the above query returns "no rows selected".

Additionally, the following query will confirm that all failgroups have the same number of disks of the correct status. (MODE_STATUS = ONLINE or MOUNT_STATUS=CACHED) (via SQL> )

SQL> select group_number,failgroup,mode_status,count(*) from v$asm_disk group by group_number,failgroup,mode_status;

The rebalance operation has completed when there are no "group_number" values of 0, and each disk group has count the same number of disks.

If the new griddisks were not automatically added back into the ASM diskgroup configuration, then locate the disks with group_number=0, and add them back in manually using "alter diskgroup <name> add disk <path> rebalance power 10;" command:

SQL> select path,header_status from v$asm_disk where group_number=0;

PATH                                               HEADER_STATU
-------------------------------------------------- ------------
o/192.168.9.9/DBFS_DG_CD_03_edx2cel01        FORMER
o/192.168.9.9/DATA_Q1_CD_03_edx2cel01        FORMER
o/192.168.9.9/RECO_Q1_CD_03_edx2cel01        FORMER

SQL> alter diskgroup dbfs_dg add disk 'o/192.168.9.9/DBFS_DG_CD_03_edx2cel01' rebalance power 10;
SQL> alter diskgroup data_q1 add disk 'o/192.168.9.9/DATA_Q1_CD_03_edx2cel01' rebalance power 10;
SQL> alter diskgroup reco_q1 add disk 'o/192.168.9.9/RECO_Q1_CD_03_edx2cel01' rebalance power 10;

Repeat the prior queries to validate the rebalance has started and there are no longer any disks with "group_number" values of 0.

5. If the disk replaced was a system disk in slot 0 or 1, then the status of the OS volume should also be checked. Login as 'root' on the Storage cell and check the status using the same 'df' and 'mdadm' commands listed above:

[root@dbm1cel1 ~]# mdadm -Q --detail /dev/md5
/dev/md5:
        Version : 0.90
  Creation Time : Thu Mar 17 23:19:42 2011
     Raid Level : raid1
     Array Size : 10482304 (10.00 GiB 10.73 GB)
  Used Dev Size : 10482304 (10.00 GiB 10.73 GB)
   Raid Devices : 2
  Total Devices : 3
Preferred Minor : 5
    Persistence : Superblock is persistent

    Update Time : Wed Jul 18 11:56:36 2012
          State : active, degraded
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

           UUID : e75c1b6a:64cce9e4:924527db:b6e45d21
         Events : 0.215

    Number   Major   Minor   RaidDevice State
       3      65      213        0      spare rebuilding   /dev/sdad5
       1       8       21        1      active sync   /dev/sdb5

       2       8        5        -      faulty spare


[root@dbm1cel1 ~]#

While the system disk is rebuilding, the state will show as "active, degraded" or "active,degraded,recovering" with one indicating it is rebuilding and the 3rd being the 'faulty' disk. After rebuild has started, re-running this command will give a "Rebuild Status: X% complete" line in the output. When the system disk sync status is complete, the state should return to "clean" only with 2 devices.


If the status of any of the above checks (firmware, grid disk / cell disk creation, rebalance) is not successful, re-engage Oracle Support to get the correct action plan to manually complete the required steps.


PARTS NOTE:

Refer to the Exadata Database Machine Owner's Guide Appendix C for part information.

How to identify which Exadata disk FRU part number to order , based on image and vendor and mixed disk support status - Note 1416303.1 and Oracle System Handbook.


REFERENCE INFORMATION:

References

<NOTE:1113013.1> - HALRT-02003: Data hard disk failure
<NOTE:1071220.1> - Oracle Sun Database Machine V2 Diagnosability and Troubleshooting Best Practices
<NOTE:1316829.1> - Mirror partitions not resynched after replacing failed system drive (lun 0 or 1)
<NOTE:1281395.1> - Steps to manually create cell/grid disks on Exadata V2 if auto-create fails during disk replacement
<NOTE:1274324.1> - Oracle Sun Database Machine X2-2/X2-8 Diagnosability and Troubleshooting Best Practices
<NOTE:1112995.1> - HALRT-02004: Data hard disk predictive failure
<NOTE:1386147.1> - How to Replace a Hard Drive in an Exadata Storage Server (Hard Failure)
@<NOTE:1088475.1> - Replacing an Oracle Exadata System disk drive
@<NOTE:1087742.1> - Replacing an Oracle Exadata V2 Data disk drive
@<NOTE:1352938.1> - Replacing a physicaldisk on a storage cell , cellcli list physicaldisk reports two entries on same slot but LUN is not created
@<NOTE:1360343.1> - INTERNAL Exadata Database Machine Hardware Current Product Issues
@<NOTE:1360360.1> - INTERNAL Exadata Database Machine Hardware Troubleshooting

Attachments
This solution has no attachment
  Copyright © 2012 Sun Microsystems, Inc.  All rights reserved.
 Feedback