Pages

Monday, February 12, 2024

Oracle Database TDE in OCI Cloud

 Oracle Database TDE in OCI Cloud vs OnPrem


Oracle's Transparent Data Encryption (TDE) is a powerful data-at-rest encryption feature that can be used to secure Oracle databases in the Oracle Cloud Infrastructure (OCI) environment. TDE provides a robust layer of protection for sensitive data stored in database files, backups, and other storage media.

TDE on-prem is part of advance licensing model which customers need to license separately, where as in Cloud TDE is part of the database license, we can use BYOL for database and TDE is offered as part of the native database license in Cloud. 

This is change in the way licensing is done as in Cloud all the databases are TDE enabled by default and there is no option to skip the TDE in the OCI Cloud.

Leverage TDE benefits in the OCI cloud without need to pay extra licensing :) 

To Recap TDE benefits:

  1. TDE provides a strong layer of data protection by encrypting sensitive data at rest, including database files, backups, and exports.
  2. This helps organizations meet various compliance requirements and industry regulations related to data security, such as PCI-DSS, HIPAA, and GDPR.
  3. In a cloud environment, data is stored on shared infrastructure, and TDE ensures that even if an unauthorized party gains access to the storage media, the data remains encrypted and unreadable.



Monday, January 22, 2024

Oracle Zero Downtime Migration (ZDM) - Installation

Oracle Zero Downtime Migration (ZDM) - Installation


ZDM - Install ZDM 21.4

Requirements:

- Minimum OS version Oracle Linux 7

Install Pre-Req:

[root@zdmhost01]# yum install glibc-devel expect libnsl ncurses-compat-libs

Install ZDM:

[oracle@zdmhost01]# cd /opt/zdmsoftware/zdm21.4.1/

[oracle@zdmhost01]# ./zdminstall.sh setup oraclehome=/opt/app/zdm oraclebase=/opt/app/base

ziploc=/opt/zdmsoftware/zdm21.4.1/zdm_home.zip

oracle@zdmhost01]# cd /opt/zdm21.4.1/app/zdm/bin

oracle@zdmhost01]$ ./zdmservice start

No instance detected, starting zdmservice

spawn /opt/app/zdm/mysql/server/bin/mysqladmin

--defaults-file=/opt/app/base/crsdata/instance-20231111-1137/rhp/conf/my.cnf -u root -p

ping


ZDM - Setting up ZDM Machine

Setup Passwordless SSH.

[oracle@zdmhost01 ~]$ cat .ssh/id_rsa.pub

#on the source database host as user oracle

#Add ZDM public keys in source and target host.

[oracle@sourcedb01 ~]$ vi .ssh/authorized_keys

#insert the public key and save the changes

[opc@targetdb01 ~]$ vi .ssh/authorized_keys

#insert the public key and save the changes

#add the following in source, target and ZDM machines.

[root@zdmhost01 ~]# vi /etc/hosts

#add the following entries

10.10.10.01 sourcedb

10.10.10.02 targetdb

ZDM - Prepare Source Database

Turn on FORCE LOGGING at the primary database.

SQL> alter database force logging;

SQL> select force_logging from v$database;

FORCE_LOGGING

---------------------------------------

YES

-- Enable ARCHIVELOG mode for the database.

SQL> select log_mode from v$database;

LOG_MODE

------------

ARCHIVELOG

-- For Oracle Database 12c Release 2 and later, it is mandatory to configure TDE.

SQL> select wrl_type, status from v$encryption_wallet;

WRL_TYPE STATUS

-------------------- ------------------------------

FILE OPEN

-- Set RMAN CONFIGURE CONTROLFILE AUTOBACKUP to ON.

[oracle@sourcedb01 ~]$ rman target /

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

ZDM - Prepare Target Database

01 Ensure source and Target has different db_unique_name

02 Configure listener in the Target Node.

03 Make sure password file is created and same password for SYS for source and target

04 Set SQL*Net connectivity between source and target database servers.


ZDM - Migration Response File

[oracle@zdmhost01 ~]$ vi /opt/zdmsoftware/physical_online.rsp

MIGRATION_METHOD=ONLINE_PHYSICAL

DATA_TRANSFER_MEDIUM=OSS

HOST=https://cloud.oracle.com/object-storage/buckets/ax6yc1uoj1112/bucket-12234

/objects?region=us-phoenix-1

OPC_CONTAINER=bucket-12234

TGT_DB_UNIQUE_NAME=TARGETDB

PLATFORM_TYPE=VMDB


ZDM - Initiate Migration

[oracle@zdmhost01 ~]$ $ZDMHOME/bin/zdmcli migrate database -rsp /opt/zdmsoftware/physical_online.rsp \

-sourcesid srcdb \

-sourcenode source \

-srcauth zdmauth \

-srcarg1 user:oracle \

-srcarg2 identity_file:/home/oracle/.ssh/id_rsa \

-srcarg3 sudo_location:/usr/bin/sudo \

-targetnode target \

-tgtauth zdmauth \

-tgtarg1 user:opc \

-tgtarg2 identity_file:/home/opc/.ssh/id_rsa \

-tgtarg3 sudo_location:/usr/bin/sudo \

-targethome /u01/app/dbhome \

-backupuser "oracleidentitycloudservice/naresh@xyz.com" \

-eval

Enter source database srcdb SYS password:

Enter user "oracleidentitycloudservice/naresh@xyz.com" password:

zdmhost01: 2023-10-14T07:59:53.865Z : Processing response file ...

Operation "zdmcli migrate database" scheduled with the job ID "1".


ZDM - Check the Status

$ZDMHOME/bin/zdmcli query job -jobid

Job ID: 1

User: oracle

Client: zdmhost01

Job Type: "EVAL"

...

Current status: SUCCEEDED

Current Phase: "ZDM_GET_SRC_INFO"

...

# For checking the eval job id's

$ZDM_HOME/bin/zdmcli query job -eval

# For checking the migrate job id's

$ZDM_HOME/bin/zdmcli query job -migrate

ZDM - Run Actual Migration

[oracle@zdmhost01 ~]$ $ZDMHOME/bin/zdmcli migrate database -rsp

/opt/zdmsoftware/physical_online.rsp \

-sourcesid srcdb \

-sourcenode source \

-srcauth zdmauth \

-srcarg1 user:oracle \

-srcarg2 identity_file:/home/oracle/.ssh/id_rsa \

-srcarg3 sudo_location:/usr/bin/sudo \

-targetnode target \

-tgtauth zdmauth \

-tgtarg1 user:opc \

-tgtarg2 identity_file:/home/opc/.ssh/id_rsa \

-tgtarg3 sudo_location:/usr/bin/sudo \

-targethome /u01/app/dbhome \

-backupuser "oracleidentitycloudservice/naresh@xyz.com" \

-pauseafter ZDM_CONFIGURE_DG_SRC

Enter source database srcdb SYS password:

Enter user "oracleidentitycloudservice/naresh@xyz.com" password:

zdmhost01: 2023-10-14T13:59:53.865Z : Processing response file ...

Operation "zdmcli migrate database" scheduled with the job ID "2".

ZDM - Pause and Complete the Migration

[oracle@zdmhost01 ~]$ $ZDMHOME/bin/zdmcli query job -jobid 2

...

Job Type: "MIGRATE"

...

Current status: PAUSED

SQL> select database_role from v$database;

DATABASE_ROLE

----------------

PHYSICAL STANDBY

# Complete the migration.

[oracle@zdmhost01 ~]$ $ZDMHOME/bin/zdmcli resume job -jobid 2

[opc@target ~]$ sqlplus / as sysdba

SQL> select database_role from v$database;

DATABASE_ROLE

----------------

PHYSICAL STANDBY



Oracle Zero Downtime Migration (ZDM) - Introduction

Oracle Zero Downtime Migration (ZDM) Explained in Detail


What is ZDM?

Oracle Zero Downtime Migration (ZDM) allows you to directly migrate

your Oracle Database to the Oracle Cloud from various Oracle

Database versions into different target cloud deployments depending

on your requirements and business needs.


How does it work?




What Happens in ZDM?


● ZDM software is installed on ZDM host which connects to source
and target to perform the migration process.
● ZDM is tooling on top of Oracle Data Guard, Data Pump and
Goldengate technologies.
● ZDM tooling allows customers to invoke and perform the
migration without knowing the details of the underlying process.
● ZDM has MySQL database to keep track of progress.





ZDM - Before Migration

● ZDM host should be running Oracle Linux 7 or later and latest version of ZDM is 21.4.
● ZDM host can be on-premise or cloud.
● Source database should be Oracle Database 11GR2 (11.2.0.4) or later.
● Source database must be in archive log mode.
● TDE Wallet should be open on PDB and CDB on source DB.
● Target database must be same version as the source database for physical migration.
● Target database to be created before the migration and ready.
● Target database db_name should match with source database.
● Source and target database should have access to object storage.



ZDM - Physical Online Migration

● Backs up the source database to the specified data transfer medium.
● Instantiates a standby database from this backup to the target environment.
● Configures Data Guard with Maximum Performance protection mode and asynchronous
(ASYNC) redo transport mode.
● Synchronizes the source and target databases.
● Switches over to the target database as the new primary database with minimum downtime.


ZDM - Physical Offline Migration (RMAN)

● Zero Downtime Migration can perform a backup and restore operation to achieve an offline
physical migration using RMAN.
● Backs up the source database to the specified data transfer medium.
● Instantiates a new database from this backup to the target environment.
● The offline migration method is similar to cloning a database. The target database has no
relationship to the source, so there is no data synchronization or fallback capability. No
SQL*Net connectivity is needed between the source and target database servers.

*While Standard Edition databases can use Zero Downtime Migration, they must use the

offline migration method which is based on a backup and restore methodology that does

not use Data Guard.



ZDM - Logical Online Migration (GoldenGate)


● Zero Downtime Migration harnesses Oracle GoldenGate and Oracle Data Pump to perform an

online logical migration.

During a logical online migration, the source database remains online for client connections while

data is moved to the target database, using a combination of Oracle Data Pump and Oracle

GoldenGate replication.

Logical online migration involves two steps:

● Instantiation of target database.

● Oracle Data Pump extracts data from the source database and loads it into the target

database.

● Real-time data replication between source and target databases.

ZDM - Logical Offline Migration (DataPump)


 Zero Downtime Migration can perform an offline logical migration using Oracle Data Pump to extract

the data from the source database and load it into a target database.

 Offline logical migration means that the source database is not available for clients while data is

moved to the target database. When using the offline migration method,

 You must stop updates to the source database before you start a migration. When the migration is

complete, the target database and source database do not require any direct SQL*Net connectivity

between them.



Monday, January 8, 2024

High Availability Architecture implementation Commands - Part 2

 High Availability Architecture implementation Commands


  1. Add Application VIP service in Source cluster

Run below commands from the root user.


# $GRID_HOME/bin/appvipcfg create -network=1 -ip="10.10.10.74" \

-vipname gg-sourcedb-vip -user=root -group=oinstall -failback=0





# $GRID_HOME/bin/crsctl modify res 'gg-sourcedb-vip' \

 -attr "HOSTING_MEMBERS=sourcedb01"





# $GRID_HOME/bin/crsctl modify res 'gg-sourcedb-vip' \

-attr "USR_ORA_VIP=10.10.10.74"




# $GRID_HOME/bin/crsctl start resource gg-sourcedb-vip -n sourcedb01





# $GRID_HOME/bin/crsctl stat resource gg-sourcedb-vip -p → This command displays the resource properties.



  1. Add Application VIP service in Target cluster

Run below commands from the root user.


# $GRID_HOME/bin/appvipcfg create -network=1 -ip="10.10.10.75" \

-vipname gg-targetdb-vip -user=root -group=oinstall -failback=0



# $GRID_HOME/bin/crsctl modify res 'gg-targetdb-vip' \

 -attr "HOSTING_MEMBERS=targetdb01"



# $GRID_HOME/bin/crsctl modify res 'gg-targetdb-vip' \

-attr "USR_ORA_VIP=10.10.10.75"


# $GRID_HOME/bin/crsctl start resource gg-targetdb-vip -n targetdb01


# $GRID_HOME/bin/crsctl stat resource gg-targetdb-vip -p → This command displays the resource properties.


  1. Add Goldengate service in Source database.

Note: Run below command from oracle user 


Command to add the goldengate service


$ agctl add goldengate GG_SOURCEDB \

--gg_home /u01/app/oracle/product/gghome \

--use_local_services \

--instance_type source \

--dataguard_autostart no \

--oracle_home /u01/app/oracle/product/db_1/19c \

--critical_extracts EXT,PMP \

--db_services ora.sourcedb.sourcedb_ogg.svc \

--nodes sourcedb01,sourcedb02 \

--vip_name gg-sourcedb-vip \

--filesytems dbfs_mount \

--user oracle \

--group oinstall 


Command to check the Goldengate service Configuration:

$ agctl config goldengate GG_SOURCEDB 

Command to start the Goldengate service on node-1:

$ agctl start goldengate GG_SOURCEDB --node sourcedb01 



Command to relocate the Goldengate service on node-2:

$ agctl relocate goldengate GG_SOURCEDB --node sourcedb02



Command to start the Goldengate service:

$ agctl stop goldengate GG_SOURCEDB



Command to disable the Goldengate service:

$ agctl disable goldengate GG_SOURCEDB



Command to enable the Goldengate service:

$ agctl enable goldengate GG_SOURCEDB



  1. Add Goldengate service in Target database.

Note: Run below command from oracle user 


$ agctl add goldengate GG_TARGETDB \

--gg_home /u01/app/oracle/product/gghome \

--use_local_services \

--instance_type target \

--dataguard_autostart no \

--oracle_home /u01/app/oracle/product/db_1/19c \

--critical_extracts REP \

--db_services ora.targetdb.targetdb_ogg.svc \

--nodes targetdb01,targetdb02 \

--vip_name gg-targetdb-vip \

--filesytems dbfs_mount \

--user oracle \

--group oinstall 



Command to check the Goldengate service Configuration:

