Для понимания парадоксальности ситуации — на обоих серверах развернута одна и та же база (с одного и того же файла backup'a). В этой базе порядка 600 таблиц. Те 5-6 которые ведут себя удивительно ничем не отличаются от десятков подобных (по структуре и количеству записей) с которыми такой проблемы нет. На обоих «серверах» — Windows 10 с последними обновлениями (это сервера разработок, а не продуктивные). На обоих SQL Server'ах последние сервис паки (без hot fix'ов). Никакие специальные «режимы» (trace flags и пр.) SQL Server'ов не включены.
Загадка сия была велика, но мой коллега ее решил. Вы даже знаете как…
Он перезагрузил компьютер с 2016 SQL сервером. После этого все «рецидивы» ушли. Как!? А точнее «Доколе!!!!!!!» хочется воскликнуть мне.
Чего мы только не делали. Каким «шаманствам» не предавались, чтобы объяснить это странное и абсолютно нелогичное поведение. Мы перестраивали индексы и изменяли типы данных (у нас в одной из этих «проблемных» таблиц был тип данных помеченных как «устаревший» в 2016, то, что он же применяется и в других «не проблемных» таблицах нас уже не останавливало), рассчитывали количество записей на странице и сравнивали размеры страниц SQL серверов, повышали версию совместимости базы данных и перестраивали статистику и прочее, прочее, прочее.
Очередная проблема с Windows, которая решилась как в том классическом анекдоте, «А вы не пробовали просто выйти и снова войти?».
Вдруг машина заглохла.
Техник вылез, открыл капот, стал там копаться.
Бизнесмен достал свой мобильный телефон и стал вызывать
техпомощь.
Программист удивленно посмотрел на них и спросил:
— Ребята, а вы не пробовали просто выйти и снова войти?
Внимательный читатель (и поборник Microsoft) должен меня сразу уличить, что я де «передергиваю». Я использую для сервера базы данных не серверную операционную систему (Windows 10). Проблема понятна — это же desktop (!!!!!!!) операционная система, а вот в Windows server'ах, естественно, такой проблемы нет.
Спешу вас расстроить — я с завидной регулярностью наблюдаю подобные «выкрутасы судьбы» и на Windows серверах.
Кто виноват!?
Ну, Вы знаете — Windows Updater. Он там себе в фоне что-то устанавливает и все надеятся, что «прокатит». Я имею в виду, что если заменить без перезапуска часть исполняемых файлов операционной системы, некоторые настройки и т.д. (все то, что делает любое обновление ПО), то это может непредсказуемым образом сказаться на процессах, которые уже выполняются и которые невозможно незаметно перезапустить (как в моем случае с SQL Server'ом). Обновление исполняемых файлов и библиотек, которые уже загружены в память сервера, будет отложено, скорее всего, до перезагрузки компьютера, а вот все прочее — загадка. Как мне видится, фоновое обновление Windows всегда будет приводить к подобным «сюрпризам».
Проблема, в общем-то, стара как мир. Первый раз я с таким последствиями Windows Updater'a столкнулся в далеком 2007 году, кажется. С тех пор ничего, к сожалению, радикально не улучшилось. В оправдание Windows Updater'а скажу, что я как-то наблюдал как коллега на заре 2000-х установил в обеденный перерыв service pack на Windows Server и не смог перезагрузить сервер до конца рабочего дня. Интересные эффекты наблюдались :)
А могло ли быть иначе?
Возможно, если бы исполняемые файлы были «самодостаточными» — т.е. включали в том либо ином виде копии всех библиотек, которые они используют (за исключением самых низкоуровневых). Обновления операционной системы были не фоновыми… и мы возвращаемся в мир ранних версий Windows когда все(?) обновления «откладывались» до перезагрузки, пользователи не дожидались окончания установки обновлений и выключали компьютерыи в результате оказывались с незагружаемыми «операционками».
Т.е. скорее всего для серверных решений можно найти вариант решения — обновление всего по команде и с ведома «админа», а для «desktop'ов» мы наблюдаем «наименьшее из зол».
У меня Windows Update отключен!
Как говорится, «Если у вас паранойя — это не значит, что за Вами не следят». Я к тому, что чем дальше, тем сложнее и сложнее отключить Windows Updater. Даже в выключенном состоянии (я про «Панель Управления») Windows устанавливает «критические обновления» (в том числе на серверные операционные системы).
Я настоятельно рекомендую всем для серверных решений отключить авто-обновление Windows, но при этом выполнять его регулярно «в ручном режиме», как это делается в Unix подобных операционных системах. Я про пакетные менеджеры apt, yum или тот же brew для OSX. Если нечто подобное есть для Windows серверов и обновлений — расскажите мне об этом пожалуйста.
Хочу напомнить, что даже если у вас на windows сервере нет доступа в Интернет, то Windows Update может «утягивать» обновления по локальной сети (зараза такая).
Ха, это все проблемы Windows...
Не совсем. Критические обновления без вашего ведома на рабочие станции — «раскатывают» многие поставщики. Тот же Apple, если я ничего не путаю (речь не об уведомлениях для которых нужно что-то нажать в App Store'e, а о том, что без Вашего ведома было установлено). Ссылка.
Надеюсь, никто кроме Microsoft не устанавливает без ведома админа обновления на сервера.
В принципе, я наблюдал «свистопляски» еще и похлеще под Unix, когда «кривой» пакет принесенный apt-get'ом не остановил старый instance сервиса и заменил исполняемые файлы. О том, что дело в «косяке» обновления пакета и сервис до обновления нужно остановить я догадался после второго восстановления сервера из backup'а (благо это была «виртуалка» и делалось это в пару кликов).
Какие из всего этого мы можем сделать выводы?
Я бы не стал использовать серверные решения Microsoft без веских на то причин (я не об active domain или там file/print сервере), а про сервисы, которые должны работать 24x7. Скажу только, что за последний год я помню минимум три ситуации, когда проблемы с нашими системами решались перезапуском ОС (это все были windows server'ы разных версий с отключенными автообновлениями). Нет, у нас не «течет память». Нет, перезапуск наших серверов приложений не решал проблемы. А как вам ситуация когда операция сравнения дат перестает корректно работать для некоторых значений? Я, к сожалению, это наблюдал в этом году. Почему мы (иногда) используем на серверах приложений операционные системы Windows — это требование заказчика.
Доктор, я делаю так и у меня болит — не делайте так!
А как же тот самый SQL Server с которого начался этот монолог? Как с ним быть!? Ответ прост — SQL Server 2016 on Linux. Мне, как и многим, наверное, пока страшно его запускать в «промышленную эксплуатацию», но если есть у кого-то подобный опыт с ним — поделитесь, пожалуйста.
Комментарии (27)
LoadRunner
20.12.2017 10:48Если нечто подобное есть для Windows серверов и обновлений — расскажите мне об этом пожалуйста.
Ну хотя бы WSUS (ибо бесплатен для Windows Server), если речь идёт не о домашнем пользователе.
FoxyBOA Автор
20.12.2017 11:02Спасибо, гляну. Речь именно о мелком бизнесе или корпоративе, чтобы обновления windows «накатывать» на «боевые» сервера по «зеленому свистку», а не как он там себе решит.
dmitry_dvm
20.12.2017 13:37Старая песня об обязательных обновлениях.
Ребят, ну сколько можно, я один что ли знаю об этом параметре? Вин-админы не знают о групповых политиках? Доступна на всех вёндах кроме Home.
Заголовок спойлера
FoxyBOA Автор
21.12.2017 13:05Спасибо. Тестируем насколько статус disabled сделает нашу жизнь проще. В оправдание свое могу сказать, что админом, а тем более виндовым, я не был никогда. Скорее я Java developer :)
Еще раз спасибо!
Fox_exe
20.12.2017 10:51Я использую для сервера базы данных не серверную операционную систему (Windows 10).
Ну это мало на что влияет — Ядро у них (с 2016 server) одно и тоже, как и все драйвера и службы и многое другое. Отличия лиш в большем функционале сервера, да в некоторых настройках.
greeensnake
20.12.2017 11:02Субъективно, качество кода в 2016-м упало по сравнению с 2012 R2, то что стабильно работало в 2012 R2, стало валиться в 2016-м самым неожиданным образом.
Fanta
20.12.2017 12:38приведите, пожалуйста, примеры!
Давно юзаю обе версии и такого не встречал.greeensnake
20.12.2017 13:15Шареные диски для виртуальных машин Hyper-V нормально не работают по Linux, был заведен кейс в MS еще летом — проблему признали но до сих пор не решили.
Кластер Hyper-V нестабильно работает с CSV томами при создании снапшотов на томах, если у вас в кластере ноды с разными уровнями апдейтов
AlanDenton
20.12.2017 11:32SQL Server 2016 on Linux. Мне, как и многим, наверное, пока страшно его запускать в «промышленную эксплуатацию», но если есть у кого-то подобный опыт
Пока ничего хорошего на Linux для SQL Server не предвидится. Вот один из простых примеров. И таких радостей, по правде, уже накапливается много. Возможно через пару кумулятивных обновлений все станет лучше, но пока что-то серьезное на SQL Server под Linux делать я бы не рискнул.
В плане статьи, поддержу мнение, что Updater подлые вещи иногда делает. Но что мешает в момент установки все настроить? Отключить обновление, телеметрию на уровне SQL Server и системы в целом. И тогда подобных сюрпризов будет по минимуму. Опять же не берем во внимание Azure — он живет по другим правилам.
mpakep
20.12.2017 11:38Использовать продукты Майкрософта на линуксе это еще большее зло. Речь не идет о том, чтобы тащить все эти недостаточно стабильные продукты в стабильную операционную систему а о том, чтобы начать смотреть шире. Мир не ограничивается Майкрософтом и когда начинаешь это понимать удивляешься как жил раньше.
IT_pilot
20.12.2017 11:55У меня долгое время не вставал Azure Pack. Ничего не помогало. В итоге забил. Через месяца три пришли обновления. Установил на все сервера. Просто так запустил Azure. Сразу заработало.
А про то, что нужно сначала перезагрузить если что-то не работает, так это само собой. Начальная школа как говорится.
acmnu
20.12.2017 12:16Я имею в виду, что если заменить без перезапуска часть исполняемых файлов операционной системы, некоторые настройки и т.д. (все то, что делает любое обновление ПО), то это может непредсказуемым образом сказаться на процессах, которые уже выполняются и которые невозможно незаметно перезапустить (как в моем случае с SQL Server'ом).
В общем-то, это не столько проблема Windows, сколько концептуальная проблема. В Linux разве что контроль за такими вещами как обновление и рестарт более полный. Концептуально это решается например с помощью Docker, но там не все хорошо именно с базами данных.
FoxyBOA Автор
20.12.2017 12:28Я понимаю и пишу, как мне кажется, об этом же. Т.е. для всех серверов с задачами 24x7 не может быть процессов автоматического обновления (в том числе для критических обновлений безопасности и пр.) иначе имеем весь этот «зоопарк».
acmnu
20.12.2017 12:51Тут ещё зависит от дистра Linux. Например в Debian обновление автоматически рестартует затронутые сервисы, в отличии от RHEL, где так делать не принято (хотя можно). Соответственно если сервис не критичен к небольшому простою, то секьюрити патчи можно и нужно ставить автоматом. Ну а 24х7 это совсем отдельная тема. Мне кажется там сразу нужно думать о кластеризации.
Alozar
20.12.2017 12:29В целом 2016 «отдает» данные в 2-5 раз быстрее, за исключением некоторого набора таблиц, для которых 2012 работает быстрее в 1,5-2 раза.
У нас аналогичная ситуация.
Дело в оптимизаторе запросов, который был сильно переработан с в 2014 версии, и были изменены принципы оценки селективности данных. В большинстве случаев это улучшило производительность запросов, но в некоторых случаях привело к обратному эффекту, с чем соглашается сам Microsoft в своих статьях (например тут). Решения проблемы два: переписывать запросы и индексы, либо принудительно включать использование старого оптимизатора запросов на уровне базы или конкретного запроса)
ildarz
20.12.2017 14:19Не смогли разобраться с нетривиальной проблемой — ладно, бывает. Но после более чем десяти лет работы (судя по упоминанию 2007 года) с серверными решениями на винде и "проблем" с обновлениями ничего не знать WSUS, GPO и т.п., зато писать статьи "винда-отстой" — это, конечно, сильно. Старая добрая традиция — в чем не разбираешься, то и отстой. :)
Я настоятельно рекомендую всем для серверных решений отключить авто-обновление Windows, но при этом выполнять его регулярно «в ручном режиме»
На всех десятках/сотнях/… серверов. Регулярно в ручном режиме, ага. Нет, спасибо, мы как-нибудь настройкой автообновления в нужное нам время на нужные сервера обойдемся. Может быть, даже с тест-группой, чтобы поглядеть, не поломается ли чего после обновлений.
Хочу напомнить, что даже если у вас на windows сервере нет доступа в Интернет, то Windows Update может «утягивать» обновления по локальной сети (зараза такая).
Не может. Без доступа к Windows Update/WSUS обновляться ничего не будет, вне зависимости от того, включена возможность скачивания обновлений от "соседей" или нет.
IT_pilot
20.12.2017 16:58WSUS с его политиками и группами обновлений защищает лишь от явных багов.
Только вчера у одного сервера после обновления отвалилась сеть. Остальные нормально перенесли. Зашел на этот один сервер и удалил обновления.
И при чем здесь WSUS?
С кластерами кстати все проще — обновил одну ноду: работает. Точно? Ага. Ок, обновляем вторую. А не работает, так роль живет на второй ноде. И есть время покопаться в первой и найти злоумышленное обновление.
ildarz
21.12.2017 13:28Проблема не в том, от чего защищает или нет WSUS, а в том, что люди не осознают границы собственной компетентности и, как следствие, делают какие-то выводы в областях, в которых не разбираются, после чего оформляют свои выводы в виде статьи на ресурсе, который вроде как технический, но при этом статья ухитряется сохранить положительный рейтинг (что в целом весьма характеризует нынешнее состояние отрасли, к сожалению). В результате плодятся статьи вида "мы тут поплясали с бубном, потом призывали духов, и только святой ребут откликнулся на наши мольбы", что делает положение вещей еще печальнее. :)
FoxyBOA Автор
21.12.2017 14:31Как любая статья, эта, в том числе, субъективна и отражает как мое мнение, так и те наблюдение которые я делаю в тех областях в которых, скорее всего, не настолько компетентен как ildarz. Я просто не понимаю, почему для того чтобы все работало на серверах мира Windows и которыми управляют наши партнеры в разных точках этого мира (и в разных организациях) нужно время от времени «трясти бубном». Я просто вижу, как периодически выходит очередное обновление (которого как бы не было и которое никто не ставил) и кому-то из моих коллег в службе технической поддержки приходится говорить слова в стиле «А вы не пробовали просто выйти и снова зайти?». Эти шаманские тряски с бубном очень странные и я их (почему-то) не наблюдаю в альтернативных вселенных Microsoft (может просто плохо смотрю или у меня мало данных). Хотелось бы, чтобы и в том мире в котором так много «живых людей» также все было хорошо и все работало просто «из коробки».
zeronice
21.12.2017 15:15АБС на SQL 2014 на Win2012R2, работает месяцами. Это как пример и в духе статьи.
На деле же вместо предложения даже не попробованного вами — стоило провести тесты производительности, выяснить на каких операциях проблемы. Да план запроса хотя бы показать, что ли… "отдавать данные" — это растяжимое понятие.
По поводу обновлений. А кто их накатывает не контролируя в ответственных средах?
mpakep
На дворе 2017. Вы все еще используете виндоуз?
SirEdvin
Присоединяюсь к вопросу. С# вроде уже тоже везде завезли. Зачем вам windows?
FoxyBOA Автор
У нас не только cloud решения. Иногда нужно «развернуть» с-мы у заказчиков и они (очень часто) хотят windows. В ситуациях, когда твой софт работает месяцами, а потом приходит Windows Updater и «приваливает все» — это бесит.
Когда мы можем «продавить» linux — мы это делаем, но это вопрос не ИТ, а уже политический.