Atenção: esse artigo tem uma palestra complementar. Clique e assista!
Criação de scripts para monitoramento de banco de dados Oracle.
Para que serve?
Scripts que ajudarão o DBA na detecção pró-ativa de possíveis problemas com o banco de dados, bem como verificar o estado atual do backup, saúde geral do banco de dados, etc.
Em que situação o tema é útil?
Uma das tarefas cruciais do DBA é a verificação constante da situação geral do banco de dados. Os scripts criados neste artigo ajudarão nesta tarefa do dia-a-dia, enviando e-mails para o DBA informando a situação geral do banco de dados.
Uma das tarefas mais importantes de qualquer administrador de banco de dados é justamente a tarefa de monitorar o banco de dados para detectar, de maneira pró-ativa, possíveis problemas que possam comprometer a aplicação devido a falhas no banco de dados.
Dentro desta tarefa de monitoramento, o DBA deverá verificar diariamente os arquivos de log do banco de dados (Alert.log, arquivos de trace, etc.), verificar se o backup foi executado com sucesso, conferir o estado geral de performance, áreas de memória, etc.
Sem dúvida nenhuma, esta é uma tarefa que demanda tempo e deve ser encarada como o "café da manhã" do DBA. Uma das primeiras coisas que faço diariamente é esta verificação. A grande questão é a quantidade de bancos de dados que você administra. Caso administre um ou dois bancos de dados, esta tarefa não será tão maçante, mas como na maioria dos casos (incluindo o meu), o número de bancos de dados que o DBA é responsável é considerável e conectar-se ao servidor de cada um dos bancos de dados e efetuar uma verificação detalhada poderá consumir, em alguns casos, mais do que a manhã inteira, sem contar na quantidade de e-mails de usuários, desenvolvedores, gerentes, etc. que temos que responder.
Agora imagine uma situação em que, ao chegar na empresa ou mesmo ligar o notebook em casa, você já verifique a caixa de entrada de seu e-mail e já veja, logo de cara, e-mails enviados pelos servidores de banco de dados lhe passando todas as informações que citamos acima. Com certeza é algo que lhe poupará um bocado de tempo e lhe permitirá utilizar o seu tempo de maneira muito mais produtiva e eficiente, "atacando" os problemas de maneira eficaz.
É justamente este ponto que irei atacar neste artigo, criando uma série de scripts que, quando "instalados" no servidor de banco de dados, auxiliarão muito o DBA.
Definindo o ambiente
A primeira coisa a ser feita sempre que algum script precisa ser executado é definir todas as variáveis de ambiente, e neste arquivo iremos abordar apenas os sistemas operacionais UNIX e Linux.
Existem duas formas para se definir todas as variáveis de ambiente necessárias para a execução de um script:
1. Definir todas as variáveis necessárias "dentro" do próprio script;
2. Criar um arquivo de definição do ambiente e "chamá-lo" no script.
Neste artigo irei utilizar a segunda opção, pois ela traz enormes vantagens, como por exemplo, quando algum valor deve ser modificado em função de upgrade do banco de dados ou até mesmo o e-mail do DBA que irá receber o relatório.
Irei criar um arquivo com o nome de .dba.env, isso mesmo, iniciando com um ponto (.) e com a extensão .env. Ao iniciar o nome do arquivo com um ponto, definimos que o mesmo se trata de um arquivo oculto e que não será listado por um simples comando ls –l, precisaremos utilizar uma opção a mais no comando, ou seja, teremos que usar ls –la.
Este arquivo deve ser criado no diretório home do usuário oracle no servidor de banco de dados. O padrão é o diretório /home/oracle.
A Listagem 1 apresenta o conteúdo do arquivo .dba.env.
Listagem 1. Conteúdo do arquivo .dba.env.
1. # Este arquivo tem o proposito de definir todas as variaveis
2. # de ambiente necessarias relativas a instancia de banco de
3. # dados oracle
4. oratab_list="/var/opt/oracle/oratab /etc/oratab"
5. FOUND=FALSE
6. if [[ $# -eq 1 ]]
7. then
8. export ORACLE_SID=$1
9. for oratab in $oratab_list
10. do
11. if [ -f $oratab ]; then
12. FOUND="TRUE"
13. break
14. fi
15. done
16. if [ "$FOUND" = "TRUE" ]; then
17. export ORACLE_HOME=`grep "$ORACLE_SID:" $oratab |cut -f2 -d':'`
18. export ORACLE_BASE="/`echo $ORACLE_HOME |cut -f2,3 -d'/'`"
19. export SHLIB_PATH=$ORACLE_HOME/lib:/usr/lib
20. export LD_LIBRARY_PATH=$ORACLE_HOME/lib
21. export TNS_ADMIN=$ORACLE_HOME/network/admin
22. export PATH=$ORACLE_HOME/bin:/usr/ccs/bin:$PATH
23. else
24. echo Nao foi possivel encontrar informacoes relativas ao ORACLE_HOME
25. exit 1
26. fi
27. else
28. export ORACLE_SID=""
29. export ORACLE_HOME=""
30. export ORACLE_BASE=/oracle
31. fi
32. export MAIL_LIST="ricardo@sqlmagazine.com.br"
33. export MAIL_PGM="/usr/bin/mailx"
34. export COMPRESS_PGM="/usr/contrib/bin/gzip"
35. export EXCLUDE_OWNER="('SYS', 'SYSTEM', 'OUTLN', 'PERFSTAT', 'DBSNMP')"
Vamos entender o que acontece neste primeiro script. A linha 4 define uma variável chamada oratab_list, que irá armazenar uma lista com as possíveis localizações do arquivo oratab (Nota DevMan 1). Por padrão, no Sun Solaris, o arquivo oratab é o /var/opt/oracle/oratab. Já no HP-UX, AIX e Linux o arquivo oratab é o /etc/oratab.
Caso o padrão de sua empresa seja o de colocar o arquivo oratab em outra localização, basta adicionar na lista do oratab_list.
O oratab é um arquivo criado pelo Oracle quando o software do banco de dados é instalado. Originalmente, o oratab era usado pelo SQL*Net V1, mas atualmente ele é utilizado para listar os bancos de dados e versões dos softwares de banco de dados instalados no servidor.
O arquivo oratab pode conter comentários, sempre iniciados pelo símbolo sustenido (#) e cada linha fará referência a informações de cada banco de dados instalado no servidor e o formato é:
ORACLE_SID:ORACLE_HOME:Y|NComo por exemplo:
SQLMAG:/oracle/u01/software/rdbms/11.0.1:YORACLE_SID é o system ID da instância do banco de dados;
ORACLE_HOME é o diretório de instalação do software de banco de dados associado à instância;
Y\N indica se a instância deve ser inicializada automaticamente após um boot do servidor (Y=sim, N=não).
Na linha 5 foi criada uma variável chamada FOUND que recebe o valor FALSE, que será usada para definir se o arquivo oratab foi ou não encontrado. Veremos esta variável novamente adiante.
A linha 6 inicia um desfio condicional (if) verificando se o número de argumentos enviados ao script ($#) é igual a 1 e, caso sim, define a variável ORACLE_SID com o valor do primeiro argumento passado para o script ($1).
Ainda dentro do desvio condicional, a linha 9 inicia um loop do tipo for onde ele inicia a variável oratab com o conteúdo da lista da variável oratab_list, ou seja, para cada entrada na lista oratab_list, será executada a repetição.
Para o primeiro valor da lista (/var/opt/oracle/oratab) um novo desvio condicional é iniciado (linha 11) onde será verificado se o arquivo armazenado na variável oratab (/var/opt/oracle/oratab) existe. No meu caso, o banco de dados está instalado em um sistema operacional Linux onde o arquivo oratab é o /etc/oratab. Portanto, nada será feito na primeira iteração do comando for pois o arquivo não será encontrado. Na segunda iteração, o arquivo será encontrado com sucesso e a variável FOUND receberá o valor TRUE (linha 12) e o laço de repetição será quebrado (linha 13).
É na linha 16 que "as coisas acontecem". Um novo desvio condicional é iniciado verificando se a variável FOUND possui o valor TRUE. Caso sim, na linha 17 é extraído, do arquivo oratab, o diretório de instalação do software do banco de dados para a instância especificada e armazenado na variável ORACLE_HOME. A linha 18 extrai um "pedaço" da variável ORACLE_HOME e armazena esta fração do diretório ORACLE_HOME como sendo o diretório base da instalação na variável ORACLE_BASE. Agora não será mais necessário extrair nada, basta apenas inicializar as variáveis com valores com base no ORACLE_HOME. As linhas 19 e 20 definem a localização em que o sistema operacional deverá encontrar as bibliotecas dinâmicas. No caso de HP-UX PA-RISC as bibliotecas são procuradas na variável SHLIB_PATH enquanto que Linux ou qualquer outro UNIX (incluindo HP-UX Itanium) a variável é a LD_LIBRARY_PATH.
...
