本篇内容介绍了“Oracle 41亿数据量表建立索引记录的方法是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
背景
生产系统一个流水表，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@rh3 ~]$ 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;“Oracle 41亿数据量表建立索引记录的方法是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
