Author Archives: Simon

21c, VALIDATE FAST_START FAILOVER

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.

Syntax

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>

Click here to read more…

21c, ROOH

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.

Click here to read more…

21c, PREPARE DATABASE FOR DATA GUARD

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.

Click here to read more…

21c Grid Infrastructure Upgrade

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.

Planning

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:

  • OS version: If it is compatible with 21c and if you are using asmlib or asm filter, check kernel modules and certification matrix.
  • Current GI: Maybe you need to apply some patches. The best practice recommends using the last version.
  • Used features (like AFD, HAIP, Resources): Check compatibilities of the old features with 21c. Maybe you need to remove HAIP or change your crs resources.
  • 21c requirements for GI: Check memory, space, and database versions.
  • Oracle Home patches (for databases running): Check if you need to apply some patches for your database to be compatible with GI 21c.
  • Backup of your Databases: Just in case you need to roll back something.

My environment

The environment that I am using for this example is:

  • Oracle Linux 8.4.
  • GI cluster with two nodes.
  • ASM Filter for disk access.
  • 19.11 for GI.
  • 19.12 for Oracle Home database.

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:

Click here to read more…

Upgrade AHF and TFA at Exadata

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.

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…

Exadata, dracut and LVM locking_type as read-only

Sometimes even a perfectly running server can pass over issues after a simple reboot. And was exactly that occurred recently with one Exadata database node. And was not the first time that the same error appears (and since there is no well-documented step by step to fix it I documented them below). So, check how to fix the issue related to the read-only locking_type of LVM detected by dracut.

Click here to read more…

2020-2021

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.

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…