大家都知道，我们使用ORACLE数据库时，常常会为实例配置一个processes参数，此参数顾名思义，就是设置整个数据库系统可以启动多少个进程(包括系统自己的后台进程)设置不合理的processes参数值，会导致实例无法启动。此参数还有其它许许多多的含义和作用，影响着数据库系统的运行。比如，ORACLE在哪里为其分配内存,分配多大内存？此内存信息在ORACLE instance级的作用？为什么processes参数是一个静态参数？通过本文，相信大家能找到一个的答案。下面是通过一些测试，来回答上述问题。
Read more…
前面说到，Oracle9i中每个sub pool的空间下边界是128M，实践证明是偏小的，所以在Oracle10g中，这个边界被调整为256M，在Metalink的一篇文章(Note 396940.1)中还有一种说法，可能500M左右一个sub pool在10.2以后的版本中更加合适，不知道在Oracle11g中是不是对这个设置再次做出调整，因为没有足够的测试环境，我也没有试验。大家如果谁有试验出Oracle11g的sub pool边界大小，欢迎留言给出。Oracle10g的另外一个改进，就是为某些共享对象搜索可用空间的时候，如果在一个sub pool中找不到可用的chunk，可以切换到其他sub pool了，不过还不能做到所有类型的内存请求都能切换。而可以做到在不同子池间切换，对于单个子池空间不够的情况，应该算是比较彻底的解决方案，希望在以后的版本中能更进一步了。
最后介绍一个内部视图X$KSMSP，这个视图保存了每个chunk的详细信息，chunk可以分成四种类型(KSMCHCLS)：
- free：free chunks–未分配的可用chunk。
- recr：recreatable chunks–包含可以被临时移出内存的对象，在需要的时候对象可以被重新创建，如共享sql代码的内存。
- freeabl：freeable chunks–包含session周期或调用的对象，随后可以被释放。但是注意，由于某些中间过程产生的对象不能临时被移出内存(因为不可重建)。
- perm：Permanent memory chunks–包含永久对象.通常不能独立释放，像processes/sessions参数指定的数组控制结构。
如果是R-开头的如R-free类型，则表示该chunk是Shared Reserverd Pool中的内存片。
说点简单的，我说说共享池里面的两个latch
Shared pool latch用来保护共享池内部结构，在分配和释放共享池时需要获得latch，在老化或释放空间时也需要 latch。Oracle9i之前，共享池内存结构是由单独的Shared pool latch保护，从9i开始，如果服务器有4个以上的cpu且shared_pool_size大于250M,Oracle会动态将共享池分为多个子池，最多可以达到7个sub pool，每个子池有自己的free list，lru list及latch。子池的数量可以通过_kghdsidx_count参数来手动调整。
Read more…
在ORACLE 7之前的版本，连接oracle的每一个会话都有一个服务器进程为它服务，这个服务器进程的作用是解析(parse),优化(opimize)客户端提交的PL/SQL或SQL代码.就算客户端向各个服务器进程提交的PL/SQL,SQL代码一样，各个服务器进程并不会share cursor,刚开始采用这种设计方式也并没有什么性能问题。但随着客户端数量的高速增长，以及在OLTP SQL语句执行频率高速增长的情况下，ORACLE 7版本的数据库的这种设计就开始出现了性能问题。当执行一样的SQL或PL/SQL代码时，如果执行计划或其它一些信息可以被所有的服务器进程所共享，而不用重新去产生，那么将可以节约大量的时间。当时oracle已开始意识到此问题，并开始着手进行改进,采用了如下的方法：
1.扩展SGA variable portion
2.提供一种方法来管理和访问SGA variable portion中的shared objects
3.ORACLE内存管理的增强
Recent Comments