Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Truncate log Expand / Collapse
Author
Message
Posted Tuesday, September 29, 2009 7:52 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Monday, October 13, 2014 1:58 PM
Points: 752, Visits: 1,070
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

Post #795140
Posted Tuesday, September 29, 2009 8:30 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 12:41 PM
Points: 20,734, Visits: 32,510
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.





Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #795165
Posted Tuesday, September 29, 2009 8:45 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, October 8, 2014 9:35 AM
Points: 2,223, Visits: 3,649
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?





Pradeep Singh
Post #795183
Posted Tuesday, September 29, 2009 8:48 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Monday, October 13, 2014 1:58 PM
Points: 752, Visits: 1,070
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
Post #795190
Posted Tuesday, September 29, 2009 8:51 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,181, Visits: 15,626
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #795196
Posted Tuesday, September 29, 2009 8:55 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 12:41 PM
Points: 20,734, Visits: 32,510
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.



Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #795200
Posted Tuesday, September 29, 2009 11:22 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 12:19 PM
Points: 40,200, Visits: 36,602
Please read through this - Managing Transaction Logs


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #795327
Posted Tuesday, September 29, 2009 11:38 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 12:41 PM
Points: 20,734, Visits: 32,510
GilaMonster (9/29/2009)
Please read through this - Managing Transaction Logs


Add I must that article to the library in my sig block.



Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #795342
Posted Tuesday, September 29, 2009 11:52 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 12:19 PM
Points: 40,200, Visits: 36,602
Lynn Pettis (9/29/2009)
GilaMonster (9/29/2009)
Please read through this - Managing Transaction Logs


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 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #795349
Posted Tuesday, September 29, 2009 12:01 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 12:41 PM
Points: 20,734, Visits: 32,510
GilaMonster (9/29/2009)
Lynn Pettis (9/29/2009)
GilaMonster (9/29/2009)
Please read through this - Managing Transaction Logs


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.


Handy though the links are...



Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #795359
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse