Что Восстановление и Компактные операции делают к .MDB
?
Если эти операции не останавливают 1 ГБ + .MDB
поддержанный катастрофический отказ приложения VB, что другие опции там?
Почему был бы крупных размеров .MDB
причина файла приложение для катастрофического отказа?
«Что делают с MDB операции сжатия и восстановления?»
Во-первых, не беспокойтесь о ремонте. Тот факт, что все еще существуют команды, предназначенные для автономного ремонта, - это наследие старых времен. Это поведение этой команды было сильно изменено, начиная с Jet 3.51, и остается таковым с тех пор. То есть ремонт никогда не будет выполнен, если Jet / ACE не определит, что это необходимо. Когда вы делаете компактирование, он проверит необходимость ремонта и выполнит его перед компактированием.
Итак, что он делает?
При сжатии / восстановлении файл данных перезаписывается, удаляются все неиспользуемые страницы данных, записываются таблицы и индексы на смежных страницах данных и помечаются все сохраненные QueryDef для повторной компиляции в следующий раз. бег. Он также обновляет определенные метаданные для таблиц и другие метаданные и внутренние структуры в заголовке файла.
Все базы данных имеют некоторую форму «компактной» работы, потому что они оптимизированы по производительности. Дисковое пространство дешево, поэтому вместо того, чтобы записывать что-либо для эффективного использования хранилища, они вместо этого записывают в первое доступное пространство. Таким образом, в Jet / ACE, если вы обновляете запись, запись записывается на исходную страницу данных только в том случае, если новые данные помещаются в исходную страницу данных. В противном случае исходная страница данных помечается как неиспользуемая, и запись перезаписывается на совершенно новую страницу данных. Таким образом, файл может стать внутренне фрагментированным, при этом использованные и неиспользованные страницы данных смешиваются по всему файлу.
Компактность все аккуратно упорядочивает и избавляется от лишнего пространства.Он также перезаписывает таблицы данных в порядке первичного ключа (кластеры Jet / ACE на PK, но это единственный индекс, по которому вы можете кластеризоваться). В этот момент также переписываются индексы, поскольку со временем они тоже становятся фрагментированными.
Компактность - это операция, которая должна быть частью регулярного обслуживания любого файла Jet / ACE, но вам не следует делать это часто. Если вы регулярно сталкиваетесь со значительным раздуванием, это говорит о том, что вы можете неправильно использовать свою внутреннюю базу данных, сохраняя / удаляя временные данные. Если ваше приложение добавляет записи и удаляет их как часть своих обычных операций, то у вас есть проблема с дизайном, из-за которой ваш файл данных будет регулярно раздуваться.
Чтобы исправить эту ошибку, переместите временные таблицы в другой автономный MDB / ACCDB, чтобы отток не приводил к раздутию вашего основного файла данных.
Еще одно примечание, неприменимое в данном контексте, внешние интерфейсы bload по-разному из-за характера того, что в них хранится. Поскольку этот вопрос касается MDB / ACCDB, используемого из VB, я не буду вдаваться в подробности, но достаточно сказать, что сжатие внешнего интерфейса - это то, что необходимо во время разработки, но очень редко в производственном использовании. Единственная причина для сжатия производственного интерфейса - это обновить метаданные и перекомпилировать хранящиеся в нем запросы.
Всегда было так, что файлы MDB становятся медленными и склонными к повреждениям, когда их размер превышает 1 ГБ, но я никогда не знал почему - это всегда было просто фактом жизни. Я провел быстрый поиск и не смог найти никаких официальных или даже хорошо информированных инсайдеров, объясняющих, почему этот размер связан с проблемами MDB, но мой опыт всегда говорил о том, что файлы MDB становятся невероятно ненадежными по мере приближения к 1 ГБ и более.
Вот статья MS KB о Repair and Compact, в которой подробно описано, что происходит во время этой операции:
http://support.microsoft.com/kb/209769/EN-US/
Приложение, вероятно, падает в результате неправильных/неожиданных данных, возвращенных в результате запроса базы данных к MDB такого размера - какую именно ошибку вы получаете, когда ваше приложение падает? Возможно, есть способ перехватить ошибку и справиться с ней вместо того, чтобы просто аварийно завершить приложение.
Если он часто падает, то вы можете попробовать декомпилировать БД и/или создать новую базу данных и скопировать все объекты в новый контейнер.
Сначала попробуйте декомпилировать, для этого просто добавьте флаг /decompile в опции запуска вашей БД, например
"C:\Program Files\access\access.mdb" "C:\mydb.mdb" /decompile
Затем уплотните, скомпилируйте и снова уплотните
EDIT:
Вы не можете сделать это без установленного Access, но если он просто хранит данные, то декомпиляция не принесет вам никакой пользы. Однако вы можете посмотреть на jetcomp, который поможет вам с уплотнением
support.microsoft.com/kb/273956