Good point, Stephen. The buzzword is "consolidation" - bean counters love it - product managers hate it, since it increases chances of failure in one app when something happens in the other. Let them fight it out. ;)
I also ask another question to the product manager (or account manager, or departmental head, whoever is the head honcho of that user group) - what is their SLA requirements for uptime. If the uptime requirements are quite high, I introduce that caveat of consolidation and increased risk into the SLA. If they don't like it, well it's their decision (and budget). Even if you have a one application = one database startegy, large disks may still be useful for other tasks. Sor instance, in a 1.2 TB database on a Sun 15K server and Hitachi 9800 Series SAN, I have four groups of disks (72 GB each) allocated for redo log groups. edo logs constitute only 2 GB each, the additonal space is used for other non-essential tasks like an occasional export, the tools directory, etc. HTH. Arup Nanda ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Wednesday, February 19, 2003 12:28 PM > I have a different way of justifying it. It seems that everyone still > assumes the one application = one database mentality. I have chosen to > implement a different strategy. Multiple applications = one database. I > see no reason to use the "file server" approach anymore. The issues with > downtime, etc. outages are easily managed and performance is not squandered > if the equipment is properly configured. > > So, your tact could be that larger disks can be used by multiple > applications in a single database for better and more efficient utilization > of resources. > > Thank You > > Stephen P. Karniotis > Product Architect > Compuware Corporation > Direct: (248) 865-4350 > Mobile: (248) 408-2918 > Email: [EMAIL PROTECTED] > Web: www.compuware.com > > -----Original Message----- > Sent: Wednesday, February 19, 2003 9:49 AM > To: Multiple recipients of list ORACLE-L > Subject: RE: > > > I'm curious as to how others with smaller databases deal with it as well.. > > > You can't even buy under 18GB hard disks for some brands of servers > anymore.. > My production databases are all relatively small i.e. 5 GB - 7 GB, but yet > I'd still want several independent physical disks to spread the I/O load... > > On test servers, the 'extra' space is easy to justify because you often > create several instances > for different purposes... But on your production box it can seem a bit > excessive. > > I justify it in part by pointing to the increased flexibility afforded.. > e.g. you could do cold backups to disk in minutes and then copy the backed > up > files to tape after the database is restarted. > > > Wayne Straughn > > > -----Original Message----- > Sent: Tuesday, February 18, 2003 7:24 PM > To: Multiple recipients of list ORACLE-L > > > Hi, > > I was wondering how DBAs are coping with these new large disks that are > available....you can purchase 36gb, 72gb, etc. You can fit a whole database > on one of these. But with all the performance and redundancy > considerations, you wouldn't....so what do you do with the free space? Or > how do you tell your bean counter that out of that 72gb you are only going > to use 10gb so you need a couple of these? > > Rgds, Ken Heng > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Ken Heng > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > 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.net > -- > Author: Wayne Straughn > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > 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). > > > > The contents of this e-mail are intended for the named addressee only. It > contains information that may be confidential. Unless you are the named > addressee or an authorized designee, you may not copy or use it, or disclose > it to anyone else. If you received it in error please notify us immediately > and then destroy it. > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Karniotis, Stephen > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > 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.net -- Author: Arup Nanda INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
