У меня есть таблица, в которой используется значение идентификатора для столбца уникального идентификатора. Мы заметили несколько резких скачков ценности идентичности, которые мы не можем объяснить. В таблице 20 000 нечетных строк, максимальное значение идентификатора превышает 560 000 000, а приращение идентификатора равно 1!
Я хотел использовать профилировщик SQL Server для мониторинга активности только в этой таблице, чтобы я мог видеть, что заставляет идентификацию прыгать в больших количествах, но когда я подошел посмотреть на монитор, я был мгновенно сбит с толку. Я признаю, что я в спешке, и у меня нет времени, чтобы по-настоящему изучить, как это работает (сколько бы мне хотелось), поэтому я мог бы использовать приблизительное руководство относительно шагов, которые вы должны предпринять для мониторинга активности на столе.
Любая помощь будет оценена по достоинству.
Запустите SQL Profiler, создайте новую трассировку и подключитесь к SQL Server, который вы хотите отслеживать.
Внимание, если это очень загруженный производственный сервер, вам не следует использовать SQL Profiler, так как это замедлит работу SQL Server.
Обычно я использую "стандартный" профиль, а затем редактирую его.
Щелкните вкладку «Выбор событий». Обычно я снимаю флажки «Аудит входа в систему», «Аудит выхода из системы», «Существующие соединения» и «Запуск пакета RPC». Это дает хороший чистый результат трассировки.
Убедитесь, что установлен флажок «TextData».
Вы можете добавить фильтр к следу "LIKE %%" в столбце TextData, но он будет включать только операторы SQL, отправленные непосредственно на сервер. Если есть хранимые процедуры, вам нужно знать, какие хранимые процедуры касаются вашей таблицы, и фильтровать их.
Если у вас есть запросы курсора, вы получите много "sp_fetch". Вам нужно найти оператор DECLARE CURSOR с тем же идентификатором курсора.
Если подумать, плохой цикл для курсора может быстро вставить многие тысячи «ошибочных» записей, и это может быть причиной этих больших скачков приращения.
Значение идентификатора будет увеличиваться при каждой вставке, даже если вставка не удалась.
Если у вас есть проверка или ограничение внешнего ключа, каждый сбой будет увеличивать идентификатор. Если у вас есть «слишком большое значение», тогда вставка не удастся, но идентичность увеличится.
В общем, это не проблема. Назначение поля идентификатора - предоставить уникальную ссылку для этой строки, и ее аккуратное приращение без пропущенных чисел - это человеческая вещь, которую нужно держать в порядке, а не то, из-за чего база данных может расстроиться.
Более насущная проблема - почему ваши вставки выходят из строя, а вы об этом не знаете ...
SQL Server сбрасывает столбец идентификаторов при остановке и запуске службы. есть элемент подключения, где кто-то подумал, что это ошибка, но в MS это хорошая дизайнерская особенность. https://connect.microsoft.com/SQLServer/feedback/details/739013/alwayson-fail
Существует флаг трассировки, который отключает повторное заполнение идентификатора, добавление -T272 в качестве флага запуска поможет.