Operating System - HP-UX
1752822 Members
4516 Online
108789 Solutions
New Discussion юеВ

Moving DB from FC60 to CLARiiON FC4700

 
Lukas Grijander
Advisor

Moving DB from FC60 to CLARiiON FC4700

Hello all.

I've Oracle Applications (ERP) running in a two node cluster (N4000 DB Server and L2000 App. Server), all the data is stored in several FC60 LUNs.

We're planning to migrate this data to our new CLARiiON FC4700. In this migration, one of the goals is to distribute de DB objects to improve performance.

The people of EMC have told us to create several LUNs whith the following architecture (for the DB package):

- log : for redo-log and archive-log
- data : for all datafiles of data tablespaces
- idx : for all datafiles of indexes tablespaces
- other one : for tmp, rbs and system tablespaces
- soft : for the software and temporary directories.

What do you think about this?
Has anyone of you an environment like this?, is the solution similar?, are you happy ...?

All information will be wellcome ...

Thanks in advance.
4 REPLIES 4
Alexander M. Ermes
Honored Contributor

Re: Moving DB from FC60 to CLARiiON FC4700

Hi there.
Take a look at the Install and Upgrade guide for Oracle. Your idea is not bad at all.
Distribute the tablespace files, the online logs and the controlfiles thru the different disks, that they will not influence each others performance. Create three members in every logfile group on different LUN's, same with the controlfiles. Keep away the index tablespaces from the data tablespaces.
And try load balancing on the fc interfaces.
Rgds
Alexander M. Ermes
.. and all these memories are going to vanish like tears in the rain! final words from Rutger Hauer in "Blade Runner"
Sanjay_6
Honored Contributor

Re: Moving DB from FC60 to CLARiiON FC4700

Hi Rafael,

We have some configurations where we have distributed the oracle filesystems in this manner,

tables & cntrl ---seperate lun
index & cntrl--- seperate lun
temp & logs ---seperate lun
export & arch --seperate lun
systab & rbsegs --seperate lun
ora home ---seperate lun

splitting the db directories depend on how many luns/disks you have to play around with.

Hope this helps.

regds
Mike Hassell
Respected Contributor

Re: Moving DB from FC60 to CLARiiON FC4700

Rafael,

Your plan for distribution of your data seems solid, however you may wish to investigate further into striping the lvols across the seperate LUNs (one for each physical path to the EMC). Since the EMC is already mirrored by default there is no need to mirror it again with your LVM configuration, however striping across the multiple paths (assuming you have multiple physical paths) may increase your performance even more. Work closely with your EMC SE to gain a solid understanding of how your storage will be assigned to you, in our case we have 7.77GB "slices", which the OS assumes is a physical disk, however the actual disk are 50GB each in our EMC Symmetrix, taking into account the 8GB of cache also makes the picture more complex. It seems like you're moving in the right direction by segerating the data to gain performance, both from the aranagement of your database and the hardware upgrade. I'm sure some of the other forum members can shed even more light on this subject.

-Mike
The network is the computer, yeah I stole it from Sun, so what?
Lukas Grijander
Advisor

Re: Moving DB from FC60 to CLARiiON FC4700

Mike.

How do you distribute de data?

My real plan is :

I've 20 disk (50 GB each one) 2 of them for Hot Spare. These disk are grouped in 5 groups:

1.- 2 disks raid 1 for log
2.- 6 disks raid 0+1 for data
3.- 4 disks raid 0+1 for idx
4.- 4 disks raid 0+1 for tmp, rbs and system
5.- 2 disks raid 1 for software

really I've to put on all these disks two clusters (ERP - CRM) so the data group will be "broken" into 2 slices (LUNs) one for ERP (90 GB) and the other one for CRM (50 GB).My questions is : is pretty good to put all the data datafiles in only one LUN?

Do you you have a configuration like this? or your group disks are "broken" in more LUNs?

Sorry about "my english".

Thanks in advance.

Rafa.