Timeline for Setting DB to Simple Recovery then back to Full Recovery
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 8, 2017 at 13:39 | vote | accept | squizz | ||
| Feb 8, 2017 at 13:39 | |||||
| Feb 7, 2017 at 14:37 | comment | added | Gareth Lyons | @squizz oh, how we love vendor recommendations :) The bulk-logged recovery model was designed with that kind of thing in mind technet.microsoft.com/en-us/library/ms190203(v=sql.105).aspx but equally may not help depending on what exactly is happening during that period. No problem & good luck! | |
| Feb 7, 2017 at 13:49 | comment | added | squizz | @GarethLyons - The system has an inbuilt archiving/purging function which generates thousands of transactions in a very short space of time, whilst it's running it was recommended by the vendor to put the DB into simple recovery (we don't necessarily agree with it and have raised several questions but they maintain it is necessary - the power of the vendor in all it's hideous glory). Thank you for your comments, appreciate the assistance. | |
| Feb 7, 2017 at 12:51 | history | edited | Gareth Lyons | CC BY-SA 3.0 |
deleted 18 characters in body
|
| Feb 7, 2017 at 12:50 | comment | added | Gareth Lyons | @ScottHodgin thanks, edited answer to reflect. Wasn't sure on diffs so put them in with a proviso. | |
| Feb 7, 2017 at 12:49 | comment | added | Scott Hodgin - Retired | Actually, you don't need a FULL backup to re-establish the log-chain. According to Paul Randal, (sqlskills.com/blogs/paul/…) You can restart the log backup chain with either a full or differential backup – anything that bridges the LSN gap from the point at which the log backup chain was broken. | |
| Feb 7, 2017 at 12:43 | history | answered | Gareth Lyons | CC BY-SA 3.0 |