January 8, 2013 at 12:27 am
i am new in DBA.
If in a database MDF file Size is 10 GB and LDF file size is 50 GB
What are the steps require to reduce to log file size.
January 8, 2013 at 1:03 am
DIB IN (1/8/2013)
If in a database MDF file Size is 10 GB and LDF file size is 50 GB.What are the steps require to reduce to log file size.
LDF will grow it should. it is its nature. but we need to manage the files ? whats the recovery model ? simple or full ? are you taking its regular backup ? see this link http://www.sqlservercentral.com/articles/Administration/64582/
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
January 8, 2013 at 1:15 am
As you state that you are a new DBA, I would strongly recommend reading the Accidental DBA guide (link in my signature below) as it will cover some of the main issues which are faced in the world of SQL.
But as Bhuvnesh, what is the recovery model of the database? If FULL or BULKLOGGED do you have transaction log backups running?
January 8, 2013 at 1:35 am
recovery model is full
January 8, 2013 at 1:37 am
Do you do transaction log backups?
Do you need the databases to be in full recovery?
What is your acceptable amount of data loss? What is your recovery point objective? Can you loose a days worth of data with no affects to the business, or can you only loose minutes?
How often do you do full or differential backups?
January 8, 2013 at 2:37 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
January 8, 2013 at 3:38 am
You should keep it to simple recovery model, untill u dont think your all transactions should logged in log file till the database backup process and it increses size of your log file..
OR you should take backup periodically..
January 8, 2013 at 3:46 am
Well i have gone through the articles mentioned above. Currently there is no transaction back up. database is in full recovery.
Will it be useful if we run the below query when there is no transaction active?
USE DBNAME;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE DBNAME
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (DBNAME_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE DBNAME
SET RECOVERY FULL;
GO
January 8, 2013 at 3:48 am
Do you need the database to be in FULL recovery?
As I have said what is your acceptable amount of data loss? How much data can you afford to loose with this database?
January 8, 2013 at 3:53 am
database to be Full recovery.
there will be no data loss or minimum data loss.
January 8, 2013 at 3:56 am
Then you need to ensure that you setup transaction log backups otherwise the issue will keep happening.
Go back to the business and ask them what the recovery point objective is for the database, that will determine how often you need to backup the transaction log.
If they can loose 15 minutes worth of data, then transaction log backups need to run every 15 minutes etc.
If your not bothered about restoring to a point in time now, then yes setting to simple and shrinking will be one option. If you want the log chain to be intact, do a manual backup of the log, then shrink, which will give you the recoveryability which you get from full without breaking the chain.
January 8, 2013 at 4:15 am
DIB IN (1/8/2013)
database to be Full recovery.there will be no data loss or minimum data loss.
Simple recovery model doesn't support that. Have another read through that article, specifically the sections on log backups.
p.s. Don't shrink the log to 0. Once you have log backups running, you can shrink the log to a sensible size (0 is not sensible)
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
January 8, 2013 at 4:39 am
Please confirm if the below points are true for full recovery model without changing the recovery model:-
The below query will take the back up transaction log and shrink the log file:-
USE DBNAME
Take a DB Full bacp of DB
Take a back up of log:-
backup log DBNAME with no_log
Shrink log:-
DBCC SHRINKFILE DBNAME_Log, 10)
January 8, 2013 at 5:07 am
Nope.
That will break the log chain, prevent further log backups, essentially put you in simple recovery model (which means you cannot meet your SLAs), then shrink the log to a stupidly small size.
Please read the article I referenced.
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
January 8, 2013 at 7:36 am
If you have databases in "FULL" recovery you need to backup the transaction logs. The easiest way to set this up as a new user is to use the Maintenance Plan Wizard.
Start a new plan and give it an appropriate name
Select "Backup DB Transaction Logs"
Set the Schedule to be Daily, every 15 minutes
Select "All databases"
"Create File for every database"
Select the folder location. I like to choose "sub directory for each DB" to keep it organized.
I suggest you do this right away to protect your data.
Once you have it running, you can do more reading and decide how you want to fine tune your processes, and perhaps be more selective in what and when you take backups. But right now, it's better to back up too much and too frequently.
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply