none
Gerenciamento de Performance do SQL-SERVER RRS feed

  • Pergunta

  • Antes de iniciar minhas dúvidas gostaria de dizer que o meu conhecimento em SQL-SERVER é bem pequeno. Utilizo nada mais do que o básico, um pouco de T-SQL, algumas procedures e functions e uma base de dados com FKs e Index. Não mais do que isso.

    A minha dúvida inicia justamente por achar que o SQL-SERVER é uma ferramenta muito poderosa para usar apenas isso, hoje nas minhas aplicações trazemos todo o tipo de processamento para programas .NET C# fazerem o trabalho, utilizando apenas consultas (selects) no SQL-SERVER, com o receio de criar um "gargalo" no banco de dados, aonde é o ponto que temos menos conhecimento do que em .NET C#.

    Possuímos em um servidor o SQL-SERVER com as características que eu disse acima. Praticamente apenas um repositório de dados. O maior processamento que fazemos é uma consulta com muitos joins e t-sql.

    Todas as informações são solicitadas do SQL-SERVER por um WindowsService. Toda a nossa regra está centralizada nesse windowservice, que acessamos via remoting. As rotinas de processamento pesado são feitas por "robôs", aplicativos C# que são chamados pelo windowsservice. Com isso podemos distribuir os processamentos em vários aplicativos executando em paralelo com um servidor com muitos núcleos. E para uma situação mais grave ainda podemos replicar esse windowsservice em vários servidores, aumentando a capacidade de processamento em máquina e evitando qualquer tipo de "gargalo" no banco de dados.

    A minha dúvida é:

    Poderíamos passar muito processamento que é feito em c# para procedures no SQL-SERVER. Mas, caso começamos a ter algum tipo de "gargalo" de processamento do SQL-SERVER, quais são as alternativas do SQLSERVER? O que posso fazer? Posso distribuir o SQL-SERVER em mais de 1 servidor físico para processamento?

    Não sei se consegui ser bem claro com a minha dúvida, mas basicamente é saber se vale a pena utilizar mais processamento dentro do próprio SQL-SERVER.

    Quais são os benefícios do SQL-SERVER, que ferramentas possuímos no SQL-SERVER para distribuição de processamento, como proceder em um caso de "gargalo" no banco?

    Obrigado pessoal!!

    Atenciosamente,

    Eduardo


    quarta-feira, 3 de julho de 2013 19:38

Respostas

  • Olá Eduardo!

    Poderíamos passar muito processamento que é feito em c# para procedures no SQL-SERVER. Mas, caso começamos a ter algum tipo de "gargalo" de processamento do SQL-SERVER, quais são as alternativas do SQLSERVER? O que posso fazer? Posso distribuir o SQL-SERVER em mais de 1 servidor físico para processamento?

    O SQL Server não foi uma ferramenta desenvolvida para rodar simultaneamente em mais de um servidor, o que ele consegue fazer com as queries mais pesadas é paralelizar a execução dos mesmos entre os processadores, ele quebra a execução das queries e distribui entre os processadores para que consiga processa-las mais rápido, obvio que existem outros mecanismos mas quanto a paralelização do trabalho seria esta a melhor resposta.

    Não sei se consegui ser bem claro com a minha dúvida, mas basicamente é saber se vale a pena utilizar mais processamento dentro do próprio SQL-SERVER.

    O mais indicado aqui seria você testar o SQL Server, estressar ele com as queries que pretende colocar em produção e ver o seu comportamento. Lembrando que o SQL Server tem algumas configurações a serem seguidas, como por exemplo a quantidade de memória que ele podera utilizar do servidor, discos distintos para os arquivos das bases ajudam na performance etc.

    Quais são os benefícios do SQL-SERVER, que ferramentas possuímos no SQL-SERVER para distribuição de processamento, como proceder em um caso de "gargalo" no banco?

    Primeiramente você precisaria identificar o gargalo (rede? disco? memória) para depois seguir uma linha de raciocinio, algumas ferramentas de monitoração poderiam lhe auxiliar (SQLDIAG, PERFMON, PROFILER). Hoje na internet existe bastante coisa para troubleshotting caso você queira se aprofundar, adianto que não é algo muito simples de entender, o SQL Server realmente é bastante complexo!

    Se precisar de mais alguma informação só dizer!

    Um abraço!


    Regards,

    André César Rodrigues

    Please click the Mark as answer button and vote as helpful if this reply solves your problem. Thanks!

    Blog: http://sqlmagu.blogspot.com.br  LinkedIn:   


    quarta-feira, 3 de julho de 2013 21:48

Todas as Respostas

  • Olá Eduardo!

    Poderíamos passar muito processamento que é feito em c# para procedures no SQL-SERVER. Mas, caso começamos a ter algum tipo de "gargalo" de processamento do SQL-SERVER, quais são as alternativas do SQLSERVER? O que posso fazer? Posso distribuir o SQL-SERVER em mais de 1 servidor físico para processamento?

    O SQL Server não foi uma ferramenta desenvolvida para rodar simultaneamente em mais de um servidor, o que ele consegue fazer com as queries mais pesadas é paralelizar a execução dos mesmos entre os processadores, ele quebra a execução das queries e distribui entre os processadores para que consiga processa-las mais rápido, obvio que existem outros mecanismos mas quanto a paralelização do trabalho seria esta a melhor resposta.

    Não sei se consegui ser bem claro com a minha dúvida, mas basicamente é saber se vale a pena utilizar mais processamento dentro do próprio SQL-SERVER.

    O mais indicado aqui seria você testar o SQL Server, estressar ele com as queries que pretende colocar em produção e ver o seu comportamento. Lembrando que o SQL Server tem algumas configurações a serem seguidas, como por exemplo a quantidade de memória que ele podera utilizar do servidor, discos distintos para os arquivos das bases ajudam na performance etc.

    Quais são os benefícios do SQL-SERVER, que ferramentas possuímos no SQL-SERVER para distribuição de processamento, como proceder em um caso de "gargalo" no banco?

    Primeiramente você precisaria identificar o gargalo (rede? disco? memória) para depois seguir uma linha de raciocinio, algumas ferramentas de monitoração poderiam lhe auxiliar (SQLDIAG, PERFMON, PROFILER). Hoje na internet existe bastante coisa para troubleshotting caso você queira se aprofundar, adianto que não é algo muito simples de entender, o SQL Server realmente é bastante complexo!

    Se precisar de mais alguma informação só dizer!

    Um abraço!


    Regards,

    André César Rodrigues

    Please click the Mark as answer button and vote as helpful if this reply solves your problem. Thanks!

    Blog: http://sqlmagu.blogspot.com.br  LinkedIn:   


    quarta-feira, 3 de julho de 2013 21:48
  • Obrigado pela resposta André.

    Acho que o que devemos fazer é ir balanceando o processamento seja em SQL-SERVER ou em código C#. A princípio eu acredito que o SQL-SERVER deve processar mais rapidamente os processamentos pelo fato de não estar rodando encima do Framework .NET, e também por estar diretamente dentro das tabelas do banco.

    A medida que encontrarmos problemas podemos ir balanceando, uma rotina que pode está pesado demais para o SQL-SERVER pode-se passar para uma rotina C# em outro servidor, e rotinas que não fazem sentido estarem em c# podem estar dentro do SQL-SERVER em procedures para ter uma resposta mais rápida.

    Acho que esse tipo de balanceamento temos que ir fazendo conforme o tempo e a análise de carga de cada servidor que temos. O primeiro que "engasgar" podemos substituir para o que está mais "folgado".

    Apenas por curiosidade, como será que é a arquitetura de um sistema bancário? Imagina as milhares de transações operações bancárias e consultas um banco tem? Isso tudo será que fica centralizado em um único banco de dados? Como será que isso é feito?

    Abraço, obrigado pela resposta!

    quinta-feira, 4 de julho de 2013 13:44
  • Eduardo,

    Recentemente escrevi um artigo no meu blog que apresenta alguns questionamentos e considerações que podem ajudar e tentar evoluir na busca dos possíveis problemas de performance.

    Faça um acesso: pedrogalvaojunior.wordpress.com


    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]

    terça-feira, 16 de julho de 2013 20:59
    Moderador