none
Indexes in temporary tables RRS feed

  • Pergunta

  • Hello!

    I created a temporary table to improve my query performance, because it uses the same table with the same filters
    repeatedly a lot of times within it.

    So, after I created the temporary table, I create some indexes on it. But my performance didn't get improved. I don't know why.

    The temporary table contains approximately 248.459 registers, while the original table has 4.964.736, and I use this table almost fifteen times in my procedure.

    I think this is because the indexes that I loose when I not use the original table. Do you have any idea?
    sexta-feira, 2 de janeiro de 2009 16:30

Todas as Respostas

  • Hi Cristianne,
    Did you already verified if you have another issue instead indexies problems?
     
    Try to verify problems like:
    * A lock within another table that has been paticipated to the query. 
    * Lack of a statistics.
    * Inaproprieted indexies.
    * Convert functions on query.
     
    Didn't you have been tried to use a profile or DTA  to verify this issues?
     
    I think that you as MCITP in BI have no dificulty to findout a workaround.

     

    sexta-feira, 2 de janeiro de 2009 18:28
  • Olá Cris,

     

    Até poderiamos continuar a discussão em Inglês, mas para que participantes do Forum BRASIL que não tenham conhecimento em Inglês possa entender, vou escrever em Portugues.

     

    Na proxima vez, sugiro que inicie a discussão em Portugues, como já foi sugerido a você anteriormente por outros participantes.

     

    Agora falando de forma direta a sua questão, fiquei com uma duvida:

     

    Você não obteve ganho de desempenho quando passou a usar a temp table ao inves da tabela original?

    ou

    Você não obteve ganho de desempenho quando passou a usar a temp table com indices ao inves da temp table sem indice?

     

    e

     

    Que tipo de uso tem a temp table: consulta, alteração de dados, etc.?

     

    sexta-feira, 2 de janeiro de 2009 19:10
  • Boa Tarde,


    Considerando que foi utilizado o termo "registers" ao invés de "records" estou certo que o autor da dúvida não deve se tratar de alguém cujo o idioma nativo seja a língua inglesa. Nesse caso, a recomendação do Alex é totalmente válida. Caso o idioma nativo não seja português, o mais recomendável é procurar o fórum MSDN mais adequado através do link abaixo:


    http://forums.microsoft.com


    After seeing the term "registers" instead of "records", I'm sure that the owner's doubt is not someone who talks english natively. In this case, the Alex's recommendation is absolutely valid. If the native language was not portuguese, the best way is to look for the most suitable using the link down:


    http://forums.microsoft.com


    Se não há ganhos de desempenho após usar a tabela temporária, é porque possivelmente o custo em criar os índices não compensa às vezes em que ela for utilizada (principalmente se você for utilizá-la em sua totalidade) já que após criar a tabela temporária, provavelmente suas páginas já estarão em memória ou que talvez os índices não sejam úteis para as pesquisas a serem realizadas.


    Considere também o fato de que caso as consultas estejam em uma stored procedure, a presença de índices irá provocar necessariamente uma recompilação e que se a stored procedure for muito longa, essa recompilação pode ser prejudicial.


    Você poderia dar mais detalhes ?


    [ ]s,


    Gustavo

    sexta-feira, 2 de janeiro de 2009 20:56
  •  

    Dependendo do uso da temporaria seria mais interessante usar uma view indexada, ( nao sei com vc. monta a temporaria ), mais indice em temporarias nao e muito comum em procedimentos que sao executados varias vezes.

     

    Abs.

    segunda-feira, 5 de janeiro de 2009 09:48
  • Colla,

     

    Na verdade qual é a dúvida, criar um índice sobre uma table temporária, ou entender se o uso de índice sobre uma temporária table poderá ocasionar perda de performance?

    segunda-feira, 5 de janeiro de 2009 10:18
  • Eu acesso uma tabela muito grande várias vezes dentro de uma stored procedure, com os mesmos filtros. Então eu pensei em criar uma tabela temporária com os filtros usados, e acessar essa tabela temporária ao invés de usar a tabela original, o que reduz a quantidade de registros drasticamente.

    Porém ao fazer isso, a minha performance não melhorou em nada, o que me fez crer que isso se deve à falta de índices na tabela temporária, índices esses que existiam na tabela original.

    Criei os índices na tabela temporária (dentro da stored procedure) e também não ganhei desempenho com isso.
    segunda-feira, 5 de janeiro de 2009 18:14
  • Olá Cristianne,

     

    Acho que sua idéia está correta e à primeira vista é uma excelente idéia. A questão é que não basta expor apenas os benefícios. Mesmo sendo uma ótima idéia, ela tem pontos fracos.

     

    Utilizar os registros em uma tabela temporária irá diminuir os acessos e o tempo de resposta nas consultas, mas lembre-se que será necessário "materializar" esses registros e que se sua tabela temporária tem muitos registros, o tempo de escrita pode superar as perdas nas consultas diretas às tabelas de origem.

     

    Criar índices na tabela temporária irá acelerar as pesquisas em um universo que já é menor que as tabelas permanentes, mas a criação de índices irá gastar algum tempo e esse tempo pode ser superior ao tempo das consultas sem os índices por exemplo.

     

    Se o código está dentro de uma SP, o melhor a fazer é medir o tempo dos passos individuais para posterior análise. Você pode iniciar o Profiler com o evento StoredProcedureTongue TiedtmtCompleted para verificar quanto cada passo da SP demora para executar. De posse desses tempos, verificar se realmente vale a pena criar tabelas temporárias e índices nessas tabelas ou utilizar as tabelas permanentes diretamente.

     

    Se o foco não for escolher o melhor das duas alternativas, mas sim melhorar o tempo de resposta utilizar uma View Indexada pode ser um ponto interessante conforme orientado.

     

    Independente disso, algo me chamou a atenção ? Será que não haveria uma forma de você ler uma vez só ? É necessário ler várias vezes o mesmo conjunto de registros ?

     

    [ ]s,

     

    Gustavo

    segunda-feira, 5 de janeiro de 2009 20:24
  • É necessário ler várias vezes sim... essa SP é enorme e as regras de negócio são bem complexas! Eu já analisei os tempos já, e a minha ultima esperança de aumento de performance era essa, pq no restante está muito dificil conseguir alguma melhoria. Vou ver o que posso fazer. Qualquer novidade posto aqui.

    Obrigada!
    segunda-feira, 5 de janeiro de 2009 22:31
  • Olá Cristianne,

     

    Eu recomendo seguir as orientações do Trace para capturar os tempos de cada passo da sp. Talvez haja um gargalo maior em algum outro ponto que não esteja mapeado. Pode ser que suas implementações possam ter dado resultado, mas se o gargalo for outro ponto, a melhora pode não ser visível.

     

    [ ]s,

     

    Gustavo

    segunda-feira, 5 de janeiro de 2009 23:38