Re: 10,000 concurrent users

Hi,

I don't think this is a good idea to put so big database on one server. Why don't you try to distrbute database on different servers, Then, transfer data to one supper server? It's impossible to maintain so large database if it's on-line 7X24.

Regards

In article <757fcr$kd6$1_at_nnrp1.dejanews.com>,   mgogala_at_rocketmail.com wrote:
> In article <36769DCB.CCCFE2A6_at_rcc.nl>,
> willie.verberne_at_rcc.nl wrote:
> > Hello fellow DBA's,
> > We're going to manage a database next year for one of our custumors that
> > is going to have, after about a year of implementation, about 10,000
> > concurrent users.
> > Has anybody out there got some experience with this, that i can ask a
> > few questions along the way?
> > It's a 7.3.4 database on a DG unix server, a client server application,
> > and all together it's got some 3000 Gb.
> > Thanks,
> >
> > Willie.Verberne_at_rcc.nl
> >
> >
>
> For that kind of load, you need a really big machine. It should have at least
> 16GB of storage, > 40 CPUs, fiber channel based storage, VLM option, a good
> backup (I can only recommend Legato Networker), at least 2 DLT stackers, and
> if all that was not enough, I recommend clustering (parallel server), too.
> Furthermore, upgrade to 8.0.5 A.S.A.P, because it has much better optimizer
> and has some things which can be of immense help (partitioning, index only
> tables, separate configurable pools for "cached" and "transient" tables,
> minimal extent for the tablespace) Above all, get yourself a good consultant
> which has a) already done a similar project and b) has a good references to
> do the initial database layout. Reorganizing once fragmented and
> misconfigured database requires a major downtime and can be very expensive.
> Oh yes, make sure to put ARIS DFRAG on your purchase list, because doing it
> via export/import utilities is simply impossible. You should also try to
> optimize your applications on both OS side and SQL side. This optimization is
> the most important step in the whole process, because a bad application can
> ruin even the best database server. A decent support from Oracle Corp (i.e.
> silver) would also be a nice thing. Before sizing the machine, try to define
> a "typical" transaction and do some benchmarking and calculations. Try to
> find out what other companies which have such data volume use for this
> purpose. A good place to start looking would be Oracle corp itself. You can
> enlist them to help you, because they just love big servers, for marketing
> purposes (remember a challenge to Microsoft)? Last, but not least, just keep
> smiling.
>
> --
> Mladen Gogala
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>

-----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own Received on Fri Dec 18 1998 - 02:50:03 CST