> 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 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
10/09/2002 09:28 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
@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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
The information contained in this e-mail is strictly confidential and for the intended
use of the addressee only; it may also be legally privileged and/or price sensitive.
Notice is hereby given that any disclosure, use or copying of the information by
anyone other than the intended recipient is prohibited and may be illegal. If you
have received this message in error, please notify the sender immediately by return
e-mail.
Corporate Systems, Inc. has taken every reasonable precaution to ensure that any
attachment to this e-mail has been swept for viruses. We accept no liability for any
damage sustained as a result of software viruses and advise you carry out your own
virus checks before opening any attachment.
