Some possible culprits:
- the testing process creates many rows in a transaction, and then rolls back the transaction
This seems like the most likely reason, as you mentioned you're currently doing testing. Perhaps there are some automated tests being run that make changes to those tables, verify the results, and then roll back the changes.
Identity values are not reused after a transaction has been rolled back, which is what causes you to see large gaps in this scenario.
- Someone used the
You can manually change the current "next identity" value with this command:
DBCC CHECKIDENT ('dbo.Transaction_Payment_NO', RESEED, 1712149313);
This one seems less likely, because you or one of the admins would have to go out of their way to do it. Similarly...
- Someone inserted those values manually
You can insert whatever you like into an
IDENTITY column by first running this statement:
SET IDENTITY_INSERT dbo.Transaction_Payment_NO ON;
- Failovers and restarts
You mentioned this in the question, but just for completeness - SQL Server caches identity values in order to improve performance. But those pre-allocated identity values can be lost if the service restarts or an AG failover occurs. This leads to more predictable gaps though (10,000 on modern versions of SQL Server).