ORACLE 9i needs mount pints on VA7410

[Johnny Kwok]

During a meeting with DBA, he asked for DB space 8 G with separate mount point A (4 G) for Data and mount point B (4 G)Index for performance reasons (ORACLE suggested separating Index/Data to reduce disk access conflicts).

However, since we are talking about VA7410 here, isn't LUN is not a physical disk anymore ? if we allocate a mount point /oracle with 8G and create sub directory /oracle/data and /oracle/index,it would scatter around the VA anyway and would achieve the same objective of reducing disk access to the same spot?

Or it makes sense to create 2 separate 4G mount points (LUNs) on the VA7410 as suggested by DBA ?

Thanks!

[doug mielke]

good luck dispelling that notion with the dba.


It's true that the selection of mount points are not nearly important now as in the past. However, there are many caveats.

If you have more than one HBA in the server, it's possible ( but certainly not required) to split the load between the two paths. There is also great debate on how your luns and filesystems should be configured regarding size, block size and more.

With 8 gig being such a small piece of a typical SAN, I'd describe his request as without merit.

[Alzhy · Accepted solution]

Cut an SLA with your DBA team... if the filesystems that you provide them do not provide the necessary "throughput" -- then that's the only time you should be mandated to demonstrate how you carve your filesystems... Most DBA's still think the old-way... dealing and thing with physical disks -- and still demanding that RAID5 be avoided ANYWHERE at all costs! We are/have been using RAID5 LUN's from our Hitachi Frames that we stripe(RAID0) or RAID5 further (for added protection) and using them outright to build filesystems... In very large DSS/DW configurations.. I present a separate RAID5 LUN or RAID10/01 LUN on each separate channel for REDO logs and for "hot" filesystems...

Using VxVM I can move volume objects non-disruptively...

BTW, if your server is not serving multiple ORACLE instances -- then its is perfectly okay to mix DATA and indexes (data and index are not simultaneously read) .. just be mindful to continously monitor performance of each volume/filesystem and be prepared to relocate certain objects that become "hot"...

We are even experimenting with a 500GB DB that is housed in just one single super-striped volume (an 8-column on 8 HBA system...) we did however separate the redo logs... our DBA's are happy and have no issues (yet...) performance is at par or even better than having DB files on separate filesystems and volumes...