ITPub博客

由于朋友的一个bi数据库最近用户增加，日志增加很多，每天有2000w行的用户日志，需要分析，但机器还是原来的一个32位的pc机，速度比较慢，报表需要10个小时才能出来，上头不能及时看到报表，很是着急！我先想32位的对于内存使用不好，有1.7G的限制，想先突破，我参考了http://yangtingkun.itpub.net/post/468/492617，但是发现出现ora错误 ORA-00371: not enough shared pool memory, should be atleast 72265318 bytes要注意的是，打开这个参数后DB_CACHE_SIZE 就不能用了，否则启动的时候会报ORA-00385: cannot enable Very Large Memo

users: 1815331行 index: inx_mobilephone inx_status pk_usernamespool: 1073行 pk_usernameSQL> SQL> select spool.username, spool.sender, spool.message, spool.sid, users.mobilephone from spool, users where spool.username = users.username and users.status = '0' and spool.sender!='pica' and spool.sender!='@pica' and users.mobilephone is not null and rownum <= 30; 2 3 4 5 no rows selectedElapsed: 00:00:01.21Execution Plan--------------------------------------------------------

rac turning工作中,一直在使用RAC环境的数据库,当然我是以9i见多.对于RAC的一些性能的调整,一直是一个比较大的问题.这里将部分自己的经验以及来自其他参考的文献写下这样的笔记.以方便自己,也方便别人.我们知道,在RAC环境中，实例间是通过内联方式来相互传递信息的，如果期间出现问题，可能会造成数据库性能严重下降，这里主要针对部分情况给出一些解决的方案。9iRAC中通过cache funsion来减少由于ping block时所产生的磁盘竞争，但都需要通过访问远程实例来写。相反，一个RAC副本dirty 从buffer中通过cf同步到远程实例中进行写入。这个功

http://www.itpub.net/showthread.php?s=&threadid=881497处理如下:前几天sp报表出现了:"db file scattered read " 15,129,548 37,247 45.83所占比例很高,并且buffer hit不到50%,很奇怪,我的Buffer Cache: 2,560M应该不会出现这个问题我找到orderd by gets,发现第一句就是: CPU Elapsd Old Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value--------------- ------------ --------------

a和b表都分别有350W条数据,在a表和b表都以username为主键;这个查询是找出存在在a表但不存在在b表的usernameselect username,mobilephone from a where username not in (select username from b );Statistics---------------------------------------------------------- 403 recursive calls 91 db block gets 10804761 consistent gets 30631 physical reads 13748 redo size 184 bytes sent via SQL*Net to client 224 bytes received via SQL*Net from client 1 SQL*Net r

PROCEDURE DBMS_UTILITY.ANALYZE_SCHEMA SpecificationSpecification: procedure analyze_schema(schema varchar2, method varchar2, estimate_rows number default null, estimate_percent number default null, method_opt varchar2 default null);Description: Analyze all the tables, clusters and indexes in a schema. Input arguments: schema Name of the schema. method One of ESTIMATE, COMPUTE or DELETE. If ESTIMATE, then either estimate_rows

注意: 下面这种情况从vcard表里返回的数据多,这时用exists效率高select *from day_onlinenum o where not exists (select username from vcard v where v.username = o.username);下面day_onlinenum返回的数据少,所以用in效率高select count(*) from vcard where username in (select username from day_onlinenum)[@more@]

$ORACLE_HOME/rdbms/admin/ashrpt.sqlstatistics_level需要设为typical,不能设为basic,否则不能产生报表[@more@]

这两个参数是在oracle 9i对执行计划的优化开始发挥影响。OPTIMIZER_INDEX_CACHING该初始化参数表示一个百分比，0％～99％，缺省值0 ，对cbo来说，意味着0％的数据块（使用索引访问）可以在oracle‘s SGA的buffer cache中发现。即所有的对索引的访问都将需要物理读（每一个对buffer cache的逻辑读都产生一个对I/o子系统的物理读），也可以看作是：对buffer cache 0％的hit ratio。该参数只影响CBO计算访问索引块时候的成本，和涉及的表无关。This parameter applies only to the CBO’s calculations of accesses for blocks in an index,

这两个等待事件，一般都是成对出现。在以前我对这两个事件的理解始终存在着误解，现在重新整理归纳如下： 这两个事件描述的是 blocks在内存中存储的情况，而不是从disk中读取的情况。也就是说，如果读取的blocks在内容中是连续存放的，那么就触发的是db file sequential read事件；如果在内容中存放的是离散的，那么就是db file scattered read 这两个事件是由unix中两个函数来对应：read() 和readv()； 其中，read()读取的是contiguous blocks 并且存放的也是contiguous area，这对应的就是db file sequential file； readv()读取的是con

library cache lock等待事件的概述：library cache lock 是在争抢library cache中的资源而造成的资源等待，它有3个参数：p1 对象的地址；p2 锁的地址； p3 namespace等，确定是表、包、索引等。 对这个lock的等待，pmon是1秒，其它进程都是3秒 出现这个等待时，经常表现的症状是：我们无法进行一些查询，甚至不能desc table_name来查看某个內容。由于等待信息不出现在v$lock中，所以，我们根据v$lock不能够确定其中的原因 解决library cache lock的方法：analyze system state dump： 我们可以通过systemstate事件，来查看所有oracle 进

log file switch(archiving needed) 日志切换的时候由于日志组循环使用了一圈但日志归档还没有完成，通常是io有严重问题， 可增大日志文件和增加日志组，调整log_archive_max_processes，如果发生(checkpoint incomplete) 错误信息，则说明当日志切换的时候由于日志组循环使用了一圈但将被使用的日志组中的checkpoint还没有完成造成， 通常是io有严重问题，可增大日志文件和增加日志组 log file sync(这个到可能是log_buffer太大的反作用) 当用户commit的时候通知lgwr写日志但lwgr正忙，造成的可能原因是commit太频繁或者lgwr一次写日志时

buffer busy wait 与 free buffer wait 的区别在于：前者指的是多个session对于同一个block的读取竞争；后者指的是，在buffer cache中，LRU列表中已经没有了空闲buffer space来接纳新的block信息。一般而言，发生buffer busy wait是由于： 1. The block is being read into the buffer by another session, so the waiting session must wait for the block read to complete. 等待另外一个session读取动作的完成 2. Another session has the buffer block locked in a mode that is incompatible with the waiting s

在data buffer中，所有的块都在一个hash table 的 link list 中。每一个 hash chain 都由一个single child latch 保护着。一个latch必须要得到该latch 才能够扫描该 hash chain 以保证该hash chain 上的blocks 不被修改 引发 cache buffer chain latch 的竞争的原因大概由如下原因：1. buffer chain 太长了： 太长的意义是指：lots of blocks all hashing to the same list (eg: having hundreds of consistent read versions of the same block and having hundreds of blocks on a list can add up) 增加 DB_BLOCK_LRU_LATCHES 参数2.

http://carson.yculblog.com/archive.109027.html[@more@]

DEFINE TABLE : SCORE : using for save the students' score informations STUDENTS : the base information of studentsDEFINE COLUMNS : STUNO : the students' ID in the University STUNAME : students' name COURSENAME : course name COURSESCORE : the study-results of the reference course CLASSNAME : where the students study in STUGRADE : the students grade TERMNAME : the term which the reference course studiedNOW BEAGIN TO WRITE DOWN THE STATEMENT HERE BLOW THIS LINE ! MERG