Re: share a new 11gR2 feature
- From: Robert Freeman <robertgfreeman@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Mon, 7 Sep 2009 09:21:45 -0700 (PDT)
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
Author:
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: http://robertgfreeman.blogspot.com
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! :-)
http://pages.sssnet.com/messndal/church/parachurch.pdf
----- Original Message ----
From: Nuno Souto <dbvision@xxxxxxxxxxxx>
Cc: oracle-l@xxxxxxxxxxxxx
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...
;)
-- Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision@xxxxxxxxxxxx
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
