| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: sequence numbers
> I'm really not so worried about gaps... more loosing the lost numbers.
This
> will be a warehouse, and with the way things are being defined, I think
we
> could run out if we load the way we anticipate with the way these are
being
> built.
April,
Do the math. :)
I did this exercise once to allay developers and mgrs fears that using a sequence would cause problems down the road when the sequence 'ran out'.
We standardized on a 12 digit integer for primary keys.
12 digits allows a maximum key value of (10 * 10^11)-1, or 999999999999.
If you were inserting 1000 rows per second, you sequence would run out of values in 999999999.999 seconds.
( ( 10 * 10^11 ) -1 ) / 1000 = 999999999.999
If your database did this 24*7 for 31.7 years, the sequence would indeed run out of values:
999999999.999 / ( 365 * 24 * 60 * 60 ) = 31.7
If that's not enough time, use more digits.
The following ( very short ) perl script can help you determine how big is big enough.
my $secondsPerYear = 365 * 24 * 60 * 60; my $insertsPerSecond = 1000;
foreach my $digits ( 12 .. 38 ) {
my $yearsToExhaustion = (
(
( 10 * 10**($digits-1) ) -1
) / $insertsPerSecond
printf("Digits: %3i Years: %36.4f\n", $digits, $yearsToExhaustion); }
Jared
April Wells <awells_at_csedge.com>
Sent by: root_at_fatcity.com
10/09/2002 09:28 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:
Subject: RE: sequence numbers
This was more of a defense question than anything....
I read the docs, but without knowing what volume we will be expecting, I
don't want stuff being aged out either. I don't guess making the
sequence_cache_entries double what I figure we will need will cause
anything
horrible... but It was put to me to try (without really TRYING) to
determine
what the ramifications were.
I'm really not so worried about gaps... more loosing the lost numbers.
This
will be a warehouse, and with the way things are being defined, I think we
could run out if we load the way we anticipate with the way these are
being
built.
Some tables may not have any records loaded, or less than 100... but that may be client specific, too...
Do you get the feeling that business rules should have come somewhat
earlier
in the project???
=)
Thank you Thomas...
April Wells
Oracle DBA
Keep yourself well oiled with life, laughter, new ideas and action.
Otherwise you will rust out. _Anonymous
-----Original Message-----
Sent: Wednesday, October 09, 2002 10:54 AM
To: Multiple recipients of list ORACLE-L
If the sequence is not cached then Oracle has to generate a new sequence number for every record inserted (CPU cycles). NOORDER is the default so that won't slow you up. If you're doing bulk loads why not cache the sequence numbers? Is it important that there be no gaps? Even with NOCACHE you can get gaps. If a sequence number is generated but the row (insert or create) is not COMMITed the sequence number is not rolled back.
Unless there are fewer than 100 rows to be inserted I'd go with some caching.
April Wells
<awells To: Multiple recipients of
list
@csedge.com> cc:
Sent by: root Subject: sequence numbers
10/09/2002
10:54 AM
Please
respond to
ORACLE-L
I have been given create scripts for sequences to be used in tables that will be loaded via bulk loads. How huge is the potential performance hit if I take out the cache 20?
April Wells
Oracle DBA
There is neither good nor bad, but thinking makes it so. -Shakespeare
<< Attachment Removed : InterScan_Disclaimer.txt >>
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Thomas Day INET: tday6_at_csc.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: April Wells INET: awells_at_csedge.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Wed Oct 09 2002 - 12:48:46 CDT-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: Jared.Still_at_radisys.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
- text/plain attachment: InterScan_Disclaimer.txt
 |
 |