Wednesday Aug 15, 2012

SPARC SuperDuperCluster

Hi Folks!

Some of you may have noticed that I've been a little quieter than usual in the last year.

Is it because I've lost interest in patching, maintenance best practices, and improving our customers' lifecycle experience ?  Not a bit of it.

It's because my team and I have been rather busy - to put it mildly! - on developing the installation configuration utilities and maintenance updates for SPARC SuperCluster.

SPARC SuperCluster is so good, and the feedback from the already substantial customer base has been so positive, that I'm lobbying Marketing to rename it SPARC SuperDuperCluster.

Available in half rack (2 T4-4s, 3 Exadata Storage Cells) or full rack (4 T4-4s, 7 Exadata Storage Cells) configurations, both of which have a general purpose 7320 ZFSSA (ZFS Storage Appliance) and 3 Infiniband Switches, SPARC SuperDuperCluster is the prime example of the integrated Oracle Red Stack at its best.

It is a true example of an Engineered System, engineered with enhancements at every layer of the Red Stack to improve performance, robustness, and quality, from the phenomenal performance of the SPARC T4 chips, through to the excellent LDoms (Logical Domains) virtualization layer, enhancements such as RDSv3 support in Solaris as well as all the other great feature of Solaris 11 (and 10), to leveraging the phenomenal performance of Infiniband, Exadata Storage Cells and the 11gR2 database.

Seemingly paradoxically, SPARC SuperDuperCluster is both a highly flexible General Purpose "app" consolidation platform and an Engineered System, offering a wide variety of optimized configurations with various combinations of 11gR2 database domains, Solaris 11 General Purpose "app" domains, and Solaris 10 General Purpose "app" domains.

But how can SPARC SuperDuperCluster be both an Engineered System and offer extremely flexible configurations at the same time ?  That's easy.  The hardware layer and cabling is fixed in an optimized fashion (Engineered).  But what apps a customer chooses to run on SuperCluster, on how many LDoms and what memory/CPU is allocated to each is up to them, optimized for their needs (Flexible), rather than a one-size-fits-none approach.

SPARC SuperDuperCluster is more than just the hardware and software.  It's also the extraordinary cross-organizational team that has been built around it.  From the absolute cream of Services, Support, and Sustaining, to the architects and management from Performance Technologies, to the cooperation and deep engagement between engineering teams for each layer of the Oracle Red Stack, to my own small but extremely dedicated install configuration utility and maintenance update team, it's the people behind SPARC SuperDuperCluster which ensure its success. 

Feedback from the rapidly growing customer install base worldwide is extremely positive.  To find out more, please see the SPARC SuperCluster resource page.  You'll be hearing lots more about SPARC SuperDuperCluster at Oracle Open World this year - wow, it's nearly that time of year again! - but, for once, I won't be presenting myself.

I will be there and available to meet/talk either about Solaris 10 Patching, Solaris 11 SRUs (Support Repository Updates), or SPARC SuperDuperCluster.  I look forward to seeing you there!

Best Wishes,


Wednesday Jan 21, 2009

Freeing up space in /var

The following is now published as Infodoc 208057:

To whom it may concern,

Over time, customers may experience space issues in /var as patch "undo" and "obsolete" data, which is stored for use during patch backout, builds up as more patches are applied to the system.

It is best to plan for this expansion of /var in advance,  and allocate plenty of free space to this partition. 

How much space to allocate to /var depends on a number of variables, such as how many patches are likely to be applied to the system, which is dependent on frequency of patching, strategy of which patches will be applied (all, sun alert, security only, etc.), products patched; whether the system has zones which implies 'pspool' space requirements, etc.  A figure of 10Gb to 20Gb or even more is not unreasonable.   In my Patch System Test lab, we currently have Solaris 10 systems with >7GB used in /var and this will continue to grow over the lifetime of Solaris 10.

If you have insufficient space in /var of an existing system, the recommended solution is to extend the size of the /var partition.  This can be accomplished by backing up /var, creating a bigger /var partition on another disk, restoring the /var backup onto that partition and then updating the /var entry in the /etc/vfstab file.  If /var is part of the "/" (root) partition, then relocating /var to a separate partition would be a good solution.  The relocation process is documented in Infodoc 215988.

Sun strongly discourages manual modifications to the /var/sadm/pkg directory and its file structure.  That directory structure should only be modified by the Solaris[TM] patching and packaging utilities.  Corruption in this directory structure will prevent any future packaging or patching operations.

Below is information on how to free up space in /var by deleting certain patch related files.  This should only be used when there are no other ways of gaining space in /var.

Having a full and current backup of the OS is highly recommended before deleting files from /var.

On behalf of Sun Microsystems, I hereby confirm that unneeded "obsolete" and "undo" files may be removed from the /var/sadm/pkg/<pkgname>/save/<PatchID> and "undo" files from the /var/sadm/pkg/<pkgname>/save/pspool/<pkgname>/save/<PatchID> directories in order to free up space in /var.

This will not invalidate support contracts.

The "undo" files are used during the patch removal process. Removing the "undo" files associated with a patch means that it will no longer be possible to uninstall the patch.

Once a later revision of a patch is applied, or a patch which obsoletes a patch is applied, the "undo" files in /var/sadm/pkg/<pkgname>/save/<PatchID> are renamed "obsolete".  These "obsolete" files may also be removed.

It is strongly recommended to only remove the "obsolete" and "undo" files for patches which the customer is confident will not need to be backed out - for example rejuvenated Kernel patches associated with Solaris 10 Update releases such as 118833-36 (SPARC) / 118855-36 (x86), 120011-14 (SPARC) / 120012-14 (x86), etc. and other older Kernel patch revisions.  See the sequence of Solaris 10 Kernel PatchIDs listed on

As patches containing subsequent fixes to the objects contained in these rejuvenated patches will have a SUNW_REQUIRES dependency on the these rejuvenated patches, it's extremely unlikely that older versions of these rejuventated Kernel patches will ever be backed out.   Therefore, their "undo" files are prime candidates for removal to free up space in /var if required and it's not possible to extend /var.

All the "undo" or "obsolete" files for a particular patch should be removed from the /var/sadm/pkg/<pkgname>/save/<PatchID> directories. For example:

rm /var/sadm/pkg/\*/save/118833-36/undo\*

The system also keeps a copy of "undo" files for use during creation of new non-global zones. These may also be removed if the customer is confident that the patches will not need to be backed out. For example:

rm /var/sadm/pkg/\*/save/pspool/\*/save/118833-36/undo\*

The "undo" files in the pspool directory are not renamed to "obsolete" when a later revision is installed.

Further Information:

  1. The "undo" files are specific to the zone of the system on which they were created during application of a patch by patchadd. Therefore, do not copy the "undo" file from one zone to another or from one system to another.

  2. One could potentially archive the "undo" files for each zone of a system and restore it to that zone if desired.

Best Wishes,

Gerry Haskins
Director, Software Patch Services


This blog is to inform customers about patching best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. ~~~~~~~~~~~~ Gerry Haskins, Director, Software Lifecycle Engineer


« April 2014