В базах данных нет серебряной пули, универсального рецепта. Мне захотелось проверить экспериментально один граничный случай использования in memory tables и natively compiled - когда в тесте все было хорошо, а на реальных данных начались тормоза.

В SQL server есть замечательная технология - AlwaysOn. Она используется для DR (disaster recovery, асинхронная репликация данных), HA (high availability, часто с automatic failover, что возможно при синхронной репликации), и для того, что мы обсудим в статье: readonly replica для DWH/OLAP/Reporting workload.

Ничто не совершенно (хотя я восхищаюсь простотой установки некоторых решений в MS SQL по сравнению с Postgre и Oracle. Хотя бы бэкапы... А AlwaysOn для маленьких баз заводится буквально в пару кликов).

Cегодня мы рассмотрим проблемы при использовании AlwaysOn для DWH/OLAP/Reporting.

Я люблю проводить численные эксперименты. Процессор должен думать, а не простаивать. Напомню, что нетривиальные нули Зета функции Римана, расположенные симметрично относительно оси X, имеют вещественную часть равную -1/2 (что не доказано, может быть, у вас получится?), а мнимая часть у первых нулей равна (+/-, так как они расположены симметрично): 14.13, 21.02, 25.01, 30.42, 32.93...

Поиграем с этим.

MSSQL поддерживает компрессию бэкапов на лету - легковесную и быструю. Также данные можно внутри базы упаковать с помощью DATA_COMPRESSION = PAGE или ROW. Как мы помним, упакованные данные плохо пакуются. Как упаковка данных повлияет на размер бэкапа?

Ваш покорный слуга работал с MSSQL с версии 6.5, но в качестве экзотики застал версии 6.0 и 4.2. Да, я супер стар!

Но осталось ли в MS SQL что-либо с тех времен?

В современном обществе принято заботиться о людях с ограниченными возможностями. Но что, если это ограничение касается возможности работы с компьютерами?

Критерий фальсифицируемости Поппера долго верой и правдой служил физикам (он служил физике задолго до того, как был явно сформулирован в 1934 году). Этот принцип избавлял физику от невидимых розовых единорогов, которые летают повсюду, но никак не наблюдаемы. Однако по мере развития науки и движения в сторону общей теории всего приходится поступаться принципами. Или нет? Давайте рассмотрим случаи, когда этот принцип ставится под вопрос.

Вскоре после создания специальной теории относительности было разобрано до косточек большое число 'парадоксов' - парадоксов в кавычках, потому что парадоксами они были только для нашего 'здравого смысла', который натренирован на классической ньютоновской механике, которая прошита в нашем мозжечке. Парадокс близнецов, парадокс карандаша и пенала, итд.

Но есть еще один парадокс, парадокс Белла (того самого, чьим именем названо неравенство квантовой механики). Он интересен тремя моментами:

Мы привыкли к различным единицам измерения, всяким метрам в секунду и киловатт-часам. В формулы пролезают многочисленные константы - c (скорость света), h (постоянная Планка), G (гравитационная постоянная), k (постоянная Больцмана). Однако оказывается, что для фундаментальной физики куда удобнее принять одну из 'естественных' единиц. Таких систем несколько - но лучше по англ.

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

Наоборот, некоторые системы (Система Си) только запутывают (см. главу "Критика"): Вследствие этого в системе единиц СИ электрическое поле и электрическая индукция, магнитное поле и магнитная индукция (в сущности — различные компоненты тензора электромагнитного поля) имеют разную размерность. Такую ситуацию Д. В. Сивухин характеризует так:

В физике есть понятие естественности (naturalness). Когда мы получаем безразмерный коэффициент, то мы ожидаем, что это безразмерный коэффициент, 'утекший' из математики. Но иногда в формулах возникают коэффициенты, которые никак не следуют из чистой математики, как правило, это производные параметров стандартной модели. Иногда эти коэффициенты очень велики.

Проблема континуума волновала математиков со времен создателя теории множеств, Кантора. Великий математик Гильберт поставил ее на первое место в своем знаменитом списке. В каком-то смысле она считается решенной - только многие не считают это решением, и она по-прежнему занимает умы философов и математиков.

