| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE:
I agree that SLAs can create a different scenario. However, in my
experience in configuring these types of environments, doing this properly
virtually eliminates the issues mentioned with SLAs. It's in the pudding
folks.
Thank You
Stephen P. Karniotis
Product Architect
Compuware Corporation
Direct: (248) 865-4350 Mobile: (248) 408-2918 Email: Stephen.Karniotis_at_Compuware.com Web: www.compuware.com -----Original Message----- Sent: Wednesday, February 19, 2003 2:04 PM To: Multiple recipients of list ORACLE-L Subject: Re:
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
> 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: Stephen.Karniotis_at_Compuware.com
> 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: kheng_at_au1.ibm.com
>
> 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: 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.net
> --
> Author: Wayne Straughn
> INET: Wayne.Straughn_at_blpc.com.bb
>
> 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: 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).
>
>
>
> 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: Stephen_Karniotis_at_compuware.com
>
> 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: 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.net -- Author: Arup Nanda INET: orarup_at_hotmail.com 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: 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). 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: Stephen_Karniotis_at_compuware.com 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: 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 Wed Feb 19 2003 - 22:08:47 CST
 |
 |