February 16, 2009 at 8:20 am
kladibeeto (2/16/2009)
Conclusion:If You DON'T perform transactional log backup's
You need to do this:
Execute:
BACKUP LOG DatabaseName with truncate_only
DBCC SHRINKFILE (FILENAME, 1000)
And don't conclude anything, not a best practice. We are only giving possible answers here for optimal performance, not confirmed answers.
February 16, 2009 at 9:24 am
I understand both of you and you have right. Only thing which I want to tell him is that is that he must start to work transactional log backup's or switch to simple recovery model.
I read this aritcles before I understand problem with truncating the log.
If you backup log with truncate only and after that perform full backup you didn't lose anything of data.
You are right that is not best practice but leave LDF file to grew to 180 GB is very wrong.
Best regards,
February 16, 2009 at 12:28 pm
kladibeeto (2/16/2009)
If you backup log with truncate only and after that perform full backup you didn't lose anything of data.
Why do you have to truncate the log anyway??Tuncate only does not reduce the physical size of the log file. You dont have to Truncate it. When you backup the Tlog it will remove the inactive portions of the log file.
If you want to reduce the file you need to explicitly Shrink the file but before this he needs to consider the options in my first reply or through this post what they have advised??
February 16, 2009 at 12:43 pm
Of course that he must shrink it after truncation. I wrote that to him. I still disagree that.
There is situation which I think that he has
1. I don't perform T. log backup and I don't care
2. Log grew to 180 GB big -- oh what now??
3. My full backup is enough to me.
4. Truncate log
5. Shrink file
6 Make full backup
Think about is it simple recovery model enough good for me OR start performing transactional log backup and in that situation FORGOT for Backup log with truncate only method.
This is my solution for him. I agree that this is not best practices but if I understand him good he are talking about some database on laptop.
February 17, 2009 at 9:29 am
Guys and Gals, if you read between the lines in the original post they put the app on the "Sales Guy's" laptop. Most likely its for customer demos and they never setup the maintenace jobs for tranaction log backups.
This is probably a copy of the "real" application and the simple recovery model will suffice.
Let's find out more about the business requirements for the data on the sales guy's laptop before we craft the proper solution.
Most likely if regular data updates are made to the laptop, and it's a true copy of production, the simple recovery model will solve the problem. :Whistling:
February 17, 2009 at 9:37 am
We haven't heard anything from the OP as of yet. So, We cannot really say Simple Recovery Model would be suffice. IF you look at the posts we have given him possible solutions as what we could do including yours.
So, Its better to wait for the OP's response than drawing out any conclusion
February 18, 2009 at 9:27 am
I totally agree Krishna. My sales people get reqular upates to the DB, but we never bother with the log files, it's just another thing that may slow down a demo.
Cheers
February 18, 2009 at 11:40 am
So, Do you send snapshots to your sales people?
February 20, 2009 at 11:01 am
not snapshots in the technical sense for SQL Server 2005, but we do update the laptops with our applications. I find its much easier to perform a backup / restore like I've alwasy done with sql2000.
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply