NT/Oracle defrag: just say no / RE: server sizing [NT: need XEON?]
Lerone, (It appears you wanted to also reply to the list, but didn't get the list address into your response, so I'm including your entire message below in this reply to the list. ) Glad you found the info useful. I hope you are going to be able to get a box that can be upgraded from 2 cpus to at least 4 (or that your SLA states that additional scaling might require whole replacement with a 4way or 6way or 8way box later). We had a discussion of NT/Oracle defrag recently. As you probably know, the "conventional wisdom" for NT SysAdmins is to use one of the better defrag products, and frequently. http://www.ultratech-llc.com/Personal/Files/?File=Defragger.TXT However, Oracle says that *IF* you do things "right", you should NOT want-to/need-to/have-to defrag. Something along the lines of: NTFS is such that when the Oracle db files are pre-allocated, they are basically "pre-defragged", and since they are maintained as large files, there are *no* conditions under which they are going to fragment (at the OS level) after being created. All defragging should be internal to Oracle (imp/exp, or whatever...) Having repeatedly read the "conventional wisdom" about the need to defrag NT constantly, I was initially amazed at Oracle's assertion, but in subsequent discussion with Oracle tech support, as well as the gurus in this list and the NT list, it turns out Oracle is right. Of course for a non-db server (eg, a file server) that has a lot of small files that change a lot, defragging is needed. I noticed that you haven't mentioned backup issues. We are currently struggling to decide between getting the Oracle modules from either Legato or Veritas (hot backup), or just staying with NT4, and doing manual/scripted cold backups only. On another, semi-related topic, when I used to be subscribed to a couple of Netware SysAdmin lists, I noticed that there was a pretty high percentage of people subscribed with a *lot* of "old school" type engineering and hardware Intel/Drive-config/Networking expertise. You might consider subscribing to one of those and slip a few hardware questions in. (archives: http://lsv.syr.edu/archives/novell.html, that list's super-guru: Joe Doupnik <[EMAIL PROTECTED]>) Of course beware that SysAmins, especially Netwareistas & other old timers, usually tend to hate dbas, and refer to Oracle as "the beast". :) regards, ep On 18 Apr 2001, at 10:04, Streeter, Lerone A LBX <[EMAIL PROTECTED]> wrote: To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Date sent: Wed, 18 Apr 2001 10:04:06 -0500 > thank you all, such an incredible amount of information and some much > desired real world testimony. just off the top of my head we'll more than > likely be going with compaq and there are versions of windows 2000 that > support 8GB of RAM so that should suffice. a lot of my information is > gestimates based on what we have or know. i consider us small-to-medium and > the 300 users and such are worst case guesses based on one time peaks. > > as i remember we were looking at dual 1GHz processor boxii and being that > our existing, insufficient, storage is about 200G we'll be looking at > external rack mount chassis. we have to archive/purge our database at > regular intervals to manage space and the archive information needs to be > readily accessible for six years. right now we've got a production database > and at least four archive databases which consume about 90G. > > I think we'll be ok with the mixed bag of drive configurations, raid5 and > raid1; no raid0... failed drive will kill the raid0 set, better to use a > more recoverable raid; which brings up another question. Defragmentation. > they talked a lot on defragmentation so now i'm wondering how may of you > NT'ers use an O/S defragmenter or do you use the export/drop/build/import > method? not good with millions of rows i'd assume from my own personal > experiences with migrating from server to server. i'm working on a > spec/tech document and i'll post it when completed, with acknowledgements of > course... thanks. > > > > === > Lerone Streeter > System Analyst > Abbott LBG > [EMAIL PROTECTED] > === ... > On 17 Apr 2001, at 12:11, Streeter, Lerone A LBX wrote: > > Date sent:Tue, 17 Apr 2001 12:11:22 -0800 > To: Multiple recipients of list ORACLE-L > <[EMAIL PROTECTED]> > From: "Streeter, Lerone A LBX" > <[EMAIL PROTECTED]> > Subject: RE: server sizing > > ... > > > why NT? familiar
RE: server sizing [NT: need XEON?]
yes, I made a mistake then... I'll see what I can do to collect metrics on logical/physical I/Os. my information is based on NT/MSSQL, we are moving to oracle so some things you mentioned were never a concern; ultimately I want to have the infrastructure as sound, functional, and scalable as possible. we've already been bitten a few times, long stories that I won't go into; regardless they've resulted in complete rebuilds and redesigns. I dread spending another 50hr holiday weekend watching lights flash hoping I can get production backup before the users get in. I have seen CPU utilization jump in certain scenarios so that disk I/O may be an issue but with load distributed across multiple controller channels... I don't know; maybe good, maybe not. I'll take note of the drive specs and their levels of performance. I hadn't even considered not having multiple writers, I was sure we'd discussed implementing it in class but maybe we just covered the theory. I know of the six major processes ARC0, LGWR0, DBWR0, SMON, PMON, and CKPT. I was sure they mentioned DBWR, LGWR, and ARC with 0's to implicate the ability to have additional processes. as I remember having multiple writers was mentioned as a way of managing performance and eliminating some of those bottlenecks. thanks. === Lerone Streeter System Analyst Abbott LBG [EMAIL PROTECTED] === -Original Message- Sent: Wednesday, April 18, 2001 4:35 AM To: Multiple recipients of list ORACLE-L "Eric D. Pierce" wrote: > If you can get ahold of him, or can wait until he > isn't so busy, Paul Drake of this list is the resident RAID/hardware > expert. Eric - this is one of the funniest pages I have seen: http://www.ultratech-llc.com/Personal/Files/?File=~MoreInfo.TXT uh oh. I don't know if I'm honored, or scared. I'm not nearly the resident RAID expert - but would like to be someday. These 4-drive JBOD workstations at home don't quite give me the room to play. Does the word "Heuristics" mean anything to you? I'd rather have stats than guidelines. Here is my one word of caution before heading off into some other direction: multiple database writer processes are not supported for Oracle 8.1.7 on NT. This is straight off of the platform-specific docs off of the Docs CDROM. I did receive an ORA-00600 error relating to running multiple db_writers on NT with 8.1.6. Don't do it. >From Metalink: Subject: Re : Db Writer Process Oracle on NT only allows/needs a single database writer process (DBWR). Multiple DBWRs on UNIX is not multiple "real" DBWRs which all go scan for dirty buffers and write them to disk. It's really just one "real" DBWR and some I/O slaves. The "real" DBWR tells the slave DBWRs to do I/O. On NT, there's really no need for this since async I/O and NT will take care of all that for you. NT acts as the I/O slaves and the "real" DBWR [1 DBWR thread] then checks the "slaves" to see if the I/O is done. Melissa Holman Oracle Support Will this produce the rate-limiting-factor in your system? I do not know. *Something* will be a rate limiting factor for a particular process. But as OLTP users' transactions vary so much from the batch processes, what exactly is the overall rate_limiting_factor is tough to say - your mileage will vary. My background is in Chemical Engineering. I spent some time in R & D wearing a white labcoat. Chemical Engineering - Process Debottlenecking - is all about "Where is the bottleneck?" Usually, a 15-20% margin is designed in such that the plant can run safely over its design spec without a retrofit of key components. Beyond that - you have to find what component needs to be increased to add capacity - safely. For your system - design in more capacity that you need, with room for expansion. Empty drive bays in external storage cabinets are good. The rebuilds of drive arrays are painful - but if you had a 7 bay drive cage (half a 14 bay - e.g. Storageworks 4200) with only a 4 drive array, hiking it up to a 6 drive RAID 0+1 (I'd rather duplex these) with a hot spare is tolerable. On an Ultra 160/m channel, 6 drives is reasonable. Here is a baseline - I/Os per second. A standard drive can accommodate 80-100 I/Os per second. Larger bufffers (cache) on the hard drive can increase that number, as can read-ahead caching algorithms on the RAID controllers. But if the reads are scattered, as in index reads and nested loops - the cache hits are not very likely. Lots of memory reduces the amount of read I/O required for a query. It does not reduce the amount of memory bandwidth required, nor does it completely reduce the overhead of creating consistent reads (reading rollback segs to provide cr blocks). This is a large part of the non-linear nature of scaling - interference of user processes creating additional overhead. When you say transactions per minute - these need to be translated out to actual logical and
Re: server sizing [NT: need XEON?]
"Eric D. Pierce" wrote: > If you can get ahold of him, or can wait until he > isn't so busy, Paul Drake of this list is the resident RAID/hardware > expert. Eric - this is one of the funniest pages I have seen: http://www.ultratech-llc.com/Personal/Files/?File=~MoreInfo.TXT uh oh. I don't know if I'm honored, or scared. I'm not nearly the resident RAID expert - but would like to be someday. These 4-drive JBOD workstations at home don't quite give me the room to play. Does the word "Heuristics" mean anything to you? I'd rather have stats than guidelines. Here is my one word of caution before heading off into some other direction: multiple database writer processes are not supported for Oracle 8.1.7 on NT. This is straight off of the platform-specific docs off of the Docs CDROM. I did receive an ORA-00600 error relating to running multiple db_writers on NT with 8.1.6. Don't do it. >From Metalink: Subject: Re : Db Writer Process Oracle on NT only allows/needs a single database writer process (DBWR). Multiple DBWRs on UNIX is not multiple "real" DBWRs which all go scan for dirty buffers and write them to disk. It's really just one "real" DBWR and some I/O slaves. The "real" DBWR tells the slave DBWRs to do I/O. On NT, there's really no need for this since async I/O and NT will take care of all that for you. NT acts as the I/O slaves and the "real" DBWR [1 DBWR thread] then checks the "slaves" to see if the I/O is done. Melissa Holman Oracle Support Will this produce the rate-limiting-factor in your system? I do not know. *Something* will be a rate limiting factor for a particular process. But as OLTP users' transactions vary so much from the batch processes, what exactly is the overall rate_limiting_factor is tough to say - your mileage will vary. My background is in Chemical Engineering. I spent some time in R & D wearing a white labcoat. Chemical Engineering - Process Debottlenecking - is all about "Where is the bottleneck?" Usually, a 15-20% margin is designed in such that the plant can run safely over its design spec without a retrofit of key components. Beyond that - you have to find what component needs to be increased to add capacity - safely. For your system - design in more capacity that you need, with room for expansion. Empty drive bays in external storage cabinets are good. The rebuilds of drive arrays are painful - but if you had a 7 bay drive cage (half a 14 bay - e.g. Storageworks 4200) with only a 4 drive array, hiking it up to a 6 drive RAID 0+1 (I'd rather duplex these) with a hot spare is tolerable. On an Ultra 160/m channel, 6 drives is reasonable. Here is a baseline - I/Os per second. A standard drive can accommodate 80-100 I/Os per second. Larger bufffers (cache) on the hard drive can increase that number, as can read-ahead caching algorithms on the RAID controllers. But if the reads are scattered, as in index reads and nested loops - the cache hits are not very likely. Lots of memory reduces the amount of read I/O required for a query. It does not reduce the amount of memory bandwidth required, nor does it completely reduce the overhead of creating consistent reads (reading rollback segs to provide cr blocks). This is a large part of the non-linear nature of scaling - interference of user processes creating additional overhead. When you say transactions per minute - these need to be translated out to actual logical and physical I/Os. Best bet here is to vary the number of sessions running in a scripted mode, and benchmark the I/Os required per transaction. So where would your bottleneck be? LGWR? DBWR? ARCH? Will your checkpoints really hurt with only a single DBWR? Will it be in the network I/O, Storage subsystem, memory bandwidth or just the capacity of the PCI bus channels? Definitely go for the 64-bit, 66 MHz RAID controllers, as many PCI bus channels and memory controllers as you can find. I can tell you this from experience: when the CPUs are I/O-bound, they do not appear as active in NT Task Manager. try this out: perform an export of a schema with datafiles, indexes, temp and the dump file all on one drive. then perform an export of the same schema with all of the above files on separate drives. I saw the average CPU utilization INCREASE from 20% to 80% average in performing this back on 7.3. Did the export utility crush the CPU? No. The I/O bottleneck (disc) was somewhat removed, and the CPU was free to perform useful work. The overall time of execution of the export dropped - but I don't have the scaling factors around. I've seen an NT box (Compaq Proliant 7000) run (4 CPUs, 26 hard drives, 7 I/O channels, 3.2 GB RAM) that averages a CPU utilization of around 85% under full load. But its executing user tasks much more quickly than a comperable dual CPU box. What this config tells you is - with sufficient available I/O - the CPUs will attempt to run at 100% utilization provided there are requests in the queue. You do have some flexib
RE: server sizing [NT: need XEON?]
Lerone, Based on an earlier mail, the following resources may be helpful: > I have been tasked with finding an NT server solution to handle 1600 > concurrent users. > (Please no laughing). Anybody got a clue/recommendations if there's any NT > solution that might handle this? (please non of the usual switch to Unix > comments) Have a look on ftp.oracle.com in /pub/www/otn/sizer for a tool - at 18-Apr-2001 doesn't seem to exist. This seems to now be located at http://partner.oracle.com/public/3size.htm but the site doesn't want to work for my browser. http://www.compaq.com/solutions/enterprise/database-oracle-sizer-download.ht ml http://www.dell.com/us/en/biz/topics/products_alls_pedge_wp-sizer.htm as of 19-Dec-2000 I found that you need to see the following instead http://support.dell.com/us/en/filelib/download/index.asp?fileid=R20794 - a word doc to download http://www2.clearlake.ibm.com/erp/oracle/sizings/sizer.html However, the IBM link seems to be very geared towards Oracle Applications users and from just using it, the Compaq tool is 3 years out of date. As for Very Large Memory (VLM) support under NT / Windows 2000 I have a copy of a document posted to this list (paper called "Oracle8i on Windows NT/2000: Architecture, Scalability, and Tuning April, 2000" that states a Xeon is required for VLM support (in addition to requiring NT Enterprise Edition under v4). However, 4GB RAM Tuning (4GT)is available using just Enterprise Edition and it will provide 3GB of memory to applications as opposed to 2GB - the MS Web site states that VLM and 4GT are incompatible. The Oracle documentation (817 Admin guide for Windows Ch 10) states that ESMA (VLM under NT 4) "is only available on Intel Pentium II and Pentium III Xeon 32-bit processors" and the Intel site (http://support.intel.com/support/performancetools/pse36/tti/softrequ.htm) seems to confirm that a Xeon is required. Where does this leave you - Buying a new Enterprise server will have Xeon processors - how many - NT 4 will support at least 4 (and we use 4) but some manufacturers offer NT servers with 8 & up to 32 on Win 2000 (eg Compaq at http://www.compaq.com/products/servers/platforms/) but how well that scales I don't know. You also have to take into account Oracle's license costs with multi processors. As for drives and RAID, you will probably find that the manufacturer you buy the server from will have their own branded RAID alternatives. Also whether you want your disks internal or external or a combination) will influence how many disks you can have and what sort of RAID. We use Dell servers and our main production server is a quad-processor with 3 internal disks (OS & Oracle) on a SCSI RAID card whilst we have 20 external disks (split into mirror pairs, hot spares and a couple of non RAID drives) that are controlled by 2 Fibre channel controllers. Then again we have a disaster recovery server with 10 disks all internal, on 2 RAID controllers, split into 5 mirror pairs. Budgetary constraints may influence what you will have to live with. You can of course also go with 3rd party RAID solutions (eg EMC) with NT just as you can with Unix. Hope this helps. Regards, Bruce -Original Message- Sent: Wednesday, 18 April 2001 9:56 Lerone, I stumbled across a skimpy, but perhaps interesting, "Capacity Planning" chapter in: _Oracle Forms Server Release 6i: Deploying Forms Applications to the Web with Oracle Forms Server for Windows and Unix_ http://docs.oracle.com/a84664/SHIPHOME/DOC/product_0/index.htm - http://docs.oracle.com/a84664/SHIPHOME/DOC/product_0/a73071.pdf (starting at http://docs.oracle.com, click: database | tools| MS Win NT | Oracle(r) Tools Version CD Pack v8...) They contrast scability for small and medium (no large) dbs on Intel vs. Sun (2 processors only!), and talk of things on the order of 500 NT users for "small" dbs, 300 NT users (max) for "medium" dbs. Of course since the document is about a year old, they are talking about a PII 2 processor Intel 200Mhz server as "small" and a PII 2 processor 400Mhz server as "medium"! Also, in the Oracle8i (Enterprise?) Install docs, they discuss support for RAM>4GB on NT (and Win2000) but this requires XEON, and special drivers. Unles I'm confusing that toic with some of the other mass of Oracle/NT stuff I've read lately, you can only run one Oracle instance with the oversized (>4gb) NT memory configuration on XEON. Sorry I'm not well enough versed in the nuances of RAID for large servers to say much (except get about the most high-end controllers you can afford). If you can get ahold of him, or can wait until he isn't so busy, Paul Drake of this list is the resident RAID/hardware expert. Other resources (sorry if you've already seen them): - http://www.geocities.com/tbcox23/generic_oracle_nt_config.pdf - http://www.geocities.com/tbcox23 - http://www.ultratech-llc.com/Personal/Files/ - http://www.ultratech-llc
RE: server sizing [NT: need XEON?]
Lerone, I stumbled across a skimpy, but perhaps interesting, "Capacity Planning" chapter in: _Oracle Forms Server Release 6i: Deploying Forms Applications to the Web with Oracle Forms Server for Windows and Unix_ http://docs.oracle.com/a84664/SHIPHOME/DOC/product_0/index.htm - http://docs.oracle.com/a84664/SHIPHOME/DOC/product_0/a73071.pdf (starting at http://docs.oracle.com, click: database | tools| MS Win NT | Oracle(r) Tools Version CD Pack v8...) They contrast scability for small and medium (no large) dbs on Intel vs. Sun (2 processors only!), and talk of things on the order of 500 NT users for "small" dbs, 300 NT users (max) for "medium" dbs. Of course since the document is about a year old, they are talking about a PII 2 processor Intel 200Mhz server as "small" and a PII 2 processor 400Mhz server as "medium"! Also, in the Oracle8i (Enterprise?) Install docs, they discuss support for RAM>4GB on NT (and Win2000) but this requires XEON, and special drivers. Unles I'm confusing that toic with some of the other mass of Oracle/NT stuff I've read lately, you can only run one Oracle instance with the oversized (>4gb) NT memory configuration on XEON. Sorry I'm not well enough versed in the nuances of RAID for large servers to say much (except get about the most high-end controllers you can afford). If you can get ahold of him, or can wait until he isn't so busy, Paul Drake of this list is the resident RAID/hardware expert. Other resources (sorry if you've already seen them): - http://www.geocities.com/tbcox23/generic_oracle_nt_config.pdf - http://www.geocities.com/tbcox23 - http://www.ultratech-llc.com/Personal/Files/ - http://www.ultratech-llc.com/Personal/Files/?File=RAID.TXT - http://www.ultratech-llc.com/Personal/Files/?File=ServerSpecs.TXT - http://www.ultratech-llc.com/KB/?File=Hardware.TXT regards, ep On 17 Apr 2001, at 12:11, Streeter, Lerone A LBX wrote: Date sent: Tue, 17 Apr 2001 12:11:22 -0800 To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> ... > 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. ... >>...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. ... -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Eric D. Pierce INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
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,
RE: server sizing
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 [EMAIL PROTECTED] === -Original Message- [mailto:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] === -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Streeter, Lerone A
RE: server sizing
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 [EMAIL PROTECTED] === -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Streeter, Lerone A LBX INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
