Teradata SQLA:行大小或排序键大小溢出

时间:2012-08-08 12:43:21

标签: teradata

当从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。有没有办法增加尺寸?

更新

罗布,你永远不会停止留下深刻的印象!您建议使用UTF16工作。更新我的ODBC配置后,它甚至可以在SQLA中运行。我认为我的问题一直是我对ASCII,拉丁语,UTF8和UTF16缺乏了解。

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

罗,您能否提供有关这里发生的事情的见解?我的理论是,因为它在拉丁语集中,使用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 );

1 个答案:

答案 0 :(得分:3)

如果没有看到您的表格定义,您是否考虑过为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数据。

希望这有帮助。