Re: 12c grid control
Date: Tue, 02 Jul 2013 08:35:07 -0600
Message-ID: <51D2E51B.70809_at_gmail.com>
On 02/07/2013 5:24 AM, Nuno Souto wrote:
>
>> I was talking about the 12c Cloud Control monitoring software, not
> > the 12c Database. And I was referring to the 12.1.0.2 Cloud Control
> > software trying to access the 12.1.0.1 Clusterware (including ASM)
> > install.
>
> Yeah, I understood that. For ease of understanding and given that Cloud
> Control is actually mostly called EM12c, let's call it that way here as
> well? Enough with confusion already.
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
My posts have been about EM12cR2 and EM12cR3 (Cloud Control, not Ops Center) against DB12cR1 and Clusterware12cR1.
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.
EM12cR1 (CC) was released 2 years ago. Roughly the same upgrade cycle as DB 11gR1 vs R2. And DB11gR1 didn't support the same OS versions as 11gR2. Similar thoughts here - go to R3 is you want the supported platform.
> > There was NO incompatibility between the OLD Cloud Control (12.1.0.2)
> > and the pre-release 12c Database.
>
> And between EM12.1.0.1 and the said db? You see: the problem is levels
> of compatibility in point releases.
You are correct - it's at the point releases.
But since I needed to go to 12.1.0.2 (EM12cR2) to get certain patches, why would I test against something that was already broken for me? Oracle has a tendency to mostly move forward with releases, not backward.
> Oracle advertises EM12c as "working with all Oracle dbs", they don't
> make any specific recommendations about specific levels of releases.
> But we all know it's not like that, as the following demonstrates:
Yup. And DB 11g works on all sorts of operating systems. It's not
until you read the docs that you discover that the family/brand does not
cover all variations and you NEED to get to the point releases.
> ... And that proves that EM12c and DB12c are
> completely compatible, exactly how? Note: EM12c has been out for 2 years
> now - about time it was compatible with everything?
Marketing has done their job well. They have you interchanging the
brand name for the product - I've been trapped by that so often that I
try to be more precise. For example, distinguishing between EM12c Cloud
Control and EM12c Ops Center at the least.
> But it is *my choice* to not waste my time finding those incompatibilities.
> First, because I firmly believe they are transient incidents.
> Second, because it is a waste of time for me to familiarize with a
> product that is still changing - I prefer to learn with a final,
> relatively stable release combo.
> And I believe - based on past experience since the 90s - that will be
> the case 2 years from now.
On that we agree. Generically, if your job is about maintaining
stability, then delay until stability can be proven. 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.
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.
> One would think that this is obvious. But it appears to be the norm in
> some quarters to on every new release of whatever, engage in the usual
> "disparage the non-immediate-upgrader", or the "non-beta-tester".
>
Works both ways - the norm in some other quarters is to disparage the
early adopter.
As usual, no middle ground?
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Jul 02 2013 - 16:35:07 CEST