Re: 12c grid control
Date: Tue, 2 Jul 2013 20:02:20 +0100
Message-ID: <CABe10sZSM_dwKes5fJ42ZRNNYD+sQEdgWLBBLNJD=VXGNHqaOw_at_mail.gmail.com>
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
On Mon, Jul 1, 2013 at 12:13 PM, Nuno Souto <dbvision_at_iinet.net.au> wrote:
> On 1/07/2013 8:39 AM, Tim Hall wrote:
> > RE: EM12c Have to agree with Kellyn here.
> > people, once you try Cloud Control, you won't go back to other tools
> > (except SQL*PLus). It's definitely a production-ready solution,
> > backed by an 11g DB repository!
>
> Oh, I like EM12c. Still have to see it run reliably and durably in our
> setup but that might indeed be due to the multiple installs it's been a
> "victim" of, including some by Oracle support "experts" - who managed to
> break it to the point I am considering a complete wipeclean-reinstall...
> But that is not the fault of EM12c!
I think one of the problems here is that EM12c (and indeed 11g are proper grown up Java Enterprise Applications. This means that a decent amount of understanding of J2EE architecture and capability is 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. 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.
>
>
> > Services, which is still shipped with an 11.1.0.7 client. :) In the
> > same way, it's going to take a while for EM12c to be fixed up to use
> > 12cR1 database as the repository home.
>
> Fair enough. In fact, I hope it won't include db12c for a long while!
> Last thing I need is an unstable db under a monitoring product!
I'd expect db12c to be *certified* reasonably quickly, but *required* fairly slowly. It seems to me in fact that since the db install is one you are supposed to be able to do yourself any currently supported database ought to be supported for the repository (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).
> > RE: DB 12cR1 I certainly wouldn't be trusting any production
> > databases or my OMS repository to DB 12cR1 any time soon. My Cloud
> > Control installation is a production system. If that fails I have no
> > backups!
>
> That is one of the areas I am not happy with EM12c: exactly how to make
> it a HA system?
> Not easy, from what I've seen so far. At least not without some extreme
> complexity added on. Of course, good old "tar cvf" works and will
> always work. But I thought in this day and age something more
> sophisticated could be knocked together, without needing a full-on RAC
> install or an extensive DG setup!
As it happens we already have a RAC and DG setup for internal apps on Oracle. That's where the repo belongs for us. We understand all that and it doesn't cost us incrementally (which RAC or DG do if EM is the only db on those servers) . 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).
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.
>
> > every feature. Not every database is mission critical. Some systems
> > will work quite happily on the buggiest piece of crap. We have some
> > systems I would gladly run on 12cR1, safe in the knowledge it would
> > take 20 minutes to switch back to 11gR2. Yes, they are that small! :)
>
>
> Bingo. 100% agreed. That is indeed how db12c will start with us.
So what I'm working towards where we are is a list of supported versions (i.e stuff we're prepared to take on) Right now that list if it existed would only contain 11.2, sometime in 2014 12.1 would appear. To get to appear it would have to pass through a series of hoops, one of which is that described above. Frankly I think there are only 2 sane strategies for version support :- *mandate* the latest possible version you've properly kicked or run the earliest terminal release Oracle will give you effective support for. Running intermediate stuff will only put you in "request a backport/upgrade to/cannot reproduce" hell with support. As Nuno says running absolute current is as Sir Humphrey used to say "a courageous decision 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 simply took all the info I could out of the Database Upgrade team at
> Oracle, run by Mark Dietrich and under the management of a guy whose
> name now escapes me.
> Those guys deserve all the credit I can possibly heap on them! I really
> hope Mike does an encore for 12c:
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.
> --
> Cheers
> Nuno Souto
> dbvision_at_iinet.net.au
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
-- Niall Litchfield Oracle DBA http://www.orawin.infol On 1/07/2013 8:39 AM, Tim Hall wrote:Received on Tue Jul 02 2013 - 21:02:20 CEST
> RE: EM12c Have to agree with Kellyn here.
> people, once you try Cloud Control, you won't go back to other tools
> (except SQL*PLus). It's definitely a production-ready solution, > backed by an 11g DB repository! Oh, I like EM12c. Still have to see it run reliably and durably in our setup but that might indeed be due to the multiple installs it's been a "victim" of, including some by Oracle support "experts" - who managed to break it to the point I am considering a complete wipeclean-reinstall... But that is not the fault of EM12c!
> Services, which is still shipped with an 11.1.0.7 client. :) In the
> same way, it's going to take a while for EM12c to be fixed up to use > 12cR1 database as the repository home. Fair enough. In fact, I hope it won't include db12c for a long while! Last thing I need is an unstable db under a monitoring product!
> RE: DB 12cR1 I certainly wouldn't be trusting any production
> databases or my OMS repository to DB 12cR1 any time soon. My Cloud > Control installation is a production system. If that fails I have no > backups! That is one of the areas I am not happy with EM12c: exactly how to make it a HA system? Not easy, from what I've seen so far. At least not without some extreme complexity added on. Of course, good old "tar cvf" works and will always work. But I thought in this day and age something more sophisticated could be knocked together, without needing a full-on RAC install or an extensive DG setup!
> every feature. Not every database is mission critical. Some systems
> will work quite happily on the buggiest piece of crap. We have some > systems I would gladly run on 12cR1, safe in the knowledge it would > take 20 minutes to switch back to 11gR2. Yes, they are that small! :) Bingo. 100% agreed. That is indeed how db12c will start with us. > If I wait until 12cR2 before I start > learning this stuff I'm going to be in real trouble when someone asks > me in 18 months to do a 11gR2 > 12cR2 upgrade. Companies have to get > involved now, or the will get in real trouble when the time comes to > try it out. Disagree. I managed quite well with staying away from 11g until 11.2.0.3. And last year I upgraded 12 prod instances from 10.2.0.3 to 11.2.0.3 without any major problem and with tremendous improvements in performance. Mind you: rather than trying to re-invent the wheel, I simply took all the info I could out of the Database Upgrade team at Oracle, run by Mark Dietrich and under the management of a guy whose name now escapes me. Those guys deserve all the credit I can possibly heap on them! I really hope Mike does an encore for 12c: it's the only way I might consider installing it before 2015. Oh, and I used the good info in your site a LOT. There are quite a few sites out there with all sorts of over-the-top technical stuff but yours seems to come up tops when weird stuff happens to day-to-day setups - and that http security in 11gr2 is a RPITA, let me tell you!... :-( Mind you: I don't for a pico-second subscribe to the silly marketing notion that somehow when a new release shows up, everyone who is still not using it has suddenly become completely IT ignorant and needs to be "re-educated". I do distinguish between IT education and IT training: the two are NOT the same, by any stretch of the imagination.
> I wrote this a while ago:
> > http://www.oracle-base.com/blog/2013/03/03/how-can-we-make-oracle-database-12cr2-the-best-release-ever/ Yeah, I read it. I don't have the slightest inclination to get involved in beta programs. Mostly because "being first" with new release training is totally irrelevant to me and my work - and has been for the last 13 years! If I was still in the consulting world, yes indeed: that might be important. But I've left those waters a long time ago. As for the sales folks: rest assured they hate me now as much as they used to! :-) -- Cheers Nuno Souto dbvision_at_iinet.net.au -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l