12C环境下分库分表改造查询优化

某交易查询库主要使用Oracle 12.1.0.2.0的In Memory特性缓存三张按月分区的大表，In Memory组件主要是针对OLAP应用的，而这种应用绝大部分的操做都是查询，并且不少时候只关心表中特定的一个或多个列，因此in memory特性还能够指定只把表中的特定的一个或多个列加载到in memory area当中。开始的状况因为并发等多种因素，跑的仍是很快的。随着时间的推移，三个表的数据量愈来愈大，所占用内存资源也愈来愈多。老是出现这样那样的问题。现在年上半年该系统的一次故障。

SQL> r
1 select wait_class_id,wait_class,count() cnt
2 from dba_hist_active_sess_history
3 where snap_id between 12073 and 12074
4 group by wait_class_id,wait_class
5 order by 3 desc

WAIT_CLASS_ID WAIT_CLASS CNT

---

1740759767 User I/O 12472
2363
3386400367 Commit 2301
1893977003 Other 1093
3875070507 Concurrency 132
4217450380 Application 67
4108307767 System I/O 21
3290255840 Configuration 1

8 rows selected.

查询对应的IO状况所反应到数据库中的事件是什么
EVENT_ID EVENT CNT

---

3056446529 read by other session 6149
834992820 db file parallel read 4756
2652584166 db file sequential read 1418
3926164927 direct path read 993
506183215 db file scattered read 56
根据其等待时间，查看对应的SQL文本为：

SELECT
FROM (SELECT tmp_page., rownum row_id
FROM (SELECT t.TRAN_UUID,
t.IN_MNO,
t.EX_MNO merchantCode,
t.CARD_TYP,
t.CARD_DISP_NO,
t.TRAN_RESPONSE_CD,
t.TRAN_CD,
t.TRAN_STS,
t.TRAN_SEQ_NO,
t.TRAN_BAT_NO,
to_char(t.TRAN_DATE_TIME, 'YYYYMMDD') AS TRAN_DT,
to_char(t.TRAN_DATE_TIME, 'HH24MISS') AS TRAN_TM,
t.TRAN_IN_MOD payWay,
t.TERMINAL_NUM,
t.POS_SIGN_FLG,
t.TRAN_AMT,
t.RECEIVER_FEE_AMT,
t.TRAN_FLG,
t.ROOT_XXXX_ORG_NM belongtoOrgNm,
t.BUSINESS_EMP_NM empNm,
t.XXXX_ORG_NM directlyOrg,
t.XXXX_ORG_NO,
t.XXXX_ORG_PATH
FROM T_SSP_TRANDATA_MPOS t
WHERE t.TRAN_DATE BETWEEN TO_DATE(:1, 'yyyyMMdd') AND
TO_DATE(:2, 'yyyyMMdd')
AND t.ROOT_XXXX_ORG_NO = :3
AND t.XXXX_ORG_PATH LIKE :4 || '%'
ORDER BY t.TRAN_DATE_TIME DESC) tmp_page
WHERE rownum < = :5)
WHERE row_id > :6;

执行计划相似以下：

使用AWR对比相同时间不一样日期时间段，查看该SQL在前一天单次执行时间为1,168毫秒，约0.01分。执行频率为171，故障时间段单次执行时间为102,929毫秒，约1.71分。执行的频率为248。故障时间段要比平时多执行77次。多出131.67分。
推测故障时间段明显比前一天的执行频率要高。是否存在前台的用户点击某个按钮，等了半天没响应，而后就一直点，致使这个SQL一直重复的运行。

IO资源几乎耗尽，会话a在进行把磁盘上的数据块读到内存，会话b，会话c 同时也请求这个数据块。就致使了b、c read by other session。
direct path read表小的时候将数据读到缓存中，表不断增大后，oracle算法干预在大于2%的cache后会采用直接路劲读的方式，跳过加载缓存。大量的反复读取磁盘IO会将IO耗尽，决定设定10949事件关闭该特性。
要使用IN MEMORY特性,须要设置parallel_degree_policy=AUTO和parallel_force_local=false,才可以真正意义上的启动IM特性,否则只是执行计划中的启用,是假象。
后将parallel_degree_policy改成AUTO。后又从新加载T_SSP_TRANDATA_MPOS表所有进入in memory。这么一折腾后，系统稳定了一段时间，可后期还有这样那样的问题。
在代码不改动的状况下，开发和架构部同事进行了拆表分库的方案。三个大表废弃一张表，另外两个表拆分红为4个表，并按月又进行了拆分，一个月有四个小表。新库迁移完成，投产当晚，进行数据校验的同时发现该查询功能仍是跑不出结果该SQL单次执行时间150S以
上，改造这么久没法交差啊。

着手查看SQL，进行SQL优化。
SELECT
FROM (SELECT tmp_page., rownum row_id
FROM (SELECT to_char(TRAN_DATE_TIME, 'yyyyMMdd HH24:mm:ss'),
t.TRAN_UUID,
t.IN_MNO,
t.EX_MNO merchantCode,
t.CARD_TYP,
t.CARD_DISP_NO,
t.TRAN_RESPONSE_CD,
t.TRAN_CD,
t.TRAN_STS,
t.TRAN_SEQ_NO,
t.TRAN_BAT_NO,
to_char(t.TRAN_DATE_TIME, 'YYYYMMDD') AS TRAN_DT,
to_char(t.TRAN_DATE_TIME, 'HH24MISS') AS TRAN_TM,
t.TRAN_IN_MOD payWay,
t.TERMINAL_NUM,
t.POS_SIGN_FLG,
t.TRAN_AMT,
t.RECEIVER_FEE_AMT,
t.TRAN_FLG,
t.XXXX_ORG_NO,
t.XXXX_ORG_PATH
FROM T_TRADE_201807_MPOS_2_0001 t
WHERE t.TRAN_DATE BETWEEN TO_DATE('20180701', 'yyyyMMdd') AND
TO_DATE('20180730', 'yyyyMMdd')
AND t.ROOT_XXXX_ORG_NO = '6AAAAAAAAA'
AND t.XXXX_ORG_PATH LIKE '0FDAFDS%'
ORDER BY t.TRAN_DATE_TIME DESC) tmp_page
WHERE rownum < = 10)
WHERE row_id > 0;

以下是执行计划：

该表索引状况：

OWNER INDEX_NAME COLUMN_NAME

---

XXXX IDX_1807_MPOS_21_XXXX_ORG_NO XXXX_ORG_NO
XXXX IDX_1807_MPOS_21_IN_MNO IN_MNO
XXXX IDX_1807_MPOS_21_ROOT_XXXX_N ROOT_XXXX_ORG_NO
XXXX IDX_1807_MPOS_21_TRAN_DT TRAN_DATE
XXXX IDX_1807_MPOS_21_TRAN_TM TRAN_DATE_TIME
XXXX PK_T_SSP_1807_MPOS_21 TRAN_UUID
XXXX PK_T_SSP_1807_MPOS_21 TRAN_DATE

咱们都知道建立索引须要查看该表的基数状况，根据基数与总行数的比值咱们就能知道该表某个列的选择性。

该7月表的总行数18228172条，ROOT_XXXX_ORG_NO列的基数为1，说明都是重复值该列。
而这个ROOT_XXXX_ORG_NO索引的选择性过低了。绝对是不推荐建立索引的！当一个表中的列选择性大于20%的时候，说明该列数据分布比较均衡。且出如今where条件中，该列没有建立索引，那么该列就必须建立索引。

不想多说什么了，既然开发部门的同事在领导面前没法交差，咱们试着看看有没有优化的余地。
首先收集一下该表的统计信息，以及作一下动态采样。执行时间缩短很多。

明确一下分页语句必定排序，要否则每次返回结果都不同。业务逻辑不严谨的话还行。
这里须要看where条件后面的字段了。
当where条件是等值，oder by其余列，那么where条件的列在前，其余列在后。
当where条件不等值，order by其余列，那么建立索引就不必定怎么建了，关键看过滤的数据多很少！！！
基于以上考虑状况，建立以下索引：

create index xxx.IDX_1807_MPOS_21_NO_PA on xxx.T_TRADE_201807_MPOS_2_0001 ("TRAN_DATE_TIME","ROOT_xxxx_ORG_NO","xxxx_ORG_PATH") tablespace XXX_IDX online nologging;

结果秒出，开发部门的同事能够交差了。

经过咱们的监控系统也能感觉到这次的优化状况，如CPU利用率

内存使用率

DBtime监控

由原来的各类突起峰值，到如今的平稳运行。

这里有几个疑问，这样的索引跳扫是否有问题？返回的行数为何不是10行？欢迎你们积极讨论。

总得留点悬念吧