Introduction
One of the common issues Oracle E-Business Suite (EBS) administrators face is the login page hanging or failing to load. In many cases, the root cause is excessive resource consumption by a WebLogic OACORE managed server. This blog walks through a real-world troubleshooting approach to identify, analyze, and safely resolve such issues in EBS R12.2 environments.
Problem Overview
Users reported that the EBS login page was not loading. Server-level investigation revealed that a specific Java process related to OACORE was consuming unusually high CPU resources, causing system slowdown and application unresponsiveness.
Step 1: Identify High Resource Utilization
Start by checking overall system performance using the top command.
Key observations:
-
Load average was significantly high
-
CPU usage was dominated by user processes
-
A Java process owned by
applmgrwas consuming excessive CPU
This immediately indicates a potential WebLogic-related bottleneck.
Step 2: Confirm the Process Belongs to OACORE
Using the process ID identified from top, verify whether it is an OACORE managed server.
The output confirms that the Java process corresponds to oacore_server2, validating that the issue is WebLogic OACORE-related.
Step 3: Analyze Historical CPU Trends
To understand whether the issue is a spike or a recurring pattern, review system activity reports using sar.
Findings:
-
Sustained high CPU usage
-
Increased I/O wait during the affected time window
This indicates prolonged system stress rather than a short-lived anomaly.
Step 4: Check WebLogic Incident Directories
Oracle WebLogic automatically generates incident reports when it detects internal issues such as thread hangs or performance degradation.
Navigate to the OACORE incident directory:
Multiple incdir_* directories suggest repeated incidents.
Step 5: Review Incident Details
Inside the latest incident directory, you’ll typically find:
-
JVM thread dumps
-
DMS metrics
-
ODL logs
-
A detailed
readme.txt
These files are extremely valuable for root cause analysis and Oracle SRs.
Step 6: Analyze the Incident Readme
The readme.txt file provides a summary of what triggered the incident—often pointing to stuck threads, long-running SQL, or memory pressure within OACORE.
This confirms that the login issue is not network-related but tied to backend processing.
Step 7: Identify Problematic SQL Executed by OACORE
To pinpoint the exact database activity causing the slowdown, query active OACORE sessions:
Once the SQL ID is identified, retrieve the full SQL text:
This step helps determine whether the issue is due to inefficient SQL, locking, or application behavior.
Additionally, check for repeating WebLogic errors:
Recurring messages usually indicate thread contention or stuck executions.
Step 8: Immediate and Safe Mitigation
If users are actively impacted, apply one of the following safe recovery options:
Option 1: Kill the Problematic Process
(This forces OACORE to restart automatically.)
Option 2: Gracefully Restart OACORE
A controlled restart is recommended in production environments.
Conclusion
EBS login page hangs are often symptoms of deeper WebLogic OACORE performance issues. By systematically analyzing system load, WebLogic incidents, and database activity, administrators can quickly isolate the root cause and restore service with minimal disruption.
Proactive monitoring of OACORE logs and incident directories can help prevent such outages in the future.