减轻Shared Pool负载 Parse一次并执行多次        在OLTP类型的应用中,最好的方法是只让一个语句被解析一次,然后保持这个cursor的打开状态,在需要的时候重复执行它.这样做的结果是每个语句只被Parse了一次(不管是soft parse还是hard parse).显然,总会有些语句很少被执行,所以作为一个打开的cursor维护它们是一种浪费.        请注意一个session最多只能使用参数:open_cursors定义的cursor数,保持cursor打开会增加…

原文链接:https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrlstate=23w4l35u5_4&id=1523934.1用途   提出问题,得到帮助并分享您的心得   排错步骤   什么是shared pool?   专用术语   Literal SQL   Hard Parse(硬解析)   Soft Parse(软解析)   完全相同的语句?   Sharable SQL   语句的版本   Library Cac…

[20190319]shared pool latch与library cache latch的简单探究.txt --//昨天看Oracle DBA手记3:数据库性能优化与内部原理解析.pdf 电子书,看了eygle的关于latch之类的测试.--//自己也重复测试看看. --//首先说明一下11g已经不存在这个shared pool latch,改为mutexes.所以测试在10g下进行:--//注意不要在生产系统做这样的测试!! 1.环境:SCOTT@test> @ &r/ver1POR…

一个简单的sequence有什么可以说的呢?如果再这样认为就大错特错了... 也许以下几点高人们都很清楚,但至少对于我来说,之前是陌生的,或者说是忽略的. 1.CREATE SEQUENCE seq;,不带任何参数,那么默认建立的SQL语句是: -- Create sequence  create sequence SEQ minvalue 1 maxvalue 999999999999999999999999999 start with 21 increment by 1 cache 20;…

latch:library cache --desc v$librarycache; latch:library cache用于保护hash bucket.library cache lock保护HANDLE.library cache pin保护library cache object--LCO.从10G开始,library cache lock和library cache pin被MUTEX部分取代.暂时不讨论MUTEX.latch:library cache的数量:SYS@ bys3>se…

INDEX Skip Scan,也就是索引快速扫描,一般是指谓词中不带复合索引第一列,但扫描索引块要快于扫描表的数据块,此时CBO会选择INDEX SS的方式. 官方讲的,这个概念也好理解,如果将复合索引看做是一个分区表,其中分区主键(这里指的是复合索引的首列)定义了存储于此的分区数据.在每个键(首列)下的每行数据都将按照此键排序.因此在SS,首列可以被跳过,非首列可以作为逻辑子索引访问.因此一个“正常”的索引访问可以忽略首列. 复合索引被逻辑地切分成更小的子索引.逻辑子索引的个数取决于初始列的…

如果问题是一个正运行的缓慢的查询SQL,那么就应该对该查询进行调优,避免它耗费过高的CPU资源.如果它做了许多的hash连接和全表扫描,那么就应该添加索引以提高效率. 下面的文章可以帮助判断查询的问题: Note:215187.1 SQLT (SQLTXPLAIN) - Tool that helps to diagnose SQL Note:199083.1 Master Note: SQL Query Performance Overview 实时SQL监控是11g的一个新特性,它能监控正运…

Oracle(用户)进程 以下这些操作都是需要消耗大量CPU资源的:解析大型查询,存储过程编译或执行,空间管理和排序. 下面这几篇文章可以帮助采集关于使用高CPU资源的进程的更多信息: Note:352648.1 How to Diagnose High CPU Usage Problems to the Module Level Note:452358.1 How to Collect Diagnostics for Database Hanging Issues 补充:Oracle用户进程(…

Jobs (CJQ0, Jn, SNPn) Job进程运行用户定义的以及系统定义的类似于batch的任务.检查Job进程占用大量CPU资源的方法,就像检查用户进程一样. 可以根据以下视图检查Job进程运行的状态:DBA_JOBS_* , DBA_SCHEDULER_*, DBA_AUTOTASK_*. 这些进程可能会消耗大量的CPU资源,因为他们无限循环地查询job队列. Note: 8531434.8 Bug 8531434 - Solaris: Excessive CPU by MMNL/C…

http://blog.csdn.net/panfelix/article/details/38347059   buffer pool 和shared pool 详解 http://blog.csdn.net/panfelix/article/details/38347137 shared pool 和buffer pool 详解(之二, Cache Buffers LRU Chain.Cache Buffers LRU Chain闩锁竞争与解决) http://blog.csdn.net/n…