简单测试过,创建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
--------------------------------------------------------------------------------
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!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
rem If the performance of a query has degraded and the majority of the
rem time is spent in the function kghfrempty, and the function that called
rem kghfrempty was kxsfwa called from kksumc, then you may be encountering
rem this problem.
rem Workaround:
rem Reducing sort_area_size may help by reducing the amount of memory that
rem each sort allocates, particularly if the IO subsystem is underutilized.
rem The performance of some queries that involved large sorts degraded due
rem to the memory allocation pattern used by sort.
rem !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
REM setting below parameter only if you are loading data into new system
REM you should restore them after loading
--alter session set db_block_checking=false;
--alter system set db_block_checksum=false;