营销业务应用系统应用级优化方案.docx

1. 项目简介 4
2. 应用系统的优化 5
2.1. 优化概述 5
2.2. 优化方案 5
2.2.1. 未使用已有索引 5
2.2.2. 缺少必要索引 23
2.2.3. 其它 38
2.2.4. 临时表优化 51
2.3. 应用系统架构设计 51
2.3.1. 业务拆分 52
2.3.2. 历史数据下线 53
3. 其它建议 53
3.1. 数据库实例性能数据采集作业 53

1. 项目简介
陕西公司营销业务系统随着业务量与数据量的增大，系统压力越来越大，系统可靠性与高效性降低，影响了对业务支持的质量。
为此，南瑞公司和陕西公司及该软件的开发公司东软公司一起合作，对营销业务系统通过先进、标准、可控的技术、工具和方法，监控系统的运行状况，评估系统现状，定位系统运行瓶颈，制定具体的优化实施及操作方案，并对优化实施结果进行评估。实现优化系统性能、提升系统运行质量、挖掘系统潜力、创建系统建设良性循环模式的目的，并有助于提高维护人员的技术水平。
本项目分为四个阶段：
第一阶段为优化小组在西安市对陕西公司营销业务系统进行现场调研和性能分析，形成性能分析报告，并提出初步优化建议。
第二阶段，优化小组和开发厂家在国网公司相关部门的领导下，在西安市是成立联合测试小组，对主要问题的优化方案进行验证。
第三阶段，优化小组在西安市实施现场优化实施工作，并在实施完成后进行性能评估。
第四阶段，开发厂商完成应用优化的代码调整工作，发布新的版本。

2. 应用系统的优化
由于本次优化工作中发现的应用优化问题，部分可以通过调整索引的方式得到解决，而部分必须由开发厂商修改应用代码。因此本方案对目前发现的一些主要的应用问题进行了分析，并给出了解决方案。在优化实施过程中，部分修改代码的工作需要开发厂商东软公司完成。
2.1. 优化概述
应用程序的优化调整贯穿整个调优项目的始终，本章就部分重点应用的调整进行总结， SQL语句的优化对于提高系统性能十分重要。高开销的SQL占用了大量的系统资源，对这些SQL进行优化，可以有效的提高系统的性能。
需要进行调整的SQL语句主要可以分为以下几类：
l 缺乏合适索引的SQL：规范索引设计，添加或调整索引，避免对大表的全表扫描。
l 语法明显不合理的SQL：主要是随意地在字段上增加了转换函数，如TRIM和UPPER等，造成了全表扫描。还有就是在取单条记录时，习惯性地使用MAX等分组函数，而不是使用更高效的rownum=1。这些可以通过改写SQL调整。
l 执行计划不稳定的SQL：找到最佳执行计划，调整表联接顺序或通过HINT固定执行计划。
l 使用更有效的物理结构，比如有些大表如果采用分区表效果可能更好。
l 其它，比如有些SQL语句或存储过程改写后效率可能更好。
具体内容见下节。
2.2. 优化方案
2.2.1. 未使用已有索引
1. Sql-1
所属函数或存储过程名称：
编号：XA_20131024_00001
模块名称：电费收缴及营销账务电费收缴及营销账务

