MS访问(MDB)并发

这是一个老问题,但从来没有人真正回答过。以下是问题:

1. MDB中如何处理并发读取?
4. 将MDB文件放在网络共享上是好主意还是坏主意?

1-2)并发读取/更新/删除

Jet数据库引擎通常被称为“文件服务器”数据库,因为没有服务器端恶魔管理服务器上的数据文件的I/O。这意味着所有使用Jet MDB的客户端都直接读取文件。

现在,对于那些对客户机/服务器数据库引擎垂涎三尺的人来说,这可能看起来既原始又危险,但在Jet数据库引擎开发时,它的目的是用作小型工作组的桌面数据库引擎,它正在与xBase和Paradox等其他桌面数据库引擎竞争,两者都使用类似的锁定文件来管理来自多个客户端的数据文件的并发使用。

在Jet数据库文件中,锁要么应用于数据页(在Jet 4中增加到4K,而在Jet 3.x及之前,它们是2K),要么应用于记录级(如果数据表最初创建时使用记录级锁)。在Jet 4的早期,许多人发现记录级锁定非常缓慢,特别是在使用悲观锁定时,因此许多Access开发人员除了页面级锁定之外从未使用过任何东西(@David Fenton举手!)。

事实上,在使用乐观锁定时,可以避免悲观锁定带来的大多数并发问题。

1. 从DAO中,记录级锁定不可用,并且您只能获得页面级锁定。

2. 在DAO中,有许多用于控制乐观/悲观锁定的选项,特别是OpenRecordset方法的LockEdits参数,但也与OpenRecordset选项参数中指定的某些设置交互(例如,选项dbReadOnly不能与LockEdits一起使用)。除了锁定之外,还有用于一致/不一致更新的选项,所有这些都可以与事务交互(例如,未提交事务中的更改对其他用户不可见,因此不会与之冲突,但它可以对相关表设置只读锁定)。

从ADO/OLEDB中,这些Jet并发控制结构将映射到ADO/OLEDB中的相关函数和参数。因为我只从Access使用Jet,所以我只能通过DAO与它交互,所以我不能建议您如何使用ADO/OLEDB控制这些,但关键是Jet数据库引擎在以编程方式(而不是通过Access UI)访问它时提供了对记录锁定的控制——这更复杂。

3) 锁和.NET

我不能在这里提供任何建议,除了您可能会使用OLEDB作为您的数据接口之外,但问题是锁定功能/控制在db引擎本身中,因此有可能通过OLEDB控制它。不过,它可能并不漂亮,因为在我看来,OLEDB是围绕客户机/服务器体系结构设计的,Jet基于文件的锁定可能不会以优雅的方式映射到这一点上。

4) 网络共享上的MDB

Jet对任何网络连接中的轻微故障都非常敏感。因此,低带宽网络可能会增加通过慢速连接打开的Jet数据库的脆弱性。

此外,Jet还进行了一些非常智能的缓存,这意味着第一个数据请求可能需要一段时间,但由于缓存的原因,对相同数据的后续请求几乎是瞬间发生的。

另一件要避免的事情是尝试通过WiFi连接使用Jet数据。我们都知道WiFi有多不可靠,而试图通过WiFi连接处理Jet数据只是自找麻烦。

底线是:

如果使用MDB作为数据存储来服务web服务器的数据,则应将数据尽可能靠近web服务器的RAM。这意味着,在可能的情况下,在连接到物理web服务器的磁盘卷上。在不可能的情况下,您需要快速、可靠的LAN连接。如今,数据中心中的GB局域网非常普遍,我很乐意通过这种连接处理Jet数据。

1. 除非所有用户都在使用同一复制副本,否则不要尝试在复制的文件系统上分发MDB。也就是说,如果有两台服务器在它们之间复制文件,那么甚至不要考虑从两台服务器编辑MDB文件。这几乎会立即损坏文件。

2. 我建议不要将任何MDB存储在通过本机Microsoft SMB网络提供服务的本机Windows文件系统以外的任何系统上。这意味着没有Novell,没有Linux,没有SAMBA。这样做的关键原因是,在Windows文件系统中,从Jet到某些低级锁定功能显然存在低级挂钩,而这些功能在其他文件系统上没有100%复制。现在,我对此非常保守,许多有能力的Access开发人员都报告了正确配置的Novell文件服务器的出色结果(通常需要进行一些记录锁定调整,尽管这些天可能不太相关——我甚至不知道Novell是否还存在!),以及运行SAMBA的基于Linux的文件服务器的出色性能。我对此持谨慎态度,并建议任何客户机都不要这样做(这也包括各种SAN设备,因为它们中没有多少是基于Windows的)。

3. 出于同样的原因,我不会在任何虚拟化文件系统上运行它们。然而,我有一个客户,她在MacAir上运行她的单用户访问应用程序已经有好几年没有任何问题了。但是它是单用户的,所以锁定问题相对较小。

我不知道这是否回答了你的问题。这一切都是基于我作为Access开发者13年来对Jet的经常使用,以及对唯一出版的Jet书籍《Jet数据库引擎程序员指南》(仅适用于Jet 3.5)的研究。我没有提供任何真实的引文,但如果有人需要我所说的任何细节,我会尽我所能进行研究。

这些年来,我已经在Access中构建了十几个左右的小企业应用程序。大多数网站一次最多有10-20个用户。数据库分为“应用程序”和“数据”数据库。性能良好,一致性没有问题。此外,自Access 2000 SP2以来,腐败基本上不存在。

有很多人说“永远不要使用Access”-如果做得好(即由专业开发人员),Access是一个很好的开发包,我已经在这方面过了很好的生活。我的客户对我的产品非常满意。

我已经编写了两个商业产品,它们使用Access数据库,从网络共享运行,通常最多支持10个用户。如果你不滥用它,真的没有问题;但是正如你所看到的,很多开发者都没有做到这一点——而且由于它的低端特性,在它的基础上构建了很多蹩脚的黑客。在一个产品的例子中,我不得不重新设计应用程序,因为其他人详细描述了所有的问题;但在我清理它之后,我在数百个安装中从未遇到过数据库完整性问题。

它的一大优势是单一文件数据库,它易于备份、恢复和复制到笔记本电脑上进行分析。几乎所有的备选方案,包括sqlite(尽管有些人不承认),都需要DBA时不时地给予某种形式的关注。

在大多数情况下,Access默认为某些DDL(例如模式更改)提供记录锁和文件锁。

但是微软基本上是在淘汰它,你的一些同事会因为你使用它而嘲笑你。

(此时,我通常会躲开并大叫“来袭!!!”)

Access实际上是一个桌面、单用户解决方案。实际上,它的用户上限为“一”。

它也是一个本地引擎。也就是说,当您运行查询时,数据会通过网络拉到本地喷气发动机进行处理。在网络共享上放置一个.ldb文件以控制锁。

这对性能、稳定性和数据完整性有着巨大的影响。

有了一个合适的数据库引擎(MSSQL、Sybase、Orable:我不喜欢MySQL的备份),您也就有了一个合适的备份功能。除非您有一些先进的软件来备份使用中的文件,否则您可能无法在Access DB中备份您的数据。

我可以看到使用Access项目作为数据库引擎的前端,但不投资于带有Access后端的完整客户端应用程序。

我一直在使用Access,或者更恰当地说,Jet作为一个非常小的私人网站的后端,这个网站永远无法增长,因为它在这个小国受到专业规模的限制。三年来我没有遇到任何问题。用户不到100人,每天大约有30到40人使用它。这些表格有几千条记录。

我在访问方面没有太多经验,但此链接可能对您有用:

http://office.microsoft.com/en-us/access/HP052408601033.aspx

在共享模式下打开Access数据库文件(.mdb)时,Microsoft Access还会创建一个与数据库文件同名(例如Northwind.ldb)且位于同一文件夹中的锁定信息文件(.ldb)。此锁定信息文件存储计算机名(例如mypc)和安全名称(例如Admin)数据库的每个共享用户。Microsoft Access使用此信息控制并发。在大多数情况下,Microsoft Access会在最后一个用户关闭数据库文件时自动删除锁定信息文件。”

Access应该是多用户的—我认为Microsoft建议最多使用4或5个用户,但实际上,我建议您不要在有多个用户的情况下使用Access数据库,尽管如果您确实没有选择权,那么考虑到某些限制条件,两个或三个用户都可以接受。

实际上,如果系统没有太多的并发插入/更新,并且没有被大量使用,那么它通常可以正常工作。根据我的经验,主要的实际问题是。。

1. 它很容易腐败——确实如此。一般来说,这不是一个太大的问题,因为打开文件并运行compact和repair可以解决问题,但良好的备份机制是绝对必要的。

3. 由于Access将记录标记为已更新或已删除,数据库文件会膨胀。这会进一步降低系统速度,因为文件必须通过网络加载。因此,通常每天压缩数据的某种机制是必不可少的。

以上所有这些对于单用户系统来说都不是什么问题,因为引发这些问题的潜在问题就不那么突出了。

总而言之,我必须强调,我决不会建议任何多用户系统访问。然而,如果你真的有太多,你可能会逃脱它,只要它是一个很少使用的应用程序,你做了备份和维护程序。

已经多次声明要使用真正的多用户免费数据库平台。但其中一个原因尚未说明。这是因为,有多少现有的、混乱的、麻烦的、大型Access数据库一开始只是“几个记录,最多一个或两个用户”?我冒昧地把它们全都说出来。

除非整个公司只有两到三名员工,否则很有可能,如果你开发一个有用的软件,它最终将被超过原来的两到三个用户使用,拥有超过原来几千条记录,并且随着时间的推移将扩展到包括许多表格、更多表格和更多数据。房子一旦建成,你就不能重新建造房子的地基。今天建立一个坚实的基础,你可以把房子扩大到你的心满意足。软件也是如此。

当使用网络共享时,我会使用支持网络的数据库(mysql/firebird/mssql),而不是access。

在这种情况下,使用Access进行描述不会有问题。

另外,当您想要一个线程安全的低开销数据库时,您可以查看vistadb(比access慢,不总是免费的,100%.NET)

我认为access使用带有某种奇怪机制的表级锁,应该可以正常工作。 如果你对此感到担忧,你可以随时进行模拟压力测试。

我认为您可以在.net应用程序连接字符串中定义它。我在谷歌上搜索JET、access和record locking

这里有一个 link 这可能会有帮助。

有关Access和JET如何获取数据的真实详细信息,请参阅已接受的答案。

具体原因:

• 没有Linq这样的东西可以访问
• Access有许多怪癖,比如依赖于将参数添加到命令的顺序,这将花费您很多时间进行调试
• 访问不可伸缩