标签: compression

我的数据库很大，最近我注意到几个月前添加的新表是罪魁祸首。

这是表脚本。

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Entry_tracker](
    [S.Number] [int] IDENTITY(1,1) NOT NULL,
    [EntryId] [varchar](50) NOT NULL,
    [EventNumber] [varchar](18) NOT NULL,
    [Data] [varbinary](max) NOT NULL,
    [TrackDateTime] [datetime] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

ALTER TABLE [dbo].[Entry_tracker] ADD  CONSTRAINT [DF_Entry_tracker_TrackDateTime]  DEFAULT (getdate()) FOR [TrackDateTime]
GO

我收集了这张表的信息，了解到该表大约有1600万行，表大小为1.4TB。

尽管如此，我认为桌子的大小对于没有。的记录。

应用程序不查询该表。它只是存储来自另一个表的相同条目的不同版本。

我检查了碎片信息，它显示平均碎片为 0，平均空间使用率为 93%。

由于我使用的是 SQL Server 2016，我虽然可以使用表压缩，因此尝试sp_estimate_data_compression_savings估计可能的空间节省。但是，结果显示没有节省。

size_with_current_compression_setting(KB) 等于 size_with_requested_compression_setting(KB)

任何人都可以指导我找到这张表的问题吗？

这非常重要，因为这会占用大量磁盘空间。

感谢你的帮助。

我正在创建一系列将启用页面级压缩的新表。

这是否也会影响索引，还是在创建索引时我还必须指定压缩？

create table Message
(
  pk_Message   int identity  NOT NULL constraint PK_Message primary key,
  [Message]    varchar(900)  NOT NULL constraint UK_Message__Message unique,
  DateCreated  datetime      NOT NULL default getdate()
) with (data_compression = page)
go  

正如您在我的示例中看到的那样，我计划对相当大的数据类型创建唯一约束，并希望利用压缩。

如果我们对数据库备份启用压缩（因为数据库备份大小很大）但不在大小相对较小的差异上启用它，还原是否有效？因为完整备份已压缩，但差异未压缩。

将已经data compression启用减少存储在内存中的OLTP表使用的金额是多少？

如果是，我认为 CPU 工作负载会增加。

有没有办法为列存储和列存储列存储归档压缩节省压缩？

为了检查这些压缩保存，我必须删除所有聚集和非聚集索引，然后创建一个聚集列存储索引 - 大多数时候这是一个耗时的操作，我想知道是否有其他方法可以做到这一点。

SQL 2012 Enterprise DB 中有一个现有表，它的大小约为 120MB，包含约 2000 条记录。其最大的字段nvarchar(max)包含海绵状 XML（范围从 20 到 300 kB），其本身在 7Zip 或 RAR 中大约压缩 50-75%。

我尝试了以下立即返回的命令，即使简单地从表中查询 * 需要花费几秒钟：

alter table sch.table1 REBUILD PARTITION=ALL WITH (DATA_COMPRESSION=ROW)
alter table sch.table1 REBUILD PARTITION=ALL WITH (DATA_COMPRESSION=PAGE)
alter table sch.table1 REBUILD PARTITION=ALL WITH (DATA_COMPRESSION=NONE)

但是在它们中的任何一个之后大小都不会改变，即使表的属性正确显示了压缩类型。

服务器实际上是否对行/页应用和删除压缩？它似乎没有时间在瞬间完成每个命令的执行。

使用 Java 和 JDBC，我将字符串存储到 Postgres 中的 JSONB 列中。插入时效果很好。

检索值时，Java 内存不足，因为我检索的数据量较大，并且每个 json/字符串大约为 1MB。我想做的是编写这样的查询：

SELECT compress( myJsonColumn ) FROM myTable WHERE ...

我在 Postgres 中查找了一些压缩方法，但没有找到。任何指示将不胜感激。谢谢。

澄清：澄清一下，我不想压缩数据库中的数据。我认为 Postgres 会优雅地处理这个问题，我主要关心的是 java-heap-space。

我的架构中有三个组件。

1. 需要未压缩的 json 的客户端（并且将自行处理解压缩）
2. 为多个客户端提供服务的服务。我正在努力保护服务的内存。该服务永远不需要查看未压缩的 json。
3. 数据库。我想将 json 存储在 jsonb 字段中，而不是以二进制形式存储，以便我可以在需要时针对数据编写新的查询。

有谁知道像这个页面https://columnscore.com/这样的工具，可以在其中确定一个表是否适合行或页压缩。

我也试图了解压缩的好处。我一直在阅读它，但仍然有这些问题。

1. 压缩会使缓冲区缓存中容纳更多 8KB 吗？数据何时变得未压缩，即在选择中？
2. 备份会变得更快吗？
3. 压缩广告cpu开销的原因是因为例如插入需要在插入之前被压缩吗？
4. 是否有充分的理由在不调查表的使用方式（即静态与易失性）的情况下压缩表。

一个同事开始压缩很多表（页）。我不知道这个决定背后的分析。我知道我们有时会在某些高峰时段等待资源信号量。我实际上不认为他知道他在做什么。我可以看到我们的 sos 调度程序收益等待略有增加。

我认为压缩会造成更大的伤害，现在维护任务似乎更多（例如备份、checkdb ......）。

我有一个完整备份近 2GB 的数据库。当我执行完整备份（不压缩），然后用 winrar 压缩它时，它变成 140MB，但是当我备份WITH COMPRESSION语法时，结果是 315MB，不幸的是，用 winrar 压缩后，大小没有改变。如何使用 T-SQL 进行最大级别的完全压缩？

v8.4 和 v9.2（是的，我知道它们过时且不受支持，但我对此无能为力。）

我管理（但未设计）的数据库中的某些表在 CHARACTER VARYING(256) 字段上具有 btree 索引。即使字段值不全为空，其中的数据长度也不超过 12 个字符。

是的，这些列的物理表存储是高度压缩的，但是 btree 索引呢？如果将列更改为 VARCHAR(12)，索引会更有效吗？

谢谢