Steps to configure Oracle Data Guard version 12.2 for a pluggable database

Steps to configure Oracle Data Guard version 12.2 for a pluggable database

This document describes the configuration of the Oracle Data Guard Version 12.2. We will configure a standby for a pluggable database.

My test environment consists of two Linux (OEL 7.3) servers: oradg1 and oradg2. I already created a pluggable database on the server oradg1. The database consists of the following components:

SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT

SQL> set lines 200
SQL> col name forma a20
SQL> select con_id, name,open_mode, restricted from v$pdbs;

CON_ID NAME         OPEN_MODE RES
---------- -------------------- ---------- ---
     2 PDB$SEED        READ ONLY NO
     3 ORCLPDB1        READ WRITE NO
     4 ORCLPDB2        READ WRITE NO

SQL> select PDB_ID,PDB_NAME,CON_ID,STATUS,LOGGING,FORCE_LOGGING from dba_pdbs;

PDB_ID PDB_NAME         CON_ID STATUS LOGGING    FOR
---------- -------------------- ---------- ---------- --------- ---
     2 PDB$SEED             2 NORMAL LOGGING    NO
     3 ORCLPDB1             3 NORMAL LOGGING    NO
     4 ORCLPDB2             4 NORMAL LOGGING    NO

Following tasks will be executed:

  • Configuration the standby database on the server oradg2.
  • Creation / drop a pdb on the primary database and verification what happens on the standby site.
  • Executing the swithover tests.

In my previously post Steps to configure Oracle Data Guard 12.2 for non-multitenant database I created the physical standby for a non-multitenant database using a database creation assistant – dbca (new 12.2 feature). Unfortunately this feature is not available for a pluggable database and we will create a physical standby via RMAN utility.

Weiterlesen „Steps to configure Oracle Data Guard version 12.2 for a pluggable database“

Advertisements

How to configure the WebLogic AdminServer for High Availability

Introduction

The high availability of applications in the WebLogic environment is realized by clustering. Managed servers in the cluster work together. The information about transactions is distributed cluster-wide. If a cluster member fails, another server takes over the tasks of the failed server and executes them. In this way, the applications are kept running without interruption.

The AdminServer is a single point of failure: if the server fails, the Domain is no longer administrable:

– Configuration changes cannot be performed

– The administration console is not available

The managed servers are still running and can continue to work, even if the AdminServer is not available: this requires the activation of MSI (Managed Server Independence) Mode.

How can the AdminSevrer be protected from failure? In this blogpost I will describe all the steps that are necessary to keep your server running safely.

Weiterlesen „How to configure the WebLogic AdminServer for High Availability“