I always thought the definition of getting screwed twice was this; A German student who auctioned her virginity and ended up paying 50% in taxes.
But it turns out that identity values in SQL Server can also screw you twice!
I used to really like identity values and problems have been rare, but this week, inside of a few days I've been screwed twice by identity values. This is also the year of embracing merge replication, time to meet your new friend the guid!
No need to rehash what happenned with identity values, but altering a table from int to bigint with 30 billion+ rows is not possible. Found two very helpful posts, i include their links here as they were most helpful:
To resolve (albeit temporarily) identity values running out for an int, do not forget you have the negative values.
DBCC CHECKIDENT ('ProcessActionHistory', RESEED, -2147483648);
Definetly we'll add a new automated health check, will probably fit in nicely with our script that check row counts occasionally to also start checking identity columns and raising alerts on certain thresholds.
I'll also be pushing back much harder on development teams that want identity columns with an int data type.