Oracle FAQ Your Portal to the Oracle Knowledge Grid
 HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US

Home -> Community -> Mailing Lists -> Oracle-L -> RE: sequence numbers

# RE: sequence numbers

Date: Wed, 09 Oct 2002 09:48:46 -0800
Message-ID: <F001.004E49B6.20021009094846@fatcity.com>

> 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.

#!/usrbin/perl

my \$secondsPerYear = 365 * 24 * 60 * 60; my \$insertsPerSecond = 1000;

foreach my \$digits ( 12 .. 38 ) {

my \$yearsToExhaustion = (

```      (
( 10 * 10**(\$digits-1) ) -1
) / \$insertsPerSecond
```

) / \$secondsPerYear;

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

```        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
ORACLE-L <ORACLE-L_at_fatcity.com>
```                    @csedge.com>         cc:

Sent by: root        Subject:     sequence numbers

10/09/2002

10:54 AM

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).

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:

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

```
Received on Wed Oct 09 2002 - 12:48:46 CDT

Original text of this message

 HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US