This content has been marked as final. Show 6 replies
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.
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.
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.
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.
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...
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.