Database Credentials in Oracle Wallet

When managing Oracle Databases, storing user credentials in plain text inside scripts is a major security risk. Oracle provides a secure solution with Oracle Wallet, which allows you to store database credentials in an encrypted location. Once configured, applications and utilities like Data Pump or JDBC can connect without requiring a clear-text password.

This blog walks through the step-by-step procedure to store database credentials in Oracle Wallet and use it securely.

---

Overview

The Oracle Wallet securely stores database credentials, eliminating the need to expose passwords in scripts.

• Multiple credentials can be stored in a single wallet.

• Supports auto-login, meaning applications don’t need a password to access it.

• OS file permissions ensure security.

In this example, a non-Oracle binary owner OS user (bidhan) is used to create the wallet.

Example usage:

Data Pump with Wallet

nohup expdp /@BSA1EP directory=DUMP_DIR dumpfile=scott_%U.dmp logfile=EXP_SCOTT.log schemas=scott parallel=4 &

JDBC with Wallet

Connection conn = DriverManager.getConnection("jdbc:oracle:oci:/@BSA1EP");

---

Step 1: Create Oracle Wallet Directory

Check wallet status:

SET LINES 180
COL wrl_type FORMAT a12
COL wrl_parameter FORMAT a35
COL status FORMAT a30
SELECT * FROM v$encryption_wallet;

If not present, create directory:

[root@dg1 ~]# mkdir -p /u01/admin/BSA1EP/wallet
[root@dg1 ~]# chown -R bidhan:bidhan /u01/admin/BSA1EP/wallet

---

Step 2: Create TNS ADMIN Directory (for bidhan)

[root@dg1 ~]# mkdir -p /u01/admin/BSA1EP/wallet/TNS_ADMIN
[root@dg1 ~]# chown -R bidhan:bidhan /u01/admin/BSA1EP/wallet/TNS_ADMIN

---

Step 3: Add TNS Entry (for oracle)

Update sqlnet.ora and tnsnames.ora:

sqlnet.ora

SQLNET.WALLET_OVERRIDE = FALSE
WALLET_LOCATION = (SOURCE = (METHOD = FILE)(METHOD_DATA = (DIRECTORY = /u01/admin/BSA1EP/wallet)))

tnsnames.ora

BSA1EP =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = dg1.bidhan.com)(PORT = 1622))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = BSA1EP)
    )
  )

---

Step 4: Export Oracle Variables

For OS user bidhan:

export ORACLE_SID=BSA1EP
export ORACLE_HOME=/oracle/1900
export PATH=$ORACLE_HOME/bin:$PATH
export TNS_ADMIN=/u01/admin/BSA1EP/wallet/TNS_ADMIN

---

Step 5: Create Password-Protected Oracle Wallet

[bidhan@dg1 wallet]$ orapki wallet create -wallet /u01/admin/BSA1EP/wallet -auto_login

After success, check files:

ls -ltr /u01/admin/BSA1EP/wallet
cwallet.sso
ewallet.p12

---

Step 6: Add Database Credentials to Wallet

[bidhan@dg1 ~]$ mkstore -wrl /u01/admin/BSA1EP/wallet -createCredential BSA1EP test
Enter your secret/Password: *****
Re-enter your secret/Password: *****
Enter wallet password: *****

---

Step 7: Verify Database Connection

[bidhan@dg1 ~]$ sqlplus /@BSA1EP
SQL> show user
USER is "TEST"

---

Step 8: List Credentials in Wallet

mkstore -wrl /u01/admin/BSA1EP/wallet -listCredential

Output:

1: BSA1EP test

---

Step 9: Modify Credentials in Wallet

After DB password change:

mkstore -wrl /u01/admin/BSA1EP/wallet -modifyCredential BSA1EP test newpassword

---

Step 10: View Wallet Contents

orapki wallet display -wallet /u01/admin/BSA1EP/wallet

---

Step 11: Change Wallet Password

orapki wallet change_pwd -wallet /u01/admin/BSA1EP/wallet

---

Step 12: Delete Credentials from Wallet

mkstore -wrl /u01/admin/BSA1EP/wallet -deleteCredential BSA1EP

---

Step 13: Delete Oracle Wallet

Remove wallet files:

rm -f /u01/admin/BSA1EP/wallet/*wallet*

---

Key Takeaways

• Oracle Wallet eliminates password exposure in scripts.

• Supports auto-login for seamless integration.

• Credentials can be securely added, updated, listed, or deleted.

• Works perfectly with Data Pump, RMAN, JDBC, and batch jobs.

 

Oracle 19c Active Data Guard Switchover Procedure

Oracle Active Data Guard provides high availability and disaster recovery by allowing seamless role transitions between the primary and standby databases. A switchover is a planned role reversal where the primary database becomes the standby, and the standby takes over as the new primary without data loss.

This guide covers the step-by-step procedure for switchover in Oracle 19c Active Data Guard.

---

1. Pre-Checks

Before initiating a switchover, ensure both databases are synchronized and healthy.

On both primary and standby:

SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;

• Primary should show: PRIMARY, READ WRITE

• Standby should show: PHYSICAL STANDBY, READ ONLY WITH APPLY or MOUNTED

Also, confirm there are no active sessions or long-running transactions on the primary.

---

2. Verify Log Transport and Apply

Ensure redo logs are being shipped and applied correctly.

On Primary:

SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST;

On Standby:

SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;

• ARCH and LGWR processes should be running on primary.

• MRP (Managed Recovery Process) should be running on standby.

---

3. Prepare Standby (Optional)

If standby is running in read-only with apply, cancel recovery before switchover:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

---

4. Switchover Command (Primary)

On the Primary Database:

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

The database is now in standby mode.

---

5. Activate New Primary (Standby)

On the Standby Database:

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;

The standby is now promoted to the new primary database.

---

6. Convert Former Primary to Standby

On the Former Primary (now mounted as standby):

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

This re-establishes redo apply.

---

7. Verify New Roles

On both databases:

SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;

Expected Results:

• New Primary → PRIMARY, READ WRITE

• New Standby → PHYSICAL STANDBY, MOUNTED or READ ONLY WITH APPLY

---

8. Post-Checks

Validate the overall Data Guard configuration.

Using Data Guard Broker (DGMGRL):

DGMGRL> SHOW CONFIGURATION;

If Data Guard Broker is configured, switchover is much simpler:

DGMGRL> CONNECT sys/password@primary;
DGMGRL> SWITCHOVER TO 'standby_db_unique_name';
DGMGRL> SHOW CONFIGURATION;

---

Conclusion

A switchover in Oracle 19c Active Data Guard ensures a zero data loss, planned role reversal between primary and standby databases. This is typically done during planned maintenance, patching, or to test disaster recovery readiness.

 

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.

---