Я предваряю этот вопрос тем, что знаю о Этот вопрос но, к сожалению, мне это не помогло, поскольку «не запускать базу данных по сети» просто не вариант.
На прошлой неделе мы перенесли наш файловый сервер с Server 2000 на виртуальную машину x64 Standard Server 2008 R2. У нас есть база данных, которая предоставляет контактную информацию для заинтересованных сторон и деловых партнеров. Это проприетарная база данных, написанная нашим специалистом по анализу баз данных. С тех пор, как мы перенесли сервер, эта база данных работала много медленнее, чем обычно.
Тем не менее, я искал причину на прошлой неделе, поскольку это важная база данных для нас. Мы переходим к использованию другой системы, но я бы хотел, чтобы эта проблема была решена с ее помощью раньше, чем позже.
Релевантная информация
Связанные таблицы были повторно связаны, чтобы отразить их новый адрес UNC, а база данных сжата.
В настоящее время на сервере не запущен антивирус
Все клиентские антивирусы настроены не проверять сетевые диски
Мы сделали исключение антивируса для msaccess.exe в целях тестирования, но безуспешно
Я безуспешно пытался отключить брандмауэр на файловом сервере
Я не заметил никаких проблем с доступом к файлам (на самом деле, большинство моих сотрудников сказали, что заметили увеличение)
Я хотел бы услышать любые предложения относительно того, почему люди думают, что Server 2008 R2 замедляет работу базы данных.
Проще говоря, MS Access - ужасный продукт, который MS никогда не должна была разрабатывать или продавать. Тем не менее, по какой-то причине вы застряли в нем (пока). Вы не хотите этого слышать, но настоящий ответ таков:
Доступны пути миграции между Access и MSSQL, и они не так уж и сложны, если ваша dba знает, что делает. Вы даже можете использовать MS Access в качестве внешнего интерфейса, подключаясь к источникам ODBC на сервере SQL.
Рискуя оказаться запретным и ответить на свой вопрос (и получить выговор за продолжение использования MS Access по сети), мы успешно устранили проблему.
Проблема была решена следующим образом:
1) Все таблицы были повторно связаны с UNC-путем, а НЕ путем относительно подключенного диска (т.е. \\ server \ share \ database.mdb, а НЕ T: \ database.mdb)
2) Код базы данных был перекомпилирован
После выполнения вышеуказанного мы заметили резкое увеличение скорости поиска и функциональности базы данных.