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

at No comments:

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.


at No comments:

📅 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


at No comments:

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.


at No comments:

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.

at No comments:

OCI Home Region Explained: Identity Domains & Service Access

Oracle Cloud Infrastructure (OCI) uses the concept of a Home Region for identity management, service access, and global policy enforcement. Knowing what this means, how it works, and how it affects your environment is critical.

🛠 What is the Home Region?

  • When you set up an OCI tenancy, Oracle assigns you a Home Region. This is where your Identity and Access Management (IAM) resources—users, groups, policies, compartments, dynamic groups—are defined and managed. 

  • Once set, the Home Region for your tenancy cannot be changed. 

  • Even if you operate services in other regions, your IAM resource definitions always live in the Home Region. When you make changes (to policies, groups etc.), those changes happen in the Home Region and then get propagated to other subscribed regions. 

🌐 How It Impacts Identity Domains & Access

  • Identity Domains Creation: When you create an identity domain in the Console, the region you select becomes its Home Region. The identity domain’s configurations and roles live there. 

  • Policy Enforcement Across Regions: IAM policies defined in your Home Region are enforced in all regions you subscribe to. Even though the IAM resource definitions are centralized, their effects are global.

  • Updates & Replication Delay: Because IAM resource updates are made in the Home Region, it may take a few minutes before those updates reflect across other regions. 

✅ What This Means for You

  • Plan Your Home Region Carefully: Since it cannot be changed later, choose the most strategic region—consider latency, compliance, data sovereignty, etc.

  • Know Where to Make IAM Changes: Always use the Home Region endpoint for API / SDK calls when modifying IAM resources. Even though you may be in another region, the changes happen in the Home Region. 

  • Policy Design With Global Scope: Design IAM policies expecting that they will apply in other regions as well. If you need region-specific controls, explicitly define them.

  • Identity Domain Awareness: If using multiple identity domains (including non-default ones), know which region is their Home Region, how replication works, and what control you have over region access. 

🧭 Bottom Line

OCI’s Home Region is more than just geographic—it’s the central authority for your identity, access, and policy definitions. It’s where your IAM is born and governed. Even though services may run in many regions, identity stays anchored at the Home Region—this ensures centralized control, consistency, and security.

at No comments:

Schedule an In-Place Upgrade to Oracle Database 23ai on Autonomous Database

 

Oracle Autonomous Database now supports in-place upgrades from Oracle Database 19c to 23ai using scheduled upgrades—a seamless, automated process tailored for modern cloud environments.

Upgrade Options Available:

  • Scheduled Upgrade
    Define your preferred time, and the upgrade process runs automatically—no manual steps needed.

  • Full Clone Upgrade
    Create a full clone of your 19c database and select 23ai during the clone setup to instantiate a new, upgraded instance.

  • Refreshable Clone Upgrade
    Similar to a full clone but allows ongoing synchronization between the 19c source and 23ai clone—ideal for ensuring minimal downtime and continuous updates.

At a Glance

Upgrade Method Description
Scheduled Upgrade     Automated upgrade of an existing 19c Autonomous DB.
Full Clone                         Creates a brand-new 23ai clone from 19c.
Refreshable Clone Creates a 23ai clone that syncs with the source 19c DB.

Upgrading to Oracle Database 23ai on Autonomous Database has never been more straightforward. Whether you choose a scheduled upgrade or cloning, you control the transition timing and method with minimal disruption.

at No comments:
Subscribe to: Posts (Atom)