怎样压缩MSSQL数据库

分类: 电脑/网络 >>程序设计 >>其他编程语言

问题描述:

怎样压缩MSSQL数据库,我的数据库文件显示占用空间120M,可用空间105M,其实正直有用的也只有几十M,怎样压缩呢?请哪位朋友提供解决方法!

解析:

数据库在使用一段时间后，时常会出现因数据删除而造成数据库中空闲空间太多的情况，这时就需要减少分配给数据库文件和事务日志文件的磁盘空间，以免浪费磁盘空间。当数据库中没有数据时，可以修改数据库文件属性直接改变其占用空间，但当数据库中有数据时，这样做会破坏数据库中的数据，因此需要使用压缩的方式来缩减数据库空间。可以在数据库属性选项中选择“Auto shrink”选项，让系统自动压缩数据库，也可以用人工的方法来压缩。人工压缩数据库有以下两种方式：

1、用Enterprise Manager 压缩数据库

在Enterprise Manager 中在所要压缩的数据库上单击右键，从快捷菜单中的“所有任务（All Tasks）”中选择“Shrink Database（压缩数据库）”选项

、用Transact-SQL 命令压缩数据库

可以使用DBCC SHRINKDATABASE 和DBCC SHRINKFILE 命令来压缩数据库。其中DBCC SHRINKDATABASE 命令对数据库进行压缩，DBCC SHRINKFILE 命令对数据库中指定的文件进行压缩。

（1） DBCC SHRINKDATABASE

DBCC SHRINKDATABASE 命令语法如下：

DBCC SHRINKDATABASE (database_name [, target_percent]

[, {NOTRUNCATE | TRUNCATEONLY}] )

各参数说明如下：

target_percent 指定将数据库压缩后，未使用的空间占数据库大小的百分之几。如果指定的百分比过大，超过了压缩前未使用空间所占的比例，则数据库不会被压缩。并且压缩后的数据库不能比数据库初始设定的容量小。

NOTRUECATE

将数据库缩减后剩余的空间保留在数据库，中不返还给 *** 作系统。如果不选择此选项，则剩余的空间返还给 *** 作系统。

TRUNCATEONLY

将数据库缩减后剩余的空间返还给 *** 作系统。使用此命令时SQL Server 将文件缩减到最后一个文件分配，区域但不移动任何数据文件。选择此项后，target_percent 选项就无效了。

压缩数据库mytest 的未使用空间为数据库大小的20%。

dbcc shrinkdatabase (mytest, 20)

运行结果如下：

DBCC execution pleted. If DBCC printed error messages, contact your system administrator.

(2) DBCC SHRINKFILE

DBCC SHRINKFILE 命令压缩当前数据库中的文件。其语法如下：

DBCC SHRINKFILE ( {file_name | file_id }

{ [, target_size] |

[, {EMPTYFILE | NOTRUNCATE | TRUNCATEONLY}] } )

各参数说明如下：

file_id

指定要压缩的文件的鉴别号（Identification number， 即ID）。文件的ID 号可以通过 FILE_ID（）函数或如本章前面所讲述的Sp_helpdb 系统存储过程来得到。

target_size

指定文件压缩后的大小。以MB 为单位。如果不指定此选项，SQL Server 就会尽最大可能地缩减文件。

EMPTYFILE

指明此文件不再使用，将移动所有在此文件中的数据到同一文件组中的其它文件中去。执行带此参数的命令后，此文件就可以用ALTER DATABASE 命令来删除了。

其余参数NOTRUNCATE 和TRUNCATEONLY 与DBCC SHRINKDATABASE 命令中的含义相同。

例6-15: 压缩数据库mydb 中的数据库文件mydb_data2 的大小到1MB。 use mydb dbcc shrinkfile (mydb_data2, 1)

具体方法有3种。

方法一:

第一步：

backup

log

database_name

with

no_log

或者

backup

log

database_name

with

truncate_only

--

no_log和truncate_only是在这里是同义的，随便执行哪一句都可以。

第二步：

1.收缩特定数据库的所有数据和日志文件，执行：

dbcc

shrinkdatabase

(database_name,[,target_percent])

--

database_name是要收缩的数据库名称；target_percent是数据库收缩后的数据库文件中所要的剩余可用空间百分比。

2.收缩一次一个特定数据库中的数据或日志文件，执行

dbcc

shrinkfile(file_id,[,target_size])

--

file_id是要收缩的文件的标识

(id)

号,若要获得文件

id，请使用

file_id

函数或在当前数据库中搜索

sysfiles；target_size是用兆字节表示的所要的文件大小（用整数表示）。如果没有指定，dbcc

