• About
  • Home
  • Oracle Enterprise Manager

Musings

~ Things I see and learn!

Author Archives: adeeshfulay

EMCLI with Scripting Option: Embedded Jython Interpreter

05 Thursday Mar 2015

Posted by adeeshfulay in emcli, oracle enterprise manager

≈ 4 Comments

Tags

em12c, emcli, jython, scripting option

If you have been using the classic Oracle Enterprise Manager Command Line interface (EMCLI ), you are in for a treat. Oracle Enterprise Manager 12c R3 comes with a new EMCLI kit called ‘EMCLI with Scripting Option’. Not my favorite name, as I would have preferred to call this EMSHELL since it truly provides a shell similar to bash or cshell.  Unlike the classic EMCLI, this new kit provides a Jython-based scripting environment along with the large collection of verbs to use. This scripting environment enables users to use established programming language constructs like loops (for, or while), conditional statements (if-else), etc in both interactive and scripting mode.

Benefits of ‘EMCLI with Scripting Option’

Some of the key benefits of the new EMCLI are:

  • Jython based scripting environment
  • Interactive and scripting mode
  • Standardized output format using JSON
  • Can connect to any EM environment (no need to run EMCLI setup …)
  • Stateless communication with OMS (no user data is stored with the client)
  • Generic list function for EM resources
  • Ability to run user-defined SQL queries to access published repository views

Before we go any further, there are two topics that warrant some discussion – Jython and JSON.

Jython

Jython is the Java implementation of the Python programming language. I have been working with Python (or CPython) and Jython for the last 10 years, and to me it is the best scripting language ever. It is fun, easy to learn, the syntax is simple, is self formatted, and is dynamically typed. This comic from XKCD summarizes it the best:

Python

There are numerous tutorials for Python/Jython on the web, so feel free to pick anyone you like but just remember that the Jython version supported by the new kit is v2.5.1.

JSON

JSON stands for JavaScript Object Notation. It is a data interchange format, much like XML, which is easier to read and write for both humans and machines, but unlike XML it contains very little metadata (elements and attribute names). JSON format is quite simple; it basically represents data as a collection of name/value pairs. These pairs can be contained within arrays, lists, or maps. Here is a sample:

{"menu": {
    "id": "file",
    "value": "File",
    "popup": {
    "menuitem": [
        {"value": "New", "onclick": "CreateNewDoc()"},
        {"value": "Open", "onclick": "OpenDoc()"},
        {"value": "Close", "onclick": "CloseDoc()"}
        ]
    }
}}

JSON is quite popular. You will often find it used with REST based web services APIs or even with some modern databases like MongoDB. Most programming languages provide libraries to work with JSON.

The EMCLI kit uses JSON as its output format as well. Many of the verbs return output in JSON format for ease of programmatic use. I say many, since there are still some verbs that don’t, but this is only matter of time.

Now let’s get back to EMCLI.

Steps to setup the kit for ‘EMCLI with Scripting Option’

1. To download the new EMCLI kit, go to Setup->Command Line Interface. Here you will notice the new section for ‘EMCLI with Scripting Option’. Click on the link to download the kit to your desktop or desired server.

Download

You can also download the kit directly from the following url:

http(s)://<host>:<port>/em/public_lib_download/emcli/kit/emcliadvancedkit.jar

2. Copy the kit (emcliadvancedkit.jar) to a directory where you wish to install EMCLI

kit

3. To install, run the following command. Note that we need the Java version to be 1.6.0_43 or greater.

java -jar emcliadvancedkit.jar client -install_dir=<emcli_client_dir>

Verify Java version

4. The last step to complete the setup is to run ‘sync’. Before using EMCLI you have to connect to the OMS to install all verb-related command line help. In classic EMCLI, this happens automatically when you run the ‘setup’ command. But in the new EMCLI, since we do not run setup, we run the ‘sync’ command instead.

The ‘sync’ verb now accepts some additional arguments. Run the following command:

emcli sync -url=http(s)://<host>:<port>/em -username=<user> -trustall

It will prompt for the user password and then take a few minutes to download and install all the help content.

emcli sync

5. Now confirm the setup with a simple test. We do this using the interactive mode. Just run ‘emcli’, and once you see the prompt run ‘help()’. This will print list all verbs along with their description.

emcli interactive mode

With the setup complete, let’s now have some fun.

Using the ‘EMCLI with Scripting Option’

Connect to the interactive mode by running ‘emcli’ from the command prompt. Now try the following commands:

1. Basic Jython: Since EMCLI is built using the Jython interpreter, you can run
Jython commands at the EMCLI prompt. For example, you can try the following:

1+2
print "Hello Jython"
mylist = [1,2,3]
print mylist

Jython test

2. EMCLI Status: Next, print the status of the EMCLI session using the ‘status()’ command.

emcli status

You will notice that the EM url and user are not set. To do this we have to set the client_properties. Run ‘help(‘client_properties’)’ for more details.

client properties

The help text instructs us to set the client properties to connect to a specific EM environment. The 4 properties of interest to us are the following:

Name

Details

EMCLI_OMS_URL

The EM url

EMCLI_USERNAME

The EM user to connect as. We will use the login() function to set
this.

EMCLI_TRUSTALL

I like to set this to true, but the default is false.

EMCLI_OUTPUT_TYPE

I like to set this to JSON even for interactive mode

To set these properties run the following:

set_client_property('EMCLI_OMS_URL','http(s)://host:port/em')
set_client_property('EMCLI_TRUSTALL','TRUE')
set_client_property('EMCLI_OUTPUT_TYPE','JSON')
login(username="em_user",password="password")

You should see the message on successful login. Now we are connected to EM.

login

3. Understanding help and verb invocations: Most of the help text presented in EMCLI is tailored towards the classic interface. Since Jython is a programming language, verb invocations are done in the function form. There is a simple mechanism for converting the classic invocation format for use in both interactive and scripting mode. Let’s use the login() verb as an example.

The EMCLI help for login is as follows:

help('login')
emcli login

-username=<EM Console Username>

[-password=<EM Console Password>]

[-force]

This means, when using classic EMCLI, you would invoke it as follows:

emcli login –username="foo" –password="bar" -force

Instead, in the interactive or script mode, the invocation would look like:

login(username="em_user",password="password",force=True)

Essentially, all verbs are now functions, and all arguments to the verb are now parameters passed to the function. Since the –force argument does not take any value, it is treated as a Boolean in Jython and takes the values of True or False.

Note: The -force parameter in the login() function is not applicable to the interactive or script mode, but is being used in this example to explain the concept of passing Boolean values. Again, you should never use the -force parameter in the interactive or script mode.

Another such conversion that you may come across is for list of values. For example,

In classic EMCLI, some verbs will ask for the same attribute to be repeated with varying values to represent a list.

emcli grant_privs -name='jan.doe'
         -privilege="USE_ANY_BEACON"
         -privilege="FULL_TARGET;TARGET_NAME=host1.acme.com:TARGET_TYPE=host"

In interactive or script mode, you can use native Jython listes instead and pass it as parameters. In Jython, lists are represented within square brackets ([]).

priv_list = ['USE_ANY_BEACON','FULL_TARGET;TARGET_NAME=host1.acme.com:TARGET_TYPE=host']
grant_privs(name='jan.doe',privilege=priv_list)

4. Sample Use Case: Let’s take a very simple use case to demonstrate the interaction with EMCLI in the interactive mode. So our sample use case is to ‘List all targets of type oracle_database and those whose name starts with the characters ‘db’”.

For this use case, we will make use of the new generic ‘list’ verb. Traditionally, each feature in EM provided its own verbs for list, get, show, and describe. Rather than working with multiple such variants, the new generic ‘list’ verb takes a page from the REST web service specification and provides a generic action that can work against different EM resources.

To learn more about this verb, we run:

help('list')

help

The help text shows us the format of this verb. Essentially, there are 3 parameters that we care about:

  • resource = the EM resource which is to be queried
  • columns = specify the different resource attributes to display
  • search = filters to narrow down the result

First, we need to know the list of resources that are supported by this verb. For this we run

list(‘help’)

list help

From the output, it is obvious that for our sample use case we want to query the Targets resource.

Second, we need to know which columns are supported by the Targets resource. For this, we run

list('help',resource="Targets")

help resourcesl

From the output, we can determine that we need the column related to target name and type. With this we have all the information we need to construct the final function call for our sample use case.

For ease of explanation, I will break down the process of determining the final function call into small incremental steps. Once you gain proficiency, you will be able to define this
function in a single pass.

       1. List all targets in the EM environment. For this we run,

list(resource="Targets")

This command will spew a lot of text on your screen as there are likely to be numerous targets in your EM environment. So instead of listing all of them on the screen, let’s just get a count. For this, we need to understand the output format of this verb.

Any function that you run in the interactive or script mode returns an object of class Response (<class ’emcli.response.Response’>). The Response class has 4 key methods:

Function

Description

out()

Provides the verb execution output. The output can be text, or the JSON.

 isJson() method on the Response object can be used to determine whether the output is JSON.

error()

Provides the error text (if any) of the verb execution if there are any errors or exceptions during verb execution.

exit_code()

Provides the exit code of the verb execution. The exit code is zero for a successful execution and non-zero otherwise.

isJson()

Provides details about the type of output. It returns True if response.out() can be parsed into a JSON object.

So let’s look at a code snippet.

snippet

For the first function call to list all targets in EM, we store the results into a variable called ‘all_tgts’. This variable contains the response object. ‘all_tgts.out()’ will give us the actual output. The output returned is in JSON format which automatically gets converted into a Jython dictionary (collection of name-value pairs represented by curly brackets). The output dictionary has a key name called ‘data’ which contains all search results in the form of a Jython list as its value. Finally, len() is a native Jython function which returns the number of elements in a Jython list. As seen in the output, we found 878 targets in the EM environment which is clearly not what we desire.

 2. Now we add search parameters to filter our results. We add two search filters, first the target type should be equal to oracle_database, and second the target name be like db%. You can add multiple search filters to the function call, but all these filters should be encapsulated in a Jython list. The search filter supports various operators: =, !=, >, <, >=, <=, like, null, and not null. Similar to a SQL query, you can also
control which columns are to be displayed in the output.

So let’s run our final function.

search_filters=["TARGET_TYPE='oracle_database'","TARGET_NAME like 'db%'"]
list(resource="Targets",columns="TARGET_NAME,TARGET_TYPE", search=search_filters)

The formatted output looks like this. As mentioned before it is in the form of a Jython dictionary which can be easily accessed programmatically. The value of the ‘data’ key is a Jython list that contains all search results, while the other keys provide other metadata related to the result.

{

'exceedsMaxRows':False, 

'columnHeaders':['TARGET_NAME', 'TARGET_TYPE'], 

'columnLength':[256, 64], 

'columnNames':['TARGET_NAME', 'TARGET_TYPE'], 

'data':[ {'TARGET_NAME':'db9328.acme.com','TARGET_TYPE':'oracle_database'}, {'TARGET_NAME':'db3092.acme.com','TARGET_TYPE':'oracle_database'},], 

'filler':
 '\n\n\n'}

You must have noticed that I hardly talk about the scripting mode. This is on purpose, as I believe that interactive mode is the best interface to learn the new EMCLI. Once you master the interactive mode, converting your code snippets into a script is fairly easy. In future blog posts, I will cover scripting mode and numerous other use cases that seem like a perfect fit for the new EMCLI.

In summary, ‘EMCLI with Scripting Option’ is a new kit that is built on top of a Jython interpreter. It is much superior to the classic EMCLI, as it provides a complete programming environment with the ability to use native Jython functions and primitives. The output is presented in the JSON format which is both human and machine readable, and avoids the need for parsing text output. The client is completely stateless, which means no user data is stored with the client. This means numerous sessions can be launched from a single client, each connecting to a different EM environment, and as a different user.

I encourage you to play around with this new EMCLI kit, and post the different use cases that you found interesting and would benefit the community.

Additional Reading:

The EMCLI Documentation Guide

Advertisement

What is EM 12c DBaaS Snap Clone?

02 Monday Mar 2015

Posted by adeeshfulay in Data Clone and Refresh, oracle enterprise manager, private cloud

≈ Leave a comment

Tags

Automation, cloning, dbaas, em12c, private cloud, snap clone

[This is a repost of my original blog on Oracle blog from about a year ago.]

Lets look at a relatively new feature in EM that has generated significant interest in a very short time – EM 12c DBaaS Snap Clone.

