Re: server sizing

And I'm just in the mood for a ramble, too...

We stayed with NT too, because we have the sysadmins and engineers already. I have a DB that sounds a lot like yours and it's running just fine on a dual p400 with a mirror for redo and archive log and a raid5 for the data files. The real problem with NT is the memory cap. I couldn't get 4GB at the time of purchase, so we can't use Enterprise server to skew the memory divide, and NT is gobbling up half of my 2GB server. That's fine for < 100 users, but as we edge up we're having to reduce buffer cache to avoid paging, which is bad (although admittedly it's not affecting performance yet). When the buying freeze lifts I'll recommend the 4GB upgrade. It wouldn't be so bad, except I had to install the Java engine for this one, and it's taking a good quarter gigabyte.

I haven't found the RAID5 to be an operations hazard, though, except in maintenance tasks. Large imports, tablespace reorgs, index rebuilds and sweeping updates suffer but so far the small stuff the application sends in is absorbed by the cache and runs just fine. Of course I'm only running about 10-20 write transactions a minute on the DB in question. If that picks up I'll be back to the funding well for more external arrays.

I (personally) would just buy more or better equipment if I needed the small boost that raw partitions would give -- I like the hardware RAID and the OS backup utilities too much to go the raw route. Using more volumes is still a good idea, if you can get them on different controllers, but for goodness' sake don't bother partitioning a RAID. More than 2 channels on a controller may challenge your cache size or bus speeds, so multiple controllers is still a good idea if you can saturate 2 channels. Raid 0+1 makes a difference over raid 5 if you have room in the rack for that many drives, and I'll certainly be doing that if the projects that want the SAN pan out. I keep everything redundant (no raid0) on this class of box, though -- too many things can go wrong, and losing your redo log volume takes your database down.

That reminds me of a story -- Last month one of my engineers noticed a warning light that indicated one of the redundant power supplies in a storage array had gone out. He jiggled the power cable. It was the wrong one... The database files were taken offline by that, but it was night and the DB was quiet and fortunately that array had only half of the OS/logging mirror for that server, so Oracle recovered after a quick shutdown-replace-reboot cycle.

You specified an upper bound of about 2 transactions per second, which should be doable with an NT system with 300 users. If you go much beyond 300 - 500, however, you'll probably start running into memory/networking performance limits on NT. In general, you should consider UNIX systems for optimum performance. NT has too many little gotchas like the lack of memory and process control. Some, like limits on total memory and practical problems with number of controllers, are related to the Intel architecture so you'll need to look past Linux, although Linux can be a good half-step when your NT boxes start underperforming. In moving to Linux you'd get more available RAM and less OS overhead, but you'll have to completely re-learn system administration and then do it again (incrementally) when you hit the architecture limits, as Linux on other-than-intel architectures is not supported by Oracle.

So if there's money I'd look at starting on NT since it's an easy step up, but plan on developing or buying some Sun engineers (or HP, or other) by the time you're ready for those upper limits. They can take you to Ludicrous Speed, but for us mere mortals NT is a good starting point.

"Streeter, Lerone A LBX" wrote:

> I'm envisioning various levels of raid just wanted to get something out
> quick for some feedback. for example, I'm thinking the data files, redo
> logs, arc log, and control files would be on differently combined disks.
>
> of course some file system recovery and redundancy is desired, but to what
> level should we go? currently we've got a raid1 set w/ O/S and documents,
> raid5 with hot spares for our existing mssql DB, and the logs on separate
> raid5 set; wanted raid1 for mssql logs but other issues arose and we had to
> go w/ raid5. this is very functional and suits our needs, failure coverage,
> low processor utilization, etc. but with oracle I'd be very worried about
> running on a similarly built platform.
>
> I didn't even mention raw partitions, which were stressed as being a better
> scenario. they offered the suggestion of multiple controllers with database
> files spread across drives and controllers, this method of "striping" being
> an alternative to raid. I wasn't too comfortable with the thought of a
> server w/ raw partitions and no hardware redundancy/recovery implementation,
> but the performance/functionality benefits were highly praised. so I
> thought maybe a mix, some raid10 or 01.
>
> maybe a raid1 set containing O/S, arc, and control files, a number of raid0
> sets with redo logs stripped across them, and a raid5 set with the data
> files. then there's the issue of storage, what capacity to shoot for as
> well as memory; currently we've got 1.2Gs of RAM and I'd shoot for at least
> twice that.
>
> why NT? familiarity and comfort. we've asked and everyone doted on
> oracle's ability to run on NT just as well as *nix and being that we have 0
> *nix boxes mgmt of course wanted NT. we looked for support in having oracle
> on *nix but found none and accepted the offering.
>
> thanks for the feedback. I'm hoping some others will offer suggestions or
> comments, support, or horror stories to help me in gathering information.
>
> I don't know if the additional processing will burden the system based on
> drive configuration/file system choices. I don't know if a couple of
> controllers or several will be required, just trying to get an idea of what
> exists.
>
> we haven't purchased any hardware yet but we need to get an idea soon.
> thanks again for the feedback, and forgive my ramblings.
> ===========================================
> Lerone Streeter
> System Analyst
> Abbott LBG
> StreeLA2_at_hpd.abbott.com
> ===========================================
>
> -----Original Message-----
> [mailto:Ed.Haskins_at_VerizonWireless.com]
> Sent: Tuesday, April 17, 2001 2:59 PM
> To: Multiple recipients of list ORACLE-L
>
> Lerone,
>
> My opinion is that your database on an NT platform will not scale as well as
> you may hope. You are talking about adding 100-150% more data and tripling
> your users to 300. I would strongly recommend going to a Unix platform for
> your database. Also, if the database is going to grow that much...it is
> likely a write intensive application that would perform better on something
> other than RAID5...maybe RAID0+1.
>
> Certainly there are servers that can handle this load...on NT, but if you
> are going to that large a server...why not go Unix and increase your
> performance (I know, an NT box costs less...but if cost isn't an issue!?!).
>
> That's just my opinion...and I actually started my IT career as an NT Admin!
>
> Ed Haskins
> Oracle DBA
> Verizon Wireless
>
> -----Original Message-----
> Sent: Tuesday, April 17, 2001 12:35 PM
> To: Multiple recipients of list ORACLE-L
>
> in gaining knowledge about oracle I've been introduced to some concepts,
> components, and concerns and I'd like to get some general feedback. so, in
> general how big of a deal is server design? what would you use as criteria
> for decision making, like the need for multiple controllers and drive/file
> system configurations.
>
> my background is with ms-sql/nt and we're looking at migrating/upgrading to
> oracle/nt. we've had success with raid 5 via a single controller with
> multiple channels. I've been to the oracle dba pt 1a and have been exposed
> to oracle architecture; we never had such concerns so I have no basis of
> comparison. our instructor and classmates, while knowledgeable, were more
> developers than system engineers; whereas we'll be more system
> engineers/administrators than developers. what kinds of metrics/performance
> should I be looking at, considering, and shooting for from the start?
>
> right now we have about 100 users and a 20G DB which *will* increase to
> probably 300 users and 40G to 50G DB; on average we're looking at about
> thirty thousand transactions over an 11 hour period; again that'll probably
> increase to 70,000 to 80,000 transactions over an 11 hour period.
> reads/writes/queries/indexes, their size and speed, and other such
> processing metrics, were never a concern.
>
> ===========================================
> Lerone Streeter
> System Analyst
> Abbott LBG
> StreeLA2_at_hpd.abbott.com
> ===========================================
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Streeter, Lerone A LBX
> INET: StreeLA2_at_HPD.Abbott.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author:
> INET: Ed.Haskins_at_VerizonWireless.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Streeter, Lerone A LBX
> INET: StreeLA2_at_HPD.Abbott.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
Received on Tue Apr 17 2001 - 17:18:53 CDT