[20130815]12c Asynchronous Global Index Maintenance Part III.txt

[20130815]12c Asynchronous Global Index Maintenance Part III.txt

参考链接:
http://richardfoote.wordpress.com/2013/08/07/12c-asynchronous-global-index-maintenance-part-iii-re-makere-model/

更多的是重复作者的测试,加深理解:

1.测试环境:

SQL> @ver
BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production              0

2.测试建立:

SQL> create table muse (id number, code number, name varchar2(30))
partition by range (id)
(partition muse1 values less than (1000001),
partition muse2 values less than (2000001),
partition muse3 values less than (maxvalue));

SQL> insert into muse
select rownum, mod(rownum,100000), 'DAVID BOWIE' from
(select 1 from dual connect by level (select 1 from dual connect by level
SQL> commit;

SQL> exec dbms_stats.gather_table_stats(ownname=>user, tabname=>'MUSE', estimate_percent=>null, method_opt=>'FOR ALL COLUMNS SIZE 1');

SQL> create unique index muse_id_i on muse(id);
Index created.

SQL> alter table muse drop partition muse1 update global indexes;
Table altered.

SQL> select index_name, num_rows, s.blocks, leaf_blocks, status, orphaned_entries
from dba_indexes i, dba_segments s where i.index_name = s.segment_name and table_name='MUSE';
INDEX_NAME             NUM_ROWS     BLOCKS LEAF_BLOCKS STATUS   ORPHANED_ENTRIES
-------------------- ---------- ---------- ----------- -------- --------------------
MUSE_ID_I               3000000       9216        8216 VALID    YES
--ORPHANED_ENTRIES=yes.

SQL> analyze index muse_id_i validate structure;
Index analyzed.

SQL> select name, blocks, lf_rows, del_lf_rows from index_stats;
NAME                     BLOCKS    LF_ROWS DEL_LF_ROWS
-------------------- ---------- ---------- -----------
MUSE_ID_I                  9216    3000000     1000000

SQL> insert into muse select rownum, 42, 'ZIGGY STARDUST' from dual connect by level 10 rows created.

SQL> commit;
Commit complete.

SQL> analyze index muse_id_i validate structure;
Index analyzed.

SQL> select name, blocks, lf_rows, del_lf_rows from index_stats;
NAME                     BLOCKS    LF_ROWS DEL_LF_ROWS
-------------------- ---------- ---------- -----------
MUSE_ID_I                  9216    3000000      999990

--可以DEL_LF_ROWS=9999990,有10条记录插入原来删除的位置。

SQL> set autot traceonly ;
SQL> select * from muse where id between 1 and 100;
10 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2515419874
------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                  | Name      | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                           |           |     1 |    23 |     4   (0)| 00:00:01 |       |       |
|   1 |  TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED| MUSE      |     1 |    23 |     4   (0)| 00:00:01 |     1 |     1 |
|*  2 |   INDEX RANGE SCAN                         | MUSE_ID_I |   100 |       |     3   (0)| 00:00:01 |       |       |
------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("ID">=1 AND "ID"
       filter(TBL$OR$IDX$PART$NUM("MUSE",0,8,0,"MUSE".ROWID)=1)

--也就是讲,对于唯一索引,oracle在插入旧键值是会重用原来的块。
--插入不再删除范围的情况呢?

SQL> insert into muse select rownum+3000000, 42, 'ZIGGY STARDUST' from dual connect by level SQL> commit;

SQL> analyze index muse_id_i validate structure;
Index analyzed.

SQL> select name, blocks, lf_rows, del_lf_rows from index_stats;
NAME                     BLOCKS    LF_ROWS DEL_LF_ROWS
-------------------- ---------- ---------- -----------
MUSE_ID_I                 11264    4000000      999990

--可以发现,插入不再删除范围的值不会重用原来的块。

We notice that the number of so-called deleted leaf entries remains the same after inserting the 1M new rows.

    So in this scenario, the effectively "empty" leaf blocks containing nothing but orphaned unique index entries are
not re-cycled and reused by subsequent index block splits as they would have been had they contained nothing but deleted
index entries.

    So Unique indexes in the unlikely event that such unique values are subsequently reinserted are an exception to the
general rule of orphaned global index entries having to be "cleaned out".

时间: 2024-07-30 13:30:29

[20130815]12c Asynchronous Global Index Maintenance Part III.txt的相关文章

[20130815]12c Asynchronous Global Index Maintenance Part II.txt

[20130815]12c Asynchronous Global Index Maintenance Part II.txt 参考链接:http://richardfoote.wordpress.com/2013/08/06/12c-asynchronous-global-index-maintenance-part-ii-the-space-between/ 更多的是重复作者的测试,加深理解: 1.测试环境: SQL> @ver BANNER                         

ORACLE 12C Partial Global/Local Indexes for Partitioned Tables

以前我有个想法,我只想对其中的某个或者某几个分区上创建索引,其他分区不想创建,在12C之前的版本,无论是Local还是Global index,都不能实现该需求,但是从ORACLE 12C开始引进了Partial Global/Local Indexes for Partitioned Tables,解决了该问题,可以在指定的分区上创建本地索引或者全局索引,主要语法是在表或者分区,子分区级别设置[INDEXING { ON | OFF }]创建测试表  代码如下 复制代码 CDB_PDB@CHF

[20130910]12C执行计划的TABLE ACCESS BY INDEX ROWID BATCHED(补充).txt

[20130910]12C执行计划的TABLE ACCESS BY INDEX ROWID BATCHED(补充).txt 链接http://space.itpub.net/267265/viewspace-772371 写了12c下在范围扫描时可能出现的TABLE ACCESS BY INDEX ROWID BATCHED,这是一种新的执行方式,能够提高执行效率,特别在数据聚集很好的情况下. 既然是12c的一个特性应该有一个参数关闭这个特性.重复前面的例子: 1.建立测试环境: SCOTT@t

[20130918]12C表统计信息的在线收集.txt

[20130918]12C表统计信息的在线收集.txt 在12c以前,如果使用ctas建立表,并不会自动收集表的统计信息,12c开始CTAS和IAS操作会收集统计信息.但是不收集直方图信息.以及索引统计. 摘要:twp-bp-for-stats-gather-12c-1967354.pdfBest Practices for Gathering Optimizer Statistics with Oracle Database 12c P16-17页: Online statistics gat

[20160220]12c视图一些字段显示128列.txt

[20160220]12c视图一些字段显示128列.txt --今天在家里做一些测试时,无意中发现视图显示字段名index_name占用很大的宽度,仔细检查才发现视图里面的显示长度已经是128列. SYS@test> @ver1 PORT_STRING          VERSION     BANNER                                                                        CON_ID -----------------

[20130915]12c新特性 varchar2支持32K长度.txt

[20130915]12c新特性 varchar2支持32K长度.txt oracle 12c以前如果字符串长度超过4000,必须使用blob或者clob类型.12c开始支持超过4000的字符串长度,提高一些应用的灵活性,达到32K,避免一些字段定义为clob,blob类型,提高处理能力. 但是12c默认的方式不支持大于4000的字符串长度,必须经过一些步骤升级完成,自己测试如下: SYS@test> @ver BANNER                                    

[20130803]ORACLE 12C TOP N SQL实现分页功能.txt

[20130803]ORACLE 12C TOP N SQL实现分页功能.txt 参考链接:http://www.xifenfei.com/4257.html SQL> @verBANNER                                                                               CON_ID----------------------------------------------------------------------

[20131116]12c的EXTENDED VARCHAR2与CLOB字段.txt

[20131116]12c的EXTENDED VARCHAR2与CLOB字段.txt oracle 12c以前如果字符串长度超过4000,必须使用blob或者clob类型.12c开始支持超过4000的字符串长度,提高一些应用的灵活性,达到32K,避免一些字段定义为clob,blob类型,提高处理能力. 要支持这个特性,要执行 @?/rdbms/admin/utl32k.sql升级步骤.如果存在pdb库,还必须升级PDB$SEED,以及PDB数据库.参考链接:http://space.itpub.

[20130901]12C在表中使用sequence(补充).txt

[20130901]12C在表中使用sequence(补充).txt 对以前写的内容做一些补充. SQL> @ver BANNER                                                                               CON_ID-------------------------------------------------------------------------------- ----------Oracle Da