MS SQL Server - дело тонкое...


DevOps or not DevOps

Драгоценные вы мои коллеги! Много в последние дни стали говорить о неких новых вершинах роста развития разработчика и админа. Всё чаще и громче звучит хор разного уровня менеджеров – блогеров (вот последний попавшийся мне на глаза пример: 5 challenges to scaling DevOps at enterprise level) о том, что сферу IT технологий должны наполнить «супер герои», и таким может стать каждый. С чей-то «лёгкой руки» скрестили два (а то и три, если считать управленцев) ортогональных направления IT-проекта, разработку и администрирование. Почему это сделали – понятно. Так проще загонять работы в неверно установленные рамки (тассочки вовремя закрывать, а то премию не дадут). А что бы «старпёры» (такие, как ваш покорный слуга) не «воняли», придумали слоган, что только таким путём можно вовремя реагировать на ставшее почему-то быстрым преобразование бизнеса в эпоху информационных технологий.
И вот перед нами предстаёт он – DevOps, великий и могучий. Давайте рассмотрим его под «лупой». Первое, что бросается в глаза, это то «море» экспертизы, которым пышет это «создание». Основная область – это конечно же разработка. Тут каждый должен знать все последние модные языки и технологии «впаривания» на них кода в продакшен. Причём, чем таких средств больше и чем они новее – тем круче! Вторая область, в которой разработчик всегда чувствовал себя увереннее любого недоразвитого админа – это поддержка и администрирование своего детища. Ведь проще это не хитрое дело делать самому, чем плодить тонны документации и внушать этим «тупым» и «упрямым» айтишникам, как заставить работать столь великолепный в исполнении и гениальный по задумке продукт (который так необъятен, что тестеры ещё долго будут ломать об него свои жалкие копья). Ну и что бы не стало никаких препятствий к заветным бонусам, нужно добавить ещё в этот «винегрет» обязанности продакт-менеджера, который вечно норовит всё перепутать и разрушить стройную модель доведения продукта до пользователя (или хотя бы до тестера). Итого, перед нами предстаёт величественная фигура полубога, который может всё и вся. Это кумир, идол и обитатель не земных высот! У него золотая голова, стальные мышцы и нестираемые метало-керамические колодки вместо подошв (автор не пытается тут напомнить вам сон Навуходоносора, совсем нет).
Теперь давайте кинем в него «камень». Что же случилось, почему эта величественная «скульптура» рассыпалась в прах!? Да всё просто, жизни не хватит, чтобы собрать даже в «золотой» голове всё ту экспертизу, которая будет покупаться и/или аутсортситься бизнесом. Раньше таких горе специалистов принято было называть просто – ламер. Но ламера не продать, поэтому то и нарядили его в «новые одежды». Чистой воды маркетинг. Дерево познаётся по плодам, и когда мы увидим и насладимся плодами девопсов, маркетологи придумают что-нибудь новое.
Второе, что бросается в глаза – это попытка совместить в одном лице две сущности, у которых очень разные цели, хотя задачи и могут иногда пересекаться. Цель разработчика – сдать к сроку работу и получить за это бонус. Цель админа, заставить эту работу работать и за это получить бонус. Цели ортогональны! Что получится в результате – работы будут всегда сданы в срок и работать будут всегда (под неусыпным присмотром девопса, который только один будет знать, как этого добиться). Кажется, где-то мы уже такое видели….
Кто же это придумал? Да уши же торчат прямо из самого названия – уж не от Devil ли сокращение первой части… От чего сокращение второй части, предлагаю обсудить в комментариях к этому посту ;)
добавлено: 19 апр 18 просмотры: 2230, комментарии: 4



SQL 2016 – It Just Runs Faster: Automatic Soft NUMA

По материалам статьи: SQL 2016 – It Just Runs Faster: Automatic Soft NUMA
30 марта 2016

Автор: Nitin Verma – Principal SQL Server Developer, Bob Dorr – Principal SQL Server Escalation Engineer

Мощности серверного оборудования растут из года в год, что обусловлено многолетним развитием технологий изготовления процессоров. Анализируя результаты наших исследований того, как работает SQL Server на современном оборудовании, и как наши клиенты достигают оптимального для себя масштабирования вычислительных ресурсов, мы выдвинули на передний план дальнейшего развития сервера баз данных необходимость улучшения возможностей секционирования обслуживания нагрузки. В настоящее время, именно основанный на секционировании дизайн является самым распространённым способом локализации обслуживания нагрузки и улучшения производительности и масштабируемости. Примером того, как SQL Server использует секционирование нагрузки является объект CMemThread.

Читать статью полностью
добавлено: 17 май 17 просмотры: 2381, комментарии: 0



SQL Server 2012 Database Engine Task Scheduling

Автор: Боб Дорр - главный эскалационный инженер поддержки SQL Server
По материалам статьи: How It Works: SQL Server 2012 Database Engine Task Scheduling

