数据库文件过大,如何瘦身?

快乐鹦鹉 2009-07-03 01:04:46
用户系统已经使用了4年,由于其中有部分信息数据量比较大,因此将数据表进行分组,分别存储到不同的数据文件中。目前数据库文件已经达到40G,同时有个索引文件也达到了40G。搞不清楚为什么。
问一下:
1。如果我删除数据库中的部分数据,那么如何才能让数据库文件变小?我知道日志文件的清理办法,可数据文件还没有尝试过,谁能告知一下?
2。为什么索引数据量也会这么大?
...全文
958 33 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
33 条回复
切换为时间正序
请发表友善的回复…
发表回复
oec2003 2009-07-12
  • 打赏
  • 举报
回复
帮楼主顶
快乐鹦鹉 2009-07-12
  • 打赏
  • 举报
回复
继续顶!!!
lao_bulls 2009-07-12
  • 打赏
  • 举报
回复
只能这样【只有重建数据库,然后把数据再搬回来这一招了。可工作量确实是大】。别无他发。
快乐鹦鹉 2009-07-08
  • 打赏
  • 举报
回复
估计也是每人能够解决。可能很多人并没有碰到过这种现象。
对于数据库的常用的压缩和数据删除,我还是会的。所以大家不用贴一堆的文章过来。不过还是表示感谢。
现在的问题是,我删除了很多数据后,进行压缩,文件大小仍然没有变化。
也许有高手知道其中的奥秘,是否在我上面所述的某段时间由于某种故障造成文件急剧增大,而后这些增大的空间还无法管理,就像内存泄漏似的?
如果从文件压缩手段无法解决,那么只有重建数据库,然后把数据再搬回来这一招了。可工作量确实是大啊。。。。。。
能解我惑者,另加100分。
fuxiaoyang13 2009-07-04
  • 打赏
  • 举报
回复
收缩数据库,索引整理,如果可以 可以把一些数据备份出去!
ChinaJiaBing 2009-07-03
  • 打赏
  • 举报
回复
看看下面的




1、用BACKUP LOG database WITH NO_LOG清除日志
把数据库属性中的故障还原模型改为“简单”可以大大减慢日志增长的速度。
如果把还原模型调到简单,这样就不支持时间点还原了,但是日志文件会很小,如果数据比较重要推荐还是把数据库的还原模型调为完全
用BACKUP LOG database WITH NO_LOG命名后,会截断不活动日志,不减小物理日志文件的大小,但逻辑日志会减小,收缩数据库后会把不活动虚拟日志删除来释放空间,不会损坏数据。
如果日志被截断并收缩数据库后,就不能直接用最近的一个全库备份做时间点还原,建议立即备份数据库,以防万一。
2、sql server运行中,是否能删除主数据库事务日志文件
步骤如下:(1)、分离数据库企业管理器--数据库--右击你要删除日志的数据库--所有
任务--分离数据库
(2)、然后删除日志文件
(3)、然后再附加数据库
企业管理器--数据库--右击数据库--所有任务--附加数据库这时候只附加。mdf就可以了。
3、压缩SQL数据库及日志的详细方法
SQL Server 2000基础教程——压缩数据库数据库在使用一段时间后,时常会出现因数据删除而造成数据库中空闲空间太多的情况,这时就需要减少分配给数据库文件和事务日志文件的磁盘空间,以免浪费磁盘空间。当数据库中没有数据时,可以修改数据库文件属性直接改变其占用空间,但当数据库中有数据时,这样做会破坏数据库中的数据,因此需要使用压缩的方式来缩减数据库空间。可以在数据库属性选项中选择“Auto shrink”选项,让系统自动压缩数据库,也可以用人工的方法来压缩。人工压缩数据库有以下两种方式:
1、用Enterprise Manager 压缩数据库
在Enterprise Manager 中在所要压缩的数据库上单击右键,从快捷菜单中的“所有任务(All Tasks)”中选择“Shrink Database(压缩数据库)”选项,就会出现如图6-10 所示的对话框。可以在图6-10 所示的对话框中选择数据库的压缩方式,也可以选择使用压缩计划或压缩单个文件单击图6-10 中的“Files”按钮,会出现如图6-11 所示的压缩数据库文件对话框,可以针对每个数据库文件进行不同的压缩设置。

单击图6-10 中的“Change” 按钮,会出现如图6-12 所示的压缩计划编辑对话框,可以指定压缩计划的执行方式。单击图6-12 中的“Change” 按钮,会出现如图6-13 所示的循环工作计划编辑对话框,可以编辑计划执行的周期或时间点。设置完成后单击“OK” 按钮就开始压缩数据库,在压缩结束后会显示一个压缩情况信息框。


