Gia tăng danh tính đang nhảy trong cơ sở dữ liệu SQL Server

Trong một trong các bảng của tôi Feetrong cột "Biên lai" trong phần tăng nhận dạng cơ sở dữ liệu SQL Server 2012 đột nhiên bắt đầu nhảy lên 100 thay vì 1 tùy thuộc vào hai điều sau đây.

1. nếu là 1205446 thì nó nhảy lên 1206306, nếu là 1206321, nó nhảy lên 1207306 và nếu là 1207314, nó nhảy lên 1208306. Điều tôi muốn làm bạn lưu ý là ba chữ số cuối cùng không đổi, tức là ba chữ số cuối cùng không đổi xảy ra như trong hình dưới đây.

2. sự cố này xảy ra khi tôi khởi động lại máy tính

Bạn đang gặp phải hành vi này do cải thiện hiệu suất kể từ SQL Server 2012.

Hiện tại theo mặc định, nó sử dụng kích thước bộ đệm là 1.000 khi phân bổ IDENTITYgiá trị cho một intcột và khởi động lại dịch vụ có thể "mất" các giá trị không sử dụng (Kích thước bộ đệm là 10.000 cho bigint/ numeric).

Điều này được đề cập trong tài liệu

SQL Server có thể lưu trữ các giá trị nhận dạng vì lý do hiệu suất và một số giá trị được gán có thể bị mất trong khi cơ sở dữ liệu bị lỗi hoặc khởi động lại máy chủ. Điều này có thể dẫn đến khoảng trống trong giá trị nhận dạng khi chèn. Nếu các khoảng trống không được chấp nhận thì ứng dụng nên sử dụng cơ chế riêng để tạo các giá trị chính. Sử dụng trình tạo trình tự với NOCACHEtùy chọn có thể giới hạn các khoảng trống cho các giao dịch không bao giờ được cam kết.

Từ dữ liệu bạn đã hiển thị, có vẻ như điều này đã xảy ra sau khi nhập dữ liệu vào ngày 22 tháng 12 sau đó khi nó khởi động lại SQL Server dành các giá trị 1206306 - 1207305. Sau khi nhập dữ liệu trong 24 - 25 tháng 12, một lần khởi động lại khác và SQL Server dành phạm vi tiếp theo 1207306 - 1208305hiển thị trong các mục nhập cho ngày 28.

Trừ khi bạn đang khởi động lại dịch vụ với tần suất bất thường, bất kỳ giá trị "bị mất" nào cũng không thể tạo ra bất kỳ vết lõm đáng kể nào trong phạm vi giá trị được cho phép bởi kiểu dữ liệu, vì vậy chính sách tốt nhất là không phải lo lắng về điều đó.

Nếu đây là vì một lý do nào đó, một vấn đề thực sự cho bạn một số cách giải quyết có thể là ...

1. Bạn có thể sử dụng SEQUENCEthay vì một cột danh tính và xác định kích thước bộ đệm nhỏ hơn chẳng hạn và sử dụng NEXT VALUE FORtheo mặc định của cột.
2. Hoặc áp dụng cờ theo dõi 272 để IDENTITYphân bổ được ghi lại như trong các phiên bản cho đến 2008 R2. Điều này áp dụng trên toàn cầu cho tất cả các cơ sở dữ liệu.
3. Hoặc, đối với các phiên bản gần đây, hãy thực thi ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE = OFFđể tắt bộ đệm ẩn danh tính cho cơ sở dữ liệu cụ thể.

Bạn nên lưu ý rằng không có cách giải quyết nào đảm bảo không có khoảng trống. Điều này chưa bao giờ được đảm bảo bởi IDENTITYvì nó chỉ có thể được thực hiện bằng cách nối tiếp các phần chèn vào bảng. Nếu bạn cần một cột không khe hở, bạn sẽ cần sử dụng một giải pháp khác với IDENTITYhoặcSEQUENCE

Sự cố này xảy ra sau khi khởi động lại SQL Server.

Giải pháp là:

• Chạy Trình quản lý cấu hình máy chủ SQL .

• Chọn Dịch vụ máy chủ SQL .

  

• Bấm chuột phải vào Máy chủ SQL và chọn Thuộc tính .

• Trong cửa sổ mở bên dưới Thông số khởi động , nhập -T272và nhấp vào Thêm , sau đó nhấn nút Áp dụng và khởi động lại.

  

Từ SQL Server 2017+bạn có thể sử dụng CONFIGURATION ALTER DATABASE SCOPED :

IDENTITY_CACHE = {ON | TẮT }

Cho phép hoặc vô hiệu hóa bộ đệm nhận dạng ở cấp cơ sở dữ liệu. Mặc định là BẬT. Bộ nhớ đệm danh tính được sử dụng để cải thiện hiệu suất INSERT trên các bảng có cột Danh tính. Để tránh các lỗ hổng trong các giá trị của cột Danh tính trong trường hợp máy chủ khởi động lại bất ngờ hoặc không thành công với máy chủ thứ cấp, hãy tắt tùy chọn IDENTITY_CACHE. Tùy chọn này tương tự như Cờ theo dõi máy chủ SQL hiện tại, ngoại trừ việc nó có thể được đặt ở cấp cơ sở dữ liệu thay vì chỉ ở cấp máy chủ.

(...)

G. Đặt IDENTITY_CACHE

Ví dụ này vô hiệu hóa bộ đệm nhận dạng.

ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE=OFF ;

Tôi biết câu trả lời của tôi có thể bị trễ bữa tiệc. Nhưng tôi đã giải quyết theo một cách khác bằng cách thêm một thủ tục lưu trữ khởi động trong SQL Server 2012.

Tạo một thủ tục được lưu trữ sau đây trong DB chính.

USE [master]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE [dbo].[ResetTableNameIdentityAfterRestart]
AS
BEGIN

begin TRAN
    declare @id int = 0
    SELECT @id =  MAX(id) FROM [DatabaseName].dbo.[TableName]
    --print @id
    DBCC CHECKIDENT ('[DatabaseName].dbo.[TableName]', reseed, @id)
Commit

END

Sau đó thêm nó vào Start up bằng cách sử dụng cú pháp sau.

EXEC sp_procoption 'ResetOrderIdentityAfterRestart', 'startup', 'on';

Đây là một ý tưởng tốt nếu bạn có một vài bảng. nhưng nếu bạn phải làm cho nhiều bảng, phương pháp này vẫn hoạt động nhưng không phải là một ý tưởng tốt.

Đây vẫn là một vấn đề rất phổ biến giữa nhiều nhà phát triển và ứng dụng bất kể kích thước.

Thật không may, các đề xuất ở trên không khắc phục được tất cả các tình huống, ví dụ như Lưu trữ được chia sẻ, bạn không thể dựa vào máy chủ của mình để đặt tham số khởi động -t272.

Ngoài ra, nếu bạn có các bảng hiện có sử dụng các cột nhận dạng này cho các khóa chính, thì việc bỏ các cột đó và tạo lại các cột mới để sử dụng giải pháp trình tự BS là một nỗ lực rất lớn. Cách giải quyết Sequence chỉ tốt nếu bạn đang thiết kế các bảng mới từ đầu trong SQL 2012+

Điểm mấu chốt là, nếu bạn đang sử dụng Sql Server 2008R2, thì hãy TRÊN NÓ. Nghiêm túc, ở lại trên nó. Cho đến khi Microsoft thừa nhận rằng họ đã giới thiệu một lỗi HUGE, vẫn còn tồn tại ngay cả trong Sql Server 2016, thì chúng ta không nên nâng cấp cho đến khi họ sở hữu nó và FIX IT.

Microsoft đã giới thiệu một thay đổi đột phá, tức là họ đã phá vỡ một API hoạt động không còn hoạt động như thiết kế, do thực tế là hệ thống của họ quên danh tính hiện tại của họ khi khởi động lại. Bộ nhớ cache hoặc không có bộ đệm, điều này là không thể chấp nhận được và nhà phát triển Microsoft có tên Bryan cần sở hữu nó, thay vì nói với thế giới rằng đó là "theo thiết kế" và "tính năng". Chắc chắn, bộ nhớ đệm là một tính năng, nhưng mất theo dõi danh tính tiếp theo sẽ là gì, KHÔNG PHẢI LÀ ĐẶC ĐIỂM. Đó là một BUG bực bội !!!

Tôi sẽ chia sẻ cách giải quyết mà tôi đã sử dụng, bởi vì DB của tôi đang ở trên các máy chủ Shared Hosting, đồng thời, tôi sẽ không bỏ và tạo lại các cột Chính của mình, đó sẽ là một PITA khổng lồ.

Thay vào đó, đây là bản hack đáng xấu hổ của tôi (nhưng không đáng xấu hổ như lỗi POS này mà microsoft đã giới thiệu).

Hack / Sửa lỗi:

Trước các lệnh chèn của bạn, chỉ cần kiểm tra lại danh tính của bạn trước mỗi lần chèn. Khắc phục sự cố này chỉ được khuyến nghị nếu bạn không có quyền kiểm soát của quản trị viên đối với phiên bản Sql Server của bạn, nếu không tôi khuyên bạn nên khởi động lại khi khởi động lại máy chủ.

declare @newId int -- where int is the datatype of your PKey or Id column
select @newId = max(YourBuggedIdColumn) from YOUR_TABLE_NAME
DBCC CheckIdent('YOUR_TABLE_NAME', RESEED, @newId)

Chỉ cần 3 dòng ngay trước khi chèn của bạn, và bạn nên đi. Nó thực sự sẽ không ảnh hưởng đến hiệu suất nhiều, tức là nó sẽ không được chú ý.

Chúc may mắn.

Có nhiều lý do có thể để nhảy giá trị danh tính. Chúng bao gồm từ chèn trở lại để quản lý danh tính để nhân rộng. Điều gì gây ra điều này trong trường hợp của bạn tôi không thể nói mà không dành thời gian trong hệ thống của bạn.

Tuy nhiên, bạn nên biết rằng trong mọi trường hợp, bạn không thể giả sử một cột danh tính là contiguos. Có quá nhiều thứ có thể gây ra những khoảng trống.

Bạn có thể tìm thêm một chút thông tin về điều này tại đây: http://sqlity.net/en/792/the-gap-in-the-identity-value- resultence/