Microsoft SQL Server *

Microsoft SQL Server 2022 представляет новую возможность запрашивать данные непосредственно из источников, осуществлять виртуализацию данных, и использовать интерфейсы REST API. Это делает работу с данными ещё более лёгкой и гибкой, за счёт увеличения числа поддерживаемых коннекторов и форматов файлов. Поддерживаются форматы: CSV, Parquet и Deltafiles, хранящиеся в любом объектном хранилище, совместимом со службой хранения S3, как локально, так и в облаке. И наконец, SQL Server 2022 теперь может использовать операции Create External Table as Select (CETAS) в OPENROWSET, вместе с такими командами как Create External Table (CET) совместно со всеми возможностями T-SQL. Всё это делает SQL Server 2022 мощным центром управления данными.

В SQL Server 2022 мы представили новую функцию, называемую: «Degree of parallelism feedback» (обратная связь для DOP). Эта функция отслеживает запросы с параллелизмом и определяет, может ли запрос работать лучше при меньшей степени параллелизма, чем используется в момент исполнения. Например, вполне возможно, что 16 потоков будут работать лучше двадцати, если в этих потоках много ожиданий процессора. Будет выполнена пробная проверка новой степени параллелизма и либо принято решение, что это хорошее изменение, и далее будут применяться 16 потоков, либо так и останется DOP = 20 потоков. Если новая степень параллелизма покажет лучшие оценки для запроса, то это значение будет сохранено в «Query Store» (хранилище запросов) и будет соответствующим образом применяться к запросу при следующем исполнении.

Сегодня речь пойдет про ускорение поиска по подстроке в высоконагруженных базах данных 1С. А точнее об альтернативе, которую можно предложить взамен полнотекстового поиска от 1С или MS SQL.

Поисковые запросы с конструкцией LIKE ‘%текст%’. Именно с двумя %%. В этом случае стандартные индексы не работают и SQL производит полное сканирование таблиц.

Развернув очередной обратно разработчику Pull Request с поиском по аналитике, принимающей разные значения в разные промежутки времени, я решил на планерке обсудить этот вопрос. И был удивлен, что подавляющее большинство разработчиков не понимают, как эффективно искать на SQL в таких случаях. Погуглив, ради интереса, обнаружил, что этот вопрос как-то обходится стороной сообществом. В итоге решил написать статью, заодно ссылаясь на нее самому.

Сразу хочу уточнить, что речь идет именно об MS SQL, так как, например, в PostgreSQL уже есть диапазонные типы и виды индексов, позволяющие их индексировать.

Всем привет от команды ЮMoney ?

Делимся видеозаписями и главными мыслями митапа High SQL, который посвятили работе с данными в DWH на Microsoft SQL Server.

Кому советуем посмотреть доклады

◾️ Тем, кто планирует перебраться с Microsoft SQL в PostgreSQL, но всё ещё сомневается.

◾️ Тем, кто выбирает между ANTLR и DacFx и хочет научиться решать проблемы во время ревью TSQL-кода.

◾️ И тем, кто хочет узнать, зачем тестировать OLAP-кубы, что может пойти не так и какой результат дают автотесты силами разработчиков и тестировщиков.

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

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

Здравствуйте. В этой статье хотел бы разобрать кейс создания резервных копий. Я опишу свои методы, и прошу Вас поделиться опытом о том, как Вы решали данные задачи. Я опишу самые простые технологии, но они эффективны и выполняют поставленную задачу…

В основном статья будет полезна начинающим системным администраторам (и, конечно, не только в вузах), но прошу опытных специалистов поправить меня, если есть неточности, а может подскажете другие более лучшие решения. Буду благодарен всем, кто проявит интерес к статье.

Но начну с такой информации…

Статья 274 УК РФ. Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно‑телекоммуникационных сетей

1. Нарушение правил эксплуатации средств хранения, обработки или передачи охраняемой компьютерной информации либо информационно‑телекоммуникационных сетей и оконечного оборудования, а также правил доступа к информационно‑телекоммуникационным сетям, повлекшее уничтожение, блокирование, модификацию либо копирование компьютерной информации, причинившее крупный ущерб, — наказывается штрафом в размере до пятисот тысяч рублей или в размере заработной платы или иного дохода, осужденного за период до восемнадцати месяцев, либо исправительными работами на срок от шести месяцев до одного года, либо ограничением свободы на срок до двух лет, либо принудительными работами на срок до двух лет, либо лишением свободы на тот же срок.

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

Сравнение, как работает операция GROUP BY в MySQL, PostgreSQL и MS SQL Server и что можно сделать, чтобы улучшить производительность запросов на столбцах с малым количеством уникальных значений.

В данной статье хочу поднять тему, которая представляет собой одну большую боль для администраторов, разработчиков и тестировщиков высоконагруженных (и не очень) систем под управлением PostgreSQL. Даже не «боль», а «БОЛЬ»!

Удивительно, что за почти 30 лет существования PostgreSQL не появилось нормальных инструментов для получения вменяемых счетчиков и трассировок. Все, кто работают с MS SQL Server используют профайлер. Это обязательный и привычный инструмент, который позволяет вылавливать запросы, интересные нам в рамках исследования. Вылавливать как все запросы без разбора, так и какие-то единичные запросы, которые удовлетворяют правилам отбора. Кроме того, можно настроить не одну трассу, а столько сколько нужно, с разными фильтрами. Эти трассы содержат очень богатый набор измерений для анализа: – Reads физические и логические; Writes; SPID, Процессорное время; план запроса (хэш плана), количество строк и т.д.

Многие компании стали всерьез рассматривать СУБД PostgreSQL как замену MSSQL и сталкиваются с тем, что возможностей для ее мониторинга просто нет – она как черный ящик, в котором наощупь вылавливаешь какую-ту информацию и пытаешься систематизировать ее хоть как-то.

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

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

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