none
Contingencia RRS feed

  • Pergunta

  • Pessoal,

    Tenho uma aplicação desenvolvida em VS2008 e SQL Server 2000. Está aplicação é estremamente crítica e temos que desenvolver uma forma de trabalharmos em contingencia. Pois caso tivermos queda na rede, problemas no servidor isso impacta diretamente a produção. E a empresa pode chegar a parar.

    Tive uma ideia de fazer algo da seguinte forma, utilizar o SQL Server 2005 Express instalados localmente nas estacoes de trabalho e quando o sistema identificar que algo aconteceu com o servidor principal ele direciona pra trabalhar localmente e quando voltar faço algo para sincronizar as informaçoes.

    Eu imagino modelar algo da seguinte forma:
       
        - Criar alguma aplicação que copia os dados do servidor oficial para as instancias locais de cada maquina. Isso porque pra utilizar a contingencia preciso basicamente das tabelas de cadastro.

        - Quando precisar utilizar a contingencia fazer algo que possa trocar o servidor na string de conexao que o software utiliza, apontando para a instancia local.

        - Definir um periodo de tempo para que seja verificado se o servidor oficial voltou, caso tenha voltado executar uma rotina de sincronizacao de informacao. Essa parte necessita de ser criada pois em meu banco utilizo inumeras PRIMARY KEY do tipo auto-numeraveis, e como o software rodou um tempo em bancos locais corro o risco de ter chaves duplicadas.

    Não sei se consegui colocar minha idéia em questão. Mas caso alguém já tenha vivenciado isso ou que possa me ajudar com algum conselho, preciso dessa ajuda!!!

    Desde já agradeço a atenção de todos.  
    • Movido Gustavo Maia Aguiar sábado, 30 de janeiro de 2010 13:29 (De:SQL Server - Desenvolvimento Geral)
    sábado, 30 de janeiro de 2010 12:24

Respostas

  • Bom Dia,

    Embora seja uma solução possível eu acredito que haja muitas tarefas envolvidas e que isso pode lhe render boas dores de cabeça.

    Ativação da contigência
    Como será feita a alteração da string de conexão ? Se você tiver que ir em cada máquina para trocar será um custo enorme. Se você colocar uma rotina na sua aplicação para sempre verificar se o servidor está "up", todas as conexões ao banco de dados serão absurdamente lentas e o aplicativo se tornará lento.

    Segurança
    Um banco de dados local está sujeito a segurança local. Um usuário poderia simplesmente "abrí-lo" e fazer as alterações que julgasse "interessantes". O "resultado da falha" seria simplesmente atribuído ao aplicativo. Ter um banco local também permitiria ao usuário "levar" os dados da empresa e inclusive analisar o modelo de dados, as regras dentro das SPs, etc.

    Sincronização
    E quando o servidor principal voltasse ? Como os registros cadastrados nas estações voltariam para o servidor principal ? E a resolução de conflitos ? Pode acontecer de dois usuários cadastrarem dados iguais e que na hora de sincronizar isso ocorra em uma violação de integridade. Qual dos dois iria valer ? E como ficariam os relacionamentos no caso de um eventual vencedor por conta da autonumeração (ex: Usuario A cadastrou o produto Sabonete com o ID 1 e o usuário B cadastrou o produto Sabonente com o ID 2 e ambos efetuaram vendas de sabonentes já que o cadastro do sabonete irá gerar um conflito ?).

    Se a aplicação é realmente crítica, eu sugiro investir em equipamentos e rede redundante. O custo pode parecer alto, mas acredite, será muito inferior às dores de cabeça e problemas de integridade. Os desenvolvedores não devem "gastar tempo codificando infraestrutura".

    Clustering, Mirroring e replicação são um bom ponto de partida. Como sua dúvida não se refere a "SQL Server - Desenvolvimento" estou movendo a dúvida para o fórum de "SQL Server - Alta Disponibilidade" que acredito ser o mais adequado.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com/blog

    Piores Práticas – Elaborar triggers preparadas para linhas e não para conjuntos
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!937.entry


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar sábado, 30 de janeiro de 2010 13:29
    • Marcado como Resposta Adalton sábado, 30 de janeiro de 2010 15:32
    sábado, 30 de janeiro de 2010 13:28

Todas as Respostas

  • Bom Dia,

    Embora seja uma solução possível eu acredito que haja muitas tarefas envolvidas e que isso pode lhe render boas dores de cabeça.

    Ativação da contigência
    Como será feita a alteração da string de conexão ? Se você tiver que ir em cada máquina para trocar será um custo enorme. Se você colocar uma rotina na sua aplicação para sempre verificar se o servidor está "up", todas as conexões ao banco de dados serão absurdamente lentas e o aplicativo se tornará lento.

    Segurança
    Um banco de dados local está sujeito a segurança local. Um usuário poderia simplesmente "abrí-lo" e fazer as alterações que julgasse "interessantes". O "resultado da falha" seria simplesmente atribuído ao aplicativo. Ter um banco local também permitiria ao usuário "levar" os dados da empresa e inclusive analisar o modelo de dados, as regras dentro das SPs, etc.

    Sincronização
    E quando o servidor principal voltasse ? Como os registros cadastrados nas estações voltariam para o servidor principal ? E a resolução de conflitos ? Pode acontecer de dois usuários cadastrarem dados iguais e que na hora de sincronizar isso ocorra em uma violação de integridade. Qual dos dois iria valer ? E como ficariam os relacionamentos no caso de um eventual vencedor por conta da autonumeração (ex: Usuario A cadastrou o produto Sabonete com o ID 1 e o usuário B cadastrou o produto Sabonente com o ID 2 e ambos efetuaram vendas de sabonentes já que o cadastro do sabonete irá gerar um conflito ?).

    Se a aplicação é realmente crítica, eu sugiro investir em equipamentos e rede redundante. O custo pode parecer alto, mas acredite, será muito inferior às dores de cabeça e problemas de integridade. Os desenvolvedores não devem "gastar tempo codificando infraestrutura".

    Clustering, Mirroring e replicação são um bom ponto de partida. Como sua dúvida não se refere a "SQL Server - Desenvolvimento" estou movendo a dúvida para o fórum de "SQL Server - Alta Disponibilidade" que acredito ser o mais adequado.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com/blog

    Piores Práticas – Elaborar triggers preparadas para linhas e não para conjuntos
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!937.entry


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar sábado, 30 de janeiro de 2010 13:29
    • Marcado como Resposta Adalton sábado, 30 de janeiro de 2010 15:32
    sábado, 30 de janeiro de 2010 13:28
  • Adalton,

    Acredito que você poderia resolver isso de forma mais fácil, criando um ambiente de contingência da seguinte forma:

     1. Utilizando controladores de domínio com replicação, entre o primário e secundário;
     2. Trabalhar com servidores de SQL Server distintos utilizando recursos de Replicação, Log Shipping e Espelhamento de Banco.
     3. Criar um ambiente de cluster através do Windows Server e instalar seu SQL Server sobre este cluster.
     4. Distribuir suas aplicações em módulos, onde cada área possui um banco de dados especifico e caso um banco de falhe somente aquela área é afetada.

    Existem diversas soluções, mas a princípio vejo o Cluster e Replicação como as mais indicadas.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    sábado, 30 de janeiro de 2010 14:20
    Moderador
  • Oi Adalton,

    Como os amigos postaram,acredito que criar sua própria solução para este problema nao seja o mais recomendado.
    Baseado em sua necessidade,acredito que Database Mirror seria a melhor opção.

    Até mais.
    Felipe Santana - MCP
    sábado, 30 de janeiro de 2010 14:31
  • Pessoal,

    Obrigado pelas dicas, vou procurar mais informacoes a respeitos e tentar implementar aqui na empresa.

    Obrigado.

    Abraço.
    sábado, 30 de janeiro de 2010 15:32
  • Adalton,

    Ficamos no aguardo.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    sábado, 30 de janeiro de 2010 15:34
    Moderador
  • Pessoal,

     

    Estou retomando este assunto pois entendo que aqui na empresa não teremos possibilidades de investimento com redundancia, espelhamento, replicação e etc (sempre aquela mesma justificativa: "Redução de Custos").

    Portanto, tive uma idéia pra ver se consigo implementar uma contingencia estilo "jeitinho brasileiro".

    Pensei em fazer da seguinte forma, adicionar no meu projeto um arquivo de banco de dados (.MDF) e trabalhar nesse arquivo quando estivermos sem conexão com o servidor de produção. Assim que voltasse a conexão criaria uma rotina de sincronização das informações.

    Minhas perguntas são:

    1 - Vcs tem alguns exemplos de como trabalhar com o MDF junto do projeto? Nunca trabalhei desta forma.

    2 - Quando trabalho com o arquivo junto do projeto, a máquina cliente necessita ter instalado o serviço de SQL Server?

     

    Aguardo retorno.

     

    Abraços.

    quinta-feira, 13 de maio de 2010 13:24
  • Olá Adalton,

    Como é que alguém pode solicitar um serviço se não está diposto a gastar ? "Redução de Custos" é uma justiticativa comum e buscar o melhor uso dos recursos é algo a ser perseguido sempre, mas se alguém quer algo que não possui é natural esperar pagar por ele e Alta Disponibilidade custa. Se a aplicação é extremamente crítica e a empresa chega a parar, creio que reduzir os investimentos em alta disponibilidade irá reduzir os custos, mas quando a parada ocorrer será bem difícil conseguir colocar as coisas para funcionar.

    O "jeitinho brasileiro" irá funcionar "para inglês ver". Ao meu ver, a solução técnica apresentada dificilmente irá funcionar além do que será absurdamente complexa de ser mantida embora seja possível. Algumas questões técnicas serão difíceis de trabalhar:

    Caso aconteça algo no servidor, a aplicação deverá trabalhar localmente. O primeiro ponto é definir o que é "algo". Vamos supor que uma queda na rede de um ou dois segundos provoque uma negação de acesso ao SQL Server. Sua aplicação já irá funcionar localmente ? Ao meu ver ser se a rede caiu dois segundos e você começa a trabalhar localmente seria algo um pouco "precipitado". Mas vamos pensar que a rede não caia por dois segundos, mas sim por uma manhã inteira. Como a aplicação irá saber o que fazer em cada situação ?

    Agora pensemos que esse primeiro desafio seja superada e que todos estejam operando localmente. Como fazer a sincronização com o servidor ? A cada tabela criada no banco ter-se-á a preocupação de incluí-la no mecanismo de sincronização, ou seja, para criar uma tabela nova será necessário fazer todos os testes da funcionalidade da aplicação e da rotina de sincronização. Ainda que isso seja realizado alguns outros pontos serão complicados de solucionar. Os identites são por banco e na hora de sincronizar vocês terá que arrumar as sequências. Pode ser que um determinado registro esteja cadastrado no servidor e seja recadastrado no banco e na hora de sincronizar haver-se-á problemas de chave primária (qual deverá ser o vencedor ?). E se o cliente (administrador da máquina) abrir o banco e fizer as alterações necessárias ? Elas vão pro servidor mesmo caracterizando-se uma fraude ?

    Enfim, acho que os custos e os riscos de desenvolver e manter uma solução de alta disponibilidade podem custar inclusive mais do que os investimentos necessários. Não se trata de "reduzir custos", mas sim aplicar o dinheiro corretamente para mitigar um risco. Talvez os gestores não tenham esse ponto de vista.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Por que utilizar uma ferramenta de ETL ?
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1026.entry


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Renato Siqueira quarta-feira, 27 de março de 2013 18:38
    quinta-feira, 13 de maio de 2010 17:26