数据库太大的通常解决办法

  前段时间碰到有朋友的数据库达到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选项可能会同时启动，从而降低系统运行速度。然而，对于那些数据库管理员无暇估计并且数据库尺寸有可能在您毫无察觉的情况下超出控制范围的桌面或远程系统来说，开启这一选项却是一种非常有效的措施。  
   总之，解决服务器各方面故障需要冷静分析，而不是盲目一位朝着一个方向去硬撞，上面我那位朋友，服务器配置已经更新到相对部门级顶级的配置：
主  板：INTEL 5520 CHIPSET

处理器：2*XEON 5560(2.8G,4核、8M,6.4GT/秒)

内  存：6*4G REG ECC DDRIII

硬  盘：3*300G SAS （RAID 5）

热插拔：支持

机  箱：1U(4盘位，支持热插拔）

电  源：1U 520W（主动式PFC，80PLUS）

网  卡：INTEL双千兆





      结果还是出现跑一个星期的数据库就假死的现象，到现在才发现是数据库的优化问题，可惜了配置这么高的服务器。