How should CurrIO, CurrRead and CurrWrite be interpreted in V17?

[Breck_Carter]

Now that CurrIO (and the new CurrRead and CurrWrite properties) can be trusted in SQL Anywhere 17, it is natural to wonder why the following paragraph was removed from the Help...

SQL Anywhere Server - SQL Usage 
 » Performance improvements, diagnostics, and monitoring 
  » Performance monitoring and diagnostic tools 
   » Diagnostic tracing 
    » When hardware resources are a limiting factor

Detecting whether I/O bandwidth is a limiting factor

To detect whether I/O bandwidth is a limiting factor, check the CurrIO 
database statistic. If this statistic is not present on the graph, click 
the Add Statistics button and click CurrIO. Look for the largest 
sustained number for this statistic. For example, look for a high 
plateau on the graph; the wider it is, the more significant the impact. 
If the graph has sustained values equal to, or greater than 3 + the 
number of physical disks used by database server, it may indicate that 
the disk system cannot keep up with the level of database server activity.

In fact, the V17 Help contains no mention at all about how to interpret and act on CurrIO, CurrRead and CurrWrite values.

A simple test involving an indadequate cache implies that any value other than zero is a harbinger of doom... is that correct?

[Former Member]

Part of this would seem to be due to the focus changing away from the deprecated Tracing features and towards the new SQL Anywhere Database Profiler way of doing performance tuning.

You might also see similar documentation differences around the Server Monitor feature and the new SQL Anywhere Cockpit.

But do jump onto DCX and add any comments about any functionality you do find completely missing. There is always a chance we overlooked something in the reorganization.