A missing number in a series of database identifiers can prompt a useful investigation. It does not, by itself, prove that a committed business transaction disappeared. Identifier generation and the evidence that business work was accepted can be different parts of an application.
For a buyer evaluating OceanBase or another distributed transaction database, the important question is what the identifier is meant to establish. A migration or capacity test should validate that requirement rather than assume that every numbered field is a complete transaction ledger.
Identify the purpose of the number
Ask whether the field identifies a record, orders a particular view, or supplies a separately defined business numbering requirement. Those purposes should not be merged merely because the field contains increasing-looking integers.
The application owner should state what must remain unique or traceable and how accepted business work is recorded. If the organization has an additional numbering rule, it needs its own explicit design and acceptance.
This is an application-evaluation question. The article does not prescribe accounting, invoice, regulatory, or legal numbering requirements.
Read the source sequence behavior
Oracle’s reviewed 26ai sequence reference explains that sequence generation is independent of transaction commit or rollback. It also describes how concurrent use and rolled-back work can create apparent gaps.
That is a specific documented reason why a number series should not automatically be treated as a list of committed transactions. It is not a statement that every gap in every application is harmless.
For another product, version, or identifier mechanism, obtain the corresponding behavior. A compatibility label or a familiar number format does not independently establish all generation, ordering, and persistence conditions.
Separate the evidence questions
The evaluation should make clear what each observation can show.
| Observation | Useful question | Conclusion it does not prove alone |
|---|---|---|
| Identifier allocated | What mechanism produced the value? | Business work committed successfully |
| Business record present | Which accepted state does the record represent? | Every preceding number must be another record |
| Gap observed | What does the selected mechanism permit? | A committed transaction was necessarily lost |
| Operation rolled back | What outcome did the application accept? | The generated value must be reused |
| Business reconciliation | Which accepted work is accounted for? | The identifier series alone supplies every answer |
These are proposed acceptance questions, not a claim that a database identifier replaces an application audit or reconciliation process.
Evaluate the target arrangement explicitly
An OceanBase Enterprise compatibility route can be relevant to an existing application. Confirm the selected offering, mode, and identifier mechanism against the actual requirement.
The same applies to a PostgreSQL-oriented distributed route such as YugabyteDB YSQL. Compare supported behavior and the application work needed to preserve the accepted meaning, rather than require every product to imitate an unverified assumption about the source.
Where an application changes its identifier design, record that as an explicit decision. A successful database migration should not silently convert a technical record key into a new business promise about numbering.
The test should include the behavior the project actually depends on, not only generation of one example value.
Include an unsuccessful operation in acceptance
Consider a hypothetical application that obtains an identifier and then does not complete the corresponding business operation. A later accepted record uses another value.
The pilot should establish the supported identifier behavior and show how the application records or explains the unsuccessful operation. The investigation should use the business evidence rather than decide the outcome solely from the apparent gap.
Also include concurrent work where relevant. A display of one user’s records may not show every consumer of a shared identifier mechanism, so the selected context matters when interpreting the series.
This is an original test exercise, not a reported OceanBase defect, an observed lost transaction, or proof that a particular application has complete audit coverage.
Reconcile business work using the accepted evidence
Keep the identifier specification, representative outcomes, and business acceptance together. Where the observed gap is unexpected under the selected design, investigate it instead of dismissing the concern with a general statement about sequences.
Equally, avoid declaring data loss without establishing which accepted business work is missing. A useful investigation should distinguish permitted identifier behavior from an actual discrepancy in the service’s records.
The business acceptance can use an explicit list of the operations that were accepted and the records that explain them. That gives the team a direct comparison with the intended work, including any operation that did not complete. The identifier series remains useful supporting information without being forced to answer questions its documented generation mechanism was never intended to settle.
OceanBase can be attractive when its supported transaction and compatibility arrangement meets the application’s real requirements. An alternative can fit under different conditions. The credible recommendation explains what identifiers establish and how committed work is accounted for. A sequence gap is a signal to interpret in context, not an automatic verdict about lost transactions.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.