Very Slow Conversion from Basic to Dynamic Disk in 64-bit Windows

[itsp1965]

Hi guys, I don't know if anyone has run into this, but we have a Windows 2003 64-bit server that is connected to SAN disk. Although we have no problem seeing the drives, they would all show as offline when in dynamic mode, so we had to revert to basic then back to dynamic in order to bring them online which took "forever". Once they were online we created a spanned volume made of the disks which also took an extremely long time to create.
I am somewhat concerned as to the integrity of this setup since I don't want to deploy a database on this storage and then experience issues
There are no errors showing in the event logs and no communication errors being displayed between the HBAs and the SAN disk
I have never had this issue on 32-bit Windows systems. Before I contact MS and/or the HBA vendor any thoughts? Thanks.

 

[mrdenny]

Why are you creating SAN volumes then spanning them together? I'd set them as basic disks, then create several database files one on each of the disk from the SAN.

Putting SQL Databases on Spanned disks is a very bad idea. If just one of those disks doesn't show up correctly then the spanned disk can be reported as bad and you'll loose the database.

If they are seperate disks, and one disk doesn't come up correctly the database will show up in suspect mode. You can stop SQL, get the disk to show correctly, then startup SQL, and flip the database into the correct mode. If this happens while the database is online it would be bad, if it happens before SQL Server starts then everything would be fine.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

My Blog

 

[itsp1965]

Thank you for the input mrdenny. Our customers servers connect to an IBM DS8300 Storage Array and when they request storage they can order in incremental LUNs in this case they requested 8x32GB LUNs -- thus the need to the span volume (the requested disks are part of a RAID-10 array)
Ended up discovering the issue was due to errors on a switch port which the SAN team ended up clearing.

 

[mrdenny]

I'm glad the error cleared up. It still seams like a bad idea to span the LUNs on the Windows side. Doesn't the IBM server have the ability to span the LUNs together on the storage side presenting the OS with a single LUN? (I'm used to EMC which calls this a MetaLUN.)

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

My Blog

 

[technome]

Agree with MrDenny...
Any program/hardware/provider requiring spanned disks via the OS has to be in question. The inept made those mistakes 15 years ago, out of ignorance. Spanned disk are inherently dangerous without redundancy, no less the Dynamic disk structure itself can be corrupted.. had to deal with it myself on a couple of inherited networks, it can be a nightmare.


........................................
Chernobyl disaster..a must see pictorial

http://www.kiddofspeed.com/default.htm

 

[itsp1965]

Thank you gentlemen for the input -- it's always nice to get a couple of opinions that you can learn from. I don't understand the reasoning for how the SAN team had it setup. On the old array they were carving out LUNs in 32GB increments and I would create a spanned volume based on this. Now when we are migrating users to our new array, the SAN team is allocating LUNs in increments of 128GB/256GB. I like mrdenny's concept of creating a MetaLUN since I am not a big fan of the spanned volume method myself.