SQL Server 2000 регистрирует запросы, которые вызывают ошибки где-нибудь?

Question

У меня есть распределенное развертывание ± 20 клиентов, использующих ту же хранимую процедуру для создания записи, а затем прикрепления подробных записей. Мы заметили пробелы в полях идентификации основной записи. В этом случае мы не используем транзакцию, поэтому единственная причина, по которой мы можем придумать пробелы, заключается в том, что один из разработчиков проглатывает исключение где-то. Есть ли список неудачных запросов или запросов, которые вызвали исключение, зарегистрированное где-то?

Есть ли еще какие-либо предложения для решения проблемных вопросов, кроме:

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

Answer 1

SQL Server 2000 (и более поздние версии) не регистрирует автоматически запросы, которые генерируют простые ошибки «данных». Он будет регистрировать запросы, которые генерируют серьезные ошибки (например, RAISERROR уровня 20 и выше), и любые такие ошибки будут регистрироваться в журнале событий приложений Windows. Тем не менее, вполне вероятно, что то, что вызывает ваши игры, не будет вызывать такого рода ошибки, поскольку вы, вероятно, уже заметили другие проблемы.

Один из способов найти это действие, как сказал Чадхок, установить след для его отслеживания. Это делает более 20 серверов в течение [сколько?] Дней, а затем анализирует результаты, что считается нетривиальной задачей. (Я бы настроил первый проход с событиями Exception и, в зависимости от вашего приложения, одним из Batch Start, Start для хранимой процедуры или RPC.)

Другая тактика: вместо зеркальной таблицы, заполняемой «расширением» хранимых процедур, попробуйте триггер INSERT для таблицы, которая заполняет таблицу журнала. (Это будет перехватывать все вставки, а не только те, которые сделаны вашей хранимой процедурой.) Таблица журнала будет отслеживать идентификатор, время вставки и любую дополнительную информацию, которая может оказаться полезной (кто выполняет вход в систему, вызывающее приложение, любые другие данные быть полезным для отладки). Это может в конечном итоге выглядеть как зеркальный стол, но это не обязательно. Если пробелы все еще появляются, вы наверняка будете знать, что транзакции откатывались. (И помните, что если только этот первый оператор INSERT завершается неудачно и строка никогда не вставляется, он все равно «использует» значение идентификатора.)

Answer 2

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

Обратите внимание, что есть и другие способы получения пробелов в идентификации, в том числе:

• ROLLBACK (использованные идентификаторы в незафиксированной транзакции не откатываются, они просто продолжают двигаться вверх или вниз, если вы настроили идентичность как таковую)
• Тиражирование
• Явное обновление идентификатора / текущего значения
• Удаление
• Etc.

Answer 3

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

Вы не можете ожидать, чтобы поля идентификаторов были без пробелов. Это просто не произойдет.