【丹臣】Shared Pool与Processes参数的关系
大家都知道，我们使用ORACLE数据库时，常常会为实例配置一个processes参数，此参数顾名思义，就是设置整个数据库系统可以启动多少个进程(包括系统自己的后台进程)设置不合理的processes参数值，会导致实例无法启动。此参数还有其它许许多多的含义和作用，影响着数据库系统的运行。比如，ORACLE在哪里为其分配内存,分配多大内存？此内存信息在ORACLE instance级的作用？为什么processes参数是一个静态参数？通过本文，相信大家能找到一个的答案。下面是通过一些测试，来回答上述问题。
ORACLE 例程已经启动。
Total System Global Area 201326592 bytes
Fixed Size 1289676 bytes
Variable Size 130023988 bytes
Database Buffers 62914560 bytes
Redo Buffers 7098368 bytes
SQL>
SQL>
SQL> show parameter processes
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
aq_tm_processes integer 0
db_writer_processes integer 1
gcs_server_processes integer 0
job_queue_processes integer 10
log_archive_max_processes integer 2
processes integer 100
SQL>
SQL> alter system set processes=5000 scope=spfile;
系统已更改。
SQL> shutdown abort;
ORACLE 例程已经关闭。
SQL> startup nomount;
ORA-00371: not enough shared pool memory, should be atleast 439686348 bytes
从上面的错误说明，oracle会根据processes参数的值在共享池中分配一定数量的内存，参数值越大，分配的内存也越多。
将processes参数调整到100个，重新启动系统
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
aq_tm_processes integer 0
db_writer_processes integer 1
gcs_server_processes integer 0
job_queue_processes integer 10
log_archive_max_processes integer 2
processes integer 100
SQL> select * from v$sgastat where pool='shared pool' and name like '%process%';
POOL NAME BYTES
------------ -------------------------------------------------- ----------
shared pool generic process shared st 12
shared pool ksb ci process list (each 348
shared pool process count for each CI 288
shared pool ksb cic process list 288
shared pool Background process state 48
shared pool process group array 25352
shared pool ksb process so list 288
shared pool processes 400 --100个进程要在共享池中分配400字节
已选择8行。
修改processes参数的值，再次启动系统
系统已更改。
shutdown immediate;
startup;
SQL> select * from v$sgastat where pool='shared pool' and name like '%process%';
POOL NAME BYTES
------------ -------------------------------------------------- ----------
shared pool generic process shared st 12
shared pool ksb ci process list (each 348
shared pool process count for each CI 288
shared pool ksb cic process list 288
shared pool Background process state 48
shared pool process group array 25352
shared pool ksb process so list 288
shared pool processes 1200 --300个进程要在共享池中分配1200字节
已选择8行。
修改processes参数的值，再次启动系统
系统已更改。
shutdown immediate;
startup;
SQL> select * from v$sgastat where pool='shared pool' and name like '%process%';
POOL NAME BYTES
------------ -------------------------------------------------- ----------
shared pool generic process shared st 12
shared pool ksb ci process list (each 348
shared pool process count for each CI 288
shared pool ksb cic process list 288
shared pool Background process state 48
shared pool process group array 25352
shared pool ksb process so list 288
shared pool processes 2000 --500个进程要在共享池中分配2000字节
已选择8行。
从上面几次修改processes参数的值，可以看出每个进程将会在shared pool中分配4字节内存，那此4字节信息是什么呢？我们查看如下的v$process视图
名称 是否为空? 类型
----------------- -------- ---------------
ADDR RAW(4)
PID NUMBER
SPID VARCHAR2(12)
...
SQL> select addr from v$process;
ADDR
--------
21528900
21528EF0
215294E0
21529AD0
2152A0C0
2152A6B0
2152ACA0
2152B290
2152B880
2152BE70
2152C460
2152CA50
2152D040
2152D630
2152DC20
2152E210
2152E800
2152EDF0
已选择18行。
字段ADDR字段刚好为4字节 ,在共享池中保存process进程的信息很有可能就是其地址信息，知道了其地址，也就知道了PGA在哪里，从PGA里的数据结构就可以知道系统进程号等等之类的东西。PMON进程也是利用此信息，在pmon timer到来之际，通过地址信息，检查各数据库服务器进程的状态；此地址信息也是执行alter system kill session命令的重要纽带。怎样从Shared Pool到PGA，或者说怎样从PGA到Shared Pool?共享池中保存process进程的信息成了关键性的作用
顺便提一句，在ORACLE 9i之上，共享池划分了很多的subpool,在实例启动时，oracle根据processes参数的值，只会挑选其中一个子池来保留此信息
为什么processes参数是一个静态参数？这跟ORACLE关于此参数的内存申请很有关系，个人猜想，此控制结构的信息是以数组的方式保存的，大家都知道数组结构是不能动态扩大的，不像队列或者线性链表。
--EOF--
地址：http://rdc.taobao.com/blog/dba/html/64_sharedpool_processes.html
导入论坛 引用链接 收藏 分享给好友 推荐到圈子 管理 举报
TAG:
