Wednesday Apr 16, 2014

RMAN Backups using Cloud Control

Friends, a technical article was recently published on the Oracle Technical Network:

Back Up a Thousand Databases Using Enterprise Manager Cloud Control 12c

This detailed technical article explains the set up and scheduling of full and incremental RMAN Database backups for  thousands of databases using Enterprise Manager 12c, and how this is done more easily and efficiently than the older, more time-consuming, manual method of performing Unix shell scripting, RMAN scripting, and CRON jobs for each database to be backed up.

And with the Database Group Backup feature new to Enterprise Manager 12c, it can be even faster to set up RMAN backups for multiple databases - even if there are thousands - that are part of an Enterprise Manager Database Group (one kind of target group).


The article also highlights the advantages of using Pluggable Databases (PDBs) in Oracle Database 12c and backing them up using RMAN. RMAN cannot backup individual schemas, and it has always been difficult to perform point-in-time-recovery (PITR) at an individual schema level, since schemas can easily be distributed across multiple tablespaces. The advantage in using PDBs in a Container Database is that you can easily set up RMAN backups at the Container Database level, and yet perform PITR at the PDB level. This is a clear technical advantage of the Multi-tenant architecture of Oracle Database 12c.

The set up and scheduling of RMAN database backups forms a part of the Base Database Management features of Enterprise Manager that enables numerous customers to get familiar with the day-to-day use of Enterprise Manager 12c. The full list of Base Database Management features can be found in the Enterprise Manager Licensing Information guide here.

In fact I had personally introduced Enterprise Manager to one of India’s largest financial services organizations in India in 2007 for the purpose of their RMAN backups, they started using it for the first time, and today we are proud to say that they are an Enterprise Manager reference customer who have presented in OOW for the last 2 years. The following slide is from their recent OOW presentation.


One thing I forgot to include in the article (and yes, it is a long article) was on reporting of the RMAN backups. A few readers asked me that question after the article’s publication, both inside and outside Oracle.

I told them that if they were using an RMAN catalog, the catalog would have this information and could easily be queried. If they were not using a catalog, then this backup information would be stored in the control file, and they would have to query each database’s control file (using V$ views) to get the backup report. BI Publisher, installed as an add-on to Enterprise Manager, could be used for this purpose. However note that if BI Publisher is used to query information from a source other than the Enterprise Manager repository database, a license is payable for each database it accesses.

Read the full article at “Back Up a Thousand Databases Using Enterprise Manager Cloud Control 12c”, and enjoy the world of Oracle Enterprise Manager.

Regards,

Porus Homi Havewala (OCM 11g/10g).

Stay Connected:
Twitter | Facebook | YouTube | Linkedin | Newsletter
Download the Oracle Enterprise Manager 12c Mobile app


Monday Mar 17, 2014

Installing a JDBC patch to an EM agent

If you have an Enterprise Manager 12c Release 3 or older agent monitoring database targets, Support may recommend that you install a JDBC (Java database connectivity) patch, such as patch 17591700, to prevent high CPU consumption by the agent.


JDBC patches, including 17591700, have readme files containing instructions for installing the patches to a database, not to an EM agent. This post provides an example of how to install a JDBC patch to an EM agent. It walks through the steps of installing patch 17591700 to an EM12c Release3 agent.


Here are the steps:

1.  Identify the version of the JDBC client in the Agent Binaries home.

  • Set the ORACLE_HOME environment variable to the Agent Binaries home.

$ setenv ORACLE_HOME /u01/em12/core/12.1.0.3.0


Note: One way to find out the Agent Binaries home is to look in file /etc/oragchomelist on the agent host. It should contain an entry for an agent install in the format of:

<Agent Binaries home>:<Agent home>

For example, file /etc/oragchomelist contains:

/u01/em12/core/12.1.0.3.0:/u01/em12/agent_inst



  • Run the following command to identify the version of the JDBC client.

$ $ORACLE_HOME/OPatch/opatch lsinv -details | grep 'Oracle JDBC/OCI Instant Client'
Oracle JDBC/OCI Instant Client           11.1.0.7.0

In this case, the version of the JDBC client is 11.1.0.7.0.


2.  Download the patch from MOS (My Oracle Support) website. The version of the JDBC client should match the version of the database for which the patch is intended. Stage the patch zip file, p17591700_111070_Generic.zip, on the agent host. I stage the patch in directory /u01/stage/jdbc_patch. I will refer to this location as the patch stage directory.


3.  Go to the patch stage directory and extract files from the zip file.

$ cd /u01/stage/jdbc_patch

$ unzip p17591700_111070_Generic.zip

Archive: p17591700_111070_Generic.zip

creating: 17591700/

inflating: 17591700/README.txt

creating: 17591700/files/

creating: 17591700/files/jdbc/

creating: 17591700/files/jdbc/lib/

inflating: 17591700/etc/xml/GenericActions.xml

inflating: 17591700/etc/xml/ShiphomeDirectoryStructure.xml


4.  Stop the agent.

$ /u01/em12/agent_inst/bin/emctl stop agent

Oracle Enterprise Manager Cloud Control 12c Release 3

Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved.

Stopping agent ..... stopped.


5.  Install the patch.

  • Go to the <patch stage directory>/<patch number>.

$ cd /u01/stage/jdbc_patch/17591700

  • Run opatch apply command.

$ $ORACLE_HOME/OPatch/opatch apply

Oracle Interim Patch Installer version 11.1.0.10.0

Copyright (c) 2013, Oracle Corporation. All rights reserved.

Oracle Home : /u01/em12/core/12.1.0.3.0

Central Inventory : /u01/app/oraInventory

from : /u01/em12/core/12.1.0.3.0/oraInst.loc

OPatch version : 11.1.0.10.0

OUI version : 11.1.0.11.0

Log file location : /u01/em12/core/12.1.0.3.0/cfgtoollogs/opatch/17591700_Mar_17_2014_12_03_05/apply2014-03-17_12-03-05PM_1.log

Applying interim patch '17591700' to OH '/u01/em12/core/12.1.0.3.0'

Verifying environment and performing prerequisite checks...

Patch 17591700: Optional component(s) missing : [ oracle.dbjava.jdbc, 11.1.0.7.0 ]

Interim patch 17591700 is a superset of the patch(es) [ 16087066 ] in the Oracle Home

OPatch will roll back the subset patches and apply the given patch.

All checks passed.

Backing up files...

Rolling back interim patch '16087066' from OH '/u01/em12/core/12.1.0.3.0'

Patching component oracle.dbjava.ic, 11.1.0.7.0...

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/aq/AQNotificationEvent$EventType.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/aq/AQNotificationEvent.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/dcn/DatabaseChangeEvent$AdditionalEventType.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/dcn/DatabaseChangeEvent$EventType.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/dcn/DatabaseChangeEvent.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/driver/NTFAQEvent.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/driver/NTFConnection.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/driver/NTFDCNEvent.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/driver/NTFManager.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/driver/T4CConnection.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc6.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc6.jar/oracle/jdbc/driver/T4CTTIokpn.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/aq/AQNotificationEvent$EventType.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/aq/AQNotificationEvent.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/dcn/DatabaseChangeEvent$AdditionalEventType.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/dcn/DatabaseChangeEvent$EventType.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/dcn/DatabaseChangeEvent.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/driver/NTFAQEvent.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/driver/NTFConnection.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/driver/NTFDCNEvent.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/driver/NTFManager.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/driver/T4CConnection.class"

Updating jar file "/u01/em12/core/12.1.0.3.0/jdbc/lib/ojdbc5.jar" with "/u01/em12/core/12.1.0.3.0/.patch_storage/16087066_Feb_4_2013_04_52_18/files//jdbc/lib/ojdbc5.jar/oracle/jdbc/driver/T4CTTIokpn.class"

RollbackSession removing interim patch '16087066' from inventory

OPatch back to application of the patch '17591700' after auto-rollback.

Patching component oracle.dbjava.ic, 11.1.0.7.0...

Verifying the update...

Patch 17591700 successfully applied

Log file location: /u01/em12/core/12.1.0.3.0/cfgtoollogs/opatch/17591700_Mar_17_2014_12_03_05/apply2014-03-17_12-03-05PM_1.log

OPatch succeeded


6. Start the agent.

$ /u01/em12/agent_inst/bin/emctl start agent

Oracle Enterprise Manager Cloud Control 12c Release 3

Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved.

Starting agent ............. started.


The above step completes the process of installing patch 17591700 to the 12.1.0.3 agent.

Tuesday Jan 07, 2014

Create a Database Instance without DB Control Schema

When using Database Configuration Assistant (DBCA) to create a database instance to house the repository of Enterprise Manager Cloud Control, people often end up with an instance containing DB Control schema, and they have to remove the schema from the instance before installing EM12c. To create an instance without DB Control or SYSMAN schema in the first place, make the following selections in the DBCA database creation process.


1. In the Database Template step, select the Custom Database option.



2. In the Management Options step, uncheck the Configure Enterprise Manager option.



Note: If DBCA locates an agent installation on the host, it will provide an option to register the database instance that you are creating with the corresponding Management Service. If you choose that option, DBCA will add the database instance to the Enterprise Manager site as a managed target upon completion of instance creation. This option, however, does not create SYSMAN schema in the database instance.



3. In the Database Content step, uncheck the Enterprise Manager Repository option.


Remember to make the above-mentioned selections, and you will have an instance without DB Control, which is fit for housing an EM repository.



Note: From EM12c Release 2, there is an option to create an 11.2.0.3 database instance with a pre-configured EM repository. For instructions see:

Creating a Database Instance with Preconfigured Repository Using Database Templates

Installing Oracle Database and Creating a Database


Saturday Nov 02, 2013

Sending notification after an event has remained open for a specified period

Enterprise Manager (EM) 12c allows you to create an incident rule to send a notification and/or create an incident after an event has been open for a specified period. Such an incident rule will help prevent premature alerts on issues that may correct themselves within a certain amount of time.

For example, there are some agents in an unstable network area, and often there are communication failures between the agents and the OMS lasting three, four minutes at a time. In this scenario, you may only want to receive alerts after an agent in that area has been in the Agent Unreachable status for at least five minutes.

Note: Many non-target availability metrics allow users to specify the “number of occurrences” or the number of consecutive times metric values reach thresholds before a notification is sent. It is best to use the feature for such metrics.


This article provides a step-by-step guide for creating an incident rule set to cater for the above scenario, that is, to create an incident and send a notification after the Agent Unreachable event has remained open for a five-minute duration.


Steps to create the incident rule

1.     Log on to the console and navigate to Setup -> Incidents -> Incident Rules.

Note: A non-super user requires the Create Enterprise Rule Set privilege, which is a resource privilege, to create an incident rule.


The Incident Rules - All Enterprise Rules page displays.


2.     Click Create Rule Set …

The Create Rule Set page displays.


3.     Enter a name for the rule set (e.g. Rule set for agents in flaky network areas), optionally enter a description, and leave everything else at default values, and click + Add.

The Search and Select: Targets page pops up.


Note:  While you can create a rule set for individual targets, it is a best practice to use a group for this purpose.



4.     Select an appropriate group, e.g. the AgentsInFlakyNework group. The Select button becomes enabled, click the button.

The Create Rule Set page displays.


5.     Leave everything at default values, and click the Rules tab.

The Create Rule Set page displays.


6.     Click Create…

The Select Type of Rule to Create page pops up.


7.     Leave the Incoming events and updates to events option selected, and click Continue.

The Create New Rule : Select Events page displays.


8.     Select Target Availability from the Type drop-down list.

The page shows more options for Target Availability.


9.     Select the Specific events of type Target Availability option, and click + Add.

The Select Target Availability events page pops up.


10.   Select Agent from the Target Type dropdown list.

The page expands.


11.   Click the Agent unreachable checkbox, and click OK.


Note: If you want to also receive a notification when the event is cleared, click the Agent unreachable end checkbox as well before clicking OK.


The Create New Rule : Select Events page displays.


12.   Click Next.

The Create New Rule : Add Actions page displays.


13.   Click + Add.

The Add Actions page displays.


14.   Do the following:

a.     Select the Only execute the actions if specified conditions match option (You don’t want the action to trigger always).

The following options appear in the Conditions for Actions section.

b.     Select the Event has been open for specified duration option.

The Conditions for actions section expands.

c.     Change the values of Event has been open for to 5 Minutes as shown below.

d.     In the Create Incident or Update Incident section, click the Create Incident checkbox as following:

e.     In the Notifications section, enter an appropriate EM user or email address in the E-mail To field.

f.     Click Continue (in the top right hand corner).

The Create New Rule : Add Actions page displays.


15.   Click Next.

The Create New Rule : Specify name and Description page displays.


16.   Enter a rule name, and click Next.

The Create New Rule : Review page appears.


17.   Click Continue, and proceed to save the rule set.

The incident rule set creation completes.

After one of the agents in the group specified in the rule set is stopped for over 5 minutes, EM will send a mail notification and create an incident as shown in the following screenshot.



In conclusion, you have seen the steps to create an example incident rule set that only creates an incident and triggers a notification after an event has been open for a specified period. Such an incident rule can help prevent unnecessary incidents and alert notifications leaving EM administrators time to more important tasks.

- Loc Nhan

Monday Oct 28, 2013

EM CLI, diving in and beyond!

Doing more in less time… Isn’t that what we all strive to do?

With this in mind, I put together two screen watches on Oracle Enterprise Manager 12c command line interface, or EM CLI as it is also known.

There is a wealth of information on any topic that you choose to read about, from manual pages to coding documents…might I even say blog posts? In our busy lives it is so nice to just sit back with a short video, watch and learn enough to dive in.

Doing more in less time, is the essence of EM CLI. It enables you to script fundamental and complex administrative tasks in an elegant way, thanks to the Jython scripting language. Repetitive tasks can be scripted and reused again and again. Sure, a Graphical User Interface provides a more intuitive step by step approach to tasks, and it provides a way of quickly becoming familiar with a product and its many features, and it is definitely the way to go when viewing performance data and historical trending…but for repetitive and complex tasks, scripting is the way to go!

Lets us take the everyday task of creating an administrator.

Using EM CLI in interactive mode the command could look like this..

emcli>create_user(name='jan.doe', type='EXTERNAL_USER')

This command creates an administrator called jan.doe which is an externally authenticated user, possibly LDAP or SSO, defined by the EXTERNAL_USER tag. The create_user procedure takes many arguments; see the documentation for more information.

Now, where EM CLI really shines and shows power is in creating multiple users. Regardless of the number, tens or thousands, the effort is the same. With the use of a standard programming construct, a loop, you can place your create_user() procedure within it. Using a loop allows you to iterate through a previously created list, creating new users until the list is complete.

Using EM CLI in Script mode, your Jython loop would look something like this…

for user in list_of_users:

      create_user(name=user, expire=’true’, password=’welcome123’) 

This Jython code snippet iterates through a previously defined list of names, list_of_users, and iterates through the list, taking each name, user in this case, and creates an administrator sets the password to welcome123, but forces the user to reset it when they first login.

This is only one of over four hundred procedures created to expose Oracle Enterprise Manager 12c functionality in a powerful and programmatic way.

It is a few months since we released EM CLI with scripting option. We are seeing many users adapt to this fun and powerful way of using Oracle Enterprise Manager 12c.

What are the first steps?

Watch these screen watches, and dive in.

The first screen watch steps you through where and how to download and install and how to run your first few commands.


The Second screen watch steps you through a few scripts.

Next time, I am going to show you the basic building blocks to writing a Jython script to perform Oracle Enterprise Manager 12c administrative tasks.

Join this growing group of EM CLI users…. Dive in!

Tuesday Jul 16, 2013

Harness the power of Configuration Search to know what's out there and drive automation

Oracle Enterprise Manager collects and monitors configuration information for every target it manages and layers support for sophisticated lifecycle operations on top of this foundation. Within the configuration management area itself Enterprise Manager has formalized support for Drift Management, Inventory Management, Topology visualization and Compliance Management. Although these features cover a good segment of configuration management use cases there will always be additional uses for this important information. Enterprise Manager makes it easy to leverage this valuable information both inside and outside the product using the Configuration Search feature.

Within the Enterprise Manager UI, users can build sophisticated queries against Enterprise Manager’s configuration management repository to generate reports without writing even one line of SQL. If the Oracle provided Search library does not already contain a matching search a user can build a search to their exact specification completely graphically.

Outside of the Enterprise Manager UI, users can find and run saved searches using the EMCLI in both interactive and the new script mode. When used in a script, configuration search results can be used to drive other lifecycle operations like patch automation and provisioning.

In this article we will take a closer look at the Configuration Search feature using some common real world examples.

Arguably one of the most important configuration items collected by Enterprise Manager is applied patches. Finding the location of applied patches can cause some confusion at first owing to the new target model introduced in Enterprise Manager 12c. Oracle Home is now a separate and proper target with its own configuration collection which includes patch information. This makes great sense as patches are in fact applied to the Oracle Home and not the software running out of it.

The question is how can you figure out which targets ( ie databases ) are using which Oracle Homes? The answer is using relationships. Enterprise Manager 12c now discovers and collects relationships between targets. These relationships include both physical (observed) and logical (inferred from configuration). As an example, all databases running out of a given Oracle Home will have an “Installed At” relationship to its specific Oracle Home target. These relationships can be graphically viewed using the topology viewer available under the configuration menu of all targets. They can also be used when building a Configuration Search when starting with a well known target like database instance.

Find all single instance databases with Advanced Compression option that do not have a patch applied. – Step by Step

Let’s build a configuration search to find all single instance databases with Advanced Compression option that do NOT have a patch applied to their Oracle Home. Since patches are typically specific to a version let’s narrow it down to version 11.2.0.3 databases and patch 14275605. ( Database Patch Set Update : 11.2.0.3.4 )

1. Start by navigating to the Configuration Search Library. Enterprise->Configuration –>Search…

2. Click Create to start building a new Configuration Search.

3. Select Database Instance from the Target Type list of value.

Next we need to narrow the list of databases to those of version 11.2.0.3 and single instance. To do this we will use the target model to choose properties which contain this data so we can filter it further.

4. Click Properties on the Database Instance row.

5. Open the Target Properties and Instance Information folders and Select Property Name, Property Value,Version, Name and Selected as shown.

6. Click OK.

To filter down the results, we enter criteria into the text boxes to the right of the properties.

7. Enter 11.2.0.3 next to Version.

8. Enter ‘Advanced Compression’ for Name and ‘TRUE’ for Selected under Database Options

9. Select ‘Metric Scope’ for property Name and Enter ‘DB’ for value. ( Metric scope can have a value of DB for single instance and RACINST for RAC instances. )

Your search should look something like this:

At any point while you are creating a Configuration Search, you can see how your search is coming along by clicking Search. Doing so at this point will show results similar to the results shown here. ( Note: If you are not interested in seeing the results of a column you can uncheck the property to remove it from the results. )

At this point we need to pull the Oracle Home target into the picture to get at the applied patches configuration information.

