October 18, 2002 at 9:35 am
I am using following command for truncating the log files. Is this the correct method to trucating the log files.
Is there any way to check that the log files have been truncated or not.
Thanks for your help.
use express
backup log eXpress to sql1backup
dbcc shrinkfile (eXpress_1_log, truncateonly)
October 18, 2002 at 11:40 am
Is there a particular reason for shrinking the file afterwards......when it grows again, you'll take a performance hit.....
If your not gonna help, Please move to the side, because if your not helping the situation, your hurting it....
October 18, 2002 at 11:55 am
Just for the space purpose.
It there any way to figure if the transaction log has been truncating.
October 18, 2002 at 12:33 pm
A simple way is to set your enterprise manager to task pad view, and check the size of the file before and afterwards.
A more exact method would be to check the size in sysperfinfo.
And of course, there is always the performance monitor, to get the same info from sysperfinfo externally. (Use the SQLServer:Databases counters.)
If your not gonna help, Please move to the side, because if your not helping the situation, your hurting it....
October 18, 2002 at 1:47 pm
quote:
I am using following command for truncating the log files. Is this the correct method to trucating the log files.Is there any way to check that the log files have been truncated or not.
Thanks for your help.
use express
backup log eXpress to sql1backup
dbcc shrinkfile (eXpress_1_log, truncateonly)
while backing up your log file use the truncate_only option as well...
October 18, 2002 at 1:57 pm
Vishy.. don't you think that when we backup the log files it automatically truncate the log files.
October 18, 2002 at 3:00 pm
Note from SQLBOL
quote:
NO_LOG | TRUNCATE_ONLYRemoves the inactive part of the log without making a backup copy of it and truncates the log. This option frees space. Specifying a backup device is unnecessary because the log backup is not saved. NO_LOG and TRUNCATE_ONLY are synonyms.
After backing up the log using either NO_LOG or TRUNCATE_ONLY, the changes recorded in the log are not recoverable. For recovery purposes, immediately execute BACKUP DATABASE.
So if you do that you will have to perform a Database backup. Now as for shirnkfile I suggest don't do it as Scorpion_66 stats, you will take a performance hit the moment the log has to grow.
Just BACKUP LOG as you have should be fine
quote:
Note If backing up the log does not appear to truncate most of the log, an old open transaction may exist in the log. Log space can be monitored with DBCC SQLPERF (LOGSPACE). For more information, see Transaction Log Backups.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply