Как сжать базу данных MS Access

Каждый механизм базы данных, который когда-либо существовал, требует регулярных операций обслуживания, выполняемых на нем, чтобы оптимизировать хранение данных и восстановить свободное пространство. Еще в дни xBase вы запускали команду PACK, например, для удаления удаленных строк. В SQL Server вы запускаете сценарии для сжатия фактических файлов данных по тем же причинам.

Почему каждый механизм базы данных делает это?

Потому что это было бы огромным снижение производительности, если при каждой записи в базу данных приходилось перезаписывать весь файл в оптимизированном порядке. Рассмотрим базу данных, в которой каждая таблица данных хранится в отдельном файле. Если в таблице 10000 записей, и вы удаляете 5000-ю запись, чтобы избавиться от свободного места, вам придется переписать всю вторую половину файла данных. Вместо этого каждая база данных использует ту или иную форму маркировки используемого пространства как неиспользуемого и отбрасываемого при следующем запуске операций оптимизации в таблице данных.

Jet/ACE в этом отношении ничем не отличается от любых других ядро базы данных и любое приложение, использующее базу данных Jet/ACE в качестве хранилища данных, должны иметь запланированные регулярные операции обслуживания, включая резервное копирование, а затем сжатие.

Есть некоторые проблемы с этим в Jet/ACE, которые отсутствуют в движках серверных баз данных. В частности, вы не можете сжать, если все пользователи не закрыли свои подключения к файлу данных. В серверной базе данных пользователи подключаются к серверному процессу ядра базы данных, и этот серверный демон является единственным «пользователем» фактических файлов данных, в которых хранятся данные. Таким образом, демон сервера может решить, когда выполнять процедуры оптимизации и обслуживания, поскольку он полностью контролирует, когда файлы данных используются или нет.

Одна из распространенных проблем с приложениями Access заключается в том, что пользователи оставят свое приложение открытым на своих компьютерах и покинут офис на день, что означает, что когда вы запускаете компактную операцию, скажем, в 2 часа ночи, файл все еще открыт, и вы не можете его запустить (потому что компактный заменяет исходный файл). Большинство программистов приложений Access, которые сталкиваются с этой проблемой, будут либо терпеть случайные сбои такого рода обслуживания в ночное время (теневая копия тома по-прежнему позволяет создавать резервную копию файла, хотя нет гарантии, что резервная копия будет находиться в 100% внутренне согласованном состоянии) , или они разработают свои приложения Access так, чтобы они завершали работу в удобное время, чтобы разрешить ночные операции обслуживания. Я сделал и то, и другое.

В приложениях без доступа такая же проблема существует, но ее нужно решать по-другому.. Для веб-приложений это своего рода проблема, но в целом я бы сказал, что любое веб-приложение, которое сбивает данные в объеме, достаточном для того, чтобы потребовалось сжатие, – это такое, для которого хранилище данных Jet/ACE совершенно не подходит.

Теперь по поводу КОМПАКТА НА ЗАКРЫТИИ:

Его никогда не следует использовать.

Когда-либо.

Это бесполезно и прямо опасно, когда оно на самом деле срабатывает.

Это бесполезно, потому что нет должным образом спроектированной производственной среды в котором пользователи когда-либо открывали бы серверную часть – если это приложение Access, оно должно быть разделено, при этом пользователи будут открывать только интерфейсную часть, а если это веб-приложение, пользователи не будут напрямую взаимодействовать с файлом данных . Таким образом, в обоих сценариях никто никогда не будет запускать КОМПАКТ НА ЗАКРЫТИЕ, поэтому вы зря потратили время на его включение.

Во-вторых, даже если кто-то время от времени запускает его, он только сработает. работают, если только этот пользователь имеет открытую базу данных. Как я уже сказал выше, его нельзя сжать, если у других пользователей он открыт, так что это тоже не сработает – COMPACT ON CLOSE может работать только тогда, когда пользователь, запускающий его, имеет монопольный доступ.

Но хуже всего то, что КОМПАКТНОЕ ЗАКРЫТИЕ опасно, и если оно все же запустится, это может привести к реальной потере данных. Это связано с тем, что существуют определенные состояния, в которых может находиться база данных Jet/ACE, в которых внутренние структуры неисправны, но все данные все еще доступны. Когда в этом состоянии выполняется операция сжатия/восстановления, данные могут быть потеряны. Это крайне редкое состояние, но это очень маловероятная возможность.

Дело в том, что COMPACT ON CLOSE не является условным, и нет запроса, который спрашивает, хотите ли вы его запустить. У вас нет возможности сделать резервную копию до ее запуска, поэтому, если она у вас включена, и она срабатывает, когда ваша база данных находится в очень редком состоянии, вы можете потерять данные, которые в противном случае вы смогли бы восстановить, если вы не выполнили операцию сжатия.

Короче говоря, никто, кто хоть немного разбирается в Jet/ACE и сжатии, никогда не включает КОМПАКТНЫЙ ПРИ ЗАКРЫТИИ.

однопользовательский, вы можете просто сжать его по мере необходимости.

Для общего приложения лучше всего использовать какой-либо сценарий планового обслуживания, обычно выполняемый на файловом сервере в ночное время. Этот сценарий сделает резервную копию файла, а затем запустит компакт. Это довольно простой сценарий для написания на VBScript, который легко запланировать.

Наконец, если ваше приложение часто удаляет большое количество записей, в большинстве случаев это указывает на ошибку дизайна. Записи, которые добавляются и удаляются при обычном производственном использовании, являются ВРЕМЕННЫМИ ДАННЫМИ и не принадлежат к вашему основному файлу данных, как с логической, так и с практической точки зрения.

Все мои производственные приложения имеют временную базу данных как часть архитектуры, и все временные таблицы хранятся там. Я никогда не удосужился сжимать временные базы данных. Если по какой-то причине производительность упала из-за раздутия в базе данных temp, я бы просто скопировал нетронутую пустую копию базы данных temp поверх старой, поскольку ни одна из данных в ней не является чем-то другим, кроме временных. Это уменьшает отток и раздувание во внешнем или внутреннем интерфейсе и значительно снижает частоту необходимых уплотнений в файле данных серверной части.

По вопросу о том, как уплотнять, есть несколько вариантов:

1. в пользовательском интерфейсе Access вы можете сжать текущую открытую базу данных (TOOLS | DATABASE UTILITIES). Однако это не позволяет вам делать резервную копию как часть процесса, и всегда рекомендуется делать резервную копию перед сжатием, на случай, если что-то пойдет не так.

2. в пользовательском интерфейсе Access вы можете сжать базу данных, которая не открыта. Он сжимается из существующего файла в новый, поэтому, когда вы закончите, вам нужно переименовать как исходный, так и только что сжатый файл (чтобы получить новое имя). Диалоговое окно «ОТКРЫТЬ ФАЙЛ», в котором спрашивается, из какого файла нужно выполнить сжатие, позволяет переименовать файл в этот момент, чтобы вы могли сделать это как часть ручного процесса.

3. в коде вы можете использовать метод DAO DBEngine.CompactDatabase для выполнения этой работы. Это можно использовать из Access VBA, из VBScript или из любой среды, где вы можете использовать COM. Вы несете ответственность в своем коде за создание резервных копий, переименование файлов и т. Д.

4. другой вариант кода – JRO (Jet & Replication Objects), но он не предлагает ничего в отношении компактных операций, чего еще нет в DAO. JRO была создана как отдельная библиотека для обработки специфичных для Jet функций, которые не поддерживались в самом ADO, поэтому, если вы используете ADO в качестве интерфейса, рекомендуемой MS библиотекой для сжатия будет JRO. Изнутри Access JRO не подходит для compact, поскольку у вас уже есть доступный метод CompactDatabase, даже если у вас нет ссылки на DAO (DBEngine всегда доступен в Access, независимо от того, есть ли у вас ссылка DAO). Другими словами, DBEngine.CompactDatabase можно использовать в Access без ссылки DAO или ADO, тогда как метод JRO CompactDatabase доступен только со ссылкой JRO (или с использованием позднего связывания). За пределами Access подходящей библиотекой может быть JRO.

Позвольте мне подчеркнуть, насколько важны резервные копии. Вам он не понадобится в 999 раз из 1000 (или даже реже), но когда он вам понадобится, он понадобится вам плохо! Поэтому никогда не выполняйте сжатие без предварительного резервного копирования.

Наконец, после любого сжатия рекомендуется проверить сжатый файл на предмет наличия системной таблицы с именем MSysCompactErrors. В этой таблице будут перечислены все проблемы, возникшие во время сжатия, если таковые были.

Это все, о чем я могу думать о компактности на данный момент..

• 3
  Хороший пост, хотя твой ответ похож на убийство мухи базукой. 🙂 – Джоэл Говро 10 авг., 13:55
• Хех, да, наверное. Но этот вопрос задают достаточно часто, и совершенно очевидно, что люди используют базы данных, включая Jet/ACE, не имея базового понимания того, как они работают. Это просто собирает все в одном месте, более или менее, и, я надеюсь, людям можно указать на это, когда это необходимо, вместо того, чтобы другим приходилось отвечать на вопросы по теме по частям. Мне нравится писать такие ответы, потому что это помогает мне понять, что я делаю и чего не знаю. Надеюсь, иногда это помогает и другим. – Дэвид-В-Фентон, 11 авг., 2010 в 0:32

Откройте MDB и выполните «Сжать и восстановить». Это уменьшит размер MDB.

Вы также можете включить опцию «Сжать при закрытии» (по умолчанию выключено).

Вот ссылка для получения дополнительной информации: http://www.trcb.com/computers-and-technology/data-recovery/ways-to-compact-and-repair-an-access-database-27384.htm

• 3
  Как вы это поняли …? – Александр, 7 августа 2010 г., 1:55
• 1
  У меня была такая же проблема 10 лет назад … я думаю, это были мои точные слова … 😉 – Эдвард Лено, 7 августа 2010 г., 2:01
• Какая у вас версия Microsoft Access? – Эдвард Лено, 7 августа 2010 г., 02:27
• 5
  Не рекомендуется устанавливать «Сжатие при закрытии», поскольку иногда возникают проблемы и потеря данных. – Тони Тэйвс 8 авг., 2010 в 1:50

Механизм базы данных Microsoft Access предоставляет метод CompactDatabase, который делает компактную копию файла базы данных. Файл базы данных необходимо закрыть перед вызовом CompactDatabase.

Документация:

• Страницы на microsoft.com о «Сжатии и восстановлении базы данных»
• Метод DBEngine.CompactDatabase (DAO)

Вот сценарий Python, который использует DAO для копирования и сжатия файлов MDB:

  import os.pathimport sysimport win32com.client # Access 97: DAO.DBEngine.35 # Access 2000/2003: DAO.DBEngine.36 # Access 2007: DAO.DBEngine.120daoEngine = win32com.client.Dispatch ('DAO  .DBEngine.36 ') if len (sys.argv)! = 3: print («Использует Microsoft DAO для копирования файла базы данных и его сжатия.») Print («Использование:% s DB_FILE FILE_TO_WRITE»% os.path.basename  (sys.argv [0])) sys.exit (2) (src_db_path, dest_db_path) = sys.argv [1:] print ('Использование базы данных "% s", сжатие до "% s"'% (src_db_path, dest_db_path  )) daoEngine.CompactDatabase (src_db_path, dest_db_path) print ("Готово")  

С python вы можете выполнить сжатие с помощью библиотеки pypyodbc (либо .mdb, либо .accdb)

  import pypyodbcpypyodbc.  win_compact_mdb ('C: \ data \ database.accdb', 'C: \ data \ сжатый. accdb ')  

(источник)

Затем вы можете скопировать compcted.accdb обратно в database.accdb с помощью shutil:

  import shutilshutil.copy2 ('C: \ data \ compailed.accdb', 'C: \ data \ database.accdb')  

(источник)

Примечание : Насколько мне известно, для Access DB с ODBC, python и его библиотеки должны быть 32-битными (ссылка). Кроме того, эти шаги, вероятно, работают только с ОС Windows.