This discussion is archived
3 Replies Latest reply: May 30, 2012 3:22 PM by Marc Fielding RSS

DBFS Size

Yoav Newbie
Currently Being Moderated
Hi,


When setting up the configuration, the best practice is to store the GoldenGate trail files and checkpoint files in DBFS to provide recoverability and failover capabilities in the event of a system failure.
I am planing to use DBFS only for this need , and dont want to waist storage space on DBFS .
On quarter rac machine , what is the minium size of the DBFS that i can configure when installing the machine.

Thanks
Yoav
  • 1. Re: DBFS Size
    Marc Fielding Journeyer
    Currently Being Moderated
    Hello Yoav,

    To help frame your question, here's a bit of background on the DBFS diskgroup: each storage server has 12 disk drives. To host the operating system itself, non-ASM disk space is required. This disk space is in a series of partitions totaling 30GB or so in size, on the first two drives (mirrored for redundancy). Let's call these the OS drives. But what about the remaining 10 disk drives? We have a few choices:

    1. Simply make the ASM volumes larger on the remaining 10 disks. This option gives the most usable space, but means that your ASM data volumes have less data on OS disks than the remaining disks. And since they have less data, the OS disks could be expected to have less I/O volume as well, creasing a less "balanced" I/O layout and reducing total I/O throughput.
    2. Make the ASM data volumes the same size on all disks, avoiding the performance penalty, but losing 30GB of storage capacity on non-OS drives.
    3. Do as option #2, but instead of leaving the unused space empty, create a completely separate ASM diskgroup whose performance characteristics are independent from the data volumes, and put a DBFS instance on top of it. This is the approach Oracle chose for new Exadata builds.

    Is there a minimum size for the DBFS volume? No, you could just go with option #1 (with a few other adjustments for voting disks and a few other small users of the DBFS diskgroup) and have no DBFS instance at all

    But keep in mind that, this 30G of storage space over 10 disks represents less than 5% of total storage capacity in 600GB high performance disks, and less than 1% of total capacity with 3TB high capacity disks. So you'll have to consider if it's worth the effort of reorganizing diskgroups, the risks of being different than most other Exadata deployments, and the performance impacts to gain this additional storage.

    Hope this helps!

    Marc
  • 2. Re: DBFS Size
    Yoav Newbie
    Currently Being Moderated
    Hi Mark,
    Thank you for your detailed answer.

    Mike Wrote :
     
    3. Do as option #2, but instead of leaving the unused space empty, create a completely separate ASM diskgroup whose performance characteristics are independent from the data volumes, and put a DBFS instance on top of it. This is the approach Oracle chose for new Exadata builds. 
    --> This sound as a good option , BUT :
     
    But keep in mind that, this 30G of storage space over 10 disks represents less than 5% of total storage capacity in 600GB high performance disks 
    Actualy , i think its about 10% and not 5% , and basically i am losing 600 GB when only 1 (one) GB is needed for golden gate pump files , which seems to me as a huge waist of space in a quarter rac machine

    Thanks
  • 3. Re: DBFS Size
    Marc Fielding Journeyer
    Currently Being Moderated
    Hi Yoav,

    Not sure I follow your math; 30GB * 10 = 300GB per storage server. With high-performance disks, you have total raw capacity of 600GB * 12 = 7200GB per storage server so a bit under 5% of total storage allocated to DBFS.

    Marc

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points