【问题标题】:Embedded Newline Character Issue in Redshift Copy CommandRedshift 复制命令中的嵌入式换行符问题
【发布时间】:2017-03-06 17:22:45
【问题描述】:

我们在源 S3 文件的字段中嵌入了十五个换行符。 Redshift 中目标表的字段大小为VARCHAR(5096)。源文件中的字段长度为5089 字节。根据copy 命令的 ESCAPE 选项的要求,我们使用反斜杠 \ 转义十五个换行符中的每一个。我们对 ESCAPE 选项的期望是,在 Redshift 中加载目标之前,我们在每个换行符之前插入的反斜杠 \ 将被忽略。但是,当我们使用带有 ESCAPE 选项的 copy 命令时,我们得到了

err_code:1204 - 字符串长度超过 DDL 长度。”

有没有一种方法可以使添加的反斜杠 \ 字符不计入 Redshift 中的目标列加载?

注意:当我们将文件中的上述源字段截断为4000字节并在换行符之前插入反斜杠\时,带有ESCAPE选项的copy命令成功加载了Redshift中的字段。此外,反斜杠 \ 字符未按预期加载到 Redshift 中。

【问题讨论】:

    标签: amazon-s3 copy amazon-redshift


    【解决方案1】:

    您冷扩展您的 VARCHAR 长度以允许更多字符。

    或者,您可以使用TRUNCATECOLUMNS 选项尽可能多地加载而不会产生错误。

    【讨论】:

    • 谢谢约翰!但我们面临的实际问题是不同的。我在回答中提到了细节。
    【解决方案2】:

    我们对上述问题的理解是不正确的。我们插入的反斜杠“\”不会导致错误“err_code:1204 - 字符串长度超过 DDL 长度。”。复制命令的“转义”选项实际上并未将插入的反斜杠字符计入目标限制,并且还正确地将它们从加载的值中删除。

    实际面临的问题是我们尝试加载的某些字符是多字节 UTF8 字符。由于我们错误地假设它们的长度为 1 个字节,因此目标字段的大小被证明是不够的。我们将目标字段的长度从varchar(5096)增加到varchar(7096),之后所有数据都加载成功了。

    【讨论】:

      猜你喜欢
      • 2014-09-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-04-18
      • 1970-01-01
      • 2022-01-23
      相关资源
      最近更新 更多