Добавление кластерного индекса к таблице SQL: какие опасности существуют для живой производственной системы?

Я был назначен ответственным за 10-летнюю систему обработки транзакций, где большинство бизнес-логики реализовано на уровне базы данных (триггеры, хранимые процедуры, и т.д.). Сервер Win2000, Предприятие MSSQL 2000 года. Никакие непосредственные планы относительно замены или обновления системы не рассматривают.

Базовый процесс является программой, которая выполняет транзакции - а именно, он выполняет хранимую процедуру с различными параметрами; давайте назовем его sp_ProcessTrans. Программа выполняет хранимую процедуру в асинхронных интервалах.

Отдельно, вещи хорошо работают, но существует 30 экземпляров этой программы на удаленно расположенных рабочих станциях, все они асинхронно выполнение sp_ProcessTrans и затем получая данные из SQL-сервера. Выполнение довольно регулярно - расположение от 0 до 60 раз в минуту, в зависимости от того, за какие объекты экземпляр программы ответственен.

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

Я обнаружил:

• В sp_ProcessTransвыполнение, это выбирает из Employee времена таблицы 7
• Выбор сделан на поле, которое НЕ является первичным ключом
• Никакой индекс не существует на этом поле. Таким образом сканирование таблицы выполняется 7 раз на транзакцию

Таким образом, причина мертвых блокировок ясна. Я создал групповой заказанный кластерный индекс на поле (почти уникальный, NUM(7), очень редко изменения). Было непосредственное улучшение тестовой среды. Проблема состоит в том, что я не могу моделировать мертвые блокировки в тестовой среде. Мне были бы нужны 30 рабочих станций, и я должен буду моделировать 'реалистическое' действие по тем станциям, таким образом, визуализация будет отсутствовать.

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

Там кто-либо - скрытые опасности, которые я не вижу? (Я не надеюсь восстановить DB, если что-то идет не так, как надо. Потребовалось бы много времени с 10 годами данных.)