Re: Restricted Use - License - OEM 12c
Date: Thu, 18 Feb 2016 11:45:52 -0700
Message-ID: <CAN6wuX03OM7o7-ArZfMX_c0hjU-mXfBcQ5Tg3cidcoeaFJLR5g_at_mail.gmail.com>
And Niall, yes, Pete just said you were "special"... :)
~Kellyn
[image: Kellyn Pot'Vin on about.me]
Kellyn Pot'Vin-Gorman
about.me/dbakevlar
<http://about.me/dbakevlar>
On Thu, Feb 18, 2016 at 11:40 AM, Peter Sharman <pete.sharman_at_oracle.com> wrote:
> The reasons not to have user data in the OMR may not apply to your
> specific use case Niall, but then again it could be argued that what you’re
> doing is not real user data as it sounds like it’s really a copy of the
> MGMT tables in another format. Actually, it probably would have been
> better to say not to put APPLICATION data in the same database as the OMR,
> rather than user data, to clarify this particular situation.
>
>
>
> What it basically boils down to is different use cases for accessing the
> data. Let me give some examples:
>
>
>
> · Different backup needs: At its absolute worst, I’ve seen users
> create their own data in the SYSMAN schema, in the same tablespaces as the
> SYSMAN schema. If the need to back up their user data differs from that of
> the normal OMR data, how do you backup their user data on a separate
> schedule for example. Yes, you could argue that only a fool would create
> their own tables that way, but I could personally introduce you to such
> fools – they do exist. L
>
> · Different recovery needs: If you have non-OMR data in the OMR
> database, both the non-OMR data and the OMR data has to be recovered to the
> same point in time if you need to perform a point-in-time recovery for some
> reason. Yes it can be done if the two datasets exist in different
> databases, but I would warrant that most DBA’s are less familiar with
> tablespace point-in-time recovery than database point in time recovery, so
> they are probably more likely to do the latter if they’re under pressure to
> perform the recovery ASAP.
>
> · Different availability needs: A similar but slightly different
> issue to the last one. One dataset may have high availability needs that
> the other dataset does not. Depending on the type of availability
> solution, this can again be easier to set up if they are in different
> databases.
>
> · Different performance needs: If you have both datasets in a
> single database, then you can’t tune for the performance of one separate to
> the other. That’s much easier if they are in different databases.
>
>
>
> And so on. You can see the thrust of what I’m saying. The issues are
> exactly the reasons you would look at not consolidating one database with
> another. While it can save you real estate, and possibly licensing fees,
> consolidation is not always the best approach to take. While many of the
> issues CAN be overcome, it’s just easier if the two datasets are separated.
>
>
>
> On a final note, I’ll raise your comment on the
> CONTROL_MANAGEMENT_PACK_ACCESS with the person who builds the templates.
>
>
>
> Pete
>
> [image: Oracle logo]
>
> Pete Sharman
> Database Architect, DBaaS / DBLM
> Enterprise Manager Product Suite
> 33 Benson Crescent CALWELL ACT 2905 AUSTRALIA
>
> Phone: +61262924095 | | Mobile: *+61414443449 <%2B61414443449>*
> Email: pete.sharman_at_oracle.com Twitter: _at_SharmanPete LinkedIn:
> au.linkedin.com/in/petesharman
> Website: petewhodidnottweet.com
> ------------------------------
>
> "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
> ------------------------------
>
>
>
> *From:* Niall Litchfield [mailto:niall.litchfield_at_gmail.com]
> *Sent:* Friday, February 19, 2016 3:09 AM
> *To:* Pete Sharman <pete.sharman_at_oracle.com>
> *Cc:* Kellyn Pot'Vin-Gorman <dbakevlar_at_gmail.com>; Chirag Shah <
> csshah85_at_gmail.com>; Hans Forbrich <fuzzy.graybeard_at_gmail.com>; Oracle L <
> oracle-l_at_freelists.org>
>
> *Subject:* Re: Restricted Use - License - OEM 12c
>
>
>
> A couple of comments.
>
>
>
> On Wed, Feb 17, 2016 at 9:32 PM, Peter Sharman <pete.sharman_at_oracle.com>
> wrote:
>
> A few points to add on this topic:
>
>
>
> · The most important point is who uses specific functionality
> (not just the management packs but more broadly than that). The example I
> keep using - and Kellyn is probably is probably sick of hearing from me! J
> - is Partitioning. We (as in Oracle Corporation) use Partitioning
> internally in the OMR. You do NOT need to buy a license for Partitioning
> for that, as it’s something we use. If, however, you want to create your
> own user tables in the OMR database (which is a dumb idea, for numerous
> reasons) and then you try to partition those user tables, Oracle
> Corporation requires you to buy a Partitioning license for that use.
>
>
>
> I'd be interested to hear those "numerous reasons". The OEM repository is
> a great source of information about *my* estate that I'd like to leverage
> for various purposes - mostly reporting - but other use cases as well. The
> database that we run that hosts an EM with nearly 3000 targets (targets
> don't half multiply :) ) consistently runs a load of under 1 AAS (kudos to
> the developers). Now I can create a companion database for the purposes of
> dumping data from the OEM repository, but that does seem rather daft when I
> would naturally just create my own schema and/or Apex app. I recognise
> doing so has license implications (but we host our repo on a licensed
> cluster anyway since we want DR and HA already), so as I say I'd love to
> know why extending OEM in this way is a bad idea.
>
>
>
> · Please, please, PLEASE do not relink the OMR kernel to remove
> functionality that you think you’re not licensed for. I had a client do
> that on me once, and it left an unholy mess to try and recover. There were
> additional issues in this case that I won’t cover here, but buy me a beer
> at a conference when you see me and I’ll tell you all the gory details
> while protecting the customer’s otherwise good name! J
>
>
>
> Indeed
>
> · The simplest way of thinking of the licensing side for the OMR
> is this. Any management pack functionality that is licensed with a
> particular pack for a non-repository database needs to be licensed for the
> repository database. Let me give you an example. Notifications for issues
> with a target database require the Diagnostics pack. Likewise, if you want
> to receive notifications for issues with the OMR, you need to buy a
> Diagnostics pack license for that use with the OMR. As always, the
> licensing guide is the single source of truth on this, even if it’s not
> particularly clear at times! J Licensing guide for EM13c is located here
> <http://docs.oracle.com/cd/E63000_01/OEMLI/toc.htm>, and for EM12c is
> located here <http://docs.oracle.com/cd/E24628_01/doc.121/e24474/toc.htm>.
>
>
>
> It would be nice then if the OEM Database Templates actually made the init
> parameter change HANS describes, especially as an oem administrators
> database account doesn't have sufficient privileges to view the performance
> pages in OEM for the OEM database target anyway :).
>
>
>
> · And just a quick point of determining what packs are needed for
> what page in EM, you can find my blog post on this tangentially related
> topic here
> <http://petewhodidnottweet.com/2016/01/determining-what-management-packs-are-needed/>
> .
>
>
>
> As always, Kellyn, Hans and I are here to help with EM related questions
> so reach out to us if you need. OK, Hans knows a lot more than just EM,
> but he’ll still provide input on EM specific issues, no doubt! J
>
>
>
> Pete
>
> [image: Oracle logo]
>
> Pete Sharman
> Database Architect, DBaaS / DBLM
> Enterprise Manager Product Suite
> 33 Benson Crescent CALWELL ACT 2905 AUSTRALIA
>
> Phone: +61262924095 | | Mobile: +61414443449
> Email: pete.sharman_at_oracle.com Twitter: _at_SharmanPete LinkedIn:
> au.linkedin.com/in/petesharman
> Website: petewhodidnottweet.com
> ------------------------------
>
> "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
> ------------------------------
>
>
>
> *From:* Kellyn Pot'Vin-Gorman [mailto:dbakevlar_at_gmail.com]
> *Sent:* Thursday, February 18, 2016 6:01 AM
> *To:* Chirag Shah <csshah85_at_gmail.com>
> *Cc:* Hans Forbrich <fuzzy.graybeard_at_gmail.com>; Oracle L <
> oracle-l_at_freelists.org>
> *Subject:* Re: Restricted Use - License - OEM 12c
>
>
>
> I also wrote out a blog post on it, as Hans is correct, we need to have it
> out there... :)
>
>
> http://dbakevlar.com/2016/02/management-packs-restricted-use-licenses-and-the-enterprise-manager/
>
>
>
> Thank you for posting this question!
>
> Kellyn
>
>
>
>
> [image: Kellyn Pot'Vin on about.me]
>
>
>
> *Kellyn Pot'Vin-Gorman*
>
> about.me/dbakevlar
>
>
>
>
>
> On Wed, Feb 17, 2016 at 11:36 AM, Chirag Shah <csshah85_at_gmail.com> wrote:
>
> Hi Kellyn
>
>
>
> Thanks a lot for confirmation..
>
>
>
> _at_Hans : Thanks for details.. Yes we will do the same and also unchecked
> the pack option from OEM "setup >> Management packs' screen for OMR DB..
>
> Or might be we think to reconstruct the OMR/OEM again to make sure from
> any further potential hassle in future..
>
>
>
> Thanks & Regards,
>
> CS
>
>
>
>
>
> On Wed, Feb 17, 2016 at 7:20 PM, Hans Forbrich <fuzzy.graybeard_at_gmail.com>
> wrote:
>
> Further to that, to disable the pack you need to run "ALTER SYSTEM set
> control_management_pack_access='NONE' scope=BOTH;" in that repository.
> (Same for any other Oracle Database in which you wish to disable the packs.)
>
> Other packs are disabled using the OEM "setup >> Management Packs" screen
> (or similar - that is for 12.1.0.5)
>
> /Hans
>
> On 17/02/2016 11:04 AM, Kellyn Pot'Vin-Gorman wrote:
>
> Hi CS,set
>
> No, unfortunately, that "Restricted Use License" on the OMR doesn't cover
> AWR or any of the other diag and tuning pack features.
>
>
>
> Thank you,
>
> Kellyn Pot'Vin-Gorman
>
> Consulting Member of Technical Staff for Enterprise Manager, SCP
>
>
>
>
> [image: Kellyn Pot'Vin on about.me]
>
>
>
> *Kellyn Pot'Vin-Gorman*
>
> about.me/dbakevlar
>
>
>
>
>
> On Wed, Feb 17, 2016 at 10:54 AM, Chirag Shah <csshah85_at_gmail.com> wrote:
>
> Hello List,
>
>
>
> I just found that our OMR (Oracle Management Repository) database - for
> OEM 12c (12.1.0.4) has "Diagnostic + Tuning" Pack enable..
> control_management_pack_access = DIAGNOSTIC+TUNING
>
>
>
> We don't aware when it was done, might be when creation/installation of
> OEM 12c. I'm aware about Enterprise Manager Restricted Use license, but
> does DIAGNOSTIC+TUNING include within this "Restricted Use License" ? Can
> we use DIAGNOSTIC+TUNING features for own OEM repository DB ?
>
>
>
> And If No, the how can we rid out of it ?
>
>
>
> Thanks a lot in advance...
>
>
>
> Thanks & Regards,
>
> CS
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Feb 18 2016 - 19:45:52 CET