Tag Archives: Engineered Systems

Oracle Engineered Systems since 2010

Recently I made a tweet about a new project with Oracle Engineered System (X9M) that remembered me about what I made with these systems until now. So, this opened the opportunity to tell my background and history until now working with these systems. Is not a show-off of ego boost post.

 

Click here to read more…

Fixing Exadata Missing Volumes at LVM

Recently during the Exadata patch, one database node reported an issue during the patchmgr and stopped the patch apply. The error was related to missing volumes (LVDoNotRemoveOrUse) at LVM. During the post, you can check the error, but please take attention that it changes some LVM config file contents. So, check correctly the step executed and (if possible) open pro-active SR to be sure what you will be doing.

Click here to read more…

Duplicate, Restore and ZDLRA

From time to time we need to clone/duplicate some databases and we have several ways to do that, most common are duplicate and restore (with a new name) commands. But when using RMAN catalogs we need to take extra care because we can up lose the backups of the entire database because of the wrong way to do that. And this is even more crucial when using ZDLRA.

You need to choose between The Good and The Bad. Because if you choose wrong you will have troubles with The Ugly. The key factor here is the RMAN/ZDLRA catalog, choose wrong and you will automatically add bad data in the internal catalog tables and if you will try to clean, can delete database backups.

In this post, I will show how correctly clone one database when you are using the RMAN/ZDLRA catalog and the reasons for that. I will show the problems and the collateral effects for ZDLRA when you choose the bad way.

Click here to read more…

ZDLRA, RA_CLIENT_CONFIG_FILE channel parameter

When we are enrolling a database at ZDLRA we need to configure the RMAN channel parameters to point to our definitions like RA_WALLET and CREDENTIAL_ALIAS. The same is done for backup and restore channels. But this can be done in a different way using RA_CLIENT_CONFIG_FILE for ra_library.

Click here to read more…

MOVE_BACKUP and ZDLRA

As I wrote previously, sometimes we need to have long-term/archival backups due to some compliance. And usually, these backups are stores outside (like a vault/bunker) but for sure not at the same datacenter as the database. But how we can do this at ZDLRA?

In my post about COPY_BACKUP, I wrote how to have an external copy of one backup set at ZDLRA. But this is not the best option when we need to archive some backup because it continues to follow the same recovery window as the original backup set. This means that if you need to have some kind of archive for 5 years, you need to define your recovery window (at the policy level) to this window. And for sure this will put high pressure on space usage because all backups will be stored until became obsolete.

So, the best way is to use the KEEP backups from rman. And as I wrote in my previous post, they not interact/broke with the incremental forever strategy. Is possible to generate the keep backup, and using the DBMS_RA.MOVE_BACKUP moves these backups to a filesystem destination (and further you can copy/store) and archive it outside of ZDLRA.

Click here to read more…

KEEP backups and ZDLRA

KEEP backups from rman are used to provide long-term and archival retention. They are used to bypass the default policy retention and are used to sustain some regulations/compliances (like HIPAA, or others) that require archival retention. But with ZDLRA they are treated in a different way. Here I will show how the KEEP backups can impact your backup strategy for ZDLRA.

Click here to read more…

COPY_BACKUP at ZDLRA

As you know, ZDLRA is one appliance dedicated to provides you zero data loss in several (planned and unplanned) outages. All the backups are stored inside of the delta store to be processed, and they are deconstructed, meaning that the rman backup set does not exist (as is the formal backup set file).

But sometimes we need to copy/extract some backups outside of ZDLRA and copy it to the filesystem. Maybe because some regulations/compliances need to store for long-term/archival purposes. But some caveats are important to be explained.

Click here to read more…

ZDLRA + MAA, Protection for Platinum Architecture

The Platinum architecture is the last defined at MAA references and is the highest level of protection that you can achieve for MAA. It goes beyond the Gold protection (that I explained in my previous post) and you can have application continuity even version upgrade for your database.

The image above was taken from https://www.oracle.com/a/tech/docs/maa-overview-onpremise-2019.pdf

Click here to read more…

Patch ODA from 18.3 to 19.8. Part 4 – 19.7 to 19.8

The process of patch ODA is not complicated but requires attention over some steps. The 19.6 version was the first that was possible to patch from 18.8 version, and the version that allows upgrades to newer. If you want to go directly to 19.5 you need to reimage of the appliance. In this post, I will cover the process that I made recently to patch from 18.3 to 19.8 version.

The fourth part covers the upgrade from 19.7 to 19.8. I separate so you can use this as a direct guide from 19.6 to 19.7 if you need to do just this update. Parts of this post are similar to the upgrade from 19.6 to 19.7 that I described in the previous post.

Patch Matrix

The matrix of what can be done can be found at this post from ODA blog, and you can check below:

Another important detail is to check the MOS note ODA: Quick Reference Matrix for Linux Release and Kernel by ODA Hardware Type and Version (Doc ID 2680219.1) and verify if your hardware is still compatible.

Remember that in this process, the ODA will reboot several times, so, you need to inform your teams that databases will be unavailable during the process.

Click here to read more…

ZDLRA + MAA, Protection for Gold Architecture

The Gold architecture for MAA is used to emphasis the application continuity. All the possible outages (planned or no) are protected by Oracle features. Here we are one step further and start to design using multi-site architecture. Data Guard, RAC, Oracle Clusterware, everything is there. But even with these, ZDLRA is still needed to allow complete protection.

The image above taken from https://www.oracle.com/a/tech/docs/maa-overview-onpremise-2019.pdf.

With the MAA references, we have the blueprints and highlights how to protect them since the standalone/single instance until the multiple site database. But for Gold we are beyond RPO and RTO, they are important but application continuity and data continuity join to complete the whole picture.

Click here to read more…