OEM13c – The page has expired. Click OK to continue.

If you are getting an error message or Pop-UP which says “The page has expired. Click OK to continue.” This means that your Cloud Control session has expired or timeout as there was no activity in your session.

The default value for session timeout is 45 minutes. Can we increase this session timeout frame, YES! You can. You set this value as per requirement of your company’s security policy. It may vary for different clients or companies.

As per your requirement you can increase the Session Timeout time by changing the value of “oracle.sysman.eml.maxInactiveTime” parameter. Also note that the value for this parameter is always defined in Minutes. In-my case the requirement was to keep the session active unless the user itself does not logs out from the application. So I set the value of oracle.sysman.eml.maxInactiveTime” parameter to -1. But if let’s say you want the session to be active for 10 hours you can set the value to 600. However if you want your session be active forever like in my case, you can set its value to -1.

NOTE: Zero means that the value is set to default than 45 minutes.

To check which session timeout is currently active, you can deduct the following command.

[oracle@hanoemap1 bin]$ cd –


[oracle@hanoemap1 bin]$ ./emctl get property -name oracle.sysman.eml.maxInactiveTime

Oracle Enterprise Manager Cloud Control 13c Release 2

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

SYSMAN password:

Value for property oracle.sysman.eml.maxInactiveTime at Global level is -1

[oracle@hanoemap1 bin]$


NOTE: This change will need your OMS to restart, if you have multi-OMS environment, you may need to bounce both OMS.

You can also change this property from EM Console if you want. Navigate to Setup -> Manage Cloud Control -> Management Servers.


From Management Servers Home Page, Drop Down Management Servers and click on “Configuration properties”


On Management Server Configuration Properties Page, you can see all the properties listed, along with “oracle.sysman.eml.maxInactiveTime” in our case, highlighted in Yellow.


Click on the property Name, for whom you want to change the value. It will take you to “Set Property” page where you can make the changes.


Make the change in the property value and Click on Save.



Oracle Enterprise Manager Cloud Control 13c Release 2 ( available now

I am not now sure how many of you are aware that Oracle Enterprise Manager 13c Release 2 is available now for those who are not I have mentioned few of the Important URL’s for OEM13cR2 which might help you if you are planning to install or upgrade to this new release.

Certification Matrix of OEM13cR2 for RHEL 6

Download Link for OEM13cR2

OEM Cloud Control Upgrade Guide

Prerequisites for Upgrading to Enterprise Manager Cloud Control 13c Release 2


Soon I’ll be publishing new post Step by Step Upgrade guide to Cloud Control 13c Release 2.




Offline Database Patching in OEM12c


This is the step by step document of how you do database patching from OEM. Before we start I’ll just give small introduction about Patching in OEM.

There are two different methods by which we can do patching in OEM:

● Out-Of-Box Patching

● In-Place Patching

Out-Of-Box patching is the recommended method by Oracle, the advantage of using this method is that it reduces your downtime. On the contrary you need to have some extra (almost double to you ORACLE_HOME) space on your disk as this method CLONE your ORACLE_HOME so that in case of failure revert back is easily possible.

In-Place patching is also known as Offline patching, in this method downtime is more as compare to Out-Of-Box patching. So if you have planned maintenance window you can easily adopt this method.

In this blog we will be performing In-Place patching. So let’s see what are some prerequisites required before patching your database.


Required Roles and Permission:





Step 1: Create Normal and Privilege Credentials for Host

Before we start with the patching process make sure we have “Normal and Privilege” credentials set. Login to OEM console and create Normal and Privilege credentials if already not created.

Navigate to “Setup -> Security -> Named Credentials ”


Click on Create and put the required Details.



Make sure you TEST credentials before you SAVE them. So that the credentials are validated.




Step 2: Download Patches and Upload them to Software Library.

Download the patches to be applied from MOS and upload them to Software Library. Navigate to “Enterprise -> Provisioning and Patching -> Saved Patches” and follow the below mentioned steps.








Step 3: Check Recommended Patches and their details.

In order to check the recommended patches and details about them. Login to OEM using your credentials and Navigate to “Patching” Home Page as shown in the screenshot below. (Enterprise -> Provisioning and Patching -> Patches & Updates)




Patch Recommendations Details are shown on this homepage in the bottom left corner. (Classification View)




You can either see the details by selecting Classification View as shown in the above screenshot or by Target View as shown below. Else we also have “All Recommendations” link as well which will show all details together.

(Target View)



Click on “Database Instance” to check recommended patches. Patches are displayed in the form of table with details like Patch Name, Description, Release, Platform etc.

If you further want to check information for specific patch, select the particular patch row and further details like SPU’s include, Bugs resolved will be displayed below. You will also get the option to download the patch or add to Patch Plan.




If you click on “All Recommendation” link on the “Patches & Updates” Home page you will get something like this . All patches for different targets clubbed together in single table.




Particular Patch Details

Click on single row to check the details about that patch.




Step 4: Create a Patch Plan and add patches

After we have confirm the patches to be applied and their details. Next step is to add particular patch to a Patch Plan. Select a particular row and Click on “Add to Plan” followed by “ Add to New ” as shown in the below screenshot.




Create New Plan pop-up window will open, please enter a meaningful name and click on “Create Plan” button.




Now Click on “View Plan” to check the Plan details.




Step 5: Deploy Patch

Patch deployment is a 5-step process,

1. Plan Information

2. Patches

3. Deployment Options

4. Validations

5. Review & Deploy

Once you have created a Patch Plan, follow the above mentioned process and step by step and at last deploy the patch.


Plan Information

This step involved Plan description and the permissions, Enter the plan information details followed by granting permissions to existing users.





In this step you can add multiple patches to existing Patch Plan.


You can search the patches in three different ways, using Patch Number, using Advanced Method or by Recommended Patch Advisor.


Deployment Options

This is further multi-step process. Screenshot for each step is show below.

How to Patch {In Place or Out-Of-Box method}

What to Patch {Database Instance Targets details}

Where to Stage {Location of staging directory}

Credentials Information {Host Credentials with sudo permissions}


Notification {Email notifications phase}

Rollback {Rollback option in-case of failure}

Conflict Check {If any existing patch is conflicting}



Select the tested Named Credentials and Privilege Credentials for the host on which you are deploying the Patch. Do not forget to Validate them.

Make sure “Named Credentials and Privilege Credentials” are different if your OEM is as there is BUG reported in OEM12cR4.



Verify effected Database Instance Targets and Staging Directory by default it goes to “%emd_emstagedir%” directory.




Verify Customization, Notification, Rollback and Conflict Options before proceeding further.




Click on the “Analyze” button to start the Validation process, this process can take time depending on the Patches and Targets involved.



Check if any Issue remains even after Validation, Review them and then resolve them before proceeding further.


In-case there is some failures like I got the one shown below during the Review Process, make sure you fix them and then proceed with the “Deployment” process.



Review & Deploy

This is the last option, this page will display all information make sure you review the information thoroughly and if everything looks good click on “Deploy” button to start the deployment process.




Prerequisite for OEM12cR4 to OEM13cR1 upgrade

If you have Oracle Enterprise Manager 12cR3/12cR4/12cR5 running on either RHEL or OEL and you are planning to upgrade your OEM to new release of 13c you must make sure that you meet below mentioned requirements.

I have shortlisted few mandatory and minimum requirements which you should keep in mind  while planning to upgrade to Oracle Enterprise Manager 13c or fresh installation of OEM13cR1.


In my next blog I’ll put the complete step by step document for OEM13cR1 upgrade.

Share your feedback and stay connected for next blog.