标签: compression

如果在发布者为 SQL 2008 Enterprise（支持数据压缩）且订阅者为 SQL 2008 Standard（不支持数据压缩）的复制表（合并复制）上启用数据压缩（行级或页级），会发生什么情况. 压缩属性会被礼貌地删除而订阅者继续愉快地未压缩还是会导致复制出错并停止？

当系统不受 CPU 限制并且 95% 的响应看到响应时间减少时，我试图找出导致某些响应时间增加的原因，当数据通过页面压缩进行压缩时。

因此，我所做的是将其追踪到系统中发生的单个进程，并对该进程进行概要分析以确定在此过程中触发了哪些 SP 和 UFN。我最初的想法是我可以单独运行每个 SP 和 UFN 并查看查询计划以查看发生完整扫描的位置，这可能需要从压缩中解压缩数据并可能导致等待触发。

所以我现在拥有的是：

• 使用参数的 SP 列表
• 运行 SP 的数据库
• 不受限制的管理员访问系统以重现问题
• 相关进程的配置文件跟踪

由于我必须对 35 个 SP/UFN 之类的东西进行分类，因此我想知道缩小原因的最有效方法是什么。根据我对系统的经验，我可以推断出某些 SP 比其他 SP 更有可能是罪魁祸首，但我想尝试以更科学的方式缩小范围。是否有任何工具或方法可以帮助我找出最有可能的罪犯？

如果我可以确定压缩时比不压缩时慢的对象，这将有助于我们了解页面压缩的策略。

我创建了一个表，其中有大约 100 个分区（每月），所有分区都配置为使用页面压缩。之后，我将逐月向该表中插入数据。

我现在希望 SQL Server 应用页面压缩。但是使用sp_estimate_data_compression_savings它看起来不像。（我会节省大约 40%-50%。）

我在配置页面压缩时错过了什么吗？

问题是我现在有大文件，每个分区 70-80 GB。当我压缩它们时，它们是半空的。重新获得这个磁盘空间是不可能的，因为如果我试图缩小分区后面的数据文件，我最终会得到一个碎片化的聚集索引。

我怎样才能避免这种磁盘空间浪费派对？

我有一张包含 100 万条记录的表格。每次针对每种类型的事件（有很多）发生事件时，每天都会创建和更新新记录。我经常需要在许多记录中找到总和，并且执行这些查询的时间逐渐变慢，即使在某些地方有多个索引。由于现在存储了几年的数据，我正在考虑将超过 6 个月的记录迁移到单独的“存档”表，并为每个事件类型创建新记录，其中包括每月聚合（即行的总和）在 2014 年 1 月存储的 31 条记录中，将存储在 1 条记录中）。这有望提高搜索速度，但有更好的策略吗？这种归档方式常见吗？

我需要想出最好的方法来在大小为 1500 GB 的表上启用页面压缩，有 363,957,740 行。数据库大小本身为 1.71 TB，并保存存档数据。

如果我理解正确，它需要磁盘空间（可能是相同的数量，只是为了更安全），以便它可以创建启用页面压缩的表副本并释放空间。这是在FULL恢复模型中，因此将被大量记录。

我已与我的容量规划资源进行了交谈，他同意为此维护提供额外的临时所需空间，并在此活动完成后收回空间。说了这么多，你认为最好的方法是：

1. 进行完整备份
2. 将备份还原到新的临时驱动器上
3. 将恢复模式更改为 SIMPLE
4. 启用页面压缩
5. 压缩后进行完整备份并恢复原始数据库
6. 将恢复模型更改为 FULL

此外，而不是启用页面压缩。Step #3 之后，截断最大的表，启用页面压缩，然后执行

SELECT * INTO ReplicaDB.dbo.ReplicaTbl

这是否在现有索引上启用页面压缩？

我没有测试环境来测试上述步骤。或者，如果有更好的方法可用，请告诉我。

目标是最大限度地减少当前增长所需的未来磁盘空间。我们是一家 ERP 软件公司，我们拥有企业版许可。该表仅用于在执行某些检查并且所有数据都驻留在该表中时存档。我有 2 个索引（1 个 CI，1 个非 CI）。没有任何列是VARCHAR (MAX)，它们要么是NVARCHAR，int要么是date类型。

我想知道 SQL Server 是否支持对整个表的一种字典压缩，而不仅仅是一个页面。

我正在开发的系统最初并不是为它今天处理的大量数据而创建的。我目前遇到的问题如下：

该应用程序允许用户创建法律合同。这些合同是标准化的，但允许用户根据需要调整合同的内容（文本）。

为方便起见，每份合同都会制作一份标准化合同文本的副本。实际上，我们发现用户几乎从不编辑合同文本，因此我们最终得到了一个包含大量重复数据的表格。

通常我会更改数据库模型以适应用例，但这是一个遗留系统，这样的更改非常昂贵。正在研究它的替代品，所以像这样的投资并不容易。

是否可以对整个表进行列字典压缩，而不仅仅是 1 页？

我们在内部部署的 SQL 集群中使用 SQL Server 2012。

问题是表大小为 80GB，整个 DB 大小为 180GB。这个表占用了很多空间，我们没有足够的内存，所以 SQL Server 不断卸载数据。

该表的数据用于生成代表合同的 PDF。每次用户修改合同状态时，都会生成一个新的 PDF 并存储用于审计目的，这会在此表上生成大量读取。

读取到磁盘（因为 SQL 服务器不断从内存中卸载表）。这给我们的 SAN 造成了巨大的 IO 压力。

正在解决内存问题，但这需要几周时间。现在可以说，简单地插入更多内存目前不是一种选择。

我的想法是：对于短期解决方案 - 压缩数据，这将大大减少表的大小，从而使 SQL Server 可以将表保存在内存中，从而减轻我们对 SAN 的 IO 压力。

由于客户端应用程序将 PDF 文件存储为 varbinary，我有一个现有的旧表，大小约为 180GB。我希望能够在创建新解决方案时使用 GZIP 压缩所有行的该列以帮助节省空间（我希望有一种方法可以在 SQL 中执行此操作，而不必为此编写客户端代码）。我看到该COMPRESS方法可用于 Sql Server 2016，但我需要一个适用于 2008 的解决方案。任何想法将不胜感激。

我似乎找不到设置服务器属性的选项，该选项将使 SQL 数据库备份的压缩默认为 ON，因此我不必每次都手动设置它。

任何人都可以指出我。

压缩和收缩 SQL Server 中的数据库是否相同？如果我压缩一个表，它会降低查询性能和 DML 吗？

运行所有这些命令的登录名是sysadminSQL 2012 Developer 实例上服务器角色的成员。它是部署到的数据库的所有者。EXTERNAL ACCESS ASSEMBLY已授予此 DB 中的登录权限。还尝试了以下所有内容作为sa登录无济于事。

alter database test set trustworthy on
go
create assembly [icsharpcode.sharpziplib]
from 'C:\Workspace\111\icsharpcode-SharpZipLib-4f2d664\bin\Release\ICSharpCode.SharpZipLib.dll'
with permission_set = UNSAFE --< This works!
go
create assembly OutOfRowCompression
from 'C:\Workspace\Sandbox\OutOfRowCompression\OutOfRowCompression\bin\Debug\OutOfRowCompression.dll'
with permission_set = UNSAFE --< This fails!
go

最后一个命令失败：

消息 10327，级别 14，状态 1，第 1 行 CREATE ASSEMBLY 为程序集“OutOfRowCompression”失败，因为程序集“OutOfRowCompression”未被授权用于 PERMISSION_SET = UNSAFE。当以下任一情况为真时，程序集被授权：数据库所有者 (DBO) 具有 UNSAFE ASSEMBLY 权限并且数据库具有 TRUSTWORTHY 数据库属性；或者程序集使用证书或非对称密钥签名，该密钥具有具有不安全程序集权限的相应登录名。

收到错误后，我使用新的非对称密钥对程序集进行了签名key1.pfx，并将其添加到主数据库中：

CREATE ASYMMETRIC KEY key1
FROM executable
FILE = 'C:\Workspace\Sandbox\OutOfRowCompression\OutOfRowCompression\bin\Debug\OutOfRowCompression.dll'

验证密钥是否存在： …