RECUPERAçÃO PARALELA GEOMETRIA | PDF | Triângulo | Geometria Elementar
O que realmente é recuperação paralela
A recuperação paralela é um mecanismo onde múltiplos processos ou threads trabalham simultaneamente para aplicar logs de transações durante a restauração de um banco de dados ou sistema. Em vez de um único processo sequencial processar redo logs um por um, o trabalho é dividido em lotes e processado ao mesmo tempo por vários canais. Isso reduz drasticamente o tempo de recuperação em sistemas com múltiplos CPUs e discos separados.
o que é recuperação paralela no contexto prático
No Oracle Database, por exemplo, a recuperação paralela é controlada pelas variáveis PARALLEL_MAX_SERVERS e PARALLEL_FORCE_LOCAL. Quando você inicia uma instância após uma falha de mídia ou precisa recuperar um tablespace a quente, o PMON e o CNTO (coordinator) distribuem os blocos de log entre processadores de recuperação dedicados. Cada um lê seu trecho do redo log e aplica às estruturas de dados correspondentes no cache de buffer. O resultado é que uma recuperação que levaria 45 minutos em modo single-thread pode terminar em 8 a 12 minutos com oito canais paralelos, dependendo da configuração de I/O.
Já no PostgreSQL, o conceito é diferente mas chega no mesmo lugar. A parallel WAL replay usa múltiplos workers para processar WAL segments simultaneamente durante o recovery. A partir da versão 14, o padrão é habilitado automaticamente quando há múltiplos núcleos disponíveis, e você vê o worker recovery aparecendo no pg_stat_progress_recover.
Um problema real que eu encontrei recentemente foi com um banco Oracle 19c em ambiente Exadata onde a recuperação paralela travava em deadlock entre os canais quando o disk group tinha um ASM rebalance rodando junto. O sintoma era a instância ficar parada no estado MOUNT por mais de duas horas sem aplicar redo, enquanto os alert logs mostravam "ORA-00600: internal error code, arguments [kcratr_scan_lostwrt]". A solução foi desligar o ASM auto-tune, configurar PARALLEL_MAX_SERVERS para um valor fixo de 16 (o padrão dinâmico causava overshoot), e rodar a recuperação com apenas dois canais ativos usando ALTER DATABASE RECOVER PARALLELISM 2. Sim, é contra-intuitivo usar menos paralelismo, mas nesse caso específico cada canal adicional estava competindo pelos mesmos disk groups e gerando mais contenção do que throughput.
Limitações e cenários onde isso não funciona
Recuperação paralela não é bala de prata. Ela depende fortemente de I/O paralelo real. Se seus datafiles estão todos no mesmo disco físico ou no mesmo LUN, a paralelização só vai aumentar a contenção de semaphore e provavelmente piorar o tempo. Já vi casos onde a recuperação sequencial era mais rápida porque evitava o overhead de scheduling entre processos.
Outro ponto que pouca gente menciona: em ambientes com backup sets comprimidos ou criptografados, a descompressão e decodificação muitas vezes acontecem no processo principal antes do paralelo, então o ganho fica limitado a 30-40% no máximo, independente de quantos canais você configurar. Não adianta jogar 64 processos paralelos se o gargalo está na CPU de descompressão.
Para sistemas de arquivo como XFS ou ZFS com stripped volumes, o ganho é significativamente melhor. Aqui a recomendação prática é começar com um número de canais igual à metade dos núcleos disponíveis e testar. Multiplicar por dois ou quatro raramente traz melhoria proporcional e aumenta o risco de instabilidade durante a recuperação.
