How and why you should set target lifecycle status properties in EM12c

If, like me, you’re using EM12c after you were already plenty familiar with EM11g, you may have missed an important detail in the EM12c new features guide.

From New Features in Oracle Enterprise Manager Cloud Control 12c

Each target now has a lifecycle status target property which can be set to one of the following values: mission critical, production, staging, test, or development. This target property is used to specify the priority by which data from the target should be handled. When Enterprise Manager is under a heavy load, targets where the value of the lifecycle property is mission critical or production are treated with higher priority than targets where the value of the lifecycle property is staging, test, or development. Setting the priorities of your most important targets ensures that even as your data center grows and the number of managed targets grows, your most important targets continue to be treated at high priority.

You may not use some of the other new features like administration groups or lifecycle management, but it’s still very much worth your while to set the lifecycle status target property. After all, you’re more concerned about alerts and monitoring on your mission critical and other production systems than you are on the staging and test systems, so why not tell EM12c about that and gain the benefits of target prioritization?

If you have quite a few targets it can be quite tedious to step through them all in the GUI interface to set this property. It works, but it’ll take a while. Enter emcli. Rob Zoeteweij has covered the setup of EMCLI in his blog post Installing EMCLI on EM12c so I won’t repeat that here other than to add that with the release of EM12cR2 there is no longer a JDK in the $OMS_HOME so if you’re running 12.1.0.2 you should amend his instructions as follows:


oracle@omshost$ export JAVA_HOME=$OMS_HOME/../jdk16/jdk
oracle@omshost$ export PATH=$JAVA_HOME/bin:$PATH
oracle@omshost$ export ORACLE_HOME=$OMS_HOME
oracle@omshost$ cd $ORACLE_HOME
oracle@omshost$ mkdir emcli
oracle@omshost$ java -jar $ORACLE_HOME/sysman/jlib/emclikit.jar client -install_dir=$ORACLE_HOME/emcli
Oracle Enterprise Manager 12c Release 2.
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved.

EM CLI client-side install completed successfully.
oracle@omshost$ $ORACLE_HOME/emcli/emcli setup -url=https://omshost.domain.com:7803/em -username=sysman
Oracle Enterprise Manager Cloud Control 12c Release 2.
Copyright (c) 1996, 2012 Oracle Corporation and/or its affiliates. All rights reserved.


Enter password

Warning: This certificate has not been identified as trusted in the local trust store
--------------------------------------
[certificate details snipped]
--------------------------------------
Do you trust the certificate chain? [yes/no] yes
Emcli setup successful

Once you have emcli running you can easily create files containing the target properties you would like to set, including the target lifecycle status, and apply them in bulk to your EM12c installation.

For the example I will demonstrate setting the target lifecycle status property for host targets. First you need to produce a list of your host targets, formatted for eventual input to the set_target_property_value verb:

oracle@omshost$ ./emcli get_targets -noheader -script -targets=host | awk '{print $4":"$3":LifeCycle Status:"}' > /tmp/targets

As another example, from commenter Bill Korb, to produce a list of database targets, including any currently under blackout, run:

oracle@omshost$ ./emcli get_targets -noheader -format='name:script;column_separator:|;' -targets='%database%' | awk -F\| '{print $4":"$3":LifeCycle Status:"}' > /tmp/targets

Edit the resulting file, appending the host or database’s lifecycle stage to each line. Be aware of the predefined lifecycle stages provided by Oracle, which are listed below in order of precedence:

  1. MissionCritical
  2. Production
  3. Stage
  4. Test
  5. Development

You can modify the names of these lifecycle stages with the modify_lifecycle_stage_name verb if you wish. Your file should now look something like:

dev1.domain.com:host:LifeCycle Status:Development
omshost.domain.com:host:LifeCycle Status:MissionCritical
prod1.domain.com:host:LifeCycle Status:Production
prod2.domain.com:host:LifeCycle Status:Production
prod3.domain.com:host:LifeCycle Status:Production
prod4.domain.com:host:LifeCycle Status:Production
stage1.domain.com:host:LifeCycle Status:Stage
test1.domain.com:host:LifeCycle Status:Test
test2.domain.com:host:LifeCycle Status:Test

Now make the call to emcli to load your target property definitions into the OMS:

oracle@omshost$ ./emcli set_target_property_value -property_records="REC_FILE" -input_file="REC_FILE:/tmp/targets" -separator=property_records="\n"

There you go. Your hosts are now updated with appropriate target lifecycle stages and the OMS will prioritize them based on these settings whenever the OMS is under high load. Repeat this for your listeners (-targets=oracle_listener), database instances (-targets=oracle_database) and so on until all of your targets have a lifecycle stage assigned. I’ve broken these out by target type for simplicity of documentation, but you can also just produce a single large file containing the lifecycle status for all of your targets and load the whole thing at once. This same technique works to assign a contact, comment, location, or any other target property you find useful.

