Re: share a new 11gR2 feature
Date: Mon, 7 Sep 2009 12:31:18 -0500
Message-ID: <ad3aa4c90909071031m2932d4c5p33fd85b324185c4e_at_mail.gmail.com>
This bullet is kind of interesting. I think it says that if you use asm for the ocr, then you can lose the whole cluster if one node (the master node) fails:
If Oracle ASM fails, then OCR is not accessible on the node on which Oracle ASM failed, but the cluster remains operational. The entire cluster only fails if the Oracle ASM instance on the OCR master node fails, if the majority of the OCR locations are in Oracle ASM, and if there is an OCR read or write access, then the crsd stops and the node becomes inoperative.
On Mon, Sep 7, 2009 at 11:21 AM, Robert Freeman <robertgfreeman_at_yahoo.com>wrote:
> 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_at_iinet.net.au>
> Cc: oracle-l_at_freelists.org
> 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_at_iinet.net.au
> --
> http://www.freelists.org/webpage/oracle-l
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' -- http://www.freelists.org/webpage/oracle-lReceived on Mon Sep 07 2009 - 12:31:18 CDT