Shell Scrip para backup manual no Oracle no Linux

… ou YASHTBODB: Yep, Another Shell Script To Backup Oracle DataBase!

Já faz algum tempo que utilizo Shell Script para fazer backup no Oracle. Na verdade eu prefiro utilizar outras linguagens de programação, particularmente o PERL, para não precisar ficar chamando o SQL*Plus toda hora. Mas como existe uma barreira cultural por aqui, acabou ficando tudo em Shell Script mesmo. Bom, ocorre que chegou a hora de aposentá-los em favor do RMAN. Sim, com o uso do RAC junto com o ASM, backup manual ou “user managed backup” como a Oracle gosta de dizer, perdeu completamente o sentido. Além disso, no Oracle 10g, o Database Control implementou uma série de alertas sofisticados bem mais eficientes que o singelo script aqui em questão. Estou terminando de implantar o RMAN para todos os últimos servidores e então os últimos scripts cairão finalmente no ostracismo. Então estou publicando-os aqui, para que sirvam de referência futura.

Requisitos

Rotinas executadas a cada 30 minutos:

  • Cópia dos archives para outro servidor;
  • Criação de alerta se alguma partição possuir mais de 80% e 95% de ocupação.

Rotinas executadas a cada 24 horas:

  • Rodar o analyze em todos objetos;
  • Fazer backup lógico full;
  • Copiar backup lógico para outro servidor;
  • Verificar a integridade dos datafiles;
  • Fazer cópia on-line dos datafiles permanentes para outro servidor;
  • Verificar o volume de origem e o copiado dos datafiles;
  • Fazer cópia do control_file em modo binário e lógico;
  • Fazer cópia do spfile;
  • Apagar archives com mais 8 dias;
  • Verificar se algum tablespace está com mais de 80% de ocupação;
  • Verificar todos os erros ocorridos no alert;
  • Renomear o alert para um nome com o SID e data

Rotinas executadas a cada 7 dias:

  • Cópia off-line dos datafiles permanentes para outro servidor;
  • Cópia do spfile

Rotina mensal (realizadas no último dia de cada mês):

  • Rodar scripts específicos de aplicações
  • Arquivar todos os logs (adump, bdump, cdump, udump e backup logs) em uma pasta ‘old’

Outros requisitos:

  • Criar um log contendo todos os erros ocorridos durante todas operações de backup;
  • Registrar no log a duração de todas operações longas;
  • Registrar no log o espaço disponível em cada partição de disco;
  • Enviar um e-mail com o log ao término de cada operação de backup;
  • Parametrizar o script de forma a utilizar o mesmo script para vários servidores distintos.

Preparação

Antes de mais nada, é preciso criar um usuário no SO e no Oracle. É preciso se assegurar que o usuário em questão tenha acesso às pastas que ele irá copiar. Existem pelo menos umas 4 formas de se fazer isso:

  • Utilizar o próprio usuário Oracle. A vantagem de usar o usuário Oracle do SO, é não precisar colocar senha no script, por outro lado a pessoa que administra o script acaba tendo autorização para acessar o banco diretamente sem senha e com poderes de SYSDBA. Em termos de segurança, isto não é recomendado. No entanto, os backups off-lines e backups de spfile exigem o usuo de um usuário com permissões de SYSDBA ou SYSOPER, então acaba fazendo sentido utilizar o usuário Oracle do SO para estas operações;
  • Alterar as permissões nas pastas do banco de dados para permitir a leitura para que qualquer usuário do SO (o terceiro dígito no sistema octal de permissões). Não gosto desta solução por problemas de segurança, uma vez que não apenas o usuário de backup como outros também terão acesso aos arquivos do Oracle. Se for para fazer isso, ainda é melhor usar o usuário Oracle do SO mesmo para tudo;
  • Alterar os grupos donos dos arquivos e pastas a serem utilizados. Também não é uma boa idéia, uma vez que ao criar um novo datafile, ele é criado com o grupo oinstall por padrão. A cada vez que um novo datafile é criado, você teria de alterar o grupo do datafile;
  • Adicionar o usuário de backup ao grupo oinstall. Pode não ser uma solução muito segura, mas veja que os datafiles são criados com a permissão 640 por padrão. O que significa que o usuário em questão só poderá ler os datafiles sem poder alterá-los, o que me parece bem razoável. Mesmo assim, você deverá acertar o acesso de algumas pastas e arquivos para que você possa gravar nelas, como a pasta onde o próprio script vai ficar e onde ele vai gerar os logs e os backups lógicos. Esta será a opção utilizada para a maioria das operações de backup. A excessão, como citado anteriormente fica para o backup do spfile e backup off line.

Para criar um usuário no SO que faça parate do grupo ‘oinstall’ (realmente estou supondo que você usou o nome dos usuários e grupos de usuáros padrões da instalação):

O mesmo usuário do SO deverá ter um correspondente dentro do banco de dados:

Se você quiser utilizar um usuário a parte mas não quer colocar a senha do usuário nos scripts (que é o que foi feito no nosso exemplo), pode criar o usuário com o comando abaixo:

Mas para utilizar usuários autenticados externamente (pelo SO) não esqueça de setar no ‘init.ora’ os seguintes parâmetros:

O parâmetro ‘os_authent_prefix’ é opcional e permite que o nome no SO seja idêntico ao nome no banco de dados. Já o parâmetro ‘remote_os_authent’ é vital para garantir a segurnaça do banco de dados. O padrão do parâmetro é ‘FALSE’ e ninguém em sã consciência utiliza este parâmetro como ‘TRUE’.

Depois de criar o usuário precisamos conceder as permissões adequadas para ele:

Lembre-se de O usuário também deve ter um tablespace com alguma quota para criar as tabelas de logs do backup lógico (coisas do data pump a partir do 10g). O comando CREATE USER cria o usuário, com a senha: ‘senha’. Depois concedemos privilégio para o usuário se conectar no banco de dados em CREATE SESSION. O privilégio ALTER SESSION será utilizado para ajudar a identificar o backup lógico do control file enquanto o privilégio ALTER DATABASE é utilizado para realizar o backup físico e lógico do control file propriamente dito. O privilégio ALTER SYSTEM é necessário para realizar o checkpoint e o rotacionamento dos logs durante o backup físico on line enquanto o privilégio MANAGE TABLESPACE permite a operação de backup on line propriamente dita. Note que aqui a permissão de leitura dos datafiles pelo usuário do SO é necessária também. Depois temos os privilégios ANALYZE e ANALYZE ANY DICTIONARY necessários para as atualizações de estatísticas das tabelas e índices. Note que o privilégio ANALYZE ANY DICTIONARY surge apenas no Oracle 10g, não existindo nem sendo necessário em versões anteriores. Por último vem o privilégio EXP_FULL_DATABASE que é necessário para o backup lógico.

Se você for utilizar o Data Pump (muito recomendado e utilizado no nosso exemplo), a nova ferramente de backup lógico da Oracle a partir da versão 10g, você deverá utilizar também os seguintes comandos SQL:

Onde ‘ORACLE_SID’ é o nome do seu banco de dados oracle. É claro que o ponto de montagem ‘/u03’ é específico do padrão que adoto nos meus servidores. Substitua o caminho do diretório para aquele que você reservou no seu servidor. Lembre-se que este diretório deve ser criado manualmente e o usuário ‘backup’ ou o grupo ‘oinstall’ do SO devem ter permissões de leitura e gravação neste diretório:

Outras permissões deverão ser acertadas para o usuário de backup no SO como a permissão para apagar os archives (com uma permissão 770 na pasta por exemplo). Alguns acertos podem ser um pouco chatos e devem ser realizados no servidor de destino onde os arquivos são copiados também.

Um último detalhe é que é preciso configurar o SSH sem senha entre os servidores onde está o servidor Oracle e e o que vai receber todos os backups. Meus testes com NFS mostraram que ele é menos estável que o SSH e a diferença de performance é mínima. Existem vários tutoriais sobre como fazer isso, inclusive este da própria Oracle. No meu caso eu criei um usuário backup e um usuário oracle no servidor de destino e gerei o ssh sem senha entre os usuários com mesmo nome nos servidores de origem e destino dos backups.

Funcionamento do Script

Algumas premissas foram assumidas antes de criar o script:

  • O mesmo script deveria ser utilizado independente do banco de dados que sofreria as operações. Para isso o script deve receber como parâmetro o nome do banco e todas as pastas devem receber o nome do banco também, seguindo as recomendações do OFA. Isto facilita e muito a utilização do mesmo script em vários servidores distintos ou quando temos mais de uma instância no mesmo servidor.
  • O mesmo script deveria ser utilizado para diversas operações diferentes. Para isso o script deve receber como parâmetro o nome da operação.
  • Excepto pelos parâmetros de nome da base e operação, todas as outras variáveis são identicas, sendo declaradas no início do script. Esta configuração é adequada para o caso onde se utiliza apenas um ORACLE_HOME para todas as bases do servidor, mas pode ser um problema em outros casos.
  • Ao invés de colocar todo o código SQL em arquivos separados e chamarmos eles pelo SQL*Plus, optei por colocar todo o códio SQL dentro do script e envia-lo para o SQL*Plus utilizando o redirecionamento conhecido como “here document”, que é algo como um <<EOF … EOF onde “…” é o código SQL.
  • Todas as chamadas do scripts seriam chamados a partir do crontab do usuário, mas isto não impede a chamada manual.
  • Cada etapa do backup é colocada em uma função separada, de forma a podermos realocar as etapas para diferentes situações em necessidades específicas (como em servidores de teste e produção). A forma como o script está configurado aqui é apenas um exemplo. Em produção, tenho uma série de outras funções específicas de nossas regras de negócio que foram removidas também.
  • O backup lógico aqui está sendo feito com o Data Pump, mas nada impede você de adaptar o script para utilizar a ferramenta tradicional de export da Oracle.

Variáveis de Ambiente

Antes de passar para os scripts de backup, segue abaixo algumas variáveis utilizadas não apenas pelos scripts em shell, como também os scripts em SQL. Vale a pena lembrar que quando os scripts são executados no modo não interativo (como quando chamados pelo cron) é comum que os arquivos .bashrc e .bash_profile ignorem suas configurações. Por via das dúvidas, vamos exportar todas as variáveis de ambiente do Oracle e outros que serão úteis em nossos scripts.

  • ORACLE_HOME : o diretório onde o SGDB Oracle foi instalado;
  • ORACLE_SID : o nome do banco de dados alvo das operações de backup;
  • SQLPATH : o diretório padrão do SQL*Plus para armazenamento de scripts SQL;
  • NLS_LANG : Diz respeito a localização e codificação de caracteres utilizados;
  • PATH : deve incluir o caminho para o diretório com os aplicativos Oracle;
  • dia : referência para saber a data em que a operação foi realizada. Gosto de utilizar o formato ano/mês/dia, pois é mais fácil de listar em órdem cronológica arquivos com este formato de data;
  • log : arquivo contendo o log de toda a operação;
  • arch_dest : local de destino local para os archives;
  • dump_dest : local de destino local para os backups lógicos;
  • remote_dest : nome ou ip do servidor remoto que receberá os backups
  • dados: nome dos pontos de montagem onde se encontram os datafiles;
  • oracle_mail : email para onde os logs e alertas serão enviados;

Chamadas no crontab

Segue aqui as chamadas utilizadas para acionar o script

Note que para realizar as rotinas de backup off line, é preciso do privilégio de SYSDBA para fechar e abrir a instância. Então se você utiliza um usuário separado para o backup, deverá colocar a linha abaixo no crontab do usuário oracle do SO e não usuário backup.

O Script

Bom, chega de enrolação, segue abaixo o script. Se você encontrar algum erro (eu tive que tirar algumas coisas muito específicas aqui do trabalho) ou alguma forma de melhorar ele, por favor deixe um comentário ou mande um e-mail.

Referências

1 comentário

  1. Marcos Responder

    É importante termos matérias com o objetivo de realizar as tarefas “junto as explicações”, conforme visto nesta matéria.

    Muitos DBA´s não costumam perguntar e nem mesmo compartilhar as experiências (talvez por vergonha ou sei lá).

    Em algumas empresas, o DBA é um cara “solitário” e não tem outro colega de trabalho para conversar sobre os problemas encontrados e soluções adotadas.

    Esta matéria parece muito interessante. Vou experimentar.

    Parabéns pela iniciativa.

  2. Renan Ricardo Responder

    Excelente scripts, muito completo e muito bem explicado cada linha dos comandos.
    Parabéns!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *