Performance issues in FULL recovery model?

Question

Performance issues in FULL recovery model?

Ashif Shaikh

Default port

Points: 1445
More actions
April 30, 2014 at 7:05 am

#288362

Hi Experts,
Just wanted to know whether there would any kind of Performance issues if I change the recovery model from Simple to Full.
Regards,
🙂

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 1

Recovery model has nothing to do with performance. It's about recoverability.

If you need to be able to restore a DB to point-in-time, you need to be able to restore to point-of-failure, then you need full recovery and log backups. If restoring to the last full backup in the case of a disaster is acceptable, then simple recovery is probably fine.

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

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Ashif Shaikh Default port Points: 1445 More actions · Answer 2

Thanks just wanted to confirm as the end users usually complain for slowness when the DB is in FULL mode.

:-):-):-)

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 3

Users will complain, that's the steady-state of the universe.

Identify the actual cause of the performance problem and work on fixing that. Then the users might stop complaining for a nanosecond or two. 🙂

This may be worth a read:

https://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server,-part-1/

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

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Beatrix Kiddo SSC-Dedicated Points: 32407 More actions · Answer 4

[CaptainObvious]Don't forget to back up your transaction log if you do[/CaptainObvious] :-D.

Grant Fritchey SSC Guru Points: 398880 More actions · Answer 5

There is a tiny impact on performance because you're using resources to backup the logs. But it's really tiny. If you're already at 99% resource usage, adding this might be an issue. But the answer is not to skip the ability to do a point in time recovery, the answer is to address why you're using 99% of your resources.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

Luis Cazares SSC Guru Points: 183706 More actions · Answer 6

Grant Fritchey (4/30/2014)
There is a tiny impact on performance because you're using resources to backup the logs. But it's really tiny. If you're already at 99% resource usage, adding this might be an issue. But the answer is not to skip the ability to do a point in time recovery, the answer is to address why you're using 99% of your resources.

Unless you're not doing log backups, the logs are constantly growing and no one cares about PIT recovery. Sounds nuts, but I've seen it.:hehe:

Luis C.
General Disclaimer:
Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

How to post data/code on a forum to get the best help: Option 1 / Option 2

Grant Fritchey SSC Guru Points: 398880 More actions · Answer 7

Luis Cazares (4/30/2014)
Unless you're not doing log backups, the logs are constantly growing and no one cares about PIT recovery. Sounds nuts, but I've seen it.:hehe:

Until all performance stops because the drive is full. Oh yeah, I've seen it too.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

irabufan SSC-Addicted Points: 479 More actions · Answer 8

Is there any bulk-load operation(s) occurring in the database?

pooyan_pdm Hall of Fame Points: 3007 More actions · Answer 9

well, in some cases it could have some performance impact depending on the workload, disk subsystem,...assuming you've also set the log backup jobs on your databases, but this doesn't mean you should set the recovery model to simple to improve performance , in rare cases that could be an option though.

Pooyan

Luis Cazares SSC Guru Points: 183706 More actions · Answer 10

pooyan_pdm (4/30/2014)
well, in some cases it could have some performance impact depending on the workload, disk subsystem,...assuming you've also set the log backup jobs on your databases, but this doesn't mean you should set the recovery model to simple to improve performance , in rare cases that could be an option though.

I don't agree. Recovery models shouldn't be defined by performance. The only thing that should define a recovery model is a disaster recovery strategy (and certain operations that may need a temporary change of the recovery model).

Luis C.
General Disclaimer:
Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

How to post data/code on a forum to get the best help: Option 1 / Option 2

Grant Fritchey SSC Guru Points: 398880 More actions · Answer 11

Luis Cazares (4/30/2014)
pooyan_pdm (4/30/2014)
well, in some cases it could have some performance impact depending on the workload, disk subsystem,...assuming you've also set the log backup jobs on your databases, but this doesn't mean you should set the recovery model to simple to improve performance , in rare cases that could be an option though.
I don't agree. Recovery models shouldn't be defined by performance. The only thing that should define a recovery model is a disaster recovery strategy (and certain operations that may need a temporary change of the recovery model).

I agree. It's not a free operation, but the impact is so miniscule I think you'd be hard pressed to get a meaningful measure through all the noise of normal operations. Recovery should drive the recovery model. Period. I posted earlier just to point out that it wasn't zero cost (may have been a mistake).

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

pooyan_pdm Hall of Fame Points: 3007 More actions · Answer 12

I said in rare situations this could be an option . The environment I'm dealing with handles more than 35000 transactions /sec and even though we're using memory flash cards to store the data the performance difference was noticeable,and of course it comes with possibility of loosing data, in our case if we loose some data it's not the end of the world.

Pooyan

Ashif Shaikh Default port Points: 1445 More actions · Answer 13

thanks all for the valuable information,,,

:-):-):-):-):-):-):-):-):-):-):-):-):-):-):-)

bbr SSChasing Mays Points: 613 More actions · Answer 14

I find that often these "Full Recovery is slower" complaints can be traced back to improperly configured or maintained systems. Often the transaction logs either are not placed in proper locations (as in isolated form data), they are not sized to avoid auto-grow, or they are not regularly backed up, or some combination of all 3. Quite often I find this auto-grow to be a the heart of the performance complaints.

After all, SQL still works the same regardless of the recovery method. Contrary to a common belief, "Simple Recovery" does not "turn off" the transaction log. It simply changes when the transaction log is truncated. In earlier SQL version, this setting was called "Truncate on Check-Point". When was a much better description of what it actually does.