Exibir Informações da Janela de Patch e Manutenção, Definir o Nível de Patch

Execute as seguintes etapas de pré-requisito conforme necessário:

• Abra a Console do Oracle Cloud Infrastructure clicando no ao lado da Nuvem.

• No menu de navegação esquerdo do Oracle Cloud Infrastructure, clique em Oracle Database e depois clique em Autonomous Database.

• Na página Autonomous Databases, selecione um Autonomous Database nos links na coluna Nome para exibição.

Para exibir o histórico de manutenção, faça o seguinte:

Exibir Nível de Patch de uma Instância do Autonomous Database

Na página de detalhes do Autonomous Database da Console do Oracle Cloud Infrastructure, você pode exibir o nível de patch da instância.

1. Na guia de informações do Autonomous Database, a área Manutenção mostra o nível de patch da instância. As opções são: regular e precoce.
2. Se quiser alterar o nível de patch, clique em Editar.

Consulte Definir o Nível de Patch para obter mais informações.

A view DBA_CLOUD_PATCH_INFO fornece informações de patch relacionadas a bugs reportados (esta é uma lista de bugs reportados por um cliente). Você pode usar essas informações para determinar se um bug relatado foi corrigido e para determinar a versão do patch em que a correção foi aplicada à sua instância do Autonomous Database. Se não houver bugs do cliente em um patch, o DBA_CLOUD_PATCH_INFO não incluirá nenhuma linha para esse patch.

Para exibir informações de patch para um patch específico, faça o seguinte:

Para exibir informações de patch para todos os patches disponíveis:

SELECT * FROM DBA_CLOUD_PATCH_INFO;

Observações para exibir informações de patch:

• A view DBA_CLOUD_PATCH_INFO está disponível para o usuário ADMIN.

• Informações sobre patches e detalhes sobre problemas resolvidos estão disponíveis a partir de ADBS-21.7.1.1 (a partir de julho de 2021).

• A view DBA_CLOUD_PATCH_INFO tem as seguintes colunas:

  BUG_NUM, BUG_TITLE, COMPONENT_NAME, PATCH_VERSION

Consulte Exibir Notificações de Status de Manutenção para obter detalhes sobre os patches aplicados durante a manutenção.

Quando você seleciona o nível de patch Anteriormente, os patches são aplicados à instância do Autonomous Database uma semana antes do patch programado Regular. O campo Próxima Manutenção na Console do Oracle Cloud Infrastructure reflete uma data e hora da janela de manutenção com base no nível de patch.

O nível de patch padrão para provisionar uma instância do Autonomous Database é Regular. O nível de patch padrão para clonagem é o nível de patch especificado para o banco de dados de origem.

O provisionamento ou a clonagem de uma instância e a definição do nível de patch como Antecipado permitem que você use e teste os próximos patches antes que eles sejam aplicados a todos os sistemas. A Oracle recomenda que você selecione o nível de patch Inicial para seus bancos de dados de desenvolvimento e teste se quiser testar os próximos patches antes que eles cheguem à produção. Você também pode testar suas cargas de trabalho usando o Oracle Real Application Testing para capturar uma carga de trabalho em um sistema de produção e reproduzi-la com o nível de patch Inicial. Consulte Testar Cargas de Trabalho com o Oracle Real Application Testing para obter mais informações.

Para alterar o nível de patch de um Autonomous Database existente, faça o seguinte:

1. Na página Detalhes do Autonomous Database, em Manutenção, no campo Nível do patch, clique em Editar.
   Observação
   
   O botão Editar pode ser desativado nas seguintes circunstâncias:

   • Se o nível de patch antecipado não estiver disponível na sua região para a versão do banco de dados.
   • Se o seu banco de dados tiver o Autonomous Data Guard ativado.
   • Se o seu banco de dados estiver no nível de patch antecipado e não for viável movê-lo para o nível de patch regular. Nesse caso, tente novamente após a próxima janela de manutenção.
2. Selecione o nível de patch, Regular ou Anteriormente e clique em Submeter.

   O tempo necessário para alterar o nível de patch depende do tamanho do seu banco de dados. Você pode ver breves quedas de conexão durante este tempo.

Reportando Problemas de Patch ao Oracle Support

Quando você reporta um problema para um banco de dados de nível de patch Inicial, o Suporte Técnico da Oracle toma as ações necessárias para impedir que o problema se propague para bancos de dados de nível de patch Regular. Alguns exemplos das ações possíveis são:

• O patch que causou o problema é removido antes que os bancos de dados regulares no nível do patch sejam corrigidos.

• O patch que causou o problema é desativado usando parâmetros de banco de dados quando está sendo aplicado aos bancos de dados regulares no nível do patch.

• A aplicação de patches em bancos de dados regulares no nível do patch é pausada até que uma ação corretiva seja tomada.

Se você tiver um problema para relatar, registre uma solicitação em Suporte do Oracle Cloud ou entre em contato com o representante de suporte.

A Oracle fornece um objetivo de nível de serviço de regressões zero em seu banco de dados de produção. Consulte Objetivo do Nível de Serviço de Regressão Zero para obter mais informações.

Observações sobre o nível de aplicação de patches:

• A opção para definir o nível de patch não está disponível em todas as regiões. Em algumas regiões, todas as instâncias do Autonomous Database são provisionadas ou clonadas no nível de patch Regular.

• O Autonomous Data Guard só está disponível para instâncias com o nível de patch Regular. Quando você configura uma instância do Autonomous Database com o nível de patch Anteriormente, não é possível ativar o Autonomous Data Guard.

• As instâncias do Autonomous Database Always Free não fornecem a opção de nível de patch Anteriormente.

• Quando o nível de patch de uma instância do Autonomous Database de origem é Regular, em regiões que suportam o nível de patch Anteriormente, você pode definir o nível de patch de um clone como Anteriormente.

Para mostrar informações de notificação:

A seguir, são fornecidos detalhes sobre os valores do campo DESCRIPTION.

• A execução da manutenção foi encerrada: Especifica que a manutenção foi concluída. O MAINTENANCE_STATUS mostra o valor COMPLETED com os timestamps inicial e final para a manutenção concluída em ACTUAL_START_DATE e ACTUAL_END_DATE.

• A execução da manutenção está programada para a instância: Especifica que uma nova manutenção foi programada. O MAINTENANCE_STATUS mostra o valor SCHEDULED com os timestamps inicial e final esperados para a manutenção programada em EXPECTED_START_DATE e EXPECTED_END_DATE.

• A execução da manutenção foi iniciada: Especifica se a manutenção está em andamento e fornece o timestamp inicial para a manutenção ativa. O MAINTENANCE_STATUS mostra o valor IN_PROGRESS e ACTUAL_START_DATE armazena o timestamp inicial.

A tabela a seguir mostra as colunas e os tipos de dados DB_NOTIFICATIONS.

Usar um Pool de Conexões e Retornar Conexões ao Pool

O uso de um pool de conexões é recomendado para ocultar a manutenção programada do seu aplicativo. A execução de um aplicativo durante a janela de manutenção não tem impacto em um aplicativo quando o aplicativo faz o seguinte:

• Usa um pool de conexões com as configurações recomendadas.
• Faz check-out de uma conexão do pool de conexões.
• Usa a conexão por menos do que o tempo de drenagem (5 minutos).
• Retorna a conexão ao pool de conexões.

A melhor prática para um aplicativo que trabalha com um pool de conexões é seguir estas etapas. O aplicativo faz check-out de uma conexão, usa a conexão para processamento do banco de dados e, em seguida, libera a conexão de volta para o pool de conexões imediatamente quando o trabalho é concluído (isso torna a conexão disponível para uso por outros threads).