How do you deal with index fragmentation if your SQL server is working in high load environment with 24/7 workload without any maintenance window? What are the best practices for index rebuild and index reorganize? What is better? What is possible if you have only Standard Edition on some servers? But first, let's debunk few myths.

Myth 1. We use SSD (or super duper storage), so we should not care about the fragmentation. False. Index rebuild compactifies a table, with compression it makes it sometimes several times smaller, improving the cache hits ratio and overall performance (this happens even without compression).

Myth 2. Index rebuild shorten SSD lifespan. False. One extra write cycle is nothing for the modern SSDs. If your tempdb is on SSD/NVMe, it is under much harder stress than data disks.

Myth 3. On Enterprise Edition there is a good option: ONLINE=ON, so I just create a script with all tables and go ahead. False. There are tons of potential problems created by INDEX REBUILD even with ONLINE and RESUMABLE ON - so never run index rebuilds without controlling the process.

Finally, we will tackle the REBUILD vs REORGANIZE subject and what is possible to achieve if you have only Standard Edition.

В двух прошлых статьях я разобрал Index REBUILD в Enterprise и Standard editions. Настало время осветить Index Reorganize - то есть Index Rebuild для бедных. Рекомендую заглянуть в статьи по ссылкам выше - там описан скрипт, который выполняет rebuild или reorg, контролируя течение процесса.

Ведь index reorganize не держит долгих блокировок, почти не нагружает сервер, работая в одном треде, поэтому он безопасен, так? Правда? Ведь правда?

В одной из моих предыдущих статей я рассказал о скрипте с названием GentleRebuild, который делал index rebuild в базах, работающих под нагрузкой 24/7, когда нет maintenance window, в Enterprise Edition. Там можно использовать опции ONLINE=ON и даже RESUMABLE=ON, вежливо уступая основной нагрузке базы.

А как же Standard Edition, где этого нет? Каюсь, раньше у меня в скрипте даже стояла проверка, и для Standard Edition скрипт сразу завершался. Но шеф меня попросил заняться и серверами со Standard Edition, и мне пришлось выжать из ситуации максимум.

Начнем с хороших новостей. Какое то время назад я написал статью Дефрагментация таблиц в высоко нагруженных базах данных (MSSQL). За это время я еще больше отшлифовал скрипт на production, и отдел безопасности фирмы, где я сейчас работаю, разрешил выложить его в open source (репо на github). Приглашаю воспользоваться им и писать мне о багах и пожеланиях.

Ниже я приведу краткий update к статье - кое в чем я теперь с ней не согласен. Кроме того, опишу опыт SHRINK - почему его лучше никогда не делать, почему все-таки иногда нужно делать и как его готовить.

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

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

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

По мере работы там я оброс тем, что мне хочется назвать 'Company-skills'. Помните, вначале было hardware и software, и потом между ними возникло firmware? Вот также между soft skills и hard skills есть company skills. Company skills это знания кучи URL, умение заказать доступы и знания, кто что аппрувит. Где смотреть логи Kibana и где алерты Zabbix и Grafana. Куда можно лезть, а где дадут по рукам. Это logins в 8 разных доменах (фирма поглотила много фирм поменьше, и они тихо переваривались в ее нутре. Но домены сопротивляются перевариванию дольше всего). И текстовый файл с кучей URL и текстовыми описаниями, что и где. Это умение правильно создать заявку в доморощенной системе XXX. И память о том, что в системе XXX логин надо вводить как просто 'user', в системе YYY как DOMAIN\user, а в ZZZ как user@domain, иначе не сработает.

Хорошо, если у вас небольшие (сотни гигабайт) базы, а ночью или в выходные вы можете себе позволить иметь '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 (потому что страницы перемещаются с помощью процессора, а не сами по себе).

Мне часто приходится пользоваться PowerShell. Конечно, его создатели не имели никакого представления о прекрасном и эстетике. Уродливость PowerShell особенна видна при его сравнении, например, с Python. С другой стороны, как говорится, c лица не воду пить - работает и хорошо? Но нет, мне кажется в PowerShell есть по крайней мере пара моментов, которые фатально влияют на его практическое применение.

Об опасном распространяющемся антипаттерне программирования на T-SQL.