Fusion General Ledger Introduction

1. What is GL in Oracle Fusion Cloud Finance?

GL = General Ledger

The General Ledger (GL) is the central accounting hub of Oracle Fusion Cloud Financials. It is where all financial transactions from different modules (such as Payables, Receivables, Assets, and Cash Management) are recorded, summarised, and reported.

Key Functions of GL

1. Record Transactions
• All journal entries from sub-ledgers (AP, AR, FA, etc.) flow into the GL.
• You can also create manual journals directly in GL.
2. Financial Reporting
• GL provides real-time financial data for generating trial balances, balance sheets, profit and loss statements, and other statutory reports.
3. Chart of Accounts (CoA)
• GL uses a structured Chart of Accounts to classify and record transactions by segment (for example: Company, Cost Centre, Account, Department).
4. Accounting Periods
• GL manages open and closed periods to control when transactions can be posted.
• This ensures accounting integrity and compliance.
5. Integration Hub
• GL acts as a central point where all subledger modules integrate.
• It ensures consistency across financial data.
6. Multi-currency and Multi-ledger Support
•  
• Fusion GL can handle multiple currencies, legal entities, and ledgers, making it suitable for global organisations.

 

 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.