Средство обнаружения тупиков Oracle

Question

Я ищу статический анализатор запросов Oracle и процедур PL / SQL (триггеры, ограничения, ...) - инструмент, который передаст нашу схему БД и укажет на возможные тупики. Так же, как FindBugs для Java.

Если такого инструмента не существует, хотели бы вы его иметь?

Answer 1

Начиная с 10g, в базу данных теперь встроен статический анализатор PL / SQL:

ALTER SESSION SET PLSQL_WARNINGS = 'ENABLE:ALL';

Закажите Google для PLSQL_WARNINGS, и вы найдете несколько полезных ссылок

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

Answer 2

Блокировка зависела бы от транзакций, а не от статического кода. В Oracle нет концепции оператора «BEGIN TRANSACTION», поэтому у статического анализатора нет возможности узнать, какова начальная точка транзакции. Гипотетически, анализатор может быть написан так, чтобы, если ему был задан начальный оператор SQL или PL / SQL, он мог отслеживать все возможные пути выполнения и определять, какие таблицы подвергались операциям обновления / удаления / вставки / слияния в каком порядке. Затем вы могли бы «сравнить» два (или более) результатов этого и определить, есть ли какие-либо таблицы, где манипулируют в другом порядке (например, TAB_A, затем TAB_B в одном и TAB_B, затем TAB_A в другом). Я подозреваю, что это приведет к множеству ложных срабатываний.

В Oracle выбор не блокируется (кроме SELECT ... FOR UPDATE). Таким образом, взаимоблокировки возникают только при обновлении данных и только тогда, когда две параллельные транзакции пытаются обновить одни и те же строки.

Answer 3

У TOAD есть инструменты для статического анализа (или, по крайней мере, какого-то качества кода). Я сомневаюсь, что они смогут найти мертвые замки.

Answer 4

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

Наиболее распространенной практикой является установка базы данных в Q & A или производственной среде. А затем отслеживать тупики, которые на самом деле возникают. Вы можете запускать автоматические модульные тесты в среде Q & A для имитации нагрузки.