Tuesday Feb 18, 2014

Monitoring Archive Area % Used on Cluster Databases


One of the most critical events to monitor on an Oracle Database is your archive area. If the archive area fills up, your database will halt until it can continue to archive the redo logs. If your archive destination is set to a file system, then the Archive Area % Used metric is often the best way to go. This metric allows you to monitor a particular file system for the percentage space that has been used. However, there are a couple of things to be aware of for this critical metric.

Cluster Database vs. Database Instance

You will notice in EM 12c, the Archive Area metric exists on both the Cluster Database and the Database Instance targets. The majority of Cluster Databases (RAC) are built against database best practices which indicate that the Archive destination should be shared read/write between all instances. The purpose for this is that in case of recovery, any instance can perform the recovery and has all necessary archive logs to do so. Monitoring this destination for a Cluster Database at the instance level caused duplicate alerts and notifications, as both instances would hit the Warning/Critical threshold for Archive Area % Used within minutes of each other. To eliminate duplicate notifications, the Archive Area % Used metric for Cluster Databases was introduced. This allows the archive destination to be monitored at a database level, much like tablespaces are monitored in a RAC database.

In the Database Instance (RAC Instance) target, you will notice the Archive Area % Used metric collection schedule is set to Disabled.

If you have a RAC database and you do not share archive destinations between instances, you will want to Disable the Cluster Database metric, and enable the Database Instance metric to ensure that each destination is monitored individually.


Tuesday Nov 12, 2013

Automate RAC Cluster Upgrades using EM12c

One of the most arduous processes  in DB maintenance is upgrading Databases across major versions, especially for complex RAC Clusters.
With the release of Database Plug-in  (12.1.0.5.0), EM12c Rel 3 (12.1.0.3.0)  now supports automated upgrading of RAC Clusters in addition to Standalone Databases.

This automation includes:

  • Upgrade of the complete Cluster across the nodes. ( Example: 11.1.0.7 CRS, ASM, RAC DB  ->   11.2.0.4 or 12.1.0.1 GI, RAC DB) 
  • Best practices in tune with your operations, where you can automate upgrade in steps:
    Step 1: Upgrade the Clusterware to Grid Infrastructure (Allowing you to wait, test and then move to DBs).
    Step 2: Upgrade RAC DBs either separately or in group (Mass upgrade of RAC DB's in the cluster).
  • Standard pre-requisite checks like Cluster Verification Utility (CVU) and RAC checks
  • Division of Upgrade process into Non-downtime activities (like laying down the new Oracle Homes (OH), running checks) to Downtime Activities (like Upgrading Clusterware to GI, Upgrading RAC) there by lowering the downtime required.
  • Ability to configure Back up and Restore options as a part of this upgrade process. You can choose to :
    a. Take Backup via this process (either Guaranteed Restore Point (GRP) or RMAN)
    b. Set the procedure to pause just before the upgrade step to allow you to take a custom backup
    c. Ignore backup completely, if there are external mechanisms already in place. 

    Mass Upgrade of RAC using EM12c


High Level Steps:

  1. Select the Procedure "Upgrade Database" from Database Provisioning Home page.
  2. Choose the Target Type for upgrade and the Destination version
  3. Pick and choose the Cluster, it picks up the complete topology since the clusterware/GI isn't upgraded already
  4. Select the Gold Image of the destination version for deploying both the GI and RAC OHs
  5. Specify new OH patch, credentials, choose the Restore and Backup options, if required provide additional pre and post scripts
  6. Set the Break points in the procedure execution to isolate Downtime activities
  7. Submit and track the procedure's execution status. 

The animation below captures the steps in the wizard.  For step by step process and to understand the support matrix check this documentation link.

Explore the functionality!!

In the next blog, will talk about automating rolling Upgrades of Databases in Physical Standby Data Guard environment using Transient Logical Standby.

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
23
24
25
26
27
28
29
30
   
       
Today