Lompatan nilai kolom MASSIVE Identity di SQL Server 2014

Aug 19 2020

Jadi di tengah pengkodean dan pengujian dasar, kami melihat lompatan besar yang tidak berpola dalam nilai Identitas untuk beberapa tabel. Kami tidak mengetahui adanya kesalahan server atau upaya operasi massal, tetapi DBA sedang memeriksa log.

Celahnya tidak seperti 1.000 atau 10.000 yang terlihat dengan restart server dan semacamnya.

Gap sebesar Application_NO10,410,345 untuk tabel dengan 2,320 baris

Transaction_Payment_NO melompat ke 1.712.149.313 yang mencengangkan untuk tabel dengan 685 catatan.

Adakah gagasan tentang apa yang dapat menyebabkan lompatan besar dan tampaknya sewenang-wenang?

Jawaban

5 JoshDarnell Aug 19 2020 at 01:06

Beberapa kemungkinan penyebabnya:

  1. proses pengujian membuat banyak baris dalam sebuah transaksi, dan kemudian mengembalikan transaksi tersebut

Ini sepertinya alasan yang paling mungkin, seperti yang Anda sebutkan bahwa Anda sedang melakukan pengujian. Mungkin ada beberapa pengujian otomatis yang sedang dijalankan yang membuat perubahan pada tabel tersebut, memverifikasi hasil, dan kemudian mengembalikan perubahan.

Nilai identitas tidak digunakan kembali setelah transaksi dibatalkan, itulah yang menyebabkan Anda melihat celah besar dalam skenario ini.

  1. Seseorang menggunakan RESEEDperintah itu

Anda dapat secara manual mengubah nilai "identitas berikutnya" saat ini dengan perintah ini:

DBCC CHECKIDENT ('dbo.Transaction_Payment_NO', RESEED, 1712149313);

Yang ini sepertinya kurang mungkin, karena Anda atau salah satu admin harus berusaha keras untuk melakukannya. Demikian pula...

  1. Seseorang memasukkan nilai-nilai itu secara manual

Anda dapat memasukkan apapun yang Anda suka ke dalam IDENTITYkolom dengan terlebih dahulu menjalankan pernyataan ini:

SET IDENTITY_INSERT dbo.Transaction_Payment_NO ON;
  1. Failover dan restart

Anda menyebutkan ini dalam pertanyaan, tetapi hanya untuk kelengkapan - SQL Server menyimpan nilai identitas untuk meningkatkan kinerja. Tetapi nilai identitas yang telah dialokasikan sebelumnya tersebut dapat hilang jika layanan dimulai ulang atau terjadi kegagalan AG. Hal ini menyebabkan kesenjangan yang lebih dapat diprediksi (10.000 pada versi modern SQL Server).