Microsoft SQL Server *

В сети огромное количество мануалов по созданию отказоустойчивых групп доступности AlwaysON Microsoft SQL Server посредством Windows Server Failover Cluster. Но что делать, если экземпляры Microsoft SQL Server развёрнуты на Linux, а очень хочется создать отказоустойчивые группы доступности AlwaysON? В русскоязычном сегменте не нашёл внятных мануалов, посвящённых этому вопросу. Решил написать гайд. Сразу скажу, гайд в некоторых местах будет очень подробный и разжёвыванием банальных вещей может раздражать опытных системных администраторов, однако, как показывает практика, людей которым хотелось бы, чтобы он был ещё подробнее куда больше, чем тех, кому эта подробность не по нраву. Тут мы затронем и вопросы оптимизации производительности, которые актуальны для наверно самого популярного прикладного применения Microsoft SQL Server в России — хранения информационных баз 1С. На самом деле данная задача не особо сложная, но важна к освящению.

Этой статьей мы начинаем цикл разбора нетривиальных случаев в нашей практике оптимизации производительности ИТ‑систем. Возможно, кому‑то они пригодятся, так как решения будут нестандартные. Возможно, кто‑то узнает свою ситуацию и поделится своими решениями или наведет на интересную мысль. Ведь, коллективный разум — это сила!

Не секрет, что самой популярной и массовой платформой в России для создания ИТ‑систем для бизнеса является 1С:Предприятие 8.х. На ней разработано огромное количество отраслевых и самописных решений.

Хочу обратить внимание на одну особенность работы приложений 1С, а именно, очень интенсивную работу с временными таблицами СУБД. Подобной интенсивной работы с tempDB, наверное, нет ни в одном тиражном решении в мире.

После завершения пакетного запроса платформа автоматически удаляет временную таблицу, отдавая серверу СУБД команду <truncate table>, чтобы освободить ресурсы под следующий запрос.

TRUNCATE — это очень простая и быстрая операция и выполняется мгновенно. Даже для таблиц с миллионами строк она длится миллисекунды. Тем не менее, у некоторых своих клиентов мы столкнулись с очень странной ситуацией, когда производительность системы проседает из‑за того, что запросы с очисткой временных таблиц могут длиться десятки секунд (не миллисекунд, а секунд!). А учитывая количество запросов с временными таблицами в ИТ‑системе на 1С:Предприятие, это время в совокупности становится просто огромным.

Оценка кардинальности «Cardinality estimation» (CE) — это процесс, используемый оптимизатором запросов для оценки количества строк, возвращаемых запросом или частью запроса. Эти оценки основаны на двух базовых вещах: статистике данных и наборе допущений (assumptions), известных как модель. Модель определяет, как мы интерпретируем статистику и данные, поступающие из разных частей выражения, поэтому для любого заданного набора статистических данных разные модели приведут к разным оценкам кардинальности.

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

CE всегда исходила из трех основных допущений, составляющих модель: независимость (или частичная независимость), однородность и контейнирование. Эти три предположения определяют как мы интерпретируем гистограммы, как мы объединяем данные, реализуя соединения, и как поступаем при наличии нескольких предикатов. В этой статье будут рассмотрены подробно возможные варианты моделей и их влияние на запросы.

В процессе своего обучения профессии ML engineer, пришло время и мне окунуться в мир баз данных. На курсе нам предложили два инструмента для работы с базами данных - это DataGrip и DBeaver (если же, по вашему мнению, существует более интересные продукты, то я буду только рад, если вы в комментария об этом расскажете). Я в своей статье задаюсь целью сравнить эти два инструмента - возможно это поможет кому-то с выбором.

Итак, приступим.

Мы рады сообщить, что в SQL Server 2022 достигнуты серьёзные успехи в ускорении восстановления базы данных (ADR). Это еще больше повышает доступность и масштабируемость баз данных, в первую очередь направлено на облегчение очистки и управления хранилищем версий - Persistent Version Store (PVS).

В SQL Server 2022 добавилась новая функция для статистики — AUTO_DROP. В этой статье мы расскажем, что она даёт и как её включать и выключать. Также будут представлены несколько примеров и показаны некоторые распространенные ошибки и способы их решения. Для демонстрационных примеров в этой статье мы будем использовать следующее:

Почему так тяжело расследовать и устанавливать причины просадки производительности в 1С 8?

Я работаю в компании, которая занимается вопросами оптимизации производительности и масштабируемости СУБД уже почти 20 лет. В своей практике мы сталкивались с разными ИТ-системами: по масштабу, по платформам приложения, по СУБД. Используя различные программные средства, постепенно выкристаллизовалась методика поиска узких мест любой системы. И дальше встал вопрос об автоматизации не только процесса анализа проблем, но и поддержки производительности.

Написание нового кода = ошибки. С этим всё просто.

Избавится от ошибок – вот это сложная задача.

Программисты привыкли, что в их средствах разработки есть встроенные инструменты, показывающие, какая строка кода сейчас работает, отображают текущее содержимое переменных, выводят сообщения о процессе выполнения и т.д. Какое-то время в SQL Server Management Studio тоже был отладчик кода, но, начиная с версии SSMS v18, он был удален. Хотя даже когда отладчик был, я не фанател от него: SQL Server буквально мог прекратить обработку других запросов, пока выполнял ваш запрос. Это была катастрофа, особенно когда ваш запрос блокировал других пользователей, и всё это происходило на рабочей базе.

Мне бы хотелось, чтобы у нас был простой способ отладки T-SQL на рабочей базе без блокировок, но отладка T-SQL отличается от отладки в C#. Так что если ваш T-SQL код делает не то, что вы ожидали, вот несколько хороших способов для его отладки.

Данные временных рядов — это набор значений, упорядоченных так, как они появляются и поступают для обработки. В отличие от транзакционных данных SQL Server, которые не зависят от времени и могут часто обновляться, данные временных рядов обычно записываются один раз и, если обновляются, то крайне редко.

Вот несколько примеров данных временных рядов: цены на акции, телеметрия от датчиков, счётчики производительности SQL Server (например, утилизация ЦПУ, памяти, устройств ввода‑вывода и сети).

Данные временных рядов часто используются для сравнений в истории наблюдений, обнаружения аномалий и уведомления о достижении заданного порога, прогнозного анализа и составления отчетов, где время является осью значений при просмотре или анализе данных.

Привет! Я Владимир Колосков, ведущий разработчик в Softpoint. Сегодня я хочу поделиться своими соображениями по поводу миграции больших и огромных БД с MSSQL Server на PostgreSQL: зачем это делать, стоит ли это делать сейчас и как я вижу такой переход.

Сразу пару слов про «Почему с SQL Server?» и «Почему на PostgreSQL?».

Самая распространенная в России платформа для бизнес-систем – это 1С:Предприятие 8. Причем в компаниях любого размера. Исторически платформа работала всегда с MS SQL Server. Есть, конечно, инсталляции и на других СУБД, но их крайне мало в общей массе. А связке 1С+MSSQL Server уже не один десяток лет, она отлажена, понятна и более-менее предсказуема. На основании собственного опыта и опыта Softpoint могу уверенно утверждать, что если в компании есть крупная ИТ-система, то она почти всегда на MSSQL Server (даже если это не 1С). И чем больше база данных, тем сложнее компании решиться на миграцию, т.к. это длительный процесс, с серьезным функциональным и нагрузочным тестированием, не укладывающийся ни в одно технологическое окно. А перспектива простоев ИТ-систем в бизнесе – такое себе.

Что касается вопроса «Почему на PostgreSQL?», то на данный момент других вариантов просто нет, ниже по тексту я разверну это утверждение.

Одна из целей статьи – показать, что использование гетерогенной информационной системы как инструмента перехода с одной СУБД на другую – это очень оправданный шаг как с экономической точки зрения, так и с учетом возможных рисков. Это позволит, с одной стороны, пользоваться и хранить данные в привычной СУБД, которая годами и десятилетиями оттачивалась крупным вендором, и которая имеет минимальные нарекания в производительности, в поддержке, в ошибках. А, с другой стороны, параллельно пользоваться СУБД с открытым исходным кодом, анализировать ее поведение при таком же профиле нагрузки, плавно увеличивать нагрузку, проводить тестирование столько времени, сколько нужно.

Я очень люблю визуализации. Человек лучше всего воспринимает информацию через образы. Для трех часто встречающихся баз (MSSQL, Postgres и MySQL) я смастерил плагины к проекту Bell, хотя этот код на Python можно использовать и отдельно. Поэтому для каждой визуализации я буду в скобочках писать имя файла из репозитория GitHub - вы можете этот файл вытащить и использовать его отдельно от проекта (для этого нудны минимальные модификации).

Отмечу только, что я считаю себя экспертом только в MSSQL, а то что сделал с другими базами - сделал по наитию. Кроме того, в отличие от MSSQL у меня нет реальных баз под большой нагрузкой для Postgres и MySQL. Поэтому ошибки/пожелания для скриптов Postgres и MySQL очень и очень welcome!

В основном я задействовал TreeMap.

В этой статье мы обсудим, как устроен агрегат WITH ROLLUP. Использование предложения WITH ROLLUP позволяет выполнить несколько «уровней» агрегации в одном операторе. Например, предположим, что у нас есть некие данные о продажах (это те же данные, которые я использовал в серии статей об операторе PIVOT).

Виртуальные файлы журналов (Virtual Log Files – VLF) — это внутреннее разбиение реальных физических файлов, которое создает Database Engine SQL Server для работы с журналом транзакций. У VLF нет четко определенного размера, и их количество на один физический файл не является фиксированным. VLF создаются компонентом Database Engine во время создания или расширения файлов журналов. Размер VLF рассчитывается динамически на основе размеров существующего журнала и нового файла приращения. За VLF, однако, числится дурная слава, которая заключается в том, что слишком большое количество VLF может вызвать ряд проблем, среди которых можно выделить существенное снижение скорости запуска базы данных, операции резервного копирования и восстановления журналов. Чем больше VLF было сгененрировано, тем дольше процесс восстановления базы данных, что может привести к превышению времени ожидания, ошибкам, связанным с памятью, и целому ряду других проблемам.

Вы когда-нибудь задавались вопросом, насколько Extended Events влияют на производительность вашей рабочей нагрузки? Я много писал о Extended Events и был активным сторонником их использования в качестве альтернативы SQL Trace даже дольше, чем я работаю на SQLskills.com. Но хоть Extended Events и дают нам множество преимуществ при сборе данных с минимальными накладными расходами, все же бывают случаи, когда нам не обойтись без дополнительных накладных расходов на наблюдение даже при использовании Extended Events.

Хорошо, если у вас небольшие (сотни гигабайт) базы, а ночью или в выходные вы можете себе позволить иметь 'maintenance window' и дефрагментировать таблицы. А если нет? В любом случае дефрагментация многих терабайт может занять дни, так что существование maintenance window становится непринципиальным.

Case study: многие терабайты данных, деятельность связанная с процессингом карт (24/7, maintenance window нет в принципе), MSSQL. Разумеется, Enterprise Edition, разумеется AlwaysOn.

Миф: у нас SSD, поэтому дефрагментация нам не нужна. Еще как нужна! Часто в высоко нагруженных системах не делают дефрагментацию, потому что это сложно. В итоге процент фрагментации выходит на уровень почти 100%, и таблицы занимают в два раза больше страниц, чем нужно. В два раза больше места - это в два раза хуже Buffer Cache Hits Ratio. Это в два раза больше размер full backups. Это в два раза дольше full table scans. Это выше CPU (потому что страницы перемещаются с помощью процессора, а не сами по себе).

Рассмотрим следующий пример:

CREATE TABLE T (PK INT PRIMARY KEY, A INT, B INT)
CREATE INDEX TA ON T(A)
CREATE UNIQUE INDEX TB ON T(B)
INSERT T VALUES (0, 0, 0)
INSERT T VALUES (1, 1, 1)

Теперь предположим, что мы выполним обновление:

UPDATE T SET A = 1 – A

Это изменение влияет на кластерный индекс (PK__T__15502E78) и на некластерный индекс TA. План в значительной степени такой, какой мы ожидали:

  _{|--Clustered Index Update(OBJECT:([T].[PK__T__15502E78]), OBJECT:([T].[TA]), SET:([T].[A] = [Expr1003]))
       |--Compute Scalar(DEFINE:([Expr1016]=[Expr1016]))
            |--Compute Scalar(DEFINE:([Expr1016]=CASE WHEN [Expr1004] THEN (1) ELSE (0) END))
                 |--Compute Scalar(DEFINE:([Expr1003]=(1)-[T].[A], [Expr1004]=CASE WHEN [T].[A] = ((1)-[T].[A]) THEN (1) ELSE (0) END))
                      |--Top(ROWCOUNT est 0)
                           |--Clustered Index Scan(OBJECT:([T].[PK__T__15502E78]))}

Это типичный «узкий» план обновления. В одном операторе обновления затрагиваются кластерный и некластерный индексы. План содержит Compute Scalar, которые определяют, нужно ли изменять соответствующую строку некластерного индекса. О подобных планах я писал в этой статье.

_{Оперативно узнавать о новостях MS SQL Server можно в телеграмм-канале: MS SQL Server - дело тонкое...}

1С работает с СУБД  Postgres более 10 лет, а сейчас это единственный легальный вариант для инсталляций в России. Много ли мы потеряем в производительности по сравнению с MS SQL ? Выдержит ли Postgres 15.2 жесткий Highload со стороны 1С? Цель этой статьи - ответить на данные вопросы, с цифрами, которые можно использовать при расчете архитектуры.

Хочется поделиться опытом преображения одного представления кода в другой с помощью ETL процесса и графовой базы данных на актуальном в наши дни примере.

Вкратце есть база на mssql сервере есть хранимые процедуры. Есть база на postgres. Есть ETL процесс на Apache Air Flow. Запускаем процесс, по окончании в базе postgres появляются процедуры и данные.

Скажу сразу данный подход не является полным автоматом, который перенесет любую mssql базу на postgres. Это попытка систематизировать подобный переход, разбить переход на управляемые небольшие части, которые типизируются и над которыми выполняются преобразования с возможностью контроля результата.