ORACLE Parallelism

When creating and rebuilding indexes, we can use parallel to speed up the operation if the CPU allows, but long-term parallelism will seriously affect server performance.
For an OLTP type database, unless it is only used for tables or indexes of statistics and reports, it is recommended not to adjust the parallelism of related tables or indexes.
During parallel processing, Oracle will start how many parallel processes to execute tasks at the same time. The higher the degree of parallelism, the more parallel processes and the faster the execution speed. The default is noparallel. If we set the degree of parallelism to the default value, then the The degree of parallelism is: the number of server CPUs * the number of threads enabled per CPU (PARALLEL_THREADS_PER_CPU) The
empirical value is 4 U corresponding to one parallel.
So generally we recommend to use Noparallel, or set the degree of parallelism to 1 instead of default; you can view the degree of parallelism of related objects through the degree field of the dba_tables and dba_indexes views.
[View parallel parameters]
SQL> show parameter PARALLEL_THREADS_PER_CPU


NAME TYPE VALUE
------------------------------------ - --------------------- ----------------------------- -
parallel_threads_per_cpu integer 2
SQL> show parameter parallel_max_servers

NAME TYPE VALUE
------------------------------------ ----------- ----------- ------------------------------
parallel_max_servers integer 20

A problem that many people ignore :
When we use parallelism to rebuild the index, after the rebuild is over, the parallelism of our index will also be changed to the parallelism of our rebuild, so we need to modify the index parallelism after the rebuild is over.
An example of code operation is as follows: [create index on parallel and then turn off parallel]
SQL> create table dave(object_id int,name varchar2(20));

Table created.

SQL> create index idx_dave_id on dave(object_id);

Index created.

SQL> select degree from all_indexes where index_name='IDX_DAVE_ID';

DEGREE
------------
1

SQL> alter index idx_dave_id rebuild parallel 4; (rebuild indexes in parallel)

Index altered.

SQL> select degree from all_indexes where index_name='IDX_DAVE_ID';

DEGREE
------------
4

SQL> alter index idx_dave_id noparallel; (close parallelism after index reconstruction is complete)

Index altered.

SQL> select degree from all_indexes where index_name='IDX_DAVE_ID';

DEGREE
------------
1

When using parallel processing, we can view related wait events through v$px_session:
SQL> select a.sql_id ,a.event,count(*)from v$session a,v$px_session b where a.sid=b.sid group by a.sql_id,a.event;

no rows selected

[modify the parallelism of the table] when setting the table When the degree of parallelism is very high, the SQL optimizer may perform a full table scan on the table, causing Direct Path Read to wait.
alter table t parallel(degree 1);------Directly specify the degree of parallelism of the
table alter table t parallel; ----------Set the degree of parallelism of the table to default

[Use parallelism in SQL statements (parallelism is set to 4)]
SELECT /*+ PARALLEL(4) */ MAX(sal),AVG(comm)FROM emp,dept WHERE emp.deptno=dept.deptno GROUP BY 1;

[Note] In parallel operation, parallel query and parallel DDL operation can be used in parallel by default, but if you want to use parallel DML, you need to modify the dml parallel configuration
alter session enable parallel dml;

[The scope of use of parallel query]
is applicable to:
Large table query, join, partition index query,
create a large number of indexes, create a
large number of tables (including solidified views),
batch insert, update, delete;
insufficient CPU utilization,
enough memory for other operations, sorting, hash, Caching,

not suitable for:
very short queries or transactions