2

作为 Cap 的一部分，一直使用这个公式作为 TB 大小计算的标准。规划努力。我们在 TD 14

     ( rc *   ( rsz / ( blocksize -38) ) * blocksize ) 
      + ( SQL (sel Hashamp()+1 ; ) * 1024 ) 

rsz : row size , rc : count ( * )

其实这里

 (blocksize-38)/rsz

只不过是行/块。结果是分数 < 1。我认为这很糟糕，因为这意味着几个块跨越一行。我的问题是

  • 公式是否需要进一步磨练。后半部分在加号后，提供表头。此表没有 SI - 只有 2 个 dates 、 1 个 Integer 和 1 个 varchar (50) 和 NUPI 是 NPPI 。它们都不是 Nullable 并且显然没有数据，开始时没有什么是可压缩的（好吧，现在没有足够的数据信息来进行压缩，但我们稍后会运行压缩脚本）
  • 因为它将是跨越一行的几个块 - 我应该增加块大小？多少 - 每个块的理想行数应该是多少。表格数据将每季度进行一次全面刷新，并且在此期间不会发生任何事情
4

1 回答 1

3

Teradata 中的一行从不跨越块。

你只是把你的计算弄错了，你说的是(blocksize-38)/rsz，但实际的计算表明了rsz / ( blocksize -38)。

随着新版本中的块开销增加到 74，这应该是正确的计算：

 ( rc /  (( blocksize - 74)/rsz ) * blocksize ) 
      + ( (HASHAMP()+1  ) * 1024 )

它可以在 Sizing Base Tables、Hash Indexes 和 Join Indexes中找到

但是您会注意到这种方法rc * rsz适用于较大的表。由于没有人关心小表，我通常使用这个简化的计算来调整表的大小（您可能会增加 1% 或 2% 以获得最大可能大小）。

编辑：

不是计算错误，而是由于使用了基本数据类型（可能是 a 的截断DECIMAL）。更改为FLOAT或NUMBER：

 ( rc *   ( rsz / ( CAST(blocksize -74 AS FLOAT)) ) * blocksize ) 
  + ( (HASHAMP()+1  ) * 1024 )
于 2016-01-07T07:24:27.867 回答