Секционирование и высокая доступность

Секционирование и высокая доступностьАвтор: Alexey Knyazev

Секционирование (partitions) — один из основных инструментов для обеспечения оптимальной работы с большим объёмом данных за счёт горизонтального масштабирования. Повышается управляемость и производительность, как модификации данных, так и запросы на выборку.
Кроме того, можно повысить производительность, применяя блокировки на уровне секций, а не всей таблицы. Это может уменьшить количество конфликтов блокировок для таблицы.

Но не все обращают внимание на ещё одну уникальную возможность, которую предоставляет секционирование, а именно: обеспечение высокой доступности данных. Сокращает время восстановления после сбоев.

Для демонстрации создадим тестовую БД:


Теперь к нашей новой БД добавим несколько файловых групп, каждая из которых будет состоять из одного вторичного файла данных (*.ndf):

Теперь наша БД состоит из 13 файловых группы: первичной и 12 вторичных


Файлы:


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


Обратите ваше внимание, что все данные, которые будут с датой < 2012 и > 2012 года расположатся в файловой группе primary.

Ну, а теперь создадим нашу наиважнейшую таблицу, которая будет содержать информацию о продажах за 2012 год. При этом к этим данным выдвигаются очень серьёзные бизнес-требования в плане доступности.


В результате у нас таблица с 14 секциями, 12 из которых содержат данные…в нашем случаи по 10000 строк:

Т.к. у нас каждая секция хранится в отдельной файловой группе, то мы можем создавать резервные копии не только всей БД, но и отдельно для каждой файловой группы.
Следующим скриптом мы создадим 12 резервных копий файловых групп:


Теперь сэмулируем аварию, для этого внесем изменения в одну из файловых групп через любой текстовый редактор. Но прежде необходимо отключить нашу БД (sp_detach_db) или остановить SQL Server, т.к. иначе файлы БД нельзя отредактировать.

Теперь внесём изменения в один из файлов БД, например в файл C:\temp\fg7.ndf. В качестве редактора я использую Far Manager.

Нам достаточно изменить всего один символ, чтобы наша БД не прошла проверку контрольной суммы. За эту проверку отвечает параметр БД PAGE_VERIFY = CHECKSUM (значение по умолчанию и если вы его не меняли, то вам не стоит о нём беспокоиться), более подробно об этом можно прочитать по ссылке —http://msdn.microsoft.com/ru-ru/library/bb522682.aspx.

Теперь подключим нашу базу:

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

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

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x95830087; actual: 0x959e8087). It occurred during a read of page (9:8) in database ID 5 at offset 0x00000000010000 in file ‘C:\temp\fg7.ndf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

При этом данные из других файловых групп доступны для работы

Т.е., не смотря на битые данные в одной из секций, мы продолжаем работать с остальными данными в обычном режиме. Теперь попытаемся восстановить нашу «битую» файловую группу в режиме ONLINE, т.е. без остановки работы с другими данными.
Начинаем всё с переключения нашей ФГ (файловой группы) в режим OFFLINE

Теперь посмотрим статусы файловых групп:

Теперь, при обращении к нашей ФГ, мы получим уже другую ошибку

One of the partitions of index » for table ‘dbo.sales'(partition ID 72057594039500800) resides on a filegroup («FG7») that cannot be accessed because it is offline, restoring, or defunct. This may limit the query result.

Далее выполним само восстановление FG7

Статус нашей ФГ изменился с OFFLINE на RESTORING.

Последним шагом необходимо сделать копию журнала транзакций и восстановить его с параметром RECOVERY.

После этого статус ФГ сменится на ONLINE и все данные нашей таблицы вновь доступны. Мало того, что на протяжении всего этого времени вся наша БД была в полном доступе для пользователей (за исключением данных в FG7), так мы ещё и восстановление произвели в разы быстрее, чем если бы производили поднятие базы из полной резервной копии. Поэтапное восстановление более подробно описано по ссылке —http://msdn.microsoft.com/ru-ru/library/ms177425.aspx

Но теперь мы проведём более серьёзный тест и удалим одну из файловых групп, но прежде сделаем новую резервную копию нашей файловой группы, которую будем удалять:

Теперь остановим службу SQL Server, удалим файл C:\temp\fg7.ndf и вновь запустим службу SQL Server.

Обратимся за подробностями к логу

И так: наша база данных повреждена т.к. нет доступа к одному из файлов. Первым делом нужно вернуть БД в оперативный доступ. Для этого необходимо перевести в OFFLINE одну ФГ, файл которой «пропал», а всю базу перевести в ONLINE-режим.

Далее восстановление очень похоже на то, что мы делали ранее

Запись опубликована в рубрике Секционирование с метками . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Войти с помощью: