People coming to SQL Server from a DB2 background may consider PLE to be a significant metric. But on DB2 the DBA can create multiple buffer pools and assign objects to a specific pool.
I remember back in the late 90s on DB2 setting up a small pool dedicated to lookup tables, another for the big sequentially-read beasties, with a third pool for the rest. PLE for the lookup pool was typically over an hour, with almost 10% of logical reads needing under 2% physical reads. The beastie pool had very low PLE as the tables in it mainly had start-to-end sequential reads and would never fit well into memory. In this one a logical read often resulted in a physical read, but pre-fetch kept response times acceptable. The third pool behaved much the same as any SQL Server buffer pool.
The main reason for saying this is to make the point that a single buffer pool cannot give a good PLE for every object that might be in it. Most organisations will have the big beasties that flood the pool and lower PLE and cause high-use lookup tables to be re-read. A good PLE for one object is a sub-optimum PLE for another.
A consistantly low PLE can be a sign that the server will benefit from more memory, but a variable PLE can be a sign that life is proceeding normally. The key to knowing if your PLE is right for you is to know your data, know your performance, and know your SLAs.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara