【问题标题】:Improving Performance of a Procedure block with Huge volume of DML operations [closed]通过大量 DML 操作提高过程块的性能 [关闭]
【发布时间】:2020-10-24 19:53:54
【问题描述】:

编辑-让我重新构建问题。 在最近一次 PLSQL 开发人员职位的面试中,有人问我这样一个问题:

有一个存储过程在短时间内跨多个节点同时执行。这会导致表上发生大量事务(DML 操作 - INSERT、UPDATE 和 DELETE)。

例子:

CREATE OR REPLACE PROCEDURE high_vol_sp() AS

BEGIN

DML OPERATIONS
COMMIT;
END high_vol_sp;

我应该创建一个 PLSQL 存储过程或修改现有过程,以便提高大量 DML 操作的性能。

如何提高程序块的性能? 你将如何处理这个问题? 你会使用什么类型的 SQL 语句来解决这个问题?

客户要求编写 SQL 查询来处理这种情况。 没有提供其他文档。

它与交易/核心银行领域有关。 谁能解决这个问题?

我想到了使用集合数组和 FORALL 来执行批量插入。 但想不出更新或删除的解决方案。

【问题讨论】:

  • 恐怕这没有任何意义。要解决什么问题?
  • @AndrewSayer 我的错。道歉。我现在修改了这个问题。我相信这应该是有道理的。
  • “dml 操作”云中可能隐藏着许多机会。而且我们不知道单独执行的性能本身是否需要改进,或者问题是否在于多个并发执行之间的冲突。 “在短时间内同时跨多个节点”可能是矛盾的。 “同时”就是这个意思。 “在很短的时间内”可能是 3 秒内执行 10 次,但实际上没有一个是同时执行的。
  • @EdStevens 考虑这种情况。在股票市场中,经纪人的交易应用程序可以下达数百万个股票买卖订单。大部分交易发生在几秒钟内跨系统,尤其是在开始的那一分钟。比如说,更新查询正在减慢这个过程。我可以采取哪些步骤来提高查询的性能?
  • 无论是股市、银行还是当地的五金店都没有关系。如果您需要减少完成交易的时间,原则是相同的。贾斯汀概述了一些优点。但是,如果您的任务是重新编写一个特定的程序,那么您必须有代码才能开始——而我们没有。因此,甚至针对代码本身制作通用的 cmets 确实是不可能的。它可能涉及许多需要纠正的不良做法。

标签: sql oracle plsql transactions


【解决方案1】:

我可能会从对代码进行某种分析开始。除非您知道什么是慢,否则尝试提高性能是没有意义的。在采访中,这将使您有机会谈论 AWR、ADDR 和 ASH 报告、10046 跟踪等。

一旦您知道大量 DML 中的哪些内容实际上很慢,您就可以开始调整了。

  • 从简单的开始——某些 DML 是否因为缺少索引而变慢?如果是这样,这是一个快速简单的解决方法。
  • 根据您从分析中看到的情况,单线程性能有问题吗?还是不同线程相互干扰的问题(即您有某种锁争用)?如果您正在尝试调试锁争用,则需要查看锁定行的顺序以及如何调用该过程以查看是否可以重新组织调用者以最小化争用 - 例如,如果您有多个调用线程,您宁愿它们为不同的帐户进行处理,而不是让所有调用线程为同一个帐户处理不同的事务。
  • 代码是否进行了大量的逐行处理?如果是这样,将其重构为基于集合的处理可能是一个显着的优势。这可以包括将集合传递给过程等操作,这样您就不必在循环中调用它们。
  • 如果您正在执行大量无法合理重构的逐行处理,请考虑使用带有bulk collectforall 的集合。
  • 程序正在执行的某些事情是否严格不需要同步完成?如果是这样,您可以通过将这些因素分解到单独的工作中来获得显着的改进。发送电子邮件之类的事情相对容易排除,但通常还有其他代码可以排队并由不同的进程异步完成。

这些项目中的任何一项都会(可能)影响所有不同类型的 DML——它们都不是特定于 select 语句与 insertupdatedelete 语句的。

【讨论】:

  • 非常感谢贾斯汀的回答。对我很有帮助。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-05-18
  • 1970-01-01
  • 1970-01-01
  • 2014-11-25
  • 1970-01-01
  • 2011-08-19
  • 1970-01-01
相关资源
最近更新 更多