Amazon Redshift - 获取光标命令挂在集群上

Question

我们有一个存在性能问题的 Redshift 集群。在集群上运行某些查询时，查询计划中有一个中间步骤Fetch 200 in "SQL_CUR7"。此步骤会导致查询挂起并阻塞集群。我们还没有定义这个游标，它似乎是由 Redshift 预先定义的。有人知道这种类型的光标是做什么的吗？如果这可能是我们的性能问题的原因？

Answer 1

该名称 SQL_CUR7 看起来像 Tableau 使用的命名，但它可能来自使用相同命名或正在复制的其他工具或用户。通常，Tableau 一次会获取 10,000 行，因此它可能不是 Tableau。关键是 FETCH 不是您的问题 - 它可能是 fetch 背后的查询。

让我们从一些背景开始。当您运行查询（选择...）时，该查询的结果将发送回给您 - 所有这些结果，无论有多大。来自 Redshift 的数据量可能会淹没较小的计算机并导致网络瘫痪。相反，可以声明一个“游标”，查询的结果可以临时存储在那里（在这种情况下是在 Redshift 领导节点上）。游标的内容由 FETCH 命令读取，该命令将指定数量的行拉出。这样，读者就不会被超出其处理能力的数据所淹没。可以重复提取，直到读取游标的所有行。

游标由 DECLARE 语句定义，该语句还指定要运行的查询以填充游标。但是，在游标的第一个 FETCH 发生之前，查询不会运行。后续的提取只是拉取更多在执行第一个 FETCH 时填充在游标中的数据。这样做的缺点是看起来 fetch 是正在运行的东西，它并不能告诉你正在发生的事情。正在运行的是在 DECLARE 语句中定义的 SQL，您需要找出该 SQL 是什么才能了解​​发生了什么。

追溯这件事并不难。游标仅在事务打开的时间内存在。这意味着 FETCH 和 DECLARE 在同一个事务 (xid) 中。因此，在“SQL_CUR7”中找到'Fetch 200'的xid，并使用它在系统表SVL_STATEMENTTEXT 中找到此事务（xid）中发出的所有语句。 （Xids 可以在一段时间后重用，因此您可能只想查看执行 fetch 的时间窗口。）您应该看到一个定义“SQL_CUR7”的语句 - DECLARE “SQL_CUR7” ... - 这是 SQL提取发生时正在运行。

既然您看到了这个 SQL，事情可能会开始理解为什么事情会变得超载。查询可能很糟糕，并与其他所有事物交叉连接世界。它可能会用中间结果填满磁盘。查询可能会返回大量数据，并且需要缓冲的数据使领导节点超载。您可能需要进行一些诊断工作，但至少现在您拥有需要分析的代码。