Esta semana me deparei com umas mensagens no alert log de uma base de dados, e vi que todas as vezes que precisavam parar a base de dados, era com o shutdown abort.

Toda vez que fazemos um shutdown abort, deixamos a base de dados em um modo inconsistente (non-rolled back).  

O shutdown abort, principalmente nas versões mais recentes, tem seu risco minimizado, no entanto, podemos tirar algumas informações para uma melhor decisão, como a quantidade de blocos que irá sofrer rollback após um novo start da base de dados.

Quando necessário, algumas medidas de prevenção, podem tornar o shutdown abort livre de problemas 🙂

1) Garantir que os backups estão em dia 🙂 !! just in case

2) Para determinar quantos blocos serão afetados pelo processo de rollback podemos consultar a v$transaction:

select sum(used_ublk) * <block size of the undo / rollback segment tablespace> from v$transaction;

3) Para acompanhar o trabalho do SMON no processo de recover, temos a query (em alguns casos costumo fazer startup restrict, até o SMON acabar os trabalhos):

select sum(distinct(ktuxesiz)) from x$ktuxe where ktuxecfl = ‘DEAD’;

Para mais detalhes, ou pode-se ler a nota oficial da Oracle sobre o assunto: What Is The Fastest Way To Cleanly Shutdown An Oracle Database? [ID 386408.1]

Bom shutdown abort 😛