Q: Como funciona o hint Parallel Uma das primeiras coisas que vejo uma galera sugerir pra aumentar a performance de uma query no Oracle é o uso do hint Parallel. Quais os benefícios/riscos que o uso desse hint pode trazer, posso ter problemas com concorrência?

A: A hint parallel divide as instruções internas feita pelo db pela quantidade de processadores / cores até o limite estabelecido por você e permitido na configuração do Oracle. Recomenda-se que essa hint em resultados com agregação - group by (sum(), min(), max(), etc), em queries que será feito full table scan. Os beneficios serão sempre a diminuição do tempo da query, e o principal risco é o consumo excessivo de recursos do servidor.

A: O Paralelismo, disponibilizado na versão Oracle Database Enterprise Edition, oferece a ideia de se quebrar uma tarefa em partes para que, em vez de um único processo fazer todo o trabalho, muitos processos possam executar simultaneamente as partes e no final apresentar um resultado único em menos tempo do que o executado por um único processo.
Quando uma consulta SQL é executada em paralelo, cria-se um processo chamado Query Coordinator (QC) e vários outros processos Queries Slaves, chamados Pn, Onde n varia de acordo com o número de paralelismo indicado no comando.
Por exemplo, quando utilizamos o hint /*+ parallel (P,4) */, estamos criando um processo QC e os slaves: P1, P2, P3 e P4.
Temos o funcionamento de uma parallel query tomando como ponto de partida a consulta:
select /*+ paralel (e, 4) */ from emp order by ename ;

Representado pela figura:

O Query Coordinator (QC) é responsável por coordenar a execução do Queries Slaves, reunir as informações recebidas por cada processo slave e apresentar o conjunto de resultados para o usuário que enviou a consulta SQL.
Os Queries Slaves são os verdadeiros responsáveis pela coleta dos dados da consulta SQL em si. Quando Queries Slaves terminam a leitura dos dados,estes enviam esses dados para o QC através de mensagens de buffer.
Essas mensagens têm seu tamanho especificado pelo parâmetro parallel_execution_message_size e são trocadas em uma área específica de buffer.
O parâmetro parallel_automatic_tuning define o lugar deste buffer de mensagens.
Se o parâmetro estiver setado para TRUE, o buffer será utilizado na large pool, se estiver setado para FALSE a área de memória utilizada será a shared pool. Portanto, é recomendado que se o banco de dados executa muitas consultas paralelas, estudar um tamanho apropriado para esta área de memória e, além disso, configurar valores mínimos para estas áreas de memória.
Isso demonstra que a utilização de paralelismo em SQLs deve ser alinhada com o DBA e bem testada, para que os parâmetros de memória sejam configurados de forma coerente.
Outro ponto importante a ser mencionado é que a abertura de vários processos paralelos em um SQL ocasiona lentidão também na própria abertura dos processos.
Benefícios:
A execução paralela proporciona melhorias no desempenho mediante a utilização otimizada dos recursos de hardware do servidor, ou seja, podemos utilizar todas as CPUs de um servidor em uma única atividade o que proporcionaria um ganho significativo no processo, por exemplo. Esta mesma distribuição pode ser realizada em um ambiente clusterizado (RAC), onde podemos utilizar, se necessário, os recursos de todos os nodes para uma única tarefa/processo.
Riscos 
Devemos sempre ficar atentos ao consumo dos recursos do servidor como CPU, memória e discos, pois o paralelismo pode saturar completamente uma máquina, ficando então a cargo do DBA equilibrar cuidadosamente o número de pessoas que executam operações paralelas quanto o grau do paralelismo utilizado para que os recursos do servidor não sejam esgotados. 
Sobre Problemas com concorrência, prefiro não explicar nessa resposta, visto que nessa pergunta "É sempre garantido que uma aplicação com múltiplas threads rode mais rápido que usando uma única thread?", a resposta do Maniero, explicar a concorrência de uma forma bem interessante.
Recomendação de leitura:
O que é uma condição de corrida?
Bibliografia: 
GRAF, Anderson. Execução paralela de instruções SQL: Parallel Query, DML e DDL.  Acesso em:  01 agosto 2017.
FIAMENGUI, José Eduardo. Paralelismo: Mitos e Fatos.  Acesso em:  01 agosto 2017.
