Microsoft SQL Server *

PRINT OBJECT_DEFINITION(OBJECT_ID('sys.objects'))

IF OBJECT_ID('dbo.Table1', 'U') IS NOT NULL
  DROP TABLE dbo.Table1
GO

CREATE TABLE dbo.Table1 (ColumnID INT PRIMARY KEY)
GO

EXEC sys.sp_helptext 'dbo.Table1'
SELECT OBJECT_DEFINITION(OBJECT_ID('dbo.Table1', 'U'))

CREATE VIEW sys.sql_modules AS
    SELECT object_id = o.id,
        definition = object_definition(o.id),
        ...
    FROM sys.sysschobjs o

Запасаем впрок

Задача

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер), до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя  было сделать проще как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей то лабораторной работы? Статья адресована прежде всего специалистам 1С избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.

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

В этой статье я бы хотел подробнее остановиться на Nasgrate

Основные преимущества Nasgrate

• в качестве хранилища SQL-запросов используются обычные текстовые файлы без привязки к какому либо языку программирования. Это упрощает процесс взаимодействия между командами, работающими с разными технологиями (например Node и Python), не приходится разбираться в особенностях язковых конструкций

• возможность автоматического создания миграции на основе анализа изменений в двух базах данных (пока поддерживается только MySQL, но в планах другие базы данных) или между двумя состояниями миграций одной базы данных

• наличие визуального интерфейса (а не только консольного клиента) позволяющего организовать просмотр изменений в наглядном виде

В мире Digital Experience платформ (DXP) понимание процессов работы с данными – ключ к достижению успеха. В этом материале – реальный сценарий внедрения продвинутого трекинга и аналитики с использованием Kentico Xperience 13 DXP. Не важно, работаете вы с Xperience by Kentico или с Kentico Xperience 13, принципы мониторинга активности остаются неизменными. Поэтому статья актуальна для обоих случаев.

Всем привет от команды ЮMoney ?

Делимся видеозаписями и главными мыслями митапа High SQL, который посвятили работе с данными в DWH на Microsoft SQL Server.

Кому советуем посмотреть доклады

◾️ Тем, кто планирует перебраться с Microsoft SQL в PostgreSQL, но всё ещё сомневается.

◾️ Тем, кто выбирает между ANTLR и DacFx и хочет научиться решать проблемы во время ревью TSQL-кода.

◾️ И тем, кто хочет узнать, зачем тестировать OLAP-кубы, что может пойти не так и какой результат дают автотесты силами разработчиков и тестировщиков.