Sorry late chiming in on this discussion, but this is not a straight forward question. First, on the topic of permissions and monitoring, all you need to be able to look at MDA data is mon_role. If you have that, then the rest is just a matter of baselining over several days/weeks.
The best metric of how much of a pool is used is to look at monCachePool. The key metrics there are PagesTouched and AllocatedKB. Okay, so the first problem is they have two different units - pages vs. KB - but you simply need to divide the PagesTouched by your server's pagesize to get the answer in KB. PagesTouched is one of the few counters in MDA that is a *current* value - meaning you don't have to do a delta between samples to get the actual value.
If PagesTouched/AllocatedKB <80%, I would start reducing the large IO pool.
BTW - PagesTouched doesn't work for log caches....they will always be "touched".... Sizing a log cache should take into consideration the number of PhysicalReads by the checkpoint process or on the log device itself - as well as any process that does a dump tran.
Now, then - how much of which table is in which buffer pool.....wellllll....you can't really tell that (unless you only have 1 buffer pool) and it likely can be fairly dynamic. monCachedObject does report cache consumption by table/index - but doesn't split it by pool. However, it is interesting to graph and see if there are sudden increases in cache consumption - which indicates that a lot of data had to be read - and possibly could use a large IO pool. It also is a good indication of cache volatility which is much better for cache tuning than simplistic cache hit rates.
One thing to remember, is that a large IO will not be used if 1 page (or more) of an extent is already in cache - so the sequence of queries could change where things are in cache from day to day. However a good place to look is monOpenObjectActivity. In earlier ASE's - at least there were columns tracking APFReads - but unlike the APFReads in monDeviceIO, the APFReads in monOpenObjectActivity included APF's satisfied from cache as well as physical reads....but it is more likely that APF's would hit a large IO, so you could probably compare APF's vs. LogicalReads and get a rough idea. Later versions of ASE (15.7 ESD #4 and higher I think) added columns such as IOSize1Page, IOSize2Pages, IOSize3Pages, and IOSize4Pages.....which would tell you precisely how many large reads (and writes) were done.
You also have to keep some other things in mind....APFs are not always large IO's, but large IOs are quite often due to APFs. APF's can be any size physical read and are issued when ASE knows it is going to need the next page (or set of pages) even before it reads the data. For example, on a standard B-tree index traversal, an APF makes no sense as the index node values will have to be evaluated to determine which branch to take. However, if a index leaf scan is being used - then ASE knows it can submit the APF's for all the index leaf pages.
Also remember that APF's are not always physical reads. Remember, the query optimizer considers how much data is in cache as a costing factor, but it doesn't know if the data will still be in cache at execution time - and if the specific rows (and if all the rows) necessary are in cache. So it may choose an APF strategy. Pages that are already in memory still may have an APF - but it will simply be found in cache.
One area that sp_sysmon has that MDA does not - is it does report how many APF's required physical IOs vs. satisfied from cache as well as why APF's were denied.
However, this also takes a bit of thinking. When is a large IO pool used????
1) APF reads for pool sized contiguous chunks from disk (note - APF's can be from memory or disk). This usually is due to a index leaf scan, a range scan or a table scan.
2) Certain DML operations (e.g. select/into will use a large IO pool to create the NEW table
3) Bulk load operations (e.g. minimally logged bcp, SQL merge inserts in 16.x)
4) Certain maintenance operations (e.g. update stats, reorg, dbcc, etc.)
In other words - not as much as you would think. For example, the last couple of days, I have been running a job to measure impact of various configs on create index in ASE 16 - I thought I would see a lot of large IOs (due to implied table scan necessary for most index creations) - but instead am seeing a lot more single page reads - on the order of 10's of millions of single page reads vs. 10's of thousands of large IOs.
Additionally, sometimes the presence of APF's indicates that there may be query issues - e.g. not so effective indexes or table scans. Rather than increasing the large IO pool size to accommodate them, it is better to find the queries and fix them. Of course, some queries legitimately need to read contiguous pages (e.g. index leaf scans and range scans), but ideally, we would like to minimize the number of rows scanned to just those necessary to materialize the result. Yes - it could be argued that increasing the large IO pool to help bad SQL will help speed things up - but often there is a price - and that price is less of other data in cache (as it will likely be using small IO pools due to single page reads) which means other queries will run slower. So, you need to balance the impact of tuning for someone's bad SQL (or bad indexing or bad QP processing) on other possibly more critical queries.