shrinkfile

将文件大小减少到默认文件大小。两个dbcc都可以带上参数notruncate或truncateonly，具体意思查看联机帮助.

方法二：

第一步：

先备份整个数据库以备不测

。

第二步：

备份结束后，在query

analyzer中执行如下的语句：

exec

sp_detach_db

yourdbname,true

--卸除这个db在mssql中的注册信息

第三步：

到日志的物理文件所在的目录中去删除该日志文件或者将该日志文件移出该目录

第四步：

在query

analyzer中执行如下的语句：

exec

sp_attach_single_file_db

yourdbname,'

d:\mssql\data\yourdbname_data.mdf

'

--以单文件的方式注册该db，如果成功则mssql将自动为这个db生成一个500k的日志文件。

方法三:

1.

进入企业管理器，选中数据库，比如demo

2.

所有任务->分离数据库

3.

到数据库文件的存放目录，将muonline_log.ldf文件删除，以防万一，你可以拷出去

4.

企业管理器->附加数据库，选muonline，这个时候你会看见日志文件这项是一个叉，不要紧，继续，此时数据库就会提示你该数据库无日志是否创建一个新的，确定就是了。

5.

记得数据库重新附加后用户要重新设置一下。

如果以后,不想要它变大:

sql2000下使用：

在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。

或用sql语句：

alter

database

数据库名

set

recovery

simple

压缩表从名字上来看，简单理解为压缩后的表，也就是把原始表根据一定的压缩算法按照一定的压缩比率压缩后生成的表。

1.1 压缩能力强的产品

表压缩后从磁盘占用上看要比原始表要小很多。如果你熟悉列式数据库，那对这个概念一定不陌生。比如，基于 PostgreSQL 的列式数据库 Greenplum；早期基于 MySQL 的列式数据库 inforbright；或者 Percona 的产品 tokudb 等，都是有压缩能力非常强的数据库产品。

1.2 为什么要用压缩表？

情景一：磁盘大小为 1T，不算其他的空间占用，只能存放 10 张 100G 大小的表。如果这些表以一定的比率压缩后，比如每张表从 100G 压缩到 10G，那同样的磁盘可以存放 100 张表，表的容量是原来的 10 倍。情景二：默认 MySQL 页大小 16K，而 OS 文件系统一般块大小为 4K，所以在 MySQL 在刷脏页的过程中，有一定的概率出现页没写全而导致数据坏掉的情形。比如 16K 的页写了 12K，剩下 4K 没写成功，导致 MySQL 页数据损坏。这个时候就算通过 Redo Log 也恢复不了，因为几乎有所有的关系数据库采用的 Redo Log 都记录了数据页的偏移量，此时就算通过 Redo Log 恢复后，数据也是错误的。所以 MySQL 在刷脏数据之前，会把这部分数据先写入共享表空间里的 DOUBLE WRITE BUFFER 区域来避免这种异常。此时如果 MySQL 采用压缩表，并且每张表页大小和磁盘块大小一致，比如也是 4K，那 DOUBLE WRITE BUFFER 就可以不需要，这部分开销就可以规避掉了。查看文件系统的块大小：

root@ytt-pc:/home/ytt#  tune2fs -l /dev/mapper/ytt--pc--vg-root  | grep -i 'block size'Block size:               4096

1.3 压缩表的优势

压缩表的优点非常明显，占用磁盘空间小！由于占用空间小，从磁盘置换到内存以及之后经过网络传输都非常节省资源。

简单来讲：节省磁盘 IO，减少网络 IO。

1.4 压缩表的缺陷

当然压缩表也有缺点，压缩表的写入（INSERT,UPDATE,DELETE）比普通表要消耗更多的 CPU 资源。

压缩表的写入涉及到解压数据，更新数据，再压缩数据，比普通表多了解压和再压缩两个步骤，压缩和解压缩需要消耗一定的 CPU 资源。所以需要选择一个比较优化的压缩算法。

1.5 MySQL 支持的压缩算法

这块是 MySQL 所有涉及到压缩的基础，不仅仅用于压缩表，也用于其它地方。比如客户端请求到 MySQL 服务端的数据压缩；主从之间的压缩传输；利用克隆插件来复制数据库 *** 作的压缩传输等等。

从下面结果可以看到 MySQL 支持的压缩算法为 zlib 和 zstd，MySQL 默认压缩算法为 zlib，当然你也可以选择非 zlib 算法，比如 zstd。至于哪种压缩算法最优，暂时没办法简单量化，依赖表中的数据分布或者业务请求。

---