HelloDBA

TIPS: 快速建立OUTLINE

fuyuncat — Mon, 15 Mar 2010 02:46:03 GMT

OUTLINE是用于保证语句的执行计划稳定性的一种手段。有的时候，我们也需要借助OUTLINES将一个环境下的语句的执行计划在另外一个环境下（如生产环境下发现的TOP SQL，在测试环境中无法直接重现时）重现，以进行进一步优化。

CBO 中如何计算调整的MBRC

fuyuncat — Wed, 10 Mar 2010 07:30:12 GMT

在CBO的IO模式中，全表扫描的IO代价不是直接由MBRC(db_file_multiblock_read_count)计算来的，而是由一个相应的调整的值（ADJMBRC）计算的. 我将在本文中讨论如何由MBRC和Block Size来计算出ADJMBRC.

Adjusted MBRC formual in CBO

fuyuncat — Wed, 10 Mar 2010 07:22:26 GMT

In IO mode, CBO will calculate IO cost by an adjusted MBRC (ADJMBRC) instead of the MBRC (db_file_multiblock_read_count) directly. We will discuss how to calculate the ADJMBRC with a deduced formula.

CBO代价估算

fuyuncat — Mon, 08 Mar 2010 03:22:28 GMT

CBO有两种模式来估算查询计划的代价：IO和CPU。在IO模式中，代价估算器仅估算IO代价，不考虑CPU代价；而在CPU模式中，估算器会将IO代价和CPU代价都转换为同一单位：读取一个数据块的时间，然后将两部分结果相加，得到最终估算代价。

CBO Cost estimation

fuyuncat — Fri, 05 Mar 2010 08:07:07 GMT

There are 2 kind of CPU mode in CBO, IO & CPU. In IO mode, only IO cost will be calcualted, while in CPU mode, IO and CPU Cycles of processing blocks and rows will both be converted to the same unit, CPU time of one single block, and then be combined together.

NULL IS NOT NULL in execution plan

fuyuncat — Thu, 04 Mar 2010 03:09:52 GMT

NULL IS NOT NULL is means always FALSE. Optimzier will add such filter when it found the logic result of the sub plan tree is FALSE, it will cause to the plan tree will never be executed. When find such filter added by optimizer, it's normally means a logic problem in the SQL.

CBO Statistics data gathering and internal arithmetic analysis -- Sampling

fuyuncat — Wed, 20 Jan 2010 07:34:44 GMT

Statistics data and histogram data are the basic data for Cost Base Optimizer to calculate the cost. They are correct or not, decide if optimizer can get the best execution plan. I will analyze the statistics data gathering internal process and arithmetic in following papers.

CBO Statistics data gathering and internal arithmetic analysis -- Calculating NDV and Density

fuyuncat — Mon, 18 Jan 2010 06:23:13 GMT

CBO Statistics data gathering and internal arithmetic analysis -- Converting to endpoint value

fuyuncat — Wed, 13 Jan 2010 03:06:07 GMT

CBO Statistics data gathering and internal arithmetic analysis -- Frequency or Height Balanaced?

fuyuncat — Mon, 11 Jan 2010 06:13:34 GMT

CBO Statistics data gathering and internal arithmetic analysis -- when will gather histogram data

fuyuncat — Thu, 07 Jan 2010 09:47:08 GMT

《Oracle IO 问题解析》PDF下载

fuyuncat — Tue, 05 Jan 2010 09:22:19 GMT

为了方便阅读，将部分篇幅较长的本站原创文章整理成PDF文件提供下载。

《Oracle 中 ROWNUM 的使用技巧》PDF下载

fuyuncat — Thu, 31 Dec 2009 09:44:54 GMT

为了方便阅读，将部分篇幅较长的本站原创文章整理成PDF文件提供下载。

TIPS: 如何获取数据的存储大小

fuyuncat — Wed, 30 Dec 2009 09:10:55 GMT

有些同学在估算数据的物理存储大小时会使用length函数，实际上这不正确，真正用于获取数据物理字节数的函数是sys_op_opnsize (10g)。length函数获取到的是数据的逻辑长度，而非物理长度。例如数字，逻辑长度是按照10进制得到的，而其物理存储是按照16进制。

《Oracle 10g特性》PDF文档下载

fuyuncat — Fri, 25 Dec 2009 03:20:19 GMT

为了方便阅读，将部分篇幅较长的本站原创文章整理成PDF文件提供下载。

[En] Oracle Row Shipping

fuyuncat — Fri, 25 Dec 2009 01:21:17 GMT

To reduce workload in server, some features were introduced to move some jobs to client side. Row shipping is one of such features. There are steps to process SQL, parsing -> optimzating -> Row Source generating -> result producting. In traditional mode, one job of Row Source gernerator is that choose the columns in SELECT clause from the rows return to client, which named Projection. We could find such information from output DBMS_XPLAN (10g later):

[中]Oracle Row Shipping

fuyuncat — Thu, 24 Dec 2009 05:26:15 GMT

为了降低服务端的负荷，oracle引入一些特性，将部分工作移到客户端去处理。Row shipping就是其中之一。我们知道，Oracle对于SQL的处理由几个步骤组成：解析(Parse)->优化(Optimize)->生产数据源(Row Source Generate)->返回结果(Result Product)。在传统模式下，数据源生成组件(Row Source Generator)要做一步工作就是从记录中找出SELECT子句的中出现的字段，返回给客户端，这一过程称为投射（Projection）。我们可以通过DBMS_XPLAN(10g)查看查询计划中的投射字段信息

《Oracle 内存全面分析》PDF下载

fuyuncat — Tue, 22 Dec 2009 01:12:43 GMT

为了方便阅读，将部分篇幅较长的本站原创文章整理成PDF文件提供下载。

《ORA-01555 错误浅析》PDF下载

fuyuncat — Mon, 21 Dec 2009 09:22:44 GMT

为了方便阅读，将部分较长的本站原创文章整理成PDF文件提供下载。

Oracle Redo Strand

fuyuncat — Fri, 18 Dec 2009 06:26:13 GMT

Redo log is a important data to be used to recovery and some other advanced features. A redo entry involved the information about database changing. All of the redo entries should be writen into logfile finally. To avoid disk io waits, oracle allocated a log buffer from sga to cache the redo data. A redo entry is generated in PGA, then it be copied to log buffer by server process. When reach some conditions, LGWR will write the log buffer contents to the logfiles. Log buffer is shared by all of server processes, to protect it, the server process should first request the "redo allocation latch" to allocate buffer from it. Hence, in high concurrent OLTP system, we may observer the redo allocation latch contentions.

Oracle Redo 并行机制

fuyuncat — Fri, 18 Dec 2009 04:05:22 GMT

Redo log 是用于恢复和一个高级特性的重要数据，一个redo条目包含了相应操作导致的数据库变化的所有信息，所有redo条目最终都要被写入redo文件中去。Redo log buffer是为了避免Redo文件IO导致性能瓶颈而在sga中分配出的一块内存。一个redo条目首先在用户内存(PGA)中产生，然后由oracle服务进程拷贝到log buffer中，当满足一定条件时，再由LGWR进程写入redo文件。由于log buffer是一块“共享”内存，为了避免冲突，它是受到redo allocation latch保护的，每个服务进程需要先获取到该latch才能分配redo buffer。因此在高并发且数据修改频繁的oltp系统中，我们通常可以观察到redo allocation latch的等待。

Unwrap 工具更新

fuyuncat — Mon, 23 Nov 2009 09:28:02 GMT

更新了frunwrap，增加了对9i wrap方式的支持。

HowTo: Trace the statistics data gathtering

fuyuncat — Thu, 19 Nov 2009 05:59:21 GMT

Sometimes, we want to know which objects failed to be gathered the stats data after the gathering job complete? What's the reason? We may set an undocumented parameter "TRACE" to capture such information.

Oracle 内存回滚 (In Memory Undo)

fuyuncat — Tue, 17 Nov 2009 03:12:09 GMT

在传统的事务更新过程中，如果一条数据记录被更新，就会从buffer cache中读取/分配一块UNDO数据块，并且立即会写入一条UNDO条目。如果同一个事务中有多条记录被更新，则undo buffer数据块中就会写入多条undo条目。引入IMU后，会从shared pool中分配出一个新的内存池——IMU pool。当一条数据记录被更新，仍然会从buffer cache中读取/分配一块undo数据块，但是，这块undo块并不会立即被更新，而是会在IMU pool中产生一个IMU node，IMU节点通过IMU map与数据记录更新对应。如果事务中有多条记录被修改，则IMU pool中就生产多个IMU nodes，而buffer中的undo block不会发生任何变化。当发生IMU commit或IMU flush时，才会通过IMU map将这些IMU node记录的undo信息写入undo buffer block中。并且，所有这些redo信息会和commit vector一起作为一个Redo条目写入Redo log中。整个过程中UNDO所产生的redo信息则大大减少。

Oracle In Memory Undo

fuyuncat — Mon, 16 Nov 2009 08:16:22 GMT

In traditional undo update, once record be updated, an undo block will be allocated in the buffer cache, 1 new entry will be inserted into the undo block immediately. If several records be updated in the same transaction, several entries generated in the undo buffer as soon as the record updated. At the mean time, each undo entry will also generate redo log entry. After introduced the IMU, new pools named IMU pools will be allocated from shared pool. Once a record be updated, an undo buffer block still be allocted from buffer cache, but without inserting a new entry into the block immediately. It will generate an undo map in the IMU pool, and one IMU node for the record change. If several records be updated, several IMU nodes will be generated in the IMU pool, and the UNDO map be updated correspondly. All of the changes occur in the IMU pool, not modify the undo buffer block. Once commit or the IMU pool be flushed, it will map the IMU nodes as undo entries into the undo block and write to disk. This process is a batch process, just 1 redo entry generated for these changes.

Secret of oracle logical IO: Index Scan

fuyuncat — Wed, 11 Nov 2009 02:29:55 GMT

How to calculate the io of a query? This question is the most concern of dba&developer when we do performance tuning. We know the IO is affected by many factors in different operations, e.g. , high water mark, index height, extents number of a segment, cr UNDO application and so on. However, for the details of the factors in IO calculation formula, are secrets for us. Even work with 10200 event, we can not count up to the final total CRs, because this trace ignored the meta data reads. By monitoring the buffer cache, we can just guess it also reads the segment header for times, and repeat reads for number of extents. From the fixed table sys.x$kcbwh, sys.x$kcbsw, we can find the buffer cache statisitcs data, which are directly related to the io behaviors. By comparing the statistic data before&after the query, we may peek some internal information for the logic IO. However, this view is a db level statistics data, it will be affected by the backgroup processes, we may not get the truth from it. So, is there any other way to find out the secret? Yes! As we know, for each data reads, it will be pined in the cache, means if we can trace the pin behaviors, we will know IO behaviors. Read which block? For what purpose? How many times a block will be red? The switch is the undocumented parameter, "_trace_pin_time".

Secret of oracle logic IO: Sorting

fuyuncat — Tue, 10 Nov 2009 01:14:31 GMT

Secret of oracle logic IO: Current Mode

fuyuncat — Mon, 09 Nov 2009 01:02:38 GMT

Secret of oracle logic IO: Consistent Gets

fuyuncat — Sat, 07 Nov 2009 14:57:13 GMT

Secret of oracle logic IO: Full Table Scan: Part 3

fuyuncat — Fri, 06 Nov 2009 06:34:48 GMT

Secret of oracle logic IO: Full Table Scan: Part 2

fuyuncat — Thu, 05 Nov 2009 09:16:25 GMT

Secret of oracle logic IO: Full Table Scan: Part 1

fuyuncat — Wed, 04 Nov 2009 09:10:41 GMT

事务队列等待（Tx Enqueue）深入分析——其它争用

fuyuncat — Tue, 03 Nov 2009 09:55:08 GMT

在TX等待中，还有一些其它不是很常见的情形会导致共享锁的等待，这类等待在10g就被记录为“enq: TX - contention”事件。例如，在以下情形中会出现“enq: TX - contention”等待事件

事务队列等待（Tx Enqueue）深入分析——外键约束

fuyuncat — Mon, 02 Nov 2009 09:13:51 GMT

如果2个表之间建立了主外键关系，那么对它们的数据操作就会受到外键约束，以保证数据完整性：子表插入数据时，外键键值在主表中必须存在；主表删除时，子表中必须已经没有该键值的数据。如果进行这样的数据操作时，相应数据约束在另外事务里面已经满足（或正导致违反约束），但事务未完成，那么这样的数据操作的事务就会进入等待队列

事务队列等待（Tx Enqueue）深入分析——位图索引维护

fuyuncat — Wed, 28 Oct 2009 08:07:52 GMT

位图索引（Bitmap Index）是一种特殊索引。在普通B+树索引中，所有表数据记录指针都存储在叶子节点上，每一条非空数据在叶子节点上都存储一条记录，而非唯一索引中，同一键值对应多条记录在索引也存储多条记录，每条索引上都存储了对应表数据记录的物理地址，即ROWID。bitmap索引也是一个树状结构，但是每一个键值，无论是否为空、或者一个键对应多条数据记录，在叶子节点上只有一条记录，而对应的每一条表数据记录的物理地址通过映射函数转换，在索引记录中对应一个“位”（bit），所有对应记录的地址转换成“位”后形成一个位图（bitmap）存储在索引记录中。Bitmap索引不仅大大提高了重复值较多（Low Cardinality）的索引的查询效率——对应一个键值，只需读取一次就可以获取到所有表记录的物理地址，而普通索引可能需要读取多次索引后才能获取到全部数据，还减少了索引的存储空间。但是，由于一个键值对应多个数据记录，这就会造成数据更新的麻烦：当多个事务修改同一键值的数据时，都需要在对应的索引记录上加锁，从而导致事务等待：

事务队列等待（Tx Enqueue）深入分析——唯一性约束

fuyuncat — Tue, 27 Oct 2009 06:13:59 GMT

唯一性约束是为了保证某个字段或者某一组字段的每一条记录的数据在表中只村子唯一一条的约束。当向表中插入一条记录（或修改记录）时，如果存在唯一性约束，就需要先检查表中是否已经存在该数据，如果不存在，数据才允许插入。而这一检查过程实际上就是对已有数据的一次查询，因此，每一个唯一性约束都会在表中建立一个对应的唯一索引（Unique Index）。而如果一个事务在插入（或修改）一条数据时，新数据已经在另外一个事务中被插入、或者已有数据在另外一个事务中被删除，相应索引数据记录被加上共享锁，但事务并未结束，此时当前事务就需要进入队列等待另外事务结束，并记录"enq: TX - Row lock contention"事件。

事务队列等待（Tx Enqueue）深入分析——索引争用

fuyuncat — Fri, 23 Oct 2009 06:24:18 GMT

索引争用是和索引块分裂直接相关的。当一个事务需要向一个数据块插入数据时，该数据块正好发生了索引分裂，则插入事务需要等待分裂事务

事务队列等待（Tx Enqueue）深入分析——ITL争用

fuyuncat — Tue, 20 Oct 2009 07:34:11 GMT

我们知道，事务在对数据块中的记录加锁时，需要首先在数据块头部记录下该事务的相关信息，这样一个记录就是一条ITL槽（slot）。ITL TX等待发生在事务请求对数据块中记录加锁时，数据块上没有足够ITL槽。

B-Tree 索引中的数据块分裂——等待事件

fuyuncat — Mon, 19 Oct 2009 07:25:54 GMT

尽管索引分裂是由递归事务控制的，其资源的请求与释放都很短暂，不受用户事务是否结束的影响，但是，在并发环境中，索引分裂仍然会导致一些等待事件。

B-Tree 索引中的数据块分裂——数据块分配

fuyuncat — Fri, 16 Oct 2009 07:56:00 GMT

当索引数据块需要分裂时，会从Freelist中找到空闲的数据块满足分配需要。如果索引数据块上的数据被全部删除，该数据块就会被放置在freelist的前面，但并不从B树结构上删除。

B-Tree 索引中的数据块分裂——分裂事务控制

fuyuncat — Thu, 15 Oct 2009 06:31:44 GMT

索引分裂是导致分裂的用户事务中调用的递归事务控制，其对资源的请求和释放都是在该递归事务中完成的。在任何一块枝节点数据块上，有且只有一个ITL slot，这个ITL slot不是被用于用户事务（User Transaction）的，而是被用于发生分裂时的递归事务的。同样，在叶子节点上，第一ITL slot，也是用于此目的

B-Tree 索引中的数据块分裂——存储参数

fuyuncat — Wed, 14 Oct 2009 06:54:17 GMT

在表的数据块中，当数据插入时，要保证数据块上剩余空间大于、等于PCTFREE的比例设置，以用于数据更新和多事务处理，从而减少数据迁移（Row Migration）的发生；而当分配新的数据块时，会根据INITRANS的设置预留相应的ITL slot，保证并发事务能分配到ITL slot。在索引中，这两个参数仅在有数据时创建或重建索引才会起作用，且仅在叶子节点上起作用。

B-Tree 索引中的数据块分裂——树的生长

fuyuncat — Tue, 13 Oct 2009 07:05:10 GMT

当分裂导致B树索引的层数（Btree Level）增加时，我们称之为树的“生长”。当叶子节点分裂时，在其父节点上需要增加一条记录指向新节点，如果此时父节点上没有足够空间，则父节点也会发生分裂，如果如此递归下去，直到根节点也分裂，那么索引的高度就增加了。

B-Tree 索引中的数据块分裂——如何分裂

fuyuncat — Mon, 12 Oct 2009 08:43:43 GMT

当一个事务需要修改（大多数情况是Insert操作，某些情况下也可能为Delete操作）索引块（枝节点或叶子节点）上的数据，但没有足够空间容纳新的数据（包括索引条目、ITL slot）时，会将原有块上的部分数据放到一个新的数据块上去，这一过程就是索引块分裂。

10g中构建“高”索引

fuyuncat — Wed, 07 Oct 2009 01:52:02 GMT

B树索引的高度(Btree Level)是影响索引的性能的因素之一，高度的增加，意味着对索引的读的次数的增加。如果索引高度要增加，其必要条件就是左枝或右枝饱和。 10g中，左分裂的算法被改进，不能再通过左分裂的方法使用少量数据来构建高索引。我们在这的代码以时间换空间，保证在高度增加的同时保持数据量最少。

Q&A: 为什么在10053Trace文件中没有变量值？

fuyuncat — Wed, 23 Sep 2009 03:56:27 GMT

10053 trace文件为我们分析CBO解析SQL语句的过程提供了非常有用的信息。而在Oracle中，为了提高查询计划的正确性，有一个很重要的特性——绑定变量窥视(Bind Variable Peeking)。10053 Trace文件中跟踪到的“窥视”数据，我们可以更加容易理解优化器为什么会选择某一个查询计划。但是，有时我们却发现在Trace文件没有窥视值，而是显示“No bind buffers allocated”。

事务队列等待（Tx Enqueue）深入分析——记录锁

fuyuncat — Tue, 22 Sep 2009 07:18:46 GMT

在我之前的文章中，曾经分析过产生TX锁的几种情况。但是，在发现TX锁时，我们如何鉴别是哪一种情况导致的呢？当存在TX等待队列时，如何找到锁所在的对象呢？
这类锁是事务插入/删除/更新数据记录时加在记录的锁。对于插入操作，数据在未提交之前对其他事务是“不可见”的，因而不会导致TX等待。这一类的TX锁是比较容易鉴别的——只有这类锁的模式（mode）是6（即排它锁，exclusive）。

不均衡分区和绑定变量窥视导致的查询计划错误

fuyuncat — Fri, 18 Sep 2009 02:40:39 GMT

绑定变量窥视其目的主要是帮助CBO下更加精确的计算出查询计划代价。但是，因为这依赖于被“窥视”的变量值，因而也为查询计划带来了不稳定性。数据的不平衡、分区的不平衡都可能会因为这种不稳定性而导致性能风险。
周一收到生成支持人员的报告，系统上一个作业启动后很长时间没有完成，其执行时间远远大于上周的正常执行时间。接到报告后，首先检查了系统，不存在锁队列的问题。然后查询V$SESSION_LONGOPS，立即发现下面的语句正在进行长操作。

异常终止会话导致系统被Hung

fuyuncat — Thu, 03 Sep 2009 06:06:47 GMT

通常，我们需要杀掉一些希望被立即结束的会话时，推荐使用Kill Session的方法，它能让会话回滚未提交的事务，释放占用的资源，比较安全的结束会话。如果直接从操作系统杀掉Oracle进程，会导致很多意想不到的问题发生。下面就是一个典型案例。
接到生产支持的同事报告：数据库反应非常慢，很多数据库操作无法完成，DB出在被hung住的状态。同时，他们通过OEM发现其中一个节点（我们的数据库是10G RAC环境，3个节点）上发现存在很高的“Active Sessions Waiting: Other”的waits

11g新特性 ——更加灵活的分区策略

fuyuncat — Mon, 31 Aug 2009 07:43:52 GMT

11g中，新增的各种分区策略为我们的优化设计提供了更多灵活的选择。

Row Movement 对系统的影响

fuyuncat — Fri, 28 Aug 2009 05:57:56 GMT

ROW MOVEMENT特性最初是在8i时引入的，其目的是提高分区表的灵活性——允许更新Partition Key。这一特性默认是关闭，只是在使用到一些特殊功能时会要求打开。除了之前提到的更新Partition Key，还有2个要求打开的ROW MOVEMENT的功能就是flushback table和Shrink Segment。所以，只有当使用到以上3个功能特性时，ROW MOVEMENT才会真正起作用。我们如果需要知道ROW MOVEMENT会对系统产生什么影响，就只要看这3个功能使用时会产生什么影响。

Q&A: 表(Table)和段(Segment)之间是什么关系

fuyuncat — Fri, 28 Aug 2009 02:13:24 GMT

问：表(Table)和段(Segment)之间是什么关系？
答：首先，要清楚它们的概念：表是逻辑对象；段是物理存储对象。然后，再看它们之间的关系：

11g新特性 —— 索引不可见（Index Invisible）

fuyuncat — Wed, 26 Aug 2009 06:42:40 GMT

索引维护是DBA的一项重要工作。当一个系统运行很长一段时间，经过需求变更、结构设计变化后，系统中就可能会存在一些不会被使用的索引，或者使用效率很低的索引。这些索引的存在，不仅占用系统空间，而且会降低事务效率，增加系统的waits。因此，我们需要找出那些无用或低效索引的索引并删除它们（找出无用索引可以通过索引监控的方法）。

但是，直接删除索引还是存在一定风险的。例如，某些索引可能只是在一些周期的作业中被使用到，而如果监控周期没有覆盖到这些作业的触发点，就会认为索引是无用的而被删除。当作业启动后，可能就会对系统性能造成冲击。这时，可能就会手忙脚乱的去找回索引定义语句、重建索引。

TIPS: OEM锁视图中ROWID的转换

fuyuncat — Mon, 24 Aug 2009 06:45:07 GMT

在OEM的Database Locks视图，我们可以监控到数据库上的锁，对于TX锁，视图会显示锁对应的ROWID，如以下格式。 0010CDBE.0007.007B 但是这个ROWID并不是我们所熟悉18位64进制的格式。实际上，如果你熟悉Oracle 7及之前版本的话，就可以认出这是Oracle7中ROWID的格式，其组成为（数据为16进制）：

TIPS: 获取RAC环境中的锁等待队列

fuyuncat — Fri, 21 Aug 2009 09:40:45 GMT

通常，我们在分析锁导致的会话被阻塞的问题的时候，都会查询视图DBA_WAITERS或者DBA_HOLDERS，找到阻塞进程，提交或者回滚它，就能为被阻塞的会话“疏通”道路了。但是，在RAC环境中，这两个视图并不完全可靠。当阻塞和被阻塞会话都在同一个instance上时，这两个视图对我们还是有帮助的。但是，当阻塞和被阻塞会话在不同instance上时，从这两个视图中就不能得出结果。

Full Table Scan cost formula cracking

Fuyuncat — Sat, 01 Aug 2009 15:03:37 GMT

CBO is a relatively more accurate optimizer, it will choose the access path considering more objective factors, to draw a more reasonable execution plan. However, Oracle does not give us complete formula for calculating the cost, so we do not know the impact of these factors in the costs calculation. When we try to adjust some parameters, there is no formula that can be relied upon. However, Oracle provides a method of CBO and the output of the Trace (10053). This is for us the equivalent of a "black box", we are able to enter some data to the black box, and it will return the output.
Many of us have probably done some IQ test questions, of which a very typical questions that are given a set of figures, but among the missing 1,2, and let you out of this by observing the law of numbers to supplement the lack of figures. For example, a group of figures 1,2,? , 5,8,? , 21, through observation, this group of figures can be such a law of Xn = Xn-1 + Xn-2, in accordance with this rule, we can draw the two missing figures were 3,13.
Then we can be black-box input and output to try to deduce how the black box in the end of this operation?

Full Article

CBO全表扫描代价计算公式推导

Fuyuncat — Tue, 07 Jul 2009 15:02:34 GMT

CBO是一种相对更加精确的优化器，它在选择访问路径时能够更多的考虑一些客观因素，得出更加合理的查询计划。但是，Oracle并没有给出完整的代价计算公式，所以我们并不清楚这些因素在整个代价中到底产生多大的影响，或者在尝试调整一些参数时，也没有可依靠的理论公式。不过，Oracle提供了对CBO的Trace方法和输出。这对于我们来说相当于是个“黑盒子”，我们可以向黑盒子输入一些数据，黑盒子会输出结果。

很多人可能都做过一些IQ测试题，其中一种很典型的题型就是给出一组数字，但是中间缺1、2个，让你通过观察出这一组数字的规律来补充出缺少的数字。比如，一组数字1、2、？、5、8、？、21，通过观察，可以对这组数字得出一个这样的规律Xn = Xn-1 + Xn-2，根据这个规律，可以得出两个缺失的数字分别是3、13。

那么我们是否可以由黑盒子的输入、输出来尝试推导出黑盒子里到底如何运算的呢？

完整文章

Q&A——多缓冲池

Fuyuncat — Tue, 07 Jul 2009 15:01:52 GMT

问：

1. 关于Recycle buffer,在这个缓存区中数据是可以被清出去的,但是,什么条件才会让这里的数据被清理出去呢?
2.您写的文档说会即清除那些不在使用的数据缓存块.请问一下,在哪个文档上有更详细说明,谢谢您.
3. keep buffer和recycle buffer也是使用LRU吗?

答：

完整文章

一致性读（Consistent Reads）与buffer cache

Fuyuncat — Thu, 18 Jun 2009 15:01:07 GMT

在一致性读（Consistent Read）过程中，Oracle根据SCN从undo segment/buffer中读取脏数据块的undo数据来保证查询数据的一致性。当查询读取了CR数据块时，为了提高后续CR的性能，会将CR块copy到buffer中，后续的CR就直接读取buffer。

在分析CR buffer之前，先简单看下buffer cache是怎么管理的。

我们知道，buffer cache的主要目的就是缓存那些被访问过的数据，以提高下次对这些数据的访问性能。由于一个数据库的被访问的数据量是很庞大的，但是buffer cache资源是有限的，这就需要一个对buffer cache的管理算法，以大大提高buffer cache的利用率。这一算法就是LRU算法，其基本思想就是让那些经常被访问的数据能尽量长时间的保留在buffer中，以提高数据库的整体性能。

完整文章

Performance issue caused by uncorrected statistics data

Fuyuncat — Mon, 08 Jun 2009 01:13:36 GMT

· Troubleshooting:

1st, Hosting report a program seems hung, DB server CPU raised up

2nd , Found a abnormal top SQL from statspack report

Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
110,089,488 1,555 70,797.1 40.0 2801.99 3369.20 3261003379
Module: SQL*Plus
SELECT ROWID FROM CSS_TP_SHMT_QUEUE WHERE CARRIER_ID = :B6 AND T
RDNG_PTNR_ID = :B5 AND CNTR_ID = :B4 AND SHMT_ID = :B3 AND EVENT
_TYPE_ID = :B2 AND TRANSHMT_SEQ = :B1 AND ROWNUM = 1

ROWNUM的一个性能陷阱

Fuyuncat — Sun, 07 Jun 2009 15:00:23 GMT

在之前的文章中，我们已经介绍过ROWNUM的使用及一些要注意的问题。这里，再介绍一种由ROWNUM导致的性能陷阱。事实上，如果能清楚了解ROWNUM的基本机制，那么对这个陷阱就很容易理解。

我们有定义如下视图，

完整文章

通过Parallel Trace分析并行过程

Fuyuncat — Sun, 10 May 2009 14:59:44 GMT

1、并行化跟踪设置

在OLAP或DSS系统中，或者在OLTP中大批量处理数据时，我们经常会借助于并行化处理来最大化利用硬件资源使作业在更短的时间内返回结果。由于影响并行化的因素比较多，如cpu数量、系统参数设置、分区等等，在并行化过程中，又可能会遇到一些意想不到的问题，例如，语句不能并行化或者并行度（DOP Degree Of Parallel）和预期的不一致。这时我们就可以通过Parallel Trace对并行过程进行分析，找出问题所在。

在9i之前，可以通过设置10384~10399 event对并行会话进行trace，在9i以后，可以通过在会话中设置“_px_trace”来实现：

完整文章

让语句横着走————对海量数据更新的并行优化

Fuyuncat — Thu, 07 May 2009 14:57:45 GMT

接到开发组的一个调优请求，任务是对一张海量表CS2_CT_MVMT（近2亿多记录，表大小48G）进行数据update，而更新数据来自于另外一张海量的日志表CS2_TXN_LOG（同样近2亿，表大小42G），数据处理的语句如下：

UPDATE CS2_CT_MVMT CT
SET CT.LAST_MOD_DT = (SELECT TL.MSG_GMT_DT
FROM CS2_TXN_LOG TL
WHERE TL.MSG_ID > 9000000000000000000
AND CT.MSG_ID = TL.MSG_ID
AND TL.MSG_GMT_DT IS NOT NULL)
WHERE EXISTS (SELECT 1
FROM CS2_TXN_LOG TL
WHERE TL.MSG_ID > 9000000000000000000
AND CT.MSG_ID = TL.MSG_ID
AND TL.MSG_GMT_DT IS NOT NULL);

完整文章

Oracle IO问题解析

Fuyuncat — Tue, 07 Apr 2009 14:57:01 GMT

数据库的作用就是实现对数据的管理和查询。任何一个数据库系统，必然存在对数据的大量读或者写或者两中操作都大量存在。IO问题也往往是导致数据库性能问题的重要原因。在这篇文章中，主要帮助大家在理解Oracle的读写操作机制的基础上，灵活解决遇到的各种常见的IO问题。

1 Oracle中IO的产生

IO当然包括了读、写两部分，先介绍Oracle中写操作的产生。

完整文章

Oracle 10gR2新SQL提示——opt_param

Fuyuncat — Mon, 16 Mar 2009 14:56:22 GMT

我们知道，在Oracle中存在许多参数能够影响SQL的查询计划，如hash_join_enabled、optimizer_index_cost_adj、_optim_peek_user_binds。正确调整这些参数能够解决不少SQL所引起的性能问题。但是，在调整这些参数时需要注意一点，他们是对整个实例其作用的。他们的影响范围如此之大，以至于我们可能通过调整这些参数解决某一条SQL的问题，但是参数的调整却会给其他SQL带来负面影响。有没有办法使某个参数只针对某条语句有一个特殊的数值，而对系统没有影响呢？Oracle 10gR2就提供了一个这样的提示——opt_param。

看下这个提示的用法：/*+opt_param([,] )*/。这个提示的作用就是使我们在某条语句中指定某个系统参数值。

完整文章

Oracle SCN机制解析

Fuyuncat — Sat, 07 Mar 2009 14:55:44 GMT

SCN（System Chang Number）作为oracle中的一个重要机制，在数据恢复、Data Guard、Streams复制、RAC节点间的同步等各个功能中起着重要作用。理解SCN的运作机制，可以帮助你更加深入地了解上述功能。

在理解SCN之前，我们先看下oracle事务中的数据变化是如何写入数据文件的：

1、事务开始；
2、在buffer cache中找到需要的数据块，如果没有找到，则从数据文件中载入buffer cache中；
3、事务修改buffer cache的数据块，该数据被标识为“脏数据”，并被写入log buffer中；
4、事务提交，LGWR进程将log buffer中的“脏数据”写入redo log file中；
5、当发生checkpoint，CKPT进程更新所有数据文件的文件头中的信息，DBWn进程则负责将Buffer Cache中的脏数据写入到数据文件中。

完整文章

Oracle中ROWNUM的使用技巧

Fuyuncat — Sat, 14 Feb 2009 14:54:36 GMT

ROWNUM是一种伪列，它会根据返回记录生成一个序列化的数字。利用ROWNUM，我们可以生产一些原先难以实现的结果输出，但因为它是伪列的这个特殊性，我们在使用时也需要注意一些事项，不要掉入“陷阱”。下面就介绍一下它的使用技巧及注意事项。

1 特殊结果输出

利用ROWNUM，我们可以做到一些特殊方式的输出。

完整文章

Replace 函数操作CLOB导致临时表空间泄露

Fuyuncat — Sun, 08 Feb 2009 01:12:33 GMT

生产系统抛ORA-01652错误，找到跑错的程序，发现是下面一段代码（这里只是演示代码，不是原代码）抛出的：

package_body ppp

完整文章

查询计划中的笛卡尔积

Fuyuncat — Sat, 07 Feb 2009 14:53:41 GMT

今天遇到一个性能问题，经过定位，最终确定问题的根本原因是一个查询中存在笛卡尔乘积（Cartesian）。在这里，我们先讲一下什么叫笛卡尔乘积以及查询计划中笛卡尔乘积的来由。

首先，我们要知道在查询计划中产生笛卡尔乘积的一个先决条件：笛卡尔乘积只出现在CBO中。

完整文章

如何获取长事务的运行情况

Fuyuncat — Wed, 07 Jan 2009 14:53:02 GMT

在一个系统中，往往会出现一些长事务进行大批量的数据处理，这些事务往往占据大量系统资源，而且运行时间长。如果我们不能有效的监控这些事务，可能会影响到其他事务的运行，甚至可能会由于事务没有在预期时间内完成作业，到了业务高峰时期仍然在运行而导致系统被hung。

实际上，oracle提供了一个视图让DBA来监控长事务的运行状况及历史信息。下面介绍如何使用这个视图来查看长事务信息——v$session_longops。

在oracle中，运行时间超过6秒的事务就被视为长事务。确切地说，这个视图显示的就是时间超过6秒的一些操作，包括备份和恢复、统计数据收集、查询中的各种操作。在视图的各个字段中，totalwork表示该操作要完成所需要做的总的工作单位数；sofar则是目前已经完成的工作单位数；unit则表明工作单位是什么，例如，全表扫描操作中，是以数据块为单位；eplapsed_seconds是操作已经完成的时间，time_remaining是操作的剩余时间。另外，如果操作涉及到的是sql语句，则可以通过sql_address和sql_hash_value查询到相关语句。

完整文章

如何监控索引的使用情况

Fuyuncat — Sun, 07 Dec 2008 14:52:07 GMT

一个系统，经过长期的运行、维护和版本更新后，可能会产生大量的索引，甚至索引所占空间远远大于数据所占的空间。很多索引，在初期设计时，对于系统来说是有用的。但是，经过系统的升级、数据表结构的调整、应用的改变，很多索引逐渐不被使用，成为了垃圾索引。这些索引占据了大量数据空间，增加了系统的维护量，甚至会降低系统性能。因此，DBA应该根据系统的变化，找出垃圾索引，为系统减肥。

Oracle 9i后，可以通过设置对索引进行监控，来监视索引在系统中是否被使用到。语法如下：

完整文章

利用statspack来获取生成环境中top SQL及其执行计划

Fuyuncat — Fri, 07 Nov 2008 14:51:07 GMT

在一些特殊情况下，生产环境中top SQL会让DBA捉摸不定。比如一个由复杂分支条件所生成的动态语句；第三方软件或者代码本身对会话环境进行了修改，导致无法正确重现问题语句的查询计划；语句过长导致无法获取正确的全部语句，等等。这时，我们可以考虑设置statspack为更高级别（默认级别为5），以获取相关语句的详细信息。具体过程如下：

获取级别6的statspack的快照：

完整文章

NLS参数设置导致的性能问题案例

Fuyuncat — Wed, 08 Oct 2008 01:11:35 GMT

接到现场报告，服务器CPU增加、响应慢。取回statspack报告一看，问题很快找到了，有一条语句的physical reads非常高，初步判断这条语句没中索引，是全表扫描。但奇怪的是，这条语句结构很简单，对一个表的查询，带一个查询条件。类似如下：

select a, b from ttt where b like 'aaa%'

ttt表是个大表，这样简单而且会导致全表扫描的语句没道理能轻易跑到生成库上去的啊。

查了一下，果然字段b上面也是有索引的，而且b的cardinality值很高，以上语句几乎肯定命中索引，在开发库上看了它的查询计划，确实没错，命中了索引，效率也很高，几乎没有物理读：

完整文章

Oracle时间类型数据为0的bug

Fuyuncat — Tue, 07 Oct 2008 14:50:13 GMT

开发组在数据迁移时，报告发现一些数值为'0000/00/00'的date数据，导致数据迁移失败。

这个问题有点奇怪，因为在Oracle中，date类型的数据的取值范围是从-4712/12/31到9999/12/31之间，并且年份不能为0。也就是说'0000/00/00'是一个非法数据，不为oracle所接受。

完整文章