Validating an Oracle TDE Wallet Password Safely with mkstore

When managing Oracle Transparent Data Encryption (TDE), it’s often necessary to verify whether a wallet password is correct—especially before performing operations such as opening the wallet, rotating keys, or restoring backups. The safest way to do this is by using the mkstore utility outside the database environment, without requiring any database open/close actions.

Below is a simple and secure method to validate your TDE wallet password.

---

Why Use mkstore for Validation?

mkstore allows you to test the wallet password independently of the database.
This approach ensures:

• No impact on the running database

• No wallet state changes

• A direct and reliable password validation method

---

 Steps to Validate a TDE Wallet Password

1. Copy Only the ewallet.p12 File

Copy the wallet file (ewallet.p12) to a temporary directory:

• Do not copy cwallet.sso
  The .sso file enables auto-login, which bypasses the password prompt.
  Excluding it ensures that mkstore must ask for the password.

Example:

cp /path/to/original/ewallet.p12 /tmp/wallet_validation/

---

2. Run the mkstore Command

From the Oracle home bin directory, execute:

mkstore -wrl <wallet_directory> -list

Replace <wallet_directory> with the path to your copied wallet (e.g., /tmp/wallet_validation/).

mkstore will prompt you to enter the wallet password.

---

3. Interpret the Result

• Valid Password:
  The command displays wallet contents (aliases/entries).

• Invalid Password:
  You will see an error indicating that the password is incorrect.

This method confirms the correctness of your TDE wallet password without any risk to the running database or the original wallet.

---

Why Avoid Copying cwallet.sso?

cwallet.sso enables auto-login mode.
If present, the wallet opens automatically and no password check occurs, defeating the purpose of validation.
By copying only ewallet.p12, you ensure that mkstore enforces password authentication.

---

Example Commands

cp /u01/app/oracle/admin/db_wallet/ewallet.p12 /tmp/wallet_validation/
mkstore -wrl /tmp/wallet_validation/ -list

---

🟩 Summary

Validating a TDE wallet password using mkstore is:

• Safe

• Non-intrusive

• Independent of database state

• Ideal before sensitive operations like wallet open, key changes, or backup restores

This simple check can help prevent downtime and errors related to incorrect wallet passwords.

Edition-Based Redefinition (EBR) in Action: Resolving Synonym Translation Errors

While working with Oracle Applications schemas, you may encounter the error ORA-00980: synonym translation is no longer valid when accessing editioning views or objects through a synonym. This article explains a practical example of how this issue arises and how to resolve it.

---

Scenario

A user TEST tried to access the APPS schema object FND_USER_RESP_GROUPS_DIRECT using a synonym.

SQL> SHOW USER
USER is "TEST"

The user then connected and created a synonym for the editioning view:

