устранение коррупции в файлах базы данных SQL Server Compact Edition

Это не запрос. Это сводка нашего решения, чтобы обойти проблему коррупции в файлах SQL Compact Database с (почти) определенным успехом. SQLCE Коррупция – очень распространенная проблема. Мы получили огромную помощь от более ранних сообщений в StackOverflow и, следовательно, этого сообщения.

Наш продукт представляет собой трехуровневую архитектуру с сервером, работающим как служба Windows, подключенную к Rich Клиентам через .Net Remoting. Наш продукт использует SQLCE с 2006 года. Мы перешли с v3.1 на v3.5 и теперь на v4.0. У нас есть пользовательский инструмент OR-Mapping для некоторых очень специфических требований. Мы столкнулись с ограниченными проблемами с v3.1, мы больше столкнулись с v3.5 и v4.0.

Первоначально с v3.5 мы реализовали SqlCeEngine.Repair . Но он только снижает поврежденные данные и пытается воссоздать стабильный db. Мы обнаружили, что foreign keys затронутых таблиц пропали. Мы должны были немедленно устранить это. Мы начали уведомлять пользователей о повреждении db и восстанавливать последнюю резервную копию. Это обеспечило лишь временное облегчение; проблема коррупции все еще сохранялась.

В этом году мы приняли v4.0. Однако наше приложение также представило несколько новых функций, которые значительно увеличили количество вызовов в базе данных. v4.0 начался хорошо, но начал давать проблемы при увеличении использования программного обеспечения. Повреждения, возникающие во время работы приложения, не вызваны сбоем Windows, ненормальными остановками или проблемами с диском. База данных просто повреждена.

В следующей статье мы рассмотрим решение, которое мы разработали для этой проблемы:

[Разделение запроса и решение]

Вот как мы решили проблему:

A) Закрытие / удаление объектов Connection / Command / Transaction: Мы гарантировали, что неиспользуемые, незаблокированные объекты соединения, транзакции или команды отсутствуют. Наш инструмент ORM, используемый для создания новых объектов после вызова фиксации транзакции, которые в некоторых случаях лежали без дела. Это значительно сократило количество коррупции на 50%.

B) Отключение автоматического сжимания: единственная процедура, выполняемая в середине запуска приложения, над которой мы не контролировали, была автоматической сжиманием. При запуске приложения мы вызывали SqlCeEngine.Compact. Мы решили покончить с компактированием и автоматическим сжиманием. И к нашему удивлению, мы уменьшили коррупцию еще на 48%. Это был выстрел в темноте, и мы не могли поверить, что автоматическое сжимание могло вызвать такие проблемы. Мы практически решили проблему с этим обновлением.

C) Синхронизированные транзакции базы данных: некоторые повреждения базы данных все еще происходят. При отсутствии четких причин мы решили синхронизировать транзакции базы данных! Я знаю, что многим людям с базами данных не понравится. Мне тоже это не нравится. Мы вводили блокировки в нашем среднем уровне, чтобы гарантировать, что только один вызов изменяет базу данных одновременно. Наша самая большая реализация – 55 клиентов одновременно с использованием нашей системы. Синхронизация вызовов базы данных вряд ли приводила к какой-либо видимой задержке производительности. Скорее, Синхронизация позволила нам осуществлять регулярный вызов по таймеру SqlCeEngine.Compact с регулярными интервалами. Мы знали, что Компакт не был виновником, и мы чувствовали, что Compaction является необходимым вызовом, поскольку он повторно индексирует db (наше решение делает много вложений и удалений). Однако он должен функционировать исключительно; при вызове компакт-диска нет вызовов в базе данных. Синхронизация позволила нам контролировать это во время запуска приложения. Поскольку мы это сделали, мы не получили ни одной проблемы с повреждением базы данных. Его было больше месяца. От почти 5 клиентов в неделю, до нуля в месяц.

Основным аргументом, который привел нас к идеям B и C, является то, что SQLCE является встроенной базой данных. Коррупции являются общими для каждого встроенного решения для баз данных. Полномасштабные решения для баз данных работают независимо друг от друга с помощью управления соединениями и другими задачами с интерфейсом 24×7 db-сервера. Встроенная система баз данных не имеет такой системы поддержки. Единственный этап, когда он жив, – это когда соединение открывается.

Еще несколько указателей: 1) Мы реализуем фиксацию с CommitMode.Immediate, что делает избыточное свойство Flush-Interval избыточным. 2) AutoShrink установлен в 100, что полностью отключает процедуру. 3) Я увеличил тайм-аут подключения, чтобы обеспечить бесперебойную работу синхронных вызовов базы данных. 4) При вызове приложения вызывается Compact. В тех случаях, когда клиенты вообще не выключают свою машину, мы использовали таймер для вызова Compact каждые 24 часа.

Надеюсь, что этот пост помогает решить проблемы.

При использовании SQL Server CE 4.0 существует известная проблема, которая может помешать сбросу данных на диск (AT ALL). https: // support /

Своими словами:

Предположим, что вы указали интервал очистки в максимальном количестве секунд в строке соединения, прежде чем совершенные транзакции будут сброшены на диск в Microsoft SQL Server Compact 4.0. В этой ситуации фиксированные транзакции могут занимать гораздо больше времени, чем интервал очистки, который должен быть сброшен на диск или даже не может быть сброшен на диск. Кроме того, потеря данных происходит, если есть ненормальное завершение программы.

Исправление, устраняющее эту проблему, включено в пакет исправлений исправления по требованию для SQL Server Compact 4.0 с пакетом обновления 1 (SP1).

Обходной путь заключается в использовании transaction.Commit(CommitMode.Immediate) вокруг блока, который вы хотите удостовериться,

Interesting Posts
Давайте будем гением компьютера.