$ agctl config goldengate GG_TARGETDB



Command to start the Goldengate service on node-1:

$ agctl start goldengate GG_TARGETDB --node targetdb01 



Command to relocate the Goldengate service on node-2:

$ agctl relocate goldengate GG_TARGETDB --node targetdb02



Command to start the Goldengate service:

$ agctl stop goldengate GG_TARGETDB


Command to disable the Goldengate service:

$ agctl disable goldengate GG_TARGETDB


Command to enable the Goldengate service:

$ agctl enable goldengate GG_TARGETDB



Reference:
https://www.oracle.com/database/technologies/xag-agents-download.html

Tuesday, January 2, 2024

High Availability Architecture implementation Commands - Part 1

 High Availability Architecture implementation Commands:

Environment Details: 


Source Cluster:

 It is two node cluster and Grid Home & database versions are 19c


Node1 → sourcedb01.oracle.com

Node2 → sourcedb02.oracle.com


Source DB Name: sourcedb


Target Cluster:

 It is two node cluster and Grid Home & database versions are 19c


Node1 → targetdb01.oracle.com

Node2 → targetdb02.oracle.com


Target DB Name: targetdb


Installed Goldengate Version: 19

Architecture: Classic Architecture


Source side GG services: EXT, PMP are extract and pump processes.

Target side GG services: REP is the replicat process.


Note: This implementation is considered that unidirectional goldengate replication is already setup and only implementing HA for Goldengate services. 



Implementation Steps:

  1. Download XAG agent binaries.
    What is XAG: Oracle Grid Infrastructure Bundled Agents (XAG) are Oracle Grid Infrastructure components that provide the HA framework to application resources and resource types managed through the bundled agent management interface, AGCTL.
    https://www.oracle.com/database/technologies/xag-agents-download.html

  2. To configure Grid agent, application vip resource is needed, select a free ip from cluster’s public network and assign it to a vip host.

Source cluster application vip is gg-sourcedb-vip.oracle.com

Target Cluster Application vip is gg-targetdb-vip.oracle.com

Note: These application vip names should be added in the DNS before the configuration.

  1. XAG installation

Copy the downloaded zip file in step-1 to source and target cluster nodes ( sourcedb01, sourcedb02, targetdb01 & targetdb02 ) stage directory and follow below steps in all the nodes.


  1. Unzip the file to stage directory:


$ cd /u01/app/oracle/xag_stage

$ unzip -q p31215432_190000_Generic.zip



  1. Create XAG installation directory:

$ mkdir -p /u01/app/oracle/xag

  1. Add XAG agent to PATH variable and also update the .bash_profile for persistence:


$ export PATH=$PATH:/u01/app/oracle/xag/bin



  1. Install XAG agent:

$ cd /u01/app/oracle/xag_stage/xag

$ ./xagsetup.sh --install --directory \

/u01/app/oracle/xag --all_nodes



  1. Verify the XAG agent release version after installation


$ agctl query releaseversion




  1.  Add service & TNS alias as mentioned below.

Commands for Goldengate source database: 


Run below commands from grid home owner:


$ srvctl add service -db SOURCEDB -service SOURCEDB_OGG -role PRIMARY -preferred SOURCEDB1 -available SOURCEDB2        



$ srvctl start service -db SOURCEDB -service SOURCEDB_OGG



$ srvctl status service -db SOURCEDB -service SOURCEDB_OGG



Node-1 TNS Names:


SOURCEDB_OGG=

   (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = sourcedb01.oracle.com)(PORT = 1521))

    (CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = sourcedb_ogg)))


Node-2 TNS Names:


SOURCEDB_OGG=

   (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = sourcedb02.oracle.com)(PORT = 1521))

    (CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = sourcedb_ogg)))


Verify the service status using crsctl from Grid Home:

$ crsctl stat res | grep -i sourcedb_ogg


NAME=ora.sourcedb.sourcedb_ogg.svc → Command Output



Commands for Goldengate Target database: 


Run below commands from grid home owner:


$ srvctl add service -db TARGETDB -service TARGETDB_OGG -role PRIMARY -preferred TARGETDB1 -available TARGETDB2        



$ srvctl start service -db TARGETDB -service TARGETDB_OGG

$ srvctl status service -db TARGETDB -service TARGETDB_OGG



Node-1 TNS Names:


TARGETDB_OGG=

   (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = targetdb01.oracle.com)(PORT = 1521))

    (CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = targetdb_ogg)))


Node-2 TNS Names:


TARGETDB_OGG=

   (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = targetdb02.oracle.com)(PORT = 1521))

    (CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = targetdb_ogg)))


Verify the service status using crsctl:

$ crsctl stat res | grep -i targetdb_ogg


NAME=ora.targetdb.targetdb_ogg.svc → Command Output