SQL> CONN test/***
Connected.

SQL> CREATE OR REPLACE SYNONYM "FND_USER_RESP_GROUPS_DIRECT" FOR APPS.FND_USER_RESP_GROUPS_DIRECT;

Synonym created.

However, when querying the synonym, the following error occurred:

SQL> SELECT COUNT(1) FROM FND_USER_RESP_GROUPS_DIRECT;
SELECT COUNT(1) FROM FND_USER_RESP_GROUPS_DIRECT
                     *
ERROR at line 1:
ORA-00980: synonym translation is no longer valid

---

Root Cause

This issue happens because the TEST user is not edition-enabled, while the target object in the APPS schema is an editioning view.
Edition-based redefinition (EBR) in Oracle allows for multiple versions of application objects (like packages and views) across different editions.
When a non-editioned user tries to access editioned objects, Oracle cannot resolve the synonym, leading to this error.

To verify the editioning status of the user:

SQL> SELECT EDITIONS_ENABLED FROM DBA_USERS WHERE USERNAME='TEST';

E
-
N

The result N indicates the user is not edition-enabled.

---

Resolution

Enable editions for the user to allow access to editioned objects:

SQL> ALTER USER test ENABLE EDITIONS;

User altered.

Confirm the change:

SQL> SELECT EDITIONS_ENABLED FROM DBA_USERS WHERE USERNAME='TEST';

E
-
Y

Reconnect as the user and retry the query:

SQL> CONN test/***
Connected.

SQL> SELECT COUNT(1) FROM FND_USER_RESP_GROUPS_DIRECT;

  COUNT(1)
----------
     18916

The query now executes successfully.

---

Key Takeaway

When creating synonyms for editioning views in Oracle E-Business Suite or any EBR-enabled schema, ensure that the referencing user has editioning enabled.
Otherwise, Oracle will fail to translate the synonym, resulting in the ORA-00980 error.

Oracle AI Database 26ai – What It Means for Oracle E-Business Suite

At Oracle AI World 2025 in Las Vegas, Larry Ellison announced the launch of Oracle AI Database 26ai (26ai) — the next evolution of Oracle Database, bringing AI-driven capabilities into the core database engine. This announcement marks a key milestone for both the Oracle Database and Oracle E-Business Suite (EBS) communities.

---

🔑 Key Highlights from the Announcement

• New Naming Convention: Oracle Database is now officially referred to as the Oracle AI Database.

• 26ai Replaces 23ai: Oracle AI Database 26ai supersedes Oracle Database 23ai, becoming the latest long-term release.

• No Architectural Changes: DB 26ai builds on 23ai with no changes to the internal architecture or APIs.

• Smooth Transition:

  • If you’re on Oracle Database 23ai, simply apply the October 2025 Database Release Update (DBRU).

  • If you’re on 19c or earlier, a standard upgrade is required to move to 26ai.

• Updated Documentation: Oracle’s database documentation and release materials now reference DB 26ai instead of DB 23ai.

• New Release Numbering: Oracle has updated its database release numbering with the introduction of 26ai.

For detailed platform availability, refer to:
📘 Release Schedule of Current Database Releases (Doc ID 742060.1)

---

💡 Impact on Oracle E-Business Suite

For Oracle E-Business Suite (EBS) customers:

• All EBS documentation will be updated to replace mentions of “Oracle Database 23ai” with “Oracle AI Database 26ai.”

• During this transition, you may see references to both names in parallel, but once updates are complete, only Oracle AI Database 26ai will appear across official documentation.

---

Oracle AI Database 26ai represents the next step in integrating AI-driven performance, automation, and insight into Oracle’s enterprise database platform—ensuring that EBS customers can continue to innovate with a future-ready, AI-enhanced foundation.

---

How to Safely Remove Sensitive Data Before Sharing Diagnostic Files with Oracle Support

When working with Oracle Support, customers often upload diagnostic files (such as logs, trace files, or exports) to assist in troubleshooting issues. However, these files may occasionally contain sensitive or confidential information.

Oracle provides clear guidance on how to review and sanitize such files before submission to ensure compliance and data privacy.

---

🔍 Key Recommendations

• Review Before Uploading:
  Oracle’s Global Customer Support (GCS) does not automatically collect Personally Identifiable Information (PII). Customers should review all diagnostic output before uploading it through My Oracle Support (MOS).

• Avoid Restricted File Types:
  Files with extensions like .exe, .com, .bat, and .aspx are not accepted by Oracle’s upload systems. Such files should be removed or archived (e.g., .zip, .tar, or .gzip) before resubmission.

• Editable File Types:
  Files such as .trc, .log, .txt, .sql, .xml, .doc, and .xls can be opened in standard text or office editors to manually remove sensitive portions.

• Non-Editable Formats:
  Files generated by tools like Documaker, or compressed binary files (e.g., .dpa, .pdf, .met, .pcl) may not be editable. Any personal data should be scrubbed before creating such files.

• Using ADR and RDA Data:

  • ADR packages: Remove specific files before packaging via Enterprise Manager → Support Workbench.

  • RDA files: Review .rda, .htm, or .txt outputs with a text editor to redact confidential sections.

---

🧩 Why This Matters

Protecting sensitive data during support interactions safeguards both organizational security and customer trust. Oracle’s documentation emphasizes that customers retain full control and responsibility for what data is shared with Support.

By following these simple steps, organizations can ensure that only the necessary, sanitized information is sent to Oracle — keeping diagnostic collaboration secure and compliant.

---

📘 Reference:
Oracle Support Document ID 1227943.1 – How to Edit Output from Oracle Tools and Utilities to Remove Sensitive Content

Understanding Profile Option Values in Oracle E-Business Suite R12

In Oracle E-Business Suite R12, administrators often query the table FND_PROFILE_OPTION_VALUES to check profile settings at the user, responsibility, or site level. However, many times the VALUE column displays a lookup code instead of a readable description — making it hard to interpret.

For example if you query "FND: Debug Log Level" for user or site level from backend, it shows some numeric value.

Let’s look at how to find the actual meaning behind those coded values.

---

🧩 Step 1: Identify the Lookup Type

1. Log in to EBS using the Application Developer responsibility.

2. Navigate to:
   Profiles → System → Query the Profile Option -"AFLOG_LEVEL" (using its short name).

3. In the results, note down the Lookup Type associated with that profile.

---

🧠 Step 2: Query the Lookup Meaning

Once you know the Lookup Type, use the following SQL query to decode the meaning: 

SELECT lookup_code,
       meaning,
       description
FROM   fnd_lookup_values
WHERE  lookup_type = 'AFLOG_LEVELS';

🧾 Example

If a profile option value shows as ‘3’ or ‘4’ in FND_PROFILE_OPTION_VALUES, the above query helps you find out what those codes actually represent (for example, Statement or Exception).

---

✅ Summary

When you see cryptic values in FND_PROFILE_OPTION_VALUES, remember:

• Use the Application Developer responsibility to find the Lookup Type.

• Query FND_LOOKUP_VALUES to get the actual meaning.

This simple approach helps DBAs and support teams interpret configuration settings accurately — ensuring smoother troubleshooting and configuration validation.

📅 Quarterly Upgrade Highlights: EBS August 2025

Oracle’s August 2025 update provides key recommendations for EBS environments and accompanying technology components. (Oracle Blogs)

✅ Core Platform Guidance

• EBS 12.2 remains in Premier Support through at least December 2036. 

• Older versions (EBS 12.1, 12.0, 11.5.10) are in sustaining support and no new patches will be released—migration to 12.2 is strongly recommended. 

🔧 Patching & Baselines

• Minimum patch baseline for EBS 12.2 should be Patch 24690690 (or equivalent) as of July 1 2024. 

• Apply the latest suite-wide Release Update Pack (RUP)—version 12.2.14 (Sept 2024) or 12.2.13 (Nov 2023). 

🧰 Technology Stack & Tools

Ensure these components are up to date:

• AD/TXK Delta version 16 (July 2024)

• OAF Bundle releases (ex: 12.2.14 OAF Bundle 3 as of Aug 2025)

• Deploy the latest desktop/client tier components: JRE 1.8.0_461, certified browsers, transition from IE 11 to Edge.

---

📝 Why This Matters

Adhering to these recommendations keeps your EBS environment secure, supported, and optimized. Lower patching risk means better stability, stronger compatibility, and clearer upgrade paths. For older EBS versions, the message is clear: migrate to 12.2 now to avoid unsupported environments.

---

🔗 For full details and the complete list of stack-specific recommendations, you can read the original blog here: https://blogs.oracle.com/ebstech/post/quarterly-ebs-upgrade-recommendations-august-2025

Oracle Linux vs. Red Hat Enterprise Linux: Clearing the Confusion

 

For many years, people have often assumed Oracle Linux and Red Hat Enterprise Linux (RHEL) are the same—or weren’t sure what truly sets them apart. While both share the same open-source upstream code base, Oracle Linux offers more flexibility, cost efficiency, and performance tuning.

🔍 Key Highlights

• Binary Compatibility: Oracle Linux is 100% compatible with RHEL, ensuring that any application running on RHEL will run flawlessly on Oracle Linux.

• Two Kernel Options:

  • Red Hat Compatible Kernel (RHCK) – identical to RHEL’s kernel.

  • Unbreakable Enterprise Kernel (UEK) – optimized for Oracle workloads and cloud performance.

• Lower Total Cost: Oracle Linux delivers enterprise-grade support at a lower price, without additional subscription fees for updates or security patches.

• Free Access to Updates: Oracle provides open and free access to all updates and patches through the Oracle Linux yum server—something RHEL restricts to paid subscribers.

• Built for Oracle Cloud: Oracle Linux is deeply integrated with Oracle Cloud Infrastructure (OCI), providing consistency across on-premises and cloud environments.