Oracle OFA and SAN layout

[Henrique Silva_3]

Hi everyone.

With 2 fibre channels on the SAN, and two application table spaces that I need to separate, and about 40 GB to do it, which table spaces related to Oracle that should be separated on the channels and how about redo log files ?

Some table spaces like USER, TOOLS, TMP are hardly used, so how do which ones go to channel a and channel b regarding system, index and rbs and on the app side, one table space is hit more often then the other, so, I am assuming that system and rbs plus lightly hit table space go on channel a and indx and hard hit app table space on channel b ? and mix the other ones up among the channels.

I am reading teh SAME paper and the OFA paper, just to make sure that I am not missing anything here.

Any help will be appreciated.

Tahnks,

Henrique

[harry d brown jr]

Interesting, because I don't think I'd be worrying about a 40GB database. Use both channels for everything, use striping, and alternate path'ing for failover.

What is the vendor's name of the SAN, they should have guided you on this!??!?!

live free or die
harry

[Henrique Silva_3]

This is an HP internal app, using XP 512.

We are using MCSG for the HA piece and bcv for backup purposes and to cut a copy of the DB for the reporting box.

I am not too concerned about the layout, but since I have never done a layout on a SAN, and I only have two channels to play with, I would like to hear from people out there how they have done it and what have they seen and learned ?

This app will be a WW app, so, it will be hit faily often 24/7. 40 GB is the space we have available right now for each piece. We think the growth rate will be about 4 to 5 GB per day, once we migrate all users in about 6 months or so. At that time, we would have cleared up another 300 GB of SAN space that can be used here.

So, as you see, this up will have storage and volume increased considerably in a few months, so, I would like to get it right to begin with and extend the DB as we need to.

Thanks,

Henrique Silva

[Ashwani Kashyap]

It would be quite a task manually balancing load across the channels .

Since you are already on SAN why don't you use HP's auto path or EMC's Power path ( On Ssymmetrix units only ) to balance your load across channels.

[Henrique Silva_3]

I am not wooried about load balancing manually.

All I want to know is how to go about layout out the file systems on this scenario.

2 fibre channels,
40 to 60 GB to start with but will grow to more than 400 G in about 6 months.

should I use SAME ?

We are thinkning about using Veritas so that we can do dynamic striping later.

thanks,

Henrique Silva

[Henrique Silva_3]

OK, one more question here. This SAN thing is really confusing me :-)))

In this scenario, two channels, data spread amongst several disks on the SAN.

My app has two big table spaces in relation to all others. The data and index table sapce for the app.

now, I have created several file systems on this data access path, so that we can have a OFA feel here, however, I am strugling with something. On the old days of disks and controllers, you would try to balance the load of the table spaces by creating several datafiles for a particular table space.
What should I do here ?
I need a 20 GB and a 10 GB table space. Should I create several datafiles on different file systems taht accesses the same data access path ? OR should I create one big datafile for the table spaces ? Even on a SAN, does it make sense to spread the data around, eventhough it is accessing the SAME data access path ?

Thanks,

Henrique Silva

[Ashwani Kashyap]

I don't know what kind of backend storage array you have , but one good thing about SANs particularly if you have an EMC storage array at the backend is that you don't have to worry much about your lay out .

If you have sufficient amount of cache in your storage array , most read/write operations will be done from the cache rather that from the disk . Cache operations are extremely fast . All disk striping , availibility and load balancing is done at the storage end and the OS doesn't have to worry much about it .

If you are still particular , then you can create PV links across both the channels alternately changing the primary links for most used and least used PV's .

Talk to your storage administrator about it .
As wrote earlier , autopath or power path can be very useful here in case you don't want PV links.

[Henrique Silva_3]

HP XP 512.

The question still remains.

Given nothing is changed, as far as the setup goes, if I setup a table space with one 20 GB datafile on this File system that is mirrored and striped across both channels and multiple disks, does it even make sense to break this table space among 4 or more datafiles across different file systems that are accessing the same HW path as the 20 GB is ?

This might be semantics, but I believe the disk cache here on the XP is 64 GB, and so, I do not see much advantage on breaking the datafile into parts, unless we can take advantage of parallel access to the data, although this data is "kind" of sequential ( almost like a heap table but not quite like it ).

Still strugling with the old way of placing datafiles and table spaces and the new way on SAN using SAME !!!

Thanks,

Henrique Silva

[Ashwani Kashyap]

Henrique ,

YOu just answered your own question . Since the file system is already mirrored and striped across both channels on multiple disks , you won't achieve anything in breaking the table space into multiple data files .

I have a same setup with an EMC SAN , and 600 GB of a database . And I have done the same thing with no performance issues .

[Henrique Silva_3]

Thanks everyone.

It is just a different way of thinking here. Kind of hard to let go the old LEARNED ways !!!

Cheers,

Henrique Silva