6 Replies Latest reply: Feb 4, 2013 10:27 PM by Justin_Mungal RSS

    OFA confuses me - why 3 mount points for datafiles?

    piotrtal
      Hi,

      i encoutered lately on such statement:

      Table D-7 shows a hierarchical file mapping of a sample OFA-compliant installation with two Oracle home directories and two databases. The database files are distributed across three mount points, /u02, /u03, and /u04.



      from http://docs.oracle.com/html/B10811_05/app_ofa.htm

      my question is:
      why three mount points (/u02, /u03, and /u04) for datafiles? don' understant this.
      isn't it better to store all datafiles in one mountpoint?
        • 1. Re: OFA confuses me - why 3 mount points for datafiles?
          Justin_Mungal
          Although separate mount points don't necessarily mean they are mounted on different arrays or drives, that is what the examples are implying. Systems are often configured that way for a number of reasons such as performance or recovery (ie. multiplexing your redo logs, or placing the data files for certain tablespaces on their own arrays or drives). The documentation is illustrating how to be OFA compliant in that scenario.
          • 2. Re: OFA confuses me - why 3 mount points for datafiles?
            marksmithusa
            This predates ASM, I'm guessing, where Oracle manage the stripeing of the disks appropriately (at least, in theory). To be fair, it does seem like to works as advertised.

            I think that the three mount points were meant to be on separate filesystems/disks. The first was for system data (SYSTEM, SYSAUX, UNDO, etc), the second for application data and the third for application indexes. That way, you won't be competing with I/O on the same disk when you insert into a table, etc.

            Of course, you might find it necessary to further separate tablespaces onto separate disks if you have a logical need to do so.

            That's always what I've done, anyway. If you're bothered about performance, I would definitely separate filesystems onto different volumes. On test/dev, I wouldn't care too much.

            I know that you can further refine ASM to move the heaviest hit data on the fastest disks and the least hit data on the slower ones. But not sure how to do that myself.
            • 3. Re: OFA confuses me - why 3 mount points for datafiles?
              marksmithusa
              And, of course, this would allow you to put each member (3 per group) of each redo log group onto a different volume as well. I would put archive logs on another volumes as well.
              • 4. Re: OFA confuses me - why 3 mount points for datafiles?
                Justin_Mungal
                I know that you can further refine ASM to move the heaviest hit data on the fastest disks and the least hit data on the slower ones. But not sure how to do that myself.
                The only way I know to do that would be to place the heaviest hit data files on their own diskgroup. ASM automatically stripes the ASM files across the disks of a diskgroup (based on the size of the ASM disks) to eliminate hot spots, but it is in no way aware of which ASM disks within a diskgroup are the fastest. This is why the standard practice is to create diskgroups comprising of disks that are uniformly sized and have the same performance capabilities.
                • 5. Re: OFA confuses me - why 3 mount points for datafiles?
                  marksmithusa
                  Yeah, that's my understanding as well. I just remember Oracle making a big deal about data layout when releasing a product and extolling its virtues. I'm thinking it might have been 11gR1 but I haven't heard anything about it since, so really not sure. It was a cost option, naturally...
                  • 6. Re: OFA confuses me - why 3 mount points for datafiles?
                    Justin_Mungal
                    I know that you can further refine ASM to move the heaviest hit data on the fastest disks and the least hit data on the slower ones. But not sure how to do that myself.
                    I'm reading the storage admin guide; Intelligent Data Placement seems to be the closest thing to that. Unfortunately, it is more useful in JBOD than anything else.

                    http://docs.oracle.com/cd/E11882_01/server.112/e18951/asmdiskgrps.htm#CHDICBEB

                    -Justin