We *try* to sort stuff in memory (because obviously thats the most efficient means of doing so). This is called an "optimal" sort (ie, in memory)
If we can't, then we will *still* use memory, but because we can't sort the entire set, we sort a chunk of it, and then dump that to disk. Then we sort the next chunk, and so forth.
Now we have 'n' sorted chunks on disk - we then read them and merge the results to provide a single sorted result. This is called a 1-pass sort, ie, we had to pass through the result on disk once.
Sometimes the data to be sorted is so large, than when we come to merge the sorted chunks, we have to dump a merged chunk back down to disk. We'll then come back later and so *another* merge operation. This is called a multi-pass sort, and is obviously the slowest.
The "sorts (disk)" reflects the latter two, but you can see more granular detail in some of the performance views, eg
SQL> desc V$SQL_WORKAREA
Name Null? Type
----------------------------------------------------------------------- -------- -----------------
ADDRESS RAW(8)
HASH_VALUE NUMBER
SQL_ID VARCHAR2(13)
CHILD_NUMBER NUMBER
WORKAREA_ADDRESS RAW(8)
OPERATION_TYPE VARCHAR2(40)
OPERATION_ID NUMBER
POLICY VARCHAR2(10)
ESTIMATED_OPTIMAL_SIZE NUMBER
ESTIMATED_ONEPASS_SIZE NUMBER
LAST_MEMORY_USED NUMBER
LAST_EXECUTION VARCHAR2(10)
LAST_DEGREE NUMBER
TOTAL_EXECUTIONS NUMBER
OPTIMAL_EXECUTIONS NUMBER
ONEPASS_EXECUTIONS NUMBER
MULTIPASSES_EXECUTIONS NUMBER
ACTIVE_TIME NUMBER
MAX_TEMPSEG_SIZE NUMBER
LAST_TEMPSEG_SIZE NUMBER
CON_ID NUMBER
Hash areas are not dissimilar - we put results of the hash in memory if we can, otherwise we'll dump chunks out to disk as we go.