The only problem you are going to have with this is that you need to take a
full backup just prior too and fallowing the shrink because the shrink will
destroy your t-log. Which means you wont have point of failure recovery.
You will find that the shrink is most effective on the t-log file. This is
because each time the server does the t-log backup it clears the old data
out of the t-log but does not free the space the t-log has taken up. So for
example one day you have a process that feeds hundreds of thousands of
records into the db. But it was a one time thing that will most likely never
ever happen again. This process will make the t-log extremely large but in
the future the DB will never really ever take up that much space for normal
daily processing.
I use to set up a sql job that would shrink tempDB on a regular basis. There
is a sql command out there that will do it for you.
~Charlie
_____
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Jeff Stockard
Sent: Friday, April 24, 2009 8:26 AM
To: vantage@yahoogroups.com
Subject: [Vantage] SQL Server Management
I went into our SQL Vantage server the other day and the C: drive was almost
completely full. I noticed that there was a file called TempDB that was 34
GB. I called support and they told me that I could Shrink the TempDB using
SQL Server Management. They told me to open it and go to the System
Databases, right click on the TempDB, select Tasks and Shrink. I did this
and the TempDB went from 34 GB to 512 KB. This made me very happy. I had
never heard of this before, and I think it is great. They said that the
TempDB will grow, but never shrink until you reboot it or use the Shrink
option.
Now for my question. Is it safe to do a Shrink function on our MFGSYS803
database? We are on 803.407C, but I don't this that matters, because this
is a SQL function. SQL version is 2005.
Thank you
Jeff
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
full backup just prior too and fallowing the shrink because the shrink will
destroy your t-log. Which means you wont have point of failure recovery.
You will find that the shrink is most effective on the t-log file. This is
because each time the server does the t-log backup it clears the old data
out of the t-log but does not free the space the t-log has taken up. So for
example one day you have a process that feeds hundreds of thousands of
records into the db. But it was a one time thing that will most likely never
ever happen again. This process will make the t-log extremely large but in
the future the DB will never really ever take up that much space for normal
daily processing.
I use to set up a sql job that would shrink tempDB on a regular basis. There
is a sql command out there that will do it for you.
~Charlie
_____
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Jeff Stockard
Sent: Friday, April 24, 2009 8:26 AM
To: vantage@yahoogroups.com
Subject: [Vantage] SQL Server Management
I went into our SQL Vantage server the other day and the C: drive was almost
completely full. I noticed that there was a file called TempDB that was 34
GB. I called support and they told me that I could Shrink the TempDB using
SQL Server Management. They told me to open it and go to the System
Databases, right click on the TempDB, select Tasks and Shrink. I did this
and the TempDB went from 34 GB to 512 KB. This made me very happy. I had
never heard of this before, and I think it is great. They said that the
TempDB will grow, but never shrink until you reboot it or use the Shrink
option.
Now for my question. Is it safe to do a Shrink function on our MFGSYS803
database? We are on 803.407C, but I don't this that matters, because this
is a SQL function. SQL version is 2005.
Thank you
Jeff
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]