Teradata SQL：行大小或排序键大小溢出

Question

从 SQLA 中的 86 列组成的表中选择所有列时，我总是收到错误 Row size or Sort Key size overflow。避免此错误的唯一方法是减少 select 中的列数，但这是一种非常规的解决方案。必须有一种方法可以在一个 select 语句中选择该表中的所有列。

赏金

我正在添加此赏金，因为我无法再破解此问题。必须有一个解决方案。现在，我正在从包含 Unicode 列的表中进行选择。我假设这导致行大小超过容量。当我从连接字符串中删除Session Character Set=UTF8 时，我收到The string contains an untranslatable character 的错误。我正在使用 NET 数据提供程序 14.0.0.1。有没有办法增加尺寸？

更新

Rob，你永远不会停止给人留下深刻印象！您建议使用 UTF16 有效。在我更新我的 ODBC 配置后，它甚至可以在 SQLA 中工作。我一直认为我的问题是我对 ASCII、拉丁文、UTF8 和 UTF16 缺乏了解。

我们还有一个 80 列的表，其中包含所有拉丁列，其中一些是 `varchar(1000)'。在 UTF8 和 UTF16 中从 SQLA 中进行选择时，我在 SQLA 中遇到相同的错误，但在我的 ODBC 配置中将我的字符集更新为 ASCII 或拉丁模式后，我可以从中进行选择。

Rob，您能否提供有关这里发生的情况的见解？我的理论是，因为它在拉丁语集中，使用 UTF8 或 UTF16 会导致转换为更大的字节集，从而导致错误，尤其是对于 varchar(1000) 的。如果我使用拉丁语作为我的会话字符集，则不会进行任何转换，并且我会以本机编码获得字符串。至于有问题的问题，UTF8失败是因为编码不能“降级”吗？

根据请求，这里是相关表的 DDL：

CREATE MULTISET TABLE mydb.mytable ,NO FALLBACK ,
     NO BEFORE JOURNAL,
     NO AFTER JOURNAL,
     CHECKSUM = DEFAULT,
     DEFAULT MERGEBLOCKRATIO
     (
      FIELD1 VARCHAR(214) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
      FIELD2 VARCHAR(30) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD3 VARCHAR(60) CHARACTER SET UNICODE CASESPECIFIC NOT NULL,
      FIELD4 VARCHAR(4000) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD5 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD6 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD7 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD8 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD9 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD10 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD11 VARCHAR(3600) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD12 VARCHAR(3600) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD13 VARCHAR(3600) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD14 VARCHAR(3600) CHARACTER SET UNICODE CASESPECIFIC)
PRIMARY INDEX ( FIELD1 );

Answer 1

在没有看到您的表定义的情况下，您是否考虑过为您的SESSION CHARSET 使用 UTF16 而不是 UTF8？

对您的错误消息进行的更多研究发现此 post 表明 UTF16 可能使您能够返回 UTF8 否则无法返回的记录。

编辑： 如果您还记得我上面分享的链接，对于给定的 VARCHAR(n)，要存储的字节如下：

• 拉丁语：n 个字节
• UTF8：n*3 字节
• UTF16：n*2 字节

这意味着 UTF8 会话中的 VARCHAR(4000) UNICODE 字段应该需要 12KB。如果您必须始终如一地处理 UNICODE 数据，则将默认会话字符集保留或更改为 UTF16 可能对您有利。根据我的经验，我不必使用 UNICODE 数据，因此我无法告诉您更改字符集是否会为数据库中其他地方的 LATIN 数据引入什么陷阱。

希望这会有所帮助。