is the list smart enough to block my posts made after 2 am? Pd
--- Paul Drake <[EMAIL PROTECTED]> wrote: > --- [EMAIL PROTECTED] wrote: > > Hi everyone! > > > > Can anybody point me to any good documentation > > regarding disk capacity > > planning? Sharing your experience or approach will > > also give me so much > > help. I'd like to know other people's approach on > > forecasting the growth > > of their databases particularly on determining the > > (growth) rate of disk > > space usage and on deciding when to add and how > many > > disk to add on an > > Oracle server. > > > > Thanks in advance. > > > > Best Regards, > > Rhojel > > Hi Rhojel, > > http://www.baarf.com > > not organized, just a brain dump. > > use a UPS and configure it to properly shutdown the > instance should it be running out of power. > > use battery backed-up cache (NVRAM) on your > host-based > RAID controllers. replace or recharge the battery as > perscribed in the manual (or you'll be testing media > recovery in an unscheduled fashion). > > enable write-back caching on your host-based RAID > controller (if you have satisfied the above > conditions). > > Base the number of disks on the number of IOPS > (independent operations per second) the storage > subsystem must handle in steady state, and in peak > usage, and on the response time that exists in the > service level agreement with your users. > > It will be very likely that you will not be > constrained on space, but on controller channels and > physical hard drives (e.g. having 24 x 36 GB hard > drives, but only having an 18 GB database - I am not > kidding). > > Spread the disks out across controllers and > controller > channels such that controller bandwidth is not the > limiting factor. Spread controllers across PCI-X bus > channels. > > use dedicated drives for online redo logs. > > At least have 2 redo log members per group on > separate > controllers. Provided that one member per group is > still accessible, you can take a hit in terms of > losing a volume and your instance(s) will still be > up. > > Don't use more than 50% of the space of your RAID > volumes for live files. Don't even create > filesystems > for live files on the remaining 50%, or use them for > staging backup sets or for trial recoveries. This > will > keep your mean seek time down, reducing latency. > better yet, don't format them at all. Beware of > Network Admins chanting "iSCSI" that want to store > their files on your unused space. If need be, create > bogus tablespaces with say 1 GB datafiles to > "consume" > the excess space. drop them. when its time to add a > datafile, re-use the bogus datafiles. in the > meantime, > the storage reports from the OS won't turn up loads > of > free space. > If your SysAdmins are crafty and will see through > this > ploy, create raw volumes on the unused space and > label > them in a very cryptic fashion, or say that they are > for when you are going to partition the large fact > tables. > > use dedicated drives for your archived redo logs. > > use a stripe size that is a multiple of your > operating > system max IO size. set your db file multiblock read > count accordingly. don't set it too high, as the CBO > will think its time to chow down and grab blocks by > the 32 pack instead of using that index that the > developer intended. > > have space for cloned databases for testing new > application updates, new oracle server software > releases, on disk backup sets, uncompressed archived > redo logs since your last full backup, logical > dumps, > copies of binaries and patch sets. All of these can > help reduce mean time to recovery in the event that > you need to perform media recovery or re-install the > database server software. > > if you intend to use dbms_flashback or select AS OF > ... use dedicated drives for your UNDO tablespace. > > use tape for getting backup sets offsite. > recover from local storage. > > use dedicated drives for your TEMPORARY tablespace's > temp files, unless you have so much memory that you > don't sort to disk. Remember that global temporary > tables and hash joins can write out to TEMP also. > > segregate files on RAID volumes based upon access > methods. If you want an agressive read-ahead > algorithm > to be used for full table scans, don't store index > data files there that are only accessed a block at a > time. > > stripe and mirror everything if you can. > even numbers are best, multiples of 2 work well with > Oracle block sizes (4 or 8 disk RAID 10 volume). > > by now, 24 drives looks about halfway there, doesn't > it? > > My point is, that if you have enough drives to keep > your CPUs well fed, you likely won't have any space > concerns. > > it is customary to include your server OS and Oracle > version. as this is a storage question, you might > want > to include the storage system manufacturer if you > are > not going with direct attached storage. > > Based upon someone's posting about his monday > morning > having 20 database instances crashed due to a > sysadmin > pulling a cable, use redundant data paths if > possible. > If you are connecting via Fibrechannel to a SAN, > specify dual Fibrechannel switches and use multiple > FC > HBAs, not just 2 ports off of a dual ported card. > > > or you could just order 3 x 146 GB drives and set > them > up as RAID 5. use a stripe size of say 32 KB. That > works for most people that specify file servers, > mail > servers, web servers, etc. > except for '/boot' and <swap>, store everything > under > '/'. no worries. > > Pd __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Paul Drake 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).
