oracle timekey,Oracle 19c新特性介绍及优化实践.pptx

从自动化到自治Oracle 19c新特性介绍及优化实践;目录

Oracle 的变革之路

性能优化与数据库进化

Oracle 19c新特性;;Oracle 的云上变革之路 – 数据为王;;;;目录

Oracle 的变革之路

性能优化与数据库进化

Oracle 19c新特性;我的成长：曾经年少做开发;SELECT /*+ ordered */ “SP_TRANS”.“TRANS_NO”, … "SP_ITEM"."CHART_ID","SP_ITEM"."SPECIFICATION";SQL背后的世界：多表如何联合;SQL背后的世界：多表如何联合;SQL背后的世界：多表如何联合;SQL背后的世界：理解优化器;SQL背后的世界：理解优化器;Join order[88]: SP_RECEIVE [SP_RECEIVE] SP_RECEIVE_SUB [SP_RECEIVE_SUB] SP_CHK [SP_CHK] SP_CHK_SUB [SP_CHK_SUB] SP_TRANS [SP_TRANS] SP_TRANS_SUB [SP_TRANS_SUB] SP_ITEM [SP_ITEM]

Now joining: SP_CHK_SUB [SP_CHK_SUB] *******;;;常规表的单列索引IDX_PRODUCT_04 – product -LASTTIMEKEY；IDX_LOT_08 – lot - LASTTIMEKEY；时间范围分区表的复合索引IDX_PRODUCTHISTORY_01-producthistory- (timekey,productname) ；IDX_LOTHISTORY_02- lothistory- (timekey,eventname,machinename)；LASTTIMEKEY/TIMEKEY是时间戳，单调递增;Index contention 是索引分裂同时有其他会话尝 试更新。最容易产生等待的是单调递增的索引，因 为每次插入都在索引的最右边。;数据库级解决方案：降低bufferbusywait/indexcontention，也就是打散热点索引，把相近timekey 对应的索引块分散；IDX_PRODUCT_04 / IDX_LOT_08 ，通过建立hash partition index，就可以把索引块分布到不 同的分区上，大幅降低争用；Create index IDX_PRODUCT_04 on PRODUCT(lasttimekey) global partition by hash(lasttimekey) partitions 16;Create index IDX_LOT_08 on LOT(lasttimekey) global partition by hash(lasttimekey) partitions 16;Producthistory/lothistory是分区表，无法直接创建hash子分区索引，除非把整个表重建为range-hash的复合分区，但是这么做改动太大；分析SQL,发现producthistory表的访问基本都是两个栏位productname和timekey的，因此把索 引重建为 productname 在前，timekey 在后就可解决问题。Create index idx_producthistory_01(productname,timekey);;LOTHISTORY 表的索引优化SQL主要以 timekey 为条件，很多不包括eventname, machinename； 必须有合适的索引可以应用 timekey 条件；可以增加前缀列，让SQL走index skip scan；但是前缀列的唯一值不能太大, 否则index skip scan的额外成本高； 前缀列的唯一值也不能太小，否则起不到分散索引块的作用。考虑使用8-32之间的值。;;SQL>select seq_eygle.nextval from dual; NEXTVAL---------- 1013950000000000000000000001SQL>select instance_number from v$instance;1SQL>select sid from v$mystat where rownum=1; 395;将分片能力引入到RAC集群实例中;;目录

Oracle 的变革之路

性能优化与数据库进化

Oracle 19c新特性;使用统计信息支持查询使用已经收集的统计信息，避免扫描大量数据；例如，select count(*) from emp可以极大提升某些检查