Método de desligamento do Oracle

9

O encerramento de um banco de dados antes de fazer uma atualização ou um patch pode ser feito de várias maneiras.

shutdown immediate;

ou

shutdown abort;
startup restrict;
shutdown immediate;

ou

shutdown abort;
startup restrict;
shutdown;

ou

alter system checkpoint;
shutdown abort;
startup restrict;
shutdown immediate;

Claro que existem outras opções também. Qual deve ser preferido e por quê?

Leigh Riffel
fonte

Respostas:

12

O objetivo ao desligar para manutenção (ou backup a frio) é que o banco de dados seja mantido em um estado consistente, sem necessidade de reversão / recuperação na inicialização.

Existem 3 shutdowncomandos SQL * Plus que alcançam isso em teoria, os quais impedem imediatamente que novas sessões se conectem à instância:

  1. shutdown normalou apenas shutdown: espera que todas as sessões sejam desconectadas. Esse modo raramente é usado na prática porque depende de clientes bem comportados que não deixam as conexões abertas. Esse costumava ser o único shutdownmodo que não cancelava transações em execução.
  2. shutdown transactional: desconecta as sessões após a conclusão das transações atualmente em execução, impedindo o início de novas transações.
  3. shutdown immediate: desconecta todas as sessões imediatamente e reverte as transações interrompidas antes de desligar. Observe que as desconexões são imediatas, mas o encerramento pode não ocorrer, pois as transações interrompidas podem levar um tempo para serem revertidas.

O quarto modo de shutdowné shutdown abort. É como puxar o cabo de alimentação - a instância pára agora sem nenhuma limpeza. Você geralmente deseja ativar o banco de dados novamente depois e desligar imediatamente imediatamente, como no seu exemplo. O guia de conceitos diz :

Este modo é destinado a situações de emergência, como quando nenhuma outra forma de desligamento é bem-sucedida.

Todos os exemplos que você dá executar um posto de controle , como parte do shutdown [normal]ou shutdown immediatecheckpointing tão explícita é, presumivelmente, para reduzir o tempo necessário para a recuperação .

Conselho Geral:

  • Não use shutdown normal .
  • Use apenas shutdown transactional para desligamento assistido , quando desejar minimizar transações canceladas (assistidas apenas porque esse tipo de desligamento não é garantido para desligar o banco de dados se houver tempo limite excedido).
  • Usar shutdown immediate para desligamento automático ou quando você não se importa com as transações em execução no momento.
  • Não use shutdown abort(mais inicialização / desligamento), a menos que seja necessário - isso era mais comum nas versões anteriores do Oracle do que é hoje. Em outras situações (não em correção / atualização), se você precisar minimizar o tempo de inatividade, esse modo pode ser apropriado.
Jack diz que tenta topanswers.xyz
fonte
Você pode fornecer mais detalhes sobre as desvantagens de shutdown abort? Interpretando o antagonista, se podemos confiar na Oracle para se recuperar corretamente quando a energia é puxada, não deveríamos confiar nela durante a shutdown abort, principalmente se for mais rápido e vamos fazer imediatamente a startup restricte a shutdown immediate? Em outras palavras, existem fatos que podemos comprovar contra o terrível aviso da Oracle shutdown abort?
Leigh Riffel
@Leigh - O único perigo específico que conheço diz shutdown abortrespeito ao backup acidental de logs on-line, mas é apenas no caso de você não fazer um desligamento posterior posteriormente. Se você sabe o que você está fazendo eu acho que shutdown abortpode ser considerado perfeitamente seguro - e eu não tenho certeza se a contagem posição da Oracle como um "terrível aviso" ;-)
Jack diz tentativa topanswers.xyz
3

Eu prefiro o método de interrupção do desligamento , porque é a maneira mais rápida de derrubar um banco de dados. existem algumas operações que não podem ser realizadas após um cancelamento do desligamento, por exemplo

  • recrie o arquivo de controle do banco de dados com criar resetlogs de arquivo de controle (para renomear o banco de dados, renomear os arquivos de log ou renomear arquivos de dados)
  • altere o dbid com o procedimento de dbms_backup_restore (este foi o único método no 8i para alterar o dbid)

nos dois casos, o banco de dados foi danificado e deve ser restaurado a partir de um backup completo.

desde 9i, a renomeação do banco de dados ou a alteração do dbid podem ser feitas com o utilitário dbnewid . tanto quanto sei, o utilitário verifica se o banco de dados foi encerrado corretamente. renomear arquivos de dados, arquivos temporários e arquivos de log pode ser feito executando as instruções sql apropriadas sem recriar o arquivo de controle, é claro.

miracle173
fonte