: Tuesday, September 23, 2003
4:05 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Insert performance
I have already bumped
that up quite a bit as well, but I still get many waits.
Thanks,
Rick
Stephenson
Oracle
Database Administrator
Ovid
Technologies, Inc.
[EMAIL PROTECTED
22, 2003
11:10 PM
To: Multiple recipients of list
ORACLE-L
Subject: Re: Insert performance
At 09:44 PM 9/22/2003, you wrote:
Does anyone have any idea how to
improve performance for multiple inserts into a table that uses a sequence
generated primary key?
Is the sequence cache set to an
Sent: Tuesday, September 23, 2003 6:44
AM
Subject: Insert performance
Does anyone have any idea how to
improve performance for multiple inserts into a table that uses a sequence
generated primary key?
I have approximately 6 concurrent
inserts per second into this table
At 09:44 PM 9/22/2003, you wrote:
Does
anyone have any idea how to improve performance for multiple inserts into
a table that uses a sequence generated primary
key?
Is the sequence cache set to an appropriately large value?
Justin Cave
I have approximately 6 concurrent inserts per second into t
Rick,
I haven't tried this myself but you could consider a reverse key index (depending on
your version).
That way multiple inserts won't go to the same block.
However, (from Perf Tuning 101) you will incur much more IO than a normal index if you
do range scans, so you'd need to consider how yo
Does anyone have any idea how to improve performance for
multiple inserts into a table that uses a sequence generated primary key?
I have approximately 6 concurrent inserts per second into
this table which causes the primary key index to become a hot block. This
in turn causes "buffer
oepke, Kevin M" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
>Subject: RE: Partitoned Table Insert Performance
>Date: Thu, 02 May 2002 09:48:31 -0800
>
>Way back in the days of Oracle 8.0.5 I did
Way back in the days of Oracle 8.0.5 I did some performance testing of bulk
inserts/sqlldr of range partitioned tables v.s. non-partitioned tables. I
don't have the benchmarks on hand, but here's what I found. All tests were
done using the direct path inserts (sqlldr direct=true or /*+ APPEND */)
My last set of test results is a little out of date,
but here's an idea to check.
Inserting single rows:
partitioned key insert HAD ca. 50% overhead
Array Inserts sorted by partition key to get lots
of adjacent rows in the same partition
virtually no overhead
Array inserts randomised t
I am in the process of implementing partitioning on some existing tables. I
have been asked by management to evaluate the performance impacts of the
changes. I am aware of many of the performance advantages of partitioning:
partition pruning, partition-wise joins and parallel data loads. What I am
; logical
> > > I/O. You can check on that as well.
> > >
> > > Hope this helps.
> > >
> > > Shakir
> > >
> > > --- Paul Baumgartel <[EMAIL PROTECTED]> wrote:
> > > > Greetings!
> > > >
&g
n that as well.
> >
> > Hope this helps.
> >
> > Shakir
> >
> > --- Paul Baumgartel <[EMAIL PROTECTED]> wrote:
> > > Greetings!
> > >
> > > I am trying to diagnose a performance difference between two
> > > databases
&
e test. They are similarly configured (same SGA size,
> etc.), and the servers are identical except for the number of CPUs
> (server A has 4, server B has 6).
>
> On database A, INSERT performance is about 190 rows/second.
>
> On database B, INSERT performance is over 500 rows/
> Greetings!
>
> I am trying to diagnose a performance difference between two
> databases
> running the same test. They are similarly configured (same SGA size,
> etc.), and the servers are identical except for the number of CPUs
> (server A has 4, server B has 6).
>
&
xcept for the number of CPUs
> (server A has 4, server B has 6).
>
> On database A, INSERT performance is about 190 rows/second.
>
> On database B, INSERT performance is over 500 rows/second.
>
> I saw some cache buffers chains, buffer busy, and library cache latch
> waits o
igured (same SGA
> size,
> > etc.), and the servers are identical except for the number of CPUs
> > (server A has 4, server B has 6).
> >
> > On database A, INSERT performance is about 190 rows/second.
> >
> > On database B, INSERT performance is over 5
Greetings!
I am trying to diagnose a performance difference between two databases
running the same test. They are similarly configured (same SGA size,
etc.), and the servers are identical except for the number of CPUs
(server A has 4, server B has 6).
On database A, INSERT performance is about 190
GA size,
> etc.), and the servers are identical except for the number of CPUs
> (server A has 4, server B has 6).
>
> On database A, INSERT performance is about 190 rows/second.
>
> On database B, INSERT performance is over 500 rows/second.
>
> I saw some cache buffers
.
Anjo.
Paul Baumgartel wrote:
> Follow-up question: can someone explain exactly why buffer busy waits
> can be due to heavy insert activity when there are insufficient
> freelists? I suspect that this may figure into my problem with insert
> performance. Thanks!
>
&g
Follow-up question: can someone explain exactly why buffer busy waits
can be due to heavy insert activity when there are insufficient
freelists? I suspect that this may figure into my problem with insert
performance. Thanks!
Paul Baumgartel
Greetings!
I am trying to diagnose a performance difference between two databases
running the same test. They are similarly configured (same SGA size,
etc.), and the servers are identical except for the number of CPUs
(server A has 4, server B has 6).
On database A, INSERT performance is about
22 matches
Mail list logo
