Oracle Database Error Solutions & DBA Knowledge Base

Welcome to Oracle Database Error Solutions, a professional technical knowledge base dedicated to helping Oracle Database Administrators, Oracle E-Business Suite administrators, developers, and IT professionals troubleshoot Oracle Database and Oracle Linux issues with confidence.

This website provides practical, real-world troubleshooting guides based on hands-on Oracle administration experience. You'll find detailed solutions for Oracle Database errors, RMAN backup and recovery, Data Guard, ASM, RAC, Oracle Linux administration, Oracle E-Business Suite (EBS), cloning, performance tuning, patching, installation, and day-to-day DBA tasks.

Whether you're resolving ORA-27101, ORA-28040, ORA-01555, ORA-12154, ORA-01017, or other Oracle errors, our step-by-step articles are designed to save you time and help you solve problems efficiently.

ORA-00845: MEMORY_TARGET Not Supported on This System – Complete Oracle DBA Solution Guide

ORA-00845: MEMORY_TARGET Not Supported on This System – Complete Oracle DBA Guide

📅 Last Updated: August 2026

This guide has been completely updated for Oracle Database 11g, 12c, 18c, 19c, 21c, and Oracle Database 23ai running on Oracle Linux, Red Hat Enterprise Linux (RHEL), CentOS, Rocky Linux, AlmaLinux, and other supported Linux distributions. It explains Oracle Automatic Memory Management (AMM), Linux shared memory (/dev/shm), MEMORY_TARGET configuration, root causes of ORA-00845, and production-ready troubleshooting techniques.


One of the most common Oracle startup errors encountered after installing Oracle Database or changing memory parameters is:

ORA-00845: MEMORY_TARGET not supported on this system

This error usually appears when starting the database after enabling Automatic Memory Management (AMM) by configuring the MEMORY_TARGET or MEMORY_MAX_TARGET initialization parameters.

Although the error appears to indicate an Oracle configuration problem, the actual cause is typically related to the Linux shared memory filesystem (/dev/shm). If this filesystem is too small, incorrectly mounted, or unavailable, Oracle cannot allocate the shared memory required by AMM and refuses to start the instance.

This guide explains why ORA-00845 occurs, how Oracle memory management works, how Linux shared memory affects database startup, and how to permanently resolve the issue in production environments.

Quick Solution

Verify that the Linux /dev/shm filesystem is mounted and large enough to support the configured MEMORY_TARGET. Increase the shared memory size if necessary, update /etc/fstab for persistence, or consider using Automatic Shared Memory Management (ASMM) instead of AMM if it better suits your environment.


What Does ORA-00845 Mean?

ORA-00845 indicates that Oracle Database cannot initialize Automatic Memory Management because the operating system does not provide sufficient shared memory resources required by the configured memory parameters.

The error commonly occurs during database startup after setting one or both of the following parameters:

  • MEMORY_TARGET
  • MEMORY_MAX_TARGET

Oracle validates the availability of shared memory before opening the instance. If the required memory cannot be allocated, the startup process terminates with ORA-00845.


Understanding Oracle Automatic Memory Management (AMM)

Automatic Memory Management (AMM) enables Oracle Database to dynamically manage both the System Global Area (SGA) and the Program Global Area (PGA) using a single memory target.

Instead of manually allocating memory to individual components, Oracle automatically redistributes memory between the SGA and PGA based on workload requirements.

This simplifies memory administration, particularly for small and medium-sized environments.


AMM Architecture

               MEMORY_TARGET
                     │
        ┌────────────┴────────────┐
        │                         │
        ▼                         ▼
   System Global Area       Program Global Area
        (SGA)                      (PGA)
        │                         │
        └────────────┬────────────┘
                     ▼
       Dynamic Memory Redistribution

Oracle automatically adjusts memory allocation between these areas to improve overall database performance.


AMM vs ASMM

Feature AMM ASMM
Controls SGA Yes Yes
Controls PGA Yes No
Uses MEMORY_TARGET Yes No
Requires /dev/shm Yes No
Production Recommendation Suitable for many environments Often preferred for large production databases

How Linux Shared Memory Works

Oracle AMM depends on the Linux shared memory filesystem, which is typically mounted as:

/dev/shm

This tmpfs filesystem provides memory-backed shared storage used by Oracle to allocate memory required for Automatic Memory Management.

If /dev/shm is too small or unavailable, Oracle cannot allocate the requested memory and ORA-00845 is generated.


Oracle Memory Architecture

Oracle Database

        │

        ▼

Automatic Memory Management

        │

        ▼

MEMORY_TARGET

        │

        ▼

Linux /dev/shm

        │

        ▼

Shared Memory Allocation

        │

        ▼

Database Startup

Typical Symptoms

Administrators commonly observe the following:
  • Database fails to start.
  • ORA-00845 appears during STARTUP.
  • Instance terminates immediately after initialization.
  • AMM configuration fails after reboot.
  • Oracle installation completes successfully but the database will not open.
  • Startup succeeds after disabling MEMORY_TARGET.

Business Impact

Failure to resolve ORA-00845 can result in:
  • Production database outage.
  • Application downtime.
  • Delayed deployments.
  • Failed patching or upgrade activities.
  • Backup and recovery interruptions.
  • Business service disruptions.

Common Root Causes

  • /dev/shm is smaller than MEMORY_TARGET.
  • /dev/shm is not mounted.
  • Incorrect tmpfs configuration.
  • Invalid MEMORY_TARGET value.
  • Improper Linux memory configuration.
  • Virtual machine memory limitations.
  • Container runtime shared memory restrictions.
  • Operating system changes after reboot.

Before You Begin

Before modifying Oracle memory parameters, verify:
  • The database parameter file (SPFILE or PFILE) is available.
  • You have root access for Linux configuration changes if required.
  • Sufficient physical RAM exists on the server.
  • The database is using AMM rather than ASMM.
  • You have a current backup of the initialization parameter file.
Production Oracle DBA Recommendation

Do not simply disable MEMORY_TARGET to bypass ORA-00845 without understanding the underlying cause. First verify the size and status of /dev/shm, review your Oracle memory configuration, and ensure the operating system is correctly configured to support the chosen memory management method.


Step 1 – Verify Oracle Memory Parameters

Before making operating system changes, verify the current Oracle memory configuration.

Connect as SYSDBA and check the memory-related initialization parameters:

SHOW PARAMETER memory;

SHOW PARAMETER sga;

SHOW PARAMETER pga;

Typical output may include parameters such as:

  • MEMORY_TARGET
  • MEMORY_MAX_TARGET
  • SGA_TARGET
  • SGA_MAX_SIZE
  • PGA_AGGREGATE_TARGET

If MEMORY_TARGET is configured, Oracle expects sufficient shared memory to be available through /dev/shm.


Step 2 – Check the Size of /dev/shm

The most common cause of ORA-00845 is an undersized shared memory filesystem.

Check the current configuration:

df -h /dev/shm

Example:

Filesystem      Size   Used  Avail Use%

tmpfs           2G     20M   1.98G   1%

Compare the available size with the configured MEMORY_TARGET. The shared memory filesystem should be large enough to accommodate Oracle's memory requirements.


Step 3 – Verify the Mount Configuration

Ensure that /dev/shm is mounted correctly.

mount | grep shm

Typical output:

tmpfs on /dev/shm type tmpfs

If no output is returned, the shared memory filesystem may not be mounted correctly.


Step 4 – Increase the Size of /dev/shm

If the shared memory filesystem is too small, increase its size.

Example (temporary until reboot):

mount -o remount,size=8G /dev/shm

Replace 8G with a value appropriate for your Oracle memory configuration.


Step 5 – Make the Change Persistent

Update /etc/fstab so that the new shared memory size is retained after a reboot.

Example entry:

tmpfs   /dev/shm   tmpfs   defaults,size=8G   0 0

After modifying /etc/fstab, verify the syntax before rebooting the server.


Step 6 – Restart the Shared Memory Filesystem

If permitted by your maintenance procedures, remount the filesystem or reboot the server to activate the new configuration.

Verify the result:

df -h /dev/shm

Confirm that the reported size matches the updated configuration.


Step 7 – Start the Database

After correcting the shared memory configuration, start the Oracle instance.

sqlplus / as sysdba

STARTUP;

If the shared memory configuration is correct, the database should start successfully without ORA-00845.


Alternative Solution – Use ASMM Instead of AMM

Some production environments choose Automatic Shared Memory Management (ASMM) instead of AMM because it does not rely on /dev/shm in the same way.

Typical ASMM configuration:

MEMORY_TARGET=0

MEMORY_MAX_TARGET=0

SGA_TARGET=6G

PGA_AGGREGATE_TARGET=2G

ASMM gives administrators greater control over SGA sizing while managing the PGA separately.


Virtual Machine Considerations

  • Verify that sufficient RAM has been assigned to the virtual machine.
  • Confirm that the hypervisor is not restricting available memory.
  • Ensure /dev/shm is configured correctly after VM cloning.
  • Review ballooning or memory overcommit settings if applicable.

Oracle RAC Considerations

  • Verify shared memory configuration on every cluster node.
  • Ensure consistent Oracle memory parameters across all instances.
  • Validate node-specific operating system settings.
  • Test instance startup individually after configuration changes.

Container and Docker Considerations

Containerized Oracle deployments often allocate a smaller shared memory segment by default.

When deploying Oracle Database in Docker or similar container platforms, ensure that the shared memory allocation is sufficient for the configured Oracle memory parameters.


Production Troubleshooting Checklist

Verification Status
MEMORY_TARGET Verified
MEMORY_MAX_TARGET Verified
/dev/shm Mounted
/dev/shm Size Verified
/etc/fstab Updated
Shared Memory Remounted
Database Startup Tested
Alert Log Reviewed

Production Case Study

Following a migration to Oracle Linux, an Oracle Database 19c instance failed to start with ORA-00845 immediately after enabling Automatic Memory Management. Investigation showed that /dev/shm was limited to 2 GB, while MEMORY_TARGET had been configured to 6 GB.

The DBA increased the size of /dev/shm, updated /etc/fstab for persistence, verified the new configuration after remounting the filesystem, and successfully restarted the database without further changes to the Oracle memory parameters.


Oracle Memory Management Best Practices

Proper memory configuration is essential for Oracle Database stability and performance. Whether using Automatic Memory Management (AMM) or Automatic Shared Memory Management (ASMM), administrators should regularly review memory settings and operating system resources.

  • Size /dev/shm appropriately before enabling AMM.
  • Keep MEMORY_TARGET below the available shared memory capacity.
  • Use ASMM for large production databases when appropriate.
  • Monitor memory usage regularly using Oracle performance views.
  • Review memory settings after operating system upgrades.
  • Validate memory configuration after virtualization or cloud migrations.
  • Maintain current backups of SPFILE and PFILE.
  • Document all Oracle memory configuration changes.
  • Monitor alert logs for memory-related warnings.
  • Perform capacity planning before increasing Oracle memory parameters.

Common Oracle DBA Mistakes

  • Setting MEMORY_TARGET larger than /dev/shm.
  • Forgetting to update /etc/fstab after resizing shared memory.
  • Ignoring Oracle alert log messages.
  • Changing Oracle memory parameters without verifying available physical RAM.
  • Using AMM in environments where ASMM is more appropriate.
  • Not testing database startup after memory changes.
  • Overlooking container or virtual machine shared memory limitations.
  • Failing to back up the SPFILE before modifying initialization parameters.
  • Assuming a reboot alone will resolve ORA-00845.
  • Not validating configuration changes across all RAC nodes.

Useful Oracle and Linux Commands

Display Oracle Memory Parameters

SHOW PARAMETER memory;
SHOW PARAMETER sga;
SHOW PARAMETER pga;

Check Shared Memory Filesystem

df -h /dev/shm

Verify Shared Memory Mount

mount | grep shm

Review Oracle Alert Log

tail -100 alert_SID.log

Display Physical Memory

free -h

Restart Oracle Instance

sqlplus / as sysdba

SHUTDOWN IMMEDIATE;

STARTUP;

Troubleshooting Flowchart

ORA-00845

        │

        ▼

Check MEMORY_TARGET

        │

        ▼

Check /dev/shm Size

        │
        ├────────────► Too Small
        │                 │
        │                 ▼
        │      Increase /dev/shm
        │
        ▼

Verify Mount

        │
        ├────────────► Not Mounted
        │                 │
        │                 ▼
        │      Mount /dev/shm
        │
        ▼

Update /etc/fstab

        │

        ▼

Restart Database

        │

        ▼

Database Starts Successfully

Frequently Asked Questions (FAQ)

What causes ORA-00845?

The error is most commonly caused by insufficient or unavailable Linux shared memory (/dev/shm) when Oracle Automatic Memory Management is enabled.

Can I disable MEMORY_TARGET to resolve the issue?

Yes, switching to ASMM by disabling MEMORY_TARGET and configuring SGA_TARGET and PGA_AGGREGATE_TARGET separately is a valid alternative. However, first determine whether AMM is appropriate for your environment before changing the memory management model.

How large should /dev/shm be?

It should be at least large enough to accommodate the configured MEMORY_TARGET, while also considering overall operating system memory requirements and Oracle best practices.

Does ORA-00845 occur only on Linux?

The error is primarily associated with Linux systems using tmpfs shared memory for AMM. Other operating systems use different mechanisms for shared memory management.

Should production databases use AMM or ASMM?

Both are supported. Many large production environments prefer ASMM because it provides more predictable control over SGA sizing, while AMM is often convenient for smaller or less complex deployments.


Related Oracle Articles


About the Author

Rana Abdul Wahid is an Oracle Database 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.

He has implemented Oracle memory management, performance tuning, database migrations, backup and recovery, and high-availability solutions across numerous production environments. His articles are based on practical Oracle DBA experience and provide reliable, production-tested solutions for database professionals.

Learn more about the author →


Conclusion

ORA-00845 is not simply an Oracle configuration error—it is an indication that the operating system cannot provide the shared memory resources required by Automatic Memory Management. By verifying MEMORY_TARGET, correctly sizing and mounting /dev/shm, updating /etc/fstab, and following Oracle memory management best practices, DBAs can permanently resolve the issue and prevent it from recurring.

A structured troubleshooting process that includes reviewing Oracle parameters, validating Linux shared memory, and testing the database startup ensures reliable operation across standalone servers, RAC clusters, virtual machines, cloud environments, and containerized deployments.

Final Oracle DBA Recommendation

Before enabling Automatic Memory Management in any production environment, verify that the operating system is fully prepared to support it. Proper planning of physical memory, /dev/shm sizing, and Oracle initialization parameters will help avoid startup failures, reduce downtime, and provide a stable foundation for long-term database performance.

Found this guide helpful? Explore the Oracle Error Codes Guide for more production-tested Oracle Database, Oracle E-Business Suite, Linux, and enterprise administration tutorials.

Comments