New 19c Instance: Memory, Time Zone, and Listener Failures
A new production instance is being built on a virtual machine with 64GB RAM, 16 vCPUs, and a 200GB system disk. The installer configures MEMORY_TARGET=40G. Startup fails with ORA-00845: MEMORY_TARGET not supported on this system; /dev/shm is 8GB. After switching to hugepages, the instance starts. A clone from the production database then fails during import with ORA-39405: Oracle Data Pump does not support importing a time zone version that is newer than the target. The source is at DST version 32; the new home is at version 31. Meanwhile, the new instance does not register with the listener because an older 12c home is earlier in PATH, and a second service name appears under the wrong home. The change window closes in four hours.
1. Explain the ORA-00845 failure and give the exact remediation sequence, including hugepages sizing.
Read the worked answer
MEMORY_TARGET requires shared memory backed by /dev/shm when Automatic Memory Management is used. The target was 40GB, but /dev/shm was 8GB, so startup failed before the database could open.
Two valid paths:
- Increase
/dev/shmto at least 40GB and remount it, keeping AMM. This is simple but leaves AMM in place. - Switch to hugepages, which is better for a 40GB SGA. AMM cannot use hugepages, so set
MEMORY_TARGET=0, configureSGA_TARGETandPGA_AGGREGATE_TARGET, and size hugepages.
Hugepages math: with 2MB pages, 40GB needs 20,480 pages, plus overhead for the instance and other processes. Set vm.nr_hugepages to roughly 21,000–22,000, raise memlock limits for the oracle user, and disable transparent hugepages. Then start the instance and confirm v$sgainfo shows hugepage allocation.
Do not simply lower MEMORY_TARGET to 8GB to make startup succeed; that would under-size the SGA for a 64GB host and cause performance problems later. After the fix, verify ipcs -m and the alert log for hugepage messages.
2. How do you resolve the ORA-39405 time zone version mismatch without rebuilding the target database?
Read the worked answer
The target home has DST version 31, but the source is at 32. Data Pump intentionally refuses to import data whose time zone semantics are newer than the target, because timestamps with time zone could be misinterpreted.
Correct fix: apply the newer DST patch to the target Oracle home so the binaries include version 32, then upgrade the database time zone. Run utltz_upg_check.sql to see the current version and any affected tables, then utltz_upg_apply.sql (or the equivalent DBMS_DST upgrade procedure) to move the database from 31 to 32. Confirm with SELECT * FROM v$timezone_file and by checking DBMS_DST output.
Do not use the Data Pump TZ_VERSION parameter as a workaround here; that parameter is for specifying the target version at export time and does not make an older target accept newer data.
Sequencing: patch the home first, restart the instance, upgrade the time zone, then rerun the import. Validate a sample of TIMESTAMP WITH TIME ZONE values after import. If the patch cannot be applied within the window, defer the import rather than risk silent time zone corruption.
3. The service registers under the wrong Oracle home and a duplicate service name appears. What is the diagnostic and corrective sequence?
Read the worked answer
This is an environment and registration problem, not a database problem. The older 12c home earlier in PATH means the wrong lsnrctl, oracle binary, or ORACLE_HOME is being used.
Diagnose: run which lsnrctl, echo $ORACLE_HOME, and lsnrctl status from a clean shell. Check lsnrctl services to see which home and instance are registered. Look at listener.ora for static entries, and check LOCAL_LISTENER and REMOTE_LISTENER parameters in the new instance.
Correct: set ORACLE_HOME and PATH explicitly for the 19c home, or use a wrapper script; remove the stale static entry from listener.ora; set LOCAL_LISTENER to the correct address; and restart the listener from the 19c home. If Grid Infrastructure manages the listener, use srvctl rather than manual lsnrctl changes so the configuration survives restarts.
Verify: lsnrctl services should show one service name under the 19c home, and a test connection using the full connect descriptor should succeed. Document the environment setup to prevent the same ambiguity on the remaining builds.