Я был назначен ответственным за 10-летнюю транзакционную систему, в которой большая часть бизнес-логики реализована на уровне базы данных (триггеры, хранимые процедуры и т. Д.). Сервер Win2000, MSSQL 2000 Enterprise.
Никаких ближайших планов замены или обновления системы не рассматривается.
Основной процесс - это программа, которая выполняет транзакции - в частности, она выполняет хранимую процедуру с различными параметрами; давайте назовем это sp_ProcessTrans. Программа выполняет хранимую процедуру с асинхронными интервалами.
Само по себе все работает нормально, но есть 30 экземпляров этой программы на удаленно расположенных рабочих станциях, каждый из которых асинхронно выполняет sp_ProcessTrans, а затем получает данные с сервера SQL. Выполнение выполняется довольно регулярно - от 0 до 60 раз в минуту, в зависимости от того, за какие элементы отвечает экземпляр программы.
Производительность системы значительно упала с 10-летним ростом данных: причина в взаимоблокировках, в частности, в ожидании взаимоблокировок, для таблицы Employee.
Я обнаружил:
- При выполнении
sp_ProcessTrans он выбирает из таблицы Employee 7 раз
- Выбор выполняется в поле, которое НЕ является первичным ключом
- В этом поле нет индекса. Таким образом, сканирование таблицы выполняется 7 раз за транзакцию
Так что причина тупиков понятна. Я создал на поле неуникальный упорядоченный кластерный индекс ( почти уникальный, NUM(7), , очень редко изменения). В тестовой среде произошло немедленное улучшение.
Проблема в том, что я не могу симулировать взаимоблокировки в тестовой среде. Мне понадобилось бы 30 рабочих станций, и мне нужно было бы имитировать «реалистичную» активность на этих станциях, поэтому визуализация отсутствует.
Мне нужно знать, должен ли я планировать время простоя.
Создание индекса не должно быть рискованной операцией для MSSQL, но есть ли какая-либо опасность (повреждение данных, дополнительное время ожидания и т. Д.) При создании этого индекса поля в производственной базе данных, пока транзакции все еще происходят? Я могу выбрать время, когда транзакции будут проходить довольно спокойно на 30 станциях.
Есть ли какие-то скрытые опасности, которых я не вижу? (Я не с нетерпением жду восстановления БД, если что-то пойдет не так. Это заняло бы много времени с данными за 10 лет.)