This detailed technical article explains the set up and scheduling of full and incremental RMAN Database backups for thousands of databases using Enterprise Manager Cloud Control (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 Cloud Control 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.

The article also highlights the advantages of using 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 PDBsin a Container Databaseis that you can easilyset up RMAN backups at theContainer Databaselevel, and yet performPITRat the PDB level. This isa clear technical advantage of the Multi-tenant architectureof 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 use Enterprise Manager 12c more and more. In fact I had personally introduced Enterprise Manager to HDFC bank in India in 2007 for the purpose of their RMAN backups, they started using it for the first time, and today they are a DBaaS-Exadata reference customer who have presented in OOW for the last 2 years.

Thursday Aug 29, 2013

This detailed technical article explains the set up ofOracle Data Guard Standby databasesusing Enterprise Manager Cloud Control 12c, and their management, performance, conversion to snapshot standby, switchover, failover etc. The article also includes the improvementsin Database 12cfor managing standbys via Enterprise Manager using a new database role which is not sysdba.

This book is a solid introduction to EM12c and can be used as a complimentary gift to clients seeking to know more about EM12c and its capabilities. It is written in easy to understand English. Please have a look at the updated chapter of contents:

Thursday Feb 21, 2013

Studies show that many corporations world-wide expect their IT footprint to grow in the coming years. They expect more servers, more databases, more data, and more of everything.

They require more floor space in their data centers, and also the corresponding greater power footprint. Have you heard of a data center where no more servers can be added because the power supply has reached its limit, or the UPS (Uninterruptible Power Supply) can no longer cope? This story is not new.

The growth seems to be endless, and this is fuelled by today's information age, where larger and larger volumes of data need to be stored and distributed to satisfy an ever-growing demand. More applications are coming to use those databases, on more and more application servers.

So for the IT Manager, this will mean more of everything in his/her data center. There may be different hardware platforms, there may be different operating systems (e.g. Solaris, Linux, IBM-AIX, Microsoft Windows), and in each case there may be different versions – such as the different flavors of Linux supplied by different vendors including Oracle Enterprise Linux, Red Hat, SUSE Linux, and so on.

To add to the complexity, nothing placed in production should be treated as static. Software changes in development cycles, enhancements take place, or security/functional issues are found. For almost anything in the IT world, new patches are bound to be released. These will also need to be applied to production, test, reporting, staging, and development environments in the Data Center on an ongoing basis.

For the Database side of things, Oracle releases quarterly a combination of security fixes known as the Critical Patch Update (CPU). Other patches are bundled together and released every quarter in the form of a Patch Set Update (PSU), and this also includes the CPU for that quarter.

Oracle strongly recommends applying either the PSU or the CPU every calendar quarter. If you prefer to apply the CPU, continue doing so. If you wish to move to the PSU, you can do so, but in that case continue only with the PSU.

The quarterly patching requirement, as a direct recommendation from Oracle, is followed by many companies which prefer to have their Databases secured with the latest security fixes. This underscores the importance of patching.

However, if there are hundreds of development, test, staging and production Databases in the Data Center to be patched, the situation quickly turns into a major manual exercise every three months. DBAs and their Managers start planning for the patch exercise in advance, and a lot of resources are allocated to make it happen – with the Administrators working on each Database serially, at times overnight and at times over the weekend.

There are a number of steps involved in patching each Database, such as locating the appropriate patch in My Oracle Support (MOS), downloading the patch, transferring it to each of the target servers, upgrading the OPATCH facility in each Oracle Home, shutting down the Databases and Listeners running from that Home, applying the patch, starting each of the Databases in restricted mode, applying any supplied SQL scripts, restarting the Databases in normal mode, and checking the patch inventory.

These steps have to be manually repeated on every Database Home on every server, and on every Database in that Home. Dull repetition of these steps in patching the hundreds of servers in a data center is a very monotonous task, and it can lead to an increase in human errors.

To avoid these issues inherent in manual patching, some companies decide not to apply the quarterly patches on their Databases. They wait for a year, or a couple of years, before they consider patching, and some even prefer to apply year-old patches instead of the latest patches. This is counter-productive and leads to their Databases being insecure and vulnerable to attacks, since the latest recommended CPUs from Oracle have not been applied.

What then is the solution, to convince these companies to apply patches regularly? If the patching process can be mostly automated (but still under the control of the DBAs), it would reduce the quarterly patching effort to a great extent. Companies would then have the confidence that their existing team of DBAs would be able to manage the patching of hundreds of Databases in a controlled and automated manner, keeping human error to a minimum.

The Database Lifecycle Management pack for Oracle Enterprise Manager Cloud Control 12c is able to achieve this via its Patch Automation capability. We will now look into Patch Automation and the close integration of Enterprise Manager with My Oracle Support.

For the full Oracle Technet article, refer to http://www.oracle.com/technetwork/articles/oem/havewala-patching-oem12c-1864147.html