10. Click Relationships on the Database Instance row.

11. Choose “Oracle Home” as the Destination Target Type then Click Search. This should result in one relationship type “Installed At”. Select this row and click OK.

We now have something that looks like this:

To add collected patch information from the Oracle Home target we need to use the target model again.

12. Click Properties on the Oracle Home row.

13. Open the “Patches installed in Oracle Home” folder and select “Patch ID” property.

14. Click OK.

15. Enter 14275605 in the text box next to “Patch ID” to narrow the results to this patch.

16. Click Search. You should see something similar to the results below.

But wait, this shows the databases that HAVE patch 14275605 installed. We are after databases that DON’T have this patch installed.

Fortunately we can achieve this result by using the “Advanced Options” capabilities.

17. Click the “Advanced Options” button on the “Patches installed in Oracle Home” row. ( Be sure to select the correct one! )

18. Change the Condition in the resulting dialog box to “NOT EXISTS”. ( The explanatory text shown just happens to use patch search as an example. )

19. Click OK.

Notice the addition of “Condition : NOT EXISTS” on the “Patches installed in Oracle Home” row. This will show targets in which none of the targets matches the criteria. In our case, an Oracle Home may have hundreds of patches applied. Only if none of the patch IDs equal 14275605 will the target be in the results.

20. Click Search.

This time, the results finally display what we are after. That is “11.2.0.3 Single Instance database with Advanced Compression option that do NOT have patch 14275605 applied.”

21. Click ‘Save As’ to save the search with the name “11.2.0.3 SI AC DBs without patch 14275605”.

22. Click OK.

The library now shows our new search. You or any other user can run the search by selecting it and clicking Run. You can modify it by using Edit or make a copy with Create Like to continue to refine it without affecting the original.

Running Configuration Search using Interactive EMCLI

As mentioned at the opening, Enterprise Manager Release 3 now supports the execution of saved Configuration Search from the EMCLI. There are two verbs with which you can run configuration searches: get_targets and run_configuration_search

The get_targets verb has been available since Release 1 but now has an additional switch to specify a configuration search. This results in a standardized result containing the Target Name, Target Type and Status.

Here is an example using the configuration search we just built.

The run_config_search verb generates results exactly as you see them in the results of the configuration search. The results are a little harder to read but the output could be re-directed to an output file for import into something like a document editor or spreadsheet for easier viewing or analysis.

Scripting Lifecycle processes using EMCLI Script mode

Enterprise Manager Release 3 introduced the EMCLI Script mode which is especially effective when performing tasks in bulk or many tasks at once. This mode enables you to create Jython scripts, store them as files and pass them as an argument to EMCLI. For more information on EMCLI see the documentation here.

In this section, we will expand on our previous work to automate the creation of patch plans to automate the application of the missing patch. We will use a python script to retrieve the list of databases without a patch, and then create a patch plan for each database.

As a prerequisite you must create a sample patch plan for a single instance database which has the desired patch ( 14275605 ) added to the plan. We will use this plan to create the others.

The work flow is as follows:

  1. Retrieve specified patch plan metadata and extract required patch information.
  2. Get list of databases without the patch applied using a configuration search.
  3. Create a patch plan for each database.

Here is the script in its entirety. Obviously you will need to make modifications for you environment, specific patch plan and configuration search names.


 #emcli_config_search.py

from emcli import *
import xml.dom.minidom


# Set Connection properties and logon
set_client_property('EMCLI_OMS_URL','https://oem.example.com/em')
set_client_property('EMCLI_TRUSTALL','true')
login(username='DWWOLF1',password='password')

patch_id = []
release_id = []
platform_id = []
language_id = []
target_type = []

# Get Sample Patch Metadata
pp_xml = show_patch_plan(name='PSU4 Rollout').out()

# Parse plan metadata into XML
patchPlan = xml.dom.minidom.parseString(pp_xml)

# Retrieve metadata for each patch in the sample patch plan
for patchList in patchPlan.getElementsByTagName("patchList"):
        for patch in patchList.getElementsByTagName("patch"):
                patch_id.append(patch.getElementsByTagName("id")[0].toxml().replace("<id>","").replace("</id>",""))
                release_id.append(patch.getElementsByTagName("release_id")[0].toxml().replace("<release_id>","").replace("</release_id>",""))
                platform_id.append(patch.getElementsByTagName("platform_id")[0].toxml().replace("<platform_id>","").replace("</platform_id>",""))
                language_id.append(patch.getElementsByTagName("language_id")[0].toxml().replace("<language_id>","").replace("</language_id>",""))
                target_type.append(patch.getElementsByTagName("target_type")[0].toxml().replace("<target_type>","").replace("</target_type>",""))

# Run stored configuration search to get list of databases missing the patch
target_array = get_targets(config_search='11.2.0.3 SI AC DBs without patch 14275605').out()['data']

# For each target create a patch plan containing the patches in the sample patch plan
for targets in target_array:
    tn = targets['Target Name']
    nodeCount = 0
    f = open('patchplan.txt', mode='w')
        for node in patch_id:
                f.write( "patch." + str(nodeCount) + ".patch_id=" + patch_id[nodeCount] + "\n")
                f.write( "patch." + str(nodeCount) + ".release_id=" + release_id[nodeCount] + "\n")
                f.write( "patch." + str(nodeCount) + ".platform_id=" + platform_id[nodeCount] + "\n")
                f.write( "patch." + str(nodeCount) + ".language_id=" + language_id[nodeCount] + "\n")
                f.write( "patch." + str(nodeCount) + ".target_name=" + tn + "\n")
                f.write( "patch." + str(nodeCount) + ".target_type=" + target_type[nodeCount] + "\n")
                nodeCount += 1
        f.close()
        planName = 'PSU4 ' + tn
        create_patch_plan(name=planName,input_file='data:patchplan.txt',impact_other_targets='add_all')

exit()


A zip of the script is available for download here.

Run the script by passing it as an argument to EMCLI:

>emcli @emcli_config_search.py

Here we can see all of the patch plans created by the script plus the sample patch plan “PSU4 Rollout”

Conclusion

Enterprise Manager’s Configuration Search feature is a powerful tool that can be leveraged both inside and outside of the UI. It can quickly and easily provide answers to difficult configuration questions without writing any SQL. When used via through the EMCLI it can be used to dynamically generate a target list which can be used to drive complex and otherwise time consuming tasks in the UI quickly and efficiently.

Configuration Search and patch automation are both features of Enterprise Manager’s Database lifecycle management pack.

For more information on Enterprise Manager’s database lifecycle management capabilities, visit http://www.oracle.com/technetwork/oem/lifecycle-mgmt/index.html

Stay Connected:

Twitter |  Face book |  You Tube |  Linked in |  Newsletter

Monday Jun 10, 2013

Operational Plans - Running plans against multiple targets using Oracle Enterprise Manager Ops Center 12c

Oracle Enterprise Manager Ops Center - Operational Plans - Tricks and Tips #2

In this blog, I will be showing you how to run your Operational Plans against either a single target (host) or many targets at once. When you have created your Operational Plan and loaded it into Ops Center, the next thing you will want to do is to run it. If you want to run it against a single host, just select the target from the asset tree under the "Assets" menu.

Select the "Execute Operation" action near the top of the "Actions" panel.

 And select the Operational Plan you want to run.

You can also use predefined groups based on an Operating System version like "Solaris 10" by changing the pull-down in the "Assets" menu and selecting "Operating Systems". Of course, I expect that you will have more than one Solaris 10 host. When you execute the Operational Plan, it will run against all the targets that are part of that group.

With the group highlighted, select the "Execute Operation" action, which for OS groups is a little lower down the "Actions" panel.

It is worth noting here that as of Ops Center 12.1.3 (12C Update 3) the predefined Operating System group for Solaris 11 does not have the "Execute Operation" action enabled. While we are working on fixing that, it just means you have to create a User Defined Group based on Solaris 11 OS's. Creating a User Defined Group, both static and dynamic (smart groups), will be a topic for a later blog, but until then, if you don't know how to create a User Defined Group, please refer to the Ops Center documentation at http://docs.oracle.com/cd/E27363_01/doc.121/e27511/asset_mgmt.htm#OPCFG4247.

Or, as a third method of selecting Operational Plan targets, you can change the pull-down in the "Assets" menu and select "All User Defined Groups". Then, choose the group you would like to run your Operational Plan against. These groups can be created to hold whatever assets you require and the use of groupings is an extremely powerful feature of Ops Center. 

And once again look for and select the "Execute Operation" action.

And you will see your Operational Plan run against multiple targets. In this case, it is 2 targets but it could be as easily 2,000 targets that you have just updated, configured or controlled with just a few mouse clicks.

So we have covered how to run Operational Plans against a single target or a group of many targets, but what if you wanted to run your Operational Plan against a number of single hosts that you have not put into a group or a number of groups or a mixture of both? This can easily be done. We just start the selection from the Operational Plan perspective instead of the target perspective. The first step is to select "Plan Management" from the "Navigation" panel, then "Operational Plans" from within the "Plan Management" panel. Highlighting the Operational Plan you want to run will enable the icons in the middle panel.

Selecting the icon with the green tick will launch the "Select Target Assets" wizard.

Here it is just a matter of selecting any individual targets or groups of targets that you want to run your Operational Plan against, by clicking "Add to Target List", and then clicking "Next".

And fill in the Operational Plan variables as you usually would.

I hope this has given you more ways to launch your Operational Plans, whether it be for a single target, 2,000 targets or even more.

Regards,

Rodney


Monday Jun 03, 2013

Operational Plans - Recording user input to a log file using Oracle Enterprise Manager Ops Center 12c

