数据库太大的通常解决办法2010-04-28 10:00 前段时间碰到有朋友的数据库达到8G多,导致系统总是出现假死机的现象,因为朋友对这方面的知识不是很专业,导致误以为是硬件故障,盲目的更新硬件升级服务器,结果即浪费了精力又浪费了金钱。遇到这种情况应该先逐步分析:如果并非因为数据量巨大而导致数据库达到8G大小,应当先考虑收缩数据库。如果是因为数据量巨大以及应用原因导致数据库系统出现隐患,应在性能监视器里监控数据库运行时的CPU、内存、磁盘I/O状况,寻找出性能瓶颈的所在,有针对的进行程序代码的优化、数据库系统的优化以及硬件设备的升级。 下面收集了一些专业朋友的意见。仅供参考:
一·生成脚本重新建立数据库:
--参考这个:
--迁移数据库
1.生成数据库脚本
sql200企业管理器
--右键要迁移的数据库
--所有任务
--生成SQL脚本
--常规里选择生成全部对象脚本
--设置格式里,将"包含扩展属性"选上
--选项中,将"编写数据库脚本"及"表脚本选项"中的内容全部选择上
--其他所有的选项保持默认值
--然后确定,将其保存成一个.sql文件
2.在目标服务器上创建一个新的数据库
用查询分析器连接到目标服务器,创建一个新的数据库:
create database 数据库名
go
use 数据库名
go
然后打开并执行第1步中生成的脚本.创建一个数据库结构
3.导入数据到目标服务器
sql200企业管理器
--右键要迁移的数据库
--所有任务
--导出数据
--目标数据库,服务器选择目标服务器名,数据库选择上面生成的数据库
--然后选择"在两个SQL数据库之间复制数据和对象"
--将"创建目的对象"的选择取消
--最后完成.
另外注意:1.backup,再RESTORE,这样不会少东西
2.生成脚本的时候,一定要把"包含扩展属性"选上,否则没有索引之类的
二· 若是日志太大,可以:
方法一此方法适用于7.0和2000。
1、在查询分析器中执行: exec sp_detach_db 'DB_Name','true'
2、在我的电脑中将日志的物理文件xxx_Log.LDF改名。
3、在查询分析器中执行: exec sp_attach_single_file_db 'DB_Name','C:/Program Files/Microsoft SQL Server/MSSQL/Data/DB_Name.MDF'
4、如果上一步成功,将步骤2中改名后的文件删除。如果上一步不成功,改回原来的文件名,用sp_attach_db将数据库附加到服务器,然后用方法二。
方法二
6.X中 DUMP TRANSACTION test2 with NO_LOG
DUMP TRANSACTION test2 with TRUNCATE_ONLY 将上面的语句多次执行,直到日志缩小。
7.0和2000中 backup log test2 with NO_LOG
backup log test2 with TRUNCATE_ONLY
DBCC SHRINKDATABASE(test2) 将上面的语句多次执行,直到日志文件缩小。
上面的方法治标不治本,标本兼治要用下面的方法。
方法三:
--6.X和7.0中改为日志处于截断模式,2000中恢复模型改为简单恢复
exec sp_dboption 'test2','trunc. log on chkpt.','on'
--7.0和2000中设为自动收缩,6.x中不用执行。
exec sp_dboption 'test2','autoshrink','on' 通常用于测试环境。
方法四: --7.0中改为日志不处于截断模式,2000中恢复模型改为完全恢复
exec sp_dboption 'test2','trunc. log on chkpt.','off'
--7.0和2000中设为自动收缩,6.x中不用执行。
exec sp_dboption 'test2','autoshrink','on' 建立作业,每半个小时一次日志备份,每天一次完全数据库备份。 7.0和2000中:在Log收缩到正常大小后,将autoshrink选项设置为off。通常用于真实环境。 在产品化系统中将autoshrink选项设置为开启状态并非明智之举(除非您真的需要这样做),这是因为,当您的系统正在忙于完成其它任务时,autoshrink选项可能会同时启动,从而降低系统运行速度。然而,对于那些数据库管理员无暇估计并且数据库尺寸有可能在您毫无察觉的情况下超出控制范围的桌面或远程系统来说,开启这一选项却是一种非常有效的措施。