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.1How 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.


Troubleshooting a Never-Ending Concurrent Program in Oracle EBS 12.2 – My Real-Time Experience

 Recently, while working on our Oracle E-Business Suite 12.2 environment, I encountered an interesting issue that I thought was worth sharing.

The Problem

A few of our custom concurrent programs were not completing. They were running forever, with no errors in the log files and no obvious clues in the usual diagnostic areas.

Like most DBAs would do, I checked:

  • Concurrent request log and output – nothing unusual.

  • Database session waits – nothing conclusive.

  • Trace files – no errors.

Eventually, I raised an Oracle SR to get assistance, but even after multiple attempts, we couldn’t pinpoint the issue.

The Breakthrough

Finally, I decided to take a different approach. I used the strace command on the Linux OS to trace the system calls of the concurrent program's process ID (PID).

What I saw was eye-opening — the process was generating a large number of file-related system calls, and one particular line caught my attention:

It was trying to write temporary files to a production directory path that did not exist in the cloned test server!

Root Cause

On further investigation, I discovered that the $APPLLKOR environment variable was pointing to a non-existing directory:

/usr/tmp/prod

This was a leftover from the production environment after the test instance was cloned. Since the directory did not exist on the test server, the concurrent programs were unable to write the required temporary files and got stuck.

The Fix

I corrected the $APPLLKOR variable in the environment file to point to a valid directory on the test server. After making this change, I restarted the EBS application services.

Immediately, the concurrent programs that were stuck started completing successfully!

Key Takeaways

  • Think beyond EBS and DB logs – sometimes the issue is at the OS or filesystem level.

  • strace is a powerful tool – it can reveal exactly what the process is trying to do at the system call level.

  • Post-clone checks are critical – always verify environment variables and directory structures after cloning from production.

This experience reinforced for me that troubleshooting sometimes requires going one level deeper and thinking outside the usual EBS framework.