从总体的sga的概览来看
SQL> show sga
Total System Global Area 1.1742E+10 bytes
Fixed Size 2251264 bytes
Variable Size 5200938496 bytes --这个部分还是有很大的差别。按照目前的shared_pool+large_pool+java_pool+stream_pool<3G,剩下的2G可能就是最后的可能，没有分配的内存空间。
Database Buffers 6526337024 bytes
Redo Buffers 12193792 bytes
带着这种疑问来查问题，可能你看到很多细节都是潜在的问题。
首先来看进程的情况。结果就发现按照常理进程的owner应该显示是用户名，但是现在却是进程号。
xxxxxx 6545 25419 0 12:44 pts/7 00:00:00 grep smon
3068 21040 1 0 Oct22 ? 00:01:21 ora_smon_TESTCUS1
最后确认了下，原来如果用户名超出8位的时候就会显示为进程号,不是问题。
最后在spfile中先写入shared_pool_size=4G,然后重启数据库的时候，就报错了。
SQL> startup
ORA-00838: Specified value of MEMORY_TARGET is too small, needs to be at least 13920M
SQL>
从开始查问题的时候就没有注意到这个参数，memory_target是在11g引入的。算是sga自动存储管理的加强版本，能够自动管理sga和pga。
如果大体了解了memory_target和报错的部分，可能一下子就明朗了。
因为当前的Memory_target的值就是12G和sga_max_size是一致的。
这个时候memory_target是12G，而同时pga是3G,那么分配给sga的部分就只有不到9G,这样的情况就相当于设置了sga_max_size=9G
这个时候重新分析下报错信息。我们把shared_pool从2G调整到了4G。这样的话memory_target的大小按照配置应该需要
shared_pool_size(4G）+db_cache(6G)+stream pool(0)+large_pool(300M）+java_pool(300M)+pga(3G)=13600M左右，和报错的部分基本符合。所以到此为止就可以判定是memory_target的设置不当导致了这个问题。
memory_target的设置还是需要重启数据库实例的。重启后查看就没有问题了。
看来很多问题都在一些细节上注意，这个memory_target从一开始就没有注意到，根据客户dba的反馈，他们是直接使用dbca来建的库，可能就是这个时候引入了这个新特性，然后在后期做了buffer size的变更。才发现这个很潜在的问题。