is the list smart enough to block my posts made after
2 am?
Pd
- Paul Drake <discgolfdba_at_yahoo.com> wrote:
> --- Rhojel_Echano_at_sgs.com 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: discgolfdba_at_yahoo.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 Tue Jan 13 2004 - 10:04:25 CST
