The documentation describes the Writes By APW value as being the percentage of database blocks written to disk by the APW; this is a percentage of the total number of database blocks written by the database engine.
However the Writes By APW % metric in itself is not overly useful.
The storage management and I/O architecture is such that any process (a few utilities excepted) that is connected to a database may find a need to write a block from shared memory to the on-disk data extents. Even a proutil dbanalysis may have to write something. Generally, it is undesirable for a self-serving client or a server acting behalf of a network client to have to write modified database blocks to disk. It is undesirable because we want to do as much useful work as possible on behalf of the clients and the applications they are executing. Even though they can't be avoided and we try to minimize that as much we can, we might consider database writes to be an overhead.
The purpose of the APW's is to write modified database blocks back to disk as a background activity, relieving the servers and the self-serving clients of that task. But there are rules for the buffer replacement policy, how writing has to be performed so that we can maintain the so-called "ACID" transaction properties, and so that before-image log space can be reused, and other things. The APW's do not do all the data block writing even when things are operating normally. For example, when a self-serving client needs a data block that is not resident in memory, it has to bring it in from disk. If the buffer it chooses to store the new block has been modified, it may write the modified buffer to disk. When a server has a bi note to write, it may find that the current bi cluster is full and has to be closed so a new one can be opened. This may cause some modified blocks to be written by the server.
The best metric to use to determine whether the page writers are being effective is the "Buffers flushed" value that is reported in several places by PROMON and in VST tables. When this number is consistently larger than a few, it means database writes are not keeping up with demand. During the flush operation no database changes or transaction state changes can be performed. When it takes too long, users perceive a temporary "freeze" in their application. One or two writes take just a few milliseconds but thousands can take a minute or more.
A problem that production sites sometimes experience is that the storage devices they are using do not have sufficient write bandwidth to handle the load placed on them by the application and the database. So when the disks are 100% busy, or close to it, then the page writers fall behind, resulting in buffers flushed. Adding more page writers will not help in such a case.
To sum up, the percentage of writes by APW's by itself is not all that useful because it cannot be used as a predictor of anything. A low number is not always a cause for concern, and a low number does not mean the APWs are not working. At best it is a clue that suggests you should investigate further and look at other things.
