Sorry for any confusion with that metric. The word “percentage” is misleading, perhaps I should have used the word “ratio” instead (yes, we all know that percentages are ratios as well ).

So, yeah, it’s page lookups per second over batch requests per second. The units cancel leaving us with page lookups per batch requests, as you noted.

The number 100 is just a line in the sand here, YMMV for your servers. I’d recommend you take a baseline to get an idea of what is normal for you. The idea is that if your batch is requiring many page lookups you likely have an inefficient query plan, or perhaps many ad-hoc queries (which will contribute to plan cache bloat).

HTH

For example, I don’t know how this metric is a percentage. And I’m not sure how this metric ties says anything about plan cache bloat.

Based on the query, the metric looks like it could be called “Page lookups per batch request” which could indicate memory caused by plan cache bloat (but maybe there are other causes?).

Oh, thanks for that. I should have specified that these scripts were for SQL 2008. I don’t believe I tested them on SQL 2012. I’ll have to go back and update them, thanks!