The ‘Oracle Cloud Management Pack for Oracle Database’ a.k.a
the Database as a Service (DBaaS) feature in EM 12c has grown tremendously
since its release two years ago.  It started with basic single instance and RAC database provisioning, a technical service catalog, an out of box self service portal, metering and chargeback, etc. But since then we have added provisioning of schemas and pluggable databases, add/remove of Dataguard standby databases, full clones using RMAN backups, and Snap Clone. This video showcases the various EM12c DBaaS features.

This blog will cover one of the most exciting and popular features – Snap Clone. In one line, Snap Clone is a self service approach to creating rapid and space
efficient
clones of large (~TB) databases.

Self Service – empowers the end users (developers, testers, data analysts, etc) to get access to database clones whenever they need it.
Rapid – implies the time it takes to clone the database. This is in minutes and not hours, days, or weeks.
Space Efficient – represents the significant reduction in storage (>90%) required for cloning databases

Customer Scenario

To best explain the benefits of Snap Clone, let’s look at a Banking customer scenario:

  • 5 production databases total 30 TB of storage
  • All 5 production databases have a standby
  • Clones of the production database are required for data analysis and reporting
  • 6 total clones across different teams every quarter
  • For security reasons, sensitive data has to be masked prior to cloning

Based on the above scenario, the storage required, if using traditional cloning techniques, can be calculated as follows:

5 Prod DB                  = 30 TB
5 Standby DB            = 30 TB
5 Masked DB             = 30 TB (These will be used for creating clones)
6 Clones (6 * 30 TB) = 180 TB
——————
Total                           = 270 TB
Time = days to weeks

As the numbers indicate, this is quite horrible. Not only 30 TB turn into 270 TB, creating 6 clones of all production databases would take forever. In addition to this, there are other issues with data cloning like:

  • Lack of automation. Scripts are good but often not a long term solution.
  • Traditional cloning techniques are slow while, existing storage vendor solutions are DBA unfriendly
  • Data explosion often outpaces storage capacity and hurts ITs ability to provide clones for dev and testing
  • Archaic processes that require multiple users to share a single clone, or only supports fixed refresh cycles
  • Different priorities between DBAs and Storage admins

Snap Clone to the Rescue

All of the above issues lead to slow turnaround times, and users have to wait for days and weeks to get access to their databases. Basically, we end up with competing priorities and requirements, where the user demands self service access, rapid cloning, and the ability to revert data changes, while IT demands standardization, better control, reduction in storage and administrative overhead, better visibility into the database stack, etc.

EM 12c DBaaS Snap Clone tries to address all these issues. It provides:

  • Rapid and space efficient cloning of databases by leveraging storage copy-on-write (or similar) technology
  • Supports all database versions from 10g to 12c
  • Supports various storage vendors and configurations NAS and SAN
  • Lineage and association tracking between clone master and its various clones and snapshots
  • ‘Time Travel’ capability to restore and access past data
  • Deep visibility into storage, OS, and database layer for easy triage of performance and configuration issues
  • Simplified access for end user via out-of-the-box self service portal
  • RESTful APIs to integrate with custom portals and third party products
  • Ability to meter and charge back on the clone databases

So how does Snap Clone work?

The secret sauce lies in the Storage Management Framework (SMF) plug-in. This plug-in sits between the storage system and the DBA, and provides the much needed layer of abstraction required to shield DBAs and users from the nuances of the different storage systems. At the storage level, Snap Clone makes use of storage copy-on-write (or similar) technology. There are two options in terms of using and interacting with storage:

1. Direct connection to storage: Here storage admins can register NetApp and ZFS storage appliance with EM, and then EM directly connects to the storage appliance and performs all required snapshot and clone operations. This approach requires you to license the relevant options on the storage appliance, but is the easiest and the most efficient and fault tolerant approach.

2. Connection to storage via Solaris file system (ZFS): This is a storage vendor agnostic solution and can be used by any customer. Here instead of connecting to storage, the storage admin mounts the volumes to a Solaris server and format it with ZFS file system. Now all snapshot and clone operations required on the storage are conducted via ZFS file system,. The good thing about this approach is that it does not require thin cloning options to be licensed on the storage since ZFS file system provides these capabilities.

For more details on how to setup and use Snap Clone, refer to a previous blog post.

Now, lets go back to our Banking customer scenario and see how Snap Clone helped then reduce their storage cost and time to clone.

5 Prod DB                      = 30 TB
5 Standby DB                 = 30 TB
5 Masked DB                 = 30 TB
6 Clones (6 * 30 TB)      = 180 TB
6 Clones (6 * 5 * 2 GB) = 60 GB
——————
Total                               = 270 TB 90 TB
Time = days to weeks minutes

Assuming the clone databases will have minimal writes, we allocate about 2GB of write space per clone. For 5 production databases and 6 clones, this totals to just 60GB in required storage space. This is a whopping 99.97% savings in storage. Plus, these clones are created in matter of minutes and not the usual days or weeks. The product has out-of-the-box charts that show the storage savings across all storage devices and cloned databases. See the screenshot below.

Snap Clone Savings

Where can you use Snap Clone databases?

As i said earlier, Snap Clone is most effective when cloning large databases  (~TBs). Common scenarios we see our customers best use Snap Clone are:

  • Application upgrade testing. For example, EBusiness suite upgrade to R12.
  • Functional testing. For example, testing using production datasets.
  • Agile development. For example, run parallel development sprints by giving each sprint its own cloned database.
  • Data Analysis and Reporting. For example, stock market analysis at the close of market everyday.

Its obvious that Snap Clone has a strong affinity to applications, since its application data that you want to clone and use. Hence it is important to add that the Snap Clone feature when combined with EM12c middleware-as-a-service (MWaaS) can provide a complete end-to-end self service application deployment experience. If you have existing portals or need to integrate Snap Clone with existing processes, then use our RESTful APIs for easy integration with third party systems.

In summary, Snap Clone is a new and exciting way of dealing with data cloning challenges. It shields DBAs from the nuances of different storage systems, while allowing end users to request and use clones in a rapid and self service fashion. All of this while saving storage costs. So try this feature out today, and your development and test teams will thank you forever.

Additional References

Cloud Management Page on OTN

Cloud Administration Guide (Documentation)

Enterprise Manager 12c Database-as-a-Service Snap Clone Overview (Presentation)

Limit User Access to Oracle Private Database Cloud Portal

02 Monday Mar 2015

Posted by adeeshfulay in Database as a service, oracle enterprise manager, private cloud

≈ Leave a comment

Tags

database as a service, dbaas, em12c, private cloud

When implementing Database as a Service (DBaaS) and/or Snap Clone, a common request was for a way to hide the other service types like IaaS, MWaaS, etc from the self service portal for the end users. Before EM12c R4, there was no way to restrict the portal view. Essentially, any user with the EM_SSA_USER role would be directed to the self service portal and would then be able to see all service types supported by EM12c.

Of course, you could always set Database as your default self service portal from the ‘My Preferences’ pop up, but this only helps with their post-login experience. The end user still gets to see all the options as shown in screen above.

In EM12c R4, a new out of the box role called EM_SSA_USER_BASE has been introduced. This role, by default, does not give access to any portal, that is an explicit selection. Here is how you use this role:

1. Create a custom role and add the EM_SSA_USER_BASE role to it.

2. Now in the Resource Privileges step, select the Resource Type ‘Cloud Self Service Portal for Database’, and edit it

3. Check the ‘Access the Cloud Self Service Portal for Database.’ privilege. Finish the rest of the wizard.

Now, when a user with this custom role accesses the self service portal, they can only do so for databases and nothing else.

While the EM_SSA_USER role will continue to work, we recommend you start using the new EM_SSA_USER_BASE role. For more details on DBaaS or Snap Clone roles, refer to the cloud admin guide chapter on roles and users.

Convert Crontab to Enterprise Manager Jobs

02 Monday Mar 2015

Posted by adeeshfulay in job system, oracle enterprise manager

≈ 3 Comments

Tags

Automation, crontab, em12c, job system

Surprisingly, a popular question posted on our internal forum is about the possibility of using the Enterprise Manager (EM) Job System to replace customer’s numerous cron jobs. The answer is obviously YES! I say surprisingly because the EM Job system has been in existence for around 10 years (I believe since EM 10.2.0.1), and my hope was that, by now, customers would have moved to using more enterprise class job schedulers instead of cron. So, here is a quick post on how to get started with this conversion from cron to EM Jobs for some of our new users.

Benefits of EM Job System

Before we learn about the how, let’s look at the why. The EM job system is:

  • Free – (Yes, I said free) It is included with the base EM at no cost.
  • Flexible – It supports multiple options for scheduling, notification, authentication, etc
  • Infinitely scalable – the job system seamlessly scales to every new Oracle Management Server (OMS). In fact, in case of OMS failures, the job steps are automatically picked up by the next available OMS without affecting the job execution.
  • General purpose – General purpose since it provides numerous out-of-the-box job types like run OS command, start/stop, backup, SQL Script, patch, etc that span multiple target types. As of today, there are over 50 job types available in the product.
  • Enterprise grade – It allows users to automate multiple administrative tasks like backup, patching, cloning, etc across multiple targets. Customers have not only converted their cron jobs to EM, but have also replaced other enterprise tools like Autosys and migrated 1000s of jobs to EM Job System.
  • APIs – Jobs can be scheduled and managed from the UI and using EMCLI (the command line interface).

Now back to our topic.

The Conversion Process

Let’s start with a sample crontab that we want to convert.

Sample Crontab

A cron expression consists of 6 fields, where the first 5 fields represent the schedule, while the last field represents the command or script to run.

 Field Name Mandatory?  Allowed Values  Allowed special characters
 Minutes Yes 0-59  * / , –
 Hours Yes  0-23  * / , –
 Day of month Yes  1-31 * / , – ? L W
 Month Yes  1-12 or JAN-DEC * / , –
 Day of week Yes  0-6 or SUN-SAT * / , – ? L #

Cron jobs run on the operating system, often using the native shell or other tools installed on the operating system. The equivalent of this capability in Enterprise Manager is the ‘OS Command’ job type. Here are the steps required to convert the first entry in the crontab to an EM job:

1. Navigate to the Job Activity page
Job activity menu

2. Select the ‘OS Command’ job and click Go
OS Command

A 5-tab wizard will appear. Let’s step through this one by one.

3. Select the first tab called ‘General’. Here provide a meaningful name and description for the job. Since this job will be run on the Host target, keep the target type selection as ‘Host’. Next, select all host targets in EM that you wish to run this script against.

While cron jobs are defined on a per host bases, in EM a job definition can be run and managed across multiple hosts or groups of hosts. This avoids having to maintain the same crontab across multiple hosts.

General

4. Select the ‘Parameters’ tab. Here enter the command or script as specified in the last field of the crontab entry. When constructing the command, you can make use of the various target properties.
Parameters tab

5. Next select ‘Credentials’. Here we provide the credentials required to connect to the host and execute the required commands or scripts. Three options are presented to the user:

  • Preferred – default credential set for the host
  • Named – Credentials are stored within Enterprise Manager as “named” entities. Named credentials can be a username/password, or a public key-private key pair. Here we choose pre-created named credentials
  • New – This allows us to create and use new named credential

Note: If your OS user does not have the required privileges to execute the set command, Named Credentials also support use of sudo, powerbroker, sesu, etc.

Credentials tab

6. Next, we set the schedule and this is where it gets interesting. As discussed before, crontab uses a textual representation for the schedule, while EM Job system has a graphical representation for the schedule.

Our sample schedule in the crontab is ‘00 0 * * Sun’. This translates to a weekly job at 12 midnight on every Sunday. To set this in EM, choose the ‘Repeating’ schedule type. The screenshot below shows all the other selections.
Schedule tab

The key here is to select the correct ‘Frequency Type’, the rest of the selections are quite obvious. This also lets you choose the desired timezone for the schedule. Your options are to either start the job w.r.t a fixed timezone, or start it in individual target’s timezone. The latter is very popular, for example, I want to start a job at 2 AM local time in every region around the world.

Another selection of note is that for ‘Grace Period’. This is an extremely powerful feature, but often not used by many customers. Typically, we expect jobs to be started within a few seconds or minutes (based on the load on the system and number of jobs scheduled) of the start time, but a job might not start on time for many reasons. The most common reasons are the Agent being down or due to a blackout. The grace period controls the latest start time for the job in case the job is delayed, else its is marked as skipped. By default, jobs are scheduled with indefinite grace periods, but I highly recommend setting a value for it. In the sample above, I set a 3 hr limit which may seem large but given the weekly nature of the job seems reasonable. So the job system will wait until 3 am (the job start time is 12 am) to start the job, after which the iteration will be skipped. For repeating schedules, the grace period should always be less than the repeat interval. If the job starts on time, the grace period is ignored.

7. Finally, we navigate to the ‘Access’ tab. This tab has two parts:

  • Privilege assignment to roles and users: this allows you to control job level access for other users
  • Email notifications for the Job owner: this allows you to control the events for which you wish to receive notifications. Note, this only sets notification for the job owner, the other users can subscribe to emails by setting up notification and/or incident rules.

To prevent EM from sending deluge of emails, I recommend the following settings in the notifications region:

  • Match status and severity: Both
  • Select severity of status: Critical
  • Select status: Problems & Action Required

You can always come back and modify these settings to suit your needs.

Access tab

Not all cron jobs need to be converted to OS command. For example, if you are taking Oracle database backups using cron, then you probably want to use the out-of-the-box  job type for RMAN scripts. Just provide the RMAN script, list of databases to run this against, and the credentials required to connect to the database. Similarly, if you run sqls on numerous databases, you can leverage the SQL Script job type for this purpose. There are over 50 job types available in EM12c, all available for use from the UI and EMCLI.

Finally, the best way to learn more about the EM Job System is to actually play with it. I also recommend blogs from Maaz, Kellyn, and other users on this topic. Good luck!!

References

Maaz Anjum: http://maazanjum.com/2013/12/30/create-a-simple-job-for-a-host-target-in-em12c/
Kellyn Pot’vin: http://dbakevlar.com/

EM12c Release 4: Job System Easter Eggs – Part 2: Export/Import of Job Definitions

02 Monday Mar 2015

Posted by adeeshfulay in job system, oracle enterprise manager

≈ 1 Comment

Tags

Automation, em12c, job system

This is part 2 of my two part blog post on
Job System Easter Eggs (hidden features). The two features being covered are:

  1. New Job progress tracking UI
  2. Import/Export of job definitions

In the previous post, I talked about the new UI while in this post I will cover import and export for job definitions.

2.  Import/Export of job definitions

The ability to export and import job definitions across EM environments has been a popular enhancement request for quite some time. There are 3 primary drivers:

  • Test to Production: Moving active and library job definitions from test site to production
  • Migration: Move job definitions across EM versions. This is often used as an alternative to upgrade.
  • As Failsafe: For that extra protection, in addition to repository backups. This can be useful for selective restoration of job definition.

In the first iteration, we are exposing these functions as emcli verbs.  Since these emcli verbs are not formally supported in the release, no documentation is included in the EMCLI Reference Guide. So to learn more about them,
we will have to look at emcli help. The two verbs are called
export_jobs, and import_jobs.

>> ./emcli help | grep _jobs

Some salient points about the import & export verbs are.

Export:

  • Rich filter criteria to form the list of jobs to export
  • Active and Library jobs can be exported
  • Preview mode, to view results before exporting them
  • Job definitions are exported as zip files for ease of transfer
  • Contextual information like targets, credentials, access settings, etc is exported, but not imported. In future, we may be able to support import for this information as well.
  • System jobs and nested jobs are not exported

Import:

  • Special Preview mode to view contents of the exported file, and to determine possible conflicts during import
  • Rich filter criteria to selectively import job definitions from the exported file
  • Job definitions are imported to the library ONLY. This is true even if an active job was exported
  • Two failure modes – skip on error, and rollback on error
  • Import only works on same or higher version of EM12c. The patch set number matters.

Export Job Definitions

Let’s walk through an example.

1. We start with export_jobs. The help for this verb will show you all the available options. Most of the filters are self explanatory, so i will skip the explanation. The most important option of all is the -preview flag. This when used in conjunction with other filters, will show results without exporting the job definitions.

>> ./emcli help export_jobs

emcli export_jobs
[-name=”job name1;job name2;…”]
[-type=”job type1;job type2;…”]
[-targets=”tname1:ttype1;tname2:ttype2;…”]
[-owner=”owner1;owner2;…”]
[-preview]
-export_file=<Zip filename that will be created>”
-libraryjobs

2.  Now lets play with this verb. If we invoke the verb with just the -preview flag, it will list all job definitions that can be exported both that are active, and from the library. Note: system jobs and nested jobs are skipped from this output.

>> ./emcli export_jobs -preview

Not all job types are exportable. To determine the list of job types supported via the import and export verbs, use the get_job_types verb.

>>  ./emcli get_job_types

Currently, there are over 50 job types supported, and this list will continue to grow with every release.

3. From the list above, I am primarily interested in jobs that are created by the user AFULAY. So I apply the -owner filter.

>> ./emcli export_jobs -owner=AFULAY -preview

In this output i see 2 jobs, ‘Library Job’ which is a simple OS command job stored in the job library, while the ‘Test Job’ is an active OS command job scheduled against a bunch of targets.

Note: if multiple options are specified, like -name and -owner, then these are ANDed together.

4. Since i am the lazy kind, i would rather export every thing and then later decide what i wish to import. So here it goes. The -export_file option takes the location and file name for the export file. Note the actual output file is an xml that contains job metadata, but the export file is always archived and stored in a zip format. At this time, I am sure most would instinctively unzip the file and start perusing through its contents, but doing so would be analogous to removing the warranty void sticker of your new TV or Blue Ray player. Basically, attempts to manually modify the contents of the exported zip file is highly discouraged.

>> ./emcli export_jobs -export_file=/tmp/afulay_alljobs.zip

Note how the status column reports success or failure for each job being exported. With the file exported, we now move on to the import verb.

Import Job Definitions

In the previous section, we exported a file with all job definitions in it. Now lets say we share this file with bunch of other admins and ask them to import whatever job definitions that make sense or are relevant to their environment.

1. To understand the capabilities of the import verb, we take a look at the help content.

>> ./emcli help import_jobs

emcli import_jobs
[-name=”job name1;job name2;…”]
[-type=”job type1;job type2;…”]
[-targets=”tname1:ttype1;tname2:ttype2;…”]
[-owner=”owner1;owner2;…”]
[-preview]
[-force]
[-stoponerror]
-import_file=<Zip filename that contains job definitions>”

Most of the options are quite similar to export_jobs barring a few. The -force flag allows the admin to update an existing job definition. Typically, you will run into these situations when a conflicting job is found in the new environment, and you want to either update its definition with the new version in the import file or overwrite the localized changes. The -stoponerror flag, when specified, will stop the import process on first encountered failure, and then rollback all jobs imported in the session. We will likely change this label to rollbackonerror to correctly represent its behavior. The default behavior is to skip failed jobs and continue importing others.

2. Before our admins import job definitions, they first need to view the contents of the exported file. This again can be done using the -preview option.

>> ./emcli import_jobs -preview -import_file=/tmp/afulay_alljobs.zip

The -preview option in the import verb is very special. It not only just lists the contents of the exported file, but also connects to the new EM environment and looks for potential conflicts during import. So this is a deep validation test. As seen in the above screenshot, there are two sections in the output, first is just a listing of all job definitions from the import file, while the second is a list of all conflicts. Note: for demo sake, i am exporting and importing to the same EM site, and hence every job shows up as a conflict. To address this issue, i will eventually delete the ‘Library Job’ from my job library, and import it from the import file.

Disclaimer:

In the interest of full disclosure, i should mention that there are few known bugs for the import verb, hence the rationale for not releasing these verbs formally with EM12c R4. Some bugs i ran into when writing this blog were:

  • you cannot export an active job, delete it, and import it back to the same EM environment, this currently is only possible with library jobs.  This is an obscure case though.
  • The -force flag is a little flaky, so sometimes it wouldn’t force import even if you want it to
  • The -owner flag does not work on the import file, it instead will throw an exception

That said, when the job does get imported, it does so properly, so there is never any risk of metadata corruption.

3. If i try to import the ‘Library Job’, the verb will fail and give me an error message.

>> ./emcli import_jobs -name=’LIBRARY JOB’ -import_file=/tmp/afulay_alljobs.zip

The Status column reports Error, while the Notes column gives the reason as ‘job already exists’.

4. Now lets delete the library job and try to import it.

>> ./emcli delete_library_job -name=’LIBRARY JOB’

>> ./emcli import_jobs -name=’LIBRARY JOB’ -import_file=/tmp/afulay_alljobs.zip

Success!!We were able to delete the library job, and import it back from the import file.

In summary, there two very useful enhancements made in EM12c R4. Unfortunately, due to time constraints and our inability to meet the set quality standards, we decided to ship these features in disabled state. This ensures that production sites and users are not impacted, while still giving the few brave souls the opportunity to test these features. In my assessment, i have found the new UI to be fairly robust as i have been using this exclusively for a while. On the other hand, there are few known bugs with the import and export emcli verbs, so use these with caution.

EM12c Release 4: Job System Easter Eggs – Part 1: New Progress Tracking UI

02 Monday Mar 2015

Posted by adeeshfulay in job system, oracle enterprise manager

≈ 2 Comments

Tags

Automation, em12c, job system

So you just installed a new EM12c R4 environment or upgraded your existing EM environment to EM12c R4. Post upgrade you go to the Job System activity page (via Enterprise->Job->Activity menu) and view the progress details  of a job. Well nothing seems to have changed, its the same UI, the same multi-page drill down to view step output, same no. of clicks, etc. Wrong! In this two part blog post, i talk about two Job System Easter Eggs (hidden features) that most of you will find interesting. These are:

  1. New Job progress tracking UI
  2. Import/Export of job definitions

So before i go any further, let me address the issue of why are these features hidden? As we were building these features, we realized that we would not be ready to ship the desired quality of code by the set dates. Hence, instead of removing the code, it was decided to ship it in a disabled state so as not to impact customers, but still allowing a brave few to experiment with it and provide valuable feedback.

1.  New Job Progress Tracking UI

The job system UI hasn’t changed much since its introduction almost 10 years ago. It is a daunting task to update all the job system related UIs in a single release, and hence we decided to take a piecemeal approach instead. In the first installment, we have revamped the job progress tracking page.

Old Job Progress Tracking UI

The current UI, as shown above, while being very functional, is also very laborious. Multiple clicks and drill downs are required to view the step output for a particular target. Also, any click leads to complete page refresh, which leads to wastage of time and resources. The new UI tries to address all these concerns. It is a single page UI, which means no matter where you click, you never leave the page and thus never lose context of the target or step you where in. It also significantly reduces the no. of clicks required to complete the same task as in the current UI. So lets take a look at this new UI.

First, as i mentioned earlier, you need to enable this UI. To do this, you need to run the following emctl command from any of the OMS:

./emctl set property -name oracle.sysman.core.jobs.ui.useAdfExecutionUi -value true

This command will prompt for the sysman password, and then will enable the new UI.

NOTE: This command does not require a restart of the OMS. Once run, the new UI will be enabled for all user across all OMSes.

EMCTL Output

Now revisit the job progress tracking page from before. You will be directed to the new UI.

New Job Progress Tracking UI

There are in all 6 key regions on this new single page job progress tracking UI. Starting from top left, these are:

  1. Job Run Actions – These are actions that can be performed on the job run like suspend resume, retry, stop, edit, etc.
  2. Executions – This region displays all the executions in the job run. An execution, in most cases, represents a single target and hence runs independently from other executions. This region thus shows the progress and status of all executions in a single view. The best part of this region is the column titled ‘Execution Time’. The cigar chart in this column represents two things – one, the duration of the execution, and two, the difference in start times. The visual representation helps in identifying runaway executions, or just compare execution times across different targets. The Actions menu allows various options like start, stop, debug, delete, etc.
  3. Execution Summary – Clicking on an execution in the above region, paints the area on the right. This specific region shows execution summary with information like status, start & end date, execution id, command, etc
  4. Execution Steps – This region lists the steps that make up the execution.
  5. Step Output – Clicking on a step from the above region, paints this region. This shows the details of the step. This includes the step output and the ability to download it to a text file.
  6. Page Options – We imagine that learning any new UI takes time, and hence this final region provides the option to switch between the new and the classic view. Additionally, this also allows you to set the auto refresh rate for the page.

Essentially, considering that jobs have two levels – executions and steps, we have experimented with a multi-master style layout. EM has never used such a layout and hence there were concerns raised when we chose to do so.

Master 1 (region 2) -> Detail 1 (regions 3, 4, & 5)

Master 2 (region 4) -> Detail 2 (region 5)

In summary, with this new UI, we have been able to significantly reduce the no. of clicks required to track job progress and drill into details. We have also been able to show all relevant information in a single page, thus avoiding unnecessary page redirection and reloads. I would love to hear from you if this experiment has paid off and if you find this new UI useful.

In the next part of this blog i talk about the new emcli verbs to import and export job definitions across EM environments. This has been a long standing enhancement request, and we are quite excited about our efforts.

Oracle Private Database Cloud REST APIs

27 Friday Feb 2015

Posted by adeeshfulay in Database as a service, oracle enterprise manager, private cloud

≈ 7 Comments

Tags

apis, Automation, database as a service, dbaas, em12c, private cloud

While we spend a lot of time developing GUI for our private cloud features – like the self service portal, setup screens, etc, a large percentage of our customers use these features via our APIs, both EMCLI and REST based.

Q: So why would anyone not use the out of the box cloud (self service) portal and use the APIs instead?

A: Well, there are many reasons:

  1. You already have a custom cloud portal that you use to deploy non-Oracle products and now you would like Oracle products to be part of it
  2. You want cloud related actions to be part of a larger orchestration flow. For example, prior to provisioning, you want to integrate an approval workflow, and then post-provision update your asset management system with the service details.
  3. You want to integrate the cloud actions with our IT service desk or ticketing systems
  4. Integrate actions like cloning of databases (Snap Clone), or provisioning of middleware and applications with your continuous integration or devops process.

I am sure there are more reasons, but this list should do for now.

Q: What kind of APIs does EM12c expose?

A: Typically, we identify two key roles in the Private Cloud space:

  1. Service Providers – This role represents the various administrators like DBAs, sysadmins, storage admins, etc that help setup and manage the private cloud infrastructure. EM12c provides EMCLI verbs and RESTful APIs for all actions that can be performed by this role.
  2. Service Consumers – This role represents the users who request and consume cloud based services like databases, VMs, middleware servers, etc. This role can access the cloud services from either the out-of-the-box cloud portal, or using RESTful APIs.

This blog post is focused on the the RESTful APIs provided for Service Consumers. The best way to understand and learn about these APIs is to see them in action. In the video below, i explain the various concepts (note i assume that you are already familiar with EM12c DBaaS concepts, if not check the references section), demo the cloud portal, and then perform the same actions using RESTful APIs. The demo is approx. 23 minutes long, so grab a drink before you get started.

The Python script used to demo the APIs can be found here. Note: i am posting this script as sample implementation, so there is no formal support available for it. Also, the demo was recorded on the latest version of EM – EM12c R4 Plugin Update 1.

Finally, I am often asked about customer examples. Till date, i have seen customers use our REST APIs from Chef recipes, shell scripts using the curl command, from 3rd party tools like Service Now and VMware vCAC, custom Java based applications, etc. Unfortunately, i am not an expert on any of these 3rd party tools, so i probably cannot tell you how the integration was done, but i would be more than happy to help you with the EM REST APIs.

Hopefully this was a good introduction to our EM12c Database as a Service (Private Database Cloud) REST APIs. I encourage you to play with the APIs and post code examples for the benefit of other users.

References:

Screenwatch: Oracle Enterprise Manager 12c: Build Service Catalog with DBaaS

Documentation: Cloud Administration Guide, REST API Chapter

Editing EM12c Jobs in Bulk

25 Wednesday Feb 2015

Posted by adeeshfulay in emcli, job system, oracle enterprise manager

≈ Leave a comment

Tags

em12c, emcli, job system

I recently received requests for suggestions on how to edit EM12c jobs in bulk. The two examples that were presented to me were:

  1. Change the start time of 70+ jobs
  2. Change the oracle home path in 80+ RMAN script jobs

So how do we do this?

Option 1: Log into EM12c, navigate to each and every job, click edit and make the desired changes. This of course gets boring after the 4th job, not to mention the potential for developing carpel tunnel syndrome.

Option 2: The other choice is to scan the EM repository tables and try to update the correct columns. Unfortunately, the EM schema is not that simple to follow and your changes to the repository may not take effect as they haven’t updated all relevant references or have not been called from the correct set of APIs. BTW, this also violates our recommendation to never make changes to the EM schema without specific instructions from Oracle support or development, and has the potential of messing up your repository.

Option 3: This makes use of the job system emcli verbs, and is the only viable solution to the problem. The process would be as follows:

  1. Use emcli verb “describe_job” to dump all required jobs into separate properties files (I am assuming you have list of job names that needs to be edited)
  2. Mass-edit the property files to change the start date or any other parameters you like
  3. Create new jobs using these property files with slightly different names using the emcli verb ”create_job”
  4. Once satisfied with newly created jobs, remove older jobs using “delete_job” emcli verb

Documentation for these verbs can be found here.

Now you could argue that option 3 is not perfect either, and i would give you credit for making that argument. Hence an ER has been filed to provide a formal ‘edit_jobs’ verb which will allow you to edit jobs via emcli either in bulk or in a loop. Until then, hopefully this serves as a good work around.

Monitoring NFS mounted file systems using EM12c

24 Monday Nov 2014

Posted by adeeshfulay in host management, oracle enterprise manager

≈ 4 Comments

Tags

em12c, host management, monitoring, nfs, oracle enterprise manager

A customer recently asked me how they could monitor and alert against all the NFS mounted file systems across their datacenter. Here is a quick guide to do the same.

A. Lets say for starters, all you want to do is view details of all NFS mounted file systems on a single Host target.

Solution:

Navigate to the Host target home page. Access the menu item Host->Storage Details. Switch to the file systems tab and filter the list by NFS. You can now happily view used and total sizes of your file systems.

nfs storage details

B. Now you want to list details of all your NFS mounted file systems across all Host targets.

Solution:

The best way to do this would be to create a report using the published repository view called ‘MGMT$STORAGE_REPORT_NFS‘. The view is rather straight forward and easy to use.

C. While the first two cases were more focused on viewing the information, lets say now you want to set a threshold and actively monitor these NFS file systems.

Solution:

All the data we have viewed so far is collected as a configuration metric, and hence its collection frequency is 24 hrs and you cannot set thresholds against it directly. So for the purposes of active monitoring, we will navigate to the All Metrics page (Host->Monitoring->All Metrics) on the host target and take a look at ‘Filesystem Space Available (%)‘ metric. This metric will allow you to set thresholds and get alerts on file system space usage. Unfortunately, when you view the output of this metric, you will not find any of your NFS mounted file systems. This is because the collection for NFS mounted file systems is disabled by default. To enable this:

1. Go to $AGENT_HOME/sysman/config/emd.properties on the desired set of hosts

2. Add the property EM_MONITOR_ALL_DISKS=true

3. Run $AGENT_HOME/bin/emctl reload agent

Wait about 15 minutes, since that is the default collection interval. Refresh the page and Viola! all your NFS mounted file systems will appear on the all metrics page. Any thresholds set for this metric will now automatically apply to your NFS mounted file systems.

Finally, making the changes on a single agent is simple enough, but doing this manually across 100s of agents is rather tedious. To automate this, go to the Agents page (Setup->Manage Cloud Control->Agents), select the desired agents and click on the Properties button in the toolbar. This will launch a job submission wizard where you can select additional agents. In the parameters tab, find the EM_MONITOR_ALL_DISKS property and set its value to ‘true’, click submit. A job is submitted which takes only a fraction of a second to finish, and takes care of applying the changes to all agents and activating them. More details on this job can be found here.

Enjoy!

– Adeesh Fulay (@AdeeshF)

Download Urls for Self Update Entities in Offline Mode

21 Friday Nov 2014

Posted by adeeshfulay in oracle enterprise manager, Self Update

≈ Leave a comment

Tags

em12c, offline mode, oracle enterprise manager, plugins, self update

Self update in the online mode is fairly easy to use. I mean it is hard to beat a user interface that simply has three primary actions –

  • Check Update – check for latest updates available for download. This also happens automatically every day, so there is no explicit need to use this button.
  • Download – download your favorite update (plug-in, agent, connector, etc) to a local directory in EM
  • Apply – apply the downloaded update to EM

Here is a good overview video for Self Update in Online Mode.

Unfortunately, there are a lot of customers (Federal, Banking, Financial, etc) who are not allowed to use the Online mode due to various security reasons. We did anticipate this and thus designed a complete offline experience for such customers. In a nutshell, the process can be described as follows:

  1. Assuming, your MOS connection settings are set to OFFLINE, a user when clicks on the ‘Check Updates’ button, is shown the download url that can be used to download the metadata required to populate the Self Update UI
  2. Once this archive is downloaded, you can run ’emcli import_update_catalog’ from an agent host or from the OMS to import the metadata
  3. Now you browse through the table of entities, choose your favorite one, and click on the download button. This is just like you would do in the online mode, with the exception that instead of download being kicked off, you would again see a popup with the download url for the payload along with instructions on how to apply them.
  4. Once you download the new archive, run emcli import_update to import the payload into self update from one of the agents or from the OMS host
  5. Finally, we go back to the UI, and apply the entities

While the above looks quite involved, in reality it should take you less than 5 mins (minus the download time) to complete the entire process. This is not bad.

A challenge with the above approach thought is that steps 3-5 have to be repeated for every entity and this can be time consuming. Especially for step 3, you have to click on each interesting entity to determine its download url. While we are working on formally addressing this, here is a quick hack to make your life easier.

In EM12c R4, we introduced an internal view that contains all the relevant information for self update entities and their download url. This view is called gc$selfupdate_entity. That fact that this view is internal means (the usual disclaimers) – firstly, the view has been created for internal consumption by EM, and not by customers, and secondly, we reserve the right to modify this view at any time.

Here are a few useful queries:

1. Every release, whether it is platform or a plug-in release, brings a slew of new entities. Majority of these entities are plug-ins. The following query lists the download urls of all new plug-ins that are in the ‘Available’ state:

SELECT su2.attr4_label,
su2.version,
su2.entity_id,
su2.url
FROM gc$selfupdate_entity su2,
(SELECT su.attr4_label,
MAX(su.version) max_version
FROM gc$selfupdate_entity su
WHERE et_name=’core_emplugin’
AND su.status=’Available’
GROUP BY attr4_label
) max_su
WHERE su2.attr4_label = max_su.attr4_label
AND su2.version       = max_su.max_version
ORDER BY 1;

2. Similarly, this query lists the download urls for all new agents in the ‘Available’ state:

SELECT su2.attr3_label,
su2.version,
su2.entity_id,
su2.url
FROM gc$selfupdate_entity su2,
(SELECT su.attr3_label,
MAX(su.version) max_version
FROM gc$selfupdate_entity su
WHERE et_name=’core_agent_core_image’
AND su.status=’Available’
GROUP BY su.attr3_label
) max_su
WHERE su2.attr3_label = max_su.attr3_label
AND su2.version       = max_su.max_version
ORDER BY 1;

—

Adeesh Fulay (@AdeeshF)

Newer posts →

About Me

Product Manager at CA Technologies
Formerly, at Robin Systems, VMware, Oracle, mValent.

Interests: Startups, Containers, Patriots, Warriors, Python, Problem-solving, Biking,…

Views are my own.

Follow Me

Follow @AdeeshF

View Adeesh Fulay's profile on LinkedIn

Recent Posts

  • Create EM Jobs via EMCLI
  • Create Database using EMCLI Verbs
  • Understanding Docker Images and Layers
  • Linux: Analyze disk space full issues
  • Can Containers Ease Cassandra Management Challenges?

Categories

  • agent (1)
  • Data Clone and Refresh (1)
  • Database as a service (4)
  • Deployment Procedures (1)
  • Docker (2)
  • emcli (6)
  • host management (1)
  • job system (6)
  • Linux (1)
  • oracle enterprise manager (16)
  • private cloud (5)
  • Provisioning (1)
  • Self Update (1)
  • Storage (2)

Archives

  • October 2017
  • September 2017
  • March 2017
  • September 2016
  • May 2015
  • March 2015
  • February 2015
  • November 2014

EM12c Tweets

My Tweets

Create a free website or blog at WordPress.com.

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy
  • Follow Following
    • Musings
    • Already have a WordPress.com account? Log in now.
    • Musings
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...