The answer to this one is difficult as well as simple. When I asked the reason to my client why they want to move to the Simple Recovery Model, their answer was that they have heard it is better for performance. Honestly, it is not true entirely. I have been doing consulting for over a decade and I have yet to see a single situation when we have changed the recovery model and it the server has performed miraculously well.
The Recovery model is directly connected with the data loss and secondary related to SQL Server features. There are few features of the SQL Server that are not possible when your model is set to Simple. Here is a list of the features which are not supported if you are using the Simple Recovery Model.
- Log shipping
- Always On
- Database mirroring
- Point-in-time restores
If you are going to use any of the features listed above, they are not supported by the Simple Recovery Model. Additionally, you should make the decision of using the recovery model on your work loss exposure and not on any other factor primarily.
Here are few recent blog posts where I have posted SQL in the Sixty Seconds videos.
- CONCAT and NULL – SQL in Sixty Seconds #123
- Sleeping vs Suspended Process – SQL in Sixty Seconds #122
- Pinned Tab – SSMS Efficiency Tip – SQL in Sixty Seconds #121
- Split Screen for SSMS Efficiency – SQL in Sixty Seconds #120
- Nonclustered Primary Key – SQL in Sixty Seconds #119
- Recent Execution of Stored Procedure – SQL in Sixty Seconds #118
- Full-Screen Execution Plan – SQL in Sixty Seconds #117
Reference: Pinal Dave (https://blog.sqlauthority.com)