Re: Suggestions/advice on choosing/configuring a high load/high reliabilty system

A couple of comments, but not exhaustive...

1. Definitely put the Redo on a separate set of disks, preferably striping the Redo Logs if you can afford the disks, and don't forget that the Member should be on a different disk. Also, GROUP 1 Logs are on a different set of disks to GROUP 2 Logs if you are archiving, which I would expect. Minimum number of disks therefore = 4 for non Struiped and 8 for Striped.
2. Go for UNIX, again like another post, I am from the UNIX would.
3. Make sure that the RAID level is set correctly.
4. Consider using Partitioning since the PURGE will be easier. I believe with o8i the BLOB can be partitioned as well.
5. Buy monitoring tools for the system, and sell them as part of the solution. If you are still going to be responsible for the performance of the system after the client gets the system, then make sure it supports remote monitoring with Agents and the like. In alphabetical order and not exhaustive BMC / Platinum / Quest / ...
6. Don't worry about the NT Clients, they are ideal for client, but not for the database. IMHO.
7. Make sure that the SQL*Net is tuned for large packets. This might kill you outright if you are trying to ship 300K per transaction.
8. 300K per transaction = large LOG_BUFFER or LOG_SPACE_REQUESTS.

Just some thoughts,
Andrew

smb_slb_at_my-dejanews.com wrote:

> Hi all,
>
> I've been implementing databases (Oracle & Sybase) for a number of
> years now, but I'm currently on an assignment where the performance
> requirements of the system are considerably greater than what I've
> worked with in the past. I'm looking for some information (both
> anecdotal & 'scientific' (i.e. articles)) on how to set this system up.
>
> Here's the scenario: The system must be available 24/7, and will be
> receiving data at a rate of around 2-5 megabytes per second, although
> this throuput is mostly due to blobs, not zillions of transactions. The
> data will be coming in as "stores" of around 300K each, at the rate of
> 5 per second. Each store will consist of around 10-30 inserts, maybe 1
> or 2 of which contain the blobs (the rest are small rowsize tables).
> There will be up to 10 "users" (actually they are machines - the system
> is a data-acquisition tool) creating this output.
>
> The database will hold onto the blob data for about a week, then let it
> spool off. The starting configuration for the system will be about 200
> Gigabytes of disk. More disk can be added to increase the amount of
> time you hold onto
> the blobs.
>
> The rest of the system (client machines) will be NT boxes.
>
> Here's my questions:
> - Should we go NT or SUN? This system will be sold "turnkey" to our
> customers, and our field techs will be responsible for handling
> problems. Is the added reliability & performance of a SUN box enough
> to justify the hassle of requiring our field techs to know 2 OS's?
>
> - We obviously need some big RAID subsystem to handle this.
> .Hot-swapping is absolutely necessary, since with 200 - 500 Gig of
> disk, you know they're going to be failing. What RAID level should we
> be running this at, and if we go for 'total safety' is there any reason
> to get another controller & disk to handle the log files & such, or
> will they actually be safer on our big fancy RAID?
>
> - Will a 4 processor system be enough to handle this setup? Can NT
> deal gracefully with this much disk?
>
> - What are some likely candidates for RAID systems & CPU's?
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---
Received on Mon May 24 1999 - 19:00:55 CDT