Главная » Microsoft SQL Server, Базы данных » Настройка, обслуживание и администрирование

0

Подобно любой реляционной базе данных, находящейся в промышленной эксплуатации, для достижения оптимальной производительности и продолжительной безошибочной работы SQL Everywhere требует настройки и обслуживания. В этом разделе вам будут представлены основные концепции настройки производительности SQL Everywhere; также мы пройдемся по постоянно расширяющемуся множеству методов поддержания производительности и целостности мобильных баз данных. В то время как большинство приложений, в основном выполняющих операции чтения из баз данных SQL Everywhere, могут работать бесконечно долго, не требуя к себе повышенного внимания, те приложения, которые интенсивно извлекают, хранят и синхронизируют данные, требуют как обслуживания, так и периодической подстройки, чтобы в полной мере реализовать свой потенциал.

Измерение производительности выполнения запросов и ее повышение

Естественно, вопрос настройки производительности запросов не может вместиться в рамки рассмотрения настоящей главы. В то же время практический опыт эксплуатации SQL Everywhere указывает на небольшой набор действенных средств повышения производительности.

?               Добавляйте в таблицы SQL Everywhere индексы, однако подходите к этому вопросу избирательно. В составных индексах те столбцы, по которым отбор выполняется чаще, помещайте левее.

?               Замените подзапросы объединениями. Процессор запросов SQL Everywhere всегда переписывает подзапрос IN с помощью объединений JOIN и затем рассматривает совершенно отличный план выполнения.

?               Избегайте объединения больше пяти таблиц.

?               Используйте параметризованные запросы и подготавливайте SqlCeCommands для повторяющихся задач, таких как вставка в таблицу сотен строк.

?               Возвращайте из запросов как можно меньше данных — берите только то, что нужно инструкции SQL и репликации.

?               Для запроса или обновления больше одной строки используйте, когда это возможно, SqlCeResultSet.

?               Денормализуйте базу данных, когда остальные методы не помогают добиться достаточной производительности.

?               Минимизируйте и по возможности даже избегайте ограничений в таблицах.

?               Если база данных SQL Everywhere находится на карте памяти, исследуйте скорость обмена данными карты и не вынимайте ее из устройства, пока существуют открытые подключения к базе данных.

Подробную информацию о вопросах настройки производительности вы можете получить на сайте SQL Server 2005 Performance по адресу http: / /msdn. microsof t. com/sql/ learning/perf/default.aspx.

Благодаря интеграции SQL Everywhere с SQL Server 2005 Management Studio теперь стало возможным просматривать в графическом представлении план выполнения любого запроса DML, производительность которого вы хотите повысить в SQL Everywhere. Выберите в меню утилиты пункт Query1^Display Estimated Execution Plan, и вы увидите графическое представление плана; к тому же при желании вы можете его сохранить в формате XML. Это может оказаться полезным, когда в одном регионе запрос выполняется крайне медленно, а в другом регионе была выполнена его настройка и скорость стала гораздо выше.

Обслуживание SQL Everywhere

Ядро хранилища SQL Everywhere было полностью переработано с целью уменьшения необходимости обслуживания и вероятности повреждения данных, чего так требовал опыт эксплуатации SQL СЕ. Файлы баз данных SQL Everywhere поделены на логические единицы (или “страницы”) емкостью в 4 Кбайт. Во время хранения, индексации и удаления данных на страницах могут оставаться незаполненные участки, а некоторые страницы базы данных могут оказаться и полностью пустыми. Для оптимизации производительности и экономии пространства на устройстве клиента нужно перераспределять неиспользуемое пространство, периодически пересчитывать статистику индексов и очищать буфер транзакций. SQL Everywhere для выполнения этих задач реализует концепции автосжатия, уплотнения и AutoFlush.

Автосжатие

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

Если вы хотите выполнить сжатие файла базы данных вручную, то можете воспользоваться специальным методом объекта SqlCeEngine под названием AutoShrink, выполняющим немедленное сжатие, независимо от текущего объема свободного пространства в базе данных.

Уплотнение

Уплотнение выполняется с помощью метода Compact объекта SqlCeEngine. Он позволяет перераспределить пространство, а также изменить такие настройки базы данных, как пароль, идентификатор региона и шифрование. В отличие от автосжатия уплотнение не только перераспределяет пустые страницы, но и создает полностью новую базу данных, которая имеет следующие преимущества.

1.                              Все индексы создаются заново, а статистика пересчитывается.

2.                              Страницы таблиц реорганизуются в последовательные.

3.                              Столбцы идентичности переустанавливаются так, чтобы следующее доступное значение было на один шаг больше максимального текущего.

4.                              К новой базе данных применяются все изменения пароля, шифрования и/или идентификатора региона.

Приведем пример использования метода Compact в базе данных SQL Everywhere.

Пример на языке C#

string originalDB = "AWMobile.sdf"; string compactedDB = "AWMobile.sdf.tmpM;

SqlCeEngine engine = new SqlCeEngine("Data Source = " + originalDE);

{

engine.Compact("Data Source = " + compactedDB); engine.Dispose();

File.Delete(originalDB);

File.Move(compactedDB, originalDB);

}

catch(SqlCeException e)

{

DisplaySQLErrors(e);

}

finally

{

engine.Dispose();

}

С помощью SQL Everywhere и нового объекта SqlCeEngine среды Compact Framework 2.0 уплотнение может быть выполнено непосредственно в исходной базе. Это значит, что в свойстве Data Source не указывается база данных назначения, вместо этого переписывается исходная база. Таким образом, приведенный выше пример можно преобразовать следующим образом:

string originalDB = "AWMobile.sdf";

SqlCeEngine engine = new SqlCeEngine("Data Source = " + originalDB); try

engine.Compact{); engine.Dispose();

}

catch(SqlCeException e) {} finally {

encrine . Dispose () ;

}

AutoFlush

SQL Everywhere поддерживает транзакции посредством интерфейсов ADO.NET и OLEDBCE. Буфер транзакций содержит изменения, которые ожидают подтверждения транзакций и последующей записи в базу данных SQL Everywhere. Этот буфер гарантирует, что транзакции всегда будут записаны в базу данных в том порядке, в котором они подтверждены. Транзакции могут быть подтверждены, но еще не записаны в базу данных ввиду ненормального завершения программы или блокировок, установленных другими процессами, записывающими собственные транзакции. Интервал времени, в течение которого изменения, хранящиеся в буфере, должны быть записаны в базу данных, в SQL Everywhere можно настроить с помощью параметра Flush Interval строки подключения. В этом параметре определяется максимальное количество секунд, которые должны истечь, прежде чем подтвержденные транзакции будут записаны в базу данных.

Восстановление поврежденной базы данных SQL Everywhere

В ходе эксплуатации SQL СЕ компания Microsoft собирала от разработчиков мобильных приложений сведения об инцидентах повреждения баз данных. В результате она пришла к выводу, что ядро хранилища данных SQL СЕ имеет фундаментальную брешь. Оно не учитывало то, что мобильные устройства имеют кратковременный срок действия аккумуляторов и съемные карты памяти. Как уже говорилось, ядро хранилища данных SQL Everywhere было полностью переписано и теперь обеспечивает безопасность мобильных данных. Любая операция записи в базу данных остается в области теневой копии, равно как применяется и к самой базе данных. Таким образом, в результате потери напряжения или перезагрузки устройства SQL Everywhere гарантирует, что все незаконченные операции будут завершены в нужном порядке и не будут утеряны. В этом разделе мы рассмотрим новые возможности проверки и восстановления баз данных SQL Everywhere, которые разработчик может включить в план обслуживания базы данных.

Проверка

Проверка выполняется с помощью метода Verify объекта SqlCeEngine, который определяет необходимость выполнения восстановления данных. Метод Verify вычисляет контрольные суммы всех страниц базы данных SQL Everywhere и сравнивает их с ожидаемыми. Если эти значения не совпадают, то метод возвращает значение false, указывая, что необходимо выполнить восстановление данных.

Восстановление

Несмотря на то что ядро хранилища данных SQL Everywhere было полностью переписано, чтобы максимально уменьшить вероятность повреждения данных, тот фундаментальный факт, что SQL Everywhere все равно работает на мобильных устройствах, указывает на необходимость обработки ситуации, когда повреждения все-таки произошли. Представьте себе ситуацию, в которой база данных SQL Server 2005 запущена на сервере, а пользователь имеет возможность в течение дня просто отключать питание или извлекать съемные диски, содержащие файлы данных. Базы данных SQL Everywhere часто помещают на съемные карты памяти мобильных устройств, которые потенциально можно извлечь в процессе выполнения транзакции записи. Исходя из этого, рекомендуется периодически проверять базы данных SQL Everywhere и при получении отрицательного результата вызывать метод Repair объекта SqlCeEngine.

К тому же теперь компания Microsoft предлагает два параметра метода Repair, определяющие, что делать, если будут найдены поврежденные данные.

1.     RepairOption.DeletedCorruptedRows. Удалить поврежденные строки из базы данных SQL Everywhere.

2.     RepairOption.RecoverCorruptedRows. Выполнить попытку прочитать данные с поврежденной страницы, однако успех операции не гарантирован. К тому же, даже если удалось восстановить одну или несколько строк, нет никакой гарантии, что в базе данных не осталось логических повреждений. Как бы там ни было, наличие дополнительного варианта действий все равно является шагом в правильном направлении.

Следующий фрагмент программного кода иллюстрирует, как два описанных выше метода работают совместно. В процессе обслуживания базы данных SQL Everywhere рекомендуется выполнять подобные программы еженедельно или после определенного количества запусков приложения.

Пример на языке 0#

SqlCeEngine engine = new SqlCeEngine("Data Source = AWMobile.sdf"); if (!enaine.Verify())

{

Cursor.Current = Cursors.WaitCurscr;

engine.Repair(null, RepairOption.RecoverCoiruptedRows);

Cursor.Current = Cursors.Default;

MessageBox.Show("База данных SQL Everywhere Database была восстановлена.");

}

Поддержание производительности репликации слияния

Репликация слияния является хорошим вариантом синхронизации баз данных SQL Everywhere и SQL Server 2000/2005. Несмотря на то что производительность репликации слияния может быть исследована в мониторе репликаций утилиты Management Studio, существует естественная необходимость периодически выполнять ее обслуживание, чтобы поддерживать оптимальную производительность. На практике большое количество корпоративных мобильных реализаций обнаруживали быстрое и существенное падение производительности репликаций слияния уже после нескольких дней обслуживания 20-30 подписчиков.

Чтобы всегда поддерживать производительность репликаций слияния на должном уровне, нужно периодически выполнять три основные задачи настройки и обслуживания.

1.              Как можно чаще дефрагментировать все индексы таблиц Distribution .Msmerse_* (желательно каждую ночь).

2.              Уменьшить период сохранения снимков (по умолчанию он составляет 14 дней), если модель использования приложения это позволяет.

3.              Увеличить число генераций в каждом пакете на сервере.

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

Более подробную информацию о настройке и обслуживании репликации слияния вы можете получить на сайте:

www.microsoft.com/technet/prodtechnol/sql/2 000/maintain/mergperf .mspx

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии