Whether with manual DOP or with Auto DOP, the runtime DOP of a statement is not always the same as the requested DOP. There are several reasons for this like hitting the maximum number of parallel execution (PX) servers allowed, hitting the DOP limit set by the resource manager, etc...
To find about why a specific statement's DOP got downgraded you can use the SQL Monitor reports in 12.1. SQL Monitor shows the DOP downgrade in the General section as a people icon with a red down-pointing arrow, when you hover over that icon you can see the actual DOP, the downgrade percentage, the number of PX servers requested, and the number of PX servers allocated, like below.
To find out the reason for the downgrade you can click the binocular icon in the OTHER column in the PX COORDINATOR line.
That shows you the actual DOP after the downgrade and the reason for the downgrade (as a cryptic code obviously) like below.
Here is the list of possible reasons and their number codes as of 12.1.
350 DOP downgrade due to adaptive DOP
351 DOP downgrade due to resource manager max DOP
352 DOP downgrade due to insufficient number of processes
353 DOP downgrade because slaves failed to join
You can look at an example SQL Monitor report showing this here.
We plan to provide this information in an easy to reach section of SQL Monitor in human readable format in a future release.