Microsoft SQL Server *

Этот материал подготовил автор решения 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 при больших объёмах данных.

Готового мониторинга для SSRS и Power BI Report Server в сети нет - одни обзоры «SQL Server» с CPU и памятью. Собрал свой на Grafana: трейс упавших рассылок, тяжёлые отчёты, ночная нагрузка pbix и грабли с часовым поясом. Сборку отдаю целиком.

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'ом за вечер.

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

Temporal tables позволяют следить за историями изменений уровне движка. SQL Server сам хранит полную историю изменений каждой строки — без триггеров, без дополнительного кода и без самописного аудита. Фича появилась в SQL Server 2016 и к сегодняшнему дню обросла возможностями. Разберём, как все устроено и как использовать.

Ключевые аспекты проектирования и реализации SCADA-систем в автоматизированных системах управления технологическими процессами (АСУТП). Основное внимание уделяется интеграции с базами данных, такими как SQL Server, и использованию протокола OPC UA для взаимодействия с контроллерами.

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

У нас есть продукт и нам нужно рассчитать ключевые метрики, которые показывают здоровье продукта:

• DAU/MAU – вовлеченность
• Conversion Rate – конверсия в целевое действие (у нас это создание объявления)
• Retention – удержание пользователей
• LTV – жизненная ценность клиента
• ARPPU – средний доход с платящего пользователя

В статье разберем последовательный расчет с примером синтетических данных и готового кода на SQL.

Почему SUM() OVER (ORDER BY ...) иногда даёт неожиданный результат, даже когда запрос синтаксически правильный? В статье на практических примерах разбираю, как работают оконные фреймы в SQL, чем отличаются ROWS, RANGE и GROUPS, где чаще всего возникает путаница и как писать накопительные итоги и скользящие метрики без сюрпризов. Если используете оконные функции в аналитике, этот разбор поможет сделать их поведение предсказуемым и управляемым.

Всем привет! Я Игорь Эльяс — бэкенд-разработчик, сейчас работаю в МТС Веб Сервисы. Однажды мне досталась задача «перенести приложение в другую БД, за XX времени», где ХХ — короткий интервал с точки зрения потенциального объема работ при подходе «переделываем все по-нормальному — на Entity Framework» :-)

Проект на C#, изначальная БД — MS SQL + мы использовали самодельный ORM. Возможно, вы сейчас подумали — «очередное легаси!». И да и нет. Проект родился еще во времена Framework 2.0, но регулярно обновлялся и сейчас работает на .NET8. Он пережил десятки циклов рефакторинга, поэтому не безнадежен для доработок.

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