Teradata: как вы отлаживаете транзакцию, прерванную из-за ошибок взаимоблокировки?

Определение прерванных транзакций

Условие взаимоблокировки должно приводить к прерыванию обеих транзакций, ответственных за взаимоблокировку. Обычно я вижу тупиковые ситуации с оптимизацией push down от Informatica, пытающейся создать временные представления параллельно, и тупиковые ситуации в таблицах DBC, необходимых для создания представлений. Как и ваша ситуация, наша ситуация с Informatica совершенно случайна. Мы можем обходиться неделями или месяцами без прерывания из-за тупика.

Вы можете найти подозрительные транзакции, запросив в таблице журнала DBQL транзакции с ErrorCode = 2631 (Edit: Fixed error code) и ORDER BY StartTime DESC. Это даст вам каждую транзакцию, которая была прервана из-за тупиковой ситуации. Пары транзакций, которые привели к тупиковой ситуации, должны быть довольно близко друг к другу, если не объединены в пары по сортировке.

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

Определение причин прерывания транзакций

Примечание. Это не исчерпывающий список.

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

Это потребует от вас сначала понять, как вы попадаете в состояние тупика.

• Если две транзакции пытаются манипулировать одной и той же записью, поддерживает ли ваша модель данных медленно меняющиеся измерения, чтобы у вас была запись о каждом происходящем изменении?
• Если это транзакция чтения и транзакция обновления, обращающаяся к одной и той же записи, можете ли вы настроить степень детализации и продолжительность блокировки, чтобы минимизировать шансы?
• Вы используете ACCESS или READ блокировку?
• Обращаются ли ваши SELECT операторы к таблице через представление 1: 1, в котором используется ROWHASH ACCESS блокировка, позволяя оптимизатору наращивать блокировку с наиболее детализированного уровня до уровня, необходимого для рассматриваемой транзакции? (например, LOCKING ROW FOR ACCESS SELECT * FROM DBC.DBCInfo;)
• Удалено предложение для БЛОКИРОВКИ СТРОК в ЗАЯВЛЕНИИ ОБ ОБНОВЛЕНИИ.

Обработка прерванных транзакций

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

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

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

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

Итак, ответ таков: прерванные транзакции - это совершенно нормально, и вы просто должны повторить их со стороны клиента. Но, как заметил Роб, это может быть легко или сложно, в зависимости от типа транзакции, которую вы выполняете (например, если вы выполняете 2-часовой процесс ETL, вы можете вместо этого выяснить, как уменьшить вероятность взаимоблокировок) .