在什么情况下 Oracle 高级排队是实现功能需求的首选机制？例如，从银行账户 A 到银行账户 B 的汇款在理论上可能被认为是两种不同的操作，并且可以分别实现——首先，将来自账户 A 的汇款入队（更新），然后将资金转移到账户 B（更新） . 但是，很明显它不能那样做，因为这两个操作应该在一个一致的操作中完成 - 在事务中。
也许只有在开发执行一些内部（通过执行 DML 操作和调用其他本地存储的 proc/fnc）和外部（通过调用一些 web 服务）的逻辑的存储过程/函数时才应该考虑高级排队。当使用这种对 webservices 的调用时，我们不能把它全部包装成一致的事务，所以唯一的方法是使用一些排队机制......
任何现实生活中的详细示例将不胜感激。
我好奇的不是技术本身的细节，而是使用这种消息传递的真实案例是什么，因为我以前没有这样做过。比如，为什么我需要传递一些数据（消息有效负载）？
我对 Oracle 并不像对 Postgres 那样熟悉。尽管如此，我会告诉你我在哪里看到这样的排队方法是理想的（作为pg_message_queue的作者）：允许数据库事务以最小的复杂性成本具有非事务性副作用。一个简单的例子是“当我们提交一个交易说我们已经发货了一个零件时，让我们发送一封电子邮件通知客户。”
您可以在没有 Oracle AQ 的情况下执行此操作，但 Oracle AQ 可能会使这变得更简单。关键因素是，这允许您将消息排入队列，使其在提交时可见，并且一旦数据库事务提交而不是之前，该消息将成为电子邮件的基础。如果您尝试从事务内部发送消息，则会遇到许多令人讨厌的失败案例：
另一个例子可能是松散耦合的应用程序，集成在消息队列上。每个应用程序在很大程度上可以在不知道另一个应用程序的情况下运行，但是当事务提交时，消息会发送到另一个应用程序。如果他们不能立即交付，没问题。我们会尽可能处理它们。
所以基本的事情是，在很多情况下，您希望围绕数据库集中逻辑，而您无法在单个事务中真正正确地完成所有事情。能够在 db commit 上向其他组件发送消息真的很有帮助。
并且确保您可以在没有 AQ 的情况下自己构建一切。但这已经为您构建好了。
编辑：我在这里重新阅读了 Oracle 文档，它们令人绝望地令人困惑，所以我不会因为你的困惑而责怪你。如果我不是对他们谈论的事情有点熟悉，我不确定我是否能够跟上他们。不过，我现在 100% 确定我的答案是符合目标的。