1. Script:Speed Up Large
Index Create or
Rebuild
by Maclean.liu
liu.maclean@gmail.com
www.oracledatabase12g.com
2. About Me
l Email:liu.maclean@gmail.com
l Blog:www.oracledatabase12g.com
l Oracle Certified Database Administrator Master 10g
and 11g
l Over 6 years experience with Oracle DBA technology
l Over 7 years experience with Linux technology
l Member Independent Oracle Users Group
l Member All China Users Group
l Presents for advanced Oracle topics: RAC,
DataGuard, Performance Tuning and Oracle Internal.
3. 简单测试过,创建 25g 大小的索引,普通 pc 机不做任何优化大约要 1 个小时,优化后 35 分
钟完成。
因为之前经常有业务人员问我怎么加速索引创建或重建,所以萌发了把能优化的选项集中在
一个脚本里的想法,但也仅是指导思想(绝大多数场景应当是有效的)。
以上主要优化的几点:
1.普通多块读和排序多块读的大小
2.直接路径 IO 的大小,10351 event level 128
3.内存排序空间的大小,10g 中存在 bug 需要 2 次设置。在 10g 中针对 parallel execution 环境
也需要设置_sort_multiblock_read_count。但是仅对能从内存获益的排序操作有利,适合大多
数场景
4.nologging
5.并行,一般这个业务人员也会想到
6.独立的临时表空间
7.使用备选的排序算法_newsort_type 或_newsort_enabled,一般不要用
8.禁用 block checksum/checking,不推荐,尽在新系统加载大量数据时使用
以下脚本可以用于加速大表索引的创建或重建
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
SQL> select * from global_name;
GLOBAL_NAME
--------------------------------------------------------------------------------
4. www.oracledatabase12g.com
-- Script Tested above 10g
-- Create a new temporary segment tablespace specifically for creating the
index.
-- CREATE TEMPORARY TABLESPACE tempindex tempfile 'filename' SIZE 20G ;
-- ALTER USER username TEMPORARY TABLESPACE tempindex;
REM PARALLEL_EXECUTION_MESSAGE_SIZE can be increased to improve throughput.
REM but need restart instance,and should be same in RAC environment
REM this doesn't make sense,unless high parallel degree
-- alter system set parallel_execution_message_size=65535 scope=spfile;
alter session set workarea_size_policy=MANUAL;
alter session set workarea_size_policy=MANUAL;
alter session set db_file_multiblock_read_count=512;
alter session set db_file_multiblock_read_count=512;
--In conclusion, in order to have the least amount 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';
REM set sort_area_size to 700M or 1.6 * table_size
REM 10g bug need to set sort_area_size twice
REM remember large sort area size doesn't mean better performance
REM sometimes you should reduce below setting,and then sort may benefit from
disk sort
REM and attention to avoid PGA swap
alter session set sort_area_size=734003200;
alter session set sort_area_size=734003200;
REM set sort area first,and then set SMRC for parallel slave
REM Setting this parameter can activate our previous setting of sort_area_size
REM and we can have large sort multiblock read counts.
alter session set "_sort_multiblock_read_count"=128;
alter session set "_sort_multiblock_read_count"=128;
alter session enable parallel ddl;
create [UNIQUE] index ... [ONLINE] parallel [Np] nologging;
alter index .. logging;
alter index .. noparallel;
--TRY below underscore parameter while poor performance
--alter session set "_shrunk_aggs_disable_threshold"=100;
REM _newsort_type=2 only works if the patch for bug:4655998 has been applied
REM The fix for bug:4655998 has been included in the 10.2.0.4 patchset.
REM got worse in most cases
--alter session set "_newsort_type" = 2;
OR
--alter session set "_newsort_enabled"=false; then use
Sort V1 algorithm,got worse in most cases
rem !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
IMPORTANT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!