我们有一个文件共享MS-Access数据库。 我们正在得到性能缓慢，我们怀疑与文件访问速度如此之慢的错误消息。 首先要检查什么是瓶颈？
它在本地工作正常，所以我们很确定它不是应用程序本身。
您可以使用fsutil命令在服务器计算机上创build一个大的临时文件，然后将传输计时到客户端计算机，从而对文件服务器吞吐量进行“快速和肮脏”testing：
fsutil file createnew temp-file-name 209715200 这将创build200MB的临时文件。 您可以使用以下脚本（从您在服务器上创build临时文件的目录中，假设您有权连接到客户端计算机的“C $”共享）执行快速复制（使用计时器）：
@echo off echo.|time copy temp-file-name \\remote-computer-name\c$ echo.|time
从开始时间减去结束时间，转换为秒数，然后将秒数除以209715200，以获得每秒字节数。
在100Base-TX局域网上，你应该看到每秒700万字节（大约56Mbps）。 任何低于这一点，我会开始怀疑有事。 假设服务器计算机是相当现代的，它应该能够填充100Mbps的pipe道，没有问题。 如果您看到传输速度比这慢，我会开始查看服务器和客户端连接到的交换机的pipe理界面中的错误计数器。 您可能有错误的布线，双工不匹配或NIC驱动程序问题。 这只是一个有系统地追踪问题的问题。
尽量缩短文件名并缩短完整path。 听起来很奇怪，但在一些设置中却是如此。 看这个KB 。
您还可以确保服务器和工作站上的SMB签名已禁用（HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Lanmanworkstation \ Para meters \ enablesecuritysignature设置为0）（请参阅此线程 ）。
还有一个与你可以testing的LDBlocking有关的奇怪问题。 看到这个页面 。
请参阅访问性能常见问题页面。
其他一些要尝试的事情是压缩数据库本身（我假设Access仍然有这个function），并在实现共享的机器上碎片整理实际的数据库文件。 为了整理单个文件，我推荐使用sysinternals contig命令行工具。
你也可以testing一个不好的networking，通过运行ping延长的时间（我相信“ping -t”是命令的正确的Windows咒语），看看你是否丢包或看到高networking延迟。