July 16, 2010 at 2:32 am
Hi,
Im running a DBCC SHRINKFILE EMPTYFILE COMMAND against a 1.7TB database to split it across multiple files. AVG Disk Que length is 1, PLE is 450 and its writting at 20-40MB per second. Any ideas where i could start to try and speed up this process as its gonna take like 5 days at the current speed.....
Thanks
Sorry for re-posting but i put this in completely the wrong section before.
July 19, 2010 at 1:38 am
I'll take that as a no then...
April 3, 2011 at 7:35 pm
I have the same issue. Anyone who found the efficient way to reallocate data from one big data file to smaller files?
April 4, 2011 at 6:10 am
EvilPostIT (7/19/2010)
I'll take that as a no then...
How many filegroups\files do you currently have in use for this database?
Toothpicker (4/3/2011)
I have the same issue. Anyone who found the efficient way to reallocate data from one big data file to smaller files?
This is a different situation altogether. You would not empty the file, but work out which objects you want to relocate and move them (obviously create your filegroups\files first)
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 4, 2011 at 2:09 pm
This is a different situation altogether. You would not empty the file, but work out which objects you want to relocate and move them (obviously create your filegroups\files first)
How's that different from OP task?
The goal is to spread data from one large 1.2TB data file (not an mdf file) into several smaller (500GB or less) files
on SQL 2008 64 bit enterprise platform. I can keep the original large file but then I have to shrink it to 500GB.
I don't want create an extra filegroup unless it's absolutelly neccessary and I cannot take 1.6TB database
off production for more then 2 hours.
March 16, 2020 at 7:43 pm
Did you try to DBCC shrinkFile 100GB at a time ?? It works for me. I shrunk down 1.2TB
March 16, 2020 at 9:48 pm
Make sure you pre-allocate enough log space to handle any logging required. If the log file has to grow dynamically, that will be very slow.
Make sure the new data files are also pre-allocated to the full size needed. Before that, verify that IFI is enabled. If it's not, you need to enable IFI before moving the data!
Check the log file for the db and look for error messages, and to make sure that nothing is blocking/slowing the data transfer. This is likely only if some type of snapshot is in use, or something else that requires the version store be used.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply