Microsoft SQL Server *

Поговорим о блокировках в 1С:Предприятие. Идея написать эту статью появилась «по просьбам слушателей». Постараюсь максимально простым языком, без зауми рассказать о природе блокировок и что с ними делать. В один пост весь материал помещать не буду — громоздко, поэтому сегодня речь пойдет о логических блокировках сервера СУБД.

С точки зрения конечного пользователя проблема избыточных блокировок выглядит почти одинаково — замедление при выполнении операций и/или ошибка. Но природа блокировок бывает разной и решения тоже разные.

В предыдущей статье обсуждалась функция ROW_NUMBER. Сейчас же мы рассмотрим другие функции ранжирования: RANK, DENSE_RANK и NTILE. Начнем с RANK и DENSE_RANK. Эти функции по функциональности и реализации аналогичны ROW_NUMBER. Разница в том, что ROW_NUMBER присваивает уникальное (возрастающее) значение каждой строке без учета связей в значениях ORDER BY, а функции RANK и DENSE_RANK присваивают одно и то же значение строкам, имеющим одинаковое значение ORDER BY. Разница между функциями RANK и DENSE_RANK заключается в том, как значения присваиваются строкам. Проще всего проиллюстрировать разницу между всеми этими функциями на простом примере:

Эта статья носит своей целью продемонстрировать другой подход в анализе проблем производительности в системах 1С:Предприятие с применением журнала регистрации (ЖР) и технологического журнала (ТЖ).

Напомню, что ЖР логирует действия пользователей — кто, когда в каком объекте внес изменения, с какого компьютера, каким сеансом и т. п. ТЖ — это средство для логирования уже самой платформы. Для расследования проблем производительности информация из журналов очень полезна, но основное время уходит на её поиск, сопоставление с другими метриками и счетчиками мониторинга.

При проведении расследований мы сами часто сталкиваемся с проблемой длительной обработки и сопоставления данных журналов 1С с остальными метриками. И вот наконец руки дошли до парсинга журналов. С точки зрения анализа производительности все данные журналов нам не нужны. А какие нужны?

Вот! В этом как раз вся «соль» идеи.

Сегодня обсудим общие вопросы, связанные с миграцией баз данных на новую платформу. Как обычно, акцент сделан на системах 1С:Предприятие, как самых популярных на российском рынке. Но многие рекомендации универсальны и годятся для всех ИТ-систем.

Эта статья о том, что нового появилось в SQL Server Management Studio 20 (SSMS), и является второй из серии статей на эту тему. Первую статью можно почитать тут: Upcoming changes for SQL Server Management Studio (SSMS) — Part 1.Заключительной статьёй в серии является: Upcoming changes for SQL Server Management Studio (SSMS) — Part 3. SSMS 20 может удивить Вас сразу после установки, когда вдруг обнаружится что по умолчанию предполагается шифрованное соединение SSMS с сервером баз данных. На то, чтобы помочь пользователям SSMS справится с этой проблемой и добиться лучшей защиты соединения с помощью новых механизмов шифрования SQL Server 2022, как раз и направлена эта статья.

Приветствую всех читателей Хабра! Меня зовут Михаил, я администратор DBA в компании «Автомакон». На данный момент работаю на проекте для «ВкусВилл».

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

Четыре функции ранжирования: ROW_NUMBER, RANK, DENSE_RANK и NTILE появились в SQL Server 2005 и отличаются от обычных скалярных функций тем, что результат, который они выдают для строки, зависит от других строк выборки. От агрегатных функций они отличаются тем, что возвращают только одну строку для каждой строки на входе, т. е. они не объединяют набор строк в одну. В этой статье мы рассмотрим ROW_NUMBER — самую простую из всех функций ранжирования.

Материал подойдет для студентов и тех кто только начинает создавать распределенные базы данных.

Всем доброго дня, дорогие Хабровчане! Решил поделиться созданием связаннх серверов, поскольку информации в интеренете много, но не везде описываются все мелочи.

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

Однако из-за ряда ограничений SQL Server постепенно теряет своих пользователей. SQL Server имеет достаточно сковывающую лицензию и стоимость обслуживания, растущую по мере увеличения размера базы данных или числа клиентов. Ее максимальный размер составляет 10 ГБ, а буферный кэш — 1 МБ. Она работает только под Windows.

Переманить же пользователей SQL Server может PostgreSQL — полностью бесплатная база данных с открытым исходным кодом. Эта база данных может похвастаться поддержкой международного сообщества и доступна под Windows, Mac, Linux, FreeBSD и Solaris. Кроме того, для нее существуют множество опенсорсных дополнений.

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

В предыдущей статье Внутренняя оптимизация операций изменения для индексов было рассказано о том, что планы запроса для UPDATE состоят из двух частей: курсора чтения, который выбирает строки, которые необходимо изменить, и курсора записи, который и выполняет изменения. SQL Server использует такую логику изменения, следуя которой курсоры чтения и записи в плане с UPDATE выполняются двумя отдельными шагами или фазами. Другими словами, фактическое изменение в строке не должно влиять на выбор строк изменения. С этим связана описанная ниже проблема, для преодоления которой нужно обеспечить такую работу курсора записи в плане с UPDATE, чтобы он не влиял на курсор чтения, эта проблема известна под названием «Halloween Protection». Такое имя она получила поскольку была обнаружена исследователями IBM более 30 лет назад в Хэллоуин.

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