Oracle Enterprise Manager Ops Center - Operational Plans - Tricks and Tips #1

This is the first of a series of blogs pointing out some tricks and tips in the use of Operational Plans in Oracle Enterprise Manager Ops Center.

Ops Center Operational Plans, as you may or may not know, allow you to run scripts and prompt the user for values for variables at run time.

In the above case, with one value, you may think this is a trivial thing, but unless your script outputs the variable to standard out or standard error, so that it get captured in the Ops Center job log, you have no historical record of what the user entered. You should log the user input, whether it is just for the record or as an audit trail or to use as a debugging tool. You could always echo each variable you request out to the log file, but what is the chance that you will forget one? The easiest way to display every variable is to include the "env" command into your script.

This has the advantage that you log, not only the user entered variables, but shell environments of the target server that you are running on, as I am sure that on the 1000 servers you administer, no one has ever change the PATH variable without you knowing it.

While adding "env " is enough, I have included a slightly nicer formatted module:

#!/bin/ksh
Log_Env () 
{		
# Log shell environment for the record
# Usage: Log_Env
# This is really useful if you need to check the values entered as run-time into the operational plan.
echo "INFO: Dumping the shell environment for the record..... [****Start****]"
env
echo "INFO: Dumping the shell environment for the record..... [**** End ****]"
}

Command ()
{
echo "INFO: Doing nothing as this is a test"
}

############
## Main ##
###########
Log_Env
Command   # Do the rest of your script here

I log the shell environment to standard out as it works for me, but as it has been pointed out to me that you could keep the script output logging to standard out and log diagnostic information like the "env" command, output could be logged to standard error. It is a simple change to the above script and I am still of two minds as to which is best, so choose whichever option (STDERR/STDOUT) suits you best.

So to see the script working:

First, load the Op Plan into your EC. Give it a name and select a target type (Operating Systems in this case).

Load or cut and paste the script in.

Define some variables (These are examples, just for testing).

Review the summary page and click finish in the wizard.

So we have our Operational Plan - Sample_Env_Script.

Then, let's run it on a couple of hosts:

I have chosen a group called "ProxyControllers" which has two hosts in it. 

Fill in some values in the Additional Environment Variables fields.

Schedule the job.

Review the summary and apply.


 Looking at the job output:

We see it has been successful on both hosts.

Clicking on a host, we can go into the job detail for each host. And there for all to see, recorded as part of the job log, is the values that the user inputted at run-time and the shell environment the script ran in. Both are great things to have if you ever have to debug one of your Op Plans.


If you click the export button and select full job log, you can see the job output for all the hosts that were part of the job. This is sometimes easier than clicking into each host.

Of course the full log can be saved to do with what you will.

I hope that this little tip helps you get more use out of Ops Center Operational Plans.

Regards,

Rodney


Wednesday May 15, 2013

How to go Physical to Virtual with Oracle Solaris Zones using Enterprise Manager Ops Center

Many customers have large collections of physical Solaris 8, 9 and 10 servers in their datacenters and they are wondering how they are going to virtualize them. This leads to a commonly asked question. Can Enterprise Manager Ops Center 12C be used to P2V (Physical to Virtual) my old servers? Ops Center does not have a single button P2V capability, but it is possible for Ops Center to deploy physical servers, LDOMs and branded zones based on flash archives(flars) that have been taken of your existing physical servers. Ops Center achieves P2V by deploying flars and leveraging its patching and automation capabilities, to make the P2V process consistent, repeatable and as cost effective as possible.

As with any virtualization project, there will be a number of things that will need to be updated as you move from a physical to a virtual environment. It is a common misconception that you can virtualize a system and change nothing about it. There are always a few things that have to be changed on an OS or process level to make it compatible with the virtualized environment. As a best practice, there are many more things that should be updated, re-allocated and redesigned as part of a virtualization project but that is a subject for another blog.

In this blog, we will be covering migrating physical servers to Oracle Solaris Zones.

We will also review this in our community call on Monday , 05/20/2013. Here are web conference details.

----

Topic: How to P2V to Oracle Solaris Zones using Enterprise Manager Ops Center
Date: Monday, May 20, 2013
Time: 5:00 pm, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 594 835 639
Meeting Password: oracle123
-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://oracleconferencing.webex.com/oracleconferencing/j.php?ED=236653047&UID=1653030737&PW=NNzUxYjUwOWY5&RT=MiMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: oracle123
4. Click "Join".

To view in other time zones or languages, please click the link:
https://oracleconferencing.webex.com/oracleconferencing/j.php?ED=236653047&UID=1653030737&PW=NNzUxYjUwOWY5&ORT=MiMxMQ%3D%3D

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
Call-in toll-free number:       1-866-682-4770  (US/Canada)      
Other countries:
https://www.intercallonline.com/listNumbersByCode.action?confCode=7629343

Conference Code:       7629343#
Security code:            7777# 
-----

Ops Center does not do anything differently to what you could do by hand, it just automates the process and, by the use of templates and wizards, drives consistency and repeatable results.

Physical Server to Branded Zones

Let’s first look at converting existing Solaris 8, 9 and 10 physical servers into Solaris 8/9 branded zones (on Solaris 10) and Solaris 10 branded zones (on Solaris 11).

There are 4 basic steps involved in converting a physical server to a virtual server.

Capture

This is done by creating a flash archive of the source system. If the source system is a Solaris 10 environment with a ZFS root, it is possible to use a ZFS based flar, but for consistency and ease of coding in the grooming scripts, I recommend that all flars be taken as a cpio flash archive.

When capturing the flar, we should include all the root files systems that will be required for the new zone to boot. If the application data is small, it can be included in the flar, but if it is large, you should copy the application data after the P2V migration is complete.

Example flar capture command line

# flarcreate -n [HostNameOfSourceSystem] -S -c -L cpio \

-x /[Dir where archive will be stored] \

 /[Dir where archive will be stored]/[HostNameOfSourceSystem].flar

Note that we are using the –x flag to exclude the directory where we are storing the archive. You can use multiple –x flags to exclude any other directories you do not want to include as part of the archive, such as large application data. Large archives just become difficult to unpack/pack and upload. As you can imagine, if your source archive contained 100 GB of application data, you would need probably 300-400 GB of space just to perform grooming, and that would make the process much slower.

Grooming

The first question I often get is, “Why do I need to groom my flar?” In an ideal world, you would not need to, but rarely do we live in an ideal world:

1). If your environments are like most customers', there are a wide variety of configurations, patching levels and processes that have been applied to the source system during its lifecycle. This level of entropy means that there may well be things that must be fixed, like the following “real world” examples of problems with source flars that I have observed:
    • A customer’s patching methodology had disabled the startup scripts that are required for a branded zone to boot.
    • Some Solaris “df” command patches were missing that are mandatory for Solaris 8/9 branded zones (with a separate /var) to work.
So formalized grooming is a chance to automate the fixing of these anomalies and to help standardize your new environment.

2).  A common restriction that is placed on you, in a migration project, is that you cannot alter/update/reconfigure the source machine to suit its target virtualized environment. So you have to at least apply any mandatory fixes needed to the archive file itself and preferably also remove anything that may conflict with/fail in the new virtualized environment. So, once again, a formalized grooming is an ideal way to address these requirements.

You will often come across the argument that everything must be identical on the new virtualized environment, in an attempt to minimize change. Let’s be honest here, while virtualization will aim to provide a functionally identical environment, there is a massive amount of change that is happening under the covers when you virtualize a machine and there are a few things that must be changed to make it work. The history of virtualization projects has shown that once the existing servers are virtualized, they are almost never revisited to cleanup the idiosyncrasies of the source machines to bring them into a standard format. Therefore, I am a supporter of more aggressive grooming and the cleaning up of years of entropy as part of the P2V process.

The way to make grooming consistent and less manual and tedious is to convert the steps into an Operational Plan and use Ops Center to run them in a consistent manner.

Here are some of the modules I usually include in my grooming plans:

Module

What It Does

Get_FLAR_info

Export flar info as shell variables to be used elsewhere in the program.

Flar_Cpio_Fmt_Check

Check that the flar is in cpio format.

Unpack_Archive

Unpack the flar archive.

Min_OS_Release

Check that the OS release meets the minimum for branded zones.

ServiceTag_Identity

Remove the service tag identity file. Old service tags and duplicate service tags can confuse Ops Center.

SoftPartition_Check

Check that no soft partition data is included in the flar.

Clean_FMD

Remove any outstanding FMD faults from source machine.

Clean_SVM

Disable any references to disk suite (svm/sds/ods) from source machine.

Clean_NFS

Disable any NFS mounts in vfstab from source machine as they may not be available in the new virtualized environment and will stop the zone from booting.

Add_Packages

Add missing packages if required (the packages you want to add are laid out under a directory structure).

Add_Patches

Add missing patches if required (the patches you want to add are laid out under a directory structure)

App_Disable

Disable application startup in the flash archive. It is often advisable to disable automatic application startup as part of the P2V process, so that it cannot conflict/corrupt the production source machine.

Agent_Cleanup

Un-configure OC agent and cleanup OC identity files in case the source system was already under Ops Center control.

Pack_Archive

Repack the flar archive.

These are just some of the common modules that I have used over the years on P2V projects. You may not need any or all of these. You may need to create your own module if you find something unique in your source machines. Grooming is an iterative process, as your source machines can vary wildly from any machine I have ever come across. This is not an Ops Center thing; this is just the nature of P2V on a source pool of unknown quality. So if you hit an issue, troubleshoot it, add a new module to the Operational Plan and try again. To help get you started, I have included some sample code [Sample Grooming script]. This script provides examples of what can be done and should be considered an example of how you can build your own grooming script.

Loading the script into an Operational Plan is as simple as:

Creating a new Operational Profile
Give the plan a name, and select Operating System as the target type.

Creating an Operational Plan

Click browse to find the script and then load it. I have increased the profile time out to 180 minutes as grooming large flars can take a while.
Browse and load script
Finally, specify any variables for which the script requires user input. You can specify the variable as required or optional and provide a hint/description to help the user at run time.
Specify variable input


So how do I groom my flar?

Step 1) Copy the flar taken from the source system onto any system managed by Ops Center that has sufficient space.

Step 2) Launch your grooming “Operational Plan” against the system to which you copied the flar.

Laanching an op plan

Step 3) Have a cup of coffee... then check the logs

Check the logs

Step 4) You now have a flar ready for uploading into Ops Center.

Deployment

Deployment is where this process comes under full Ops Center control.

Step 1) Load your groomed flar into the EC library.

Load Groomed flar

Step 2) Create a profile for the zone you want to deploy.

Create zone profile

Step 3) Deploy the zone.

Deploy a zone

When the job completes, you have your source system as a zone.

Customization

What are the sorts of actions you can do here?

  • Add additional networks if you only deployed with a single network.
  • Update the application configuration.
  • Update secondary apps like backup software, application monitoring, etc.
  • Re-enable application startup scripts and remote file systems in vfstab.
  • Do any updates to patches/packages/applications.

 To make these actions repeatable and consistent, I employ Operational Plans or Update Profiles.

Operational Plans – These are scripts that make actions repeatable and can be modified by operator input (Operational Plan Variables) at run time.

Update Profiles - These can contain patches, packages, scripts and customized configuration files (based on the system you are deploying to).

Choose the right method for what you are trying to do or combine both of them together in a Software Deployment/Update Plan.

Congratulations you have P2Ved your system.

Conclusion

It is fairly straightforward to automate the migration of physical servers to Oracle Solaris Zones using Enterprise Manager Ops Center. Operational Plans and Update Profiles are great tools to automate many of those operational tasks and increase their reliability and repeatability.

Look out for a future blog on “How to P2V to Oracle Virtual Machine for SPARC using Enterprise Manager Ops Center“.

Thursday May 02, 2013

How to Monitor Systems in Enterprise Manager using Ops Center

In this post, we'll use Ops Center to add hardware monitoring to Enterprise Manager. We'll discuss the existing capabilities of Host targets, show how to create an Infrastructure Stack and demonstrate some of the features it provides to Enterprise Manager.



A recording of this community call is now available here:

WebEx Recording: Ops Center integration with Cloud Control
          


Prerequisites

This blog post uses both the Enterprise Manager 12c Cloud Control and Ops Center products. The following list describes the initial setup state and provides links to Oracle documents you can use to install and configure both products:

  • Enterprise Manager 12c
    • Install and configure an Oracle Management Server and Repository (OMS and OMR)
    • Install the Oracle Management Agent (OMA) on a target OS instance
  • Ops Center 12c
    • Install and Configure the Enterprise and Proxy Controller (EC and PC)
    • Discover and manage the system and its associated OS (installing the Ops Center agent on the OS instance)

I've configured the environment for this post in the following way:

  • Enterprise Manager 12c: OMS and OMR running separately
  • Ops Center 12c: EC and PC running co-located
  • Two sample systems, both running Solaris 11
    • An Oracle SPARC T4-2 server
    • An Oracle SunFire X4200 M2 server

Host Capabilities in Enterprise Manager

By default, installing an Enterprise Manager agent on an OS instance creates an associated Host target. A Host provides a lot of useful data about the platform that hosts the OMA, such as

  • CPU and memory utilization
  • File system size and utilization
  • Network interfaces and activity
  • Program and process resources
  • User activity

The Host does not provide sensor data associated with the server and cannot report issues with the underlying hardware. Fortunately Ops Center can do both of these things, and you can incorporate server data, monitoring thresholds and alerts into your Enterprise Manager environment.

Setting Up an Infrastructure Stack

Ops Center: Configure the connection to Enterprise Manager

To connect Ops Center with Enterprise Manager, select the left-hand Navigation link Administration > Enterprise Manager Cloud Control. Click on the right-hand Action link Configure/Connect and open a pop-up dialog box. The dialog lets you configure the OMS and OMR settings. The screen shot below shows both steps from the wizard.

Enterprise Manager: Download and deploy the Ops Center Plug-In

Enterprise Manager 12c provides a deployable plug-in to manage an Infrastructure Stack. For Enterprise Manager installations running in online mode, you can download it from the Extensibility > Plug-Ins menu from the Servers, Storage and Network category.

Download and deploy the plug-in to the OMS. You can immediately deploy it to the OMA instances you want to integrate with Ops Center, or wait until you create an infrastructure stack. (Enterprise Manager will automatically install the plug-in to the OMA if it is not already present)

Enterprise Manager: Create an Infrastructure Stack Target

An Infrastructure Stack associates data from a system in Ops Center with targets in Enterprise Manager. To create one, select the menu option Setup > Add Targets > Add Targets Manually. From the wizard, select Infrastructure Stack from the pull-down menu and identify the Monitoring Agent that will be used.

The subsequent configuration screen allows you to define the name for the target, to identify the Enterprise Controller that will provide the data for the server, and to specify the Ops Center login credentials. Any user account defined in Ops Center is suitable for the target.

Infrastructure Stack Capabilities

What benefits does an Infrastructure Stack provide? As the consolidation point for server-related information, it enables you to perform three principal tasks:

  • Monitoring, with metrics and thresholds for the server
  • Reporting, using a set of standard Information Publisher reports
  • Incident Management, with Ops Center hardware alerts

Let's look at some examples for each.

Monitoring

An Infrastructure Stack provides a wealth of information about a server, including identification information, state, capabilities and sensor data. The home page provides a summary of current values for power consumption, temperature, fan speed, and reported incidents.

The metrics section provides more detailed data such as sensor values, thresholds, installed firmware and server capabilities.

Note that the reported values ultimately depend on what data is available for a specific type of server. Some earlier models don't report temperature data, for instance.

Reporting

Enterprise Manager provides three standard Information Publisher reports:

  • Infrastructure Stack Topology, showing the server and OS associated with the stack
  • Infrastructure Stack Configuration, providing a tabular summary of key data
  • Hardware Sensors, showing current values and thresholds for monitored server data

The following screen shots provide sample report output for the infrastructure stack configuration and hardware sensor data.

Incident Management

Incident reporting is an optional capability for an Infrastructure Stack. Enabling the feature causes Ops Center to forward hardware alarms, allowing you to consolidate problem management in Enterprise Manager.

To enable incident reporting, navigate to the Infrastructure Stack and select the menu option Monitoring > Metric and Collection Settings. Select the link Collection Schedule for Infrastructure Stack Alarms to edit the settings:

If you toggle the collection schedule to Enabled, Enterprise Manager will activate incident reporting based on hardware alarms. By default, the data refresh frequency is once every five minutes, with warning or critical alarms being reported.

In this example, we simulated an hardware alarm using the IPMItool utility from the Hardware Management Pack. Ops Center forwarded the event and all associated data, which generated an actionable incident in Enterprise Manager,

Summary

In this post, we have demonstrated how to integrate Ops Center data into Enterprise Manager, and described the features available for an Infrastructure Stack. If you would like to learn more, please join us for the WebEx demo on May 9th.


Monday Apr 29, 2013

Creating a generic service with emcli ( Oracle Enterprise Manager Command Line Interface )

This blog walks you through the steps to create an Enterprise Manager Cloud Control 12c generic service using the command line API emcli.  At the end of the walk through you will have created a service consisting of;
  • A Host, an Oracle Fusion Middleware Farm, a Database and a Listener
  • HTTP and JDBC Service Test

  • System based performance and usage metrics

  • Service based performance metrics

The following emcli verbs will be used during the exercise;

For this exercise we need to create an XML file consisting of the service test definitions and substitution variables.  The documentation for the create_service verb implies that we can specify separate files in the -input_file parameter, one for the tests and one for the variables; however the documentation is wrong and this is being addressed by (Bug 16329952).

The XML schema definition transaction-template.xsd, contains the definition for both variables and template files, however we recommend that you create a template from an existing service definition using the UI and then use the emcli verb extract_template_tests command to extract a pre-existing template, however if you are comfortable with XML file creation then you can review the examples template.xml and variables.xml.

Creating a template from an existing service definition

Using the UI navigate to Enterprise > Monitoring > Monitoring Templates

Click on the Create button

Click on Target for the Copy Monitoring Settings using option button and enter the name of an existing service that you want to copy and then click Continue.

In the next screen provide the Name of the template and click OK; this will accept the defaults that were provided from the target being copied.


Extract the service test definition from the template using emcli.

emcli extract_template_tests \
    -templateName="myTemplate" \
    -templateType=generic_service \
    -output_file=myTemplate.xml

At this point you need to edit the file myTemplate.xml and ensure that you have the correct values for the substitution variables at the top of the file.

<variables>
   <variable name="HOST1" value="myserver.company.com"/>
   <variable name="PASSWORD1" value="thepassword"/>
   <variable name="PORT1" value="7799"/>
   <variable name="PROTOCOL1" value="http"/>
</variables>

Create the System and Service definition

Now we can start by creating the system definition.

emcli create_system \
    -name="mySystem" \
    -add_members="EMGC_GCDomain:oracle_ias_farm" \
    -add_members="emrep.company.com:oracle_database:key_member" \
    -add_members="LISTENER_myserver.company.com:oracle_listener:key_member" \
    -add_members="myserver.company.com:host:key_member" \
    -timezone_region="PST8PDT" \
    -availabilty_type="ALL"

Before we can create the service we must first ensure that we have a beacon to replay the tests.  Create a beacon on an existing agent.

emcli add_target \
    -name="myBeacon" \
    -type="oracle_beacon" \
    -host="myserver.company.com"

Now we are ready to create the service.

emcli create_service \
    -name="myService" \
    -type="generic_service" \
    -availType="test" \
    -availOp="or" \
    -timezone_region="PST8PDT" \
    -systemname="mySystem" \
    -systemtype="generic_system" \
    -input_file=template:"/u01/app/oracle/home/myTemplate.xml" \
    -beacons="myBeacon:Y" \
    -keycomponents="emrep.company.com:oracle_database"

NOTE: Although -timezone_region is optional if it is not specified then the availability computation of the targets will fail and the service and its tests will always show status pending.  Therefore you MUST specify the timezone_region parameter (Bug 16344350).

Additionally if you try to create a service with a name that has been used before it will fail with the error;

Oracle Error :ORA-20233: Target with guid CB9DED6762A117EC708709489C883230 does not exist

This is fixed by Patch 10096491.

We can now create a bunch of Usage and Performance metrics for the service definition that we can alert on.  The key to these metrics is the MGMT$METRIC_COLLECTION view, from this view you will use the METRIC_NAME and METRIC_COLUMN field for the metric definitions for each target type. First we will create the Usage metrics which can only be based on the system definition and not the service.

Let’s add a Usage metric based on the Active HTTP Requests across all targets on the system definition.

emcli set_metric_promotion \
    -name="myService" \
    -type="generic_service" \
    -category=Usage \
    -basedOn=system \
    -aggFunction=AVG \
    -promotedMetricKey="Active HTTP Requests" \
    -metricName="ohs_server" \
    -column="request.active" \
    -depTargetType="oracle_apache" \
    -depTargets="/EMGC_GCDomain/instance1/ohs1" \
    -threshold="125;100;GT" \
    -mode=CREATE

Now one for the Average Active Sessions for the database targets in the system.

emcli set_metric_promotion \
    -name="myService" \
    -type="generic_service" \
    -category=Usage \
    -basedOn=system \
    -aggFunction=AVG \
    -promotedMetricKey="Average Active Sessions" \
    -metricName="instance_throughput" \
    -column="avg_active_sessions" \
    -depTargetType="oracle_database" \
    -depTargets="emrep.company.com" \
    -threshold="150;125;GT" \
    -mode=CREATE

Next the Performance metrics, the first one based on the system definition for CPU Utilization (%).

emcli set_metric_promotion \
    -name="myService" \
    -type="generic_service" \
    -category=Performance \
    -basedOn=system \
    -aggFunction=AVG \
    -depTargetType="host" \
    -depTargets="myserver.company.com" \
    -metricName="Load" \
    -column="cpuUtil" \
    -promotedMetricKey="CPU Utilization (%)" \
    -threshold="80;70;GE" \
    -mode=CREATE

The second based on the Total Time (ms) for the JDBC test

emcli set_metric_promotion \
    -name="myService" \
    -type="generic_service" \
    -category=Performance \
    -basedOn=test \
    -aggFunction=AVG \
    -testname="Database Login" \
    -testtype="JDBC" \
    -beacons="myBeacon" \
    -promotedMetricKey="Total Time (ms)" \
    -column="total_time" \
    -metricName="jdbc_response" \
    -metricLevel=TXN \
    -threshold="200;100;GT" \
    -mode=CREATE

The third based on the Perceived Total Time (ms) for the Homepage test

emcli set_metric_promotion \
    -name="myService" \
    -type="generic_service" \
    -category=Performance \
    -basedOn=test \
    -aggFunction=AVG \
    -testname="Homepage" \
    -testtype="HTTP" \
    -beacons="myBeacon" \
    -promotedMetricKey="Perceived Total Time (ms)" \
    -column="avg_response_time" \
    -metricName="http_response" \
    -metricLevel=TXN \
    -threshold="12000;6000;GT" \
    -mode=CREATE

At this point the Service homepage in Cloud Control looks like;

You will notice it does not show a chart, the metrics do not appear however if you navigate to Usage or Performance metrics page and click OK the metrics appear on the chart and you have to do this for both Usage and Performance.


Wednesday Mar 27, 2013

Using Advanced Notifications in Oracle Enterprise Manager 12c

When using an enterprise monitoring tool such as Oracle Enterprise Manager 12c, one of the most critical components is notification. Once an alert or issue has been identified, how do you tell the right people at the right time? Most enterprises use e-mail or open a trouble ticket. As you can imagine, no two enterprises are the same when it comes to their tools and processes. Many customers use one of the more common and well known trouble ticketing systems but quite a few use non-standard or custom (homegrown) trouble ticketing systems. Some customers have special routing requirements or corporate standards and have custom applications which handle all emailing functions instead of directly emailing using an SMTP server.

Oracle Enterprise Manager 12c can handle all of these situations by utilizing one of the various notification methods provided: E-mail, 3rd party connectors and advanced notification methods. There are three types of advanced notifications: SNMP, OS Command or PL/SQL. This blog will introduce you to the OS Command and PL/SQL notification methods available in EM 12c and provide an example of using a custom OS script for notifications.

[Read More]

Tuesday Nov 27, 2012

Using Oracle Enterprise Manager Ops Center to Update Solaris via Live Upgrade

Introduction: LU99_AD

This Oracle Enterprise Manager Ops Center blog entry provides tips for using Ops Center to update Solaris using Live Upgrade on Solaris 10 and Boot Environments on Solaris 11.

Why use Live Upgrade?

  • Live Upgrade (LU) can significantly reduce downtime associated with patching
  • Live Upgrade avoids dropping to single-user mode for long periods of time during patching
  • Live Upgrade relies on an Alternate Boot Environment (ABE)/(BE), which is patched while in multi-user mode; thereby allowing normal system operations to continue with the active BE, while the alternate BE is being patched
  • Activating a newly patched (A)BE is essentially a reboot; therefore the downtime is ~= reboot
  • Admins can easily revert to the prior Boot Environment (BE) as a safeguard / fallback.

Why use Ops Center to patch via Live Upgrade, Alternate Boot Environments, and Solaris 11 equivalents?

  • All the benefits of Ops Center's extensive patch and package knowledge base can be leveraged on top of Live Upgrade
  • Ops Center can orchestrate patching based on Live Upgrade and Solaris 11 features, which all works together to minimize downtime
  • Ops Center's advanced inventory and reporting features assure that each OS is updated to a verifiable, consistent standard, rather than relying on ad-hoc (error prone) procedures and scripts
  • Ops Center gives admins control over the boot environment specifications or they can let Ops Center decide when a BE is necessary, thereby reducing complexity and lowering the opportunity for user error

Preparing to use Live Upgrade-like features in Solaris 11

