Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

When we setup FC LUNs for our MSSQL boxes we rarely have to present them with more than about 8 distinct LUNs of various kinds (Quorum, MSDTC, TempDB, Data, Logs, Backup and a few others).

We have a new Oracle DBA, and he's given me a list of LUNs he wants for his first new server - there's 38 of them! and this is for a really basic DB box, with only a single DB. They're all fairly small (100GB) LUNs and they clearly bolt together using ASM in an LVM-type way.

Is the the best way to do this, I'm really no Oracle expert but it seems overcomplex to me, what's your thoughts and experiences on this matter?

Thanks in advance.

share|improve this question
1  
38 LUNs for a single DB ... what?!?! –  Zypher Jan 7 '10 at 15:33
4  
    
Thank you DW, great piece! –  Chopper3 Mar 27 '10 at 10:46

5 Answers 5

up vote 18 down vote accepted

I am an Oracle DBA. Your new DBA is acting like alot of Oracle DBAs and over engineering.

  1. NO oracle does NOT need 38 LUNs. I have spread data files out on large numbers of lun's but these are on systems that are VERY active and VERY large. LUNs don't necessary map to new RAID groups right? So having files on seperate luns don't necessary spread anything out anyway (I am not an expert at this).

  2. All this kind of file striping will do is make far more work for the DBA. This increases his importance to the team. Alot of Oracle DBAs try to make themselves seem more important and over engineer things ALL THE TIME.

  3. Seperating data out to differnet raid groups/luns is not oracle specific. Its based on usage. In order to properly spread out files your DBA would need to understand the application to know what is being accessed alot (btw, seperating indexes from data does NOT improve performance since access is serial... ). Does he know the application? Has he looked at the database to see what objects are being accessed alot? What needs to be spread out? What does bulk writes and reads and needs to be isolated.

This sounds like a small/medium size database. What is the activity level? He probably doesn't know.

Generally on smaller databases you don't need to do much at the file system level to improve performance. 95% is SQL and do the developers run too many sql statements in loops.

edit (years later!):

I have been spending some time talking to SAN engineers and have improved my knowledge of SANs and LUNs somewhat since posting this. First off a LUN is 'logical'. It does not necessary map to separate RAID groups, disks, etc... That is setup by the SAN engineer and will not be visible to the DBA. There is alot more to separating out IO in a SAN that most people realize.

I am working on a very large systems that has a very high activity level. We have hundreds of LUNs, RAID Groups, etc... we spread files all over the place. We work with the SAN engineers to configure LUNs to make sure they are spread to different parts of the SAN. We really have NO visibility into how the LUNs are mapped from the OS level. A new file system does not mean we have data mapped to a new location on the SAN.

As far as the HP paper about striping ASM. This is totally meaningless when working with a SAN. The striping,mirroring, RAID, etc... is all done under the surface. You will not see it at the application or database level. Configuring Oracle ASM for 'striping' is agian meaningless in a SAN, because you will just be striping across logical volumes that could be using a RAID 5 configuration (vast majority due to control costs. SANs are multi-million dollar investments). You will just see file systems. Those do not necessarily map to different disks or different locations in the SAN.

IBM apparently has a new feature that lets the SAN decide where to write to disks based on activity. My point here is that people who optimize SANs are specialists. You need to work with them. A DBA or an application developer will not have visibility to see whether anything is being spread out.

From what I have seen most shops do not have very good SAN engineers. It tends to be a job for junior level people. Most of the good ones tend to be consultants. So alot of the time you are just using the default setup by the manufacturer. To reiterate adding more LUNs probably won't spread any data out, unless you have a SAN engineer configure it for you under the surface. On top of that, you can have 1 LUN and have it spread out for you. Unless you have a good SAN engineer, all this stuff is meaningless. It is obvious to me that the DBA in question does not know enough about SANs to even know he doesn't know anything.

99.9% of the time standard configurations are just fine. Unless you have a specific IO bottleneck this is unnecessary. If you do, then you need to work with the SA and SAN engineer to determine what the problem is. Alot of the time it has NOTHING to do with the layout of the SAN. Again, DBAs and developers won't have access to see what is going on underneath let alone the knowledge to figure this out. SANs are very complex.

share|improve this answer
    
Excellent reply, thank you very much indeed. –  Chopper3 Jan 7 '10 at 19:36
    
With all respect, just few points of attention :- 1. "SAN is complex" - So do Oracle database is. Even one of the most highly priced product in any IT infrastructure or IT system. 2. "Striping/spreading/ect " - Agreed. DBAs do not need to know what's going on underneath as long they never face issues with I/O - but unfortunately it's always IO bottleneck for any performance related issues. 3. Again DBAs differ - Infra/Core DBA vs Application DBA. Infra DBA is tasked with activities related to DB working with OS & disks(SAN) - so he must have good knowledge of what's going on. 4. All the above –  Lodh Nov 1 '13 at 17:37

You can try to whack him over the head with THIS, describing the SAME (Stripe And Mirror Everything) approach, which is refreshingly simple.

share|improve this answer
1  
I think that's what he's trying to do - not realising that our array is an already nasty beast with RAID10. –  Chopper3 Jan 7 '10 at 16:56

There are studies that show that striping in ASM and at the hardware level can be an advantage for performance. HP-Oracle whitepaper These performance gains are mostly seen in high concurrency situations which it doesn't sound like you are expecting. But might be what your DBA is used to.

share|improve this answer
    
Actually this will be HIGHLY concurrent, just a simple DB - so thanks. –  Chopper3 Jan 12 '10 at 19:15

I know that for DB2 on AIX, our DBAs get 5 volumes per database - each one for a different part of the DB. One for the DB, one for the primary log, one for the archive log, a temp, and something else. Those are volumes, they don't have to be LUNs, it depends on how you like to manage your storage.

share|improve this answer
    
More details needed - does he want 38 LUNs for one DB, or 38 LUNs for one DB PLUS the build of the new server? Is it Oracle on Windows, or Linux/Unix? Linux/Unix admins tend to want more smaller partitions just for the OS, before you even get into apps and DBs - /usr, /var, swap, /etc, and so on. I think you need to have a detailed discussion with him, and you both may need to do more research. He might need a lot of unshared disks for IO reasons, for example. –  mfinni Jan 7 '10 at 17:39

I don't have a direct answer because we use MSSQL and mySQL. But whenever my DBA asks for something that just sounds crazy ... like that. I require him to document why each piece is required. This serves two purposes one a lot of times they suddenly change their mind to something more sane and two allows me to see their thought process so i can apply some systems logic to what they want and present a alternative that isn't so out of whack. SO in this case I would ask for a document justifying the need for each of the 38 LUNs

share|improve this answer
    
Thanks for the response, I have asked for this but he's not responded yet, thought I'd check with you good folks first ;) –  Chopper3 Jan 7 '10 at 15:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.