We append the following metrics to the T-SQL procedure statements: execution count (x), CPU time in milliseconds (c), duration in microseconds (d), number of reads (r), number of writes (w), and @@rowcount value (n). You can display these as absolute values or percentages.

Лем - "неровный" писатель. Есть у него очень хорошие вещи, а есть проходные. Серия "Дневники Йона Тихого" содержит и стеб, и политическую сатиру, но есть и очень глубокая вещь - это 21е путешествие.

Напомню немножко - Йон попадает на планету, жители которой боролись со старением, и в результате развития технологий достигли практически всего, например, "прошивать" любые умения и убеждения в мозгу, копировать существ. "Даже ребенок может сегодня воскресить умершего, вдохнуть дух в прах и лом, гасить и возжигать светила, поскольку есть все необходимые технологии". Однако у этого обнаруживается и темная сторона. "На смену кошмарам прежних ограничений пришел кошмар полного их отсутствия.", и далее "Там, где можно продублировать любимое существо, нет уже любимых существ, но есть лишь осмеяние любви, а там, где можно быть кем угодно и питать какие угодно убеждения, каждый становится никем, и нет никаких убеждений"

Would you like to know which indexes are used frequently or rarely? Which ones aren't used at all? Which tables and indexes are the largest? It's very easy to create visualizations for this. They're both visually appealing and practically useful.

Недавно я прочитал статью Парадокс Ньюкома и искусственный интеллект и понял, что с появлением ИИ многие мысленные эксперименты стали реальными. Действительно, ИИ можно сохранять, стирать память, клонировать итд. А что сам ИИ думает по этому поводу?

Настало время... интересных историй. Про то, как я заказал сайт и что из этого вышло. Спойлер — человек не справился, а нейросетка — да

На этот раз более простая и красивая визуализация. Речь пойдет о том, как нарисовать историю выполнения SQL Agent jobs — как раз тех, с которыми все время имеет дело DBA.

В моей предыдущей статье я отображал метрики из записанного SQL profiler trace на листинг stored процедуры. Это идеально подходит к тестовым окружениям, но в production надо быть осторожным, и запись "частых" событий могут увеличивать CPU сервера и замедлять его работу.

@speshuric предложил использовать данные из Query Store. Там, правда, нет номеров строк. Но можно выкрутиться, так как есть смещения и можно посчитать количество переводов строки до смещения. Итак, сказано - сделано!

Вам интересно, какие индексы используются больше или меньше? Какие не используются вовсе? Какие таблицы и индексы самые большие? Очень легко создать такие диаграммы. Это и красиво, и полезно.

Мне кажется, что на одного админа приходится довольно много программистов. Многие стараются «войти в айти» либо напрямую, либо через QA. В админы идут редко. Поэтому на habr много обсуждений, а вот админов почти не упоминают. А, между прочим, у нас многое по другому. Поэтому я решил восполнить этот пробел статьей.

Сразу покажу, о чем идет речь, чтобы вы решили, нужно вам это или нет. На текст процедуры мы отображаем данные о числе выполнений, cpu, duration, о числе чтений и записей и числе обработанных записей.

If your code has many nested executions of stored procedures, you can benefit from building popular "flame diagram" of the execution time which is de facto standard for performance profiling.

Если в вашем коде TSQL много вложенных вызовов stored procedures, вы можете наглядно построить стек вызовов с помощью «flame chart» — стандартным представлением для профилирования вызовов.

Опишем по шагам всю процедуру.

Недавно я писал статью - что такое 50% cpu? На системах с hyperthreading 50% cpu по метрикам означает, что большая часть ресурсов сервера уже использована. То есть cpu>50% - это уже "желтая зона", и мы ожидаем замедление всего, чего можно. Но я никогда не думал до экспериментов, что падение может быть столь катастрофическим.

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

Я написал ряд статей по истории техники, с которой сталкивался. Раз, Два, Три, Четыре. Но эти статьи были посвящены технике. А как было с наймом на работу?

Итак, на дворе 1991 год. Вы не знаете, кто вы — джуниор, миддл и сеньер, потому что никто не знает этих слов. Вы не поймете слова «стек», но после дополнительных пояснений можете объяснить, железячник вы или по программам. Скорее всего «писишки». Есть узкие специалисты, Novell Netware, например.

Ну и поиск работы. Нет сайтов linkedin и hh.ru... Да собственно, никаких сайтов нет.

Посчитаем по пунктам потенциальные грабли и проблемы, с которым встречается DBA на своем рабочем месте. Сколько получилось у вас? Отпишитесь в комментариях.

Если у вас на машине стрелочка показывает, что у вас осталась половина бака, то у вас точно осталась половина бака? На самом деле больше, так как современные машины врут и топлива еще немного есть, даже когда стрелка на нуле - забота об альтернативно одаренных водителях. А если сервер показывает 50% cpu, то сколько ресурсов у нас осталось?

Для многих ответ ясен, и это не 50%. Поэтому извините, если многие вещи будут вам очевидны. А вот для менеджеров, например, которые планируют ресурсы, это может быть открытием.

В базах данных нет серебряной пули, универсального рецепта. Мне захотелось проверить экспериментально один граничный случай использования 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. Как мы помним, упакованные данные плохо пакуются. Как упаковка данных повлияет на размер бэкапа?