How many records can we create in a Siebel server database before the ROW_ID "hits the wall"?
So let's try to find the answer together:
- A ROW_ID value in a Siebel server database consists of a prefix (1 for the 'HQ' database) and a suffix.
- Prefix and suffix are separated by a hyphen (-).
- A ROW_ID can be 15 characters long, so 13 characters are left for the suffix.
- The suffix is in base36, consisting of upper case characters (English alphabet) from A to Z and numbers from 0 to 9.
For those with more interest in the Siebel ROW_ID, you can read up here:
Article on My Oracle Support: What is RowID/ROW_ID, and How is it Generated and Used? (Doc ID 476256.1)
The Calculation
As pointed out by Bash, the maximum ROW_ID ever imaginable would be
1-ZZZZZZZZZZZZZ (13 Zs)
170,581,728,179,578,208,466
whereas 3613 calculates to
170,581,728,179,578,208,256
Not sure which one is right but I don't wan't to appear nit-picky here ;-)
The conversion tool does not count the value zero BTW.
In addition we did not take into account that we can have ROW_IDs of different lengths (see below).
The Example
Let's use a base2 approach with the letters A and B.
If we would have only 1 character for the suffix, the possible ROW_ID values would be
1-A, 1-B (2 possible values)
For 2 characters it would be
1-A, 1-B, 1-AA, 1-AB, 1-BA, 1-BB (6 = 2 +4 possible values - where 4 = 22)
For 3 characters suffix length, the possible ROW_IDs would be
1-A, 1-B, 1-AA, 1-AB, 1-BA, 1-BB, 1-AAA, 1-AAB, 1-ABA, 1-ABB, 1-BAA, 1-BAB, 1-BBA, 1-BBB (15 = 21 + 22 + 23)
So when we extend the example to base36 and 13 characters for the suffix, we would end with
(361 + 362 + 363 + 364 + 365 + 366 + 367 + 368 + 369 + 3610 + 3611 + 3612 + 3613)
The result of this calculation is
175,455,491,841,851,871,348
which is a bit more than the first result (roughly 5.4 quintillion or so ;-)
My result (hopefully correct) is
Really so many?
Bash and Lennard are completely right in mentioning that the ROW_ID generation mechanism "reserves" blocks of 100 for a session. So in real life we could end up with anything close to 1/100 of this value (still 1.75 quintillion) or even less (assuming that some sessions are closed without creating a single record).
The consequences of large numbers
Let's assume we try to store 1.75 quintillion (let's stick with this number for a while) records in a database and each record consumes 1000 bytes (highly underestimated for easier calculation).
The number of bytes needed to store this information is
1,750,000,000,000,000,000,000 bytes
or
which translates to 1.75 billion hard drives with 1000 GB of storage.
Studies claim that the data traffic produced by internet users will reach a volume of 1 ZB by 2015.
If you would use an interface which creates 1 million records per hour, it would take
1.75 trillion hours
or
199,771,000 years
to complete the task of creating 1.75 quintillion records.
In other terms, if the first mammals would have had computers (and Siebel EIM) they should have been finished by now.
Conclusion
No need to fear that we run out of ROW_IDs in our Siebel database how many records we might be ever able to produce.
Some more: offensive ROW_IDs
As PaulH pointed out in his answer, some ROW_IDs could have an offensive meaning such as (hold your breath)
1-WTF
(or even worse...). According to my experience this is clearly the case. I have personally witnessed such a naughty ROW_ID for a new record to be 1-NEU (which translates to 'NEW' in english).
Oracle Support describes this behaviour (Doc ID 603077.1) and recommends to use the RowIdToRowNum() function to convert alphanumeric ROW_IDs to numeric values when the Id needs to be on screen or printed.
Have a nice day
@lex