Monthly Archives: March 2012

Yum Repository for Oracle Enterprise Linux

One of the new requirements of the Exadata Storage Server patches (starting with 11.2.3.1.0) is that the compute nodes will be patched through yum.  Previously, the minimal pack was bundled with the storage server patch and applied directly to the database servers.  Instead of having the compute node directly receive updates from Oracle’s yum repository (the Unbreakable Linux Network – ULN), it is recommended to configure a local yum repository that will download the RPMs from ULN.  After this is done, all local servers will connect to the yum repository to receive RPM patches, saving time and network bandwidth.  This post will describe how to configure the yum repository on Oracle Enterprise Linux (process borrowed from OTN).

Creating a yum repository does not require any additional license other than a ULN subscription (included with Exadata or any OEL support contract) unlike RedHat’s Satellite product, which can be quite pricey.  First, you will need a server running Oracle Enterprise Linux.  If you don’t have anything running OEL, check out Tim Hall’s great site – oracle-base.com for a quick primer on installing OEL.  After you have a server up and running with OEL, you’ll need to register it with the ULN.  This requires a CSI – included with an OEL license.  To do this, run:

rpm --import /usr/share/rhn/RPM-GPG-KEY
up2date --nox --register

 
Continue reading

Exadata V2 Battery Replacement

For some reason, I’ve been working on lots of Exadata V2 systems in the past few months.  One of the issues that I’ve been coming across for these clients is a failure in the battery that is used by the RAID controller.  It was originally expected for these batteries to last 2 years.  Unfortunately, there is a defect in the batteries where they reach their end of life after approximately 18 months.  The local Sun reps should have access to a schedule that says when the “regular maintenance” should occur.  For one client, it wasn’t caught until the batteries had run down completely and the disks were in WriteThrough mode.  This can be seen by running MegaCLI64.  Here is the output to check the WriteBack/WriteThrough status for 2 different compute nodes (V2 is first, X2-2 is second):

[enkdb01:root] /root
> dmidecode -s system-product-name
SUN FIRE X4170 SERVER          
 
[enkdb01:root] /root
> /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -LALL -aALL | grep "Cache Policy"
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Disk Cache Policy   : Disabled
[root@enkdb03 ~]# dmidecode -s system-product-name
SUN FIRE X4170 M2 SERVER
[root@enkdb03 ~]# /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -LALL -aALL | grep "Cache Policy"
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Disk Cache Policy   : Disabled

If you have a V2 and you haven’t replaced the batteries yet, it’s worth running these commands to see what state your RAID controllers are in.  To find out what this means for you, read on after the break.

Continue reading