Menu de navegação

[Manoel872Participante]

Boa tarde,

Pessoal estou com um problema desenvolvi uma procedure para fazer um relatorio crystal, a procedure estava funcionando perfeitamente logo após o almoço a procedure ficou lenta ao abrir no crystal, porem ao executar o select via BD ele esta bem rápido e retorna a informações que necessito, porém no Crystal começou a aparecer o erro a baixo:

—————————
Crystal Reports
—————————
Erro de Conector de Banco de Dados: ‘HY000:[DataDirect][ODBC Oracle Wire Protocol driver][Oracle]ORA-01652: unable to extend temp segment by 128 in tablespace TEMP1 [Código do Fornecedor de Banco de Dados: 1652 ]’
—————————
OK
—————————

Não consigo compreender o por que de tal erro, pois não fiz nenhuma alteração no banco e nada, verifiquei se haviam criado alguma tabela na tablespace TEMP1, porém não achei nada alguém poderia me ajudar, por gentileza.

Att,
Manoel Jr.

[Manoel872Participante]

Pessoal descobri uma view q mostra os datafiles do meu tablespacce e veriquei o seguinte:

select BYTES/1024,USER_BYTES/1024,USER_BLOCKS from DBA_TEMP_FILES

512000 510976 63872

Ou seja eu tenho 512 mega e estou alocando 510 mega, porém não existe nada para esse tablespace de tabela como posso verificar o que esta consumindo o espaço dele e se possível aliviaro o tamanho.

Att,

Manoel

[abonacinParticipante]

Talvez ajude…

https://profissionaloracle.com.br/blogs/ … ablespace/

[Manoel872Participante]

[quote=”abonacin”:10fcxit9]Talvez ajude…

https://profissionaloracle.com.br/blogs/ … ablespace/[/quote]

Não ajuda muito pois essa tablespace e temporária e não existe nenhuma tabela vinculada a ela, porem por algum motivo ela ta ficando com 499 mega ocupada de 500 mega portando alguns de meus relatorios pararam de rodar.

Att,

Manoel

[eriveltonParticipante]


Tablespace Temporária, ou como nós conhecemos, TEMP, é utilizada para armazenar informações de ordenação (SORT) ou para armazenar dados de tabelas temporárias (CREATE TEMPORARY TABLE). A principio, a Tablespace Temporária tem seu lugar físico reservado no servidor, determinado pelo DBA, porém, sua principal função no banco de dados é auxiliar a memória do Oracle (SGA), em seu principal componente, o SORT_AREA_SIZE.


Você cria TEMPORARY TABLE ou executar sql na stored procedure?

Veja se alguma coisa assim está estourando o tamanho do temp;

Talvez vc tenha que aumentar o tamanho seu temp;

Uma query [usando order by] mau formulada também pode gerar isso (
join sem os critérios adequados gerando um produto cartesiano)

Veja link:

http://imasters.uol.com.br/artigo/3694/ … emporaria/

[Manoel872Participante]

[quote=”erivelton”:33nz0x9t]
Tablespace Temporária, ou como nós conhecemos, TEMP, é utilizada para armazenar informações de ordenação (SORT) ou para armazenar dados de tabelas temporárias (CREATE TEMPORARY TABLE). A principio, a Tablespace Temporária tem seu lugar físico reservado no servidor, determinado pelo DBA, porém, sua principal função no banco de dados é auxiliar a memória do Oracle (SGA), em seu principal componente, o SORT_AREA_SIZE.


Você cria TEMPORARY TABLE ou executar sql na stored procedure?

Veja se alguma coisa assim está estourando o tamanho do temp;

Talvez vc tenha que aumentar o tamanho seu temp;

Uma query [usando order by] mau formulada também pode gerar isso (
join sem os critérios adequados gerando um produto cartesiano)

Veja link:

http://imasters.uol.com.br/artigo/3694/ … emporaria/[/quote]

Meu problema é o seguinte não sei por que a temp esta ficando o tempo todo com 499 mega alocado ja parei o banco e reiniciei ele porem isso não muda Erivelton… Não consigo entender… tenho varias procedures cujo o custo dela esta alto e rodam e algumas não rodam a unica coisa que achei foi isso que a temp ta ficando com 499 mega alocado… existe alguma forma de liberar espaço sem que eu aumente o tamanho dela?

[eriveltonParticipante]

Veja as session’s que estão consumindo o temp:


