由一个数据库恢复案例而想到的

存储型号：HDT721032SLA360

故障现象：逻辑E盘保存的1.5G SQL数据库文件正常使用突然置疑。管理员尝试修复等手段失败，进行复制备份也失败

处理过程：

先对硬盘进行检测发现此盘有坏扇区存在，数据库所在的逻辑盘为NTFS，元文件完好，通过对元文件分析发现引文件有6个片段（也就是常说的碎片化），对每段进行检测，发现片段3 4 5都有坏扇区，可能是此问题导致了数据库管理器报错。使用PC3000 UDMA DE进行数据提取，由于LDF文件完好，用户提出直接附加方案（由于管理器在加载时会对MDF文件进行初步校验，所以一般情况下是加载不上的），结果附加失败管理器报错。对当前库文件进行坏页分离修复方式修复，重新生成LDF，并使用DBCC命令对当前库进行修复后库恢复正常，通过和软件公司提供的关键表核对，数据全部正常。至此数据恢复完毕！

有关数据库管理想到的：

很多中小型公司使用MS公司的SQL产品进行数据收集及管理，正常情况下建议对库文件进行按年度或季度进行命名的方案，比如2011年则生成一个2011年的库文件，2012年则生成2012年的库文件，这样管理的好处是备份起来较为方便，且分类较为清晰。如上述案例1.5G的库文件是07年生成的到现在都已经5年了，平均每年也就300M不到的大小，这样在备份的时候管理器生成BAK文件的速度会很快，而大小超过1G或者4G的（数据库内部管理有一个边界值，大于设定的边界值在管理上会比边界值内的要复杂，会影响速度），不仅在生成BAK文件时速度慢且在管理相对较复杂！