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

Tunning 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.

Esse erro comum ocorre quando você tenta executar uma operação em uma tabela que foi alterada e a transação ainda está pendente. No nosso caso, estávamos tentando truncar uma tabela de B.I. e o erro era retornado instantaneamente: ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired !

O select abaixo ajudou a identificar a causa raiz, ele lista quais sessões estão aguardando commit ou roolback. No meu caso foi uma transação aberta há mais de 30 dias e, alinhando com a área, matamos a sessão:

SELECT O.OBJECT_NAME, S.SID, S.SERIAL#, P.SPID, S.PROGRAM,S.USERNAME,
S.MACHINE,S.PORT , S.LOGON_TIME,SQ.SQL_FULLTEXT 
FROM V$LOCKED_OBJECT L, DBA_OBJECTS O, V$SESSION S, 
V$PROCESS P, V$SQL SQ 
WHERE L.OBJECT_ID = O.OBJECT_ID 
AND L.SESSION_ID = S.SID AND S.PADDR = P.ADDR 
AND S.SQL_ADDRESS = SQ.ADDRESS;

Dica: Em ambiente Oracle RAC troque o V$ por GV$ !

Faça bom uso do script.

Um erro muito comum em empresas que possuem equipes distintas de DBA, AD e Desenvolvimento é criar as estruturas de banco sem o devido cuidado em indexar as FK’s. Sistemas e melhorias são feitos diariamente e isso pode incluir novos dados, colunas, constraints e demais objetos no banco dedados.

Um script que costumo rodar semanalmente é o que verifica se as FK’s estão indexadas, pois dependendo do uso da tabela, podemso ter um aumento do wait TM CONTENTION. NO meu caso, todos os schemas começam com DB, portanto eu ajustei em 2 lugares para trazer somente os dados referente á esses schemas:

  AND a.owner LIKE 'DB%' 
  WHERE  c.index_owner LIKE 'DB%' 

Basta adaptar o script ás suas necessidades, ou se preferir não filtrar nada, retira esse trecho do código e execute-o.

O script é simples mas de grande utilidade, conforme pode ser visualizado abaixo:

SELECT CASE 
         WHEN b.table_name IS NULL THEN 'unindexed' 
         ELSE 'indexed' 
       END               AS status, 
       a.owner, 
       a.table_name      AS table_name, 
       a.constraint_name AS fk_name, 
       a.fk_columns      AS fk_columns, 
       b.index_name      AS index_name, 
       b.index_columns   AS index_columns 
FROM   (SELECT a.owner, 
               a.table_name, 
               a.constraint_name, 
               Listagg(a.column_name, ',') 
                 within GROUP (ORDER BY a.position) fk_columns 
        FROM   dba_cons_columns a, 
               dba_constraints b 
        WHERE  a.constraint_name = b.constraint_name 
               AND b.constraint_type = 'R' 
               AND a.owner LIKE 'DB%' 
               AND a.owner = b.owner 
        GROUP  BY a.owner, 
                  a.table_name, 
                  a.constraint_name) a, 
       (SELECT table_name, 
               index_name, 
               Listagg(c.column_name, ',') 
                 within GROUP (ORDER BY c.column_position) index_columns 
        FROM   dba_ind_columns c 
        WHERE  c.index_owner LIKE 'DB%' 
        GROUP  BY table_name, 
                  index_name) b 
WHERE  a.table_name = b.table_name(+) 
       AND b.index_columns(+) LIKE a.fk_columns 
                                   || '%' 
ORDER  BY 1 DESC, 
          2; 

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.

 

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.

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.

 

 

 

 

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…