Почему зеркало базы данных выходит из строя после изменения настроек группы файлов с RESTRICTED_USER на MULTI_USER?

9

Моя среда выглядит следующим образом: VMWare 5.5 витализованный сервер MS Windows Server 2008R2 Enterprise domain и SQL Server 2008 R2 Enterprise . Централизованное хранилище с оптоволоконным соединением.

У меня есть разделы в моем SQL Server DB. У меня есть 2 file groups: один с живыми данными (FG1) , второй с историческими данными (HDG) .

Вторая группа файлов read-only. Каждый месяц я делаю движения в разделах - я добавляю новые данные (из предыдущего месяца) в исторические данные. Этот процесс автоматический .

Мы перенесли нашу базу данных на новый сервер. Первоначально я должен был сделать процесс вручную . Во время этой операции мое зеркало ломается (после операции 3 - см. Поток процесса ниже) со следующей ошибкой:

НА ОСНОВНОМ СЕРВЕРЕ:

Строка 0 в журнале:

Date        15.6.2015 20:54:11
Log     SQL Server (Current - 16.6.2015 07:55:00)

Source      spid84

Message
Setting database option MULTI_USER to ON for database MYDB.

Строка 1 в журнале:

Date        15.6.2015 20:54:11
Log     SQL Server (Current - 16.6.2015 07:55:00)

Source      spid18s

Message
Error: 1453, Severity: 16, State: 1.

Ряд 2 в журнале:

Date        15.6.2015 20:54:11
Log     SQL Server (Current - 16.6.2015 07:55:00)

Source      spid18s

Message
'TCP://10.201.27.154:5022', the remote mirroring partner for database 'MYDB', encountered error 823, status 3, severity 24. Database mirroring has been suspended.  Resolve the error on the remote server and resume mirroring, or remove mirroring and re-establish the mirror server instance.

ЗАМЕЧАНИЕ: Я выполнял эту операцию на старом сервере много раз автоматически и никогда не сталкивался с такой ошибкой.

НА ЗЕРКАЛО СЕРВЕР:

Строка 1 в журнале:

Date        15.6.2015 20:54:11
Log     SQL Server (Archive #3 - 15.6.2015 21:33:00)

Source      spid17s

Message
Error: 823, Severity: 24, State: 3.

Ряд 2 в журнале:

Date        15.6.2015 20:54:11
Log     SQL Server (Archive #3 - 15.6.2015 21:33:00)

Source      spid17s

Message
The operating system returned error 5(Access is denied.) to SQL Server during a write at offset 0000000000000000 in file 'e:\Databases\MYDB_HISTRICAL.ndf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level 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.

МОЙ ПРОЦЕСС СЛЕДУЕТ

1. Я делаю несколько резервных копий базы данных (полная, файловая группа и резервная копия TLog).

2. Я установил БД в RESTRICTED_USER(чтобы разрешить удаление только для чтения исторического флага группы файлов по сценарию).

2а. Я удаляю READ-ONLYфлаг моей Исторической Файловой Группы.

3. Я установил БД, чтобы MULTI_USERразрешить нормальную работу нашего программного обеспечения.

4. Я обновляю разделы, чтобы данные перемещались в историческую файловую группу.

5. Я повторяю шаги 2 , 2a и 3, чтобы снова установить историческую группу файлов READ ONLY.

6. Я делаю резервные копии снова.

У кого-нибудь есть идея, почему я получаю эту ошибку?

РЕДАКТИРОВАТЬ: Мы получаем ту же проблему на разных этапах процедуры. Это единственная ситуация, в которой зеркало ломается, поэтому я полагаю, что проблема в процедуре, но я не могу понять, почему!

Богдан Богданов
источник
Error: 823, Severity: 24Кажется аппаратная проблема. Проверьте свои диски, чтобы увидеть, не испортились ли они. Запустите checkdb для баз данных, чтобы убедиться в их чистоте.
Кин Шах
Я не уверен, @Kin. У нас есть совершенно новое специализированное оптическое хранилище IBM. Работает около 3 месяцев. И это был единственный раз, когда мы получили такую ​​ошибку. На самом деле есть около 10 строк с этой ошибкой, но все они произошли в течение этого периода времени. Мы уничтожаем зеркало и создаем его снова. У нас есть проблема, чтобы удалить зеркало. Поэтому мы удаляем его вручную.
Богдан Богданов
Ошибка 823 with sev 24- это аппаратная проблема. Делаете ли вы резервные копии на уровне файлов вместо собственных резервных копий SQL Server, или на сервере работает какое-либо антивирусное программное обеспечение? Вы должны поставить оповещения агента SQL, чтобы предупредить вас, когда происходит ошибка 823 - этот скрипт поможет вам . Кроме того, 823 - это неприятная ошибка - он говорит, что операция ввода-вывода завершилась неудачно на уровне ОС, а подсистема ввода-вывода вызывает повреждение - сервер sql не выполнил проверку страницы
Кин Шах,
Мы делаем резервные копии обоих типов, @Kin. Мы также имеем VmWare replicationк remote host. То, что я заметил, пока не написал вам ответ, это то, что мы не можем уничтожить зеркало обычным способом. Файл был заблокирован, и нам нужно stop SQL serviceи для перемещения файлов БД в другой каталог. С этого момента все в порядке (проверяю логи используя sys.xp_readerrorlog). Другая мысль заключается в том, произойдет ли репликация VmWare в тот же момент, но я не уверен, как это повлияет на процесс (я мало знаю о нем VmWare).
Богдан Богданов
We do both type of backupsэто может быть проблемой. Снимки виртуальных машин не должны использоваться в качестве альтернативы собственным резервным копиям сервера SQL.
Кин Шах

Ответы:

0

Мы нашли проблему. Это ошибка в SQL Server. Когда мы READ_WRITEзадаем команду, она не передается должным образом в mirrorБД. При изменении запуска скрипта partitionsна зеркальном сервере произошла ошибка. После этого синхронизация разрушается и БД на зеркале блокируется (в suspendedсостоянии).

Мы исправили проблему, обновив SQL Server до последней версии (наша первоначальная версия была без SP).

Богдан Богданов
источник