Quando o período de drenagem inicia, o pool de conexões trata de restabelecer as conexões disponíveis no pool de conexões para que novas conexões se conectem aos nós recém-disponíveis. Quando um aplicativo faz check-out de uma nova conexão, ele não vê interrupções (novas conexões usam os novos nós). No entanto, se uma conexão for submetida a check-out antes do início da manutenção ou durante o tempo de drenagem e ela executar um processamento que continue por mais do que o tempo de drenagem, a conexão será desconectada. Nesse caso, para evitar interrupções, você pode interromper essas operações de longa execução antes do início da manutenção e reiniciá-las quando a manutenção terminar. Para saber quando parar e quando reiniciar operações de longa execução, você pode se inscrever em eventos, conforme explicado na seção a seguir, "Inscrever-se em Eventos de Informações".

A tabela a seguir mostra alguns dos tipos comuns de pool de conexões e as versões e definições recomendadas.

Use Testes de Conexão no Driver JDBC se Não for Possível Usar um Pool de Conexões

Se você não puder usar um pool de conexões, os drivers do cliente Oracle 19.13 (ou mais recente) poderão drenar conexões para que seu aplicativo não veja interrupções. Para garantir que as conexões sejam drenadas corretamente, você pode chamar qualquer API de drenagem JDBC da Oracle: isValid(), isUsable(), pingDatabase() ou endRequest().

Assinar Eventos de Informações

Se o seu aplicativo tiver operações de banco de dados de longa execução que são executadas por mais tempo do que o tempo de drenagem (5 minutos), o pool ou o driver JDBC não poderá drenar as conexões, pois elas não serão liberadas antes do fim do tempo de drenagem. Para tais operações de longa execução, para evitar interrupções, você não deve iniciar os processos e jobs durante ou pouco antes de uma janela de manutenção.

O Autonomous Database publica eventos de Informações no serviço OCI Events para notificá-lo sobre janelas de manutenção, incluindo estes eventos de Informações (com a categoria de evento Manutenção):

• Quando uma nova janela de manutenção é programada
• 24 horas antes do início da aplicação de patches
• 60 minutos antes do início da aplicação de patches
• Quando o patch é iniciado
• Quando a aplicação de patches terminar

Você pode se inscrever em eventos de Informações do Autonomous Database e, opcionalmente, especificar a manutenção da categoria de evento, receber notificações e limitar as notificações recebidas aos eventos de manutenção. Em seguida, com base na notificação e nas regras definidas, você pode executar ações para interromper as operações de longa execução e reiniciá-las após o término da manutenção. Embora as janelas de manutenção anunciadas geralmente tenham 2 horas de duração, a correção real acontece em 5 a 10 minutos durante essa janela. Usando esses eventos e seu conhecimento das operações de longa execução, você pode determinar quando interromper as operações de longa execução e quando reiniciá-las.

Consulte Usar Eventos do Autonomous Database para obter mais informações.

Lidar com o Estado da Sessão de PL/SQL se o Seu Aplicativo estiver Usando PL/SQL

O parâmetro de banco de dados SESSION_EXIT_ON_PACKAGE_STATE_ERROR especifica o tratamento de um pacote PL/SQL com monitoramento de estado em execução em uma sessão. Quando tal pacote sofre modificação, como durante a manutenção planejada para objetos fornecidos pelo Oracle, as sessões que têm uma instanciação ativa do pacote recebem o seguinte erro quando tentam executar o pacote: ORA-04068: existing state of packages has been discarded.. No entanto, o código do aplicativo que recebe o erro ORA-4068 pode não estar equipado para tratar esse erro com sua lógica de repetição.

A definição de SESSION_EXIT_ON_PACKAGE_STATE_ERROR como TRUE fornece um tratamento diferente para esse caso. Quando SESSION_EXIT_ON_PACKAGE_STATE_ERROR for TRUE, em vez de apenas gerar o erro ORA-4068 quando o estado do pacote for descartado, a sessão será encerrada imediatamente. Isso pode ser vantajoso porque muitos aplicativos podem lidar com o encerramento da sessão, restabelecendo a conexão de forma automática e transparente.

Consulte SESSION_EXIT_ON_PACKAGE_STATE_ERROR para obter mais informações.