Устранение проблем с tempdb в выделенном пуле SQL

Статья
11/20/2024

Область применения: Azure Synapse Analytics

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

Что делать, если не удается подключиться к выделенному пулу SQL?

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

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

Устранение неполадок с полными файлами данных tempdb

Шаг 1. Определение запроса, заполняющего базу данных tempdb

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

SELECT TOP 5 *
FROM sys.dm_pdw_exec_requests
WHERE status = 'running'
ORDER BY total_elapsed_time desc;

После того как у вас есть достаточно подозрительный запрос, попробуйте один из следующих вариантов:

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

Шаг 2. Предотвращение повторения

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

Причина	Description	Меры по снижению риска
Плохо распределенный план	Распределенный план, созданный для данного запроса, может случайно привести к перемещению данных высокой частоты в результате плохо поддерживаемой статистики таблицы.	Обновите статистику для соответствующих таблиц и убедитесь, что они сохраняются в регулярном расписании.
Низкая работоспособность кластеризованного индекса columnstore (CCI)	Он потребляет пространство tempdb из-за разлива памяти.	Перестройте ccis и убедитесь, что они поддерживаются в регулярном расписании.
Крупные транзакции	Большой объем `CREATE TABLE AS SELECT (CTAS)` или `INSERT SELECT` операторы заполняют tempdb во время операций перемещения данных.	Разбейте инструкцию `CTAS` или `INSERT SELECT` на несколько небольших транзакций.
Недостаточно выделенной памяти	Запросы с недостаточной выделенной памятью (через класс ресурсов или группу рабочих нагрузок) могут перетекать в `tempdb`.	Выполните запросы с использованием большого класса ресурсов или группой рабочей нагрузки с большим количеством ресурсов.
Запросы внешних таблиц конечного пользователя	Запросы к внешним таблицам не являются оптимальными для запросов конечных пользователей, так как обработчику необходимо считывать весь файл `tempdb` перед обработкой данных.	Загрузите данные в постоянную таблицу, а затем направьте туда пользовательские запросы.
Недостаточно общих ресурсов	Вы можете обнаружить, что выделенный пул SQL близок к максимальной емкости tempdb во время высокой активности.	Рассмотрите возможность масштабирования выделенного пула SQL в сочетании с любым из описанных выше способов устранения рисков.

Устранение неполадок с полными файлами журнала транзакций tempdb

Журнал транзакций tempdb обычно заполняется только в том случае, если клиент или пользователь:

Открывает явную транзакцию, но никогда не выдает или COMMIT ROLLBACK.
Наборы IMPLICIT_TRANSACTION = ON (особенно для клиентов и средств JDBC, использующих функции AutoCommit).

Шаг 1. Определение открытых транзакций

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

SELECT *
FROM sys.dm_pdw_exec_sessions
WHERE is_transactional = 1
AND status = 'Idle';

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

Шаг 2. Устранение и предотвращение проблемы

После определения того, какие клиенты проводят открытые транзакции, обратитесь к пользователям, чтобы изменить или оба:

Конфигурация драйвера (например, параметр автокоммута JDBC в off, для которого заданы)IMPLICIT_TRANSACTIONS = ON
Поведение нерегламентированного запроса (например, неправильное выполнение BEGIN TRAN без COMMIT/ROLLBACK)

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

Ресурсы

Выполните запрос динамического административного представления sys.dm_pdw_errors, чтобы проверить наличие ошибок.

Поделиться через