September 11, 2010 at 11:45 pm
Hi Team,
I am very new to DBA environment
Transaction log backups could not support simple recovery model Why ?
Could you any body please explaine. step by step...
Thanks
September 12, 2010 at 12:21 am
I think a good place to start on this is to check books online or google Recovery Models..
In simple recovery mode, the log will checkpoint and you will lose the transaction chain. Thus a log backup serves absolutely nothing.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
September 12, 2010 at 2:28 am
Simple recovery means that you don't want the log to be retained and you don't need point in time recovery. Hence no log backups. Full and bulk logged means that you want to prevent reuse until a log backup is taken because you need point in time recovery.
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 12, 2010 at 9:59 pm
Hi Team,
In simple recovery model does't support point of failure why ?
In Full recovery model point of failure is supporting why ?
can any body give me good explanations ?
Thanks for advance.. really appreciate those guys..
September 12, 2010 at 11:25 pm
shiv-356842 (9/12/2010)
In simple recovery model does't support point of failure why ?
Because that's the way it's designed
In Full recovery model point of failure is supporting why ?
Because that's the way it's designed
Have you read through Books Online as recommended?
The main point and reason for the recovery models is that two retain the log allowing for log backups and point-in-time recovery and one doesn't. So depending on whether you need the ability to do point in time recoveries or not, you then select the appropriate recovery model
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 13, 2010 at 11:24 am
To add to that - not everybody needs to have point in time recovery. Due to this, it would have been bad design to force everybody to perform log backups or force everybody into something they don't need. The difference in these recovery models allows people to have choices in how they support their data.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
September 14, 2010 at 12:30 am
It is not possible to take Transactional log backup. becoz in simple recovery model transactions are not stored in .LDF file after a full backup.
September 14, 2010 at 2:01 am
shaik.masrath (9/14/2010)
It is not possible to take Transactional log backup. becoz in simple recovery model transactions are not stored in .LDF file after a full backup.
Um, no.
In simple recovery inactive portions of the log are marked as reusable when a CHECKPOINT occurs, not a full backup.
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 14, 2010 at 8:29 am
shaik.masrath (9/14/2010)
It is not possible to take Transactional log backup. becoz in simple recovery model transactions are not stored in .LDF file after a full backup.
See Gail's response - it is accurate.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
September 14, 2010 at 11:56 am
I also agree with Gail!
September 16, 2010 at 1:57 pm
CirquedeSQLeil (9/13/2010)
To add to that - not everybody needs to have point in time recovery. Due to this, it would have been bad design to force everybody to perform log backups or force everybody into something they don't need. The difference in these recovery models allows people to have choices in how they support their data.
There's an example of that in my old workplace. We had an ERP software app with a SQL Server database at the back end. One of the software's capabilities was being able to have more than one company in the system (each with its own SQL database). So in addition to the live company, we had a test company which we used for trying things out, letting new users get acquainted with the system, etc. To put data in the test company, we just restored one of the live company's BAK files to the test company's database, and then periodically refreshed the test company from a backup of the live company.
Obviously, the live company's recovery model was Full, with a maintenance plan creating full backups every night and transaction log backups every two hours during the business day. The only support the test company needed was just a restore from a live-company BAK file every once in a while, so we left the test company's recovery model at Simple and didn't worry about creating a maintenance plan for it.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply