数据库经常置疑、损坏，有没有办法预防或解决？
客户的生产环境可能有时比较恶劣（掉电、强制结束、强制关机等），导致经常出现数据库置疑和损坏（平均每周要处理两起），处理这种问题非常麻烦，感觉sql2000在这方面真的表现很差，想了很多办法，真是无解啊。。。假设生产环境不可改变（比如平均每天掉电一至两次，且不可能要求用户提供UPS），大家有没什么好招预防或解决这个问题？

其它参考信息：
1.数据库平均大小1-2G
2.基本每张表都有聚集索引
3.很多表都有自增长列
4.很多表都有触发器(ins/upd/del均可能有)
5.部分表有rowversion列
6.读写都不算特别频繁，可按每5分钟一笔销售计算，单笔销售的数据量不大，但平均10-30分钟左右会有一次相对较大数据量的交换（门店数据库与总部数据库的数据交换），交换数据时会在多张表中插入或修改（例如某次数据交换写了20张表，平均每张表写100条记录）

------解决方案--------------------
我来mark下，看有没有高手有好的招。
我也遇到这样的问题，但总觉得无法避免，因为这样时间长了别说数据库，连整个硬盘都会废掉。这种情况我已经遇到一次了，硬盘直接就挂了，最好做一个远程备份。然后出问题以后再还原回去
------解决方案--------------------

探讨

客户的生产环境可能有时比较恶劣（掉电、强制结束、强制关机等），导致经常出现数据库置疑和损坏（平均每周要处理两起），处理这种问题非常麻烦，感觉sql2000在这方面真的表现很差，想了很多办法，真是无解啊。。。假设生产环境不可改变（比如平均每天掉电一至两次，且不可能要求用户提供UPS），大家有没什么好招预防或解决这个问题？

其它参考信息：
1.数据库平均大小1-2G
2.基本每张表都有聚集索……

------解决方案--------------------
UPS才多少钱，我觉得丢一次数据可能更好
------解决方案--------------------
每天做一次完整备份(业务不繁忙的时候，如凌晨1-3点)，每5分钟做一次事务日志备份。备份路径可以考虑本地和网络路径。

当然少不了UPS，从成本考虑，可以选择便宜的UPS。

------解决方案--------------------
1.增加ups
2.每天做数据库维护，把备份，清楚维护，收缩数据库设置为每日执行
3.每周做数据库维护，把重新生成索引，检查数据库完整性和更新统计信息设置为每周执行
4.做检查记录，每天检查数据库以及维护计划的执行情况
------解决方案--------------------
还是应该想办法换个好点的生产环境，否则其他办法都是治标不治本，万一哪天你数据库彻底完蛋了，再也无法修复了，你怎么办？
靠备份？在等待备份的时间里，客户怎么办？难道不生产了？
------解决方案--------------------
极品客户，又常停电，加个UPS都不可能……
那只有用极品手段对付了……常人的套路是玩不转的
------解决方案--------------------
试试关掉硬盘的cache功能，当然性能会降低。