Fixing Page Life Expectancy (PLE)

SQL Server Page Life Expectancy (PLE)

SQL Server Page Life Expectancy (PLE) Counter key performance indicator for those DBAs looking at the overall health of their database instance.

Page life expectancy (PLE) -Indicates the number of seconds a page will stay in the buffer pool without references.

The recommended value of the PLE counter is (updated: minimum of) 300 seconds. I have seen on busy system this value to be as low as even 45 seconds and on unused system as high as 1250 seconds. Page Life Expectancy is the number of seconds a page will stay in the buffer pool without references. In simple words, if your page stays longer in the buffer pool (area of the memory cache) your PLE is higher, leading to higher performance as every time request comes there are chances it may find its data in the cache itself instead of going to the hard drive to read the data.

Some Important point to know about PLE, If you have a server with 64 GB of memory with 56 GB allocated to SQL Server, which means you’re reading about 56 GB of data from disk every 300 seconds. If you look at Page 36 of Troubleshooting SQL Server – A Guide for the Accidental DBA by Jonathan Kehayias and Ted Krueger you’ll see an actual scalable version of this; PLE should be 300 for every 4 GB of RAM on your server. That means for 64 GB of memory you should be looking at closer to 4,800 as what you should view as a critical point.

The reason you see 300 written everywhere is because we were limited by 32-bit servers for so long while at the same time SQL Server documentation was really being developed well.  Those servers could only have 4 GB of memory, thus making this number make sense as well as the Buffer Pool / 4 GB * 300 formula.  I’ll go so far as to say that you should be cautious of anything that doesn’t have a formula to it because our servers keep getting faster, our databases keep getting bigger, and static values…don’t.

Expert comment on PLE -
I'm suggesting is that you don't need to panic every time PLE counter. There isn't always going to be a problem to solve. I wouldn't have anything set up to alert on PLE.

You can find the value of the Page life expectancy (PLE) by running the following query.

Query 1-

SELECT [object_name],
[cntr_value] FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Manager%'
AND [counter_name] = 'Page life expectancy'

Query 2-

SELECT [object_name],
[cntr_value] FROM sys.dm_os_performance_counters
WHERE [counter_name] = 'Page life expectancy' --if multiple NUMA on a server should return multiple Nodes,
OR [counter_name] = 'Free list stalls/sec'  -- Number of requests per second that had to wait for a free page
OR [counter_name] = 'Lazy writes/sec' --Flushes of dirty pages before a checkpoint runs. 
OR [counter_name] = 'Buffer cache hit ratio' --percentage of pages found in the buffer cache without having to read from disk you want this ratio to be high
Order by [counter_name] DESC, [object_name];

Query 3-

--plan cache Life expectancy
SELECT sys.dm_exec_cached_plans.objtype AS [CacheType]
,    COUNT_BIG(*) AS [Total Plans]
,    SUM(CAST(sys.dm_exec_cached_plans.size_in_bytes AS DECIMAL(18, 2))) / 1024 / 1024 AS [Total MBs]
,   AVG(sys.dm_exec_cached_plans.usecounts) AS [Avg Use Count]
,   AVG (DATEDIFF(MINUTE, PH_Time.creation_time, (GETDATE()))) AS [Avg Age in Minutes]
FROM sys.dm_exec_cached_plans
left join (
            Select  plan_handle
            , Min (creation_time) as creation_time --A plan can have several unique related quiries, this gets just one time per plan
            from sys.dm_exec_query_stats
            group by plan_handle
            ) as PH_Time On sys.dm_exec_cached_plans.plan_handle = PH_Time.plan_handle
--left join sys.dm_exec_query_stats On sys.dm_exec_cached_plans.plan_handle = sys.dm_exec_query_stats.plan_handle
GROUP BY objtype

How to Fixing Page Life Expectancy (PLE)?
There are lists of ways you can trim down on the space you need.
1.     Drop Unused Indexes
2.     Merge Duplicate Indexes
3.     Use Your Indexes – SARGability
4.     Watch for Big Queries
5.     Look in Your Proc Cache for Opportunities
6.     Know What’s in Your Buffer Pool
7.     Index Maintenance – Defrag
8.     Index Maintenance – Statistics
9.     Purge Your Data
10.  Other
You can also check the more details to fixing Page Life Expectancy (PLE), using the below,

Reface link -

Index Searches
Number of index searches per second. These are used to start range scans and single index record fetches and to reposition an index.

Cause: In general the number of Index is recommended to be high. This means that more searches are being performed thru the use of indexes rather than full scans. This is preferable. However on large databases where the data is constantly changing, if this value starts to decrease and the full scan value starts to increase. It is possible that the statistics for the tables and indexes need to be updated.

Action: Update the statistics for the affected tables. Use Enterprise Manager to reschedule when statistics samples are updated. They may not be occurring frequently enough, or they may not be scheduled at all. In this case set 'auto update statistics' database option on all your databases.

Anil Singh is an author, tech blogger, and software programmer. Book writing, tech blogging is something do extra and Anil love doing it. For more detail, kindly refer to this link..

My Tech Blog -
My Books - Book 1 and Book 2 Powered by Blogger.