File system level backup  в Postgres это первое чему нужно научится при использовании Postgres . Никакие pg_dump \ pg_restore не заменят Полный бэкап на уровне файлов. File system level backup это первая ступень для подготовки к Continuous archiving. Понимание архитектуры хранения – это фундамент, по которому можно понять сможете ли Вы жить с Postgres на больших объемах или у Вас другой путь?

Статей о селектах хватает, попробуем про апдейты. "ТОП-100" вопросов не обещаю - тут бы с одним разобраться. Разработчиков OLTP-систем под MS SQL Server и кандидатов на подобные вакансии приглашаю под кат.

Код на T-SQL, и он идеален. Атомарности нет, целостность вернём ручными апдейтами, изоляция с дюрабилити только мешают. Программируем без оглядки на ACID, который жив лишь в статье википедии.

В нескольких предыдущих статьях обсуждалось, как в SQL Server реализована агрегация, были рассмотрены операторы агрегирования потока и хеш-агрегат. Я также использовал хеш-агрегат в качестве примера в статье Введение в распараллеливание исполнения запроса. В этой статье мы рассмотрим частичную агрегацию. Частичная агрегация — это метод, который SQL Server использует для оптимизации параллельной агрегации. Прежде чем начать, я хочу отметить, что рассуждения о частичной агрегацию можно найти в книге Inside Microsoft SQL Server 2005 : Query Tuning and Optimization (см. страницу 187 внизу).

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

Речь сегодня пойдет об отказоустойчивости и даже о катастрофоустойчивости.

Почему вроде бы правильно настроенное архивирование базы данных не всегда помогает спасти систему в случае инцидентов? Этим вопросом я, наверное, многих даже задел за живое. Одних тем, что сама постановка вопроса им кажется абсурдной – у этой группы админов все настроено идеально, работает как часы и они готовы к любым катаклизмам. А кого-то тем, что напоминаю о тех самых инцидентах, когда возвращаться в тот день, даже мысленно, совсем не хочется.

В рамках проектов аудита производительности мы обязательно проверяем систему заказчика на предмет используемых средств отказоустойчивости и катастрофоустойчивости. И если есть основания, обязательно предоставляем рекомендации по улучшениям. Соответствующий раздел в своё время стал обязательным в каждом отчёте аудита не на пустом месте. За долгие годы мы встречались с таким количеством ситуаций, что можно начинать писать книгу :) Сама по себе ситуация краха системы редкая, поэтому вопросы отказоустойчивости далеко не везде в приоритете, а с учетом распространения в последние годы разнообразных ЦОД’ов, появляется большой соблазн снять с себя ответственность за целостность базы данных и непрерывного доступа к ней. Так что, с появлением ЦОД’ов люди совсем расслабились. А зря.

 Опишу несколько характерных примеров из нашей практики, с которыми мы столкнулись, причем в роли спасателей клиентской инфраструктуры и данных. Иногда на кону стояло само существование БД, иногда – интервал потерянных данных, иногда – время простоя бизнеса.

Мы — SQL команда Срочного рынка Московской Биржи, занимаемся разработкой и сопровождением бэкофиса торгово-клиринговой системы Spectra с момента ее возникновения. Срочный рынок Московской Биржи — это более 500 фьючерсных и 30000 опционных инструментов, несколько миллионов сделок в день.

Торгово-клиринговая система Срочного рынка (ТКС Spectra) изначально строилась на основе MS SQL, и за пару десятков лет прошла сложный путь от нескольких серверов БД до огромной системы с сервис-ориентированной архитектурой. Долгое время вся бизнес-логика системы разрабатывалась в программном слое на серверах MS SQL: и матчинг заявок, и расчет обеспечения, и управление клиентами были реализованы на T-SQL.

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

В этой статье мы хотим рассказать об эволюции нашей системы разработки на SQL.

Одним из наиболее важных применений CTE являются рекурсивные запросы, для которых CTE является фактически единственным средством реализации. Как отмечалось в предыдущей статье, в Books Online есть несколько примеров использования CTE, включая и рекурсивный CTE. Тут мы будем использовать эти примеры из Books Online, используя один из ранних образов базы данных AdventureWorks.

Рекурсивные CTE все сделаны по одному шаблону. Тело CTE представляет собой запрос с UNION ALL, который объединяет один или несколько подзапросов называемых закреплёнными элементами, которые заполняют набор результатов. Кроме закреплённых элементов есть один или несколько рекурсивных подзапросов, называемых рекурсивными элементами, которые возвращают оставшуюся часть результирующего набора. Эти рекурсивные подзапросы ссылаются на сам рекурсивный CTE. Получается, у нас есть один или несколько закреплённых подзапросов и один или несколько рекурсивных подзапросов, объединенных UNION ALL. 

Бэкап в 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.