Компания Microsoft не публикует значения кэша, используемые по умолчанию для последовательности и идентификатора, так как предпочитает иметь возможность изменять их без предупреждения по собственному усмотрению. В главе электронной документации по SQL Server, относящейся к команде CREATE SEQUENCE (msdn. microsoft.com/en-us/library/fT878091. aspx), содержится следующее замечание относительно значения кэша последовательности по умолчанию: «Если кэш включен без указания размера кэша, то размер выбирается компонентом Database Engine». Однако пользователям не следует полагать, что этот выбор будет постоянным. Компания Microsoft может изменить метод расчета размера кэша без предупреждения.
Хотя значения кэша по умолчанию официально не опубликованы, их можно определить с помощью простого теста. Я продемонстрирую тест с типом INT, а затем приведу результаты, полученные мною для других типов.
Вы получите 2 в качестве текущих значений как последовательности, так и идентификатора.
Чтобы вызвать нечистое завершение процесса SQL Server, откройте диспетчер задач (Ctrl+Shift+Esc), щелкните правой кнопкой мыши процесс SQL Server и выберите действие End task («Завершить задачу»).
Я получил текущие значения 50 для последовательности и 1001 для идентификатора. Значения по умолчанию для типа INT для последовательности — 50, а для идентификатора — 1000. Причина тою, что текущее значение для идентификатора после перезапуска 1001, а не 1000, заключается в том, что первая запись в кэш происходит
после второго запроса, тогда как для последовательности она происходит после первого запроса.
Аналогичный тест был выполнен для проверки значений по умолчанию для других типов. Результаты показаны на рисунке 1.
Как мы видим, последовательность имеет значение 50 для всех типов, но примечательно, что идентификатор имеет различные значения по умолчанию в зависимости от типа. Выполнение аналогичного теста с идентификатором в версиях SQL Server, предшествующих SQL Server 2012, показывает, что в этих версиях идентификатор не имеет кэша. Это объясняет, почему в SQL Server 2012 и более новых версиях стал появляться пробел 1000 после нечистого завершения процесса или переключения на другой ресурс в группе обеспечения доступности SQL Always On. Некоторые специалисты считают такое поведение ошибкой (см. публикацию «Failover or Restart Results in Reseed of Identity» на сайте Microsoft Connect (connect.microsoft. com/SQLServer/feedback/details/739 013/failover-or-restart-results-in-reseed- of-identity)).
Однако на практике, как объяснялось выше, пробелы возможны даже без кэша. Тем не менее специалисты Microsoft ввели флаг трассировки 272, чтобы дать возможность вернуться к поведению, свойственному версиям, предшествующим SQL Server 2012, в которых идентификатор не использует кэша. Но помните, что отключение кэша негативно отразится на производительности, как будет показано ниже.
