sql-server-ce - 解决SQL Server Compact Edition数据库文件中的损坏

Question

这不是查询。它概述了我们的解决方案，它可以(几乎)绝对成功地解决SQL Compact Database文件中的损坏问题。 SQLCE损坏是一个非常普遍的问题。我们已经从StackOverflow的早期文章中获得了巨大的帮助，因此也获得了这篇文章。

我们的产品是3层体系结构，其中服务器作为Windows服务运行，并通过.Net Remoting连接到Rich Clients。自2006年以来，我们的产品使用SQLCE。我们已经从v3.1升级到v3.5，现在是v4.0。我们为某些非常特定的需求提供了自定义OR映射工具。 v3.1面临的问题有限，v3.5和v4.0面临的问题更多。

最初使用v3.5，我们实现了SqlCeEngine.Repair。但是它只会删除损坏的数据，并尝试重新创建稳定的数据库。我们发现受影响的表的外键丢失了。我们不得不立即取消这一点。我们开始通知用户有关数据库损坏的信息，并恢复了上一次备份。这只是暂时的救济；腐败问题仍然存在。

今年，我们采用了v4.0。但是，我们的应用程序还引入了一些新功能，这些功能极大地增加了数据库调用的次数。 v4.0起步不错，但是当软件使用率增加时开始出现问题。应用程序运行期间发生的损坏不是Windows崩溃，异常关闭或磁盘问题引起的。数据库刚刚损坏。

下一篇文章介绍了我们针对此问题设计的解决方案:

Answer 1

[分离查询和解决方案]

这是我们如何解决问题的方法:

A)关闭/处置连接/命令/事务对象:
我们确保没有未使用的，未关闭的连接，事务或命令对象。我们的ORM工具用于在调用事务提交后创建新对象，在某些情况下，它们处于空闲状态。这几乎将腐败的数量减少了50％。

B)禁用自动收缩:
在我们无法控制的应用程序运行中唯一发生的过程是自动收缩。应用程序启动时，我们正在调用SqlCeEngine.Compact。我们决定同时取消压缩和自动收缩。令我们惊讶的是，我们又将腐败减少了48％。这是在黑暗中拍摄的镜头，我们无法相信自动收缩可能会导致此类问题。我们实际上通过该更新解决了该问题。

C)同步数据库事务:
一些数据库损坏仍在发生。在未发现明显原因的情况下，我们决定同步数据库事务!我知道很多数据库人员不会喜欢这样。我也不喜欢我们在中间层引入了锁，以确保一次只有一个调用正在修改数据库。我们最大的实现是同时使用我们的系统的55个客户。同步数据库调用几乎不会导致任何可见的性能延迟。相反，通过同步，我们可以定期执行对SqlCeEngine.Compact的计时器驱动的调用。我们知道Compact并非罪魁祸首，并且我们认为Compaction是必需的调用，因为它会重新索引db(我们的解决方案会执行很多插入和删除操作)。但是，它需要专门运行；调用Compact时没有数据库调用。同步允许我们在应用程序运行期间进行控制。既然完成了，我们就没有收到一个单一的数据库损坏问题。现在已经超过一个月了。从每周近5位客户到一个月零位。

导致我们想到想法B和C的基本原因是SQLCE是嵌入式数据库。腐败对于每个嵌入式数据库解决方案都是常见的。全面的数据库解决方案可通过24x7 db-server管理连接和其他任务独立支持。嵌入式数据库系统没有这样的支持系统。存活的唯一阶段是打开连接时。

还有一些指针:1)我们使用CommitMode.Immediate实现commit，这使Flush-Interval属性变得多余。 2)AutoShrink设置为100，这将完全禁用该过程3)我增加了Connection超时，以允许同步的数据库调用平稳运行。 4)在应用程序启动时调用Compact。如果客户根本不关闭计算机，则我们实现了计时器，每24小时调用一次Compact。

希望这篇文章有助于解决问题。