Re: 12c grid control
- From: Nuno Souto <dbvision@xxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 03 Jul 2013 20:25:13 +1000
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@xxxxxxxxxxxx
--
//www.freelists.org/webpage/oracle-l
Other related posts:
