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

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

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

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

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

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

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

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

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

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

В приложениях, не поддерживающих 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. В этой таблице будут перечислены все проблемы, возникшие во время заключения договора, если таковые были.

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