Simple recovery

Hi All,
Its very basic  question for my understanding  I have try to learn my self but need some important and Perfect  information request to you every body  please answer the below.
In Simple recovery why does not  allow transaction log  backups and why does not  support point-in-time recovery.
Kindly provide valuable  information
subu

To add a little more to the above point illustrated, a database in
Simple Recovery model is usually in Auto-Truncate mode which means log truncation can usually occur immediately after upon
checkpoint in performing in a making of space available for reuse.
read here more about checkpoint
http://msdn.microsoft.com/en-gb/library/ms189573.aspx
…to explain it in other word SQL Server usually flushes cached dirty pages to disk after first writing the transaction details and after this process what it does is immediately truncates
(remove the data from the log to make space without reducing the size) any
VLF that are no longer active (internally SQL Server breaks a transaction log file down into sub-files which is called Virtual Log Files (VLFs)) so in this truncation process the space that are freed can be used to store new log records.
Therefore simple recovery model keeps the transaction log records only till the next checkpoint process happens because of this reason SQL will not allow us to perform transaction
log backup in simple recovery model because the transaction log is not retained in simple recovery and the main reason taking transaction log is for DR reason.
So that’s the reason why log backups are simply meaningless for simple recovery model databases since it’s on auto-truncate and we are not able to use the contents of the log to restore the
database to a state of failure or point in time.
So to sum up Transactional replication, log shipping, or data mirroring is not allowed in the simple recovery model since their life basically relay on transaction log and simple recovery
is their enemy in truncating their log every checkpoint. 
I hope this helps
Please remember to click “Mark as Answer” on the post that has answered your question as it is very relevant to other community members dealing with same problem in seeking the right answer.

