Author Archives: Simon

21c, DG PDB

Since the 21c was public available the Data Guard per Pluggable Database – DG PDB – was intended to be there, but Oracle needed more time to make things work and some weeks ago released the feature with the 21.7 version. Here in this post, I will show to configure it and also how to troubleshoot, and the pitfalls of using it. As usual, all the steps, logs, and outputs are covered here and I hope that it helps you understand the whole DG PDB process.

My environment

The environment that I am using here is:

  • Two databases running in RAC mode (two nodes in each cluster).
  • ASM: same DATA and RECO diskgroups names in each cluster.

About the databases I have:

  • ORADBDC1, that have the pdb PDBDC1. So, they represent the DC1.
  • ORADBDC2, that have the pdb PDBDC2. So, they represent the DC2.

Each of these clusters is in a separate environment, this means that both are primary databases inside each datacenter. So, they have no DG configured between them.

The main target for this post is to have the pdb from DC2 protected by the ORADBDC1 at the DC1. I used RAC and ASM because this is usually the normal configuration for the MAA (following the recommended architectures baseline) when using DG. This increases the protection and reduces the SPOF of your environment.

DG PDB

The idea of DG PDB differs a little from what we see commonly for Data Guard, here each container have own life. This means that only the pdb is protected and not the entire cdb. This puts the DG PDB close to Cloud than On-Prem because it fit perfectly at the OCI structure since you can create your pdb in one region and choose another region to protect it. And even closer if you think for Autonomous Database that your ownership is pdb only. I will not say that is good or not, but is linked to how Oracle works with OCI. Personally, I prefer to have normal DG configured to protect my databases and I choose where I want to open my pdb (maybe they add this feature in the future).

Another detail is that DG PDG (from now) works only in MaxPerformance mode, so, there is no SYNC mode for the archive destinations. There are more limitations for the DG PDB and you can check it in the topic DG PDB Configuration Restrictions from official documentation (I recommend that you read it).

Click here to read more…

21c, Zero-Downtime Oracle Grid Infrastructure Patching – Silent Mode

Recently I made two posts about the process for patch/upgrading your 21 Grid Infrastructure (GI) while the databases continue to be running. The first post shows how to do this using the GUI interface, and the second one show more details about the process for AFD/ACFS Kernel Driver Update. But here in this post, I will show how to do the Zero-Downtime Patch (zeroDowntimeGIPatching – ZDGIP) in silent mode.

This way to do the patch is important because allows you to automatize it. You can create your own script and call it (using Ansible, Puppet, Chief, etc.) to upgrade your servers (or farms) remotely.

Current Environment

The current environment is the same of the first post:

  • OEL 8.4 Kernel 5.4.17-2102.201.3.el8uek.x86_64.
  • Oracle GI 21c, version 21.3 with no one-off or patches installed.
  • Oracle Database 21c, RU 21.5 (with OCW 21.5).
  • TFA version is 21.4 (last available in March 2022).
  • Nodes are not using Transparent HugePages.
  • Is a RAC installation, with two nodes.

You can see the output for the info above in this txt file.

And I will apply the same RU 21.5 (21.5.0.0.220118) for GI which is patch 33531909.

Patch Process

The patch process is almost the same as the first post, the main change is the response file and the way to call the gridSetup.sh. So, for this reason, I recommend for you read the first (and second) post. Below you will see a quick review of previous steps and a focus on the new 

Click here to read more…

21c, updateosfiles after Grid Infrastructure Patch

Recently I made one post about how to use the new feature -zeroDowntimeGIPatching when patching the Grid Infrastructure for 21c. It is a new feature/option that allows your database continues to be running while the grid is patched. You can see my post here. But during that post I talked about the usage of -updateosfiles when calling the rootcrs.sh and want to clarify some details and provide better examples.

Current environment

For this post, my environment is:

  • OEL 8.4 Kernel 5.4.17-2102.201.3.el8uek.x86_64.
  • Oracle GI 21c, version 21.5.
  • Is a RAC installation, with two nodes.

The GI was upgraded from 21.3 to 21.5 as demonstrated in my post.

Compatibility Matrix

Before you think about upgrading the ACFS/AFD drivers you need to check if they are compatible with the version or kernel that you are running. The only place to check this is the MOS note ACFS Support On OS Platforms (Certification Matrix). (Doc ID 1369107.1). On that note, you will see tables for each major version (18c, 19c, 21c), and you can see the versions of Linux Version and Kernel versions that are compatible. Below is marked for OEL 8:

And you can see that my version of Linux Kernel is compatible. If your version is not compatible, not update the ACFS/AFD kernel drivers.

Click here to read more…

Duplicate PDB from active database, ASM, and OMF

Starting with 18c is possible to duplicate one PDB from an active database. This is a cool feature that helps a lot in daily activities. But recently I got one error when the destination is using ASM, and the files (of course) are managed using OMF. The solution is simple and is related to a bug that is affecting the 18c, 19c, and 21c versions.

Duplicating pluggable databases can be done for a long time and have some rules. But the duplicate PDB from an active database to a new CDB helps a lot because everything can be done online. We don’t need to create an intermediate CDB to export this PDB doing the unplug/plug, or cloning the source locally to read-only PDB and create a new one using dblink, or even using rman backups.

Click here to read more…

21c, Zero-Downtime Oracle Grid Infrastructure Patching

Oracle 21c delivered a lot of new features and for Grid infrastructure one of the most interesting is the zero-downtime patch (zeroDowntimeGIPatching). This basically allows your database continues to be running while you patch/upgrade your GI. The official doc can be seen here. Let’s say that is an evolution of the Out of Place (OOP) patch for GI.

In this post I will show how to do that, but some details before starting:

  • This post shows how to do the zero-downtime patch using GUI mode.
  • I will do another post showing how to do in silent mode the same procedure. So, it can be automatized.
  • In a third post, I will detail how the zero-downtime works behind the scenes and will discuss some logs.

Click here to read more…

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…

AHF and TFA Management

Recently I posted about the upgrade of AHF/TAF from version 19 to 21 at Exadata and also for ODA. But with version 21 of AHF, some collections are made automatically and this can impact your space usage. Here you can see how to check this and disable/modify some of these.

The automatic collection for AHF/TFA is a feature that generates the diagnostic packages (to send to Oracle) when some specifics errors appear in the database. The collected errors follow some patterns like ORA-0600, ORA-07445, and several others. The basic idea can be seen in the official doc here and in the image below (retried directly from the official doc).

Click here to read more…

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…