两种使用B树在列上建立索引的情况：

l 索引用于访问表中的行：通过读索引来访问表中的行。此时你希望访问表中很少的一部分行（只占一个很小的百分比）。

l 索引用于回答一个查询：索引包含了足够的信息来回答整个查询，我根本不用去访问表。在这种情况下，索引则用作一个“较瘦“版本的表，即通过查询索引就能找到查询结果，在这种情况下，可以通过处理标准100%的数据，而不像第一种情况中只能访问少量的数据。

为什么在通过索引访问表时如果数据量比较大的话，使用索引反而会降低性能？

一般来讲，B*树索引会放在频繁使用查询谓词的列上，而且我们希望从表中只返回少量的数据（只占很小的百分比），或者最终用户请求立即得到反馈。在一个瘦（thin）表（也就是说，只有很少的几个列，或者列很小）上，这个百分比可能相当小。使用这个索引的查询应该只获取表中2%～3%（或者更少）的行。在一个胖（fat）表中（也就是说，这个表有很多列，或者列很宽），百分比则可能会上升到表的20%～25%。以上建议不一定直接适用于每一个人；这个比例并不直观，但很精确。

索引按索引键的顺序存储。索引会按键的有序顺序进行访问。索引指向的块则随机地存储在堆中。因此，我们通过索引访问表时，会执行大量分散、随机的I/O。这里“分散“（scattered）是指，索引会告诉我们读取块1，然后是块1000、块205、块321、块1、块1032、块1，等等，它不会要求我们按一种连续的方式读取块1、然后是块2，接着是块3（原因在与表中的每一行并没有按照索引键的顺序存储在堆中，否则不会出现这种情况）。我们将以一种非常随意的方式读取和重新读取块。这种块I/O可能非常慢。

下面来看这样一个简化的例子，假设我们通过索引读取一个瘦表，而且要读取表中20%的行。若这个表中有100,000行，其中的20%就是2,0000行。如果行大小约为80字节，在一个块大小为8KB的数据库中，每个块上则有大约100行。这说明，这个表有大约1000个块。了解了这些情况，计算起来就非常容易了。我们要通过索引读取20,000行；这说明，大约是20,000个TABLE  ACCESS  BY  ROWID操作。为此要处理20,000个表块来执行这个查询。不过，整个表才有大约1000个块！因而最后会平均把表中的每一个块读取和处理20次（效果就是缓存的命中率很低，缓存的相邻块的数据没有用到）。 即使把行的大小提高一个数量级，达到每行800字节，这样每块有11.行，现在表中就有11.,000个块。要通过索引访问20,000行，仍要求我们把每一个块平均读取2次。在这种情况下，全表扫描就比使用索引高效得多，因为每个块只会命中一次。如果查询使用这个索引来访问数据，效率都不会高，除非对于800字节的行，平均只访问表中不到5%的数据，因为这样一来，就只会访问大约5,000个块，如果是80字节的行，则访问的数据应当只占更小的百分比，大约0.5%或更少（这就是为什么在一次查询中一个“胖表”的数据获取百分比比一个“瘦表”相对高的原因）。

因此，根本原因是因为缓存命中率降低，出现了大量随机分散的I/O操作。

物理组织对索引效率的影响

此外，数据在磁盘上如何物理组织，对上述过程也会有显著影响。

表会很自然地按主键顺序聚簇（因为数据或多或少就是已这种属性增加的）。当然，它不一定严格按照键聚簇（要想做到这一点，必须使用一个IOT），但是，一般来讲，主键值彼此接近的行的物理位置也会“靠“在一起。如果发出以下查询：

select * from T where primary_key between :x and :y；

你想要的行通常就位于同样的块上。在这种情况下，即使要访问大量的行（占很大的百分比），索引区间扫描可能也很有用。原因在于：我们需要读取和重新读取的数据库块很可能会被缓存，因为数据共同放置在同一个位置（co-located）。另一方面，如果行并非共同存储在一个位置上，使用这个索引对性能来讲可能就是灾难性的。

聚簇因子

接下来，我们来看Oracle所用的一些信息。我们要特别查看USER_INDEXES视图中的CLUSTERING_FACTOR列。Oracle reference手册指出了这个列有以下含义：

根据索引的值指示表中行的有序程度：

 如果这个值与块数接近，则说明表相当有序，得到了很好的组织，在这种情况下，同一个叶子块中的索引条目可能指向同一个数据块上的行。

 如果这个值与行数接近，表的次序可能就是非常随机的。在这种情况下，同一个叶子块上的索引条目不太可能指向同一个数据块上的行。

可以把聚簇因子（clusteringfactor）看作是通过索引读取整个表时对表执行的逻辑I/O次数。也就是说，CLUSTERING_FACTOR指示了表相对于索引本身的有序程度，查看这些索引时，会看到以下结果：

ops$tkyte@ORA10G> select a.index_name,           

2 b.num_rows,

3 b.blocks,

4 a.clustering_factor

5 from user_indexes a, user_tables b

6 where  index_name in ('COLOCATED_PK', 'DISORGANIZED_PK' )

7 and a.table_name = b.table_name

8 /

INDEX_NAME  NUM_ROWS  BLOCKS  CLUSTERING_FACTOR

---------------   ----------  ---------- -----------------

COLOCATED_PK  100000  1252 1190

DISORGANIZED_PK  100000  1219 99932

所以数据库说：“如果通过索引COLOCATED_PK从头到尾地读取COLOCATED表中的每一行，就要执行1190次I/O。不过，如果我们对DISORGANIZED表做同样的事情，则会对这个表执行99,932次I/O“。之所以存在这么大的区别，原因在于，当Oracle对索引结构执行区间扫描时，如果它发现索引中的下一行几乎总与前一行在同一个数据库块上，就不会再执行另一个I/O从缓冲区缓存中获得表块。它已经有表块的一个句柄，只需直接使用就可以了。不过，如果下一行不在同一个块上，就会释放当前的这个块，而执行另一个I/O从缓冲区缓存获取要处理的下一个块。因此，在我们对索引执行区间扫描时，COLOCATED_PK索引会发现下一行几乎总于前一行在同一个块上。DISORGANIZED_PK索引发现的情况则恰好相反。

以上讨论的关键点是，索引并不一定总是合适的访问方法。优化器也许选择不使用索引，而且如前面的例子所示，这种选择可能很正确。影响优化器是否使用索引的因素有很多，包括物理数据布局。因此，你可能会矫枉过正，力图重建所有的表来使所有索引有一个好的聚簇因子，但是在大多数情况下这可能只会浪费时间。只有当你在对表中的大量数据（所占百分比很大）执行索引区间扫描时，这才会产生影响。另外必须记住，对于一个表来说，一般只有一个索引能有合适的聚簇因子！表中的行可能只以一种方式排序。在前面所示的例子中，如果Y列上还有一个索引，这个索引在COLOCATED表中可能就不能很好地聚簇，而在DISORGANIZED表中则恰好相反。如果你认为数据物理聚簇很重要，可以考虑使用一个IOT、B*树聚簇，或者在连续地重建表时考虑散列聚簇。

B*树索引小结

什么时候建立索引，在哪些列上建立索引，你的设计中必须注意这些问题。索引并不一定就意味着更快的访问；实际上你会发现，在许多情况下，如果Oracle使用索引，反而会使性能下降。这实际上两个因素的一个函数，其中一个因素是通过索引需要访问表中多少数据（占多大的百分比），另一个因素是数据如何布局。如果能完全使用索引“回答问题“（而不用表），那么访问大量的行（占很大的百分比）就是有意义的，因为这样可以避免读表所带来的额外的分散I/O。如果使用索引来访问表，可能就要确保只处理整个表中的很少一部分（只占很小的百分比）。

应该在应用的设计期间考虑索引的设计和实现，而不要事后才想起来（我就经常见到这种情况）。如果对如何访问数据做了精心的计划和考虑，大多数情况下就能清楚地知道需要什么索引。

    Oracle 提供了多种不同类型的索引以供使用。简单地说， Oracle 中包括如下索引：

    B* 树索引

这些是我所说的 “ 传统 “ 索引。到目前为止，这是 Oracle 和大多数其他数据库中最常用的索引。 B* 树的构造类似于二叉树，能根据键提供一行或一个行集的快速访问，通常只需很少的读操作就能找到正确的行。不过，需要注意重要的一点， ” B* 树 “ 中的 ” B “ 不代表二叉（ binary ），而代表平衡（ b alanced ）。B* 树索引并不是一颗二叉树，这一点在介绍如何在磁盘上物理地存储 B* 树时就会了解到。 B* 树索引有以下子类型：

索引组织表（ index organized table ）：索引组织表以 B* 树结构存储。堆表的数据行是以一种无组织的方式存储的（只要有可用的空间，就可以放数据），而 IOT 与之不同， IOT 中的数据要按主键的顺序存储和排序。对应用来说， IOT 表现得与 “ 常规 “ 表并无二致；需要使用 SQL 来正确地访问 IOT 。 IOT 对信息获取、空间系统和 OLAP 应用最为有用。 IOT 在上一章已经详细地讨论过。

B*树聚簇索引（ B*tree cluster index ）这些是传统 B* 树索引的一个变体（只是稍有变化）。 B* 树聚簇索引用于对聚簇键建立索引（见第 11. 章中 “ 索引聚簇表 “ 一节），所以这一章不再讨论。在传统 B* 树中 ，键都指向一行；而 B* 树聚簇不同，一个聚簇键会指向一个块，其中包含与这个聚簇键相关的多行。

降序索引（ descending index ）：降序索引允许数据在索引结构中按 “ 从大到小 “ 的顺序（降序）排序，而不是按 ” 从小到大 “ 的顺序（升序）排序。我们会解释为什么降序索引很重要，并说明降序索引如何工作。

反向键索引（ reverse key index ）：这也是 B* 树索引，只不过键中的字节会 “ 反转 “ 。利用反向键索引，如果索引中填充的是递增的值，索引条目在索引中可以得到更均匀的分布。例如，如果使用一个序列来生成主键，这个序列将生成诸如 987500 、 987501 、 987502 等值。这些值是顺序的，所以倘若使用一 个传统的 B* 树索引，这些值就可能放在同一个右侧块上，这就加剧了对这一块的竞争。利用反向键， Oracl e则会逻辑地对 205789 、 105789 、 005789 等建立索引。 Oracle 将数据放在索引中之前，将先 把所存储数据的字节反转，这样原来可能在索引中相邻放置的值在字节反转之后就会相距很远。通过反转字节，对索引的插入就会分布到多个块上。

    位图索引（ bitmap index ）

在一颗 B* 树中，通常索引条目和行之间存在一种一对一的关系：一个 索引条目就指向一行。而对于位图索引，一个索引条目则使用一个位图同时指向多行。位图索引适用于高度重复而且通常只读的数据（高度重复是指相对于表中的总行数，数据只有很少的几个不同值）。考虑在一 个有 100 万行的表中，每个列只有 3 个可取值： Y 、 N 和 NULL 。举例来说，如果你需要频繁地统计多少行有值Y ，这就很适合建立位图索引。不过并不是说如果这个表中某一列有 11.000 个不同的值就不能建立位图索引，这一列当然也可以建立 位图索引。在一个 OLTP 数据库中，由于存在并发性相关的问题，所以不能考虑使用位图索引（后面我们就会讨论这一点）。注意，位图索引要求使用 Oracle 企业版或个人版。

位图联结索引（ bitmap join index ）：这为索引结构（而不是表）中的数据提供了一种逆规范化的 方法。例如，请考虑简单的 EMP 和 DEPT 表。有人可能会问这样一个问题： “ 多少人在位于波士顿的部门工作 ？“ EMP 有一个指向 DEPT 的外键，要想统计 LOC 值为 Boston 的部门中的员工人数，通常必须完成表联结，将 LOC 列联结至 EMP 记录来回答这个问题。通过使用位图联结索引，则可以在 EMP 表上对 LOC 列建立索引 。

基于函数的索引（ function-based index ）

这些就是 B* 树索引或位图索引，它将一个函数计算得到的结果存储在行的列中，而不是存储列数据本身。可以把基于函数的索引看作一个虚拟列（或派生列）上的索引，换句话说，这个列并不物理存储在表中。基于函数的索引可以用于加快形如 SELECT * FROM T W HERE FUNCTION(DATABASE_COLUMN) = SAME_VALUE 这样的查询，因为值 FUNCTION(DATABASE_COLUMN) 已经提前计算并存储在索引中。

应用域索引（ application domain index ）

应用域索引是你自己构建和存储的索引，可能存储在Oracle 中，也可能在 Oracle 之外。你要告诉优化器索引的选择性如何，以及执行的开销有多大，优化器则会根据你提供的信息来决定是否使用你的索引。 Oracle 文本索引就是应用域索引的一个例子；你也可 以使用构建 Oracle 文本索引所用的工具来建立自己的索引。需要指出，这里创建的 “ 索引 “ 不需要使用传统的索引结构。例如， Oracle 文本索引就使用了一组表来实现其索引概念。

在对数据库进行操作过程中我们可能会遇到这种情况，表中的数据可能重复出现，使我们对数据库的操作过程中带来很多的不便，那么怎么删除这些重复没有用的数据呢?

　　重复数据删除技术可以提供更大的备份容量，实现更长时间的数据保留，还能实现备份数据的持续验证，提高数据恢复服务水平，方便实现数据容灾等。 重复的数据可能有这样两种情况，第一种时表中只有某些字段一样，第二种是两行记录完全一样。Oracle数据库重复数据删除技术有如下优势：更大的备份容量、数据能得到持续验证、有更高的数据恢复服务水平、方便实现备份数据的容灾。

　　一、删除部分字段重复数据

　　先来谈谈如何查询重复的数据吧。

　　下面语句可以查询出那些数据是重复的：

　　select 字段1,字段2,count(*) from 表名 group by 字段1,字段2 having count(*) > 1

　　将上面的>号改为=号就可以查询出没有重复的数据了。

　　想要删除这些重复的数据，可以使用下面语句进行删除

　　delete from 表名 a where 字段1,字段2 in

　　(select 字段1,字段2,count(*) from 表名 group by 字段1,字段2 having count(*) > 1)

　　上面的语句非常简单，就是将查询到的数据删除掉。不过这种删除执行的效率非常低，对于大数据量来说，可能会将数据库吊死。所以我建议先将查询到的重复的数据插入到一个临时表中，然后对进行删除，这样，执行删除的时候就不用再进行一次查询了。如下：

　　CREATE TABLE 临时表 AS

　　(select 字段1,字段2,count(*) from 表名 group by 字段1,字段2 having count(*) > 1)

　　上面这句话就是建立了临时表，并将查询到的数据插入其中。

　　下面就可以进行这样的删除操作了：

　　delete from 表名 a where 字段1,字段2 in (select 字段1，字段2 from 临时表);

　　这种先建临时表再进行删除的操作要比直接用一条语句进行删除要高效得多。

　　这个时候，大家可能会跳出来说，什么?你叫我们执行这种语句，那不是把所有重复的全都删除吗?而我们想保留重复数据中最新的一条记录啊!大家不要急，下面我就讲一下如何进行这种操作。

　　在oracle中，有个隐藏了自动rowid，里面给每条记录一个唯一的rowid，我们如果想保留最新的一条记录，

　　我们就可以利用这个字段，保留重复数据中rowid最大的一条记录就可以了。

　　下面是查询重复数据的一个例子：

　　select a.rowid,a.* from 表名 a 

　　where a.rowid != 

　　( 

　　select max(b.rowid) from 表名 b 

　　where a.字段1 = b.字段1 and 

　　a.字段2 = b.字段2 

　　)

　　下面我就来讲解一下，上面括号中的语句是查询出重复数据中rowid最大的一条记录。

　　而外面就是查询出除了rowid最大之外的其他重复的数据了。

　　由此，我们要删除重复数据，只保留最新的一条数据，就可以这样写了：

　　delete from 表名 a 

　　where a.rowid != 

　　( 

　　select max(b.rowid) from 表名 b 

　　where a.字段1 = b.字段1 and 

　　a.字段2 = b.字段2 

　　)

　　随便说一下，上面语句的执行效率是很低的，可以考虑建立临时表，讲需要判断重复的字段、rowid插入临时表中，然后删除的时候在进行比较。

　　create table 临时表 as 

　　select a.字段1,a.字段2,MAX(a.ROWID) dataid from 正式表 a GROUP BY a.字段1,a.字段2; 

　　delete from 表名 a 

　　where a.rowid != 

　　( 

　　select b.dataid from 临时表 b 

　　where a.字段1 = b.字段1 and 

　　a.字段2 = b.字段2 

　　); 

　　commit;

　　二、完全删除重复记录

　　对于表中两行记录完全一样的情况，可以用下面语句获取到去掉重复数据后的记录：

　　select distinct * from 表名

　　可以将查询的记录放到临时表中，然后再将原来的表记录删除，最后将临时表的数据导回原来的表中。如下：

　　CREATE TABLE 临时表 AS (select distinct * from 表名);

　　truncate table 正式表; --注：原先由于笔误写成了drop table 正式表;，现在已经改正过来

　　insert into 正式表 (select * from 临时表);

　　drop table 临时表;

　　如果想删除一个表的重复数据，可以先建一个临时表，将去掉重复数据后的数据导入到临时表，然后在从临时表将数据导入正式表中，如下：

　　INSERT INTO t_table_bak 

　　select distinct * from t_table;

　　三、怎样快速删除oracle数据库

　　最快的方法就进入注册表 在运行..里输入regedit.

　　依次展开HKEY_LOCAL_MACHINE SOFTWARE

　　找到ORACLE节点。删除。

　　然后删除ORACLE数据文件，安装的时候选的路径。

　　最后删除oracle引导文件，在系统盘符的Program Files 里面删除oracle文件夹。

ops$tkyte@ORA10GR1> create table t1

2 ( x int primary key,

3 y varchar2(25),

4 z date

5 )

6 organization index;

Table created.

使用一下方法查看详细定义语句：

ops$tkyte@ORA10GR1> select dbms_metadata.get_ddl( 'TABLE', 'T1' ) from dual;

S_METADATA.GET_DDL('TABLE','T1')

-----------------------------------------------------------------------------

CREATE TABLE "OPS$TKYTE"."T1"

(
"X" NUMBER(*,0),

"Y" VARCHAR2(25),

"Z" DATE,

PRIMARY KEY ("X") ENABLE
)
ORGANIZATION INDEX

NOCOMPRESS

PCTFREE 10 INITRANS 2 MAXTRANS 255 LOGGING

STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)

TABLESPACE "USERS"

PCTTHRESHOLD 50

在此基础上可以进行修改。

注意：select dbms_metadata.get_ddl( 'TABLE', 'T1' ) from dual;中“ 'TABLE', 'T1'”均要大写！

    索引组织表(index organized table, IOT)就是存储在一个索引结构中的表。存储在堆中的表是无组织的(也就是说，只要有可用的空间，数据可以放在任何地方)，IOT中的数据则按主键存储和排序。对你的应用来说，IOT表和一个“常规”表并无二致。

索引组织表的数据按主键排序手段被存储在B-树索引中，除了存储主键列值外还存储非键列的值。普通索引只存储索引列，而索引组织表则存储表的所有列的值。

索引组织表一般适应于静态表，且查询多以主键列。当表的大部分列当作主键列时，且表相对静态，比较适合创建索引组织表！（8i以上）

既然它属于表，那么它当然也有建立索引的需求。由于它的索引的结构，比如说由于索引叶节点的分裂，行所在块可能会发生改变，因而建立在IOT上的索引和一般的索引的最大区别是它存的是IOT的行的逻辑地址，也就是UROWID，oracle用这个逻辑rowid来猜这个行所在的块，如果猜到了，那么这个urowid是正确的，否则它从这个地址向下遍历来找这条记录。

IOT表的rowid是逻辑上的，因为IOT表中的行的位置是在不断变化的(例如插入新的行，有可能带来其它行的位置移动)

    IOT有什么意义呢？使用堆组织表时，我们必须为表和表主键上的索引分别留出空间。而IOT不存在主键的空间开销，因为索引就是数据，数据就是索引，二者已经合二为一。但是，IOT带来的好处并不止于节约了磁盘空间的占用，更重要的是大幅度降低了I/O,减少了访问缓冲区缓存(尽管从缓冲区缓存获取数据比从硬盘读要快得多，但缓冲区缓存并不免费，而且也绝对不是廉价的。每个缓冲区缓存获取都需要缓冲区缓存的多个闩，而闩是串行化设备，会限制应用的扩展能力)

     IOT适用的场合有：
  1、完全由主键组成的表。这样的表如果采用堆组织表，则表本身完全是多余的开销，因为所有的数据全部同样也保存在索引里，此时，堆表是没用的。
  2、代码查找表。如果你只会通过一个主键来访问一个表，这个表就非常适合实现为IOT.
  3、如果你想保证数据存储在某个位置上，或者希望数据以某种特定的顺序物理存储，IOT就是一种合适的结构。

    IOT提供如下的好处：
  ·提高缓冲区缓存效率，因为给定查询在缓存中需要的块更少。
  ·减少缓冲区缓存访问，这会改善可扩缩性。
  ·获取数据的工作总量更少，因为获取数据更快。
  ·每个查询完成的物理I/O更少，因为对于任何给定的查询，需要的块更少，而且对地址记录的一个物理 I/O 很可能可以获取所有地址（而不只是其中一个地址，但堆表实现就只是获取一个地址）

    如果经常在一个主键或惟一键上使用BETWEEN 查询也是如此，因为相近的记录存在一起，查询时引入的逻辑IO和物理IO都会更少。

    在 建立 IOT 时，最关键的是适当地分配数据，即哪些数据存储在索引块上，哪些数据存储在溢出段上。对溢出条件不同的各种场景进行基准测试，查看对 INSERT 、 UPDATE 、 DELETE 和 SELECT 分别有怎样的影响。如果结构只建立一次，而且要频繁读取，就应该尽可能地把数据放在索引块上（最合适获取），要么频繁地组织索引中的数据（不适于修改）。堆表的 freelist 相关考虑对 IOT 也同样适用。 PCTFREE 和PCTUSED 在 IOT 中 是两个重要的角色。不过， PCTFREE 对于 IOT 不像对于堆表那么重要，另外 PC TUSED 一般不起作用。不过，考虑 OVERFLOW 段时， PCTFREE 和 PCTUSED 对于 IOT 的意义将与对于堆表一样重大；要采用与堆表相同的逻辑为溢出段设置这两个参数。

不同点:
1. truncate和 delete只删除数据不删除表的结构(定义)
    drop语句将删除表的结构被依赖的约束(constrain),触发器(trigger),索引(index); 依赖于该表的存储过程/函数将保留,但是变为invalid状态.
2.delete语句是dml,这个操作会放到rollback segement中,事务提交之后才生效;如果有相应的trigger,执行的时候将被触发.
   truncate,drop是ddl, 操作立即生效,原数据不放到rollback segment中,不能回滚. 操作不触发trigger.
3.delete语句不影响表所占用的extent, 高水线(high watermark)保持原位置不动
  显然drop语句将表所占用的空间全部释放
  truncate 语句缺省情况下见空间释放到 minextents个 extent,除非使用reuse storage;   truncate会将高水线复位(回到最开始).
4.速度,一般来说: drop>; truncate >; delete
5.安全性:小心使用drop 和truncate,尤其没有备份的时候.否则哭都来不及 
            使用上,想删除部分数据行用delete,注意带上where子句. 回滚段要足够大. 
            想删除表,当然用drop 
            想保留表而将所有数据删除. 如果和事务无关,用truncate即可. 如果和事务有关,或者想触发trigger,还是用delete. 
            如果是整理表内部的碎片,可以用truncate跟上reuse stroage,再重新导入/插入数据

TRUNCATE   TABLE   在功能上与不带   WHERE   子句的   DELETE   语句相同：二者均删除表中的全部行。但   TRUNCATE   TABLE   比   DELETE   速度快，且使用的系统和事务日志资源少。    
   
  DELETE   语句每次删除一行，并在事务日志中为所删除的每行记录一项。TRUNCATE   TABLE   通过释放存储表数据所用的数据页来删除数据，并且只在事务日志中记录页的释放。  
   
  TRUNCATE   TABLE   删除表中的所有行，但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值，请改用   DELETE。如果要删除表定义及其数据，请使用   DROP   TABLE   语句。  
   
  对于由   FOREIGN   KEY   约束引用的表，不能使用   TRUNCATE   TABLE，而应使用不带   WHERE   子句的   DELETE   语句。由于   TRUNCATE   TABLE   不记录在日志中，所以它不能激活触发器。    
   
  TRUNCATE   TABLE   不能用于参与了索引视图的表。

• 更新前在应用中存储所要操作行的“前映像”，更新时使用存储的旧记录来判断当前值是否已经改变；
• 使用一个特殊的列，这个列由一个数据库触发器或应用程序代码维护，可以告诉我们记录的 “版本”；
• 使用一个校验和或散列值，这是使用原来的数据计算得出的；
• 使用新增的 Oracle 10g 特性 ORA_ROWSCN 。
  

1.使用版本列
    附加一个LAST_MODIFIED列，类型可以为 timestamp with time zone default systemstamp（ora 9i以上）,这个类型在Oracle中精度最高，精确到百万分之一秒。
不建议使用触发器，因为开销太大，而由DML来负责。

2.使用校验和的乐观锁定
    使用一个虚拟的版本列来判断数据是否改变。
    与使用版本列的做法一样，我们可以采用同样的方法使用这些散列值或校验和，只需把从数据库读出数据时得到的散列或校验和值与修改数据前得到的散列或校验和值进行比较。在我们读出数据之后， 但是在修改数据之前，如果有人在这段时间内修改了这一行的值，散列值或校验和值往往会大不相同。
    以下为Oracle提供的三种计算散列值得数据包：
OWA_OPT_LOCK.CHECKSUM ：这个方法在 Oracle8i 8.1.5 及以上版本中提供。给定一个串，其中一个函数会返回一个 16 位的校验和。给定 ROWID 时，另一个函数会计算该行的 16 位校验和，而且同时将这一行锁定。出现冲突的可能性是 65 536 分之一（ 65 536 个串中有一个冲突，这是假警报的最大几率）。
 DBMS_OBFUSCATION_TOOLKIT.MD5 ：这个方法在 Oracle8i 8.1.7 及以上版本中提供。它会计算一个 128 位的消息摘要。冲突的可能性是 3.4028E+38 分之一（非常小）。
DBMS_CRYPTO.HASH ：这个方法在 Oracle 10g Release 1 及以上版本中提供。它能计算一个SHA-1 （安全散列算法 1 ， Secure Hash Algorithm 1 ）或 MD4/MD5 消息摘要。建议你使用 SHA- 1算法。
    注意 很多编程语言中都提供了一些散列和校验和函数，所以还可以使用数据库之外的散列和校验和函数。
    要记住，计算散列或校验和是一个 CPU 密集型操作（相当占用 CPU ），其计算代价很昂贵。如果系统上 CPU 是稀有资源，在这种系统上就必须充分考虑到这一点。不过，如果从 “ 网络友好性 ” 角度看，这种方法会比较好，因为只需在网络上传输相当小的散列值，而不是行的完整的前映像和后映像（以便逐列地进行比较），所以消耗的资源会少得多。下面会使用一个新的 Oracle 10g 函数 ORA_ROWSCN ，它不仅很小（类似于散列），而且计算时不是 CPU 密集的（不会过多占用 CP U ）。

3.使用ORA_ROWSCN
    ORA_ROWSCN 建立在内部 Oracle 系统时钟（ SCN ）基础上。在 Oracle 中，每次提交时， SCN 都会推进（其他情况也可能导致 SCN 推进，要注意， SCN 只会推进，绝对不会后退）。这个概念与前面在获取数据 时得到 ORA_ROWSCN 的方法是一样的，更新数据时要验证 SCN 未修改过。之所以我会强调这一点（而不是草草带过），原因是除非你创建表时支持在行级维ORA_ROWSCN ，否则 Oracle 会在块级维护。也就是说，默认情况下，一个块上的多行会共享相同的 ORA_ROWSCN 值。如果更新一个块上的某一行，而且 这个块上还有另外 50 行，那么这些行的 ORA_ROWSCN 也会推进。这往往会导致许多假警报，你认为某一行已经修改，但实际上它并没有改动。因此，需要注意这一点，并了解如何改变这种行为。
    要修改这个特性，只能重新建立表，并启用 ROWDEPENDENCIES 。

使用乐观锁定还是悲观锁定？

那么哪种方法最好呢？根据我的经验，悲观锁定在 Oracle 中工作得非常好（但是在其他数据库中可能不是这样），而且与乐观锁定相比，悲观锁定有很多优点。不过，它需要与数据库有一条有状态的连接，如客户 / 服务器连接，因为无法跨连接持有锁。正是因为这一点，在当前的许多情况下，悲观锁定不太现实。过去，客户 / 服务器应用可能只有数十个或数百个用户，对于这些应用，悲观锁定是我的不二选择。不过，如今对大多数应用来说，我都建议采用乐观并发控制。要在整个事务期间保持连接，这个代价太大了，一般无法承受。

在这些可用的方法中，我使用哪一种呢？我喜欢使用版本列方法，并增加一个时间戳列（而不只是一个 NUMBER ）。从长远看，这样能为我提供一个额外的信息： “ 这一行最后一次更新发生在什么时间？ ” 所以意义更大。而且与散列或校验和方法相比，计算的代价不那么昂贵，在处理 LONG 、 LONG RAW 、 CLOB 、 BLO B和其他非常大的列时，散列或校验和方法可能会遇到一些问题，而版本列方法则没有这些问题。

如果必须向一个表增加乐观并发控制，而此时还在利用悲观锁定机制使用这个表（例如，客户 / 服务器应用都在访问这个表，而且还在通过 Web 访问），我则倾向于选择 ORA_ROWSCN 方法。这是因为，在现有的遗留应用中，可能不希望出现一个新列，或者即使我们另外增加一步把这个额外的列隐藏起来（使用散列等等方式），为了维护这个列，可能需要一个必要的触发器，而这个触发器的开销非常大，这是我们无法承受的。 ORA_ROWSCN技术没有干扰性，而且在这个方面是轻量级的（当然，这是指我们执行表的重建之后）。

散列 / 校验和方法在数据库独立性方面很不错，特别是如果我们在数据库之外计算散列或校验和，则更是如此。不过，如果在中间层而不是在数据库中执行计算，从 CPU 使用和网络传输方面来看，就会带来更大的资源使用开销。

• Oracle 只在修改时才对数据加行级锁。正常情况下不会升级到块级锁或表级锁（不过两段提交期间的一段很短的时间内除外，这是一个不常见的操作）。

• 如果只是读数据， Oracle 绝不会对数据锁定。不会因为简单的读操作在数据行上锁定。

• 写入器（ writer ）不会阻塞读取器（ reader ）。换种说法：读（ read ）不会被写（ write ） 阻塞。这一点几乎与其他所有数据库都不一样。在其他数据库中，读往往会被写阻塞。尽管听上去这个特性似乎很不错（一般情况下确实如此），但是，如果你没有充分理解这个思想，而且想通过应用逻辑对应用施加完整性约束，就极有可能做得不对。

• 写入器想写某行数据，但另一个写入器已经锁定了这行数据，此时该写入器才会被阻塞。 读取器绝对不会阻塞写入器。

即：读既不会阻塞读，也不会阻塞写；写不会阻塞读，但会阻塞写。
Oracle 的无阻塞方法有一个副作用，如果确实想保证一次最多只有一个用户访问一行数据，开发人员就得自己做些工作。要加入我们自己的串行化机制来确保业务逻辑的正确性，如for update语句会使读操作也对相应的行加锁，确保了串行访问。

    4.   Oracle多版本
    ①、Oracle多版本特性是Oracle并发控制机制的基础， Oracle 采用了一种多版本、读一致（ read-consistent ）的并发模型。实质上讲， Oracle 利用这种机制提供了以下特性：
 读一致查询：对于一个时间点（ point in time ），查询会产生一致的结果。
 非阻塞查询：查询不会被写入器阻塞，但在其他数据库中可能不是这样。
    ②、由于有多版本机制，Oracle中没有“共享读”锁的概念。
    只要你修改数据， Oracle 就会创建撤销（ undo ）条目。这些 undo 条目写至 undo 段（撤销段， undo segment ）。如果事务失败，需要撤销， Oracle 就会从这个回滚段读取 “ 之前 ” 的映像，并恢复数据。除了使用回滚段数据撤销事务外， Oracle 还会用它撤销读取块时对块所做的修改，使之恢复到查询开始前的时间点 。这样就能摆脱锁来得到一致、正确的答案，而无需你自己对任何数据锁定。
    Oracle非阻塞读是这样实现的： Oracle 只看数据是否改变，它并不关心数据当前是否锁定（锁定意味着数据已经改变）。 Oracle 只是从回滚段中取回原来的值，并继续处理下一个数据块。
    在数据库中，可以得到同一个信息处于不同时间点的多个版本。Oracle 能充分使用不同时间点的数据快照来提供读一致查询和非阻塞查询。

    5.在SQL Server和Sybase中，NULL就等于NULL，但是，在Oracle中，NULL与NULL既不相等，也不完全不相等。
    6.Oracle没有“共享读”锁。

calvin 2009-08-30 13:24 发表评论

]]>

（ 2 ）作为 SYSTEM 登录 SQL*Plus ；

（ 3 ）运行 @utlxplan ；

（ 4 ）运行 CREATE PUBLIC SYNONYM PLAN_TABLE FOR PLAN_TABLE ；

（ 5 ）运行 GRANT ALL ON PLAN_TABLE TO PUBLIC 。

可以把 GRANT TO PUBLIC 中的 PUBLIC 替换为某个用户。通过将 PLAN_TABLE 置为 public ，任何人都可以使用 SQL*Plus 进行跟踪。这么一来，就不需要每个用户都安装自己的计划表。还有一种做法是，在想要使用 AUTOTRACE 的每个模式中分别运行 @utlxplan 。

下一步是创建并授予 PLUSTRACE 角色：

（ 1 ） cd [ORACLE_HOME]/sqlplus/admin ；

（ 2 ）作为 SYS 或 SYSDBA 登录 SQL*Plus ；

（ 3 ）运行 @plustrce ；

（ 4 ）运行 GRANT PLUSTRACE TO PUBLIC 。

通过设置 AUTOTRACE 系统变量可以控制这个报告：

 SET AUTOTRACE OFF ：不生成 AUTOTRACE 报告，这是默认设置。

 SET AUTOTRACE ON EXPLAIN ： AUTOTRACE 报告只显示优化器执行路径。

 SET AUTOTRACE ON STATISTICS ： AUTOTRACE 报告只显示 SQL 语句的执行统计信息。

 SET AUTOTRACE ON ： AUTOTRACE 报告既包括优化器执行路径，又包括 SQL 语句的执行统计信息。

 SET AUTOTRACE TRACEONLY ：这与 SET AUTOTRACE ON 类似，但是不显示用户的查询输出（如果有的话）。