Dealing with identity gaps

请大家耐心看下去，受益非浅！


Identity columns (sometimes referred to as "auto-increment" columns) remain a somewhat controversial topic in ASE: while the functionality is very useful, the implementation in ASE leaves quite a few things to be desired. In practice, this means that there is a risk of running into "identity gaps" : these are occasions where the identity value suddenly make large jumps, like from 10031 to 5000002 instead of to 10032, usually as a result of a shutdown with nowait.
Because shutdown with nowait cannot always be avoided, identity gaps may occur at some point, and they can cause real problems for applications that are not expecting such large numbers. 
It is unfortunate that ASE does not have any features to make repairing an identity gap easy: the repair procedure documented by Sybase is a bit clumsy and can cause significant application downtime (it requires a full BCP-out and BCP-in of the table). For this reason, some developers or DBAs have decided not to use identity columns at all. 

The problems caused by identity gaps can actually be limited; the precise method depends on your ASE version:

1)When running ASE 12.0 or later, you should use the identity_gap feature for each table with an identity column to limit the size of possible identity gaps. Details are described here . 见文1

2)For all ASE versions, you can design your data model in such a way that identity gaps will never occur.见文2


---------------------------------------------------------------------------

A better method for dealing with "identity gaps" 

Introduction
A well-known feature of Sybase Adaptive Server Enterprise is the "identity column". Identity columns are useful because they automatically generate consecutive numeric values upon insertion of new rows, while having minimal impact on performance. 
A disadvantage of using identity columns is that so-called "identity gaps" may occasionally occur. Identity gaps are large, sudden jumps in the value of an identity column, which often cause problems for applications. 
Unfortunately, there is currently no quick or easy way of repairing an identity gap. The standard remedy as recommended by Sybase Technical Support can be rather time-consuming, which may result in unacceptable, hour-long application downtime. For this reason, DBA’s or developers sometimes prefer to avoid the use of identity columns for applications with high availability requirements.

This article presents a database design technique that allows identity gaps to be fixed easily and quickly, taking no more than a few seconds. With this approach, full advantage can be taken of the functionality of identity columns, while minimising the impact on application availability in case identity gaps need to be repaired. 

What "identity gaps" look like
To illustrate the problems related to identity gaps, let’s assume the following simplified database design for storing invoice data: 

create table invoices
       (invoice_nr numeric(10,0) identity, 
       customer_nr int,
       amount money)

/* insert new invoice */
insert invoices (customer_nr, amount)
       values (@new_customer, @new_amount)

This involves a database table named invoices , having an identity column called invoice_nr. When a new invoice is created, the customer number and the amount payable are inserted into the invoices table. No value is specified for the invoice_nr column, as this value will automatically be generated as a result of the identity property. The value assigned to the new invoice number will be 1 higher than the previous invoice number that was generated. This way, identity columns automatically generate unique, consecutive numbers which make ideal primary keys in database systems. 

An identity gap has occurred when there is a large, unexpected jump in the value of an identity column, like in this example: 
1> select invoice_nr from invoices order by 1
2> go

invoice_nr 
---------- 
(...)
10028
10029
10030
10031
5000002
5000003

(1033 rows affected)           

For some reason, the invoice inserted after nr. 10031 was not assigned number 10032 as was expected. Instead, the invoice number jumps to 5000002 and continues to count up from there. This phenomenon is referred to as an "identity gap".
Such discontinuities in identity values are often a serious application problem. For example, some applications might not be able to handle invoice numbers of more than, say, 6 digits. Indeed, identity gaps are usually discovered because of application errors resulting from the unexpected high values in an identity column.
From the point of view of a DBA or end-user, identity gaps are almost always inconvenient, and should often be fixed immediately. 
It should be noted here that it is always possible that some individual identity column values are missing. This can happen when the transaction containing the insert operation is rolled back: the identity value that was already issued for this rolled-back row will not be re-used and therefore never show up as an invoice number. 
In this article, an "identity gap" refers to a gap of a large number of units, and not to individual missing identity column values. 

Why "identity gaps" occur
Identity gaps can occur following a rough server shutdown ("shutdown with nowait" or a crash of the server process. This is related to the algorithm the server uses to generate identity column values: essentially, a counter is kept in server memory, holding the identity value most recently issued. When a new row is inserted, this counter is incremented and the resulting value is assigned to the identity column in that row. While the new data row itself is written to disk, the new value of the in-memory counter is not. Only when the server is shut down in a normal way, this value is saved on disk. 
This algorithm makes the identity feature very fast, because no I/O is required to generate a new value. On the other hand, should the value of the in-memory counter be lost, as is the ca