Tag Archives: 21c

21c, DG PDB, New Steps

2 Replies

When the DGPDB was released for 21c (at version 21.7) I wrote a blog post about how to use the feature (you can read it here). This was in August of 2022 and since that time, we got small changes and corrections, but with the update 21.12 (patch 35740258) we got new commands like “EDIT CONFIGURATION PREPARE DGPDB”.

Not just that, but Ludovico Caldara (Data Guard PM) recently wrote one blog post about new commands for Data Guard preparation that can be used with Broker. Is an evolution of the commands I covered in one previous blog post.

So, in this post, I will cover the new commands for DG PDB and the changes/improvements that appeared in the last version. It is a long post, but everything is covered here. No gaps or information are missing, all the steps, logs, and outputs are described and documented.

Click here to read more…

21c, DG PDB

1 Reply

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).

Please read my new blog post about the new changes to the process. You can see how the process evolved and it is better. Read it here. 

Click here to read more…

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

1 Reply

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

2 Replies

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

4 Replies

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

4 Replies

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…

21c, VALIDATE FAST_START FAILOVER

Leave a reply

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

3 Replies

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

1 Reply

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

Leave a reply

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…