September 29, 2009 at 7:52 am
Hi,
I have a database in SQL Server 2000.
This database is in full recovery model.
The log size is now of 10GB.
I have made a backup of the database (full backup) and i need to truncate the log, and then shrink it.
how can i truncate all the log from a database that is in full recovery model?
Thank you
September 29, 2009 at 8:30 am
river-653653 (9/29/2009)
Hi,I have a database in SQL Server 2000.
This database is in full recovery model.
The log size is now of 10GB.
I have made a backup of the database (full backup) and i need to truncate the log, and then shrink it.
how can i truncate all the log from a database that is in full recovery model?
Thank you
If your database is using the full recovery model, why don't you have regularly scheduled transaction log backups? Running scheduled transaction log backups will keep your transaction log file from continually growing. IF point in time recovery is not necessary, then I'd change your recovery model to simple.
How large is your database itself? I'd use this to help determine the initial size for your transaction log.
In SQL Server 2000, the simpliest way is BACKUP LOG WITH TRUNCATE_ONLY (hopefully that is correct, check BOL).
After you do that, you can use DBCC SHRINKFILE (again, look in BOL for more info).
Once that is done, run another full backup, and if you are leaving the database in full recovery, setup regularly scheduled transaction log backups to manage the size the transaction log.
September 29, 2009 at 8:45 am
If you do not need point in time recovery (that's the reason u must have put the db in full recovery mode), why dont keep it in simple recovery mode?
September 29, 2009 at 8:48 am
My database as 430 MB in the data file and 10GB in the Log file.
I want to live the database in full recovery model, because i want to be able to do recovery in time.
I will do what you told me (truncate the log file, then shrink it) and then make another full backup to this database.
What does the backup log with_notruncate do exactly?
thank you
September 29, 2009 at 8:51 am
If you want point in time recovery, you need to have log backups. Set them up, maybe once an hour to start, and keep all log backups since the most recent full. that way you can recover to a point in time.
A log backup will mark those transactions in the log as free, and the space can be reused. Note how big your log backups are, and then you can shrink the log to hold that much data, plus some pad. Likely your log is much bigger than it needs to be. However, a shrink should not be done regularly. Just for one-time events, like this, and use DBCC SHRINKFILE.
You can read about the backup command in books online to understand what the truncate does. Basically it's an emergency measure when you have filled the disk. If you haven't don't run it.
September 29, 2009 at 8:55 am
river-653653 (9/29/2009)
My database as 430 MB in the data file and 10GB in the Log file.I want to live the database in full recovery model, because i want to be able to do recovery in time.
I will do what you told me (truncate the log file, then shrink it) and then make another full backup to this database.
What does the backup log with_notruncate do exactly?
thank you
When you lookup DBCC SHRINKFILE, you will probaby want to shrink the transaction log to a size between 50 to 100 MB, that is about 10 to 20% the size of your database.
You also need to be sure to setup regularly scheduled transaction log backups between your full and differential backups. It is the regularly scheduled transaction og backups that will keep your transaction log from growing to 10 GB again, and will provide you with point in time recovery. If you don't have transaction log backups, you don't have the ability to performa point in time restore.
Please take the time to read BACKUP LOG in BOL. It will provide you with information regarding the options.
September 29, 2009 at 11:22 am
Please read through this - Managing Transaction Logs[/url]
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 29, 2009 at 11:38 am
September 29, 2009 at 11:52 am
Lynn Pettis (9/29/2009)
Add I must that article to the library in my sig block.
Much more and your sig will be larger than most of your posts. 😀 😉
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 29, 2009 at 12:01 pm
September 30, 2009 at 2:07 am
I will read it.
What about using BDCC shrink file instead of using the GUI (EM) to shrink the log file?
do i have any benefits of doing it through DBCC instead of doing it with the GUI?
thank you
September 30, 2009 at 9:44 am
river-653653 (9/30/2009)
What about using BDCC shrink file instead of using the GUI (EM) to shrink the log file?
All the GUI does is run DBCC ShrinkDatabase or DBCC ShrinkFile.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply