Conteúdo voltado para banco de dados Oracle e SQL Server

Checklist Archive

Uma simples maneira de limpar o arquivo de log do listener (Listener.log) é escrevendo nele mesmo um valor simbólico.

Abaixo vamos aprender como limpar de maneira rapida o log do listener. É recomendável que você compacte e guarde em algum lugar para consultas futuras.

Ao listar
-rw-r—–   1 oracle dba   15G Jul 21 19:05 listener.log

Execute o comando:
# cat /dev/null > listener.log

E verifique que o arquivo foi sobrescrito:
-rw-r—–   1 oracle dba  1,1K Jul 21 19:09 listener.log

 

 

A maior parte do tempo de um DBA é gasta usando ferramentas como SQL Developer, SQLPlus e RMAN. Essas duas últimas em específico são muito boas mas também tem algumas limitações banais. Quem nunca errou ao escrever um select e teve que apertar o CONTROL para sair deletando os caracteres? E aquele comando valioso que foi executado no RMAN e você tem que digitá-lo novamente porque o utilitário não acumula o histórico de comandos como é feito no linux.

No exemplo abaixo, ao tentar trocar a letra F por um * ele simplesmente escreve ^H^H^H^H^H^H. Para deletar é preciso apertar CONTROL  +BACKSPACE para que ele delete a linha:

Pois é, depois de passar muita raiva com isso e conviver com o “problema” por meses meus problemas acabaram somente após eu instalar a ferramenta RLWRAP nos meus servidores Linux e com isso usa-la como complemento ás ferramentas SQLPlus e RMAN. Ela traz recursos tais como:

Autocompletar com TAB

Deletar caracteres apenas com o backspace

Usar a setinha pra cima traz o histórico de queries executadas

Chega de prosa e vamos por a mão na massa, siga os passos abaixo e seja feliz:

1 – Instalar o repositório e em seguida o rlwrap propriamente dito:

[root@server01]$ yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm -y

Após instalar o repositório, rode o comando abaixo:

[root@server01]$ yum install rlwrap -y

 

2 – Depois de feita a instalação, precisamos alterar o arquivo ~/.bashrc do usuário oracle:

[root@server01~]# su – oracle
[server01:inst01:/home/oracle]$ vim ~/.bashrc

 

3 – Inserir as duas linhas abaixo no arquivo bashrc:

alias sqlplus=’rlwrap sqlplus’
alias rman=’rlwrap rman’

O seu arquivo bashrc deve ficar dessa maneira:

4 – Feito isso, basta salvar as alterações realizadas no arquivo bashrc e fazer logout do usuário oracle! Depois logue novamente para que as configurações do bashrc sejam aplicadas e abra normalmente o SQLPlus e o RMAN.

Agora será possível apagar os caracteres sem a necessidade de ficar apertando CONTROL, usar o recurso de auto-completar do SQLPlus e do RMAN dentre outros.

Os logs do Oracle são salvos em sua grande maioria no arquivo alert.log! Com o passar do tempo esse arquivo vai acumulando informações e se torna muito grande,  dificultando sua leitura e compreensão não hora do troubleshooting. Já tive arquivos na casa dos GB e a melhor alternativa era copia-lo para a Área de Trabalho e editar com o notepad++.

Para limpar os arquivos de logs podemos utilizar o utilitário ADRCI. Com o usuário Oracle logado digite o seguinte comando:

adrci

Você receberá uma mensagem semelhante á essa:

ADRCI: Release 12.1.0.1.0 - Production on Wed Dec 21 21:30:43 2016
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
ADR base = "/u01/app/oracle"

Em seguida digite show homes e espera o S.O. listar os homes de cada log gerenciado:

adrci> show homes;

ADR Homes:
diag/tnslsnr/server01/listener_scan4
diag/tnslsnr/server01/listener_scan1
diag/tnslsnr/server01/vs01
diag/tnslsnr/server01/listener_scan3
diag/asmtool/user_root/host_954678459_80
diag/rdbms/vs22/vs22

Agora é preciso setar o homepath de qual arquivo você vai limpar. Para escolher o alert log digite no sqlplus:

show parameter user_dump_dest
user_dump_dest string /u01/app/oracle/diag/rdbms/<strong>vs22/vs22/trace

Com base na informação acima, sabemos que o homepath do alert.log é o diag/rdbms/vs22/vs22!

set homepath diag/rdbms/vs22/vs22

Depois de setar o homepath basta digitar o comando agora para limpar as entradas no alert.log, sendo que 1440 é referente á 1 dia (1440 minutos).

PURGE -age 1440 -type ALERT

Geralmente deixo os últimos 30 dias de logs para consulta, sendo assim ficaria 1440 x 30 = 43200:

PURGE -age 43200 -type ALERT

Feito isso o alert.log será limpo de acordo com o tempo que você desejar. É interessante criar uma rotina de expurgo para evitar fazer o serviço manualmente e por ventura esquecer de realizá-la periodicamente.

Alguns arquivos de AUDITORIA, cuja extensão é .aud são gerados constantemente no caminho informado no parâmetro: audit_file_dest ! Uma maneira simples de limpar esses arquivos é com o comando FIND, pois o rm -rf *.aud estoura a lista de argumentos do S.O. não permitindo a exclusão por inteiro. Abaixo segue o script que utilizo para limpar as pastas de audit:

find /u01/app/oracle/admin/vs25/adump -name '*.aud' -mtime +60 -exec rm -f {} \;

Até a próxima

O Automatic Workload Repository (AWR) é um relatório muito útil para identificar gargalos e problemas de lentidão no Oracle. Esse relatório é disponível para quem tem o pacote DIAGNOSTICS TUNING licenciado, para quem não possui tem o recurso STATSPACK. O AWR pode ser gerado através do SQLPLUS em 4 simples passos:

  1. Qual tipo do relatório a ser gerado. Pode ser em .txt ou html. Eu particularmente prefiro o HTML, facilita bem mais a leitura.
  2. O tempo a ser analisado. Esse tempo deve ser colocado em dias. Exemplo: se quiser ver dados de 1 mês, digitar 30, 2 meses, 60 e assim em diante.
  3. O snapshot id inicial
  4. O snapshot id final

Para iniciar a geração do relatório entre no SQLPLUS:

[SRV:bd01:/home/oracle]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Dec 12 16:47:26 2016

Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 – 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

1º Passo: executar o script awrrpt.sql, ele fica localizado no diretório $ORACLE_HOME/rdbms/admin/awrrpt.sql! Para executar um script dentro do SQPLUS basta colocar o @? e o caminho do arquivo, conforme script abaixo:

SYS@bd01 AS SYSDBA> @?/rdbms/admin/awrrpt.sql

Current Instance
~~~~~~~~~~~~~~~~

DB Id DB Name Inst Num Instance
———– ———— ——– ————
3534058528 bd01 1 bd01

2º Passo: Informe o tipo do relatório que será gerado: HTML ou TXT. Se você não digitar nada e apertar enter, o oracle assume o valor padrão e deixa como HTML:

Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter ‘html’ for an HTML report, or ‘text’ for plain text
Defaults to ‘html’
Enter value for report_type: html

 

 

3º Passo: Especificar o número de dias a considerar, no meu caso escolhi 90 dias

Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing <return> without
specifying a number lists all completed snapshots.

Enter value for num_days: 90

Após digitar esse valor, o Oracle lista todos os snapshots disponíveis nesse range de data:

 

4º Passo: Informar o Snapshot inicial e final. No exemplo acima vamos colocar o snapshot 997 a 1001. Primeiro informe o Snapshot Id 997 e dê enter, depois informe o 1001 para o END Snapshot Id e dê enter novamente.

 

Após informar os ID’s, ele pede que você dê um nome ao arquivo, caso você ignore e aperte enter, ele será criado com o nome default: awrrpt_1_snapIdinicial_snapIdfinal.html !

Feito isso basta esperar o AWR ser gerado na pasta em que você estava antes de entrar no SQLPLUS, no meu caso, o usuário estava na pasta /home/oracle:

Ao abrir o AWR você terá algo do tipo:

Basicamente para gerar o AWR é seguir esses passos. Muitas vezes o suporte da Oracle solicita esse arquivo para análises de chamados e gargalos e durante o dia a dia o DBA pode utilizar para identificar problemas de desempenho.

Geralmente após algum desligamento programado ou um incidente no servidor, rede elétrica, etc, é preciso voltar o RAC em seu pleno funcionamento e alguns comandos são úteis para verificar se o serviço está UP:

– Verificar o status do banco de dados através do comando srvctl:

