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 😛
