Unable to Start Oracle HTTP Server (OHS): Error While Loading Shared Libraries libdb.so.2 (Complete Oracle EBS Troubleshooting Guide)

📅 Last Updated: August 2026

This guide has been fully updated for Oracle E-Business Suite R12.1.x, R12.2.x, Oracle HTTP Server (OHS), Oracle Fusion Middleware 11g/12c, Oracle Linux, Red Hat Enterprise Linux (RHEL), and CentOS. It explains how to diagnose and resolve Oracle HTTP Server startup failures caused by the missing libdb.so.2 shared library using Oracle and Linux administration best practices.

Oracle HTTP Server (OHS) is one of the most important components of the Oracle E-Business Suite application tier. Every user request from a web browser passes through Oracle HTTP Server before reaching Oracle WebLogic Server and the EBS application services.

If Oracle HTTP Server cannot start because a required shared library such as libdb.so.2 is missing, the entire Oracle EBS web application becomes unavailable. Users cannot access the login page, Forms, OA Framework pages, Self-Service applications, or administrative interfaces.

One of the most common causes of this issue occurs after Oracle EBS cloning, operating system upgrades, package removal, or migration to a newer Linux release where Berkeley DB libraries are different from those expected by Oracle HTTP Server.

This guide explains Oracle HTTP Server architecture, Linux shared libraries, Berkeley DB compatibility, diagnostic techniques, troubleshooting procedures, and Oracle EBS production best practices.

Quick Solution

Identify the missing shared library, verify whether an equivalent Berkeley DB library already exists on the operating system, confirm Oracle HTTP Server library dependencies using ldd, create the required symbolic link only if appropriate, refresh the shared library cache if necessary, restart Oracle HTTP Server, and verify successful access to the Oracle E-Business Suite login page.

Error Message

Oracle HTTP Server fails to start with an error similar to the following:

httpd: error while loading shared libraries:

libdb.so.2:

cannot open shared object file:

No such file or directory

Because the required shared library cannot be loaded, the Oracle HTTP Server executable terminates immediately.

Applies To

Oracle E-Business Suite R12.1.x
Oracle E-Business Suite R12.2.x
Oracle HTTP Server (Apache)
Oracle Fusion Middleware
Oracle Linux
Red Hat Enterprise Linux (RHEL)
CentOS
Oracle VM environments

What is Oracle HTTP Server (OHS)?

Oracle HTTP Server (OHS) is Oracle's web server based on the Apache HTTP Server. It serves as the front-end web server for Oracle E-Business Suite and Oracle Fusion Middleware environments.

Its responsibilities include:

Accepting browser requests.
Serving static web content.
Forwarding dynamic requests to WebLogic Server.
Providing SSL termination.
Managing URL routing.
Supporting Oracle Forms and OA Framework applications.

How Oracle HTTP Server Works in Oracle EBS

Browser

     │

     ▼

Oracle HTTP Server (OHS)

     │

     ▼

mod_wl_ohs

     │

     ▼

Oracle WebLogic Server

     │

     ▼

Oracle EBS Application Services

     │

     ▼

Oracle Database

Oracle HTTP Server is the first component that receives incoming HTTP or HTTPS requests. If OHS cannot start, the Oracle EBS environment becomes inaccessible even though the database and application services may still be running.

What is libdb.so.2?

libdb.so.2 is a Berkeley DB shared library used by older software components. Oracle HTTP Server binaries compiled on older operating systems may expect this library during startup.

Modern Linux distributions often provide newer Berkeley DB library versions such as:

libdb-4.3.so
libdb-4.5.so
libdb-4.7.so
libdb-5.x.so

If the expected compatibility library is unavailable, Linux cannot resolve the dependency and Oracle HTTP Server fails to start.

Common Causes

Oracle EBS cloning.
Operating system upgrades.
Migration to newer Linux releases.
Missing Berkeley DB compatibility packages.
Incorrect symbolic links.
Accidental deletion of shared libraries.
Incomplete application tier installation.
Corrupted Oracle Home.

Business Impact

Failure of Oracle HTTP Server prevents users from accessing Oracle E-Business Suite through the web interface.

Potential impacts include:

Oracle EBS login page unavailable.
Forms cannot be launched.
OA Framework pages inaccessible.
Self-Service applications unavailable.
Workflow notifications inaccessible.
Business transaction processing interrupted.
Production downtime.

Prerequisites

Operating system access to the Oracle EBS application tier.
Application Manager or root privileges where appropriate.
Knowledge of Oracle Home locations.
Oracle HTTP Server administration privileges.
Backup of Oracle Home before modifying libraries.
Maintenance window for production systems.

Understanding Linux Shared Libraries

Linux applications do not contain every required software component inside the executable. Instead, they rely on shared libraries that are loaded dynamically at runtime by the Linux dynamic linker. These libraries provide reusable functionality and reduce memory usage across the operating system.

When Oracle HTTP Server starts, Linux checks every required shared library. If even one required library cannot be found, the executable immediately terminates and displays an error similar to error while loading shared libraries: libdb.so.2.

Why This Error Frequently Appears After Oracle EBS Cloning

Oracle E-Business Suite clones are often performed between servers running different Linux versions. Although the Oracle application tier is copied successfully, the destination server may contain newer Berkeley DB libraries instead of the older compatibility library expected by Oracle HTTP Server.

As a result, Oracle HTTP Server attempts to load libdb.so.2, but Linux cannot locate the required file. Before creating symbolic links, administrators should first verify which Berkeley DB libraries are already installed and confirm that the existing version is compatible with the Oracle software.

Oracle EBS DBA Recommendation

Never create symbolic links immediately after seeing a missing library error. First verify the actual dependency using ldd, identify installed Berkeley DB libraries with ldconfig or find, and confirm compatibility with your Oracle E-Business Suite release. A proper diagnosis prevents masking deeper operating system or application tier issues and ensures a stable production environment.

Step 1 – Verify Oracle HTTP Server Status

Before troubleshooting the missing library, confirm whether Oracle HTTP Server is actually down.

On Oracle E-Business Suite, check the service status using the application tier administration script:

adapcctl.sh status

Or verify the running process directly:

ps -ef | grep httpd

If no httpd processes are running, proceed with the diagnostic steps below.

Step 2 – Review Oracle HTTP Server Log Files

Always review the Oracle HTTP Server logs before making any changes.

Typical log locations include:

$IAS_ORACLE_HOME/Apache/logs/

or

$INSTANCE_HOME/diagnostics/logs/OHS/

View the latest log entries:

tail -50 error_log

Typical error:

httpd:

error while loading shared libraries:

libdb.so.2:

cannot open shared object file:

No such file or directory

Step 3 – Locate the Missing Library

Before creating symbolic links, verify whether another Berkeley DB library already exists on the server.

find / -name "libdb*" 2>/dev/null

Example output:

/usr/lib64/libdb-4.8.so

/usr/lib64/libdb.so

/usr/lib64/libdb-4.so

This information helps determine whether a compatible library already exists.

Step 4 – Verify Installed Berkeley DB Libraries

Display the libraries registered with the Linux dynamic linker.

ldconfig -p | grep libdb

Example output:

libdb-4.8.so

libdb.so

If libdb.so.2 is missing but a compatible Berkeley DB library exists, creating the required symbolic link may resolve the issue.

Step 5 – Verify Oracle HTTP Server Dependencies

Use the ldd utility to identify unresolved shared library dependencies.

ldd httpd

Typical output:

libdb.so.2 => not found

This confirms that the startup failure is caused by the missing shared library.

Step 6 – Create the Required Symbolic Link

If a compatible Berkeley DB library is already installed, create the symbolic link expected by Oracle HTTP Server.

Example:

ln -s /usr/lib64/libdb-4.8.so \
/usr/lib64/libdb.so.2

The source library varies depending on the operating system and installed Berkeley DB version.

Always verify compatibility before creating symbolic links.

Step 7 – Refresh the Shared Library Cache (If Required)

If necessary, refresh the Linux shared library cache.

ldconfig

This updates the dynamic linker cache so newly available libraries can be located during application startup.

Step 8 – Restart Oracle HTTP Server

After resolving the missing library dependency, restart Oracle HTTP Server.

adapcctl.sh stop

adapcctl.sh start

Alternatively:

adstrtal.sh apps/apps_password

if starting the complete Oracle EBS application tier.

Step 9 – Validate Oracle EBS Login Page

Open a web browser and verify that the Oracle E-Business Suite login page loads successfully.

Example:

http://hostname:port/OA_HTML/AppsLogin

Also confirm:

Oracle Forms launch successfully.
OA Framework pages open correctly.
No HTTP Server errors appear in the browser.

Troubleshooting Checklist

Verify Oracle HTTP Server is stopped.
Review the HTTP Server error log.
Confirm libdb.so.2 is missing.
Locate installed Berkeley DB libraries.
Verify dependencies using ldd.
Create the symbolic link only if the library is compatible.
Run ldconfig if necessary.
Restart Oracle HTTP Server.
Verify Oracle EBS login page accessibility.
Confirm Forms and OA Framework functionality.

Production Case Study

Following an Oracle E-Business Suite R12 application tier clone to a newer Oracle Linux server, Oracle HTTP Server failed during startup with the error libdb.so.2: cannot open shared object file. Investigation using ldd confirmed that the required Berkeley DB compatibility library could not be located. The DBA verified that a compatible Berkeley DB version was already installed, created the appropriate symbolic link, refreshed the shared library cache using ldconfig, restarted Oracle HTTP Server, and successfully restored access to the Oracle E-Business Suite login page. Post-maintenance validation confirmed that Oracle Forms, OA Framework pages, and all application services were operating normally.

Linux Shared Library Best Practices

Oracle HTTP Server depends on numerous Linux shared libraries to function correctly. Maintaining these libraries properly helps ensure stable Oracle E-Business Suite operation and reduces unexpected startup failures.

Keep operating system packages consistent across production, test, and development environments.
Install Oracle-certified operating system packages only.
Avoid deleting shared libraries manually.
Back up Oracle Home before modifying system libraries.
Verify shared library dependencies after operating system upgrades.
Use ldd to identify missing dependencies before making changes.
Refresh the shared library cache with ldconfig after installing or modifying libraries when appropriate.
Document all operating system changes performed on Oracle EBS servers.

Oracle E-Business Suite Cloning Best Practices

Oracle E-Business Suite cloning frequently introduces operating system compatibility issues because the source and target servers may have different Linux package versions.

After every clone, Oracle DBAs should verify:

Oracle HTTP Server startup.
Oracle WebLogic Server startup.
Required shared libraries.
Environment variables.
Oracle Forms functionality.
OA Framework pages.
AutoConfig execution.
Complete EBS login validation.

Symbolic Link Recommendations

Symbolic links should never be the first troubleshooting step. They should be created only after confirming that the target library is compatible with the Oracle software version.

Before creating symbolic links:

Verify the missing dependency using ldd.
Locate installed Berkeley DB libraries.
Review Oracle certification documentation where applicable.
Confirm that the replacement library provides the required compatibility.
Test changes in a non-production environment whenever possible.

LD_LIBRARY_PATH and the Linux Dynamic Linker

Linux searches for shared libraries using several locations, including standard library directories, the dynamic linker cache maintained by ldconfig, and directories specified by the LD_LIBRARY_PATH environment variable.

Incorrect environment settings can prevent Oracle HTTP Server from locating required libraries even when they are installed. Verify that Oracle environment scripts correctly configure library paths after cloning or migrating the application tier.

