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.
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_TARGETMEMORY_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/shmis smaller thanMEMORY_TARGET./dev/shmis not mounted.- Incorrect
tmpfsconfiguration. - Invalid
MEMORY_TARGETvalue. - 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.
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_TARGETMEMORY_MAX_TARGETSGA_TARGETSGA_MAX_SIZEPGA_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/shmis 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/shmappropriately before enabling AMM. - Keep
MEMORY_TARGETbelow 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_TARGETlarger than/dev/shm. - Forgetting to update
/etc/fstabafter 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
- SYS AS SYSDBA Should Require Password
- ORA-01555: Snapshot Too Old – Complete Guide
- ORA-01017: Invalid Username/Password – Complete Troubleshooting Guide
- Oracle Error Codes Guide
- About the Author
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.
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.
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
Post a Comment