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

RAC Archive

Algumas operações de tecnologias podem ser paralelizadas utilizando mais CPUs para processar determinadas tarefas, e no banco de dados não é diferente. A opção PARALLEL X, onde X é a quantidade de cores a ser utilizada permite dividir a consulta em pequenos pedaços fazendo com que cada processador execute parte da query.

No exemplo abaixo estou paralelizando a consulta entre 20 cpus com o comando PARALLEL 20 e suspendi a geração de REDO LOG com o NOLLOGGING. Essa operação é lenta, pois está comprimindo uma tabela de 500GB e movendo para outra tablespace, a TD_MOVELOB:

ALTER TABLE GALOMG.TB_LOG COMPRESS FOR OLTP;
ALTER TABLE GALOMG.TB_LOG MOVE TABLESPACE TD_MOVELOB NOLOGGING PARALLEL 20;

Para checar se a consulta está paralelizada, basta executar o select abaixo na LONGOPS que trará uma linha para cada processo dividido:

SELECT inst_id,sid, serial#, opname, username,start_time,last_update_time,
round(time_remaining/60,2) "REMAIN MINS", round(elapsed_seconds/60,2) "ELAPSED MINS", round((time_remaining+elapsed_seconds)/60,2) "TOTAL MINS", 
ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE", message
FROM gv$session_longops 
WHERE TOTALWORK != 0 AND sofar<>totalwork AND time_remaining > 0;

Abaixo o resultado da query, onde msotra que cada pedaço da query possui um SID diferente, mesmo que a tabela seja a mesma: GALOMG.TB_LOG !

Basta executar a query várias vezes para consultar o tempo que cada pedaço da query está sendo executado.

Olá pessoal,
hoje vou passar algumas dicas para desligar corretamente seu ambiente do Oracle RAC. Precisei fazer uma manutenção em apenas 1 dos nós e as vezes temos dúvidas de qual procedimento usar, qual é melhor, mais rápido, etc.

Há duas maneiras legais de para uma instância que são utilizando os comando SRVCTL (servercontrol) ou o CRSCTL (clustercontrol). A diferença básica de um para o outro é que o ClusterControl vai parar a instância do ASM automaticamente e deve ser executado como ROOT.

Maos á obra !

Utilizando o SRVCTL teremos as seguintes opções:

srvctl stop instance -d database -i instancia -o abort
srvctl start instance -d database -i instance
srvctl status database -d database

srvctl stop asm -node hostname -stopoption IMMEDIATE
srvctl start asm -node hostname
srvctl status asm

Utilizando o CRSCTL teremos as seguintes opções:

crsctl stop crs
crsctl start crs
crsctl stat res -t init
crsstat

Com esses comandos acima você consegue facilmente parar e subir os serviços do Oracle

Numa bela tarde de terça-feira (12/06/2018) me deparo com esse erro bacana ao tentar colocar uma PK de uma tabela online .. Os scripts que eu tentei executar sempre tomavam esse erro. A causa desse problema foi um rebuild de índice PK que parei no meio do processo com um alter system kill session e o mesmo ficou incompleto.

A solução estava num doc id do MOS 375856.1 nomeado de: Session Was Killed During The Rebuild Of Index ORA-08104 : )

Basicamente é rodar esse script na instância que está ocorrendo o erro e em seguida rodar o rebuild dos índices:

DECLARE
isClean BOOLEAN;
BEGIN
isClean := FALSE;
WHILE isClean=FALSE
LOOP
isClean := dbms_repair.online_index_clean(
dbms_repair.all_index_id, dbms_repair.lock_wait);
dbms_lock.sleep(10);
END LOOP;
END;


Até a próxima.

 

 

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

 

 

Sempre que preciso trabalhar com algo no SQLPlus rodo dois comandos básicos para tratar linhas e páginas:

SYS@inst01 AS SYSDBA> set lines 900;
SYS@inst01 AS SYSDBA> set pages 100;

Toda vez que logo no SQLPlus executo esses comandos, geralmente após rodar o select e ver que veio tudo desconfigurado. Uma dica simples e que me ajudou bastante foi configurar meu ambiente para sempre abrir o SQLPlus com essas configurações. Basta alterar o arquivo glogin.sql conforme passos abaixo:

1 – Logar no terminal com o usuário Oracle:

[root@server01 ~]# su – oracle

 

2 – Acessar o diretório do SQLPlus via variável $ORACLE_HOME

[server01 :inst01:/home/oracle]$ cd $ORACLE_HOME/sqlplus/admin

 

3 – Após entrar na pasta admin, digite o comando ls -l para listar os arquivos:

O arquivo a ser alterado é o glogin.sql, cujo nome está destacado em amarelo na imagem acima.

 

4 – Editar o arquivo através do vi: #vi glogin.sql e adicionar as linhas set line 900 e set pages 900 :

 

5 – Depois de realizar o passo acima, basta salvar as alterações, sair do vi e executar normalmente o SQLPlus que as configurações estarão de acordo com o configurado.

 

Dica simples que evita eu ter que setar a configuração de linhas e linhas por página toda vez que logo no SQLPlus.

 

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 erro: ORA-01591: lock held by in-doubt distributed transaction, ou em um bom português ORA-01591: bloqueio retido pela transação distribuída 3251.6.3549 geralmente é causado por timeout entre as instâncias de um Oracle RAC.

A consulta por transações retidas ficam na tabela: DBA_2PC_PENDING. Um simples select nessa tabela retorna informações sobre as transações locais e globais:

SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID,STATE,
'EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('||''''||LOCAL_TRAN_ID||''''||');'||chr(13)||'COMMIT;'
FROM DBA_2PC_PENDING
ORDER BY 1 ASC;

Para limpar as transações, basta executar o comando abaixo, onde o @local_tran_id é o campo LOCAL_TRAN_ID e o @COMMIT# é o campo COMMIT# da tabela DBA_2PC_PENDING:

EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('@LOCAL_TRAN_ID');
COMMIT;

Em alguns casos é preciso realizar o rollback da transação através do comando ROLLBACK FORCE ‘@LOCAL_TRAN_ID’,’@COMMIT#’ ficando o script completo dessa maneira:

ROLLBACK FORCE '@LOCAL_TRAN_ID','@COMMIT#';
EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('@LOCAL_TRAN_ID');
COMMIT;

Para automatizar essa limpeza podemos utilizar o seguinte script no crontab ou no Oracle Scheduler e agendar da forma como seu ambiente se comporta, podendo ser diário, semanal ou mensal:

declare
xid varchar2(22);
begin
for c1 in (select LOCAL_TRAN_ID FROM DBA_2PC_PENDING) loop
dbms_transaction.PURGE_LOST_DB_ENTRY(c1.LOCAL_TRAN_ID);
commit;
end loop;
end;

Importante: Em situações que não for possível purgar a transação via pacote DBMS, o procedimento poderá ser feito de forma manual executando os 3 deletes abaixo:

delete from
sys.pending_trans$
where
local_tran_id = 'LOCAL_TRAN_ID';

delete from
sys.pending_sessions$
where
local_tran_id = 'LOCAL_TRAN_ID';

delete from
sys.pending_sub_sessions$
where
local_tran_id = 'LOCAL_TRAN_ID';

commit;

 

É importante frisar que esse procedimento resolve os problemas das transações retidas e não elimina a causa raiz do problema, procure encontrar evidências no ALERT.LOG, no log do GRID para resolver o problema por completo.

 

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.

 

 

 

 

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.