如何避免带有非常大的 IN 表的 dbsql_stmnt_too_large 转储？

Posted 2023-02-18

【中文标题】如何避免带有非常大的 IN 表的 dbsql_stmnt_too_large 转储？

【英文标题】：How to avoid a dbsql_stmnt_too_large dump with a very large IN table?

【发布时间】：2022-01-08 10:52:05

【问题描述】：

我的报告有一个带有选择选项范围的屏幕，如果用户输入的条目很少，报告工作正常，但如果用户在范围内输入几千个条目，则会发生转储：

dbsql_stmnt_too_large

系统说下面的 SELECT 查询有问题。这太复杂了。 我不知道如何解决它。 有人可以帮我解决一下吗？

查询看起来是这样的：

SELECT * FROM ZDBtab INTO TABLE gt_itab WHERE dbfeld1 LE gv_feld1
AND dbfeld2 IN gt_itab2
AND (  
       ( dbfeld3 NE ' ' AND dbfeld3 NE gv_feld2 )
    OR ( dbfeld4 NE ' ' AND dbfeld4 NE gv_feld2 )
    OR ( dbfeld5 NE ' ' And dbfeld5 NE gv_feld2 )
    ).

它是一个普通的 ERP 不是 S4 而是 HanaDB 的 Hana DB

【问题讨论】：

请注明您的数据库系统和版本。

"用户输入了几千个条目" ...为什么用户这样做？那里的模式是什么？

检查这个***.com/a/55795285/911419注意事项在哪里不使用范围

【参考方案1】：

检查是否需要那么多条目

根据我的经验，用户不需要“几千个条目”。要么有 许多 个重复项，要么他们必须使用一份报告的结果作为另一份报告的输入。这通常意味着一开始就应该是一份报告而不是两份。

如果你被当前的设置卡住了，你仍然可以从技术方面修复它。

检查重复项，然后将gt_itab2 切成更小的部分

检查重复项，然后删除它们

一个。 SORT + DELETE ADJACENT DUPLICATES 是最简单的

b. COLLECT 是最快的

如果gt_itab2 只包含I 和EQ，则可以使用 FOR ALL ENTRIES

如果没有，您可以将 gt_itab2 切成 1000 个（或您的数据库可以处理的任何内容）的切片，然后在 WHILE 中选择，直到您处理完所有 gt_itab2

【参考方案2】：

IN gt_itab2    " <<< will have too many entries for 1 statement

IN 状态转换为表中每个条目的 OR 语句。 1 个 SQL 语句的实际语句大小是有限的。 （默认为 64k） https://maxdb.sap.com/doc/7_6/f6/069940ccd42a54e10000000a1550b0/content.htm

您可以尝试使用for all entries 选项或其他一些访问策略来避免大 IN 表选项。

编辑：提供有关实际数据库的信息后。 所以这里是HANA DB。 HANA DB SQL Docu 在 HANA 上是一个巨大的 2gb 语句大小。 因此，在构建 SQL 语句时，可能会耗尽其他一些内存分配限制。无论如何，如果您在 gt_itab2 中有大量条目，那么这很可能是问题所在。

【讨论】：

限制取决于数据库系统和版本，OP没有说它是什么。您的参考仅涉及数据库 SAP MaxDB 7.6 版。

是的，对不起。这是一个具有正常 erp 而非 s4hana 的 hana db。但是数据库是hana

这是对所有 ERP 数据库的类似限制。该声明仍然需要在 HANA 上形成。那么 HANA 上的最大语句大小是多少？

在哪里可以查到？是的，为了测试，我们在选择屏幕中输入了大约 60,000 个文档编号。然后发生这个转储。在较低的选择范围内，代码可以工作

第一个链接中提到的 64 kB 是 increased to 1 MB 超过十倍前。该链接适用于 Oracle，但它也发生在其他数据库中。