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

Monthly Archive:: outubro 2018

O erro ORA-22297: warning: Open LOBs exist at transaction commit time ocorre quando o usuário faz alguma manipulações colunas do tipo CLOB ou BLOB e por algum motivo não fechou o LOB conforme deveria antes de fazer o commit.

Abaixo segue um exemplo simples que poderia ter evitado o problema:

DBMS_LOB.CLOSE(myFile);
DBMS_LOB.CLOSE(myBlob);
COMMIT;

Para solucionar o problema precisei fazer um rebuild no CLOB e na PK da tabela em questão. O primeiro passo foi listar os índices da tabela:

desct DBUSER.TB_CLOB
select * from dba_indexes where table_name = 'TB_CLOB' and owner='DBCLOB';

Após verificar os índices, fiz o move no CLOB e o rebuild na PK:

ALTER TABLE DBUSER.TB_CLOB MOVE LOB (CLOB_ARQUIVO) STORE AS (TABLESPACE TD_USER);
alter index DBUSER.PK_CLOB rebuild;

Após realizar esse procedimento conseguimos executar o processo sem retornar o erro:

ORA-22297: warning: Open LOBs exist at transaction commit time

Em alguns blogs e sites de referência, a maioria das pessoas disseram que essa mensagem é apenas informativa, porém só consegui rodar o processo após o reubild no CLOB e na PK da tabela.

Fica a dica.

As colunas que armazenam datas e horas no Oracle, pode default retornam apenas a DATA no formato DD/MM/YYYY, sendo que DD = Dia, MM = Mês e YYYY = Ano!

No exemplo abaixo temos um select que retorna a data do sistema:

SELECT TO_CHAR(SYSDATE) FROM DUAL;
14/10/18

Para extrair a data e hora desse campo, é preciso usar a função TO_CHAR passando o parâmetro de data e hora, conforme comando abaixo:

SELECT TO_CHAR(SYSDATE,'DD/MM/YYYY HH:MI:SS') FROM DUAL;
14/10/2018 11:19:32

E se preferir o formato de 24 horas, basta ajustar conforme abaixo:

SELECT TO_CHAR(SYSDATE,'DD/MM/YYYY HH24:MI:SS') FROM DUAL;
14/10/2018 23:19:49

Sabendo como funciona o TO_CHAR, você consegue aplicar esse comando em qualquer coluna de data nas suas tabelas, basta trocar o SYSDATE pelo nome da coluna na tabela e executar o comando.

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.