ITPub博客

首页 > Linux操作系统 > Linux操作系统 > oracle全文索引之同步和优化索引做了什么

oracle全文索引之同步和优化索引做了什么

原创 Linux操作系统 作者:space6212 时间:2019-04-20 16:51:06 0 删除 编辑
一、同步索引做了什么
我们知道,在数据被修改后,不能被查询到了,直到索引被同步。那么同步索引做了那些工作呢?


suk@oracle9i> insert into t_domain values(3,'this is beijing');

已创建 1 行。

suk@oracle9i> update t_domain set doc='this is beijing' where id=3;

已更新 1 行。

suk@oracle9i> delete from t_domain where id=5;

已删除 1 行。

suk@oracle9i> commit;

提交完成。

suk@oracle9i> @begin_tracesuk@oracle9i> exec ctx_ddl.sync_index('IDX_DOMAIN');suk@oracle9i> @end_trace

摘取trace中主要的sql如下:

--发出索引同步命令
BEGIN ctx_ddl.sync_index('IDX_DOMAIN'); END;

--删除DR$WAITING中与DR$PENGING重复的信息
DELETE FROM DR$WAITING
WHERE
WTG_CID = :b1 AND WTG_PID = :b2 AND EXISTS (SELECT 1 FROM DR$PENDING
WHERE DR$PENDING.PND_CID = DR$WAITING.WTG_CID AND DR$PENDING.PND_PID =
DR$WAITING.WTG_PID AND DR$PENDING.PND_ROWID = DR$WAITING.WTG_ROWID )

这一步很重要,我们在《oracle全文索引之几个关键表》中介绍了DR$WAITING的使用原理,为了避免重复同步同一条记录的索引,提高效率,必须删除掉DR$WAITING中多余的信息。
在删除DR$WAITING的多余信息后,oracle会把DR$WAITING的记录与DR$PENGDING的记录联合,得到最终需要同步的记录的集合。
(因为这个实验中DR$WAITING表中的数据完全是DR$PENDING的子集,所以,trace没有反应合并这一步)

--通过一定的分词算法,把产生的信息插入到$I表中
insert into "SUK"."DR$IDX_DOMAIN$I"
values
(:token, :ttype, :first, :last, :count, :data)

--插入记录到$K表中
insert into "SUK"."DR$IDX_DOMAIN$K" (textkey, docid)
values
(:akeys, :adocs)

--更新$R表
select data
from
"SUK"."DR$IDX_DOMAIN$R" where row_no = :row_no for update
在trace中并没有更新$R的直接信息,但我猜测在同步索引时会更新$R表

--删除DR$PENGING的信息
delete from dr$pending
where
pnd_cid = :cid and pnd_pid = :pid and pnd_rowid = :rid

实际上,我猜测,如果删除DR$WAITING中与DR$PENGING重复的信息后,DR$WAITING还有记录的话,这一步还会删除DR$WAITIING的记录的。

--最后提交
commit


二、优化索引做了什么

优化索引可以有很多方式,不同的优化方式得到的结果会不一样,但原理应该是差不多的。我们以FULL优化为例说明。
紧接着上面的例子,我们发出命令:

suk@oracle9i> @begin_tracesuk@oracle9i> exec ctx_ddl.optimize_index('idx_domain','FULL');suk@oracle9i> @end_trace

从trace文件中摘取主要的sql:
--发出命令
BEGIN ctx_ddl.optimize_index('idx_domain','FULL'); END;

--将DR$INDEX的部分字段设置为空
UPDATE DR$INDEX SET IDX_OPT_TOKEN= NULL ,IDX_OPT_TYPE= NULL ,IDX_OPT_COUNT=
NULL
WHERE
IDX_ID = :b1

其中:
IDX_OPT_TOKEN:当次优化的起始关键字
IDX_OPT_COUNT:当次优化的doc数量

--将$N表的doc设置为需要被优化状态
update "SUK"."DR$IDX_DOMAIN$N" set nlt_mark = 'U'
where
nlt_mark != 'U'

之所以要做这一步是因为设置这些状态和删除$I表是两个事务。为了避免在更新了状态位后,没有删除$I表的相关数据的情况。

--将N$表的前16000行设置为"M"状态
update "SUK"."DR$IDX_DOMAIN$N" set nlt_mark = 'M'
where
rownum <= 16000

"M"表示正在被处理。

--更新DR$INDEX的状态
UPDATE DR$INDEX SET IDX_OPT_TOKEN=:b1,IDX_OPT_TYPE=:b2,IDX_OPT_COUNT=:b3,
IDX_DOCID_COUNT=GREATEST(IDX_DOCID_COUNT - :b3 ,0)
WHERE
IDX_ID = :b5

--提交
commit

--删除无效的docid对应的$I中数据
delete from "SUK"."DR$IDX_DOMAIN$I"
where
rowid = :rid

--删除已经优化完成的DOCID
delete from "SUK"."DR$IDX_DOMAIN$N"
where
nlt_mark = 'M'

从以上过程可以看出:oracle优化索引实际上是根据$N表记录的DOCID删除$I表对应的信息,清除$I表的垃圾数据,从而达到提供查询性能的目的。
实际上,优化索引还执行了合并token的步骤,减少索引的碎片。

在做full方式优化索引时有几下几点需要注意:
1)在9ir2以前的版本中,full方式优化索引相当于索引全部删除了重建;在9ir2后,full方式优化索引不会去重写已经被优化的记录。
2)在9ir2前,每次用full方式优化索引最多能处理16000个docid,也就是说每次优化最多能在$I表删除16000个docid对应的记录,如果无效doc很多,需要多次运行优化才能完全优化。
在9ir2及以后版本,执行一次full方式优化可以删除$I表全部的无效信息,但是,在$N表每次还是最多删除16000个docid(让人容易混淆的地方,不明白oracle为什么这样做);
如果无效doc很多,那么在执行完一次full优化后,如果不再产生新的无效doc,那么,再之后的full优化中,只是删除$N表的记录。
3)DR$INDEX中的IDX_OPT_TOKEN为空表示索引已经执行完full方式的优化。


疑问:优化时,为什么要分成两个事务?

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/231499/viewspace-63757/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2005-01-25

  • 博文量
    119
  • 访问量
    87422