Re: 300K Commits/Hour

In article
<Pine.SV4.3.91.950209233201.19512E-100000_at_brisbane.DIALix.oz.au>, Thomas Mudd <gers_at_brisbane.DIALix.oz.au> wrote:

> Has anyone ever seen an Oracle database handle anything close to 300K commits
> (including index updates) per hour?
>
> The environment would consist of 1200 users on client machines running an
> OLTP application.

How do I look at the article? (I am somewhat new to the internet)

Any way, I am currently involved with a OLTP simulation project though not quite at that scale.

My system is currently performing at over 40,000 business transactions ( each with one to three commits) per hour with a simulated 80 to 120 users. Each of these transactions consists of 6 to 24 database updates, inserts and deletes. Each of these may affect an index or two. This system is based on two primary tables and a number of subsidiary tables. This system is only on a Sun Sparc 1000 with four 60Mhz processors. (Currently this is my personal computer!!)

It is interesting in that, as I am adding processors to this system, performance is not quite scaling as fast I thought. Presently there is some type of resource(s) that is causing some type of contention. Symptons: total transaction times are increasing, total transaction volumes are falling off, there is a wide difference between some types of transactions times yet small differences in logic.

I have done some work on redo logs, disk layout, index work (lots or work), good database desing (fully relational) and many of the other standard performance tuning tricks. I'll find a few more in this process...

The big question is how to decide which SQL statements to persue to tune/rewrite? Which statements which run in 30 miliseconds will run in 300 miliseconds when in a whole system?

• Is there any way to get timing stats in hundreths of a second inside a database stored procedure??? HELP

I would like to be contacted further in your quest -- Performance tuning is a constant journey and your learn more by the journey than actually getting there.

Y'know concerning splitting up this newsgroup there should be a seperate group labeled "Wizard Tricks" for all of the things we learn out there. Received on Sat Feb 11 1995 - 05:47:28 CET