Memory_target cannot be started because of improper settings.

Memory_target cannot be started because of improper settings.

Today, I encountered another "strange" problem during troubleshooting.
The SGA Automatic Storage Management has been disabled in the Test Library. As a result, the shared_pool_size configuration is lost in the spfile file.
The parameters in the test environment are similar to the following:
Sga_max_size big integer 12000 M
Sga_target big integer 0
Shared_pool_size big integer 0
Db_cache_size big integer 6G
Pga_aggregate_target big integer 3147483648

This configuration should be faulty and the shared_pool_size part should be lost. The result shows the current test database. It is found that the shared_pool is more or less 2 GB.

COMPONENT CURRENT_M MIN_M MAX_M SPECCIFIED_M last_1_last_oper_typ GRANULE_M
--------------------------------------------------------------------------------------------------------
Shared pool 2000 992 2000 manual grow 16
Large pool 304 304 512 deferred shrink 16
Java pool 512 512 512 304 STATIC 16
Streams pool 0 0 0 STATIC 16
DEFAULT buffer cache 6224 6144 6352 6144 manual shrink 16
KEEP buffer cache 0 0 0 0 STATIC 16
RECYCLE buffer cache 0 0 0 0 STATIC 16
DEFAULT 2 K buffer cache 0 0 0 0 STATIC 16
DEFAULT 4 K buffer cache 0 0 0 0 STATIC 16
DEFAULT 8 K buffer cache 0 0 0 0 STATIC 16
DEFAULT 16 K buffer cache 0 0 0 0 STATIC 16
DEFAULT 32 K buffer cache 0 0 0 0 STATIC 16
Shared IO Pool 0 0 0 STATIC 16
If the problem persists, it may end up.
But I took a serious look and found that there was still a problem. SGA has around 12 GB, allocated to shared_pool 2 GB, buffer_cache 6 GB, plus large_pool, java_pool has less than 9 GB, where are the remaining parts?

From the overall sga overview
SQL> show sga
Total System Global Area 1.1742E + 10 bytes
Fixed Size 2251264 bytes
Variable Size 5200938496 bytes -- this part is quite different. Based on the current shared_pool + large_pool + java_pool + stream_pool <3G, the remaining 2G may be the final possibility, with no allocated memory space.
Database Buffers 6526337024 bytes
Redo Buffers 12193792 bytes

You may find that many details are potential problems.
First, let's look at the process. The result shows that the owner of a common process is the user name, but now it is the process number.
Xxxxxx 6545 25419 0 00:00:00 pts/7 grep smon
3068 21040 1 0 Oct22? 00:01:21 ora_smon_TESTCUS1
Finally, confirm that if the user name exceeds 8 digits, it will be displayed as a process number, not a problem.

Finally, write shared_pool_size = 4G in spfile, and then report an error when restarting the database.
SQL> startup
ORA-00838: Specified value of MEMORY_TARGET is too small, needs to be at least 13920 M
SQL>

We didn't notice this parameter when we started to check the problem. memory_target was introduced at 11 GB. It is an enhanced version of sga Automatic Storage Management, which can automatically manage sga and pga.
If you have a general understanding of memory_target and the error section, it may be clear at once.
Because the current Memory_target value is 12 GB and sga_max_size are consistent.
In this case, if memory_target is 12 GB and pga is 3 GB at the same time, less than 9 GB is allocated to sga. This is equivalent to setting sga_max_size = 9G.

At this time, re-analyze the error message. We adjusted the shared_pool from 2 GB to 4 GB. In this case, the size of memory_target is required according to the configuration.
Shared_pool_size (4G) + db_cache (6G) + stream pool (0) + large_pool (300 M) + java_pool (300 M) + pga (3G) = around M, and the error message. So far, it can be determined that this problem is caused by improper settings of memory_target.
The memory_target settings still need to restart the database instance. After restarting, check that there is no problem.
It seems that many problems have been noticed in some details. This memory_target was not noticed from the very beginning. According to the customer's dba feedback, they directly used the database created by dbca, this new feature may be introduced at this time, and then the buffer size is changed later. This is a potential problem.

Install Oracle 11gR2 (x64) in CentOS 6.4)

Steps for installing Oracle 11gR2 in vmwarevm

Install Oracle 11g XE R2 In Debian