RE: 12c grid control
Date: Wed, 3 Jul 2013 09:51:30 -0700 (PDT)
Message-ID: <dff31bb3-ffbd-408e-8f1f-130cd8df6dd9_at_default>
Point of clarification on Nuno's point re ruling out SE for the repository: the repository must be an EE version DB because of its use of EE features. However, the licensing doc makes it clear that you have a restricted use of EE for the repository - provided you are not using that EE features of that database for your own applications you are not charged for the use of EE.
Pete
Pete Sharman
Principal Product Manager
Enterprise Manager Product Suite
33 Benson Crescent CALWELL ACT 2905 AUSTRALIA
Phone: +61262924095 | | Fax: +61262925183 | | Mobile: +61414443449
"Controlling developers is like herding cats." Kevin Loney, Oracle DBA Handbook
"Oh no, it's not, it's much harder than that!" Bruce Pihlamae, long term Oracle DBA
-----Original Message-----
From: Nuno Souto [mailto:dbvision_at_iinet.net.au]
Sent: Wednesday, July 3, 2013 8:25 PM
To: oracle-l_at_freelists.org
Subject: Re: 12c grid control
On 3/07/2013 5:02 AM, Niall Litchfield wrote:
> Wow I decide to leave off a thread for a day or so to investigate
> some new stuff and look what happens! Anyway here goes
Time flies, Niall! :-)
> required. An *awful* lot of EM installs get given to the DBA group
> (or installed by them at their request) and an awful lot of those DBA > teams aren't great J2EE application admins - I include myself in this > category.
Tell me about it! I hate it that Glassfish is needed now with the Apex Java listener: it's been an endless source of annoyance for us...
> In addition because its an Oracle product it uses, quite
> intelligently, a fair number of database features - particularly AQ > and partitioning. Again these aren't universally well understood > features.
Wow! That rules out SE for its db: no partitioning! Then again, the std db maintenance tasks nowadays do archival by dropping partitions, and they work fine in SE: I wonder if there isn't some partitioning going on there, under the covers...
> (and that would have the side effect of requiring Oracle's in house
> development team to think carefully about feature availability and > stability as well as the product support lifecycle).
Yes, indeed: very good point! Thanks for mentioning it!
> that and it doesn't cost us incrementally (which RAC or DG do if EM
> is the only db on those servers) .
Bingo! Not only that, but for example in our case it'd mean a complete upgrade of our carrier-pigeon-class network fabric. And that costs mucho diņero!...
> If I was doing this on a new setup
> I'd strongly consider an industrial strength active/passive setup for > the database tier ( & in passing one that the vendor believed in - > the speed with which Oracle Restart has been deprecated must be a > record).
I've been quite happy with EMC's SRDF synchronous replication. For reasonably low IO intensive dbs, it's a very good option for those with Symmetrix SANs. Wouldn't use it for our DW where we do 8TB/day of I/O, of course! But for anything up to around 100GB/day, not a worry - it works like a charm and is very, very solid and resilient.
> For the OMS the strategies *I* think makes sense are 1) to have n+m
> vms where n is how many you need and m is your desired redundancy > level. ( In our case as many n=m=1) 2) to use vms and vm HA features > such as vMotion or LiveMigration.
Noted. Thanks heaps for the tip.
> Minister". Not properly kicking stuff to see how your workload
> performs is equally daft. Oracle's business case for testing doesn't > extend beyond "make sure the marketing functionality works as > described" (nb marketing functionality means stuff shown in demos > works in practice, NOT functionality marketed wil *always* work) and > that their support organisation has reduced rather than increased > operating costs. The benefit for making sure it works for you accrues > to you not them. So sadly do the costs. The benefit of it working in > the general case accrues to them and not you.
I must also note here that of late I've been having quite a good run with Support. Most of the little nagging problems we had during the upgrade to DB11.2.0.3 were resolved in less than one day by them. Very impressive, given my past experience with the service!
And there can be a few issues, particularly when the SYSTEM tablespace has over the years been upgraded from 7.3.2 to 8.1.7, then to 10.2.0.2, then to 10.2.0.3, and finally to 11.2.0.3! At one stage I had to completely wipe and reload XMLDB as it got completely broken! Not an easy and immediately obvious task unless the right script and process is available.
In fact, I believe it was Julian Dontcheff who pointed out a while ago that one needs to bite the bullet from time to time and completely re-init the SYSTEM tablespace rather than keep upgrading it ad-infinitum! Completely in agreement with that. I expect more so for DB12c than for anything before, with the container dictionary layers!
It will be my task for next fin year with the db that started out as 7.3 and is now in 11.2.0.3! The others are a lot more recent but that one? Man, it scares me!
> Already exists as I understand it. Like the 11g stuff though I expect
> it to be better in 9 months than it is now. That stuff is up there
> with the known issues and bugs fixed in docs on metalink for
> usefulness.
Indeed. Just found it, thanks. Gonna do some serious reading ASAP.
-- Cheers Nuno Souto dbvision_at_iinet.net.au -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Wed Jul 03 2013 - 18:51:30 CEST