问题描述：
1.存在问题的SQL
SELECT
/*+ FIRST_ROWS */
*
FROM
(SELECT t.*,
ROWNUM AS RN2
FROM
(SELECT a_pay_flow.CHARGE_ID AS "CHARGE_ID",
a_pay_flow.ORG_NO AS "ORG_NO",
a_pay_flow.TYPE_CODE AS "TYPE_CODE",
a_pay_flow.RCV_AMT AS "RCV_AMT",
a_pay_flow.THIS_CHG AS "THIS_CHG",
a_pay_flow.LAST_CHG AS "LAST_CHG",
a_pay_flow.CHARGE_EMP_NO AS "CHARGE_EMP_NO",
a_pay_flow.PAY_MODE AS "PAY_MODE",
a_pay_flow.SETTLE_MODE AS "SETTLE_MODE",
a_pay_flow.SETTLE_NOTE_NO AS "SETTLE_NOTE_NO",
a_pay_flow.SETTLE_BANK_CODE AS "SETTLE_BANK_CODE",
a_pay_flow.ACCT_NO AS "ACCT_NO",
a_pay_flow.ACCT_NAME AS "ACCT_NAME",
(SELECT REAL_NAME
FROM sa_user
WHERE sa_user.USER_ID = a_pay_flow.CHARGE_EMP_NO
AND rownum =1
) AS "REAL_NAME",
a_cashchk_flow.CASHCHK_NO AS "CASHCHK_NO",
a_pay_flow.CHARGE_DATE AS "CHARGE_DATE",
a_cashchk_flow.ACCT_STATUS_CODE AS "ACCT_STATUS_CODE",
a_cashchk_flow.ARRIVE_DATE AS "ARRIVE_DATE",
a_pay_flow.CHARGE_REMARK AS "CHARGE_REMARK",
a_pay_flow.CONS_NO AS "CONS_NO",
(SELECT ORG_NAME
FROM sa_org
WHERE sa_org.org_no = a_pay_flow.org_no
AND rownum =1
) AS "CONS_ORG_NAME",
a_cashchk_flow.DISPOSE_DATE AS "DISPOSE_DATE"
FROM a_pay_flow,
a_cashchk_flow
WHERE (((((a_cashchk_flow.CASHCHK_ID = a_pay_flow.CASHCHK_ID)
AND (a_pay_flow.CHARGE_DATE >= :1
AND a_pay_flow.CHARGE_DATE <= :2))
AND (A_PAY_FLOW.ORG_NO LIKE :3
AND a_cashchk_flow.org_no LIKE :4))
AND (A_PAY_FLOW.RCV_ORG_NO LIKE :5))
AND ( A_PAY_FLOW.PART_CHG_YM >= :6))
AND (A_PAY_FLOW.PART_CHG_YM <= :7)
ORDER BY a_pay_flow.CHARGE_DATE DESC,
a_pay_flow.TYPE_CODE ASC,
a_pay_flow.RCV_AMT ASC
) t
WHERE ROWNUM <= :8
)
WHERE RN2 > :9
（生产环境真实执行计划）
2.导致效率低下的原因：
索引 EPM_SN.AC_PAYINTO_AC_FLOW_FK"的优化程序统计信息已失效。
从执行计划可以看到a_pay_flow.charge_date字段进行了隐式类型转换从而导致该字段上的索引无法使用
，隐式类型转换会导致过多cpu的消耗，我们从执行计划的id=15可以看到cpu的消耗是420k
建议方案：
考虑收集此索引的优化程序统计信息。
execute dbms_stats.gather_index_stats(ownname => 'EPM_SN', indname =>
'AC_PAYINTO_AC_FLOW_FK', estimate_percent =>
DBMS_STATS.AUTO_SAMPLE_SIZE);
修改程序，把传入变量的类型修改成与字段类型一致，避免隐式的数据类型转换，避免消耗大量cpu资源
原执行效果：
从原执行计划看到此sql CBO估算的cpu的消耗为420K，每次执行逻辑读：130905，每次执行时间：22s
测试效果：

（生产环境真实执行计划）
对该sql的变量传入相应的数据类型的值之后，再执行查看其执行计划，看到CBO估算的cpu的消耗降低到了4，每次执行时间：2.95s。由此可看cpu和执行时间都大大缩短
测试日期：2013年10月24
生产库实际效果：
每次执行时间：2.95s
生产库确认日期：2013年10月24
2. Sql-2

所属函数或存储过程名称：
编号：XA_20131024_00002
模块名称：系统后台模块系统后台模块

问题描述：
1.存在问题的SQL
SQL_ID=' 8rf106msub9b7' CHILD_NUMBER=0
select count(*) from sa_log_login where sa_log_login.ORG_NO like :1 and sa_log_login.LOGIN_TIME > :2 and sa_log_login.LOGIN_TIME < :3

（生产环境真实执行计划）
每次逻辑读：2416229
每次执行时间：11.72s
2.导致效率低下的原因：
从原始执行计划中的谓词部分我们可以看到sa_log_logtime表的login_time字段进行了隐式类型转换，导致不能使用该字段上的索引，隐式类型转换会消耗cpu资源
建议方案：
建议修改程序，把绑定变量类型改成和login_time字段类型一致，这样就能够使用login_time字段上的索引，进而提高执行效率
原执行效果：
测试效果：

（生产环境真实执行计划）
我们注意到，把类型修改完之后的cpu cost、逻辑读以及执行时间都大大的减少，性能提高了近10倍
测试日期：2013年10月24
生产库实际效果：
每次逻辑读：22738
每次执行时间：1.3s
生产库确认日期：2013年10月24
3. Sql-3

所属函数或存储过程名称：例:TRANS_ID_TONAME
编号：XA_20131025_00006
模块名称：系统后台模块系统后台模块

问题描述：
1.存在问题的SQL SQL_ID='094hspafbxm2n'
SELECT COUNT(DISTINCT a.user_name)
FROM sa_log_login a
WHERE EXISTS
(SELECT 1 FROM sa_user b WHERE a.user_name = b.user_name
)
AND a.LOGIN_TIME > :1
AND a.LOGIN_TIME < :2
AND ( a.org_no LIKE '61405%')

（生产环境真实执行计划）
2.导致效率低下的原因：
从执行计划中看到SA_LOG_LOGIN表的LOGIN_TIME字段上进行了隐式类型转换，导致不能使用该字段上的索引，从而对性能产生严重影响
好多类似sql（只是like后面的值不一样），原因一样

建议方案：
原执行效果：
每次执行逻辑读：112656
每次执行时间：2.38s

测试效果：

（生产环境真实执行计划）
我们从执行计划中看到，修改数据类型和字段类型一致之后，cbo选择了索引，cost、逻辑读和执行时间都大大减少，整体性能也提高了10倍
测试日期：2013年10月25日
生产库实际效果：
每次执行时间：0.22s
每次逻辑读：54960
生产库确认日期：2013年10月25日

4. Sql-4

所属函数或存储过程名称：PRC_O_CUST_POWERON , PRC_O_PAP_FILE_CHK, PRC_O_PAP_CMPL_CHK
编号：XA_20131028_00007
模块名称：（所属应用系统的模块名称）
问题描述：
1.存在问题的SQL
SELECT COUNT (1)
INTO WKST_NUM1
FROM ARC_S_APP A, SA_WORKFORM_INST_HISTORY WF
WHERE TO_CHAR (A.HANDLE_TIME, 'YYYYMMDD') = V_FEE_MONTH
AND CONS_SORT_CODE = '01'
AND A.ORG_NO = WF.ORG_NO
AND A.ORG_NO = V_ORG_NO
AND A.APP_NO = WF.KEYDATA_ID
AND WF.INSTANCE_STATUS = '02'
AND EXISTS (SELECT 1
FROM ARC_S_POWERON
WHERE ARC_S_POWERON.APP_NO = A.APP_NO);

--高压完成2
SELECT COUNT (1)
INTO WKST_NUM2
FROM S_APP A
WHERE TO_CHAR (A.HANDLE_TIME, 'YYYYMMDD') = V_FEE_MONTH
AND CONS_SORT_CODE = '01'
AND ORG_NO = V_ORG_NO
AND EXISTS (SELECT 1
FROM S_POWERON
WHERE S_POWERON.APP_NO = A.APP_NO);
………….

2.导致效率低下的原因：
经查询在ARC_S_APP表的字段HANDLE_TIME是有索引的，然而在sql中我们看到该字段上添加了to_char函数，导致无法走索引，从而影响了整体性能

建议方案：
改写sql，去掉字段上的to_char函数，从而是sql能够使用上该字段上的索引，提高查询效率

原执行效果：

（生产环境真实执行计划）
每次执行逻辑读：1062
测试效果：

（生产环境真实执行计划）
从前后的执行计划中我们可以看到，每次执行产生的逻辑读降低了42倍
测试日期：2013年10月28日
生产库实际效果：
每次执行逻辑读：25
生产库确认日期：2013年10月28日
5. Sql-5

所属函数或存储过程名称：PRC_95598_DATA_DAY
编号：XA_20131028_00010
模块名称：
问题描述：
1.存在问题的SQL
DELETE FROM EPC_SN.S_IVR_APP_STAT A WHERE TO_CHAR(A.DEAL_TIME, 'YYYYMMDD') = DAY_DATE;
2.导致效率低下的原因：
经查询在DEAL_TIME字段上是已经存在索引，但是由于在该字段上使用了函数，导致sql无法使用索引，从而导致性能的严重下降
建议方案：
修改sql，去掉索引字段上的函数，进而能够使用索引，提高效率
原执行效果：

（测试环境下执行计划）
测试效果：

（测试环境下执行计划）
我们从前后的执行计划中看到，CBO评估的cost值大大减少
测试日期： 2013年10月28日

6. Sql-6

所属函数或存储过程名称：
编号：XA_20131028_00013
模块名称：
问题描述：
1.存在问题的SQL
select o1.org_name AS 供电单位,
a0.rcvbl_ym AS 应收年月,
count(0) AS 合计笔数,
sum(a0.rcvbl_amt) AS 应收金额,
sum(a0.rcved_amt) AS 实收金额,
u1.real_name AS 收费员,
y1.PROP_LIST_NAME AS 到帐状态
from a_rcvbl_flow a0,
a_rcved_flow a1,
a_cashchk_flow a2,
a_pay_flow a3,
epsa_sn.sa_prop_list y1,
epsa_sn.sa_org o1,
epsa_sn.sa_user u1
where a0.rcvbl_amt_id = a1.rcvbl_amt_id
and a1.charge_id = a3.charge_id
and a2.cashchk_id = a3.cashchk_id
and a3.org_no like :1 || '%'
and a3.pay_mode like nvl(null, '%')
and a2.acct_status_code like nvl(null, '%')
and a3.charge_emp_no like nvl(null, '%')
and to_char(a3.charge_date, 'yyyy-MM-dd') >= nvl(null, '200001')
and to_char(a3.charge_date, 'yyyy-MM-dd') <= nvl(null, '220001')
and a0.rcvbl_ym >= nvl(:2, '200001')
and a0.rcvbl_ym <= nvl(:3, '220012')
and o1.org_no = a3.org_no
and u1.user_id = a3.charge_emp_no
and y1.PROP_TYPE_ID = 'acct_status_code'
and y1.PROP_LIST_ID = a2.acct_status_code
group by a0.rcvbl_ym,
a3.org_no,
a2.acct_status_code,
a3.charge_emp_no,
u1.real_name,
o1.org_name,
y1.PROP_LIST_NAME;
2.导致效率低下的原因：
经查询在a_pay_flow. charge_date字段上已经存在索引，然而该sql在该字段上添加了函数，导致索引无法使用，从而导致性能严重下降
建议方案：
改写sql去掉charge_date字段上的函数，进而能够使用该字段上的索引，提升效率
原执行效果：

测试效果：

测试日期： 2013年10月28日
可以看到去掉索引字段上的函数之后，cpu的cost值大大减少，性能得到很大提升

7. Sql-7

所属函数或存储过程名称：PRC_DELETE_HUIFANG_YK
编号：XA_20131028_00014
模块名称：
问题描述：
1.存在问题的SQL
SELECT A.KEYDATA_ID
FROM EPSA_SN.SA_WORKFORM_INST A, EPM_SN.ARC_S_APP B
WHERE A.KEYDATA_ID = B.APP_NO
AND B.VOLT_CODE IN ('AC02202', 'AC03802')
AND A.WORKFORM_TYPE = '002'
AND TO_CHAR(A.START_TIME, 'YYYYMMDD') = TO_CHAR(SYSDATE - 1, 'YYYYMMDD')
AND ROWNUM <
(SELECT COUNT(1)
FROM EPSA_SN.SA_WORKFORM_INST A, EPM_SN.ARC_S_APP B
WHERE A.KEYDATA_ID = B.APP_NO
AND B.VOLT_CODE IN ('AC02202', 'AC03802')
AND A.WORKFORM_TYPE = '002'
AND TO_CHAR(A.START_TIME, 'YYYYMMDD') = TO_CHAR(SYSDATE - 1, 'YYYYMMDD')) * 0.949;
2.导致效率低下的原因：
经查询在EPSA_SN.SA_WORKFORM_INST 表的START_TIME字段上已经存在索引，但是该sql在该字段上添加函数，从而导致无法使用索引，最终导致该sql整体性能严重下降
建议方案：
修改sql，去掉索引字段START_TIME字段上的函数，使执行计划能够走索引，提高执行效率
原执行效果：

