Site em Manutenção
Conteúdo voltado para banco de dados Oracle e SQL Server

Monthly Archive:: novembro 2016

Muitas pessoas ao executar operações DDL (alteração de tabelas, inclusão de FK’s, etc) recebem o seguinte erro no SQLPLUS, SQL Developer e afins:

ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired.

Esse erro ocorre devido á tabela que está sendo alterada estar ocupada com outras operações de manipulação de dados. Nesse caso você sempre receberá o erro ORA-00054 enquanto a tabela que você deseja alterar não estiver disponível.

Para resolver o problema é preciso agendar um horário de baixa atividade no banco de dados, tais como períodos da madrugada ou finais de semana! Fazendo assim, você evita a concorrência durante o dia e consegue executar o script sem esperar por muito tempo. Para ajudar nesse trabalho, existem 2 parâmetros que podem facilitar muito a execução dessa tarefa. São eles:

  • ALTER SESSION ENABLE PARALLEL DDL;
  • ALTER SESSION SET DDL_LOCK_TIMEOUT= 600;

O parâmetro ENABLE PARALLEL DDL habilita a sessão para realizar operações DDL em paralelo com o intuito de reduzir o tempo da operação e o DDL_LOCK_TIMEOUT especifica o tempo em segundos que a sessão vai aguardar por um lock na tabela a ser alterada.

O padrão para o ENABLE PARALLEL DDL é zero, o que indica que você nunca vai esperar por um lock. Sempre deixo o padrão de 10 minutos (600 segundos) quando preciso realizar alguma operação em uma grande tabela no banco de dados.

Abaixo segue o exemplo de execução dos comandos:

enable-paralel-ddl

Feito isso basta rodar a query e aguardar o tempo necessário para executá-la.

 

 

 

 

Algumas informações podem ser listadas diretamente no shell, porém o output é muito grande e atrapalha a busca por determinadas informações. No RMAN quando você lista os backups realizados, o utilitário retorna milhares de linhas com informações referente aos datafiles backupeados.

Uma opção interessante para salvar as informações do RMAN e posteriormente localiza-las com NOTEPAD++, notepad e afins é a opção LOG, que pode ser realizada da seguinte maneira:

[server01:inst01:/home/oracle]$ rman target / log=/home/oracle/log_rman_20161114.log

Feito isso, o prompt do RMAN abrirá normalmente:

rman_blog_log_destination

Os comandos listados acima tiveram seu output enviados para o arquivo: /home/oracle/log_rman_20161114.log e podem ser acessados com o editor VI ou comando CAT, TAIL, etc.

 

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.