Microsoft SQL Server *

Это вторая часть разбора ошибок конфигурации MS SQL Server под 1С. Первая часть — про планирование и развёртывание: профили нагрузки, дисковая подсистема, баланс ресурсов, инсталляция и виртуализация, здесь первая часть. Там же была описана типичная история дефолтного развёртывания сервера на прод или «как не надо».

Побудившая меня написать всё это предыстория такова: сервером СУБД под 1С обычно занимается системный администратор в паре с 1С‑разработчиком или франчом, уровень СУБД теряется где‑то между их компетенциями. Первая часть была про то, как этот разрыв закладывает проблемы при развёртывании. Вторая (эта) — про то, как этот же разрыв в компетенциях мешает найти причину, когда система уже тормозит «и всё висит, и прод лежит».

Напомню и про два профиля настроек для СУБД из первой части: первый — тяжёлая ERP с одной большой базой, второй — стопка из сотни бухгалтерских баз на одном инстансе. Настройки, о которых пойдёт речь ниже, зависят от профиля использования так же, как зависела схема размещения данных из предыдущей части. К концу статьи станет видно, из чего складывается ответ на вопрос «почему тормозит», и что железо в этом ответе часто ни при чём.

Все звонки начинаются как под копирку

«База висит». «Окна не открываются». «К вечеру всё тормозит так, что документ не провести». Жалобы на сервер 1С звучат одинаково в рознице, в производстве и в бухгалтерии, но причины под одинаковыми симптомами всякий раз оказываются разными. Посмотреть, какие типы ожиданий превалируют на сервере, найти тяжёлые запросы, указать в каких местах и что можно поправить. За каждым этим шагом стоит достаточно узкая компетенция администратора баз данных, отдельная профессия — DBA. Разработчики этим навыком, как правило, не владеют, у них другая специализация, отсюда следствие: код, который прекрасно работает на тесте, в проде начинает работать очень тяжело. На тесте нет ни боевых объёмов, ни конкуренции за строки, ни сотни пользователей, проводящих документы одновременно. В проде есть всё и сразу.

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

Всем привет!
Я порядка 15 лет занимаюсь администрированием СУБД, а в данный момент работаю на должности старшего инженера по базам данных.

За свою карьеру мне довелось попробовать в работе разные системы мониторинга СУБД, но больше всего мне нравился Spotlight for SQL Enterprise. Это, наверное, лучшая система мониторинга, с которой мне доводилось работать.

К сожалению, Quest Software ушел из РФ, и компании, которые вынуждены соблюдать санкционные режимы, больше не могут им пользоваться. В попытках найти близкие альтернативы я понял, что ничего похожего на рынке нет, и понял: вот она, ниша, в которой можно проявить себя и применить весь свой опыт! :=)

Так появился Lumen.

Сначала — об архитектуре.
Lumen имеет аналогичную архитектуру со Spotlight, есть Diagnostic Server который устанавливается на Windows host. В нем настраиваются подключения к целевому серверу. На целевой сервер ничего устанавливать не нужно, необходимо лишь наличие прав на стороне сервера.

За много лет работы с MS SQL Server я много раз наблюдал одну и ту же последовательность событий.

Сервер под 1С устанавливается методом «далее — далее — готово». Полгода всё работает. Потом наступает пик, сезон продаж или закрытие года, и система встаёт. Отдел сопровождения ищет причину, находит десяток версий и ни одного ответа. Руководство нервничает. Решение рождается само собой, купить новый сервер, так как «этот уже не справляется».

Вопрос, который витает немым подтекстом, звучит просто. С чем именно он не справляется?

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

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

Возьмите Oracle Exadata. Никому не придёт в голову привезти стойку, включить питание и пройти установку кнопкой «Далее». Конфигурацию считают под профиль нагрузки. Схему размещения данных согласовывают заранее. Приёмку и ввод в эксплуатацию закладывают отдельным этапом работ, с отдельными сроками и бюджетом, и зовут людей, которые это уже проходили. Никто при этом не спрашивает, к чему такие сложности, всем понятно, какого класса машина приехала.

1. Зачем это нужно

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

Продолжаем классифицировать ошибки, с которыми сталкивается пользователь при работе в 1С.

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

Разбираемся как увидеть, разобраться и побороть.

Этот материал подготовил автор решения Database Compression Tool (DCT), представленного на Инфостарт Маркетплейс. Мы публикуем его от имени компании, чтобы поделиться практической экспертизой наших авторов. В статье разработчик DCT рассказывает, как устроена свертка больших баз 1С, какие ошибки могут привести к нарушению учета и что необходимо учитывать при работе с базами объемом в сотни гигабайт и несколько терабайт. Мнение, выводы и практические рекомендации в материале принадлежат автору решения.

Заявка выглядит буднично: ERP размером 2,3 терабайта, бэкап перестал влезать в ночное окно, место в СХД заканчивается быстрее, чем согласовывается его закупка. Диски можно докупать до бесконечности, но в какой-то момент кто-то произносит слово «свёртка». И тут выясняется, что удалить из работающей учётной системы две трети строк и ничего при этом не сломать заметно сложнее, чем звучит.

Переход крупных корпоративных систем на отечественные СУБД остается одной из наиболее актуальных задач последних лет. Однако основная сложность подобных проектов заключается не столько в переносе данных, сколько в сохранении работоспособности существующих приложений, написанных под Microsoft SQL Server и Oracle Database.

Именно поэтому развитие Digital Q.DataBase сосредоточено сразу на нескольких направлениях: расширении совместимости с зарубежными СУБД, автоматизации миграции и создании инструментов, позволяющих минимизировать объем ручной доработки приложений.

Версия 18.2 стала одним из наиболее масштабных обновлений платформы. В релиз вошли изменения архитектуры продукта, значительное развитие совместимости с Microsoft SQL Server и Oracle Database, новые возможности мастера миграции, первая версия службы построения отчётов, совместимой с SQL Server Reporting Services, а также десятки других улучшений.

Подробнее об изменениях - в этой статье.

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

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

На одном из проектов заказчика объём базы 1С:ERP достиг 16 ТБ, а регистр накопления «СебестоимостьТоваров» вырос до 4 ТБ и 2 млрд строк. При таких объёмах оптимизация перестала быть опцией и превратилась в обязательную задачу.

Симптомы были типичными для системы, которая упёрлась в пределы физического хранения: запросы к себестоимости выполнялись десятки минут, расчёт себестоимости тормозил, а серверный диск работал на пределе возможностей.

Были применены стандартные подходы к оптимизации: работа с индексами и статистикой, а также дефрагментация. Существенного эффекта они не дали.

Для решения задачи использовалось секционирование (партиционирование) таблиц на уровне MS SQL Server. Но, как оказалось, у 1С и секционирования сложные отношения. 

Меня зовут Владимир Андрейков, я руководитель группы разработки в GRI. Эта статья — разбор практического кейса из проекта заказчика. Она будет полезна тем, кто работает с крупными внедрениями 1С:ERP и упирается в ограничения SQL Server при больших объёмах данных.

JOIN - крайне популярная операция в SQL, о которой еще и спрашивают на 99% собеседований на программиста. Но когда начинаешь впервые разбираться с ней, то постоянно путаешься, какие таблицы соединять и когда именно.

В этой статье простыми словами и с великолепной графикой расскажу, что такое JOIN в SQL, что такое Foreign Key, какой тип JOIN когда использовать - INNER или OUTER - и зачем вообще.

Эта статья о библиотеке Microsoft.SqlServer.TransactSql.ScriptDom и опыте её использования для тех, кто работает с T-SQL — разработчиков и администраторов. Если нужно анализировать зависимости в коде, менять структуру, разбирать сложные запросы или генерировать код, то эта библиотека — то, что нужно.

В предыдущей статье я разобрал что умеет REDB на практике: code-first схемы, LoadAsync без Include, LINQ с оконными функциями, деревья, redb.Route и redb.Tsak. Если не читали — начните с неё, она даёт общую картину.

Теперь начинаю цикл «REDB изнутри» — серия статей про устройство хранилища: как хранятся объекты и свойства, как работают схемы и кэш структур, как LINQ превращается в SQL, как устроены деревья, права, оконные функции. Всё с реальным SQL под капотом.

Первая статья цикла — про саму базу данных. Без понимания схемы таблиц всё остальное будет висеть в воздухе.

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

Взгляд на экосистему SQL-разработки под MS SQL SERVER через призму контроля качества кода. Обзор существующих инструментов, описание самостоятельной наработки для линтинга T-SQL кода.

На протяжении уже лет пятнадцати мы сталкиваемся с вопросом типа: «А вы уверены, что без обрезки никак?». Речь идёт о многотерабайтных базах 1C: десять лет назад это были базы 1-2 Тб, а сейчас это уже десятки Тб. Специалисты меняются, железо становится мощнее, но вопрос остаётся.

Пожалуй, можно поделить участников этого опроса на две группы: «Резать к чёртовой матери» и «Полный бред резать базу – нужно правильно обслуживать и заложить нормальную архитектуру».

Привет, Хабр! Меня зовут Евгений Грибков, я ведущий разработчик в центре технологий VK. В этой статье я покажу решение, к которому мы с коллегами пришли при работе над одной из наших внутренних систем.

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

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

Black-box подразумевает, что у пентестера нет никакой внутренней информации: ни списков IP, ни учётных данных, ни описания архитектуры. Только доменное имя - и вперёд. Звучит как ограничение, но на практике это зачастую преимущество: вы смотрите на инфраструктуру глазами реального злоумышленника.

Целью данного пентеста является проверка возможности компрометации внутренней инфраструктуры через веб-приложения.

Вокруг резервного копирования Microsoft SQL Server обычно обсуждают либо штатные BACKUP DATABASE ... TO DISK, либо интеграцию с большими корпоративными системами защиты данных. Между этими двумя мирами есть важный слой: VDI (Virtual Device Interface). Именно через него внешнее приложение может встроиться в процесс резервного копирования и восстановления так, чтобы SQL Server писал не в обычный .bak по своему усмотрению, а в управляемый приложением поток данных.

В этой статье разберем небольшой, но вполне рабочий проект на C++, который реализует РК и ВД для MS SQL Server через VDI в ПО «Береста».

Утилита поддерживает:

• полный, дифференциальный и логический backup;

• restore одной базы или всех найденных;

• striped backup/restore в несколько потоков;

• Windows-аутентификацию и SQL-аутентификацию;

• работу с SQL Server 2008-2022.

Почему VDI?

Если задача ограничивается локальным резервным копированием на диск, VDI не нужен: достаточно стандартных T-SQL команд. Но как только появляется внешняя система резервного копирования, картина меняется.

СРК обычно хочет сама управлять:

• жизненным циклом задания;

• маршрутом потока данных;

• параллелизмом;

• политиками хранения;

• журналированием и обработкой ошибок.

И здесь VDI становится мостом между SQL Server и внешним приложением. SQL Server продолжает выполнять привычные BACKUP и RESTORE, но вместо физического файла работает с виртуальными устройствами. А уже клиент VDI читает или записывает данные туда, куда считает нужным: в локальные файлы, сетевое хранилище, object storage, дедуп-слой или собственный медиасервер.

Если у вас стоит Always On Availability Groups, вы наверняка бывали в такой ситуации: в SSMS всё зелёное, дашборд показывает «Synchronized», а пользователи звонят с жалобами на тормоза. Смотришь на secondary — а там redo_queue_size 600 МБ, реплика отстаёт на полчаса. Ни одного алерта.

У нас это случилось на продуктивном кластере с 1С: secondary молча отвалился в SYNCHRONIZING, а мы узнали только при плановом переключении. Полтора часа redo queue. Стало понятно, что встроенный дашборд SSMS — это не мониторинг. Дальше — как мы это закрыли Zabbix'ом за вечер.