Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Splitting and shrink a Windows Volume without Cluster's downtime? Expand / Collapse
Author
Message
Posted Tuesday, July 23, 2013 11:40 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, September 18, 2014 11:15 AM
Points: 384, Visits: 1,270
Ok.

Got a quick question, maybe for Perry or whoever can clarify.

Got a SQL 2012 failover instance running on Windows 2008 R2 with a volume that I need to split in two. Let's call it E:\tempdb. The reason why I want to do that, is because that particular LUN (Disk on Windows management) runs on the fastest tier on the SAN. We are running out of SAN's disks and Tier1 space and tempdb size is way to big for current workload.

So let's say E:\tempdb is 100GB, this is what I would like to do while the Cluster is online:

-Shrink the volume from 100GB to 20GB
-Format the new 80GB available space and create a volume from it
-Mount that new volume to root volume , new folder.

Once finished, I should have something like this:

E:\tempdb but now 20GB of size
E:\SQLData3 with 80GB available space

I do believe this does not requires downtime and I actually tested it on VMware, but wanted to confirm. I also believe this may take a bit on a real environment (the shrink part) depending of how much available space we have and SAN capabilities?

Also, as a secondary or follow up question. Can I join two unformatted partitions from two different Windows disks, let's say 100GB from disk 2 and 100GB from disk 3, and make a single volume from it? Got a barely used Volume on my Cluster that I would like to destroy and later join to my existing Data LUN in order to expand our Data drive or main LUN. They both reside on different LUNs / Disks.
Post #1476728
Posted Thursday, July 25, 2013 2:39 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 1:56 PM
Points: 6,365, Visits: 13,695
shrinking is not as easy as extending a volume, from what i have read it seems that you want to convert to using mounted volumes is that correct?

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs"
Post #1477396
Posted Thursday, July 25, 2013 8:27 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, September 18, 2014 11:15 AM
Points: 384, Visits: 1,270
Perry Whittle (7/25/2013)
shrinking is not as easy as extending a volume, from what i have read it seems that you want to convert to using mounted volumes is that correct?


Hi Perry,

Thanks for reply.

No, I do not want to convert to using mounted volumes (I am already) I want to shrink an existing LUN that holds tempdb and I want to do it on the fly, without taking the SQL failover instance down. If this is possible, I want to format the new unallocated space that will be at right position and create a new mounted volume with it.

Like I said, that volumen is running on a tier1 pool at SAN level. We do have the immediate request of moving a database to that tier1 space and this is the only available LUN at this moment.

For monitoring reasons, I want to divide that LUN and leave tempdb files on its own so my alert systems will be filtered correctly by mount point letter or volume. I understand the performance and I/O workload will be the same as it is actually the same pool or volume at SAN level.

Is that possible? Also, how critical this may be for tempdb on a Cluster that holds hundred of databases? On a live server the shrink process may take longer I guess or maybe crash the system?
Post #1477524
Posted Friday, July 26, 2013 6:43 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 1:56 PM
Points: 6,365, Visits: 13,695
sql-lover (7/25/2013)
I want to shrink an existing LUN that holds tempdb and I want to do it on the fly, without taking the SQL failover instance down.

Not going to possible, the volume can be extended on the fly but not shrunk. There is no diskpart command to shrink a volume.

You could either get a new LUN attached and mounted under the root drive and then move the files to the new drive or you could have the current LUN mirrored to a new LUN which you then attach to the server and then move the db files. You'll need to stop and restart the instance so do this within a maintenance window.


-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs"
Post #1477972
Posted Monday, July 29, 2013 7:23 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, September 18, 2014 11:15 AM
Points: 384, Visits: 1,270
Perry Whittle (7/26/2013)
sql-lover (7/25/2013)
I want to shrink an existing LUN that holds tempdb and I want to do it on the fly, without taking the SQL failover instance down.

Not going to possible, the volume can be extended on the fly but not shrunk. There is no diskpart command to shrink a volume.

You could either get a new LUN attached and mounted under the root drive and then move the files to the new drive or you could have the current LUN mirrored to a new LUN which you then attach to the server and then move the db files. You'll need to stop and restart the instance so do this within a maintenance window.


Hmmm...

Maybe I did not explain myself properly?

I actually did additional test on my lab and I was able to. I also found Microsoft documentation confirming it is possible.

I am not talking about shrinking the LUN's size, but shrinking the partition or volume's size inside that LUN, moving it to the left, if I can use that expression. Once done, unassigned or unpartitioned space will be on the right, based on the shrink value that it was previous selected.

I will probably will have to do it on the real Cluster during downtime window and I will confirm.
Post #1478579
Posted Monday, July 29, 2013 8:29 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 1:56 PM
Points: 6,365, Visits: 13,695
Even using a partitioning tool on an online cluster volume, i'm not sure this would be a wise thing to do, i assume this is what you are using.

IMHO, It's far easier and less work to create 2 new LUNs present them and set them up and move the datafiles as required.


-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs"
Post #1478614
Posted Monday, July 29, 2013 8:48 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, September 18, 2014 11:15 AM
Points: 384, Visits: 1,270
Perry Whittle (7/29/2013)
Even using a partitioning tool on an online cluster volume, i'm not sure this would be a wise thing to do, i assume this is what you are using.

IMHO, It's far easier and less work to create 2 new LUNs present them and set them up and move the datafiles as required.


True.

But the problem is that there is no additional space or disks on the SAN. That's the whole point of doing this, re-use the existing LUN and divide it in two. If we have space, we would not be worrying about re-purposing that existing LUN.

Doing it offline it's actually easy, as that LUN only contains tempdb files, but we need the whole downtime window for the migration project. If I had enough time, it's just destroying the LUN (after taking SQL off and probably removing the disk resource from the SQL failover package) and create two new volumes inside.

What I am using is Disk Management tooL, from Windows. It is pretty simple. Right click, shrink, and select the new size or value. It can be done with diskpart as well but it is easier with the GUI.
Post #1478628
Posted Tuesday, July 30, 2013 6:56 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 1:56 PM
Points: 6,365, Visits: 13,695
Yes, my bad you are quite right shrink is available.
Even so, I'm you can manage to scrape up the extra 80GB or so required to pre create the new LUNs, but hey if your option works, then fine


-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs"
Post #1478974
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse