Если бы Дарт Вейдер существовал и решил бы сделать с Землёй то же, что он сделал с Алдерааном, все потеряли бы данные.
Мне нравится эта цитата Роберта Хааса, потому что это отрезвляющая реальность, которая нужна всем нам. В мире баз данных нам постоянно продают мечту о «пяти девятках» (99,999% времени доступности) и «нулевой потере данных» (RPO=0). Мы тратим месяцы на построение сложных кластеров, чтобы достичь этого.
Давайте будем честными: это сказки. Красивые для воображения, но они не существуют в рабочей среде. Если планетарная лазерная пушка — или даже просто серьёзный сетевой обрыв — поразит ваш дата-центр, ваши «гарантии» исчезнут.
Моя цель сегодня — не помочь вам поверить в сказки. Моя цель — помочь вам построить архитектуру, которая действительно работает.
Индексы существуют для ускорения доступа к данным. Они позволяют PostgreSQL избегать полного просмотра таблицы, значительно сокращая время выполнения запросов для рабочих нагрузок с интенсивным чтением.
Из реального производственного опыта мы наблюдали, что хорошо спроектированные, целевые индексы могут улучшить производительность запросов в 5 и более раз, особенно на больших транзакционных таблицах.
Однако индексы не являются бесплатными.
И в этой статье мы обсудим, какие проблемы могут вызывать неиспользуемые индексы и как удалить их из производственных систем с планом отката, безопасно.
Усечение таблицы может быть замечательно быстрым - и чрезвычайно опасным при неосмотрительном использовании. Если вы хотите иметь скорость и не разочароваться, тут дается практическое, готовое для интервью руководство по реальным подводным камням TRUNCATE TABLE в SQL Server и то, как избежать их.
Справка
TRUNCATE TABLE является операцией DDL, которая освобождает страницы (эффективно журнализированные) и сбрасывает IDENTITY к начальному значению. При этом триггеры DELETE не срабатывают. Возможен откат при выполнении внутри транзакции.
Завершается неудачно, если на таблицу ссылается внешний ключ (даже если дочерняя таблица пуста), используется в индексированных представлениях, является системно-версионной (временной), опубликованной для репликации или включена для CDC, или на нее ссылается ограничение EDGE графа. Существует специальная возможность для самоссылающихся внешних ключей.
Начиная с SQL Server 2016, вы можете усекать конкретные секции: TRUNCATE TABLE dbo.Fact WITH (PARTITIONS (4 TO 6)); (индексы должны быть выровнены).
Работа над RegreSQL заставила меня уделить много внимания буферам. Если вы иногда работаете с PostgreSQL, то наверняка слышали о настройке shared_buffers и следовали старому доброму совету выставить его на уровне 1/4 от доступной оперативной памяти. Но после того как мы немного слишком увлеклись этой темой в недавнем выпуске Postgres FM, меня спросили, что к чему.
Буферы — одна из тех тем, которую легко забыть. И хотя они являются фундаментальным блоком архитектуры производительности PostgreSQL, большинство из нас воспринимает их как чёрный ящик. Эта статья попытается это изменить.
Большинство руководств по массовой вставке SQL и SQL Server openrowset игнорируют проблемы доступа к файлам, которые могут прервать импорт. И оператор bulk insert, и функция openrowset выполняются под аккаунтом службы SQL Server при чтении файла источника. Аккаунт службы SQL Server должен иметь разрешение на чтение файла или папки, где файл находится. Также удобно иметь разрешения на чтение и выполнение, а также вывод содержимого папки. Кроме того, нестандартные места размещения файла источника (например, C:\Users\Public\Downloads) могут не предоставлять доступ на чтение по умолчанию аккаунту службы SQL Server - всегда проверяйте это перед использованием.
Планировщик запросов PostgreSQL - это сложный инженерный механизм, обычно принимающий блестящие решения относительно того, как выполнять ваши запросы. Однако в сложных сценариях или при необычных распределениях данных вы можете знать лучший способ. Именно в таких ситуациях на помощь приходит pg_hint_plan - мощное расширение, которое позволяет вам руководить, или "советовать", планировщиком для выбора специфичного пути выполнения.
Regex является мощным средством обнаружения структуры внутри беспорядочных строк. PostgreSQL использует тут первоклассные функции регулярных выражений, включая REGEXP_MATCH для сопоставления и извлечения шаблонов.
Если вам когда-либо требовалось извлечь номер телефона из текста, проверить адрес электронной почты или захватить поименованный фрагмент строки, REGEXP_MATCH поможет вам сделать это за один шаг SQL.
Как специалисты по базам данных, мы все сталкивались с этим ужасным моментом, когда пользователи начинают жаловаться на медленные запросы, и внезапно все смотрят на вас с выражением «исправьте это сейчас же». Настройка производительности Oracle может показаться невероятно сложной, особенно в условиях стресса, но хорошая новость состоит в том, что большинство проблем с производительностью возникают по нескольким распространённым причинам. Позвольте мне рассказать вам о нескольких проверенных методах, которые спасали мне жизнь больше раз, чем я могу сосчитать.
Начнем с самого простого: статистика и планы выполнения
Прежде чем перейти с сложным стратегиям настройки, всегда проверяйте актуальность вашей статистики. Оптимизатор Oracle на основе стоимости всецело опирается на точность статистики для принятия умных решений относительно путей выполнения запросов. Мне приходилось видеть запросы, которые выполнялись в 10 раз медленнее только потому, что кто-то забыл обновить статистику после загрузки большого объема данных.
Continue reading "Настройка производительности в Oracle: практические методы, которыми должен владеть каждый DBA"
