Re: Scalable Performace - Inserts/Updates

Assuming that the application is written to use bind variables the next step is to make sure you have enough IO capacity to handle the load. 64 processors with 1 drive won't cut the mustard. Also you need enough controllers so they don't get saturated. Jim

<petergunn_at_hotmail.com> wrote in message news:91lk6n$1q7$1_at_nnrp1.deja.com...
> Several years back I used to work with Oracle 6, but changed
> career path to realtime C++/Unix systems. Consequently I
> still try and think of RDBMS like Oracle in terms of their
> 1993 verions. Hopefully things have moved along from those
> days especially with regard to scalability.
>
> I have been involved on the edge of several realtime
> projects in recent years which have had limited success
> due to a requirement to store a transaction log in
> Oracle (or Sybase). These systems would typically use
> a single Solaris server with fast disks and lots of memory,
> but would invariably grind to a halt at >200 individually
> commited inserts/updates per second.
>
> An obvious and more successful approach would be to
> decouple the DB from the messaging system and implement
> queuing (or get middleware that already does that), but
> it would be desirable to have a complete and up-to-date
> DB rather than using kludgy work arounds like this.
>
> If I wanted to implement an Oracle server that could
> cope with 1000+ commited inserts/updates per second as
> well as 1000+ simple indexed queries per second what
> sort of designs would be relevant?
>
> I'd rather not have multiple DBs if it can be avoided.
>
> ttfn
>
> PG.
>
>
> Sent via Deja.com
> http://www.deja.com/
Received on Mon Dec 18 2000 - 19:42:10 CST