# srvctl status database -d inst0

Resultado:

A instância inst01 não está em execução no nó dbserver01
A instância inst02 está em execução no nó dbserver02
A instância inst03 não está em execução no nó dbserver03

No nosso caso os serviços inst01 e inst03 nãoi estão rodando os 2 nós do RAC, somente em 1. É preciso executar o comando: srvctl start database -d inst0 novamente para que o serviço suba. Se ocorrer algum erro, basta ir no alert log do oracle home ou do grid para verificar as inconsistências

 

– Realizar a checkagem completa no cluster. Acesse a pasta bin do GRID: cd $GRID_HOME/bin e logo depois execute o comando abaixo:

# cd $GRID_HOME/bin

# ./crsctl check cluster -all

Resultado:

[dbserver01:inst01:/u01/app/12.1.0/grid/bin]$ ./crsctl check cluster -all
**************************************************************
dbserver01:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
dbserver02:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
dbserver03:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************

 

 – Listar os nodeapps para validação dos recursos de rede:

# srvctl status nodeapps

[dbserver01:vs012:/u01/app/12.1.0/grid/bin]$ srvctl status nodeapps
O VIP dbserver01-vip está ativado
O VIP dbserver01-vip está em execução no nó: dbserver01
O VIP dbserver02-vip está ativado
O VIP dbserver02-vip está em execução no nó: dbserver02
A rede está ativada
A rede está em execução no nó: dbserver01
A rede está em execução no nó: dbserver02
O ONS está ativado
O daemon ONS está em execução no nó: dbserver01
O daemon ONS está em execução no nó: dbserver02
PRKO-2166 : GSD não existe no nó(s) : dbserver01,dbserver02

 

– Para uma verificação mais detalhada, podemos usar o: crsctl stat res -t que lista os dados de cada recurso do cluster:

Acesse a pasta bin do GRID: # cd $GRID_HOME/bin

Execute o comando: # ./crsctl stat res -t

check_cluster_blog

Com base nas informações, podemos ver que os recursos ora.ACFS_BACKUP.BKP_ORACLE.advm, ora.ACFS_BACKUP.VOL_ACFS.advm e ora.ACFS_BACKUP.dg estão OFFLINE, sendo necessário intervenção para colocá-los online, conforme faremos no item 6.

– Para verificar o status de cada um dos itens OFFLINE, basta executar o comando abaixo:

# crsctl status resource ora.ACFS_BACKUP.BKP_ORACLE.advm

Resultado:

NAME=ora.ACFS_BACKUP.BKP_ORACLE.advm
TYPE=ora.volume.type
TARGET=ONLINE , ONLINE
STATE=OFFLINE, OFFLINE

– Para startar um recurso que está offline, basta executar o comando crsctl start resource [nome do recurso]:

# ./crsctl start resource ora.ACFS_BACKUP.BKP_ORACLE.advm

O resultado do comando é semelhante á esse abaixo, porém pode existir vários erros de acordo com o recurso e devem ser resolvidos de acordo com os erros na tela:

CRS-2672: Attempting to start ‘ora.ACFS_BACKUP.dg’ on ‘dbserver01’
CRS-2672: Attempting to start ‘ora.ACFS_BACKUP.dg’ on ‘dbserver02’

Esse é um checklist básico de verificação dos serviços. Outra variáveis podem ser verificadas tais como alert.log do oracle e do grid, logs do storage, rede e análise do /var/log/messages a nível de S.O.

Após fazer a instalação do SQL Server em seu ambiente é importante verificar alguns pontos para que nenhuma surpresa desagradável venha a acontecer. Alguns itens básicos de verificação que podem ajudar são:

 

  • Verificar o alinhamento das partições entregues ao S.O. Essa opção deve ser verificada antes de instalar o SQL Server, caso contrário, tem o trabalho administrativo para mover as bases de dados para outra unidade, formatar o disco com o alinhamento correto e voltar os bancos para a partição original.

 

  • Desabilitar o usuário SA e criar um grupo no Windows como sysadmin e incluir lá os DBA’s responsáveis pela instância.Entretanto considere a possibilidade de habilitar somente o Windows Authentication Mode no momento da instalação, e só depois habilitar o Mixed Mode, assim não será preciso digitar a senha do SA e o mesmo será criado desabilitado.

Read more…