none
View indexada - Consulta direto aos dados sem acessar tabelas RRS feed

  • Pergunta


  • Sera que é uma boa criar uma view indexada (para materializar a consulta), e fazer com que o engine busque os dados diretamente nela, ao inves de ir para as tabelas?

    Na verdade eu tenho ideia de fazer isso, para resolver um problema de "acumuladores" (atualmente, tem uma função no sistema em que obriga o BD a percorrer um longo periodo em uma tabela).
    Achei esse topico:
    http://social.msdn.microsoft.com/forums/pt-br/520/thread/02A8C17B-E3CF-4FF4-9338-A792C8269731
    o qual achei fantastico, muito informativo, 
    porém, me surgiram duvidas em relação ao real beneficio, se "é assim mesmo que funciona" a view materializada.

    Como posso fazer para verificar e "garantir" que o sistema esteja realmente obtendo dados diretamente da view, e não indo às tabelas? com o uso do profiler?
    Sera que isso vai impactar muito na inserção de registros, e quais seriam formas de amenizar isso? (exemplo, FATOR de preenchimento do indice clusterizado da View)

    Julio C.

    quarta-feira, 17 de abril de 2013 12:43

Respostas

  • Julio,

    Se entendi bem o que voce quer fazer é uma agregação é isso? Fique tranquilo quanto a isso pois funções de agregação com os indices corretos em SQL Server são bem performaticas, tenha certeza de criar um indice nas colunas que estarão no group by de sua query e caso seja um SUM de algum campo, adicione tal campo como include deste indice e voce não terá problema de performance ao realizar o select e nem ao realizar inserts/updates/deletes como teria na view indexada.


    Fabrizzio A. Caputo
    MCT
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    ITIL V3 Foundation
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Email: fabrizzio.antoniaci@gmail.com

    • Marcado como Resposta Julio Costi quinta-feira, 18 de abril de 2013 14:51
    quinta-feira, 18 de abril de 2013 12:56
    Moderador
  • Deleted
    • Marcado como Resposta Julio Costi quinta-feira, 18 de abril de 2013 14:51
    quinta-feira, 18 de abril de 2013 14:11
  • Julio,

    Um detalhe é importante, quando criamos um view indexada, valor ressaltar que o índice que esta amarrado a view tem impacto direto a tabela física que a view esta vinculada.

    Isso poderá gerar sobrecarga de processamento quando realizamos um Insert, Update ou Delete diretamente na tabela, pois a mesma possui um índice que tem que ser processado e atualizado para atender a view. 


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    • Marcado como Resposta Julio Costi quinta-feira, 18 de abril de 2013 18:26
    quinta-feira, 18 de abril de 2013 17:09

Todas as Respostas

  • Julio,

    Voce garante o acesso a view colocando a view no FROM de sua query, agora a view por sua vez fará o acesso as tabelas, pois fisicamente os dados estão nas paginas da tabela.

    Por exemplo, o que é mais performatico?

    SELECT *
    FROM Tabela

    Ou

    CREATE VIEW dbo.ViewTabela
    AS
    SELECT *
    FROM Tabela
    
    SELECT *
    FROM ViewTabela

    Nenhuma das 2, pois não há diferença pois a unica coisa que a view te fez foi abstrair a codificação, então em 99% dos casos utilizar uma view direta assim não terá melhora ou piora!

    Haverá piora na utilização da view quando a mesma for utilizada para um join externo ou alguma coisa assim, pois a estrutura da view não possui indices, então a view clusterizada veio para tentar amenizar essa situação, lembrando que pode apenas ser um indice cluster.


    Fabrizzio A. Caputo
    MCT
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    ITIL V3 Foundation
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Email: fabrizzio.antoniaci@gmail.com

    quarta-feira, 17 de abril de 2013 13:20
    Moderador
  • Ola, Fabrizzio

    o que me referi é mais ou menos algo no sentido que o Gustavo Maia colocou no referido post:

    "Possivelmente os índices estão sendo utilizados já que no momento de compilar a consulta, o código SQL da View é traduzido e a tabela é consultada. Não há necessidade de criar índices em Views se a view é apenas um SELECT de uma tabela. Seria útil criar índices na View se a View tivesse combinando várias tabelas (assim a leitura seria feita diretamente da View sem ir nas tabelas através da materialização das Views ou melhor dizendo Views indexadas).

    Para confirmar, abra o SQL Server Management Studio, pressione CTRL + M (se for Query Analyser é CTRL + K) e execute sua consulta. Você deve visualizar leituras de índices sobre as tabelas."
    (meu grifo)


    Julio C.

    quarta-feira, 17 de abril de 2013 14:01
  • Julio,

    Isso mesmo, voce terá os dados armazenados, veja esses links:

    Explicação geral: http://msdn.microsoft.com/en-us/library/ms191432(v=sql.105).aspx

    Explicação especifica sobre sua duvida: http://msdn.microsoft.com/en-us/library/ms187864(v=sql.105).aspx


    Fabrizzio A. Caputo
    MCT
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    ITIL V3 Foundation
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Email: fabrizzio.antoniaci@gmail.com

    quarta-feira, 17 de abril de 2013 14:08
    Moderador
  • Se os dados ficam "materializados" na view, a cada inserção ela é atualizada?

    E então, a busca dos não seria diretamente na propria View, ou mesmo assim, vai às tabelas?

    eu achei outro comentario, naquele mesmo topico:

    "Importante é lembrar o custo de um view indexada na manutenção de registros das tabelas associadas a view (basicamente o dobro do tempo causando queda de performance em Inserts, Deletes e Updates)"

    e com isso, pergunto: definindo um fator de preenchimento para o indice clustered da view, tende a amenizar o problema?

    Valeu!


    Julio C.

    quarta-feira, 17 de abril de 2013 14:47
  • Julio,

    Tende a, isso não quer dizer que va melhorar 100%, principalmente pelo fato de que a inserção/atualização da pagina será feita com um fill_factor maior o que voce diminui é o tempo ou a necessidade de reorganização em disco dessas paginas.


    Fabrizzio A. Caputo
    MCT
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    ITIL V3 Foundation
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Email: fabrizzio.antoniaci@gmail.com

    quarta-feira, 17 de abril de 2013 14:51
    Moderador
  • Mas de qualquer forma, ou eu faço isso

    1. view indexada

    2. ou eu precisaria gravar em uma tabela de acumuladores (ou via programação, ou com trigger no BD.. enfim, tem o custo de RECALCULAR o saldo).

    Essa tabela, no final das contas, teria a mesma chave da view indexada, e com as mesmas desvantagens (fragmentação do indice a cada inserção), pelo menos até onde eu entendi, seria isso.

    Por isso a solução 1, view indexada, seria a solução mais pratica, ao meu ver, pois as desvantagens (custo) seriam as mesmas, e não tenho que me preocupar com a inserção, pois ela vai se atualizar, sempre.

    é isso?

    mas enfim, eu só queria saber se a tal view indexada funcionaria mesmo dessa forma.. sem acessar as tabelas diretamente e sim, armazenando o resultado.

    • Editado Julio Costi quarta-feira, 17 de abril de 2013 18:18
    quarta-feira, 17 de abril de 2013 18:15
  • Julio,

    Se entendi bem o que voce quer fazer é uma agregação é isso? Fique tranquilo quanto a isso pois funções de agregação com os indices corretos em SQL Server são bem performaticas, tenha certeza de criar um indice nas colunas que estarão no group by de sua query e caso seja um SUM de algum campo, adicione tal campo como include deste indice e voce não terá problema de performance ao realizar o select e nem ao realizar inserts/updates/deletes como teria na view indexada.


    Fabrizzio A. Caputo
    MCT
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    ITIL V3 Foundation
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Email: fabrizzio.antoniaci@gmail.com

    • Marcado como Resposta Julio Costi quinta-feira, 18 de abril de 2013 14:51
    quinta-feira, 18 de abril de 2013 12:56
    Moderador
  • Deleted
    • Marcado como Resposta Julio Costi quinta-feira, 18 de abril de 2013 14:51
    quinta-feira, 18 de abril de 2013 14:11
  • Hum isso é muito bom saber Fabrizzio... legal

    Realmente é algo que não está causando problemas, atualmente.. as consultas estão satisfatorias.. a principio tem indices criados para as colunas de agrupamento, mas vou rever tudo isso para confirmar.

    Só é importante ainda dizer que , no caso, são agrupamentos para o fim de gerar acumuladores (sum) que o sistema precisa para "puxar" os saldos de varios anos atras..

    Mesmo assim, voce diria que não existem grandes preocupações com a performance em querys dessa forma, logo, nesse momento não teria que resolver isso (nem com view, nem com tabela de acumuladores atualizada a cada insert)?.

    Tou pedindo apenas como uma ideia mesmo, baseando-se apenas nessas informações... claro a decisão no final vai requerer analisar a situação bem especificamente.

    Obrigado mesmo!


    Julio C.

    quinta-feira, 18 de abril de 2013 14:56
  • Ah, e imagino q definir um fator de preenchimento para estes indices, neste caso, seria interessante, não é? pois os indices das colunas sob as quais vai haver agregação não são clusterizados.

    • Editado Julio Costi quinta-feira, 18 de abril de 2013 14:57
    quinta-feira, 18 de abril de 2013 14:57
  • Perfeita essa definição José, buscava algo que explicasse nesse sentido... Vou analisar se vale a pena, já estou lidando com o otimizador de querys do SQL Server.


    Julio C.

    quinta-feira, 18 de abril de 2013 14:59
  • Julio,

    Um detalhe é importante, quando criamos um view indexada, valor ressaltar que o índice que esta amarrado a view tem impacto direto a tabela física que a view esta vinculada.

    Isso poderá gerar sobrecarga de processamento quando realizamos um Insert, Update ou Delete diretamente na tabela, pois a mesma possui um índice que tem que ser processado e atualizado para atender a view. 


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    • Marcado como Resposta Julio Costi quinta-feira, 18 de abril de 2013 18:26
    quinta-feira, 18 de abril de 2013 17:09
  • Junior,

    poisé, eu li sobre isso.. porém, pensando no futuro dessa tabela, quando começar a ficar com um volume muito grande de registros, talvez fique inviavel consultar o saldo lendo toda ela de forma agrupada (mesmo com indices), pelo seguinte, é uma consulta bem rotineira...

    Então, ou faço uma tabela com acumuladores, para atualizar via comandos sql ou triggers no BD; ou faço essa view indexada.

    Quanto a tabela de acumuladores de saldo, teria indice clusterizado, que o no final imagino que teria o mesmo "custo" da view indexada, ou seja, cada inserção recalcular o saldo novamente...

    Meu proximo pasos é analisar exatamente o que ocorre no BD, nas diversas situações.


    Julio C.

    quinta-feira, 18 de abril de 2013 20:45