（生产环境下执行计划）
测试效果：
SELECT A.KEYDATA_ID
FROM EPSA_SN.SA_WORKFORM_INST A,
EPM_SN.ARC_S_APP B
WHERE A.KEYDATA_ID = B.APP_NO
AND B.VOLT_CODE IN ('AC02202', 'AC03802')
AND A.WORKFORM_TYPE = '002'
AND A.START_TIME>= trunc(SYSDATE - 1) and a.START_TIME< trunc(SYSDATE)
AND ROWNUM <
(SELECT COUNT(1)
FROM EPSA_SN.SA_WORKFORM_INST A,
EPM_SN.ARC_S_APP B
WHERE A.KEYDATA_ID = B.APP_NO
AND B.VOLT_CODE IN ('AC02202', 'AC03802')
AND A.WORKFORM_TYPE = '002'
AND A.START_TIME>= trunc(SYSDATE - 1) and a.START_TIME< trunc(SYSDATE)
) *0.949;

（生产环境下执行计划）
测试日期： 2013年10月28日
从前后的执行计划对比，我们可以看到去掉索引字段上的函数之后，cpu的cost值和逻辑读都大大减少，提高了整体的执行效率

8. Sql-8
所属函数或存储过程名称：
编号：XA_20131028_00015
模块名称：
问题描述：
1.存在问题的SQL
Sql_id='7fpts7u6nttcn'
Schema Name: EPSA_SN

SELECT DISTINCT b.user_id,
b.real_name,
c.dept_name,
d.org_name,
e.max_login_time login_time
FROM sa_log_login a,
sa_user b,
sa_dept c,
sa_org d,
(SELECT user_name,
MAX (login_time) max_login_time
FROM sa_log_login
GROUP BY user_name
) e
WHERE a.user_name = b.user_name
AND a.user_name = e.user_name
AND b.dept_id = c.dept_id
AND c.org_no = d.org_no
AND a.login_time > :1
AND a.login_time :2
AND ( d.org_no LIKE '61401%')
2.导致效率低下的原因：
从执行计划中可以看到该sql中sa_log_login表的login_time字段进行了隐式类型转换，导致其上面的索引无法使用，从而导致严重的性能问题

建议方案：
修改应用sql，把传入到login_time字段中的变量的类型改成和login_time字段类型一致的，这样就可以使用其字段上的索引
原执行效果：

在30分钟内执行882次，每次逻辑读1764147，每次执行时间15s
（生产环境下执行计划）

9. Sql-9

所属函数或存储过程名称：
编号：XA_20131028_00016
模块名称：
问题描述：
1.存在问题的SQL
Sql_id='62qs5xy59346s'
Schema Name: EPM_SN
SELECT COUNT(DISTINCT a.user_name)
FROM sa_log_login_history a
WHERE EXISTS
(SELECT 1 FROM sa_user b WHERE a.user_name = b.user_name
)
AND a.LOGIN_TIME > :1
AND a.LOGIN_TIME < :2
2.导致效率低下的原因：
从执行计划中可以看到该sql中sa_log_logi_history表的login_time字段进行了隐式类型转换，导致其上面的索引无法使用，从而导致严重的性能问题，隐式类型转换会消耗大量的cpu资源，从执行计划中我们也可以注意到cpu消耗非常高

建议方案：
修改应用sql，把传入到login_time字段中的变量的类型改成和login_time字段类型一致的，这样就可以使用其字段上的索引，减少cpu的消耗，同时也减少逻辑读
原执行效果：

在30分钟内执行6次，每次逻辑读228690，每次执行时间3.3s
（生产环境下执行计划）

2.2.2. 缺少必要索引
1. Sql-1
所属函数或存储过程名称：
编号：XA_20131024_00004
模块名称：新装增容及变更用电新装增容及变更用电

问题描述：
1.存在问题的SQL
select count(1) as count
from rt_workiteminst w
where (W.CURRENT_STATE = 0 or W.CURRENT_STATE = 1 or W.CURRENT_STATE = 2)
and w.limit_time > 0 and (w.overdued =1 or w.overdued=3)

2.导致效率低下的原因：
该表碎片严重，需要从新整理碎片，缺少必要索引
建议方案：
对该表和表上的索引进行碎片整理
我们查询在rt_workiteminst表的overdued字段上数据分布不均衡，而且该字段的基数很低，值为1或3的值的数据量占很少一部分，所以非常适合创建所以
在overdued字段上创建索引，同时搜集该字段上的直方图，告诉CBO该字段上数据的分布情况，以便选择最优的执行计划
create index flow_sn.rt_work on FLOW_SN.rt_workiteminst(overdued) parallel 4;
alter index flow_sn.rt_work parallel 1;
exec dbms_stats.gather_table_stats('flow_sn','rt_workiteminst',estimate_percent=>60,method_opt=>'for columns overdued size 10',degree=>4,cascade=>true);
原执行效果：
每次执行时间：205s
每次物理读：1347026
测试效果：

从执行计划上看，cost、逻辑读和执行时间都大大减少
测试日期：2013年10月24日
生产库实际效果：
每次逻辑读：6
每次执行时间：0.1s

生产库确认日期：2013年10月24日
2. Sql-2
所属函数或存储过程名称：例:TRANS_ID_TONAME
编号：XA_20131025_00005
模块名称：电费收缴及营销账务电费收缴及营销账务

问题描述：
1.存在问题的SQL
SELECT * FROM v$sql WHERE sql_id='0rm64krm4qd2h';
select
a_rcvbl_flow.CONS_NO as "CONS_NO",
c_cons.CONS_NAME as "CONS_NAME",
c_cons.ELEC_ADDR as "ELEC_ADDR",
max(c_cons.MR_SECT_NO) as "MR_SECT_NO",
nvl(SUM(a_rcvbl_flow.RCVBL_AMT) ,0) - nvl(SUM(a_rcvbl_flow.RCVED_AMT) ,0) as "OWE_FEE",
nvl(SUM(a_rcvbl_flow.T_PQ) ,0) as "T_PQ",
nvl(SUM(a_rcvbl_flow.RCVBL_AMT) ,0) as "RCVBL_AMT",
nvl(SUM(a_rcvbl_flow.RCVED_AMT) ,0) as "RCVED_AMT",
nvl(SUM(a_rcvbl_flow.DISPOSE_AMT) ,0) as "DISPOSE_AMT",
nvl(SUM(a_rcvbl_flow.rcvbl_penalty), 0) as "RCVBL_PENALTY",
nvl(SUM(a_rcvbl_flow.rcved_penalty), 0) as "RCVED_PENALTY",
nvl(SUM(a_rcvbl_flow.dispose_penalty), 0) as "DISPOSE_PENALTY",
a_rcvbl_flow.STATUS_CODE as "STATUS_CODE",
a_rcvbl_flow.PAY_MODE as "PAY_MODE",
a_rcvbl_flow.RCVBL_YM as "RCVBL_YM",
a_rcvbl_flow.amt_type AMT_TYPE,
--结清标志
(
case
when min(a_rcvbl_flow.settle_flag) = max(a_rcvbl_flow.settle_flag) and min(a_rcvbl_flow.settle_flag) = '01' then '01'
when min(a_rcvbl_flow.settle_flag) = max(a_rcvbl_flow.settle_flag) and min(a_rcvbl_flow.settle_flag) = '03' then '03'
else
'02'
end
) as "SETTLE_FLAG",
c_cons.elec_type_code as "ELEC_TYPE_CODE",
c_acct.pay_no as "PAY_NO",
c_acct.MAIN_CONS_NO as "MAIN_CONS_NO",
decode(SUM(a_rcvbl_flow.DISPOSE_AMT),SUM(a_rcvbl_flow.RCVBL_AMT),'到账','在途') as "ACCT_STATUS",
(SELECT ORG_NAME FROM sa_org WHERE ORG_NO = c_cons.ORG_NO) as ORG_NAME, --供电单位
(SELECT sa_user.real_name
FROM r_oper_activity, sa_user
WHERE r_oper_activity.act_code = '03'
AND r_oper_activity.operator_no = sa_user.user_id
AND r_oper_activity.MR_SECT_NO = c_cons.MR_SECT_NO ) as READER_NAME, -- 抄表员
max(c_cons.CONS_SORT_CODE) as "CONS_SORT_CODE", --用户类别(01 高压,02 低压非居民,03 低压居民)
nvl(SUM(a_rcvbl_flow.RCVBL_AMT) ,0) - nvl(SUM(a_rcvbl_flow.DISPOSE_AMT) ,0) as "RCVBL_DISPOSE" --欠费(收妥)
from a_rcvbl_flow, c_cons, c_acct, c_payment_rela
where (a_rcvbl_flow.CONS_NO