Common Administrator Mistakes

Creating symbolic links without verifying library compatibility.
Ignoring Oracle HTTP Server log files.
Skipping dependency verification with ldd.
Deleting existing shared libraries manually.
Installing unsupported operating system packages.
Not running AutoConfig after application tier changes when required.
Changing Oracle Home files directly without backups.
Failing to test Oracle EBS after resolving the issue.

Related Oracle HTTP Server Errors

Error	Description
libdb.so.2: cannot open shared object file	Required Berkeley DB shared library is missing.
libclntsh.so not found	Oracle Client shared library cannot be located.
libnnz.so not found	Oracle Network Security library is missing.
HTTP Server failed to start	General Oracle HTTP Server startup failure.
Apache segmentation fault	Runtime crash caused by library or module incompatibility.
OHS configuration test failed	Oracle HTTP Server configuration contains invalid directives.

Frequently Asked Questions (FAQ)

Why does Oracle HTTP Server require libdb.so.2?

Some Oracle HTTP Server binaries were built against older Berkeley DB library versions. If the expected compatibility library is unavailable, Linux cannot load the executable and Oracle HTTP Server fails to start.

Can I create a symbolic link for any Berkeley DB library?

No. A symbolic link should be created only after confirming that the installed Berkeley DB version is compatible with the Oracle software and satisfies the required binary interface.

How can I identify missing shared libraries?

Use the ldd command to inspect executable dependencies and identify any libraries reported as not found.

Does this problem occur only after Oracle EBS cloning?

No. It can also occur after operating system upgrades, package removal, Oracle Home corruption, migration to newer Linux versions, or accidental deletion of shared libraries.

Should I restart the entire Oracle EBS environment?

Not necessarily. After resolving the missing library dependency, restarting Oracle HTTP Server is often sufficient. If other application tier components were affected, follow your organization's maintenance procedures to restart additional services as required.

About the Author

Rana Abdul Wahid is an Oracle Database and Oracle E-Business Suite Consultant with more than 15 years of experience in Oracle Database Administration, Oracle E-Business Suite Application DBA, Oracle Cloud Infrastructure (OCI), Oracle RAC, Oracle Data Guard, RMAN Backup & Recovery, Linux/Unix Administration, MySQL, Microsoft SQL Server, PostgreSQL, and enterprise infrastructure management.

His expertise includes Oracle E-Business Suite cloning, Oracle HTTP Server administration, Oracle WebLogic Server, AutoConfig, Linux administration, middleware troubleshooting, Oracle Cloud Infrastructure (OCI), and enterprise production support.

Learn more about the author →

Conclusion

The libdb.so.2 shared library error is a common cause of Oracle HTTP Server startup failures, particularly after Oracle E-Business Suite cloning, operating system upgrades, or migrations to newer Linux platforms. Although creating a symbolic link may resolve the issue, successful troubleshooting begins with identifying the actual dependency and verifying that an appropriate Berkeley DB library is already available on the system.

By following a structured troubleshooting process—reviewing Oracle HTTP Server logs, validating dependencies with ldd, confirming installed Berkeley DB libraries, updating the shared library cache when necessary, and thoroughly testing Oracle EBS after the repair—administrators can restore application availability while minimizing the risk of future compatibility issues.

Final Oracle EBS DBA Recommendation

Always diagnose missing shared library errors before applying fixes. Verify the dependency with ldd, confirm library compatibility, avoid unsupported symbolic links, maintain consistent operating system package versions across Oracle EBS environments, and validate Oracle HTTP Server, Oracle Forms, and OA Framework functionality after every maintenance activity. These practices provide a stable, secure, and production-ready Oracle E-Business Suite environment.

Found this guide helpful? Visit the Oracle Error Codes Guide for more Oracle Database, Oracle E-Business Suite, Oracle HTTP Server, Linux administration, and enterprise troubleshooting articles.

Oracle Database Error Solutions & DBA Knowledge Base