Suporte para Ações do Usuário do Cliente

O que há nele para você

• Preservar seus processos: Continue usando suas etapas de automação e conformidade existentes enquanto a Atualização de Frota do Exadata gerencia a aplicação de patches.
• Pontos de integração personalizados: Insira scripts em pontos determinísticos antes e depois da aplicação do patch.
• Escopo alvo: Aplique scripts à aplicação de patches do BD ou do GI e, opcionalmente, restrinja por versão principal (12, 19, 23).
• Execução consistente: Certifique-se de que os scripts sejam executados de forma confiável em todos os nós envolvidos no ciclo de patch.

Como Funciona

• Modelo de aceitação: Coloque um arquivo useractions.zip em /u02/efu/ no(s) domU(s) de destino.
• Detecção automática: A Atualização da Frota do Exadata extrai o zip para /var/opt/oracle/managed/fppua (propriedade de oracle:oinstall, modo 750) e impede substituições simultâneas inseguras.
• Pontos de execução: Os scripts são executados sequencialmente por nó/instância nos estágios de pré-aplicação e pós-aplicação.
• Tratamento de erros: Códigos de saída diferentes de zero falham no job; use a saída 0 se não quiser bloquear a aplicação de patches.

Principais Conceitos

• Useractions: Seus scripts ou plugins personalizados.
• Pontos de ação:
  • Aplicação de patch do BD: Pré (antes da reinicialização da instância) e Pós (após a reinicialização).
  • Aplicação de patch do GI: Pré (antes da pré-aplicação do CRS) e Pós (após a pós-aplicação do CRS).
• Tipos de destino: db ou gi.
• Escopo da versão: Aplicar scripts a versões principais específicas (12, 19, 23).

Argumentos de entrada de ação do usuário

Para facilitar o desenvolvimento de script de ação do usuário personalizado, a Atualização de Frota do Exadata passa os seguintes argumentos de entrada para scripts de ação do usuário. Esses argumentos podem ser usados pelos scripts para executar as ações necessárias.

Ativando Ações do Usuário

1. Prepare o zip: Crie o /u02/efu/useractions.zip, pertencente ao oracle:oinstall (750).
2. Scripts de estrutura:
   • Coloque em diretórios db/ ou gi/.
   • Siga a convenção de nomenclatura:

     db/fppua1_pre_apply.sh
     db/fppua1_post_apply.sh
     db/19/fppua1_pre_apply.sh
     gi/fppua2_post_apply.sh

   • Use o prefixo numérico (nn) para ordenação.

Comportamento de Execução

• Ordenação: fppua1_* → fppua2_* → fppua3_* …
• Tempo limite: 30 minutos por script.
• Contextos do usuário:
  • Scripts de banco de dados executados como proprietário do banco de dados (oracle).
  • Os scripts GI são executados como usuário CRS.
• Argumentos informados: As variáveis de ambiente, como RHP_PHASE (PRE/POST), RHP_DBNAME, RHP_VERSION, RHP_EXEC_NODE e outras, são fornecidas aos seus scripts.

Práticas Recomendadas

• Torne os scripts idempotentes e seguros para novas tentativas.
• Valide variáveis de ambiente antes da execução.
• Faça log-in claramente com timestamps, nós e identificadores de BD.
• Use a saída 0 para condições sem bloqueio.
• Mantenha as operações leves (menos de 30 minutos).
• Evite prompts interativos ou dependências externas.
• Teste em ambientes de não produção antes do rollout.

Diagnóstico e Solução de Problemas

• PRGH-1024: O script retornou um valor diferente de zero; corrija o script ou assegure a saída 0.
• PRCZ-4001/2103: Falha ao executar o comando como oracle; verifique a propriedade/permissões.
• PRGT-496: Useractions ignoradas devido a permissões incorretas.
• Sem execução: Verifique o flag do recurso, a propriedade do zip, o tamanho (<10 MB) e a estrutura.
• Timeouts: Divida ou otimize scripts de longa execução.

Segurança e Conformidade

• Os scripts são executados com os mesmos privilégios dos proprietários do BD (oracle) ou do GI (usuário CRS).
• Permissões rigorosas (oracle:oinstall 750) são impostas; zips configurados incorretamente são ignorados.
• Nenhuma nova identidade ou escalação privilegiada foi introduzida.
• Revise a saída do script para obter informações confidenciais antes de permitir isso nos logs do job.

Resumo

As ações do usuário da Atualização de Frota do Exadata fornecem um mecanismo de extensão controlado e seguro para aplicação de patches de BD e GI em ExaDB-D e ExaDB-C@C. Com uma abordagem leve e baseada em zip e controles de permissão rigorosos, você pode integrar perfeitamente operações específicas do ambiente em ciclos de patches automatizados e contínuos sem sacrificar os padrões de conformidade, segurança ou operacionais.