Oracle 19c Active Data Guard Configuration on Linux – Step by Step

Oracle Active Data Guard provides high availability, data protection, and disaster recovery by maintaining a synchronized copy of the primary database on a standby system. In this guide, we will configure Oracle 19c Active Data Guard between two Linux servers.

---

1. Environment Setup

Primary Database: primary.localdomain (192.168.0.187)
Standby Database: standby.localdomain (192.168.0.188)

Update /etc/hosts on both servers:

192.168.0.187 primary.localdomain primary
192.168.0.188 standby.localdomain standby

Disable firewall & SELinux (if required):

systemctl stop firewalld
setenforce 0

---

2. Enable FORCE LOGGING & ARCHIVELOG Mode on Primary

On the Primary Database:

ALTER DATABASE FORCE LOGGING;
ARCHIVE LOG LIST;

If not in ARCHIVELOG mode:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

---

3. Configure Primary Initialization Parameters

Update the parameters using ALTER SYSTEM:

ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,standby)';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u01/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=primary';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
ALTER SYSTEM SET FAL_SERVER=standby;
ALTER SYSTEM SET FAL_CLIENT=primary;
ALTER SYSTEM SET DB_FILE_NAME_CONVERT='/u02/oradata/standby/','/u02/oradata/primary/';
ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='/u02/oradata/standby/','/u02/oradata/primary/';
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

---

4. Configure tnsnames.ora on Both Servers

Edit $ORACLE_HOME/network/admin/tnsnames.ora:

primary =
 (DESCRIPTION =
   (ADDRESS = (PROTOCOL = TCP)(HOST = primary.localdomain)(PORT = 1521))
   (CONNECT_DATA = (SERVICE_NAME = primary))
 )

standby =
 (DESCRIPTION =
   (ADDRESS = (PROTOCOL = TCP)(HOST = standby.localdomain)(PORT = 1521))
   (CONNECT_DATA = (SERVICE_NAME = standby))
 )

---

5. Create Standby Redo Logs on Primary

Add standby redo logs (same size as primary redo logs, +1 group):

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('/u02/oradata/primary/standby_redo04.log') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('/u02/oradata/primary/standby_redo05.log') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('/u02/oradata/primary/standby_redo06.log') SIZE 500M;

---

6. Create Password File & Transfer to Standby

On Primary:

orapwd file=$ORACLE_HOME/dbs/orapwprimary password=oracle entries=10 force=y
scp $ORACLE_HOME/dbs/orapwprimary oracle@standby:$ORACLE_HOME/dbs/orapwstandby

---

7. Take RMAN Backup & Transfer to Standby

On Primary:

rman target /
RUN {
  BACKUP DATABASE PLUS ARCHIVELOG;
  BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/oradumps/standby_ctrl.bkp';
}
scp /oradumps/* oracle@standby:/oradumps/

---

8. Restore Database on Standby

On Standby:

rman target /
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM '/oradumps/standby_ctrl.bkp';
ALTER DATABASE MOUNT;
CATALOG START WITH '/oradumps/';
RESTORE DATABASE;
RECOVER DATABASE;

---

9. Configure Standby Initialization Parameters

Set parameters (reverse role values compared to primary):

ALTER SYSTEM SET DB_UNIQUE_NAME=standby;
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,standby)';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u01/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=standby';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=primary ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=primary';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
ALTER SYSTEM SET FAL_SERVER=primary;
ALTER SYSTEM SET FAL_CLIENT=standby;
ALTER SYSTEM SET DB_FILE_NAME_CONVERT='/u02/oradata/primary/','/u02/oradata/standby/';
ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='/u02/oradata/primary/','/u02/oradata/standby/';
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

---

10. Start Managed Recovery

On Standby Database:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

For Active Data Guard (read-only + apply mode):

ALTER DATABASE OPEN;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

---

11. Verify Configuration

Run these checks on both Primary and Standby:

SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST;

Expected output:

• Primary DB → PRIMARY, READ WRITE

• Standby DB → PHYSICAL STANDBY, READ ONLY WITH APPLY

---

Conclusion

With this configuration, your Oracle 19c Active Data Guard environment is now up and running. Always validate in a test environment before production deployment. Active Data Guard ensures business continuity by providing real-time failover, load balancing for queries, and disaster recovery capabilities.

---

 

Introduction to Oracle Fusion General Ledger (GL)

Oracle Fusion General Ledger is the core financial component of the Oracle Fusion Cloud Financials suite. It delivers a modern, highly configurable, and scalable accounting system designed to meet global business needs. Whether you’re part of a multinational enterprise or a growing organization, Oracle Fusion GL provides the foundation for accurate, real-time financial reporting and decision-making.

---

Key Features of Oracle Fusion General Ledger

1. Multi-Dimensional Accounting

Oracle Fusion GL introduces a multi-dimensional chart of accounts using segments. Each transaction is recorded with rich context, such as:

• Company

• Cost Center

• Account

• Product

• Location

This allows flexible and powerful financial analysis.

2. Ledgers and Ledger Sets

Fusion GL supports:

• Primary Ledgers for actual accounting

• Secondary Ledgers for statutory or management reporting

• Ledger Sets for consolidating reporting across multiple ledgers in real-time

3. Accounting Periods and Calendars

You can define:

• Custom accounting calendars

• Multiple period types (monthly, quarterly, yearly)

• Automatic open/close period controls to maintain financial discipline.

4. Journal Processing

• Manual and automated journal entries

• Journal approval workflows

• Reversals, recurring journals, and allocations

• Spreadsheet integration for bulk data upload (via ADFdi or FBDI)

5. Real-Time Reporting and Analytics

Fusion GL uses Oracle OTBI and Smart View for Excel for real-time, self-service financial reporting, eliminating delays associated with batch processing.

---

Benefits of Using Oracle Fusion GL

• Global compliance: Handles multiple currencies, languages, and statutory requirements.

• Modern UX: Web-based UI with role-based dashboards and guided navigation.

• Unified data model: Ensures consistency across finance modules (Payables, Receivables, Assets, etc.).

• Audit-ready: Embedded controls and audit trail for every transaction.

• Scalable: Supports both centralized and decentralized operations.

---

Common Use Cases

• Closing accounting periods and running trial balances

• Generating P&L and balance sheet reports

• Performing allocations and consolidations across business units

• Setting up intercompany accounting and revaluations

• Integrating with EPM tools for planning and forecasting

---

Who Uses Fusion GL?

• Finance Managers: For monitoring KPIs and approving journal entries

• Accountants: For daily ledger maintenance and closing books

• Auditors: For verifying transactional integrity and controls

• IT Teams: For integrating third-party systems and managing roles

---

Author: Bidhan Mandal
Oracle Fusion Cloud | Financials Expert | EBS & Cloud Migration Specialist
Visit: https://bidhandba.blogspot.com

Configure Oracle Database Vault Realms

Configure Oracle Database Vault Realms to Secure the HR Schema

Oracle Database Vault (DV) is a powerful security feature that enables fine-grained access control by enforcing security policies that protect sensitive data.
One of the most important components in Database Vault is the Realm, which creates a security boundary around database objects to prevent unauthorized access — even by highly privileged users.

In this blog, we’ll walk through the step-by-step process of configuring a Realm to secure the HR schema in an Oracle Database 19c environment.
You’ll learn how to:

• Create a Realm

• Add objects to it

• Restrict access

• Enable auditing for security tracking

---

What is a Realm?

A Realm in Oracle Database Vault defines a logical security boundary around one or more database objects. Once a Realm is in place, no one — not even privileged users like DBAs — can access the protected objects without being explicitly authorized.

Realms are ideal for:

• Securing sensitive application data (e.g., HR, Finance)

• Enforcing separation of duties in compliance-driven environments

• Preventing data breaches caused by insider threats

---

Step-by-Step Guide to Configuring a Realm

Step 1: Select Data from the HR Schema (Before Realm Setup)

First, try selecting data from the HR schema to see the current level of access.

sql
SELECT * FROM hr.employees;

At this point, access is typically allowed without restriction.

---

Step 2: Connect as the DV Owner

To create and manage Realms, you need to log in as a Database Vault Owner — often a common user like c##dv_owner_root.

bash
sqlplus c##dv_owner_root@pdb1

This user has privileges to create Realms and manage Database Vault policies.

---

Step 3: Create the Realm for the HR Schema

Create a Realm to secure all objects in the HR schema.

sql
BEGIN
  DBMS_MACADM.CREATE_REALM(
    realm_name   => 'HR_REALM',
    description  => 'Realm for HR Schema',
    enabled      => DBMS_MACUTL.G_YES,
    audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL +
                     DBMS_MACUTL.G_REALM_AUDIT_SUCCESS
  );
END;
/

Audit Options:
Here, we enable auditing for both failed and successful access attempts. This allows us to track who tried to access the protected data.

---

Step 4: Add Objects to the Realm

Add all HR schema objects to the Realm. The % wildcard ensures all object names and types are included.

sql
BEGIN
  DBMS_MACADM.ADD_OBJECT_TO_REALM(
    realm_name   => 'HR_REALM',
    object_owner => 'HR',
    object_name  => '%',
    object_type  => '%'
  );
END;
/

Now, all HR schema objects are protected under HR_REALM.

---

Step 5: Test Realm Enforcement

Try accessing the HR schema again:

sql
SELECT * FROM hr.employees;

If your user or role is not authorized to access HR_REALM, you will receive an access violation error, even if you are a DBA.

---

Summary of Steps

Step	Action	Result
1	Select data from HR schema	Access allowed
2	Connect as c##dv_owner_root	Success
3	Create a Realm on the HR schema	HR_REALM created
4	Add objects to the Realm	All HR schema objects protected
5	Select data from HR schema again	Access denied (if unauthorized)

Best Practices for Realms

1. Enable Auditing – Always enable auditing for Realms to detect unauthorized access attempts.

2. Granular Protection – Protect only critical objects if full schema protection is unnecessary.

3. Role-Based Access – Grant Realm access via roles to simplify management.

---

References

Oracle Database Vault Realms Documentation

---

Why Use Realms?

• Enforce fine-grained access control

• Protect sensitive data from privileged users

• Achieve compliance with industry regulations

• Prevent unauthorized insider access

Realms are a cornerstone of a Zero Trust approach to database security. If you’re working in a regulated or security-conscious environment, they are essential.

---

Author: Bidhan Mandal
Oracle Apps DBA | Oracle Database Vault Specialist | OCI Architect
Visit: https://bidhandba.blogspot.com