今天5.1，在家里没什么事情，边看优化MSSQL数据库的书，边做实验，在MSSQL的TEST1数据库内创建了三个表，很简单，
test1(bb varchar(100)),
test2(bb varchar(100)),
test3(bb varchar(100)),
我边通过insert into test1..test1 select * from test1..test1。。。三个语句往三个表里插入数据，边通过windows性能监视器观察计数器的变化，结果不知不觉的三个表里的记录已经达到了2000W的级别，系统提示C驱空间紧张，结果一看，哇塞！只剩下了10几兆了，打开企业管理一看，test1数据库数据文件近800M，日志文件更吓人，达到了惊人的6G啊，原来我的TEST1数据库不知道啥时候置成了完全恢复模式了，我的天啊，我的系统盘本身空间就紧张，没办法只能想办法删除或收缩，开始打算直接删除算了，但又有点不甘心，嫌麻烦，直接删除算了，结果还删除失败，不知道为什么，也没仔细研究，反正不打算直接删除，想通过这件事来总结一下收缩的方法，查联机文档，确定了思路，开始操作，结果在试验过程中，还是漏洞百出啊，最后还是通过了，贴一下：
use master
go
backup log test1 with no_log
use test1
go
truncate table test1
truncate table test2
truncate table test3
use master
go
dbcc shrinkdatabase (test1,10)
go
这里值得注意的是，上面TRUNCATE TABLE ...语句，本来是没考虑就用了DELETE FROM TEST1..TEST1...，结果由于DELETE删除大表需要极大的LOG，因此我在删除的时候，我看到LOG在长，由开始的90M长到了近1G，最后没办法，终止，改成了TRUNCATE，由此看来，删除大表的数据时，还是TRUNCATE好使啊，几秒钟搞定，真爽！！！

ITPub博客

mssql一次数据库收缩经历

最新文章