RE: 12c grid control

On the version numbering thingy, that's totally out of my control I'm afraid. It does make life a little complex for Support now, I guess (if it wasn't before!), particularly with the plugin architecture. Since plugins can now be rev'ed outside of the release cycle (and that is a huge plus for getting support of different products out much faster, so that's a Good Thing (TM) as far as I'm concerned), you can now have plugin versions that are different to the main product version - witness the other thread where we were discussing the fact that EM12.1.0.3 comes with DB plugin 12.1.0.4. What it does mean is you guys / gals out there in customer land will need to be very clear on what versions are running. As an example, you may run into a problem with a plugin version 12.1.0.x that is fixed in 12.1.0.x+1 of the plugin, even while the base product is still on 12.1.0.3.

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 7:51 PM
To: oracle-l_at_freelists.org
Subject: Re: 12c grid control

On 3/07/2013 12:35 AM, Hans Forbrich wrote:

> So you are saying that Oracle Database 11g is enough for an
 > identifier? Since DB 11gR2 was released, I strongly encouraged people > to identify at least R1 vs R2, in a similar manner to Oracle 7.2 was > a different animal than 7.3

No. I'm saying that *in the context* of 12, I'd call the grid control product EM12 and the database product DB12. Nothing more, nothing less.

> Sadly, Oracle has elected to use the 3rd decimal (12.?.?.x) to depict
 > the EM Release, which seems to be a constant source of confusion for > DBAs in my classes and at my customers.

Are they really that different that they deserve to be called "releases"? Rather than patch levels? Yikes, that is indeed a mixed up naming convention! Pete, you still listening in? Can anyting be done to reduce that?

> On that we agree. Generically, if your job is about maintaining
 > stability, then delay until stability can be proven.

Not so much proven stability - that is mostly impossible to do nowadays - as being sufficiently resilient that it won't fall apart if someone sneezes. Believe me - I've had enough of sites inclined to catch colds at the drop of a hat!

> Then again, I

 > still have customers who ask why they can't run Oracle 7 on their > Windows 7 Windows Server 2008 R2 or higher machines.

Ah yes, the Windows rigmarole... Been there, moved everything db to Unix. Couldn't make it Linux because the place I work for has an infrastructure manager allergic to it in all its forms - and I can't override him...

> On the other hand, if your job is about supporting developers, and
 > cost management by exploiting new features, then you might need to > look for, and understand, the incompatibilities.

Absolutely! I used to do that. Not anymore in this day and age of plug-in applications and/or SaaS, but of course: it's still done in many places.

> Works both ways - the norm in some other quarters is to disparage the
 > early adopter.
> As usual, no middle ground? --

Only if early adopters insinuate or imply anyone not in the same boat is "past it" and "won't last" or "will lose their job" or "needs to brush up the resume". Indeed, a middle ground is needed. It would help if we all accepted that "one size fits all" is not an option in IT.
Never was, never will be.

(yes, I am aware "never" is an awful long time!)

-- 
Cheers
Nuno Souto
dbvision_at_iinet.net.au



--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l