Requirements and information you should know:

  • Global Zone Root file-systems must be separate from Solaris Container / Zone filesystems
  • Solaris 11 has features which are similar in concept to Live Upgrade on Solaris 10, but differ greatly in implementation
    Important distinctions:
    • Solaris 11 assumes ZFS root
    • Solaris 11 adds Boot Environments (BE's) as an integrated feature (see beadm)
    • Solaris 11 BE's avoid single-user patching (vs. Solaris 10 w/ ZFS snapshot=ABE).
    • Solaris 11 Image Packaging System (IPS) has hooks for BE creation, as needed
      • Solaris 11 allows pkgs to be installed + upgraded in alternate BE (e.g. instead of the live system) but it is controlled on a per-pkg basis
      • Boot Environments are activated across a reboot; instead of spending long periods installing + upgrading packages in single user mode.
    • Fallback to a prior BE is a function of the BE infrastructure (a la beadm).
    • (Generally) Reboot + BE activation can be much much faster on Solaris 11

Preparing to use Live Upgrade on Solaris 10

Requirements and information you should know:

  • Global Zone Root file-systems must be separate from Solaris Container / Zone filesystems
  • Live Upgrade Pre-requisite patches must be applied before the first Live Upgrade Alternate Boot Environments are created (see "Pre-requisite Patches" section, below...)
  • Solaris 10 Update 6 or newer on ZFS root is the practical starting point for Live Upgrade
    • Live Upgrade with ZFS root is far more straight-forward than any scheme based on Alternative Boot Environments in slices or temporarily breaking mirrors
    • Use Solaris best practices to upgrade the OS to at least Solaris 10 Update 4 (outside of Ops Center)
    • UFS root can (technically) be used, but it is significantly more involved (e.g. discouraged) -- there are many reasons to move to ZFS while going through the process to update to Solaris 10 Update 6 or newer (out side of Ops Center)
  • Recommendation: Start with Solaris 10 Update 6 or newer on ZFS root
  • Recommendation: Start with Ops Center 12c or newer
    • Ops Center 12c can automatically create your ABE's for you, without the need for custom scripts
    • Ops Center 12c Update 2 avoids kernel panic on unpatched Solaris 10 update 9 (and older) -- unrelated to Live Upgrade, but more on the issue, below.
NOTE: There is no magic!  If you have systems running Solaris 10 Update 5 or older on UFS root, and you don't know how to get them updated to Solaris 10 on ZFS root, then there are services available from Oracle Advanced Customer Support (ACS), which specialize in this area.

Live Upgrade Pre-requisite Patches (Solaris 10)

Certain Live Upgrade related patches must be present before the first Live Upgrade ABE's are created on Solaris 10.
Use the following MOS Search String to find the “living document” that outlines the required patch minimums, which are necessary before using any Live Upgrade features:

Solaris Live Upgrade Software Patch Requirements

(Click above – the link is valid as of this writing, but search in MOS for the same "Solaris Live Upgrade Software Patch Requirements" string if necessary)

It is a very good idea to check the document periodically and adapt to its contents, accordingly.

IMPORTANT:  In case it wasn't clear in the above document, some direct patching of the active OS, including a reboot, may be required before Live Upgrade can be successfully used the first time.

HINT: You can use Ops Center to determine what to expect for a given system, and to schedule the “pre-patching” during a maintenance window if necessary.

Preparing to use Ops Center

  • Discover + Manage (Install + Configure the Ops Center agent in) each Global Zone
  • Recommendation:  Begin by using OCDoctor --agent-prereq to determine whether OS meets OC prerequisites (resolve any issues)
  • See prior requirements and recommendations w.r.t. starting with Solaris 10 Update 6 or newer on ZFS (or at least Solaris 10 Update 4 on UFS, with caveats)

  • WARNING: Systems running unpatched Solaris 10 update 9 (or older) should run the Ops Center 12c Update 2 agent to avoid a potential kernel panic
    • The 12c Update 2 agent will check patch minimums and disable certain process accounting features if the kernel is not sufficiently patched to avoid the panic
      • SPARC: 142900-05 Obsoleted by: 142900-06 SunOS 5.10: kernel patch 10 Oracle Solaris on SPARC (32-bit)
      • X64: 142901-05 Obsoleted by: 142901-06 SunOS 5.10_x86: kernel patch 10 Oracle Solaris on x86 (32-bit)
    • OR
      • SPARC: 142909-17 SunOS 5.10: kernel patch 10 Oracle Solaris on SPARC (32-bit)
      • X64: 142910-17 SunOS 5.10_x86: kernel patch 10 Oracle Solaris on x86 (32-bit)
    • Ops Center 12c (initial release) and 12c Update 1 agent can also be safely used with a workaround (to be performed BEFORE installing the agent):
# mkdir -p /etc/opt/sun/oc
# echo "zstat_exacct_allowed=false" > /etc/opt/sun/oc/zstat.conf
# chmod 755 /etc/opt/sun /etc/opt/sun/oc
# chmod 644 /etc/opt/sun/oc/zstat.conf
# chown -Rh root:sys /etc/opt/sun/oc

NOTE: Remove the above after patching the OS sufficiently, or after upgrading to the 12c Update 2 agent

Using Ops Center to apply Live Upgrade-related Pre-Patches (Solaris 10)
Overview:

  • Create an OS Update Profile containing the minimum LU-related pre-patches, based on the Solaris Live Upgrade Software Patch Requirements, previously mentioned.
  • SIMULATE the deployment of the LU-related pre-patches
  • Observe whether any of the LU-related pre-patches will require a reboot
    • The job details for each Global Zone will advise whether a reboot step will be required
  • ACTUALLY deploy the LU-related pre-patches, according to your change control process (e.g. if no reboot, maybe okay to do now; vs. must do later because of the reboot).
    • You can schedule the job to occur later, during a maintenance window
  • Check the job status for each node, resolving any issues found
  • Once the LU-related pre-patches are applied, you can Ops Center to patch using Live Upgrade on Solaris 10

Using Ops Center to patch Solaris 10 with LU/ABE's -- the GOODS!
(this is the heart of the tip):

  • Create an OS Update Profile containing the patches that make up your standard build
    • Use Solaris Baselines when possible
    • Add other individual patches as needed
  • ACTUALLY deploy the OS Update Profile
    • Specify the appropriate Live Upgrade options, e.g.
      • Synchronize the active BE to the alternate BE before patching
      • Do not activate the BE after patching
  • Check the job status for each node, resolving any issues found
  • Activate the newly patched BE according to your change control process
    • Activate = Reboot to the ABE, making the ABE the new active BE
      • Ops Center does not separate LU activate from reboot, so expect a reboot!
  • Check the job status for each node, resolving any issues found


Examples (w/Screenshots)

Solaris 10 and Live Upgrade: Auto-Create the Alternate Boot Environment (ZFS root only)

ABE to be created on ZFS with name S10_12_07REC (Example)

Uses built in feature to call “lucreate -n S10_12_07REC” behind scenes if not already present

NOTE: Leave “lucreate” params blank (if you do specify options, the will be appended after -n $ABEName)

LU01_S10_AutoCreate_BE

Solaris 10 and Live Upgrade: Alternate Boot Environment Creation via Operational Profile (script)

The Alternate Boot Environment is to be created via custom, user-supplied script, which does whatever is needed for the system where Live Upgrade will be used.

Operational Profile, which provides the script to create an ABE:

  • Very similar to the automatic case, but with a Script (Operational Profile), which is used to create the ABE
  • Relies on user-supplied script in the form of an Operational Profile
  • Could be used to prepare an ABE based on a UFS root in a slice, or on a separate device (e.g. by breaking a mirror first) – it is up to the script author to do the right thing!
  • EXAMPLE: Same result as the ZFS case, but illustrating the Operational Profile (e.g. script) approach to call:
# lucreate -n S10_1207REC

LU02_S10_Create_BE_Contents

NOTE: OC special variable is $ABEName


Boot Environment Profile, which references the Operational Profile

  • Script = Operational Profile on this screen
  • Refers to Operational Profile shown in the previous section
  • The user-supplied S10_Create_BE Operational Profile will be run
  • The Operational Profile must send a non-zero exit code if there is a problem (so that the OS Update job will not proceed)

LU03_S10_Create_BE

Solaris 10 OS Update Profile (to provide the actual patch specifications)

Solaris 10 Baseline “Recommended” chosen for “Install”

LU04_S10_OSUpProf

Solaris 10 OS Update Plan (two-steps in this case)

“Create a Boot Environment” + “Update OS” are chosen.

LU05_S10_OSUpPlan

Using Ops Center to patch Solaris 11 with Boot Environments (as needed)

  • Create a Solaris 11 OS Update Profile containing the packages that make up your standard build
  • ACTUALLY deploy the Solaris 11 OS Update Profile
    • BE will be created if needed (or you can stipulate no BE)
    • BE name will be auto-generated (if needed), or you may specify a BE name
  • Check the job status for each node, resolving any issues found
  • Check if a BE was created; if so, activate the new BE
    • Activate = Reboot to the BE, making the new BE the active BE
      • Ops Center does not separate BE activate from reboot
  • NOTE: Not every Solaris 11 OS Update will require a new BE, so a reboot may not be necessary.


Solaris 11: Auto BE Create (as Needed -- let Ops Center decide)

  • BE to be created as needed
  • BE to be named automatically
  • Reboot (if necessary) deferred to separate step

LU06_S11_AutoCreateBE

Solaris 11: OS Profile

Solaris 11 “entire” chosen for a particular SRU

LU07_S11_OSUpProf

Solaris 11: OS Update Plan (w/BE)

 “Create a Boot Environment” + “Update OS” are chosen.

LU08_S11_OSUpPlan

Summary:

Solaris 10 Live Upgrade, Alternate Boot Environments, and their equivalents on Solaris 11 can be very powerful tools to help minimize the downtime associated with updating your servers.  For very old Solaris, there are some important prerequisites to adhere to, but once the initial preparation is complete, Live Upgrade can be used going forward.  For Solaris 11, the built-in Boot Environment handling is leveraged directly by the Image Packaging System, and the result is a much more straight forward way to patch, and far fewer prerequisites to satisfy in getting there.  Ops Center simplifies using either approach, and helps you improve consistency from system to system, which ultimately helps you improve the overall up-time across all the Solaris systems in your environment.

Please let us know what you think?  Until next time...
\Leon
--

Leon Shaner | Senior IT/Product Architect
Systems Management | Ops Center Engineering @ Oracle

The views expressed on this [blog; Web site] are my own and do not necessarily reflect the views of Oracle.



For more information, please go to Oracle Enterprise Manager  web page or  follow us at : 

Twitter | Facebook | YouTube | Linkedin | Newsletter

Tuesday Nov 20, 2012

Upgrading to Oracle Enterprise Manager 12c Release 2: Top Tips One Must Know

Recently Oracle announced incremental release of Enterprise Manager 12c called Enterprise Manager 12c Release 2 (EM12c R2) which includes several new exciting features (Press announcement). Right before the official release, we upgraded an internal production site from EM 12c R1 to EM 12c R2 and had an extremely pleasant experience. Let me share few key takeaways as well as few tips from this upgrade exercise.

I - Why Should You Upgrade To Enterprise Manager 12c Release 2

While an upgrade is usually recommended primarily to take benefit of the latest features (which is valid for this upgrade as well), I found several other compelling reasons purely from deployment perspective.

  1. Standardize your EM deployment:  Enterprise Manager comprises of several different components (OMS, agents, plug-ins, etc) and it might be possible that these are at varied patch levels in your environment. For instance, in case of an environment containing Bundle Patch 1 (customer announcement), there is a good chance that you may not have all the components up-to-date. There are two possible reasons.
    • Bundle Patch 1 involved patching different components (OMS, agents, plug-ins) with multiple one-off patches which may not have been applied to all components yet.
    • Bundle Patch 1 for different platforms were not released together. Which means you may not have got the chance to patch all the components on different platforms.

    Note: BP1 patches are not mandatory to upgrade to EM12c R2 release

    EM 12c R2 provides an excellent opportunity to standardize your Cloud Control environment (OMS, repository and agents) and plug-ins to latest versions in single shot.

  2. All platform releases are made available simultaneously: For the very first time in the history of EM release, all the platforms were released on day one itself, which means you do not need to wait for platform specific binaries for EM OMS or Agent to perform install or upgrades in a heterogeneous environment.
  3. Highly refined and automated process – Upgrade process is by far the smoothest and the cleanest as compared to previous releases of Enterprise manager. Following are the ones that stand out.
    • Automatic Plug-in management – Plug-in upgrade along with new plug-in deployment is supported in upgrade installer wizard which means bulk of the updates to OMS and repository can be done in the same workflow. Saves time and minimizes user inputs.
    • Plug-in Upgrade or Migrate

    • Auto Update: While doing the OMS and repository upgrade, you can use Auto Update screen in Oracle Universal Installer to check for any updates/patches. That will help you to avoid the know issues and will make sure that your upgrade is successful.
    • Allows mass upgrade of EM Agents – A new dedicated menu has been added in the EM console for agent upgrade. Agent upgrade workflow is extremely simple that requires agent name as the only input.
    • ADM / JVMD Manager/Agent upgrade – complete process is supported via UI screens.
    • EM12c R2 Upgrade Guide is much simpler to follow as compared to those for earlier releases. This is attributed to the simpler upgrade process.
  4. Robust and Performing Platform: EM12c R2 release not only includes several new features, but also provides a more stable platform which incorporates several fixes and enhancements in the Enterprise Manager framework.

II - Few Tips To Remember

In my last post (blog link) I shared few tips and tricks from my experience applying the Bundle Patch. Recently I upgraded the same site to EM 12c R2 and found few points that you must take note of, while planning this upgrade. The tips below are also applicable to EM 12c R1 environments that do not have Bundle Patch 1 patches applied.

  1. Verify the monitored application certification – Specific targets like E-Business Suite have not yet been certified as managed target in EM 12c R2. Therefore make sure to recheck the Enterprise Manager certification Matrix on My Oracle Support before planning the upgrade.
  2. Plan downtime – Because EM 12c R2 is an incremental release of EM 12c, for EM 12c R1 to EM 12c R2 upgrade supports only 1-system upgrade approach, which mean there will be downtime.
  3. OMS name change after upgrade – In case of multi OMS environments, additional OMS is renamed after upgrade, which has few implications when you upgrade JVMD and ADP agents on OMS. This is well documented in upgrade guide but make sure you read through all the notes.
  4. Upgrading BI Publisher– EM12c R2 is certified with BI Publisher 11.1.1.6.0 only. Therefore in case you are using EM 12c R1 which is integrated with BI Publisher 11.1.1.5.0, you must upgrade the BI Publisher to 11.1.1.6.0. Follow the steps from Advanced Installation and Configuration Guide here.
  5. Perform Post upgrade Tasks – Make sure to perform post upgrade steps mentioned in documentation here. These include critical changes that must be done right after upgrade to get the right configuration. For instance Database plug-in should be upgraded to Revision 3 (12.1.0.2.0 [u120804]).
  6. Delete old OMS Home – EM12c R1 to EM12c R2 is an out of place upgrade, which means it creates a new oracle home for OMS, plug-ins, etc. Therefore please ensure that
    • You have sufficient extra space for new OMS before starting the upgrade process.
    • You clean up the old OMS home after the upgrade process. Steps are available here.
    • DO NOT remove the agent home on OMS host, because agent is upgraded in-place.
  7. If you have standby OMS setup then do look into the steps to upgrade the standby OMS from the upgrade guide before going ahead.
  8. Read the right documentation – Make sure to follow the Upgrade guide which provides the most comprehensive information on EM12c R2 upgrade process. Additionally you can refer other resources to get familiar with upgrade concepts.

We are very excited about this latest release and will look forward to hear back any feedback from your upgrade experience!

Stay Connected:

Twitter |  Facebook |  YouTube |  Linkedin |  Newsletter

Thursday Nov 15, 2012

Ops Center Solaris 11 IPS Repository Management: Using ISO Images

A recording of this community call is now available here:

https://oracleconferencing.webex.com/oracleconferencing/ldr.php?AT=pb&SP=MC&rID=71862997&rKey=76be5a666dc12c90

With Enterprise Manager Ops Center 12c, you can provision, patch, monitor and manage Oracle Solaris 11 instances. To do this, Ops Center creates and maintains a Solaris 11 Image Packaging System (IPS) repository on the Enterprise Controller. During the Enterprise Controller configuration, you can load repository content directly from Oracle's Support Web site and subsequently synchronize the repository as new content becomes available.

Of course, you can also use Solaris 11 ISO images to create and update your Ops Center repository. There are a few excellent reasons for doing this:

  1. You're running Ops Center in disconnected mode, and don't have Internet access on your Enterprise Controller
  2. You'd rather avoid the bandwidth associated with live synchronization of a Solaris 11 package repository

This demo will show you how to use Solaris 11 ISO images to set up and update your Ops Center repository.


Prerequisites

This tip assumes that you've already installed the Enterprise Controller on a Solaris 11 OS instance and that you're ready for post-install configuration.

In addition, there are specific Ops Center and OS version requirements depending on which version of Solaris 11 you plan to install.You can get full details about the requirements in the Release Notes for Ops Center 12c update 2.

Additional information is available in the Ops Center update 2 Readme document.


Part 1: Using a Solaris 11 ISO Image to Create an Ops Center Repository

Step 1 – Download the Solaris 11 Repository Image

The Oracle Web site provides a number of download links for official Solaris 11 images. Among those links is a two-part downloadable repository image, which provides repository content for Solaris 11 SPARC and X86 architectures. In this case, I used the Solaris 11 11/11 image.

First, navigate to the Oracle Web site and accept the OTN License agreement:

http://www.oracle.com/technetwork/server-storage/solaris11/downloads/index.html

Next, download both parts of the Solaris 11 repository image. I used the Solaris 11 11/11 image, and have provided the URLs here:

http://download.oracle.com/otn/solaris/11/sol-11-1111-repo-full.iso-a
http://download.oracle.com/otn/solaris/11/sol-11-1111-repo-full.iso-b

Finally, use the cat command to generate an ISO image you can use to create your repository:
# cat sol-11-1111-repo-full.iso-a sol-11-1111-repo-full.iso-b > sol-11-1111-repo-full.iso

The process is very similar if you plan to set up a Solaris 11.1 release in Ops Center. In that case, navigate to the Solaris 11 download page, accept the license agreement and download both parts of the Solaris 11.1 repository image. Use the cat command to create a single ISO image for Solaris 11.1

Step 2 – Mount the Solaris 11 ISO Image in your Local Filesystem

Once you have created the Solaris 11 ISO file, use the mount command to attach it to your local filesystem. After the image has been mounted, you can browse the repository from the ./repo subdirectory, and use the pkgrepo command to verify that Solaris 11 recognizes the content:


Step 3 – Use the Image to Create your Ops Center Repository

When you have confirmed the repository is available, you can use the image to create the Enterprise Controller repository. The operation will be slightly different depending on whether you configure Ops Center for Connected or Disconnected Mode operation.

For connected mode operation, specify the mounted ./repo directory in step 4.1 of the configuration wizard, replacing the default Web-based URL. Since you're synchronizing from an OS repository image, you don't need to specify a key or certificate for the operation.


For disconnected mode configuration, specify the Solaris 11 directory along with the path to the disconnected mode bundle downloaded by running the Ops Center harvester script:

Ops Center will run a job to import package content from the mounted ISO image. A synchronization job can take several hours to run – in my case, the job ran for 3 hours, 22 minutes on a SunFire X4200 M2 server.


During the job, Ops Center performs three important tasks:

  1. Synchronizes all content from the image and refreshes the repository
  2. Updates the IPS publisher information
  3. Creates OS Provisioning profiles and policies based on the content

When the job is complete, you can unmount the ISO image from your Enterprise Controller. At that time, you can view the repository contents in your Ops Center Solaris 11 library. For the Solaris 11 11/11 release, you should see 8,668 packages and patches in the contents.


You should also see default deployment plans for Solaris 11 provisioning. As part of the repository import, Ops Center generates plans and profiles for desktop, small and large servers for the SPARC and X86 architecture.



Part 2: Using a Solaris 11 SRU to update an Ops Center Repository

It's possible to use the same approach to upgrade your Ops Center repository to a Solaris 11 Support Repository Update, or SRU. Each SRU provides packages and updates to Solaris 11 - for example, SRU 8.5 provided the packaged for Oracle VM Server for SPARC 2.2

SRUs are available for download as ISO images from My Oracle Support, under document ID 1372094.1. The document provides download links for all SRUs which have been released by Oracle for Solaris 11. SRUs are cumulative, so later versions include the packages from earlier SRUs.


After downloading an ISO image for an SRU, you can mount it to your local filesystem using a mount command similar to the one shown for Solaris 11 11/11.

When the ISO image is mounted to the file system, you can perform the Add Content action from the Solaris 11 Library to synchronize packages and patches from the mounted image. I used the same mount point, so the repository URL was file://mnt/repo once again:


After the synchronization of an SRU is complete, you can verify its content in the Solaris 11 library using the search function. The version pattern is 0.175.0.#, where the # is the same value as the SRU.

In this example, I upgraded to SRU 1. The update job ran in just under 8 minutes, and a quick search shows that 22 software components were added to the repository:


It's also possible to search for "Support Repository Update" to confirm the SRU was successfully added to the repository. Details on any of the update content are available by clicking the "View Details" button under the Packages/Patches entry.


About

Latest information and perspectives on Oracle Enterprise Manager.

Related Blogs




Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
3
5
6
7
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today