Сжатие и архивирование баз данных - MS Access Backend
Сценарий: существует устаревшая программа (не знаю, на каком языке), и меня попросили "Сжать и архивировать формы в базе данных". В тот момент, когда пользователь открывает приложение, для загрузки около 27000 записей требуется около 2-5 минут!!! Моя теория состоит в том, что он загружает все записи при запуске, но это может быть не единственной причиной. После некоторого поиска и нахождения бэкенда доступа, который выглядит правильно, я также нашел те же файлы доступа на 15+ других общих ресурсах компании. Теперь это приложение было создано где-то в 1997 году, когда я предположил, что Access был нормой, но будут ли они действительно получать данные из 15+ баз данных Access? То, что кажется нормой для ускорения этой программы, - это архивирование старых записей в другой базе данных доступа (вот почему я думаю, что она загружает все при запуске.
Вопрос: У меня встреча в понедельник, чтобы обсудить программу, и мне было интересно, если кто-нибудь может предложить некоторые полезные вопросы, теории, решения и т. Д. Это не то, что я не могу сделать это самостоятельно, я просто думаю, что другая точка зрения не может причинить боль. Еще один забавный факт заключается в том, что я могу или не могу получить исходный код, потому что он, возможно, был создан подрядчиком, а код давно потерян.
Примечание: возможно ли получить доступ к автоматическому архивированию старых записей? Это будет означать перенос их в другую базу данных под названием XXXArch.
Заранее спасибо. Я постараюсь ответить на любые ваши вопросы.
РЕДАКТИРОВАТЬ:
Вот обновленная информация о ситуации.
Похоже, что он использует только одну базу данных в качестве основной и одну для архивирования. У меня все еще есть собственная учетная запись, чтобы открыть приложение, но при просмотре базы данных появляется таблица пользователей с идентификатором входа и тем же паролем (ПАРОЛЬ), поэтому я попытался войти как один из этих пользователей и просто выбрать несколько данные не изменяют ничего. При выборе я был в состоянии получить данные почти мгновенно и не видел никакого замедления, которое получали другие пользователи. Я до сих пор не видел исходный код, но из того, что я могу сказать (взяв exe и поместив его в блокнот), похоже, что он был закодирован в VBA и, вероятно, создан с использованием MS Access. Также кажется, что приложение создает temp.mdb в папке данных. В настоящее время в нем ничего нет. Нет таблиц, ничего. Я предполагаю / надеюсь, что это замедляет работу пользователей и может быть просто удалено для повышения производительности. Я опубликую еще одно обновление, как только получу исходный код и пойму, что замедляет его.
3 ответа
Несколько вещей для рассмотрения:
Базы данных Access (MDB), как правило, требуют регулярного сжатия / восстановления, как вы отмечали в заголовке, если они часто используются. Однако я редко обнаруживал, что это помогает производительности больше, чем минимально. Если это было действительно долгое время, файл может раздуваться очень большим, и это может быть частью проблемы, если пользователи обращаются к нему через медленное сетевое соединение.
Кто-то собирается предложить перейти к "более крупной" БД, такой как SQL-сервер, либо в вашей компании, либо на этом форуме. Не делайте этого до тех пор, пока вы не изолируете проблему или не найдете причину, отличную от производительности. Существует реальная вероятность того, что проблемы вызваны плохим дизайном приложения или архитектурой БД. Бросок более мощного инструмента в проблему без изменения подхода вряд ли поможет.
БД доступа будет максимально использовать одновременных пользователей задолго до того, как она будет максимально использовать данные. Многие пользователи (30+) только начали использовать систему? Это может быть частью проблемы.
Архивирование старых записей: вам нужно будет что-то создать для этого. Хорошей новостью является то, что это не так уж сложно.
Доступ к 15+ базам данных: вы уверены, что интерфейсный интерфейс не написан в Access. Это обычная архитектура с доступом для загрузки внешнего интерфейса MDB на компьютер конечного пользователя (скопированного везде), подключенного к центральному файлу данных MDB в сети. Лучший способ определить это - открыть базы данных и посмотреть, содержат ли они только таблицы или таблицы + формы / отчеты.
Мне кажется, ваш первый заказ должен решить эту проблему:
Я могу или не могу получить исходный код, потому что он, возможно, был создан подрядчиком, а код давно потерян.
В настоящее время вы просите нас порассуждать о причинах и способах устранения медлительности... без каких-либо знаний о том, что на самом деле происходит.
Если у вас нет исходного кода, вы не можете изменить внутреннюю базу данных на SQL Server или что-либо еще.
Однако, если у вас действительно есть доступ к файлам данных и вы можете их редактировать, почему бы не проверить индексацию? 27K записей - это тривиально для любой базы данных, включая Access, и медлительность загрузки данных позволяет предположить, что таблицы просто не проиндексированы должным образом. Если вы изучите таблицы и не увидите индексов в очевидных полях, попробуйте добавить их и посмотреть, не ускоряет ли это процесс.
Если это не так, то это означает, что приложение плохо спроектировано, и, поскольку у вас нет исходного кода, с этим ничего не поделаешь.
Все вышеизложенное предполагает, конечно, что сетевая среда подходит для Access/Jet/ACE. То есть, если доступ к этим файлам базы данных осуществляется через что-либо, кроме проводной локальной сети, то с этим ничего не поделаешь (WAN и WiFi полностью недоступны для Jet/ACE).
И наконец, что касается архивации, я думаю, что нет никакого оправдания для того, чтобы когда-либо архивировать данные, если вы действительно не сталкиваетесь с жесткими ограничениями на аппаратное / программное обеспечение. В этом случае, вы даже не близко к этому.