本篇内容介绍了“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亿数据量表建立索引记录的方法是什么”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站,小编将为大家输出更多高质量的实用文章!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。