Microsoft SQL Server *

В SQL Server 2022 появилась замечательная возможность\функция, которая называется: Parameter Sensitive Plan Optimization (оптимизация плана с учетом параметров, для краткости - PSP). Как следует из названия, её задача обеспечить производительность параметризованных запросов. Появилась возможность создания несколько планов исполнения для параметризованного запроса, каждый из которых оптимизирован для разных значений параметров. Это позволяет оптимизатору SQL Server выбирать наилучший план выполнения для определенных значений параметров, используемых при исполнении конкретного запроса.

Когда я впервые узнал о том, что SQL Server 2022 будет поддерживать мгновенную инициализацию файлов журнала транзакций, я был заинтригован. Когда позже выяснилось, что это относится только к   автоматическому приращению и только с размером не больше 64 МБ, интрига несколько потеряла свой «блеск». Из-за этих ограничений я скептически отнесся к тому, что новая стратегия сможет заменить сложившуюся практику автоматического увеличения файлов журналов на 1 ГБ — по крайней мере, с тех пор, как SSD и другие современные хранилища получили достаточное распространение.

Но поигравшись с этим новшеством, я проникся.

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

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

Настройка резервного копирования с помощью плана обслуживания с загрузкой бэкапов на s3 ресурс selectel.

Продолжаем обсуждать инструменты анализа производительности систем на PostgreSQL.

В прошлой статье я начал рассказывать о расширении SP_TRACE, устанавливаемого на любые сборки PostgreSQL, и являющегося неотъемлемой частью мониторинга PerfExpert.

SP_TRACE предоставляет новые сведения в виде счетчиков и трасс, которых нет в других известных инструментах.

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

В этой статье я бы хотел подробнее остановиться на Nasgrate

Основные преимущества Nasgrate

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

• возможность автоматического создания миграции на основе анализа изменений в двух базах данных (пока поддерживается только MySQL, но в планах другие базы данных) или между двумя состояниями миграций одной базы данных

• наличие визуального интерфейса (а не только консольного клиента) позволяющего организовать просмотр изменений в наглядном виде

Это новая концепция обеспечения идентичности ограниченного набора системных объектов и сущностей, которой до этого очень недоставало. Администраторам баз данных приходилось «вручную» синхронизировать логины, задания агента, планы обслуживания и множество других системных сущностей, которые описывались в таблицах системных баз данных master и msdb. Теперь появился способ возложить это на SQL Server 2022, но ждать этой возможности нам пришлось 10 лет…

Привет, меня зовут Артём Коршунов, я программист в ЮMoney. В нашей команде много разработчиков, и все они пишут огромное количество кода. Его нужно проверять, но встроенных валидаций для проверки не всегда хватает, из-за чего могут возникать проблемы. Рассказываю, с какими сталкивались мы, пока не попробовали DacFx с объектной моделью и не автоматизировали валидацию.

Резервное копирование и восстановление из объектного хранилища S3 — это новая функция, появившаяся с выпуском SQL Server 2022. Резервное копирование или восстановление можно делать в S3, расположенное локально или в облаке.

В мире Digital Experience платформ (DXP) понимание процессов работы с данными – ключ к достижению успеха. В этом материале – реальный сценарий внедрения продвинутого трекинга и аналитики с использованием Kentico Xperience 13 DXP. Не важно, работаете вы с Xperience by Kentico или с Kentico Xperience 13, принципы мониторинга активности остаются неизменными. Поэтому статья актуальна для обоих случаев.

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 - почему его лучше никогда не делать, почему все-таки иногда нужно делать и как его готовить.