Advertisement

7 thoughts on “How and why you should set target lifecycle status properties in EM12c

  1. Pingback: Why your EM12cR2 FMW stack probably needs patch 13490778 to avoid OHS down/up events | Pardy DBA

  2. Bill Korb

    Brian,

    I just found this one today, and it was extremely helpful, thanks!

    However, one slight change I would suggest. When I was doing this, another admin had blacked out a bunch of targets for patching, so the awk didn’t produce the desired output (since the status of those targets was “Blacked Out” which looked like two columns to awk). I made a slight change to the emcli & awk commands to resolve this:

    emcli get_targets -noheader -format=’name:script;column_separator:|;’ -targets=’%database%’ | awk -F\| ‘{print $4″:”$3″:LifeCycle Status:”}’ > /tmp/targets

    (I was doing this for my databases, both RAC and single instance, hence the wildcards in the targets option).

    Thanks again,
    Bill

    Reply
  3. Little Mac

    I just stumbled upon this today. This is a great post. Thanks for sharing. I’m just getting into EM to get a better view on the WebLogic systems I over see. I was hoping to find this exact type of post so that I can bulk edit the list of systems in EM.

    I have a question concerning using the Lifecycle Status property. Asking my colleagues about this property, they’ve given me the impression that we need to pay for a license to use this property. I believe they’re getting confused with the ‘Oracle Database Lifecycle Management Pack’ which does required a license to install and use. I believe the fact that it contains the name ‘Lifecycle’ is what’s throwing them off.

    Can you confirm whether any sort of licensing is needed to utilize this property? I inclined to believe there’s no correlation other than the word.

    Reply
    1. Brian Pardy Post author

      Hi,

      Great question, thank you. It’s always important to be aware of not over-stepping your license when working with OEM and the DB. Since licensing is so touchy I’ll throw in the disclaimer that I don’t work for Oracle and I’m not a lawyer and only Oracle’s license team via your side’s legal team can give you a definite answer, but I agree with you that there is no specific licensing to required to set or use the “LifeCycle Status” attributes on your OEM targets (assuming your targets are properly licensed, of course).

      I work from an assumption that the OEM “Licensing Information User Manual” (https://docs.oracle.com/cd/E73210_01/OEMLI/GUID-B7FDEFFE-DECB-4826-A3C8-7660B013C5DE.htm#GUID-4E100F17-C17F-4ADD-9DF9-D5D498A5ECF4 covers the Database Lifecycle Management Pack for EM13cR2) accurately describes the specific EM components provided by the individually licensed management packs. I’ve read over the very detailed list in the EM13cR2 documentation set and I don’t see anything that I read as covering setting any target property, including the Lifecycle Status property. The management pack seems to me more focused on automated deployment, patching, and configuration management.

      The emcli set_target_property_value verb used to set this property is not included in the list of emcli verbs licensed by the DBLM pack, and the Target Setup/Properties page is not included in the list of licensed menu paths, additional points in favor of considering it part of base functionality. I also somewhat rely on EM itself to keep me away from unlicensed functionality, and I have multiple databases without the DBLM pack where I have made sure that the Management Pack Access page has the checkbox for DBLM pack licensing unchecked, and OEM has never prevented me from viewing or editing any target’s properties.

      So I can’t really confirm 100% that this interpretation is correct, but I am confident enough in it that I follow it in production.

      Cheers!
      -Brian

      Reply
      1. Little Mac

        Thanks Brian for such a thorough reply. I too have tried to scour the docs to find any correlation but came up short. I know that not finding any relation doesn’t explicitly indicate licensing isn’t involved, and I appreciate your disclaimer stating you’re not affiliated with Oracle. I believe you’ve answered my question as I was really looking to see if anyone else had to explicitly purchase licensing to use that specific property. Honestly, that would be really silly IMO. You not given me any indication that you’ve had to use special licensing and in fact you’ve given me more circumstantial proof that because you are able to modify the property value using emcli, with the baked in verbs, that it is included with the core product. I’ve asked my Oracle engineer, whose posed the question to our Oracle rep, and now it’s just a matter of waiting. Once I get a response, I don’t mind posting the response.

        Granted, as Brian had indicated and I’ll follow suit with my own disclaimer, just because I post the answer to my licensing question doesn’t mean I have any authority in deciding the legitimacy of anyone else’s licensing requirements. With that said, I will parrot what Brian said and recommend everyone ask their own Oracle reps to be sure if they have ANY concerns with Oracle licensing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s