【问题标题】:Retention period in SQL Server 2008 Change TrackingSQL Server 2008 更改跟踪中的保留期
【发布时间】:2010-06-05 05:45:02
【问题描述】:

我有点担心 SQL Server 2008 更改跟踪中的默认保留期(即 2 天)。

将此时间段设置为例如是否是个好主意。 100 年并关闭自动清理,或者它会在未来因过度使用存储和/或性能下降而咬我?有人有这方面的经验吗?

【问题讨论】:

    标签: sql-server change-tracking


    【解决方案1】:

    如果您关闭自动清理,最好定期检查并自行删除更改跟踪信息,方法是禁用然后重新启用每个表的更改跟踪。否则,是的,跟踪数据将继续增长。

    您不能直接查询基础表,但可以查看它们的元数据。以下查询显示相对行数:

    select 
      s.name as schema_name
    , t.name as table_name
    , (select sum(rows) from sys.partitions x where o.parent_object_id = x.object_id) as rows_in_base_table
    , o.name as tracking_table
    , p.rows as rows_in_tracking_table
    from sys.objects o
    join sys.tables t on o.parent_object_id = t.object_id
    join sys.schemas s on t.schema_id = s.schema_id
    join sys.partitions p on o.object_id = p.object_id
    where o.name like 'change[_]tracking%'
      and o.schema_id = schema_id('sys')
    order by schema_name, table_name
    

    在您的数据库中运行它,您应该大致了解当前的开销。

    更改跟踪表都遵循标准架构。例如:

    select 
      c.name, c.column_id
    , type_name(user_type_id) as type_name
    , c.max_length, c.precision, c.scale
    , c.is_nullable, c.is_identity
    from sys.columns c
    where object_id = (
      select top 1 object_id from sys.objects o
      where o.name like 'change[_]tracking%'
        and o.schema_id = schema_id('sys')
      )
    

    k_% 列因表而异,对应于跟踪表的主键。您正在查看每行 18 字节 +(主键长度)的基本最小开销。这加起来了!

    例如,我正在跟踪一些只有 15 字节宽的瘦基表,其中包含一个 7 字节的复合键。这使得跟踪表 18+7=25 字节宽!

    【讨论】:

    • 即使是 100 字节的行在一百万行之后也只能得到 100MB,所以我不认为你的示例 很重要,尽管我想这可能很多如果它是按表跟踪的。如果我错了,请纠正我。
    • @Sahuagin:在我的情况下,假设最多 10% 的表在两天内更新,我会为更改跟踪产生 0.1*(25/15) = 16.7% 的存储开销。不,这并不可怕——相比之下,任何指数都至少为 (7/15) = 46.7%。不过,无限期保留——这将花费 166%。另外,我不知道更改表是否使用数据压缩,但如果不使用,并且如果我的表压缩,那么百分比会变得更大。跨度>
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-07-01
    • 2011-01-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多