2009-05-13 3 views
0

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

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

ответ

1

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

2

С 10г года, база данных теперь имеет статический PL/SQL анализатор, встроенный в него:

ALTER SESSION SET PLSQL_WARNINGS = 'ENABLE:ALL'; 

Have A Google для PLSQL_WARNINGS, и вы найдете некоторые полезные Ссылки на

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

-2

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

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

+0

Мне просто интересно, как инструменты, такие как Coverity/Klocwork/FindBugs, могут найти взаимоблокировки (не все конечно и с ложными срабатываниями, но намного лучше, чем ничего) в коде C++/Java, где количество путей выполнения больше на два порядка ... –

+0

Без использования данных нет способа узнать, какие запросы выполняются в базе данных. Если вы ограничиваете себя хранимыми процедурами, нет способа узнать порядок, в котором они вызываются без использования данных. Это отличается от C++ или Java-программы, где у вас есть гораздо больше информации о том, как будет работать программа. – Andomar

1

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

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

+0

Сделка начинается с первой вставки/обновления/удаления, ее легко отслеживать. Мне просто интересно, как инструменты, такие как Coverity/Klocwork/FindBugs, могут найти взаимоблокировки (не все, конечно, с ложными срабатываниями, но намного лучше, чем ничего) в коде C++/Java, где количество путей выполнения больше на два порядка ... –

Смежные вопросы