我们有一个交易表- AET保存客户每天赚取的应计金额（sub_account_id，money_group_id）。在每个月的月底（支付日期），我们尝试将每个客户（sub_account_id，money_group_id）赚取的应计金额相加。
AET表每天存储约3000万笔交易。在支付日（每月的最后一天），我们尝试执行超过9000万（每天30 M * 30天）的聚合。表将保存最近90天的数据，任何超过90天的数据将被推送到单独的存档表。因此，我们目前有基于position_ts的分区表和基于investment_product_cd的40个散列子分区（因为我们基于investment_product_cd进行处理）。下表列出了表10。
支付日期查询确定为耗时如下所示。目前，每天有300万个客户条目的大型investment_product_cd大约需要2.5小时才能完成。
investment_product_cd -->大约有1500到2000张investment_product_cd。客户（sub_account_id和money_group_id）已注册到此investment_product_cds中。大约有10到15个大型投资_产品_CD，我们每个都有300万客户注册。accumulation_period_id -->该ID是为每个investment_product_cds的支付期间生成的。例如，将为investment_product_cds - ABCD生成一个account_period_id，支付期间（应计开始日期-2023年7月1日应计结束日期-2023年7月31日）close_out_ind -->的值可以为“Y”或“N”
我们正在努力提高我们的支付日期查询的性能。尝试将时间从150分钟（2.5小时）缩短。欢迎提出任何建议。
我试着解释有没有完全平行的暗示
2条答案
按热度按时间ego6inou1#
对于这样的汇总查询，您需要确保：
1.您正在执行全段扫描，而不是使用索引
1.您正在进行分区修剪
1.你可以充分利用并行性
1.你有足够的PGA来避免多遍排序
第一步，删除
ORDER BY。当您只是将结果写入另一个表时，添加这种昂贵的排序没有意义。然后，试试这些提示：
同时检查
v$pgastat中的global memory bound，并确保其最大值为1G。如果不是，让DBA提升数据库的pga_aggregate_target，直到全局绑定达到1G。问一下有多少CPU可用，如果它是一个有几十个或几百个CPU核心的坚固的盒子，继续把并行度从16提高到32。这不仅会使更多的内核进入混合，还将在溢出到临时内存之前使用更多的PGA内存。
确保你实际上得到了你所要求的并行性。查看您正在运行的
sql_id的gv$session中的行数，并确保它不只是一行。应该是要求的2倍。如果你得到的更少，请你的DBA调查你被降级的原因。c8ib6hqw2#
也许能分散疼痛
添加一个触发器，将每个用户事务聚合到汇总表中。那么你需要做的就是查询每个用户的当前摘要。