Microsoft SQL Server *

Создаем песочницу для безопасного выполнения non-trusted DSQL-кода и возвращаем из него by design безопасный результат в высокопривилегированное кольцо

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

Сегодня хочу затронуть тему регламентного обслуживания баз данных MS SQL. А позже поговорим и про обслуживание баз PostgreSQL.

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

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

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

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

Для чего используют кластеризацию серверов СУБД? Вопрос не совсем праздный, особенно для крупных компаний. Если с кластеризацией/масштабированием серверов приложений, терминалов, web-серверов и т. д. все понятно и прозрачно, то вот с СУБД не всё так просто. Особенно для 1С систем.

Слой приложения persistence layer является в определённом смысле уникальным в смысле узкой направленности его функционала по сравнению с другими слоями приложения. Если рассматривать его только для работы с реляционными базами данных, то реализацию функционала слоя можно разбить на два основных варианта - с использованием ORM фреймворка и без использования ORM фреймворка. Каждый из этих вариантов можно реализовать достаточно универсальным образом.

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

Можно ли хранить данные, строить по ним отчетность, при этом обходясь без ETL процессов? Технически — да. Практически — только до первого серьезного роста данных.

Привет, Хабр! Меня зовут Алина, и в этой статье я расскажу о критически важном этапе, через который проходит любая data-driven компания.

Речь о переходе:
от построения отчетности напрямую из операционных баз (или через примитивное копирование в STG)
к структурированным ETL-процессам на специализированном ПО.

В нашем случае этим ПО стал SSIS — но важно подчеркнуть: сейчас мы используем NiFi с [N] процессорами для управления data pipeline. Однако именно опыт с SSIS стал для нас тем самым «мостиком» между хаотичным и осознанным подходом к данным.

P.S. Если хотите узнать про то, как мы организовали работу в NiFi — пишите в комментах, сделаем отдельный материал!

В этой статье — только про этап с SSIS. Не потому что он «лучший», а потому что:

Тема перехода на PostgreSQL весьма популярна, и почти на каждой конференции по PG обязательно есть парочка докладов на эту тему. Почему же эта тема до сих пор злободневна?

Когда мы начинали свой блог здесь на Хабре, наша первая статья была посвящена как раз задаче перевода больших баз данных MSSQL –> PostgreSQL. И первой причиной, из-за которой компании решаются на переход мы называли законодательство. А именно, необходимость для государственных и окологосударственных организаций, чьи информационные системы относятся к значимым объектам критической информационной инфраструктуры (ЗОКИИ) переводить свою работу на отечественное ПО. Прошло два года. И это всё еще основная причина.

Это не будет инструкция в стиле «делай раз», «делай два». Это будет про то, что большие базы в принципе очень тяжело и рискованно передвинуть (СУБД, платформа, окружение,…). И мы предлагаем собственный метод, как это сделать с гарантией отсутствия простоев бизнеса. Даже если что-то пойдет не так в «новой» системе, пользователи не должны страдать, а бизнес простаивать. Это главное!

KafkaRail гудел на фоне.

Паб The Broken Tag, где начиналось утро героев, только просыпался — запах старого эля, крошки лог‑файлов, и бильярдный стол под тусклым светом прожектора. Через узел маршрута /corp/news метропоезд пронёсся, как push‑уведомление на рассвете. День в Киберляндии начинался.

JSON откинул капюшон куртки BitStone Protocol с QR‑патчем на рукаве, кивнул Mr. Parseley и заказал, как обычно, Schema Fresca. Он прошёл к бильярдному столу английского пула, стоявшему под старым плакатом «Keep Calm and Close Tags», где RAMmy спорил с TryCatch о синтаксисе ударов.

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

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

Секретное оружие в .NET Core: Почему вы игнорируете мощь T-SQL?

Ваши LINQ-запросы становятся громоздкими? Производительность упирается в потолок? Возможно, вы упускаете нечто важное.

Эта статья — приглашение взглянуть на привычные инструменты под новым углом. Мы исследуем гибридный подход, который позволяет использовать весь потенциал Microsoft SQL Server, выходя за рамки стандартного взаимодействия через EF Core. Узнайте, как T-SQL может упростить сложные задачи, повысить производительность и сделать вашу архитектуру более гибкой.

Это не просто технический трюк, а переосмысление роли СУБД в современном приложении. Готовы узнать, как использовать "скрытые" возможности MSSQL и почему это может быть именно то, что нужно вашему проекту?

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

Назвать ту работу — работой мечты, сложно, как ни крути. Трудозатраты на сбор, обработку и визуализацию информации были так велики, что уход с работы в десять вечера был для меня настоящим праздником. Именно этот «спартанский» опыт вкупе с желанием доказать себе, что разобраться можно в чем угодно, побудил меня к изучению доселе неведомого для мира баз данных, языка запросов SQL, BI и ETL инструментов.

Как вы, возможно, уже поняли, в аналитику я попал не по зову сердца, а по воле случая. Хантер Томпсон внутри меня, конечно, предпочел бы писать колонки в модные журналы, вести собственный блог о литературе или теннисе, в который я играю с детства, ну или посвятить себя еще какой-то творческой ерундистике, окрыляющей не хуже Red Bull Cola. Не смейтесь, исчезновение этого напитка с полок магазинов стало для меня в свое время настоящей трагедией.

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

Итак, осознание того, что автоматизация процессов востребована на рынке и облегчает собственное существование, становится стартовой точкой долгого пути от полного непонимания азов работы с базами данных до уверенного владения всеми необходимыми инструментами для управления подразделением, обеспечивающим data-driven подход к решению задач внутри компании.

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

Далее предлагаем вашему вниманию перевод оригинальной статьи “How Many Indexes Is Too Many?”, который подготовила специалист «Автомакона». В статье детально рассматривается данная проблема и приводятся практические рекомендации по выбору подходящего количества индексов для повышения производительности.

Для начала давайте рассмотрим простой эксперимент. Возьмем популярную базу данных Stack Overflow любого размера, уберем все индексы из таблицы Users и запустим удаление одной строки командой DELETE.

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

В свете указанных обстоятельств Совет Европейского союза разработал специальный нормативно-правовой акт — Закон о цифровой операционной устойчивости (Digital Operational Resilience Act, сокращенно — DORA). Принятый в ноябре 2022 года, данный закон направлен на создание единой правовой основы, способствующей усилению защиты финансовых учреждений и иных операторов рынка от различных видов угроз, связанных с работой информационных и телекоммуникационных технологий (ИКТ).

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

В мире .NET разработки, работа с базами данных – неотъемлемая часть. Entity Framework Core (EF Core) предоставляет удобный способ взаимодействия с данными, но при работе с SQL Server, особенно в сложных сценариях, LINQ запросы могут уступать в производительности и гибкости T-SQL. Статья рассматривает эту дилемму, предлагая гибридный подход. Мы погрузимся в проблему: как эффективно использовать мощь T-SQL, не отказываясь от преимуществ EF Core? Обсудим интеграцию T-SQL через Raw SQL, Views, UDF и Stored Procedures. Раскроем лучшие практики: разделение ответственности, оптимизацию запросов, безопасность и тестирование. Поймем, как сочетать удобство ORM с производительностью SQL Server, применяя Data-Driven Design и, при необходимости, Domain-Driven Design. Статья – руководство для .NET разработчиков, стремящихся к оптимальному балансу между производительностью, гибкостью и удобством разработки при работе с SQL Server и EF Core.

Продолжаем обсуждать серверы в контуре высоконагруженных 1С-систем. В предыдущей статье я рассматривал типичные проблемы с серверами СУБД, а сегодня перейдем к серверам 1С. Причем не хочется, чтобы пост превратился в очередной универсальный перечень настроек сервера 1С на все случаи жизни. Поэтому будем смотреть на задачу через призму производительности системы. Главное, сначала увидеть картину целиком, понять причину и, исходя из этого, менять пусть те же самые настройки 1С.

Цель статьи — подсветить несколько достаточно распространенных, но не всегда очевидных проблем производительности ИТ-системы, находящихся на стороне сервера(ов) 1С.

Естественно, я не планирую разбирать очевидные вещи из серии «Хьюстон у нас проблемы. Нагрузка на CPU — 100%, пользователи в истерике». Но начну как раз с процессора :-). Тут есть что рассказать.

На этот раз более простая и красивая визуализация. Речь пойдет о том, как нарисовать историю выполнения SQL Agent jobs — как раз тех, с которыми все время имеет дело DBA.

В моей предыдущей статье я отображал метрики из записанного SQL profiler trace на листинг stored процедуры. Это идеально подходит к тестовым окружениям, но в production надо быть осторожным, и запись "частых" событий могут увеличивать CPU сервера и замедлять его работу.

@speshuric предложил использовать данные из Query Store. Там, правда, нет номеров строк. Но можно выкрутиться, так как есть смещения и можно посчитать количество переводов строки до смещения. Итак, сказано - сделано!

Вам интересно, какие индексы используются больше или меньше? Какие не используются вовсе? Какие таблицы и индексы самые большие? Очень легко создать такие диаграммы. Это и красиво, и полезно.

Приветствую всех хаброжителей и тех, кто читает мою статью. Меня зовут Александр, я являюсь ИТ директором с более 15-летним стажем, начинал в 2002 году обычным программистом в международной FMCG компании, что сильно повлияло на меня как человека и как ИТ специалиста.

Но статья не об этом, повествование пойдет о другом, об 1С и SQL, а именно о том, как быть если нужно выгружать данные из этой самой 1С, да еще, когда она не одна, да и в разных городах и странах. Трудился я в международной алкогольной компании и достался мне «зоопарк» ИТ систем (думаю, что многим понятно и известно, о чем я говорю). Среди этих систем была самописная ERP система с подчиненными базами (больше 100 штук) на базе СУБД Firebird и клиенты, написанные на Delphi и Microsoft С#, годами пока это все развивалось и росло, появились запросы и потребность в анализе данных и стали реализовываться различные выгрузки данных. Получаемые данные как тогда водилось стали выгружать в MS SQL в специально созданную базу (DWH) используя MS SSIS и потом трансформировались в OLAP кубы в MS SSAS. Еще была систем именуемая как «Бизнес-процессы» на базе 1С Бухгалтерия 1.6, с последующим обновлением и совместимостью, чтобы запустится на платформе 1С 8.3, на обычных формах с многокилометровыми модулями кода. Обшито все это было микросервисами (как сейчас это принято называть) и обменивалось между собой как-то, никому 100% не известно как.