Recently I made a post about how to upgrade the TFA to AHF at Oracle Exadata. For today, the post is about how to upgrade AHF at ODA. The procedure is quite simple, but you need to check where to up it and if everything is up and running.
The new Oracle 21c delivered a new feature for Data Guard Broker called VALIDATE FAST_START FAILOVER. As you can imagine, helps you do validate your configuration and you can check some information at the official doc.
The syntax is simple and has no parameters. Just VALIDATE FAST_START FAILOVER:
DGMGRL> help validate
Performs an exhaustive set of validations for a member
Syntax:
VALIDATE DATABASE [VERBOSE] <database name>;
VALIDATE DATABASE [VERBOSE] <database name> DATAFILE <datafile number>
OUTPUT=<file name>;
VALIDATE DATABASE [VERBOSE] <database name> SPFILE;
VALIDATE DATABASE [VERBOSE] <database name> STRICT
{ TEMP_FILES | FLASHBACK | LOG_FILES_CLEARED | LOG_FILE_CONFIGURATION |
APPLY_PROPERTY | TRANSPORT_PROPERTY | ALL }
[ <strict option> ... <strict option> ];
VALIDATE FAR_SYNC [VERBOSE] <far_sync name>
[WHEN PRIMARY IS <database name>];
VALIDATE NETWORK CONFIGURATION FOR { ALL | <member name> };
VALIDATE STATIC CONNECT IDENTIFIER FOR { ALL | <database name> };
VALIDATE FAST_START FAILOVER;
DGMGRL>
And can be used even with FAST_TART failover disabled:
DGMGRL> VALIDATE FAST_START FAILOVER; Fast-Start Failover: Disabled Protection Mode: MaxAvailability Primary: ora21dg Fast-start failover not possible: Fast-start failover is disabled. Other issues: Fast-start failover threshold may be too low for RAC databases. DGMGRL>
ROOH – Read-Only Oracle Home – is the new way to work with Oracle 21c where the Oracle Home folder is read-only. Now, (besides the previous version like 19c) it is the default for 21c, and this means that some activities need to be changed from now.
Recently I was playing with Data Guard and when I was creating it I passed over two situations: tnsnames and password files. Where they suppose to be placed? Bellow, I will show some examples, but I recommend you to read the official documentation for ROOH to understand all the details and file paths. But basically, you don’t need to touch anymore the Oracle Home to edit files.
With the release of Oracle 21c is time for us to start to check the new features. Besides 21c is an innovative release, it shows what we will use in the future in daily activities. For Data Guard and Broker one new feature is the PREPARE DATABASE FOR DATA GUARD that adjusts the database and some parameters to become primary. Release notes can be checked here.
With the release of the 21c of Oracle Database is time to study new features. The 21c version of Grid Infrastructure (and ASM) was released and an upgrade from orders versions can be executed. It is not a complex task, but some details need to be verified. In this post, I will show the steps to upgrade the Grid Infrastructure to 21c. If you need to upgrade from 18c to 19c you can check my previous post.
The first step that you need to do is plan everything. You need to check the requirements, read the docs, download files, and plan the actions. While I am writing this post, there is no official MOS docs about how to upgrade the GI to 19c. The first place to the procedure is the official doc for GI Installation and Upgrade, mainly chapter 11. And another good example is 19c Grid Infrastructure and Database Upgrade steps for Exadata Database Machine running on Oracle Linux (Doc ID 2542082.1).
So, what you need to consider:
The environment that I am using for this example is:
I personally recommend upgrading your current GI to 19c before upgrade or apply one of the last PSU for your running version. This avoids a lot of errors since most of the know bugs will be patched. Check below my environment:
Quick post for today. Recently needed to upgrade to the last version of Autonomous Health Framework (AHF) from an Exadata running GI 19.5. In this particular case the GI was not even running AHF, but still using the standalone TFA that comes with it. So, here I will show how to upgrade to the last version of AHF and replacing the TFA as well.
My first post of 2021 is just Thank You. Thanks for reading my posts and following me on my social media (Twitter/LinkedIn/Blog). Thanks for all of the 41.000 site access during the last year and for all that attended my sessions at the online events. I hope that was possible to help you with something about Oracle.
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.
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.
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.