SQL-Ex blog

Пересказ статьи Udaya Veeramreddygari. Oracle Performance Tuning: Practical Techniques Every DBA Should Master

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

Начнем с самого простого: статистика и планы выполнения

Прежде чем перейти с сложным стратегиям настройки, всегда проверяйте актуальность вашей статистики. Оптимизатор Oracle на основе стоимости всецело опирается на точность статистики для принятия умных решений относительно путей выполнения запросов. Мне приходилось видеть запросы, которые выполнялись в 10 раз медленнее только потому, что кто-то забыл обновить статистику после загрузки большого объема данных. Продолжить чтение "Настройка производительности в Oracle: практические методы, которыми должен владеть каждый DBA"

§ С Новым Годом, коллеги!
Здоровья и благополучия в новом году!

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 25 (Learn)		6		10
 122 (SELECT)		4		8
 27 (Learn)		2		7

§ Авторы недели на форуме

Автор		Сообщений
 pegoopik 	7
 selber 	2
 Rujan 	2

Продолжить чтение "Новости за 2025年12月27日 - 2026年01月02日"

Пересказ статьи Tudor Golubenco. Going down the rabbit hole of Postgres 18 features

Особое внимание в статье уделяется таким фундаментальным функциям, как инфраструктура асинхронного ввода-вывода и поддержка Oauth 2.0, оптимизации производительности, например, пропуску сканирования btree, а также долгожданным функциям, например, встроенной поддержке UUIDv7.

Но при свыше 3000 вкладах в релиз имеется множество других изменений помимо упомянутых, о которых вы можете захотеть узнать. Мы поставили себе задачу осветить как можно больше изменений и в итоге рассмотрели около 30 функций в этой длинной записи блога (почти 5000 слов).

Если вы все это не прочитаете, я вас не виню, итак, вот попытка на "слишком много букв":
Продолжить чтение "Ныряем в кроличью нору возможностей Postgres 18"

Пересказ статьи Mamadou Cisse. Booleans vs Integers in Databases: Understanding the Trade-Offs

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

При проектировании базы данных разработчики часто сталкиваются с выбором казалось бы простого решения: следует ли использовать булевы значения или целые для представления поля? Хотя на первый взгляд разница может показаться тривиальной, выбор может оказать существенное влияние на хранилище, поддержку и масштабируемость. Давайте исследуем "за" и "против" каждого подхода, сосредоточив внимание на размере хранилища, накладных операционных расходах и обслуживании в долгосрочной перспективе.
Продолжить чтение "Булевы значения и целые числа в базах данных: понимание компромиссов"

Joe Celko, Missing Data

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

Игнорирование чего-либо говорит само за себя. В SQL мы очень часто используем NULL, когда у нас нет значения. Хотя использование NULL является спорным, они действительно дают нам единый, согласованный и чётко определённый набор правил для обработки отсутствующих значений. Но с точки зрения моделирования с ними есть проблемы. Помимо специальных вычислительных правил и общего принципа, что «NULL распространяются», который может быть сложным для изучения, более фундаментальная проблема заключается в том, что универсальный NULL в SQL охватывает по крайней мере два очень разных случая. Доктор Кодд позже исправил это в пересмотренной версии своей реляционной модели, добавив типы отсутствующих значений A и I. В одном случае значение неизвестно, но сущность обладает атрибутом. С таким типом NULL всегда возможно, что мы обнаружим (известное) значение. Пример, который мне нравится приводить: когда я ношу шляпу, всегда возможно, что у меня может быть цвет волос. Чтобы быть очень полным в выборе значений по этой шкале, я мог бы также включить «лысый» или даже «варикозные вены и пигментные пятна» в домен моих значений для цвета волос. С таким типом NULL (теоретически) возможно придумать какое-то осмысленное значение или маркер.

Второй тип NULL никогда не будет иметь значения, потому что сам атрибут отсутствует у сущности. Я могу с уверенностью сказать, как примат, что у меня не вырастут перья и не появится вариант цвета перьев. Такой тип NULL возникает в OUTER JOIN и других конструкциях, которые их генерируют. Например, конструкции GROUPING SETS, ROLLUP и CUBE должны иметь предикат для проверки NULL, который был создан, в отличие от NULL, который был в исходных данных. GROUPING (<список ссылок на столбцы>) возвращает двоичное число, в котором каждая позиция с единицей соответствует созданному NULL.

Продолжить чтение "Отсутствующие данные"

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 45 (DML)		8		7
 1 (Learn)		2		19
 24 (Learn)		2		12

§ Авторы недели на форуме