Similar Messages

  • Why is the transaction log file not truncated though its simple recovery model?

    My database is simple recovery model and when I view the free space in log file it shows 99%. Why doesn't my log file truncate the committed
    data automatically to free space in ldf file? When I shrink it does shrink. Please advice.
    mayooran99

    My database is simple recovery model and when I view the free space in log file it shows 99%. Why doesn't my log file truncate the committed
    data automatically to free space in ldf file? When I shrink it does shrink. Please advice.
    mayooran99
    If log records were never deleted(truncated) from the transaction log it wont show as 99% free.Simple recoveyr model
    Log truncation automatically frees space in the logical log for reuse by the transaction log and thats what you are seeing. Truncation wont change file size. It more like
    log clearing, marking
    parts of the log free for reuse. 
    As you said "When I shrink it does shrink" I dont see any issues here. Log truncation and shrink file is 2 different things.
    Please read below link for understanding "Transaction log Truncate vs Shrink"
    http://blog.sqlxdetails.com/transaction-log-truncate-why-it-didnt-shrink-my-log/

  • SQL Server Database - Transaction logs growing largely with Simple Recovery model

    Hello,
    There is SQL server database on client side in production environment with huge transaction logs.
    Requirement :
    1. Take database backup
    2. Transaction log backup is not required. - so it is set to Simple recovery model.
    I am aware that, Simple Recovery model also increases the transaction logs same as in Full Recovery model as given on below link.
    http://realsqlguy.com/origins-no-simple-mode-doesnt-disable-the-transaction-log/
    Last week, this transaction log became of 1TB size and blocked everything on the database server.
    How to over come with this situation?
    PS :  There are huge bulk uploads to the database tables.
    Current Configuration :
    1. Simple Recovery model
    2. Target Recovery time : 3 Sec
    3. Recovery interval : 0
    4. No SQL Agent job schedule to shrink database.
    5. No other checkpoints created except automatic ones.
    Can anyone please guide me to have correct configuration on SQL server for client's production environment?
    Please let me know if any other details required from server.
    Thank you,
    Mittal.

    @dave_gona,
    Thank you for your response.
    Can you please explain me this in more details -- 
    What do you mean by one batch ?
    1. Number of rows to be inserted at a time ?
    2. or Size of data in one cell does matter here.
    As in my case, I am clubbing together all the data in one xml (on c# side) and inserting it as one record. Data is large in size, but only 1 record is inserted.
    Is it a good idea to shrink transaction log periodically, as it is not happening itself in simple recovery model.
    HI Mittal,
    Shrinking is bad activity yu should not shrink log files regularly, in rare case if you want to recovery space you may do it.
    Have manual chekpoints in Bulk insert operation.
    I cannot tell upfront what should be batch size but you can start with 1/4 th of what you are currently inserting.
    Most important what does below query return for database
    select log_reuse_wait_desc from sys.databases where name='db_name'
    The value it returns is what stopping the log from getting cleared and reused.
    What is version and editon of SQl server we are talking about. What is output of
    select @@version
    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
    My Technet Wiki Article
    MVP

  • Change SharePoint_Config Database to simple recovery mode. Risk.

    Hello,
    we have SBS 2008 with Exchnage and OWA-Service.
    The Logfile of SharePoint is very large (30 GB).
    But we don't use SharePoint.
    I want to change the recovery mode of SharePoint_Config Database to simple.
    But i don't know, what of Application/Services/Programms use SharePoint Database.
    What are the risks of changing SharePoint_Config Database to Simple Mode?
    What of the Sevices/Programms  use SharePoint Database ?
    Thank You

    Hi ,
    As Dimitri pointed out, SharePoint DB is in SQL database, the change of it won't affect Exchange and Outlook Web Access.
    If you use SharePoint in future, you may take a look at the following article about the effect to SharePoint database with simple recovery mode.
    http://searchwinit.techtarget.com/tip/How-SQL-Server-recovery-models-impact-your-SharePoint-databases
    Thanks
    Daniel Yang
    TechNet Community Support

  • SQL Server 2012 DB log file doesn't shrink (simple recovery model)

    I've found several similar questions in this forum, but none of the answers have resolved my problem: I have a SQL Server 2012 DB using simple recovery model.  The MDF file is 12 GB and the LDF file is 10 GB.  I'm trying to shrink the size of the
    LDF file.  I've read that for simple recovery model DBs there are reasons for delaying log file shrinking, but I still can't find a solution based on these reasons.
    When I try to shrink it using this command:
    DBCC SHRINKFILE(MyDB_log, 1000000)
    I get these results, and no change of file size:
    DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages8 2 1241328 128 1241328 128
    The same results running this:
    DBCC SHRINKFILE(MyDB_log, 1000000, TRUNCATEONLY)
    There doesn't appear to be any open transactions:
    DBCC OPENTRAN()No active open transactions.DBCC execution completed. If DBCC printed error messages, contact your system administrator.
    And this returns NOTHING:
    SELECT name, database_id, log_reuse_wait_desc FROM sys.databases WHERE database_id = DB_ID()name database_id log_reuse_wait_descMyDB 8 NOTHING
    I've also tried running the following, but nothing useful is returned:
    SELECT * FROM sys.dm_tran_database_transactionsSELECT * FROM sys.dm_exec_requests WHERE database_id=DB_ID()SELECT * FROM sys.dm_tran_locks WHERE resource_database_id=DB_ID()
    Any other suggestions of what I can do to shrink this log file?  Or perhaps someone can justify its enormous size?
    David Collacott

    The answer is pretty simple.
    The following code is the problem:
    DBCC SHRINKFILE(MyDB_log, 1000000)
    You are telling SQL Server that you want to "shrink" the MyDB_log file and the target size is 1TB.  Well according to you the MyDB_Log file is well below the 1TB size you are targeting, in fact it's only 10GB so SQL Server is doing precisely what you
    are telling it to do.
    See, according to the SQL Server documentation
    here, target size "Is the size for the file in megabytes, expressed as an integer."
    Now if you'd like to actually shrink the log file down to, oh say 1GB, then you should try the following command:
    DBCC SHRINKFILE(MyDB_log, 1000)
    The theory being 1000 * 1048576 (i.e. 1MB) is equal to 1GB.

  • What is impact to MDF file size if change database to simple recovery mode

    Hi,
    Currently I have a Database with 27GB MDF and 80GB LDF.
    If I change from Full recovery to Simple recovery mode, would LDF information be transfered to MDF file and make
    MDF file size exceed 100GB?

    Hi
    May I know how to perform point in time recovery? Currently the only backup we perform every 4 hours is the server OS snapshot.
    Example :
    1. Now is 6pm and some error transaction occurred.
    2. We can perform 3pm server OS snapshot recovery on the mdf file. ( We would lost 3 hours data in this case )
    3. Could we apply the ldf transaction log after OS snapshot recovery and roll it forward till 5:50pm?
    You would be able to perform point in time recovery if you have
    1. Database configured in full recovery mode
    2. You were taking transaction log backups.(of course with full backup or may be differential)
    In your scenario applying snapshot wont help you.What you have to do it you should have full backup in place .If you had full backup ,like full backup at 3 PM then you would have restored it with no recovery.After that suppose you took tansaction log backups
    every on hour then restore 1 PM ,2 PM and 3 PM log backup all in nore covery.
    Now i should have mentioned first but before restoring full backup you can also take tail log backup read this article
    http://technet.microsoft.com/en-us/library/ms179314.aspx
    So now after full and all log backups are applied with no recobery apply tail log backup with recovery and its quite possible that you might not have a data loss or in some scenario very small data loss( not 3 hrs as you would have with snapshot)
    hope this helps
    Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers

  • Simple recovery mode

    Hi,
    I have a question..
    My production database is in full recovery mode and we have daily full backups and t-log backups after every 10 minutes.
    Suppose if I set the database in simple recovery mode for some reason, do the old full backups and t-log backups are of no use after setting the db in simple recovery mode. can I use these backups to go back in time.
    Regards

    Assume the following chain of events:
    A: Full backup
    B: Log backup
    C: Switch to simple reocvery
    D: Full backup
    E: Log backup
    F: Switch back to full recovery.
    G: Log backup
    H: Full backup
    I: Log backup
    You will be able to restore to any point in time up to C. You will also be able to restore to any point in time from H and on - but only if the full backup at H is good. The log backups at point E and G will fail, since you cannot take log backups in simple
    recovery. And the database remains in simple recovery until you have taken a full backup.
    Erland Sommarskog, SQL Server MVP, [email protected]
    Erland,
    After you switch to simple recovery how is log backup E possible. Again how is log backup G possible after you switch to full recovery and dont take full backup  ?
    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
    My Technet Articles

  • If db is in simple recovery mode can we identify who deleted the login id?

    if db is in simple recovery mode can we identify who deleted the login id?

    You can take a look in the default trace to find who dropped it. If you are lucky enough.
    The database being in simple recovery mode has nothing to do with it. Even in full recovery mode this is not going to be seperately logged.
    SELECT TE.name AS [EventName] ,
    v.subclass_name ,
    T.DatabaseName ,
    t.DatabaseID ,
    t.NTDomainName ,
    t.ApplicationName ,
    t.LoginName ,
    t.SPID ,
    t.StartTime ,
    t.RoleName ,
    t.TargetUserName ,
    t.TargetLoginName ,
    t.SessionLoginName
    FROM sys.fn_trace_gettable(CONVERT(VARCHAR(150), ( SELECT TOP 1
    f.[value]
    FROM sys.fn_trace_getinfo(NULL) f
    WHERE f.property = 2
    )), DEFAULT) T
    JOIN sys.trace_events TE ON T.EventClass = TE.trace_event_id
    JOIN sys.trace_subclass_values v ON v.trace_event_id = TE.trace_event_id
    AND v.subclass_value = t.EventSubClass
    WHERE te.name IN ( 'Audit Addlogin Event', 'Audit Add DB User Event',
    'Audit Add Member to DB Role Event' )
    AND v.subclass_name IN ( 'Drop', 'Revoke database access' )
    https://www.simple-talk.com/sql/performance/the-default-trace-in-sql-server---the-power-of-performance-and-security-auditing/
    This query is only going to check the last trace file and by default you have four others, putting path instead of the subquery to find the trace path will also work.
    Regards, Ashwin Menon My Blog - http:\\sqllearnings.com

  • How the transactional replication work for simple recovery database (looking for some internal concept)

    How the transactional replication work for simple recovery database (looking for some internal concept)
    Rahul

    There seems to be a new myth going around recently. I’ve had at least three people tell me, in the last month, that SQL’s transactional replication requires the database to be in full recovery.
    This is complete fabrication. Replication (SQL native replication, that is) can work with the databases in any of the recovery models.
    Transactional replication does involve the transaction log, as that’s where it picks up changes from. The log reader scans over the transaction log looking for log records marked for replication, copies those to the distribution database and then marks them
    as replicated. When the checkpoint (for simple recovery) or log backup (for full or bulk logged) occur, the log will only be truncated up to the oldest inactive, replicated transaction.
    Because transactional replication has its own way of ensuring log records aren’t discarded before been picked up by the log reader, there’s no requirement for a specific recovery model.
    Refer this link
    http://sqlinthewild.co.za/index.php/2008/12/05/a-new-sql-myth/
    --Prashanth

  • SQL Server transaction log not truncating in simple recovery model mode

    The transaction log for our SQL Server database is no longer truncating when it gets to the restricted file growth limit set by the autogrowth settings. Previously - as expected - it would reach this limit and then truncate allowing further entries. Now
    it stays full and the application using it shuts down. We are using 2008 R2 and the recovery model is set to simple. Is this a known behaviour / fault which can be resolved ? Thanks.

    As already suggested check wait type in log_reuse_wait_desc from sys.databases and open transaction on the database.
    Also, check long running SPIDs are waiting for from sys.sysprocesses from wait_type column
    0 = Nothing - What it sounds like.. Shouldn't be waiting
    1 = Checkpoint - Waiting for a checkpoint to occur. This should happen and you should be fine - but there are some cases to look for here for later answers or edits.
    2 = Log backup - You are waiting for a log backup to occur. Either you have them scheduled and it will happen soon, or you have the first problem described here and you now know how to fix it
    3 = Active backup or restore - A backup or restore operation is running on the database
    4 = Active transaction - * There is an active transaction that needs to complete (either way -
    ROLLBACK or COMMIT) before the log can be backed up. This is the second reason described in this answer.
    5 = Database mirroring Either a mirror is getting behind or under some latency in a high performance mirroring situation or mirroring is paused for some reason
    6 = Replication - There can be issues with replication that would cause this - like a log reader agent not running, a database thinking it is marked for replication that no longer is and various other reasons. You can also see this reason and it is
    perfectly normal because you are looking at just the right time, just as transactions are being consumed by the log reader
    7 = Database snapshot creation You are creating a database snapshot, you'll see this if you look at just the right moment as a snapshot is being created
    8 = Log Scan I have yet to encounter an issue with this running along forever. If you look long enough and frequently enough you can see this happen, but it shouldn't be a cause of excessive transaction log growth, that I've seen.
    9 = An AlwaysOn Availability Groups secondary replica is applying transaction log records of this database to a corresponding secondary database
    Please click the Mark as answer button and vote as helpful if this reply solves your problem

  • Restore a log backup on to database whose recovery model is SIMPLE ?

    Hi All,
    Today, it was new thing I found when I was testing some log shipping?
    Question is can we restore a LOG BACKUP on a database whose recovery model is SIMPLE?
    Brief background:
    I setup log shipping in SQL Server 2012 SP1 Enterprise Edition between 2 instances. Log shipping is in Standby/readonly mode. So, everything was working very fine...
    Now I changed the recovery model of secondary database on 2nd instance from Full to SIMPLE, still the restores are happening very fine. So, is this a normal behavior? other thing is once after restore job is complete the recovery model is getting changed to
    FULL automatically on secondary db and I verify it before and after restore job using below query:
    select name,recovery_model_desc from sys.databases
    Based on my knowledge when a database is in SIMPLE recovery model, we can't perform any log backups on the database and since no log backups, we cant perform Point in Time recovery?
    Please clarify what I am seeing is normal ? Also, would like to know what is happening behind the scenes?
    Thanks and appreciate your help.
    Sam

    Hi,
    >>Question is can we restore a LOG BACKUP on a database whose recovery model is SIMPLE?
    Yes you can restore Log backup on database which is in simple recovery.
    You must understand what recovery model is for. Recovery model affects Logging and recovery of a database it does not puts restriction on what can be restore on it. Of course you cannot take log backup of database in simple recovery but you can restore.
    Reason being in simple recovery log is truncated after checkpoint (unless something is holding logs like long running transaction). Recovery model also controls the extent of logging which would be done for transaction and hence recovery which you can do
    PS: Dont play with logshipping like this which is configured on prod environment
    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
    My Technet Wiki Article
    MVP

  • Why db mirror can not set db recovery model to simple?

    Hi ,All
    I have a question . 
    DB replication can set db recovery model to simple ,why db mirror can not  db recovery model to simple.
    DB mirror must be set to full recovery model.
    As far as I know, whatever db mirror  and db replication ,there is a log reader to read the log in the ldf file
    DB mirror and DB replication are almost the same principle to replicate the db to another db server
    Thanks a lots
    Love SQL

    Database mirroring involves redoing every
    insert, update, and delete operation that occurs on the principal database onto the mirror database as quickly as possible. Redoing is accomplished by sending a stream of active transaction log records to the mirror server, which applies log records to the
    mirror database, in sequence, as quickly as possible. Unlike replication, which works at the logical level, database mirroring works at the level of the physical log record.
    There is no log reader agent in case of mirroring its more internal. Mirroring
    uses the transaction log to redo everything at the mirror site.  In simple recovery model, the transaction log is effectively transitory and only enough information is kept in the log for undo/redo to keep the database consistent during
    crash recovery. Thats why mirroring does not work in simple recovery model.

  • DPM is Only Allowing Express Full Backups For a Database Set to Full Recovery Model

    I have just transitioned my SQL backups from a server running SCDPM 2012 SP1 to a different server running 2012 R2.  All backups are working as expected except for one.  The database in question is supposed to be backuped up iwht a daily express
    full and hourly incremental schedule.  Although the database is set to full recovery model, the new DPM server says that recovery points will be created for that database based on the express full backup schedule.  I checked the logs on the old DPM
    server and the transaction log backups were working just fine up until I stopped protection the data source.  The SQL server is 2008 R2 SP2.  Other databases on the same server that are set to full recovery model are working just fine.  If we
    switch the recovery model of a database that isn't protected by DPM and then start the wizard to add it to the protection group it properly sees the difference when we flip the recovery model back and forth.  We also tried switching the recovery model
    on the failing database from full to simple and then back again, but to no avail.  Both the SQL server and the DPM server have been rebooted.  We have successfully set up transaction log backups in a SQL maintenance plan as a test, so we know the
    database is really using the full recovery model.
    Is there anything that someone knows about that can trigger a false positive for recovery model to backup type mismatches?

    I was having this same problem and appear to have found a solution.  I wanted hourly recovery points for all my SQL databases.  I was getting hourly for some but not for others.  The others were only getting a recovery point for the Full Express
    backup.  I noted that some of the databases were in simple recovery mode so I changed them to full recovery mode but that did not solve my problem.  I was still not getting the hourly recovery points.
    I found an article that seemed to indicate that SCDPM did not recognize any change in the recovery model once protection had started.  My database was in simple recovery mode when I added it (auto) to protection so even though I changed it to full recovery
    mode SCDPM continued to treat it as simple. 
    I tested this by 1) verify my db is set to full recovery, 2) back it up and restore it with a new name, 3) allow SCDPM to automatically add it to protection over night, 4) verify the next day I am getting hourly recovery points on the copy of the db. 
    It worked.  The original db was still only getting express full recovery points and the copy was getting hourly.  I suppose that if I don't want to restore a production db with an alternate name I will have to remove the db from protection, verify
    that it is set to full, and then add it back to protection.   I have not tested this yet.
    This is the article I read: 
    Article I read

  • Recovery of lost file is it possible

    I like to recover chat messages from Nov 6, 2012 to Decemeber 2012, can some help please

    Recovery Toolbox for Illustrator - an easy to use Adobe Illustator recover tool that will make the task of recovering data from damaged *.ai files a breeze.
    analyzes the structure of the file and recovers data from all available layers
    simple recovery file tool for Illustrator, reliable and easy to use repair Illustrator files tool that will make the recovery of damaged Adobe Illustrator files as quick and hassle-free as possible
    several mouse clicks - and you have the results of your work again
    You may download demo version from here: http://www.illustrator.recoverytoolbox.com/
    To attempt recovery using Illustrator itself:
    1.Create a new document
    2.Select “place image” ( File > Place… )
    3.Choose your corrupted file in the dialog box. Make sure you choose file types to ” ALL DOCUMENTS “, not just RECOMMENDED.
    4.Save this file. If you cannot save this file (due to corruption), copy your vectors and paste them into a new illustrator document.
    PROS: You should be able to select the corrupted file, and your vector work should be saved.
    CONS: All layers will be flattened into one. PMS color info and placed images may be lost. File may still be corrupted.

  • Oracle DB equivalent of SQL Server's Simple Transaction Logging mode?

    G'Day Experts !
    Was wondering if Oracle DB has the functional equivalent of the 'simple' transaction logging available in SQL Server?
    Would this be availabe at the schema level, or would it have to be the entire instance?
    I'm asking because the WebCenter Interaction portal and related services has no practical use for point-in-time rollbacks. The portal uses discreet event boundaries which unfortunately do not map into the relational world.
    Thanks!
    Rob in Vermont

    Plumtree wrote:
    G'Day Experts !
    Was wondering if Oracle DB has the functional equivalent of the 'simple' transaction logging available in SQL Server?
    Would this be availabe at the schema level, or would it have to be the entire instance?
    I'm asking because the WebCenter Interaction portal and related services has no practical use for point-in-time rollbacks. The portal uses discreet event boundaries which unfortunately do not map into the relational world.
    Thanks!
    Rob in VermontHi Rob
    I assume you are referring to the simple recovery model, i.e lose everything since last backup. Oracle's equivalent of that is to run a database in NOARCHIVELOG mode. It applies to the database rather than the instance, though you probably intended database when you said instance.
    Niall Litchfield
    http://www.orawin.info/

Maybe you are looking for