August 23, 2006 at 6:29 am
Hi !
I have problem with the DBCC shrink file command. I have a datafile thats is 133 Gb big and 69 Gb freee spce on the datafile. I have tried to shrink this data file with the comamnd DBCC shrink file (<data file name>, 130 000) but the size on the datafile is the same as before the shrink command and no error on the shrink command.
Does I need to run somthing to refresh the information that the shrink command did or did the shrink command not shrink the database file?
I hope somone can help me.
Regards ///Ulf Fernholm
August 23, 2006 at 6:44 am
Why don't you use 70000 instead of 130000 which is too close to 133000 MB?
August 23, 2006 at 7:00 am
DBCC shrink command take very long time, so because of that we only s´hrink the database file with 3 Gb and it this 3 Gb did take 4 hours to be complete.
There is two datafile on the database and the first database file i ddin't have any problem to shrink the file but on the second datafile I have problem to shrink it.
August 23, 2006 at 9:27 am
Did u backup before?
try this..
backup LOG DBNAME with truncate_only
DBCC SHRINKFILE(1) //DATAFILE
DBCC SHRINKFILE(2) //LOGFILE
August 24, 2006 at 12:32 am
The backup have been done the night/morning before the shrink command statement where executed on lunchtime.
We will not shrink the logfile, becuase we don't need to do that.
August 24, 2006 at 5:03 am
Hey use this piece of code
EXEC sp_dboption gl_rnd, 'trunc. log on chkpt.', 'True'
Checkpoint
DBCC SHRINKFILE ('gl_rnd_log',100,Truncateonly)
here gl_rnd is databasse name
and gl_rnd_log is logical name of log file
This wrks!!!
can somebody answer the query i posted o
http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=5&messageid=303721
August 24, 2006 at 5:06 am
Thanks I will try and see if its will work
Thanks in advanced Ulf Fernholm
August 24, 2006 at 5:19 am
you may want to refresh statistics before you go on ...
'-- Usage ' + db_name() + ' ' + convert(varchar(25),getdate(),121) ;
DBCC
UPDATEUSAGE (0) with count_rows ;
'-- Usage Statistics ' + db_name() + ' ' + convert(varchar(25),getdate(),121) ;
EXEC
sp_updatestats ;
then have a look at the numbers again.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
August 24, 2006 at 5:57 am
I try this command tomorrow to se if it will help me. I think you have right
the database doesnt show the right information and to update the statistics will proberly
give me the right answer on the size of the database after the DBCC shrinkfile statement
regards Ulf Fernholm
August 24, 2006 at 2:34 pm
If you're shrinking a large file, I would run dbcc updateusage first. Then start shrinking the database in small increments. You might find that your shrink fails if you specify a large size to shrink by. Usually this shrink process is prone to being a deadlock victim. Shrink multiple times via small sizes. That has always brought success for me in shrinking data files.
Sorry, I didn't read the entire posting(s) clearly. Since you're not concerned with shrinking the log, disregard my posting from below....
Better if you don't truncate the log.
You need to look into the situation and find out why it doesn't shrink.
Is the Database configured for replication? This might be why it won't shrink because there might be transactions marked for replication and will stay there until the distributor picks them up.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply