у нас есть активный / активный кластер sql server 2008, работающий на wondows 2008R2 O / S. 14 ГБ оперативной памяти, 4xCPU. мы установили потолок в 12 ГБ для sql server. Мы выполняем задание агента, которое загружает в базу данных 3 миллиона записей. во время этой загрузки задание не выполняется, и кластер, кажется, пытается переключиться на другой узел, но безуспешно, т.е. адрес кластера больше не доступен. мы должны вручную вернуть узел кластера из строя.
во время загрузки при просмотре диспетчера задач мы видим, что использование памяти достигает максимум 12,5 ГБ, а ЦП иногда достигает 100% на всех 4 ЦП, но по большей части колеблется в среднем около 60%.
Я полагаю, мой вопрос: попытается ли кластер переключиться, если память или процессор сильно пострадают? или я лаю не на то дерево? также есть идеи, почему он не полностью отказал? мы просмотрели логи, которых много, и не нашли ничего полезного. мы также пытались воссоздать проблему, но позже она успешно сработала. Также 3 миллиона строк не кажутся много, но с точки зрения ресурсов должно быть недостаточно 14 ГБ ОЗУ и 4xCPU?
Дополнительная информация по этому поводу, мы снова запустили загрузку сегодня и испортили базу данных!
Мы получили сообщение об ошибке: LogWriter: ошибка операционной системы 170. Похоже, что при большой нагрузке кластер sql попытался выполнить отработку отказа, и при этом был перенесен lun (или диск), что означало, что диск больше недоступен. (это всего лишь наша теория). База данных теперь «подозрительна» и требует восстановления.
Вышеупомянутая ошибка 170 также указывает на то, что при переключении на другой узел служба sql не могла запуститься, поскольку она уже использовалась, поэтому она не могла полностью переключиться при отказе ?? Но мне интересно, зачем вообще нужно переключаться при отказе?
Мои предположения могут быть совершенно ошибочными, поэтому любые идеи будут оценены.
Если процессоры блокируются (т. Е. Все работают на 100%), рассмотрите возможность проверки параметра Maxdop в SQL Server в качестве временной меры стабилизации - это доступно через графический интерфейс на уровне сервера или дополнительные параметры sp_configure. По умолчанию он должен быть установлен на 0 - и это нормально.
Возможно, вы захотите изменить maxdop на 3, 2 или 1 - как попытку стабилизации, чтобы улучшить ситуацию. Он динамический, но помните, что любые процессы, выполняемые на нескольких ядрах (параллельно!), Могут занять больше времени.
Если это положительно, значит, вы выиграли время, чтобы найти настоящую первопричину, которая возникнет после более подробного изучения рабочей нагрузки.