Автор		Сообщений
 rock_4 	8
 selber 	3
 hongweibin	3
 Канатоходец	2

Продолжить чтение "Новости за 2025年12月20日 - 2025年12月26日"

Пересказ статьи Vaitheeswaran L M. PostgreSQL Internals: Heaps, Pages, and CTIDs

Строки не просто "сидят" в таблице в PostgreSQL. Они живут внутри страниц, перемещаются при обновлении и всякий раз получают новые "адреса" (CTID). Давайте разберемся подробнее и посмотрим, как это работает на самом деле.

1. Куча: Движок хранилища PostgreSQL

Когда вы создаете таблицу в PostgreSQL, она хранится как куча.

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


Продолжить чтение "PostgreSQL изнутри: кучи, страницы и CTID"

Пересказ статьи Brent Ozar. Which Should You Use VARCHAR or NVARCHAR?

Вы строите новую таблицу или добавляете столбец, и вы хотите знать, какой тип данных использовать: VARCHAR или NVARCHAR?

Если вам необходимо хранить данные Unicode, выбор сделан за вас: NVARCHAR говорит, что это буду я.

Но если вы не уверены, то можете подумать: "Я должен использовать VARCHAR, поскольку он занимает вдвое меньше места". Я это знаю, потому что чувствовал то же самое, но множество комментаторов указали мне на это, когда я опубликовал ответ в «Office Hours» о том, что по умолчанию я использую VARCHAR. Один за другим разработчики говорили мне, что я неправ и что в 2025 пришло время вместо этого по умолчанию использовать NVARCHAR. Давайте проведем эксперимент!

Чтобы выяснить это, давайте возьмем большую базу данных Stack Overflow и создадим две копии таблицы Users. Я использую здесь таблицу Users, чтобы сделать демонстрацию краткой и понятной, поскольку у меня нет возможности целый день загружать гигабайты данных (и перезагружаться, как вы сейчас увидите). Мы просто собираемся сфокусироваться на строковых столбцах, поэтому я создал одну с типами VARCHAR, а другую - с NVARCHAR. Затем для простоты мы загрузим только те данные, которые являются чисто VARCHAR (потому что некоторые чудаки могли добавить какие-нибудь необычные данные Unicode в столбец AboutMe).
Продолжить чтение "Что использовать: VARCHAR или NVARCHAR?"

Автор: Mayur B, The OOM-Killer Summoning Ritual: "Just Increase work_mem"

Вы, вероятно, видели такую картину инцидента:

1. Процессы (backend) PostgreSQL начинают исчезать.


2. dmesg / journalctl -k показывает, что OOM-Killer в ядре завершает процесс postgres.


3. Кто-то замечает «out of memory» и рефлекторно рекомендует: «Увеличь work_mem».

Эта рекомендация часто является обратной для случаев, когда OOM-Killer завершает процессы на уровне ОС.

Лингвистическая ловушка: «Out of memory» звучит как «недостаточно work_mem»

work_mem — это не «память для запроса». Это базовый бюджет на операцию для узлов исполнителя (executor nodes), таких как сортировки и хеш-таблицы, прежде чем они начнут сбрасывать данные во временные файлы (spill). В документации PostgreSQL прямо предупреждают, что сложный запрос может выполнять несколько операций сортировки/хеширования параллельно, и многие сеансы могут делать это одновременно, поэтому общий объём используемой памяти может во много раз превышать work_mem.

Если вы глобально повышаете work_mem, вы повышаете потолок для многих потенциальных одновременных потребителей памяти. Это может превратить «редкий скачок» в «частое завершение процессов OOM-Killer».

Продолжить чтение "Ритуал призвания OOM-Killer: «Просто увеличь work_mem»"

§ Усилена проверка задачи 186 (SELECT, обуч. этап) данными от Komov S.M.

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 779 (SELECT)		10		7
 44 (DML)		5		7
 188 (SELECT)		3		4
 780 (SELECT)		2		9
 1 (Learn)		2		9

Продолжить чтение "Новости за 2025年12月13日 - 2025年12月19日"

Пересказ статьи Sergey Gigoyan. SQL Index Rebuild vs Reorganize Comparison

При модификации данных в базе данных SQL соответствующие индексы тоже изменяются. Эти изменения приводят к фрагментации индексов. Фрагментация означает, что логический порядок данных на страницах индекса не соответствует физическому порядку. Во фрагментированных индексах информация не располагается логически, что делает операции извлечения данных из индекса более затратными по времени, это приводит к проблемам производительности запросов. Таким образом, фрагментацию индексов следует периодически устранять для поддержания высокой производительности. Операции перестройки и реорганизации индекса как раз направлены на дефрагментацию индексов.

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

Продолжить чтение "Сравнение перестройки и реорганизации индексов SQL"

Автор: Josef Machytka, PostgreSQL 18 Asynchronous Disk I/O - Deep Dive Into Implementation

PostgreSQL 17 представил потоковый ввод-вывод — группировку нескольких чтений страниц в один системный вызов и использование более интеллектуальных подсказок posix_fadvise(). Только это дало до ~30% ускорения последовательного просмотра в некоторых рабочих нагрузках, но операция оставалась строго синхронной: каждый фоновый процесс отправлял запрос на чтение и затем простаивал в ожидании возврата данных от ядра, прежде чем продолжить работу. До PG17 PostgreSQL обычно читал по одной 8-килобайтной странице за раз.

PostgreSQL 18 делает следующий логический шаг: полноценная подсистема асинхронного ввода-вывода (AIO), которая может держать несколько операций чтения в процессе выполнения, пока фоновые процессы занимаются другой полезной работой. Чтения теперь перекрываются по времени, а не выполняются строго последовательно. Подсистема AIO целенаправленно ориентирована на операции, которые заранее знают номера нужных блоков и могут отправить несколько запросов на чтение предварительно:

• Последовательный просмотр кучи (heap), например, простые операции SELECT и COPY, которые потоково читают большие объёмы данных


• VACUUM для больших таблиц и индексов


• Выборка данных для ANALYZE


• Сканирование кучи по битовой карте (Bitmap heap scans)

Автовакуум также выигрывает от этого изменения, поскольку его рабочие процессы используют те же пути выполнения кода для VACUUM/ANALYZE. Другие операции пока остаются синхронными:

• Сканирование по B‐tree индексу / индексное сканирование без обращения к таблице (index‐only scans)


• Восстановление & репликация


• Все операции записи: INSERT, UPDATE, DELETE, запись в WAL


• Небольшие OLTP-запросы, затрагивающие единственную страницу кучи

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

Продолжить чтение "PostgreSQL 18: Асинхронный ввод-вывод на диск — детальный разбор реализации"

Joe Celko, Cooking an old puzzle

Я только что получил письмо о головоломке No11 из моей старой книги «SQL PUZZLES & ANSWER» от Райнера Гемуллы из Дрезденского технического университета, факультет информатики, институт SyA, Дрезден, Германия. Это очень изящное решение, и стыдно смотреть, насколько без нужды сложными были другие ответы:

ГОЛОВОЛОМКА С РАБОЧИМ НАРЯДОМ

Сенк Эрсой задал этот вопрос на форуме Gupta в CompuServe. У него есть таблица, которая выглядит так. На заводе проект описывается в рабочем наряде, который должен пройти через серию этапов. Этап в рабочем наряде либо завершён, либо ожидает завершения одного или нескольких предшествующих этапов. Его таблица выглядит следующим образом:

CREATE TABLE Projects (

 workorder CHAR(5) NOT NULL,

 step INTEGER NOT NULL CHECK (step BETWEEN 0 AND 1000),

 status CHAR(1) NOT NULL CHECK (status IN ('Completed', 'Waiting')),

 PRIMARY KEY (workorder, step)

);

С примерными данными, такими как:

Projects

workorder step status

=================================

'AA100' 0 'Completed'

'AA100' 1 'Waiting'

'AA100' 2 'Waiting'

'AA200' 0 'Waiting'

'AA200' 1 'Waiting'

'AA300' 0 'Completed'

'AA300' 1 'Completed'

Он хотел бы получить рабочие наряды, где этап равен нулю и статус «Completed», но все другие этапы для этого рабочего наряда имеют статус «Waiting». Например, в примере данных запрос должен вернуть только «AA100».

Продолжить чтение "Готовим старую головоломку"

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 34 (Learn)		6		9
 779 (SELECT)		6		2

§ Авторы недели на форуме

Автор		Сообщений
 Baser 	6
 pegoopik 	3
 selber 	2
 ChronoMorzh 	2

Продолжить чтение "Новости за 2025年12月06日 - 2025年12月12日"

Автор: Greg Sabino Mullane, Postgres 18 New Default for Data Checksums and How to Deal with Upgrades

В недавнем патче для PostgreSQL, созданном Грегом Сабино Маллейном, PostgreSQL сделал новый шаг вперёд в обеспечении целостности данных: контрольные суммы данных теперь включены по умолчанию.

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

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

Продолжить чтение "Новое значение по умолчанию для контрольных сумм в PostgreSQL 18 и как обновляться"