ITPub博客

首页 > 数据库 > Oracle > Oracle 41亿数据量表建立索引记录

Oracle 41亿数据量表建立索引记录

原创 Oracle 作者:你好我是李白 时间:2020-06-05 11:12:34 0 删除 编辑

背景

    生产系统一个流水表,41亿数据,有一列原先开发建立了bitmap index,由于该表为流水表,有大量插入,alert日志中一直报

dead lock,死锁,由于位图索引特殊性,即使在没有任何约束情况下,由于该列的distinct值非常低,41亿,只有170左右的distinct value,所以造成大量的dead lock,需要删除bitmap index,改为global normal index。

    该表为按天分区。

建索引语句

alter session set workarea_size_policy=MANUAL;              
alter session set db_file_multiblock_read_count=512;
alter session set events ‘10351 trace name context forever, level 128’;
alter session set sort_area_size=2147483648;
alter session set “_sort_multiblock_read_count”=128;
alter session enable parallel ddl;
alter session enable parallel dml;
set timing on
create index idx_data_02 on data(xx) parallel 8 nologging [local];

大约耗时3个小时左右。

需要注意

temp表空间原先为60g,由于一开始开16个并行,所以导致报错无法在temp扩展,临时加大temp表空间到120g,顺利建立索引。

参考

https://www.askmaclean.com/archives/event-10357-and-10351.html

[oracle@rh2 ~]$ oerr ora 10351
10351, 00000, "size of slots"
// *Cause:
// *Action:  sets the size of slots to use
// *Comment: a slot is a unit of I/O and this factor controls the size
// *Comment: of the IO.
alter session set events '10351 trace name context forever, level 128';
level 128 -> direct path write max block 128
I generated a new run of the big testcase with event 10357, Patch 4417285
applied, manual workarea_size_policy, sort_area_size=50000000,
db_file_multiblock_read_count=16 and event 10351 with level 128.
I tried it with disk_asynch_io=TRUE and FALSE just to be certain this is not
something related to the async.
In the trace files I see something very peculiar. The slots size is 128 as
expected and I see many writes of 128 blocks but not all of them are and they
look like the they come in clusters. A few 128 writes, then a lot smaller of
different sizes but mainly less than 16 blocks and then another cluster of
big ones and so on.
kcblcow: dba=100c91b, sz=128, blks=117, st=3, idx=14
kcblcow: dba=100c91b, sz=128, blks=117, st=3, idx=14
kcblcow: dba=100c991, sz=128, blks=1, st=3, idx=15
kcblcow: dba=100c91b, sz=128, blks=117, st=3, idx=14
kcblcow: dba=100c991, sz=128, blks=1, st=3, idx=15
kcblcow: dba=100c990, sz=128, blks=1, st=3, idx=0
kcblcow: dba=100c992, sz=128, blks=128, st=3, idx=1
kcblcow: dba=100c992, sz=128, blks=128, st=3, idx=1
kcblcow: dba=100ca12, sz=128, blks=39, st=3, idx=2
kcblcow: dba=100c992, sz=128, blks=128, st=3, idx=1
kcblcow: dba=100ca12, sz=128, blks=39, st=3, idx=2
kcblcow: dba=100ca3a, sz=128, blks=1, st=3, idx=3
kcblcow: dba=100ca12, sz=128, blks=39, st=3, idx=2
kcblcow: dba=100ca3a, sz=128, blks=1, st=3, idx=3
kcblcow: dba=100ca39, sz=128, blks=1, st=3, idx=4
but
it is possible that there are other factor out of our control that forces
Oracle to stop adding blocks to the slot and write small batches.
In conclusion, in order to have the least ammount of direct operations and
have the maximum possible read/write batches these are the parameters to set
:
alter session set events '10351 trace name context forever, level 128';
alter session set workarea_size_policy=manual;
alter session set sort_area_size=50000000;


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

全部评论
让生活更美好。

注册时间:2017-02-28

  • 博文量
    64
  • 访问量
    31718