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],
[counter_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],
[counter_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
https://docs.microsoft.com/en-us/sql/relational-databases/performance-monitor/sql-server-buffer-manager-object
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
ORDER BY [Total MBs] DESC
GO
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 - https://simplesqlserver.com/2013/08/19/fixing-page-life-expectancy-ple/
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.
&via=stc_network)
|
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..
|
