Why the parallel hint is not working in oracle 19c

Question

SELECT /*+PARALLEL 8*/
        A.ACC_ID,
         COALESCE (B.PR_ID, NULL),
         COALESCE (B.DESC, NULL),
         COALESCE (B.CNT, 0)
    FROM (SELECT ACC_ID
            FROM ACC_ID_IN
           WHERE XXX = 1 AND YYY = 'ABCD') A
         LEFT OUTER JOIN
         (  SELECT /*+PARALLEL 8*/
                  A.ACC_ID,
                   B.PR_ID,
                   B.DESC,
                   COUNT (DISTINCT A.ACC_NBR) CNT
              FROM DB1.TABLE1 A,
                   TABLE2  B,
                   TABLE3  C
                   WHERE A.ACC_ID IN (8888888888)
                   AND A.P_ID = B.P_ID
                   AND A.P_ID = C.P_ID
                   AND A.START <=TO_DATE (SUBSTR (A.ACC_ID, 1, 4) || '1231','YYYY/MM/DD')
                   AND A.END > TO_DATE (SUBSTR (A.ACC_ID, 1, 4) || '1230','YYYY/MM/DD')
          GROUP BY A.ACC_ID, B.PR_ID, B.DESC
          ORDER BY A.ACC_ID, B.PR_ID, B.DESC) B
             ON A.ACC_ID = B.ACC_ID
   WHERE A.ACC_ID IN (8888888888)
GROUP BY A.ACC_ID,
         COALESCE (B.PR_ID, NULL),
         COALESCE (B.DESC, NULL),
         COALESCE (B.CNT, 0)

The above query with parallel hints taking very long time to execute where as same query executed in secs when I removed the parallel hints. This issue observed when oracle is upgraded to 19c. Could you please help me to understand what's happening here and do I need to perform any settings to enable parallel hints as part of DB upgrade activity.

Answer 1

Parallelism is tricky and there are many reasons why the degree of parallelism can be unexpected. Below are potential issues with your query, some of which others mentioned in comments:

1. Do you even want parallelism for such a fast query? Parallelism works harder, not smarter, so you generally only want to use it on large objects that take a long time to process. If the query runs in seconds without parallelism, it's probably not a good candidate for parallelism in the first place.

2. Statement level hints The /*+ PARALLEL */ hint at the top of the query applies to the whole statement, so you don't need to also add hints to other query blocks.

3. Incorrect hint format If you want to specify the degree of parallelism, you need to use parentheses around the number, like /*+ PARALLEL(8) */ . Without the parentheses, Oracle will compute the degree of parallelism. I can't even remember all of the rules and details, but if you ask Oracle to generate the DOP for you, it will often times use CPU_COUNT * PARALLEL_THREADS_PER_CPU * NUMBER_OF_INSTANCES .

4. CPU_COUNT Since you've just upgraded, check if the CPU_COUNT was changed. On some platforms, such as Solaris, Oracle counts every virtual processor as a CPU, and then still multiplies it by PARALLEL_THREADS_PER_CPU , which can lead to ridiculous numbers. Although that parameter seems like something you wouldn't touch, I've shrunk the CPU_COUNT on many systems with good results. Run the below query to look at the most relevant parallel parameters.

    select * from v$parameter where name in ('cpu_count', 'parallel_threads_per_cpu', 'parallel_degree_policy', 'parallel_degree_limit');

5. Find the Degree of Parallelism There are several ways to find the DOP and to find information on why the DOP was chosen. In 19c, the "Note" and "Hint Report" section of the explain plan can give detailed information on how the DOP was calculated. Use explain plan for select ... and then select * from table(dbms_xplan.display); to find that information. As astentx suggested, select dbms_sqltune.report_sql_monitor('&SQL_ID') from dual can also be a great help with long-running queries.

Answer 2

Instead of providing hint to the entire query - You can specify to a driving table.

/*+ parallel(A,8) */

and then produce a explain plan and see the DOP was in place or not.