В течении последних лет в разных источниках были описаны алгоритмы работы планировщика SQL Server. В частности, в статье «The Guru’s Guide to SQL Server Architecture and Internals» есть глава, написанная разработчиком планировщика (Sameer) и Кеном Хендерсеном. Автор этой статьи и ранее описывал некоторые технические детали алгоритмов планирования задач SQLServer.

Эта статья посвящена некоторым изменениям, которые появились в SQL Server 2012. Статья не претендует на охват всех нюансов (коих слишком много), вместо этого будет частично проиллюстрирована работа алгоритма в его современной реализации, что позволит вам лучше понимать поведение планировщика SQLServer. Автор допускает по тексту несколько вольную трактовку в описании алгоритмов, преследуя цель избавить статью от лишней официальности.


Читать статью полностью
добавлено: 19 авг 16 просмотры: 2162, комментарии: 0



Введение в секционирование таблиц

По материалам статьи Крейга Фридмана: Introduction to Partitioned Tables

27 ноября 2006г.

В этой статье я собираюсь продемонстрировать особенности планов исполнения запросов при обращении к секционированным таблицам. Обратите внимание, что существует большая разница между секционированными таблицами (которые стали доступны только с SQL Server 2005) и секционированными представлениями (которые были доступных ещё в SQL Server 2000, и по-прежнему доступны в SQL Server 2005 и последующих версиях). Особенности планов запросов к секционированным представлениям я продемонстрирую в другой статье.

Читать далее.
добавлено: 19 янв 16 просмотры: 1993, комментарии: 0



Running SQL Server on Machines with More Than 8 CPUs per NUMA Node May Need Trace Flag 8048

По материалам статьи: Running SQL Server on Machines with More Than 8 CPUs per NUMA Node May Need Trace Flag 8048

Данная статья относится к следующим версиям SQL Sever: 2008, 2008 R2, 2012 и 2014. Первый вариант статьи был опубликован в 2011г.



Примечание: в данной статье под количеством процессоров подразумеваются не сокеты, а представленные в системе логические процессоры. Рекомендации статьи применимы в тех случаях, когда для сервера баз данных доступно более восьми логических процессоров из расчёта на один физический процессор.

читать дальше...
добавлено: 24 июн 15 просмотры: 2147, комментарии: 0



SQL Server 2014 Real Time Query Monitoring

Автор: Daniel Farina

http://www.mssqltips.com/sqlservertip/3328/sql-server-2014-real-time-query-monitoring/

Проблема

Если вдруг один из запросов к SQL Server выполняется слишком долго, вы может получить его план исполнения, что даст вам понимание того, что этот запрос делает, но из этого плана вы не сможете точно определить, что запрос делает именно в это время, т.е. на каком операторе плана он «застрял»?
Продолжая читать эту статью, вы узнаете, как научится следить за прогрессом исполнения запроса в режиме реального времени.

читать дальше...
добавлено: 27 янв 15 просмотры: 3934, комментарии: 0



Важное изменение алгоритма создания LSN в SQL Server 2014

http://www.sqlskills.com/blogs/paul/important-change-vlf-creation-algorithm-sql-server-2014/

Автор: Paul Randal

Опубликовано: 6 января 2015г.

SQL Server 2014 был выпущен еще в апреле прошлого года, и ходили некоторые слухи об изменениях в алгоритме создания VLF. Они направлены на уменьшение числа VLF, когда журнал увеличивается по команде или автоматически (далее я буду говорить для простоты авто-приращение, поскольку это наиболее распространенный сценарий). Я сделал несколько экспериментов и подумал, что понял изменения указанного алгоритма. Оказывается, я понял не всё. На прошлой неделе в переписке MVP всплыл вопрос, который породил целую дискуссию, и мы вместе пришли к выводу, что алгоритм ведет себя недетерминированно... другими словами, мы не знаем, что он делает. Так что я обратился к моим друзьям в CSS, которые исследовали код (спасибо Bob Ward и Suresh Kandoth!) и объяснили изменения.

Изменение одно и довольно глубокое, оно направлено на предотвращение создания огромного количества VLF при частом авто-приращении. Это здорово, потому что слишком большое количество VLF (это зависит от размера журнала, но несколько тысяч обычно слишком много) может вызвать проблемы с производительностью для резервного копирования, восстановления, очистки журнала, репликации, восстановления после сбоев, откатов транзакций и даже рядовых операций DML.

До 2014 алгоритм определения необходимого числа VLF при создании, увеличении или авто-приращении журнала зависел от его размера и следующих вопросов:

  • Менее 1 Мб, тут всё довольно сложно, игнорируйте этот вариант.
  • До 64 МБ: 4 новых VLF, каждый примерно 1/4 размера прироста
  • От 64 МБ до 1 ГБ: 8 новых VLF, каждый примерно 1/8 размер прироста
  • Более 1 GB: 16 новых VLF, каждый примерно 1/16 размер прироста
  • Так что, если вы создали свой журнал размером 1 Гб и авто-прирост выполнялся порциями по 512 МБ до 200 Гб, у вас получится: 16 + ((200 - 1) х 2 х 8) = 3200 VLF (16 VLF при первоначальном создании журнала, 200 - 1 = 199 Гб роста по 512 Мб на автоматическое увеличение = 398 операций авто-прироста, каждый из которых создаст по 8 VLF).

    Для SQL Server 2014 алгоритм изменился так:

  • Является ли размер прироста менее 1/8 размера журнала?
  • Да: создать 1 новый VLF, равный размеру прироста
  • Нет: воспользоваться приведенной ранее формулой
  • Так что для SQL Server 2014, если вы создали свой журнал размером 1 Гб с авто-приростом кусками по 512 МБ до 200 Гб, у вас получится:

  • 16 VLF при первоначальном создании журнала
  • Все новообразования вплоть до размера журнала 4,5 ГБ происходили в соответствии с формулой, и можно было бы наблюдать такие размеры файла: 1, 1.5, 2, 2.5, 3, 3.5, 4 Гбайт, и на каждом приращении добавлялись по 8 VLF = 56 VLF в сумме.
  • Все новообразования для размера журнала более 4 ГБ будут создавать только по 1 VLF - процентный рост = (200 - 4) х 2 = 392 VLF
  • Всего = 392 + 56 + 16 = 464 VLF
  • 464 многим более разумное число VLF чем 3200, и будет создавать гораздо меньше проблем с производительностью.

    Меня также спрашивали влияет ли на это уровень совместимости? Нет, уровень совместимости игнорируется внутри механизмов Storage Engine.

    Я думаю, что это отличное изменение, и не вижу каких-либо недостатков в нём (кроме того, что оно не было обнародовано, когда SQL Server 2014 был выпущен). В блоге CSS в ближайшее время появится комплексный обзор об этом.

    Вы можете подумать, что это может привести к появлению VLF очень большого размера (например, если вы установите размер авто-приращения 4 Гб для журнала размером 100 Гб), и это возможно. Но что с того? Очень большие VLF будут проблемой только тогда, когда они создаются первоначально, а затем вы пытаетесь сжать журнал до минимального размера. Как минимум, вы можете иметь в журнале только два VLF, так что у вас получилось бы два гигантских VLF в начале журнала, а за ними более мелкие, появившиеся после прироста журнала. Это может быть проблемой, которая помешает журналу использовать повторно высвобождающиеся виртуальные журналы без нужды в авто-приращении, но это не идёт ни в какое сравнение с тем, как часто можно столкнуться со слишком большим числом VLF. И этот сценарий нетипичен для нового алгоритма. (К слову, вы можете решить эту проблему путем создания моментального снимка базы данных, а затем восстановить базу данных до состояния, сохраненного в моментальном снимке, что удалит журнал и создаст новый размером 0,5 Мб с двумя крошечными VLF ... это баг особенность, которая появилась с 2005 года, но она нарушит ваш цепочку резервного копирования журнала, когда такое восстановление закончится).

    Конечно, для улучшения управления VLF нужно сделать в будущем ещё очень многое (например, для решения проблемы, которую я только что описал), но сделанное - гигантский шаг в правильном направлении.

    добавлено: 08 янв 15 просмотры: 2413, комментарии: 1



    Автономный Монитор зеркального отображения баз данных

    Эта короткая заметка адресуется тем, кто после внедрения SQL Server 2014 столкнулся с
    проблемой запуска Монитора зеркального отображения баз данных. Чаще всего его
    вызываем из Management Studio. Однако, его можно запустить самостоятельно, на моём компьютере он
    обнаруживается по следующему пути: C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\sqlmonitor.exe


    После запуска с правами администратора программы sqlmonitor.exe, вам предстанет главное
    окно Монитора репликации, в меню которого в пункте «Перейти» можно выбрать Монитор
    зеркального отображения баз данных. Следующий скриншот демонстрирует эту
    возможность.


    добавлено: 24 дек 14 просмотры: 2377, комментарии: 1



    Блог переехал :(

    С прискорбием сообщаю, что блог неожиданно для меня переехал сюда: http://blogs.msmvps.com/gladchenko/
    Картинки пропали, ссылки не работают... Пока ещё не решил, буду чинить всё там, или переносить контент сюда. Пока знаю точно, что устаревшие статьи править не стану, некогда. Извините за возможные неудобства!
    добавлено: 28 июл 14 просмотры: 2450, комментарии: 3



    SQLCAT's Guide to High Availability and Disaster Recovery

    Представляем вашему вниманию новую бесплатную электронную книгу в формате PDF, выпущенную командой SQLCAT: SQLCAT's Guide to High Availability and Disaster Recovery

    Ниже представлен свободный перевод одной из глав книги.

    http://blogs.msmvps.com/gladchenko/2013/10/28/aoag/
    добавлено: 07 ноя 13 просмотры: 1957, комментарии: 0