SELECT s.username, tablespace, contents, extents
FROM v$session s, v$sort_usage
WHERE s.saddr = session_addr;


Com isso, você consegue identificar as sessões que usam o temp e
ver e por conseqüência os cursores abertos e sql.

link:

http://www.iselfschooling.com/FREE_Orac … son12.html

[Manoel872Participante]

[quote=”erivelton”:3b6jsqk9]Veja as session’s que estão consumindo o temp:


SELECT s.username, tablespace, contents, extents
FROM v$session s, v$sort_usage
WHERE s.saddr = session_addr;


Com isso, você consegue identificar as sessões que usam o temp e
ver e por conseqüência os cursores abertos e sql.

link:

http://www.iselfschooling.com/FREE_Orac … son12.html[/quote]

Herivelton,

Fiz um select e o sistema não traz nenhum resultado… hoje no horário do almoço fiz o backup frio do BD qndo subi o serviço novamente fiz o select para verificar o tamanho da TMP e estava consumindo os 499 MB mesmo apos ter parado e nenhum usuario conectado.

Att,

Manoel Jr.

[eriveltonParticipante]

Só resultará quando alguma sessão estiver usando o temp, neste
caso retorno vazio, então nenhuma sessão estava usando.

Quando der a exceção execute a query e veja quais sessões estão causando o problema;

[Manoel872Participante]

[quote=”erivelton”:2drvgped]Só resultará quando alguma sessão estiver usando o temp, neste
caso retorno vazio, então nenhuma sessão estava usando.

Quando der a exceção execute a query e veja quais sessões estão causando o problema;[/quote]

select BYTES/1024/1024,USER_BYTES/1024/1024,USER_BLOCKS from DBA_TEMP_FILES

Mais olha só mesmo qndo eu executo esse sql q vc me passou e nao retorna nenhuma linha e executo esse meu ele diz que esta sendo utilizado 499 MB do espaço da TEMP eu estou interpretando essas informações de forma errada ou não?

Att,

Manoel Jr.

[IshiiParticipante]

Olá,

Acho que o problema está na query que esta sendo montada pelo Crystal. Dependendo da query montada, pode ou não consumir a área temporária. O problema ocorre na execução da query pelo Crystal mas não pelo BD direto. Acho melhor analisar o que o Crystal está executando (e como) e qual a query que está com problema. A área temporária deve analisada depois de se ter certeza que a query está ok. Poste aqui ou uma parte da procedure ou a query com problema, pela sua primeira mensagem eu priorizaria a procedure mesmo.

[]s Ishii

[Manoel872Participante]

[quote=”Ishii”:36s8wy3r]Olá,

Acho que o problema está na query que esta sendo montada pelo Crystal. Dependendo da query montada, pode ou não consumir a área temporária. O problema ocorre na execução da query pelo Crystal mas não pelo BD direto. Acho melhor analisar o que o Crystal está executando (e como) e qual a query que está com problema. A área temporária deve analisada depois de se ter certeza que a query está ok. Poste aqui ou uma parte da procedure ou a query com problema, pela sua primeira mensagem eu priorizaria a procedure mesmo.

[]s Ishii[/quote]

Achei o seguinte… deem uma olhada:

Não uso OEM, então não sei exatamente o que faz a tal “consulta” que vc diz que fez nele , mas penso que deve estar acontecendo o seguinte : as tablespaces temporárias são criadas e usadas duma maneira especial, pra maior performance. É assim : o banco mantém uma lista internamente dos “pedaços” em uso dentro da tablespace temporária, e quando uma sessão pede por espaço, esse espaço é removido dessa lista, e ao fim do uso ele volta a constar da lista. PORÉM, esse espaço que não está mais em uso *** NÂO *** é apagado, removido do disco, simplesmente ele volta a estar marcado como LIVRE na lista interna, quando outra sessão o for usar, simplesmente vai escrever por cima do que havia antes. Essa lista interna é a V$SORT_USAGE.
Então é isso, se vc criar uma tablespace temporária de (diagmos) 100 Mb, em disco sempre vão estar os 100 Mb, o fato dele não diminuir fisicamente quando não estar em uso significa ENORME economia de I/O pro Oracle. Imagino que é isso que aconteceu, vc está (erradamente) usando uma consulta no OEM que mostra espaço físico em disco, isso NÂO é válido pra tablespaces temp, a utilização real fica na V$SORT_USAGE.

Minha SP:

SELECT
‘FATURAMENTO’ AS GRH1
, A1_VEND
, A1_VENDNOM
, A1_COD
, C5_TIPO
, C5_CLAPED
, A1_NOME
, A1_NREDUZ
, A1_MUN
, A1_EST
, A1_CODMUN
, C5_BLQ
, CASE WHEN F4_TIPSAID IN (‘E’,’R’,’V’,’Y’,’S’) THEN SUM(D2_TOTAL+D2_VALIPI) ELSE 0 END AS VALORTOTAL
, CASE WHEN F4_TIPSAID IN (‘T’) THEN SUM(D2_TOTAL+D2_VALIPI) ELSE 0 END AS VALORASSISTENCIA
, CASE WHEN F4_TIPSAID IN (‘B’) THEN SUM(D2_TOTAL+D2_VALIPI) ELSE 0 END AS VALORBONIFICADO
, D2_COD
, CASE WHEN F4_TIPSAID IN (‘E’,’R’,’V’,’Y’,’S’) THEN SUM(B1_CUTMAN * D2_QUANT) ELSE 0 END AS CUSTOVALORTOTAL
, CASE WHEN F4_TIPSAID IN (‘T’) THEN SUM(B1_CUTMAN * D2_QUANT) ELSE 0 END AS CUSTOVALORASSISTENCIA
, CASE WHEN F4_TIPSAID IN (‘B’) THEN SUM(B1_CUTMAN * D2_QUANT) ELSE 0 END AS CUSTOVALORBONIFICADO
— , SX5b.X5_DESCRI
— , E1_TOTAL
— , E1_SALDO
, F2_DOC
, F2_SERIE
, 0 AS VALORDEV
, F4_TIPSAID
, D2_TES
, 0 AS CTRECEBER_SALDO
, ‘ ‘ AS CTRECEBER_VENC
, 0 AS CLI_LMT_CREDITO
, ‘ ‘ AS CR_SITUACAOTITULO
, SA1.R_E_C_N_O_
FROM SYSTEM.SC6010 SC6

INNER JOIN SYSTEM.SC5010 SC5 
  ON C6_FILIAL = C5_FILIAL 
  AND C6_NUM = C5_NUM 
  AND SC6.D_E_L_E_T_ = SC5.D_E_L_E_T_

INNER JOIN  (SELECT A1_VEND,R_E_C_N_O_,A1_LOJA, A1_VENDNOM, A1_COD, A1_NOME, A1_NREDUZ, A1_MUN, A1_EST, A1_CODMUN,D_E_L_E_T_  FROM SYSTEM.SA1010 SA1) SA1
  ON C5_CLIENTE  = A1_COD 
  AND C5_LOJACLI = A1_LOJA 
  AND SC5.D_E_L_E_T_ = SA1.D_E_L_E_T_


LEFT OUTER JOIN SYSTEM.SD2010 SD2 
    ON SC6.C6_FILIAL = SD2.D2_FILIAL 
    AND SC6.C6_NUM = SD2.D2_PEDIDO 
    AND SC6.C6_ITEM = SD2.D2_ITEMPV 
    AND SC6.C6_PRODUTO = SD2.D2_COD 
    AND SD2.D_E_L_E_T_  '*'

INNER JOIN (SELECT B1_CUTMAN,B1_FILIAL,B1_COD FROM SYSTEM.SB1010) SB1 
    ON SD2.D2_FILIAL = SB1.B1_FILIAL 
    AND SD2.D2_COD = SB1.B1_COD     

INNER JOIN SYSTEM.SF4010 SF4 
    ON SD2.D2_FILIAL = SF4.F4_FILIAL 
    AND SD2.D2_TES = SF4.F4_CODIGO       

LEFT OUTER JOIN (SELECT F2_FILIAL,F2_DOC,F2_TIPO,F2_CLIENTE,F2_VALBRUT,F2_SERIE,D_E_L_E_T_,F2_EMISSAO FROM SF2010 SF2 WHERE D_E_L_E_T_'*')  SF2 
    ON SD2.D2_FILIAL = SF2.F2_FILIAL 
    AND SD2.D2_DOC   = SF2.F2_DOC 
    AND SD2.D2_SERIE = SF2.F2_SERIE  
    AND SF2.D_E_L_E_T_ '*'

/* LEFT OUTER JOIN (SELECT E1_SITUACA,E1_NUM,E1_SERIE,D_E_L_E_T_,SUM(E1_VALOR + E1_ACRESC – E1_DECRESC) OVER (PARTITION BY E1_NUM,E1_SERIE,E1_SITUACA) AS E1_TOTAL, SUM(E1_SALDO) OVER (PARTITION BY E1_NUM,E1_SERIE,E1_SITUACA) AS E1_SALDO
FROM SYSTEM.SE1010 WHERE D_E_L_E_T_’‘) SE1
ON SF2.F2_DOC = E1_NUM
AND SF2.F2_SERIE = E1_SERIE
AND SE1.D_E_L_E_T_ ‘‘

LEFT OUTER JOIN SX5010 SX5b ON
  SX5b.X5_CHAVE = E1_SITUACA
  AND SX5b.X5_TABELA = '07'
  AND SX5b.D_E_L_E_T_  '*'   */

WHERE F2_EMISSAO BETWEEN to_char(pData1,’yyyymmdd’) AND to_char(pData2,’yyyymmdd’)
AND F2_CLIENTE BETWEEN pRca1 AND pRca2
AND F2_TIPO = ‘N’
AND F4_TIPSAID IN (‘E’,’R’,’V’,’Y’,’S’,’T’,’B’)

GROUP BY
A1_VEND
, A1_VENDNOM
, A1_COD
, C5_TIPO
, C5_CLAPED
, A1_NOME
, A1_NREDUZ
, A1_MUN
, A1_EST
, A1_CODMUN
, C5_BLQ
, D2_COD
, D2_TOTAL+D2_VALIPI
, B1_CUTMAN * D2_QUANT
— , SX5b.X5_DESCRI
— , E1_TOTAL
— , E1_SALDO
, F2_DOC
, F2_SERIE
, F4_TIPSAID
, D2_TES
, SA1.R_E_C_N_O_
UNION ALL

SELECT
‘VENDAS’ AS GRH1
, A1_VEND
, A1_VENDNOM
, A1_COD
, ‘ ‘
, ‘ ‘
, A1_NOME
, A1_NREDUZ
, A1_MUN
, A1_EST
, A1_CODMUN
, ‘ ‘
, 0 AS VALORTOTAL
, 0 AS VALORASSISTENCIA
, 0 AS VALORBONIFICADO
, ‘ ‘
, 0 AS CUSTOVALORTOTAL
, 0 AS CUSTOVALORASSISTENCIA
, 0 AS CUSTOVALORBONIFICADO
, ‘ ‘
, ‘ ‘
— , ‘ ‘
— , 0
— , 0
, SUM(D1_TOTAL+D1_VALIPI) AS VALORDEV
, ‘ ‘
, ‘ ‘
, 0 AS CTRECEBER_SALDO
, ‘ ‘ AS CTRECEBER_VENC
, 0 AS CLI_LMT_CREDITO
, ‘ ‘ AS CR_SITUACAOTITULO
, SA1.R_E_C_N_O_
FROM SYSTEM.SD1010 SD1
INNER JOIN SYSTEM.SF1010 SF1 ON SD1.D1_FILIAL = SF1.F1_FILIAL AND SD1.D1_DOC = SF1.F1_DOC AND SD1.D1_SERIE = SF1.F1_SERIE AND SD1.D1_FORNECE = SF1.F1_FORNECE AND SD1.D1_LOJA = SF1.F1_LOJA
INNER JOIN SYSTEM.SF4010 SF4 ON SD1.D1_FILIAL = SF4.F4_FILIAL AND SD1.D1_TES = SF4.F4_CODIGO
INNER JOIN SYSTEM.SB1010 SB1 ON SD1.D1_FILIAL = SB1.B1_FILIAL AND SD1.D1_COD = SB1.B1_COD
INNER JOIN SYSTEM.SBM010 SBM ON SB1.B1_FILIAL = SBM.BM_FILIAL AND SB1.B1_GRUPO = SBM.BM_GRUPO
INNER JOIN SYSTEM.SA1010 SA1 ON SF1.F1_FORNECE = SA1.A1_COD AND SF1.F1_LOJA = SA1.A1_LOJA
LEFT JOIN SYSTEM.SF2010 SF2 ON SD1.D1_FILIAL = SF2.F2_FILIAL AND SD1.D1_NFORI = SF2.F2_DOC AND SD1.D1_SERIORI = SF2.F2_SERIE AND SD1.D1_FORNECE = SF2.F2_CLIENTE AND SD1.D1_LOJA = SF2.F2_LOJA AND SF2.D_E_L_E_T_ ‘‘
LEFT JOIN SYSTEM.SA3010 SA3 ON SF2.F2_VEND1 = SA3.A3_COD AND SA3.D_E_L_E_T_ ‘‘
LEFT JOIN SYSTEM.ACY010 ACY ON A1_GRPVEN = ACY_GRPVEN AND ACY.D_E_L_E_T_ ‘‘
WHERE SD1.D1_DTDIGIT BETWEEN to_char(pData1,’yyyymmdd’) AND to_char(pData2,’yyyymmdd’)
AND F1_FORNECE BETWEEN pRca1 AND pRca2
AND F1_TIPO = ‘D’
AND F4_TIPENT = ‘V’
AND SD1.D_E_L_E_T_ ‘‘
AND SF1.D_E_L_E_T_ ‘‘
AND SF4.D_E_L_E_T_ ‘‘
AND SB1.D_E_L_E_T_ ‘‘
AND SBM.D_E_L_E_T_ ‘‘
AND SA1.D_E_L_E_T_ ‘*’
GROUP BY
A1_VEND
, A1_VENDNOM
, A1_COD
, A1_NOME
, A1_NREDUZ
, A1_MUN
, A1_EST
, A1_CODMUN
, D1_TOTAL+D1_VALIPI
, SA1.R_E_C_N_O_

Mais tem um fato muito peculiar nisso tudo… o meu report tem hora q fica rapido processa o BD inteiro em questão de segundo e tem hora q fica lento e começa a estorar a tablespace não sei mais oq pensar….

Att,

Manoel Jr.

[vieriParticipante]

Utilize este script apra detectar as execuções longas.

PROMPT ======================================================================
PROMPT ======================================================================
PROMPT EXECUÇÔES LONGAS
PROMPT ======================================================================

SET LINESIZE 200
COLUMN sid FORMAT 9999
COLUMN serial# FORMAT 9999999
COLUMN machine FORMAT A30
COLUMN progress_pct FORMAT 99999999.00
COLUMN elapsed FORMAT A10
COLUMN remaining FORMAT A10

SELECT s.inst_id,
s.sid,
s.serial#,
s.username,
s.module,
ROUND(sl.elapsed_seconds/60) || ‘:’ || MOD(sl.elapsed_seconds,60) elapsed,
ROUND(sl.time_remaining/60) || ‘:’ || MOD(sl.time_remaining,60) remaining,
ROUND(sl.sofar/sl.totalwork*100, 2) progress_pct
FROM gv$session s,
gv$session_longops sl
WHERE s.sid = sl.sid
AND s.inst_id = sl.inst_id
AND s.serial# = sl.serial#;

Conselho:
Coloca logo essa temp com 3Gb.
e coloque o parâmetro sort_area_size
para 1Mb e veja se terás melhorias.

obs: Existem N maneiras de identificar lentidão.
uma boa opão é utilizar o tunnig pack do dbconsole,
e verificar no gráfico quais eventos(waits)
estão consumindo mais recursos na instância e qual o processo oriundo disto.

Outra opção é o statspack , awr , addm … mas tudo exige experiência e
literatura para implementar e interpretar.

8)

[IshiiParticipante]

Olá,

Pelo que pude notar o BD está usando o TEMP para os Group by e case when … then sum , esta proc faz algum insert em alguma tabela temporária tb?

As tabelas contém muitos registros? Pelo que me lembro do Microsiga as colunas são todas CHAR e se a coluna tem CHAR(100) mesmo que vc use 20 o banco aloca as 100, isso pode estar contribuindo para que o espaço utilizado seja grande mesmo.

Basicamente a TEMP é como uma área de SWAP, o Oracle tenta usar na Memoria (SGA) e se não der, usa a TEMP para o swap mesmo.

Outra questão que pode explicar a lentidão… as tabelas estão com OWNER System mesmo? Se for isso mesmo algo está errado e vc deve comunicar ao DBA para remover estas tabelas do System até porque devem estar usando a Tablespace SYSTEM também…

[]s Ishii

[Manoel872Participante]

Acredito que solucionei o problema o erro era mais de query… se vc ver… eu coloquei um relacionamento left outer join e fiz um filtro pelas tabelas left outer join ou seja a minha tabela principal acabou q fazia um full table scan e trazia tudo….

[Autor]

Posts