SQL 서버 온라인 도움말에 따르면 page life expectancy 카운터는 “페이지가 참조 없이 버퍼 풀에 있어야 하는 초 수” 라고 설명하고 있다. 즉, page life expectancy가 300초라면 해당 페이지에 대한 다른 참조작업이 없는 경우 버퍼 풀에서 디스크상으로 제거되기 전에 적어도 5분 동안은 버퍼 풀의 메모리상에 존재할 수 있는 상태를 의미한다.

Page life expectancy 카운터는 서버상에 메모리 압박 상황이 발생하고 있는지에 대해서 매우 정확한 보고를 해 주는 역할을 하기 때문에 현재 메모리상에 문제가 발생하고 있는지를 판단하는데 도움이 된다. 마이크로소프트에 따르면, page life expectancy 카운터의 값은 적어도 300초는 되어야 한다고 한다. 만약 버퍼 풀에서 페이지가 300초가 안되어 제거된다면 메모리상의 문제가 발생하고 있다고 할 수 있다. page life expectancy 카운터가 300초 이상인지 이하 인지만 단순하게 점검해 보면 되기 때문에 메모리 문제가 발생하고 있는지를 손쉽게 파악할 수 있다. 예를 들어 고객으로부터 “메모리를 증설할 필요가 있나?” 라는 질문을 받았는데 고객 시스템의 page life expectancy 카운터 값을 점검한 결과, 그 값이 300초 이하로 떨어지지 않는 경우라면 메모리를 아무리 증설 하더라도 성능에는 아무런 개선이 되지 않는다. 만약 다른 고객으로부터 동일한 질문을 받았는데 해당 시스템의 평균 page life expectancy 카운터 값이 10에서 50초라면 쿼리가 왜 그렇게 늦게 실행 되는지에 대해서 충분하게 이유를 설명해 줄 수 있을 것이다.

실제로 많은 회사에서 명확한 근거 없이 메모리를 추가하는 것은 성능향상에 그리 많은 도움이 되지 못하는 상황을 자주 볼 수 있다. page life expectancy 카운터 값이 지속적으로 낮은 상태로 나타나는 상황에서는 메모리를 추가하는 것이 제대로 된 해결책은 아니다. 메모리 압박현상은 대부분 비효율적인 쿼리계획 때문에 발생하게 된다. 예를 들어 page life expectancy 카운터 값이 50초 정도이고 서버에 150만 정도의 논리적 읽기 작업을 하는 select 쿼리를 실행하는 경우를 생각해 볼 수 있다. 또한 극심한 예로는 700MB의 메모리가 설치된 서버에서 11.5GB의 논리적 읽기작업을 수행하는 경우도 있다. 서버상에 메모리를 추가하기 보다는 합리적인 인덱스 전략을 수립하면 문제가 되는 논리적 읽기작업을 획기적으로 줄여줄 수 있으며 이 방법이 전체적인 성능향상에 더 도움이 될 수 있다.

메모리 압박이란 물리적인 메모리를 추가해야 한다는 것을 의미하는 것만은 아니다. 오히려 현재 작업부하를 처리하기에 충분한 메모리가 없다는 것을 의미한다고 할 수 있다. 그렇기 때문에 150만 논리적 읽기를 발생시키는 쿼리를 좀 더 합리적인 인덱스 전략을 기준으로 튜닝 하게 되면 충분한 메모리의 가용량을 확보 할 수 있다. page life expectancy 카운터가 높은 수치로 나타나는 상황에서는 메모리를 증설한다고 해도 성능상에 개선이 되지 않는다는 사실을 명확하게 알아둘 필요가 있다.