The first thing I would do is set an identity gap for this column. This allows you to limit the size of the gap when the dataserver is shutdown hard/ungracefully.
The current setting of '0' means the gap is determined by the dataserver configuration setting 'identity burning set factor' which has a default setting of 5000. This translates into a gap of 1/5000th (0.02%) of all possible ident values, which in your case would be a gap of 2million. By limiting the size of the gap you can extend the period of time you have until you run out of identity values.
I would probably start with a gap value of 10K: sp_chgattribute <table_name>, 'identity_gap', 10000.
numeric(10) means you can have up to 9,999 billion ident values. The current max() value is 9.63 billion. So you have ~369 million ident values to go before you run out of ident values.
Reducing your gap from 2million to 10K should slow down the pace at which you use up the last 369 million ident values.
While setting an identity gap won't eliminate the chance of running out of ident values, it will give you more time to come up with a more permanent solution.
-----------------------
Right now you have ~369 million ident values to go before you run out. (Just curious ... How many values do you use up in a week, month, year?)
What I find interesting is that you have 1.79 billion ident values at the 'beginning' of the table that could now be re-used.
The normal way to (re)set the 'next' ident value would be to call sp_chgattribute <table_name>, 'identity_burn_max', 0,'<new_ident_value>'. Unfortunately this won't allow you to set the ident number lower than the current max. While it's possible to override this behavior (ie, you can set the value lower) it requires some undocumented steps.
Instead of rehashing those steps here I'd suggest you take a look at Rob Verschoor's writeup on ident values ... which includes code that can be used for (re)setting the ident value lower. [Post back here if you have questions after reading Rob's notes.]
Hint: I'd suggest setting up a dummy table with a numeric(10) identity column, then use Rob's method to set the 'next' ident value forward and backward to verify his solution works.
-----------------------
The fact the table's min() ident value is 1.79 billion would tend to indicate that at some point in the past 'old rows' were deleted from the table.
I'd want to track down the problem with the purge process and get it fixed.
-----------------------
For your 'long term' solution I would skip rebuilding the table and instead be leaning towards the following:
- set a 10K gap now; this gives you more time (at least a couple years?) before you run out of ident values
- research how to (re)set the 'next' ident value back to '1'; this will allow you to tap into those 1.79 billion unused ident values at the 'beginning' of the table
- get the purge process working again; while it will probably be a loooong time before you use up the 1.79 billion ident values, a working purge process means you could continue to re-use the 9.999 billion ident values for an indefinite period of time (as you purge rows you leave 'behind' ident values that can be re-used; when you get to/near the end of the table you can reset the 'next' ident value to '1' thus allowing you to restart at the beginning of the ident value range)