monOpenObjectActivity - Handy Stats...

There are a lot of handy MDAs around in ASE.  This one is real fun.  It allows you have a sneak view into the guts of your ASE workload, on per-object resolution.

I'd like to share some insights and challenge you to fill the gaps.

First, let's take a look at a sample data (15.7 SP134 - trimmed to counters I want to discuss):

What can we see from these two consecutive snapshots of data?

TableA has been:

accessed about 1k times (UsedCount = Total number of DMLs + Scans on the Object).  Here it is probably Scans only, no DML.

access has been done by the optimizer ~50 times exclusively through the table primary key ( OptSelectCount = Object Selected for Plan by Optimizer)

these 1k accesses resulted in close to 1m total operations on the table (Operations = Object Accesses).

it has resulted in LogicalReads only - mostly retrieved through PK, with a small portion descending to data pages level (IxID 2 + 0).

pretty few lock requests (around 800).

So far so good.  So good?  Hm.  If the table has been accessed for ~1000 DMLs/SCANs - how can it be that optimizer selected it only 50 times?  Plan reuse for SPs?  Possible.  If the table has been accessed about 1k times, generating about 1k lock requests, what are those 1m operations that run against the table?  I found it confusing...  Any help?

What about another table:

TableB has been:

accessed about 100k times (UsedCount = Total number of DMLs + Scans on the Object).  Here it is probably Scans only, no DML.

access has been done by the optimizer ~1k times through several table keys and possible table scans ( OptSelectCount = Object Selected for Plan by Optimizer)

these 100k accesses resulted in 300 k total operations on the table (Operations = Object Accesses).

it has resulted in LogicalReads & PhysicalReads - retrieved through PK and one of non-clustered indices (AKx), with a small portion descending to data pages level (IxID 8, 11 + 0).

pretty few lock requests (around 8k).

These values are more easy to interpret:

The table has been accessed in read operations, mostly through its indices, but also table scanned (OptSelect>0, indexID=0,APF>0).

Still, Operations vs UsedCount is moot and APFReads vs PagesRead is moot.  Any explanation?

TableC has been:

accessed about 200 times by DMLs (update + insert, may be some scans too) (UsedCount = Total number of DMLs + Scans on the Object). 

access has been done by the optimizer ~1k times involving all table keys and table data ( OptSelectCount = Object Selected for Plan by Optimizer)

these DMLs resulted in 1m total operations on the table - distributed across various table keys and data pages (Operations = Object Accesses).

it has resulted in inserts/updates across all of the indices, generated locks and lock contention.

Here values are too tempting.  Again, probably some table scans resulting in physical io to get to the table - may be as a part of update dml itself.  DML resulting in each table index being updated.  Operations for the same access (DML) multiplied by the changes to each index (makes sense).  But - OptSelectCount higher than UsedCount?  For SP/LWP call, UsedCount may be higher than OptSelectCount (plan reuse).  When it is vice versa?  1K APF Reads with puny 30 PagesRead?  Confusing again.

Now, it is true that the table may be used to get a general idea as to which object is used in what way in your ASE - if there are table scans, physcial read, excessive logical reads.  To create a object heat map for the server, so to say.  But the data in the table on close inspection becomes very confusing.

I've done a test (on ASE 16 SP01) to see if going slowly rather than plunging into a busy ASE makes it easier to understand what's going on in this table.

Here is the test:

I won't walk through all steps, but you may easily see that here (ASE16) too are things that start to confuse:

Operations on PK and DATA seem to be repeated (non found in real life - not  in 15.7)

OptSelectCount stays zero for operations that result in table scan (based on showplan).

Insert operation populating the table which definitely affect all its indices does not change the Operation counter for all.

Did anyone tried to read this table in detail?  How safe-proof are the assumption made base on the data displayed in it?  I wish SAP would produce more documentation on MDAs.  Numbers in it are really cute...

Would appreciate some insights.

Thank you,

Andrew