2、用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 选项就无效了。例6-14: 压缩数据库mytest 的未使用空间为数据库大小的20%

dbcc shrinkdatabase (mytest, 20)
运行结果如下:
DBCC execution completed. 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)


企业管理器里面的方法:
1、打开企业管理器
2、打开要处理的数据库
3、点击最上面菜单>工具>SQL查询分析器,打开SQL查询分析器
4、在输入窗口里面输入:
Code:
DUMP TRANSACTION [数据库名] WITH NO_LOG
BACKUP LOG [数据库名] WITH NO_LOG
DBCC SHRINKDATABASE([数据库名])

点击绿色的小三角(或按F5)执行查询,等状态栏提示处理完成
即可!

程序里面的方法:
压缩数据库日志
--1.清空日志
exec('DUMP TRANSACTION ['+@dbname+'] WITH NO_LOG')
--2.截断事务日志:
exec('BACKUP LOG ['+@dbname+'] WITH NO_LOG')
--3.收缩数据库文件(如果不压缩,数据库的文件不会减小
exec('DBCC SHRINKDATABASE(['+@dbname+'])')

  4、减小日志的方法:
一、用如下步做了:
1、DUMP TRANSACTION 庫名 WITH no_log
2、dbcc shrinkfile(logfilename)
3、收縮數據庫
4、設定自動收縮。
  二、分离数据库,删除日志文件,再附加,OK!右击数据库--所有任务--分离or 附加
  三、1、backup log 庫名 WITH no_log,2、dbcc shrinkfile(logfilename),3、收縮數據庫
4、設定自動收縮。
快乐鹦鹉 2009-07-03
  • 打赏
  • 举报
回复
要是远大于德话,我也就不着急了。不知道这和解决问题有什么关系?
快乐鹦鹉 2009-07-03
  • 打赏
  • 举报
回复
要是远大于德话,我也就不着急了。不知道这和解决问题有什么关系?
haitao 2009-07-03
  • 打赏
  • 举报
回复
硬盘的剩余空间远大于40G吧?
jinjazz 2009-07-03
  • 打赏
  • 举报
回复
[Quote=引用 22 楼 happyparrot 的回复:]
用收缩界面中的操作和DBCC SHRINKDATABASE有什么区别呢?
[/Quote]

一样的,他就是用DBCC SHRINKDATABASE,你可以在管理-活动监视器里面看到执行的脚本。

我是说sql版的那帮dba
快乐鹦鹉 2009-07-03
  • 打赏
  • 举报
回复
用收缩界面中的操作和DBCC SHRINKDATABASE有什么区别呢?
快乐鹦鹉 2009-07-03
  • 打赏
  • 举报
回复
哪来的DBA哦。公司里没有数据库好的。都只能解决些小毛小病。就像我这样的。
ws_hgo 2009-07-03
  • 打赏
  • 举报
回复
DBCC SHRINKDATABASE
jinjazz 2009-07-03
  • 打赏
  • 举报
回复
DBCC SHRINKDATABASE(数据库)

---
那帮dba都哪里去了
快乐鹦鹉 2009-07-03
  • 打赏
  • 举报
回复
对啊。问题就是这样子。即使删除了某些历史表,并进行压缩,数据文件大小也是没有变化。关键是为什么有那么一段时间突然增长了很多。现在即使把这几个文件涉及的表数据都清空,数据文件大小也下不来啊。
jinjazz 2009-07-03
  • 打赏
  • 举报
回复
[Quote=引用 16 楼 happyparrot 的回复:]
根据用户的记录,数据文件是在某一段时间快速增长,现在又一直比较稳定在这个大小。
[/Quote]

如果数据量稳定的话,那他肯定是设置百分比增长,比如40G的时候,会一次分配4G,然后这4G要用上一段时间所以又稳定大小了。


不管收缩数据库还是单个文件都无法改变大小吗
快乐鹦鹉 2009-07-03
  • 打赏
  • 举报
回复
根据用户的记录,数据文件是在某一段时间快速增长,现在又一直比较稳定在这个大小。
快乐鹦鹉 2009-07-03
  • 打赏
  • 举报
回复
现在的问题是,数据库数据量已经删的剩很少了,但文件大小却压缩不小来。咋办?
jinjazz 2009-07-03
  • 打赏
  • 举报
回复
数据库增长设置是什么?

如果增长量按照百分比的话,比如10%,你现在数据文件为20G,那么有2G可用空间是很正常的。

大P 2009-07-03
  • 打赏
  • 举报
回复
http://www.sqlservercentral.com/scripts/63782/
加载更多回复(12)
这个PDF文件是我花钱买来的,现在为了挣积分,拿出来与大家分享!! 本书深入浅出地介绍了目前世界上最受欢迎的数据库管理系统之一——SQL Server。全书共分三个部分:第一部分阐释了数据库的基本概念,讲解了数据库建模语言;第二部分展示了从概念建模到在SQL Server 2008上真正实现数据库的过程;第三部分深入探讨了SQL Server若干方面的技术细节,如数据保护、索引、并发访问等。通过将理论融入数据库实践,清晰地讲解了关系型数据库的设计原则,完整地展示了如何进行良好的关系型数据库设计,深入揭示了SQL Server 2008的技术细节。   本书浓缩了作者作为SQL Server数据库架构师多年来丰富的实践经验,适合各类数据库开发和管理人员学习参考 目录 第1章 数据库概念简介  1.1 数据库设计阶段   1.1.1 概念阶段   1.1.2 逻辑阶段   1.1.3 实现阶段   1.1.4 物理阶段  1.2 关系数据结构   1.2.1 数据库和模式   1.2.2 表、行和列   1.2.3 信息原则   1.2.4 域   1.2.5 元数据   1.2.6 键   1.2.7 未显式赋值的项(NULL)  1.3 实体之间的关系   1.3.1 二元关系   1.3.2 非二元关系  1.4 数据访问语言(SQL)  1.5 理解依赖性   1.5.1 函数依赖性   1.5.2 判定  1.6 总结 第2章 数据建模语言  2.1 数据建模介绍  2.2 实体  2.3 属性   2.3.1 主键   2.3.2 替代键   2.3.3 外键   2.3.4 域   2.3.5 命名  2.4 关系   2.4.1 识别性关系   2.4.2 非识别性关系   2.4.3 角色名字   2.4.4 关系基数   2.4.5 动词短语(关系名字)  2.5 描述信息  2.6 其他建模方法   2.6.1 信息工程   2.6.2 Chen ERD   2.6.3 Visio   2.6.4 Management Studio数据库关系图  2.7 最佳实践  2.8 总结 第3章 概念阶段数据建模  3.1 理解需求  3.2 文档化过程  3.3 需求收集   3.3.1 客户访谈   3.3.2 要回答的问题   3.3.3 现存的系统和原型   3.3.4 其他类型的文档  3.4 识别对象和过程   3.4.1 识别实体   3.4.2 实体间关系   3.4.3 识别属性和域  3.5 识别业务规则和业务过程   3.5.1 识别业务规则   3.5.2 识别基础业务过程  3.6 完成概念模型   3.6.1 识别明显的、额外的数据需求   3.6.2 和客户一起评审   3.6.3 重复以上步骤直到客户同意你的模型  3.7 最佳实践  3.8 总结 第4章 规范化过程  4.1 为什么要规范化   4.1.1 消灭重复数据   4.1.2 避免编写不必要的代码   4.1.3 给表瘦身   4.1.4 最大化聚集索引的使用   4.1.5 降低每张表中索引的数量  4.2 规范化应该走多远  4.3 规范化过程  4.4 实体和属性的形式:第一范式   4.4.1 所有属性必须是原子的   4.4.2 实体的所有实例必须包含相同数量的值   4.4.3 实体中出现的所有实体类型都必须不同   4.4.4 第一范式所避免的不规则编程   4.4.5 当前设计不符合第一范式的线索  4.5 属性间的关系   4.5.1 第二范式   4.5.2 第三范式   4.5.3 Boyce-Codd范式  4.6 实体中的多值依赖   4.6.1 第四范式   4.6.2 第五范式  4.7 非规范化  4.8 最佳实践  4.9 总结  4.10 额外的例子  4.11 本书迄今为止所讲述的故事 第5章 实现基础的表结构  5.1 评审逻辑设计  5.2 变换设计   5.2.1 选择名字   5.2.2 处理子类型   5.2.3 决定树的实现方式   5.2.4 选择键的实现方式   5.2.5 决定域的实现方式   5.2.6 设置模式   5.2.7 评审“最终的”实现模型  5.3 实现设计   5.3.1 创建基本表结构   5.3.2 添加唯一性约束   5.3.3 构建默认约束   5.3.4 添加关系(外键)   5.3.5 处理排序规则和排序   5.3.6 计算列   5.3.7 实现用户定义的数据类型   5.3.8 文档化你的数据库   5.3.9 处理依赖信息  5.4 最佳实践  5.5 总结 第6章 保护数据的完整性  6.1 最佳实

22,301

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