Xing AiMing's Home Page – 邢爱明的个人网站

oracle 9i引入的spfile，简化了参数文件的管理，修改参数后可以直接同步到参数文件，避免了手工修改参数文件的危险工作。 查看是否使用了spfile启动 SYS@orcl>show parameter spfile NAME                     TYPE     VALUE ———————————— ———– —————————— spfile                     string     /opt/ora10g/oracle/product/10. 2.0/db_1/dbs/spfileorcl.ora spfile转换成pfile SYS@orcl>create pfile from spfile; File created. 使用spfile启动后，alter system修改参数，默认是both，即memory + spfile spfile的默认路径: $ORACLE_HOME/dbs/spfile<sid>.ora 10g的测试中，默认使用spfile启动数据库，如果没有的话使用init<sid>.ora的pfile启动，也可以手工指定pfile启动数数据库 SYS@orcl>startup pfile=’$ORACLE_HOME/dbs/initorcl.ora’; ORACLE instance started 参考文章：Oracle9i新特点：SPFILE的使用

原文地址：http://space.itpub.net/110321/viewspace-612585，测试部分请看原文。 每个块都有一个块首部。这个块首部中有一个事务表。事务表中会建立一些条目来描述哪些事务将块上的哪些行/元素锁定。这个事务表的初始大小由对象的INITRANS 设置指定。对于表，这个值默认为2（索引的INITRANS 也默认为2）。事务表会根据需要动态扩展，最大达到MAXTRANS 个条目（假设块上有足够的自由空间）。所分配的每个事务条目需要占用块首部中的23～24 字节的存储空间。注意，对于Oracle 10g，MAXTRANS 则会忽略，所有段的MAXTRANS 都是255。 也就是说，如果某个事物锁定了这个块的数据，则会在这个地方记录事务的标识，当然那个事务要先看一下这个地方是不是已经有人占用了，如果有，则去看看那个事务是否为活动状态。如果不活动，比如已经提交或者回滚，则可以覆盖这个地方。如果活动，则需要等待(闩的作用) 所以，如果有大量的并发访问使用的这个块，则参数不能太小，否则资源竞争将导致系统并发性能下降。 测试了一下ORACLE 并发事务的时候的块分配和ITL 管理, 略去大部分的测试过程,大概的结果小结如下: 1. INITRANS =1 时 并发多个INSERT 事务(本次测试最多5个)的时候并不会由于ITL的争用而等待组塞,ORACLE 采取的策略是每个INSERT事务分配不同的一些块来使用,这样各个会话之间就不会产生冲突，除非段没有多余的块(次种情况与本次的主题无关). 2.INITRANS =1 时 并发多个UPDATE事务(本次测试最多7个)的时候也不会由于ITL的争用而导致等待产生,此时ORACLE除了使用默认的ITL之外，另外动态扩展所需要的ITL，紧紧在非常极端的情况下才会出现等待，(当然应用层面的死锁或等待与本主题无关)。 1) 该BLOCK没有FREE空间了，注意FREE参数的设置不能太小。 2) 该块使用的ITL总数，超过该块允许的ITL的最大值min(round(block_size*0.5/24) – 2 ,255) 。    要达到这样的极端情况实际的生产情况是很难的，应该比业务SQL的死锁出现的概率更小。 小结：创建表的时候除非已经清楚，大部分的情况下没有必要调整INITRANS参数，通常1-4以下足够用了，INITRANS 设置非常大的时候ORACLE 有出现坏块的BUG，另外FREE 参数倒是要注意不能随意改小,除非你已经很清楚更改的后果．

原文地址：http://space.itpub.net/10248702/viewspace-660656，测试部分请看原文。 1. Temp表空间的分配与回收机制? 贪心法分配机制. 使用完后释放Extents,但仍表示已分配. 下一个Session要用时,先从已分配的空间中,先使用,只有不够时,才又再重新申请分配新的Extents. 直到没有Extent可用,则报错:ORA-01652: unable to extend temp segment by 128 in tablespace TEMP 这其实就是Extent的分配机制,只是在临时表空间上的应用而已.  2. 哪些动作会占用到temp表空间 DISK Sort, Temporary Table, Direct write/read path. Create table xx as select * from xx; 3. 临时表空间的相关视图: 3.1 临时表空间的基本信息 dba_tablespaces select tablespace_name, block_size,initial_extent, next_extent, pct_increase, MAX_EXTENTS,status,extent_management,SEGMENT_SPACE_MANAGEMENT   from dba_tablespaces where tablespace_name=’TEMP’; 3.2 临时文件的信息 dba_temp_files  col file_name [...]

原文地址：http://blog.csdn.net/biti_rainy/article/details/35188 热点块的定义         数据库的热点块，从简单了讲，就是极短的时间内对少量数据块进行了过于频繁的访问。定义看起来总是很简单的，但实际在数据库中，我们要去观察或者确定热点块的问题，却不是那么简单了。要深刻地理解数据库是怎么通过一些数据特征来表示热点块的，我们需要了解一些数据库在这方面处理机制的特性。 数据缓冲区的结构         我们都知道，当查询开始的时候，进程首先去数据缓冲区中查找是否存在查询所需要的数据块，如果没有，就去磁盘上把数据块读到内存中来。在这个过程中，涉及到数据缓冲区中LRU链的管理（8i开始以接触点计数为标准衡量buffer冷热从而决定buffer是在LRU的冷端还是热端），关于这部分内容，从oracle concepts 中就能得到详尽的文档，我不准备去论述这部分内容，这也不是本文的重点。现在我们的重点是，到底进程是如何地去快速定位到自己所想要的block的，或者如何快速确定想要的block不在内存中而去进行物理读的。         我们仔细想一想，随着硬件的发展，内存越来越大，cache buffer也越来越大，我们如何才能在大量的内存中迅速定位到自己想要的block？总不能去所有buffer中遍历吧！在此数据库引出了hash的概念（oracle中快速定位信息总是通过hash算法的，比如快速定位sql是否在shared pool size中存在就是通过hash value来定位的，也就是说shared pool size中对象也是通过hash table来管理的），了解一点数据结构的基本知识就知道，hash 的一大重要功能就是快速地查找。举个最简单的例子，假设我们有一个hash table 就是一个二维数组a[200][100],现在有1000个无序数字，我们要从这1000个数字里面查找某个值是否存在，或者说当我们接收到某个数字的时候必须判断是否已经存在，当然，我们可以遍历这1000个数字，但这样的效率就很低。但现在我们考虑这样一种方法，那就是把1000个数字除以200，根据其余数，放在a[200][100]里面(假设相同余数的最大数量不超过100)，余数就是数组的下标。这样，平均来说一个数组a[i]里面可能有5个左右的数字。当我们要去判别一个数字是否存在的时候，对这个数字除以200(这就是一个最简单的hash算法)，根据余数i作为下标去数组a[i]中查找，大约进行5次查找就能判别是否已经存在，这样通过开辟内存空间a[200][100]来换取了时间(当然hash 算法的选取和hash table的大小是一个很关键的问题)。         明白了基本的hash原理之后，我们再来看oracle的block的管理。数据库为这些block也开辟了hash table，假设是a,则在一维上的数量是由参数_db_block_hash_buckets 来决定的，也就是存在hash table a[_db_block_hash_buckets ],从oracle8i开始，_db_block_hash_buckets =db_block_buffers*2。而一个block被放到哪个buckets里面，则是由block的文件编号、块号(x$bh.dbarfl、x$bh.dbablk对应了block的文件属于表空间中的相关编号和block在文件中的编号，x$bh是所有cache buffer的header信息，通过表格的形式可以查询)做hash 算法决定放到哪个bucket的，而bucket里面就存放了这些buffers的地址。这样当我们要访问数据的时候，可以获得segment的extent(可以通过dba_extents查到看，详细的信息来源这里不做探讨)，自然知道要访问的文件编号和block编号，根据文件和block编号可以通过hash算法计算出hash bucket,然后就可以去hash bucket里面去找block对应的buffer。         除此之外，为了维护对这些block的访问和更改，oracle还提供了一种latch来保护这些block。因为要避免不同的进程随意地径直并发修改和访问这些block，这样很可能会破坏block的结构的。latch是数据库内部提供的一种维护内部结构的一种低级锁，latch的生存周期极短(微秒以下级别)，进程加latch后快速的进行某个访问或者修改动作然后释放latch(关于latch不再过多的阐述，那可能又是需要另一篇文章才能阐述清楚)。这种latch数量是通过参数_db_block_hash_latches 来定义的，一个latch对应的保护了多个buckets。从8i开始，这个参数的default规则为: 当cache buffers 少于2052 buffers _db_block_hash_latches  =  power(2,trunc(log(2, db_block_buffers - 4) – 1)) 当cache buffers多于131075 buffers _db_block_hash_latches  =  power(2,trunc(log(2, db_block_buffers - 4) – 6)) 当cache buffers位于2052与131075 buffers之间 [...]

早上发现数据库的wait率特别高： END_TIME    METRIC_NAME                           VALUE METRIC_UNIT ———– ——————————– ———- ——————————– 2011-8-1 上午 Database Wait Time Ratio              98.99 % Wait/DB_Time 主要的等待事件： WAIT_CLASS                     EVENT                          TOTAL_WAIT_TIME   PCT_TIME —————————— —————————— ————— ———- Concurrency                    enq: TX – index contention          4285010000         71 Configuration                  enq: HW – contention                1633063813         27 ACTIVE状态的session有40-50个，95%以上是insert一个大表的语句。 非常奇怪，怎么会有HWM的等待事件。再看一下表空间，已经基本上满了，只剩下一个datafile是AUTOEXTEND。 马上增加了数据文件，再等一会看，数据库恢复正常，活动session控制在5个以下