标签: compression

我希望在空间索引上打开页面压缩。实例为2008 Enterprise。该索引预先存在于供应商提供的应用程序中。在搜索 BOL 时，它指出压缩和填充因子都是允许的。

ALTER INDEX [ix_city_citypoint] on city 
REBUILD WITH (FILLFACTOR = 90, DATA_COMPRESSION = PAGE) 

消息 153，级别 15，状态 4，第 12 行
ALTER INDEX REBUILD 语句中选项 data_compression 的使用无效。

原创：

CREATE SPATIAL INDEX [ix_city_citypoint] ON [dbo].[city]
(
    [citypoint]
)USING  GEOGRAPHY_GRID 
WITH (GRIDS =(LEVEL_1 = MEDIUM,LEVEL_2 = MEDIUM,LEVEL_3 = MEDIUM,LEVEL_4 = MEDIUM), 
CELLS_PER_OBJECT = 16, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF
    , SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF
    , ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [primary]
GO …

我正在尝试在 Docker 容器中的 MariaDB 10.4.11-MariaDB-1:10.4.11+maria~bionic 上安装 Nextcloud (mariadb:latest sha256:2f11cf2ec18988aec8346a5cf528d69ac3f0f4fc02af79ba28f4fd47b7778d6f)。

安装程序所做的第一件事是尝试ROW_FORMAT=COMPRESSED在 DDL 中创建一个表，这会产生错误 140“错误的创建选项”。

如果我省略 row_format 参数，则会创建表，但使用 DYNAMIC row_format。

这里发生了什么？是否ROW_FORMAT=COMPRESSED在某个时候被删除了，或者正在拉取的 MariaDB docker 版本是否未使用它进行编译？

如果不修改 Nextcloud 的 SQL DDL，我能在这里做什么？

Edit:

最后可以添加有关我的系统的更多信息，如下：

首先是我的my.cnf

[mysqld]
innodb_large_prefix=on
innodb_file_per_table=on
innodb_doublewrite=off
innodb_page_size=64k
innodb_file_format=barracuda

innodb_compression_algorithm=lz4
innodb_compression_default=ON

这会导致启动包含以下行：

2020-01-11 07:10:48+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.4.11+maria~bionic started.
2020-01-11 07:10:57+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2020-01-11 07:10:58+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.4.11+maria~bionic started.
2020-01-11  7:10:58 0 [Note] mysqld (mysqld …

我已经阅读了很长时间，当数据库启用了 TDE 时，压缩备份似乎并不安全。

是否有人在使用 tde 数据库的压缩备份还原期间遇到错误？

我从未经历过此类错误，但我真的很担心。

似乎问题出在 SQL SERVER 2016 上，因为我使用的是 2012，所以我看不到任何问题。

此外，即使使用MAXTRANSFERSIZE = 131072备份也不压缩。会是什么呢？我正在使用NO CHECKSUM和WITH CHECKSUM两者的尺寸相同。

我试图查看我的所有备份是否已压缩。我运行下面的查询来检查但没有得到好的结果：

select top(10) database_name, 
case when  backup_size = compressed_backup_size then 'Compressed'
else 'Not compressed'
end as Compression, 
backup_finish_date
from msdb.dbo.backupset
where database_name ='MyDAtabase'
order by backup_start_date desc

我在用：

Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64)
2012 年 6 月 28 日 08:36:30 版权所有 (c)
Windows NT 6.1（内部版本 7601：Service Pack 1）上的Microsoft Corporation标准版（64 位）

默认情况下，我们设置了压缩，但是一旦我运行该查询，我得到的结果数据库没有被压缩。

当我右键单击 SSMS 并选择编写创建索引的脚本时：

我得到这个脚本，没有 data_compression：

USE [APCore]
GO

/****** Object:  Index [i_agencyId]    Script Date: 07/11/2019 12:18:13 ******/
CREATE UNIQUE NONCLUSTERED INDEX [i_agencyId] ON [agy].[agency]
(
    [agencyId] ASC
)
INCLUDE (   [countryCode]) WITH (PAD_INDEX = OFF, 
STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, 
DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, 
ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 100) ON [NONCLUSTERED_INDEXES]
GO

但是，当使用下面的查询专门检查数据压缩时

use APCore
go

SELECT i.name, p.data_compression_desc 
 FROM sys.partitions P
 INNER JOIN sys.indexes I ON I.object_id = …

确定行或页或列存储压缩（或无）对于用于 OLTP（其中不支持sp_estimate_data_compression_ savings）的 Azure SQL 数据库（标准层或高级层）中的每个索引最有效的最有效方法是什么？

我意识到这样做是否有利于性能取决于每个索引的写入频率和数量。还应考虑哪些其他因素？

（我意识到是否对分区索引使用列存储是一个复杂的问题，我认为这超出了此请求的范围。）

我们正在尝试从其他人的 MS SQL 数据库导入（逆向工程）一些数据，而无需任何供应商支持。

过去，数据以纯文本或 RTF 格式存储，因此易于提取。但这个数据库有一些看起来“加密”的内容。如果数据采用这种格式，则另一列“zipped” = 1。我被告知他们正在压缩数据以使其低于 SQL Express 的 10GB 限制。

它看起来有点像这样：

-\xc3\x8bj\xe2\x80\x9e@D\xc3\xb7\n\xc3\xbeC}\xe2\x82\xac7!2\xe2\x80\xb9<P\xc3\x89\xc2\xbe\xc3\xad\xc2\xbe\xc3\xaa\xc3\x8d\xc3\xb4Cn\xc2\xb7\xc3\xbf~\xc2\xa66U\xc3\x85\xc2\xa9\xe2\x80\x93F\n

关于如何解码它有什么想法吗？同一个表中还有其他行是纯文本或 RTF，但很多都是这种格式。

这是数据库导出的示例：

https://1drv.ms/u/s!Au6oldAhXo2M5Xt_bE9Q5iA0WdfF?e=IsuYdQ

其中包括它应该是什么样子的屏幕截图。