Re: share a new 11gR2 feature

From: Robert Freeman <>
Date: Mon, 7 Sep 2009 09:21:45 -0700 (PDT)
Message-ID: <>

CPU caging is a nice new feature of 11gR2. Also the OUI now shows you what packages, etc... you are missing. It also, in some cases, will actually provide a script to fix missing install pre-requisites and then allow you to continue the install after fixing them. I'd like to see it actually install the missing RPM's if they are there, but I don't think it does that yet.

Anyone else have issues installing the database with the oc4j stuff? I had several files missing. I ignored them and the single link failure too. Probably missing some RPM that I needed to install. Didn't seem to make a difference with the RDBMS operations though.

 Robert G. Freeman
Oracle ACE
Oracle Database 11g RMAN Backup and Recovery (Oracle Press) - ON IT'S WAY SOON! OCP: Oracle Database 11g Administrator Certified Professional Study Guide (Sybex) Oracle Database 11g New Features (Oracle Press) Portable DBA: Oracle (Oracle Press)
Oracle Database 10g New Features (Oracle Press) Oracle9i RMAN Backup and Recovery (Oracle Press) Oracle9i New Features (Oracle Press)
Other various titles out of print now... Blog: The LDS Church is looking for DBA's. You do have to be a Church member in good standing. A lot of kind people write me, concerned I may be breaking the law by saying you have to be a Church member. It's legal I promise! :-)

  • Original Message ---- From: Nuno Souto <> Cc: Sent: Saturday, September 5, 2009 9:51:44 PM Subject: Re: share a new 11gR2 feature

Matthew Zito wrote,on my timestamp of 6/09/2009 3:24 AM:
> Nuno,
> I think we're conflating the two different points. I was
> commenting only on the ability to tell ASM to put certain
> objects closer to the outside of the disks.
> In almost all of today's arrays, there is a non-relational
> association between the physical disk and the logical devices
> that are presented to the end host. In addition, having large
> amounts of cache and write re-ordering mitigates the performance
> benefits of placing data on the outside of the disk.
> I was just making the point that this is largely inapplicable to
> people who have traditional arrays, and seems to be a feature
> designed to help encourage people that they don't need
> traditional storage arrays.
> I agree that removing the requirement to allocate data for empty
> objects is a good thing.

Sorry, I thought you were commenting on the deferred segment allocation. Hence why it didn't make any sense to me.

Yes, I hear you. I'm fully aware of the impact of write-reordering, cache and such on a SAN disk array. In fact, it is one of the great advantages of the SAN: not having to worry about all that.

My comment was more directed at the EMC support personnel that shows up at our place: they constantly ask why aren't we "spreading the database files" across multiple disk stripes, and claiming that we "need to maximize IOPS". It doesn't even cross their minds to actually EXAMINE the characteristics and setup of out SAN and database before they start talking, all they do is disgorge the manuals upfront.

Had they bothered to even LOOK at our setup, they'd realize we have spread the I/O over 24 disks in 3 RAID10 stripes, we don't give a fig about IOPS as our I/O is mostly sequential high volume: bandwidth is the criteria we shoot for. As EMC's own doco states: tune for IOPS with OLTP, tune for bandwidth with DW and similar workloads.

Guess what we run? A DW. Even though we followed all the recommendations from EMC and have no issues whatsoever with IO capacity, every single time an EMC "expert" visits, we have to suffer the interminable sessions of "have you done this-have you done that". It'd give EMC a much better profile in our organization if their "experts" actually LOOKED first before talking, I can assure you.

But sorry, this is just me venting and has nothing to do with what you said. I do agree that to a large extent, those features of enterprise storage make hardware details not as critical for performance.
That is of course assuming one's SAN administrator doesn't go around rabidly disabling the write cache for all bronze-class disk arrays, but there I go venting again... ;)

Received on Mon Sep 07 2009 - 11:21:45 CDT

Original text of this message