Microsoft SQL Server *

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер), до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя  было сделать проще как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей то лабораторной работы? Статья адресована прежде всего специалистам 1С избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.

Common Table Expressions (CTE) или обобщенное табличное выражение, впервые появилось в версии SQL Server 2005, и это простой способ разбить сложный запрос T-SQL на несколько запросов, что придаёт больше гибкости и управляемости. CTE во многом очень похожи на представления. В отличие от представления, которое можно создать один раз и потом использовать в других запросах, CTE привязан только к одному запросу. В Books Online есть несколько отличных примеров CTE, включая и рекурсивные CTE. Вместо того, чтобы продемонстрировать их устройство на своих примерах, в этой статье будут использоваться примеры из Books Online. Чтобы попробовать эти примеры у себя, используйте один из ранних образов базы данных AdventureWorks.

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

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

В двух последних статьях приводились примеры агрегации WITH ROLLUP и WITH CUBE. В SQL Server 2008 появился новый, более мощный синтаксис, совместимый с ANSI SQL 2006. В этой статье будет рассказано об этих изменениях.

Несмотря на избитость темы и многочисленные рекомендации избегать OR в выражениях WHERE/ON SQL запросов, жизнь вносит свои коррективы. Иногда сама постановка задачи подразумевает необходимость использовать OR. Я не собираюсь здесь рассматривать простые случаи, а сразу возьму быка за рога и рассмотрю случай, когда OR должно привести к двум разным выборкам по разным индексам одной и той же таблицы.

Популярная среди администраторов баз данных SQL Server Management Studio (SSMS) для подключения к серверам баз данных (по версию 18.12.1 включительно) использовала System.Data.Sqlclient (SDS). Новая версия SQL Server теперь поставляется с библиотеками Microsoft.Data.Sqlclient (MDS). Пакет Microsoft.Data.SqlClient теперь доступен на NuGet и становится основным способом доступа к данным для SQL Server. Этот пакет поддерживает как .NET Core, так и .NET Framework. Создание нового SqlClient в новом пространстве имен позволяет старому System.Data.SqlClient и новому Microsoft.Data.SqlClient жить бок о бок, хотя это и не происходит автоматически.

В предыдущей статье говорилось о том как  работает агрегат WITH ROLLUP. В этой статье мы рассмотрим, как реализована агрегация WITH CUBE. Как и предложение WITH ROLLUP, предложение WITH CUBE позволяет просчитать несколько «уровней» агрегации в одном операторе. Разницу между двумя этими агрегатами давайте рассмотрим на примере. Мы будем использовать те же вымышленные данные о продажах, что и в прошлый раз.

SQL Server поддерживает работу с данными типа JSON, и имеет для этого необходимый функционал, в который входит функция ISJSON, для проверки, соответствует ли значение типу JSON. Она вернет 0, если это не правильный JSON, и 1, если JSON правильный. Если JSON содержит недопустимые данные, функция помогает это обнаружить.

Замахнемся сегодня на RLS.

Обсуждать будем проблемы по нашему профилю, связанные с производительностью 1С:Предприятие. Но, в целом, этот материал может быть полезен и не только 1С-никам.

Почему запросы с RLS часто такие долгие?

Какие есть варианты их ускорить?

Новая опция WAIT_AT_LOW_PRIORITY в команде DBCC SHRINKDATABASE предоставляет возможность снизить конкуренцию за блокировки во время сжатия базы или файла, заставляя сжатие пережидать окончание других операций на сервере, блокирующих сжатие. Это похоже на опцию WAIT_AT_LOW_PRIORITY для онлайн операций с индексами, но с некоторыми отличиями.

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

Сначала я думал просто перечислить наиболее распространенные проблемы, возникающие при переходе с MS SQL на PostgreSQL. Но решил, что просто перечисление будет мало информативным. Поэтому, пока ограничился наиболее частой проблемой, приводящей к деградации производительности при переходе с MS SQL на PostgreSQL. Если статья окажется нужной, то продолжу рассматривать остальные проблемы.

Технология Intel® QuickAssist (Intel QAT) в SQL Server 2022 призвана обеспечить аппаратное ускорение и возможности разгрузки процессоров от функций сжатия и распаковки резервных копий баз данных. Использование этой технологии даёт заметное снижение нагрузки на процессоры, времени создания резервных копий, а также уменьшает занимаемое под хранение копий место.

В SQL Server 2022 интегрированы возможности сжатия/распаковки с помощью библиотеки QATzip и связанной с ней библиотеки Intel Intelligent Storage Acceleration Library (ISA-L). Intel ISA-L устанавливается вместе с QATzip, и наличие их является необходимым условием для включения аппаратного ускорения Intel QAT на уровне экземпляра.

QATzip в настоящее время поддерживает передачу нагрузки резервного копирования на мощности периферийного аппаратного устройства в виде адаптера PCIe, либо на встроенный чипсет, а если этого нет, может обеспечивать программное сжатие по тем же алгоритмам.

Параллелизм – это возможность выполнения запросов сервером СУБД в нескольких потоков. По умолчанию в настройках SQL Server параллелизм не ограничен и потенциально для выполнения запроса могут использоваться все ядра всех процессоров (max degree of parallelism= 0). В то же время, в системах 1С вендор настоятельно рекомендует установить max degree of parallelism = 1, и, соответственно, один запрос будет использовать только одно ядро.

Почему так и что же с этим всем делать? Давайте разбираться.

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

В новой версии SSRS мы проделали значительную работу по обеспечению лучшего уровня доступности, и добавили новые возможности, которые включают в себя:

• Расширенную поддержку Windows Narrator¹ для новых клиентских операционных систем Windows и Windows Server.

• Улучшения в безопасности.

• Улучшения производительности браузера с помощью Angular.

• Исправлены баги, ухудшавшие доступность.

• Поддержка каталога сервера отчетов для экземпляров SQL Server 2022².

•  Повышена надежность.

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

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

Параллельный просмотр (сканирование) буферного пула — это новая функция SQL Server 2022, призванная обеспечить лучшую масштабируемость и значительно повысить производительность обслуживания вашей рабочей нагрузки.

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

Сканирование буферного пула — это распространённая внутренняя операция, потенциально требующая перебора миллионов буферов. Например, экземпляр SQL Server с пространством буфера в 1 ТБ требует просмотра всего буферного пула с перебором больше 130 миллионов буферов. Это справедливо для любой редакции SQL Server, независимо от использования буферного пространства, поскольку, чтобы найти буферы определенной базы данных, просмотр буферного пула всегда перебирает весь массив дескрипторов буферов.