下面进行参数的调整，这里笔者有一个建议，很多时候启动umount阶段故障都是由于不当的参数修改造成的。在进行参数修改之前，可以使用create pfile进行一下参数备份，可以加快故障出现时候的系统修复速度。
SQL> show parameter spfile
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string /u01/app/oracle/dbs/spfileora11g.ora
SQL> create pfile from spfile;
Done
修改系统参数，将sga和pga的target值设置为0，memory的target设置非0。注意，这个过程很多参数是静态的参数，可以都在spfile可见性中进行修改，之后重启服务器生效。
SQL> alter system set memory_max_target=360m scope=spfile;
System altered
SQL> alter system set memory_target=360m scope=spfile;
System altered
SQL> alter system set sga_target=0m scope=spfile;
System altered
SQL> alter system set sga_max_size=0 scope=spfile;
System altered
SQL> alter system set pga_aggregate_target=0 scope=spfile;
System altered
重新启动数据库服务器，查看参数配置。
SQL> conn / as sysdba
Connected.
SQL> startup force
ORACLE instance started.
Total System Global Area 263651328 bytes
Fixed Size 1344284 bytes
Variable Size 176164068 bytes
Database Buffers 83886080 bytes
Redo Buffers 2256896 bytes
Database mounted.
Database opened.
SQL> show parameter target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 0
db_flashback_retention_target integer 1440
fast_start_io_target integer 0
fast_start_mttr_target integer 0
memory_max_target big integer 360M
memory_target big integer 360M
parallel_servers_target integer 16
pga_aggregate_target big integer 0
sga_target big integer 0
AMM启动之后，系统共享段变为“虚拟”共享段。
[oracle@SimpleLinux dbs]$ ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 163840 oracle 640 4096 0
0x00000000 196609 oracle 640 4096 0
0x01606d30 229378 oracle 640 4096 0