Microsoft SQL Server *

Я уверен, что тебя беспокоит фрагментация твоего индекса.

Что такое фрагментация индекса и как она возникает 

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

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

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

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

Привет, Хабр и его читатели! 

Меня зовут Дарья Четыркина, я программист SQL в IT-компании «Автомакон». Если вы работаете с базами данных в Microsoft SQL Server и хотите, чтобы ваши запросы выполнялись быстро и без перебоев, эта статья для вас. Мы разберем динамический SQL — инструмент, который позволяет создавать гибкие запросы, но при неправильном использовании может замедлить работу системы и даже сделать ее уязвимой.

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

Привет, Хабр и его читатели! 

Меня зовут Дарья Четыркина, я программист SQL в IT-компании «Автомакон». Предлагаю обсудить проблему, которая может «съедать» производительность вашего SQL Server — фрагментация индексов, в конце статьи будут решения этой ситуации. Если вам важно, чтобы SQL Server всегда работал на полную мощность, эта статья — для вас.

Когда дело касается SQL Server, индексы — это ваши верные помощники: они организуют данные так, что сервер может находить нужные записи быстрее, чем обычный поиск. При этом со временем индексы начинают «разваливаться» и создают массу проблем. Фрагментация индексов — невидимый враг, который замедляет запросы, увеличивает нагрузку на сервер и лишает ваш SQL Server той оптимальной скорости, ради которой и создаются индексы. Разберемся, почему возникает фрагментация индекса, как она вредит производительности и что можно с этим сделать.

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

Гоняем тесты кода на T-SQL в сборке каждого пулл-реквеста, собираем Coverage, проходим Quality Gate. Особенности построения CI-пайплайна для проектов БД MS SQL Server.

Привет, Хабр!

Меня зовут Тимур Маннапов, и я самый обычный senior-разработчик в Mindbox.

На примере нашего продукта я расскажу, почему при загрузке CPU наполовину или меньше скорость параллельных вставок на SQL-сервере упирается в «невидимый» предел, а потом и вовсе замедляется. На нашем железе предел был в районе ~120 тысяч строк в минуту в одну таблицу. Поделюсь, как его преодолеть, не потратив годы на разработку и миллионы на новый сервер.

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

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

В базах данных нет серебряной пули, универсального рецепта. Мне захотелось проверить экспериментально один граничный случай использования in memory tables и natively compiled - когда в тесте все было хорошо, а на реальных данных начались тормоза.

Язык Transact SQL является процедурным расширением языка SQL и используется в СУБД Microsoft SQL Server. В этой статье мы рассмотрим использование некоторых элементов T-SQL для анализа данных. Сначала мы рассмотрим оконные функции, а затем поговорим о методах сводки (pivoting) данных и его отмены. При сводки данные преобразуются из состояния строк в столбцы, а при отмене обработки данные преобразуются из столбцов в строки, аналогично Excel.

Поговорим про падения производительности ИТ-систем, которые на первый взгляд связаны с дисковой подсистемой. Но это только «на первый взгляд».

Технические специалисты часто видят нагрузку на диски, очереди к ним и сразу появляется жгучее желание модернизировать дисковое хранилище.

В 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.

Назрела тут тема про обмены между базами данных 1С. Даже сузим круг и поговорим об обменах между гомогенными базами данных (базами данных с идентичными конфигурациями).

Ситуации когда бизнес предпочитает распределенные информационные системы централизованным системам – далеко не редкость. И чем ИТ-система больше, чем больше в ней пользователей и транзакций в единицу времени, тем сложнее поддерживать обмен между ее узлами на плаву. Обмен частенько тормозит и становится помехой пользователям и даже бизнесу...

Привет, Хабр! Меня зовут Павел Кузьмин, я работаю ведущим разработчиком в РСХБ-Интех. Однажды в своей работе мы столкнулись с острой необходимостью перенести БД объемом 1,4 ТБ (более 1,5 млрд строк) с MS SQL на PostgresSQL не более чем за 20 часов. Неожиданно для нас, все имеющиеся готовые варианты не подходили, поэтому мы решили взять библиотеку Npgsql на C# и написать свой код. В итоге созданное решение справилось с поставленной задачей за 13 часов. Рассказываем, как мы это сделали, и делимся кодом. Возможно, он вам пригодится в работе.

Продолжаем тему блокировок на сервере СУБД. Сегодня «нелогичные» блокировки. Нелогичные в кавычках, потому что с точки зрения пользователя они выглядят как обычные логические (Записки оптимизатора 1С (часть 6). Логические блокировки MS SQL Server в 1С: Предприятие), но природа их совсем другая.

При чтении логов из базы данных, а именно, из LDF данных, в большинстве случаев вы наткнётесь на такие функции в запросе sys.fn_dblog(null, null), sys.fn_dblog_xtp(null, null)

Читать из LDF Вы захотите по различным причинам, но так или иначе основная проблема будет «у нас откуда‑то списались деньги остатки, пропал товар, упал прод, разберитесь».

Допустим, Вы захотите воскресить удалённый, дропнутый объект из базы.

Типичный скрипт

Один из наших длительных проектов — это крупное многопользовательское SaaS-решение (CRM-система) основанное на микросервисной архитектуре и развернутое в облаке Azure. Изначально это был MVP, где все части (сервисы, базы данных и т. д.) располагались на одной виртуальной машине. Со временем проект вырос в облачное распределенное решение с множеством веб- и мобильных клиентов. 

В этой статье мы расскажем, как решили одну из проблем, с которой столкнулись в процессе разработки.

Продолжаем обсуждать вопросы, связанные с миграцией больших баз данных.

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

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

В этой статье я научу вас устанавливать Microsoft SQL Server 2022 на Linux и мы развернем тестовую базу данных от Microsoft в операционной системе Linux.

Мы будем использовать пакетным менеджером Yum для Linux дистрибутивов: RedHat (RHEL), CentOS, Scientific Linux и DPKG (Debian Package) – система управления пакетами в Debian и дистрибутивах на его основе, например Ubuntu и набирающем популярность Astra Linux, в связи с импортозамещением. Поэтому команды я приведу для обоих пакетных менеджеров. Так же рассмотрим универсальный способ запуска через Docker.

Microsoft SQL Server — система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов (диалект SQL) — Transact-SQL (T-SQL).

Для взаимодействия с СУБД MS SQL Server используются 2 основных способа:
1. Служебная программа sqlcmd
2. Microsoft SQL Server Management Studio (SSMS)

Конечно вы можете использовать привычный для вас DBeaver или DataGrip или любой другой инструмент администрирования базы данных.

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

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