I am running dbcc shrinkfile (filename, targetsize) example [dbcc shrinkfile (adventureworks, 2500) and I get the following error.
DBCC SHRINKFILE: Page 1:43775823 could not be moved because the partition to which it belonged was dropped.
My question, what does the number 43775823 mean? Is this the page number? How do I find out what the page that can't be moved is related to?
I need to get past this as I have 250 GB still free in this datafile. I created multiple file groups and have moved approx 800 GB out of the primary datafile. The shrinking operation has gone very smoothly up to this point. When I first came across this error I restarted the SQL Server Service, it didn't help, I then rebuilt all the indexes on the primary filegroup tables and that hasn't helped. The only article I have found on Google or Bing that addressed this, the guy deleted all indexes and was able to shrink the file, the then recreated his indexes. I have no problem doing this if I can determine what table is having the issue.
Any help is appreciated.
SQL 2005 SP3
Tim, 43775823 is the page number as you guessed. It is page 4775823 of file 1 in your database.
Have you made sure that your database is in a consistant state? Have you run DBCC CHECKDB recently? I would make sure that this were the case before doing anything drastic. Once that is ok, then the following may be of use.
First a word of warning:
To do the following, you will need to use an undocumented DBCC command. DO THIS AT YOUR OWN RISK! A test system is really useful for this stuff!!
Let me say that this command should not break anything and is used by Microsoft to troubleshoot and has been explained by the man who wrote it here: Paul Randal (DBCC PAGE and DBCC IND)<----- READ THIS SO YOU SEE WHAT I MEAN.
It will take the two numbers I mentioned above (File Number and Page Number) and display some information that you can then use to find the table that is "broken".
As Paul states, you need to activate a trace to send the output of the command that follows it to your console instead of the error log:
You would then issue the DBCC command:
As an example (I take your database to be "TimsDatabase"):
This will find the information for file 1, page 43775823 of TimsDatabase and print just the header for that page.
This should be enough to then return the
You then take this number and run:
You should then get the name of the table you are after.
You can then turn off the trace option you previously set: