March 30, 2016 at 6:48 am
I realize our internal BI guys are writting procs that need to be optimized. I've identified the high logical ready processes and plan on optimizing them. In the mean time would you suggest implimenting buffer pool extensions?
March 30, 2016 at 11:42 am
You can.
I wouldn't necessarily base it on PLE though. What kind of wait statistics are you seeing?
"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
March 30, 2016 at 12:07 pm
Snargables (3/30/2016)
I realize our internal BI guys are writting procs that need to be optimized. I've identified the high logical ready processes and plan on optimizing them. In the mean time would you suggest implimenting buffer pool extensions?
I agree with Grant.
I'll also state that's a bit like putting a band aid on a stab wound. It'll make a lot of people not think there's still a problem and you'd have to find and prove another indication that you may have a problem and the BI guys will never fix their code.
Don't tell the BI guys but PLE isn't necessarily an indication of a bad problem. Even backups can make PLE tank. Paul Randal has a good article on the subject. Fixing code that needs to be optimized will usually make PLE look better but things like Disk IO, Memory Blocks (blocks of memory used for a long term and not to be confused with "Blocking"), Cache hits, and CPU usage are much better indicators of need or success.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 2, 2016 at 12:08 pm
why not increase the physical memory instead or is this not possible
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply