3.10常用的脚本
3.10.1.删除preference:
begin
ctx_ddl.drop_preference(my_lexer);
end;
3.10.2.索引重建:
ALTER INDEX newsindex REBUILD PARAMETERS(replace lexer my_lexer);
3.10.3 同步索引
begin
ctx_ddl.sync_index(myindex, 2M);
end;
或通过后台设置同步脚本:
$ORACLE_HOME/ctx/sample/script/drjobdml.sql --后台同步脚本(9i 中有,10g 不知道放哪儿了,文档有问题)
SQL> @drjobdml myindex 360 --表示以周期360 分钟同步索引myindex
或通过创建索引加参数实现
--表示每小时同步一次,内存16m
CREATE INDEX IND_m_high ON my_high(DOCS) INDEXTYPE IS CTXSYS.CONTEXT
parameters (sync (EVERY "TRUNC(SYSDATE)+ 1/24") memory 16m ) parallel 2 online;
(确认这个时间间隔内索引同步能完成,否则,sync job 将处于挂起状态)
--还可以是
sync (manual) --手工同步,默认
sync (on commit) --dml 后立即同步
--通过job 定义同步
declare
job number;
begin
dbms_job.submit(job,
ctx_ddl.sync_index(ind_m_high);, --索引名
interval => SYSDATE+1/1440); --1 分钟一次
commit;
dbms_output.put_line(job || job || has been submitted.);
end;
3.10.4.索引碎片:
刚开始建立索引后,DOG 可能是如下的条目
DOG DOC1 DOC3 DOC5
新的文档增加到表后,新行会同步到索引中去,假设新文档中Doc7 中的DOG 被同步到索引中去,DOG
可能变成如下条目
DOG DOC1 DOC3 DOC5
DOG DOC7
随后的DML 操作可能变成:
DOG DOC1 DOC3 DOC5
DOG DOC7
DOG DOC9
DOG DOC11
这就产生了碎片,需要进行索引的优化
查看索引碎片
create table output (result CLOB);
declare
x clob := null;
begin
ctx_report.index_stats(idx_auction, x);
insert into output values (x);
commit;
dbms_lob.freetemporary(x);
end;
select * from output
3.10.5索引优化:
快速fast 优化和全部full 优化的区别是,快速优化不会删除没用的、过期的数据,而full 会删除老的数据(deleted rows)
--快速优化
begin
ctx_ddl.optimize_index(myidx,FAST);
end;
--全部优化
begin
ctx_ddl.optimize_index(myidx,FULL);
end;
--对单个记号进行优化,默认是full 模式
begin
ctx_ddl.optimize_index(myidx,token, TOKEN=>Oracle);
end;
3.10.6.Online 参数限制:
at the very beginning or very end of this process, dml might fail.
online is supported for context indexes only.
online cannot be used with parallel.
--online 索引的时候后面必须要加parameters,否则会失败
alter index IND_m_high rebuild online parameters (sync memory 16m )
3.10.7.更改索引的属性,但不进行索引重建
Replaces the existing preference class settings, including SYNC parameters, of the index with
the settings from new_preference. Only index preferences and attributes are replaced. The index is
not rebuilt.
ALTER INDEX myidx REBUILD PARAMETERS(replace metadata transactional);
alter index idx_auction_db1 rebuild PARAMETERS(REPLACE METADATA SYNC(ON COMMIT)) ;
3.10.8.Score:
--表示得分,分值越高,表示查到的数据越精确
SELECT SCORE(1), id, text FROM docs WHERE CONTAINS(text, oracle, 1) > 0;
--根据得分来排序
SELECT SCORE(1), title from news WHERE CONTAINS(text, oracle, 1) > 0 AND issue_date >=
(01-OCT-97)
ORDER BY SCORE(1) DESC;
3.10.9.分析表:
ANALYZE TABLE COMPUTE STATISTICS;
ANALYZE TABLE ESTIMATE STATISTICS 1000 ROWS;
ANALYZE TABLE ESTIMATE STATISTICS 50 PERCENT;
ANALYZE TABLE DELETE STATISTICS;
3.10.10.数据字典表:
查看系统默认的oracle text 参数
Select pre_name, pre_object from ctx_preferences
查询dml 操作后索引为同步
SELECT pnd_index_name, pnd_rowid, to_char(pnd_timestamp, dd-mon-yyyy hh24:mi:ss)
timestamp FROM ctx_user_pending;
查看错误记录表
select * from CTX_USER_INDEX_ERRORS
3.10.11.Php,Jsp 应用oracle text:
http://download.oracle.com/docs/cd/B19306_01/text.102/b14217/acase.htm
3.10.12.逻辑操作符:
-- or 操作符
Select id, text from docs where contains(text, city or state ) > 0;
--and 操作符
Select id, text from docs where contains(text, city and state ) > 0;
或是
Select id, text from docs where contains(text, city state ) > 0;
3.10.13.索引优化问题
--先看个例子
SQL> exec ctx_ddl.optimize_index(idx_auction_db1,FULL);
PL/SQL procedure successfully completed.
Elapsed: 00:16:16.77
索引优化相当的慢,200 万的数据建立context 索引需要不到5 分钟,而优化索引居然要16 分钟,这么慢
的优化速度对一个具有几亿表的数据是很难接受的的。刚开始我以为这是oracle 的一个bug,后来查到了
一些文档。Oracle10g 引进了rebuild 优化参数,速度还是很快的。
SQL> exec ctx_ddl.optimize_index(idx_auction_db1,rebuild) ;
PL/SQL procedure successfully completed.
3.10.14 事务查询
索引可能不是实时进行同步的,但是查询又要求实时的。
--更改索引为事务性,查询再找索引时还会dr$unindexed 表,把满足条件还未索引的记录找出来
alter index idx_auction_db1 rebuild parameters(replace metadata transactional)
例子:
select count(*) from table where contains(text, someword) > 0; -- 0 hits
insert into table values (someword);
select count(*) from table where contains(text, someword) > 0; -- 1 hit (the one we just
entered)
rollback;
select count(*) from table where contains(text, someword) > 0; -- 0 hit
仅仅是对某个session 启用
exec ctx_query.disable_transactional_query := TRUE;