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

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

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

Ответ 1

[Отделив запрос и решение]

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

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

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

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

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

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

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

Ответ 2

При использовании SQL Server CE 4.0 существует известная проблема, которая может помешать сбросу данных на диск (AT ALL). https://support.microsoft.com/en-us/kb/2979868 и исправление https://support.microsoft.com/en-us/kb/2960153 p >

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

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

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

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