Banco de dados interno ruim - substitua-o ou elimine o hardware?

Portanto, temos um banco de dados interno da empresa, o tipo usual de coisas: gerencia clientes, telefonemas, acordos de vendas e acordos / esquemas de clientes.

É um front-end do Access 2000 e um back-end do SQL Server 2000 Standard. Um servidor único, Xeon duplo de 3,2 GHz, 2 GB de RAM, Windows Server 2003, recebe cerca de 40% da carga da CPU o dia todo, distribuído pelos 4 núcleos visíveis para o SO (HT).

O banco de dados de back-end é mal projetado e cresceu organicamente há mais de 10 anos, mantido por indivíduos menos qualificados. É normalizado e alguns dos problemas óbvios incluem tabelas com dezenas de milhares de linhas sem chave primária ou índice, que também são usadas fortemente em junções de várias tabelas para algumas das partes mais usadas do sistema (por exemplo, uma aplicativo gerenciador de chamadas que fica no segundo monitor de todos por 8 horas por dia e executa uma grande consulta ineficiente a cada poucos segundos).

O front-end não é muito melhor, é a bagunça típica de centenas de formulários, consultas salvas aninhadas, SQL incorporado mal escrito no código VBA, dezenas de "peculiaridades" etc., e sempre que uma alteração é feita, algo não relacionado parece quebrar. Estabelecemos um MDB que funcione "suficientemente bem" e agora temos uma política de não alteração, pois não possuímos pesos pesados ​​de acesso internamente (e também não temos planos de contratar um).

A empresa agora está crescendo lentamente, aumentando o número de clientes, chamadas, etc., bem como um aumento modesto no número de usuários simultâneos, e o desempenho está notavelmente piorando recentemente (aguardando a alternância entre formulários, aguardando a lista ser preenchida, etc. )

Perfmon diz:

• Transferências de disco por segundo: entre 0 e 30, média 4.
• Comprimento atual da fila de disco: fica em torno de 1

O criador de perfil do SQL Server recebe centenas de milhares de consultas a cada minuto. O uso da CPU nos clientes é praticamente zero, indicando que está aguardando a execução das consultas do servidor. Coloquei essa carga de trabalho no DB Engine Tuning Advisor, apliquei suas sugestões em um backup de teste, mas isso realmente não fez muita diferença.

A propósito, temos uma mistura de 100 MB e Ethernet de gigabit, tudo em uma sub-rede, 40 usuários ish em dois andares.

Para a pergunta.

A meu ver, temos duas opções para resolver / melhorar essa situação.

• Podemos descartá-lo e substituí-lo por um sistema CRM totalmente novo, sob medida ou parcialmente sob medida
• Podemos prolongar a vida útil deste sistema jogando o hardware nele.

Podemos construir um sistema Intel i7 com números de desempenho malucos por uma ordem de magnitude menor que a substituição do software.

Quando um novo sistema é desenvolvido, ele pode ser hospedado nessa caixa, para que não haja desperdício de hardware. Um novo sistema de CRM continua sendo adiado e desativado - não vejo isso acontecendo há pelo menos um ano.

Qualquer opinião sobre esta situação, especialmente se você já esteve aqui, seria muito apreciada.

obrigado

Eu vou discordar de todos aqui. Coloque algum hardware nele. É barato, rápido, fácil e comprará o tempo necessário para implementar uma solução de CRM adequada. A razão pela qual estou defendendo algo que é anátema para quase todo mundo, não apenas neste quadro, mas também no fluxo de pilha, é que eu sou gerente / gerente de projeto e estou no lado "comercial" há algum tempo (negócios está entre aspas devido ao meu ódio pela palavra). Com base na sua descrição do software, levará quase um ano para reconstruir outra coisa. Apenas descobrir / documentar as regras / peculiaridades comerciais, provavelmente levará 2 meses. Também será incrivelmente caro desenvolver. Especialmente quando comparado ao custo de um servidor enganado.

Na verdade, estou prestes a hospedar um conjunto de aplicativos da web para uma empresa exatamente por esse motivo. O departamento de TI interno não o moverá para um hardware melhor, porque eles querem desenvolvê-los novamente em uma nova plataforma. Esse custo é aproximadamente o triplo do que custaria para movê-lo para um novo hardware. Sem mencionar também que a empresa pode não ter o contrato renovado em um ano.

Você pode não precisar fazer isso também. Minha sugestão é simplesmente adicionar alguns índices / chaves à tabela.

tabelas com dezenas de milhares de linhas sem chave primária ou índice, que também são usadas fortemente em junções de várias tabelas

Antes de gastar muito dinheiro ou tempo, dedique algumas horas e adicione índices (ou chaves primárias, se possível) a quaisquer tabelas envolvidas nessas associações ... particularmente para colunas usadas na cláusula where. Você poderia facilmente melhorar o desempenho em 10 vezes em apenas algumas horas.

A falta de E / S de disco implica que as consultas são alimentadas principalmente pela RAM. Se você 'repentinamente' não tiver mais suas tabelas de atalho na memória RAM e o servidor começar a trabalhar com os discos, você poderá se dar mal. Hoje em dia, 2 GB ou RAM não são muito, mas na era do SQL2000, seria considerável. Estou supondo que a quantidade de dados que o aplicativo normalmente manipula seja menor que a RAM que você possui. Você pode querer observar a quantidade de espaço "usado" nos arquivos de dados. Isso lhe dará uma idéia da quantidade de RAM que o banco de dados pode consumir, na pior das hipóteses. O SQL Server não mantém os dados de que não precisa na RAM, mas pode ser difícil saber quais tabelas são usadas e quando.

O Hyperthreading nem sempre é útil com o SQL Server. Você pode obter um melhor desempenho ao desativá-lo. É difícil de testar, porque ligar e desligar requer uma reinicialização, e isso é um grande aborrecimento em um servidor de produção.

"Centenas de milhares de consultas por minuto" se traduz em milhares de consultas por segundo. Isso parece bastante ocupado, mas muito desse tráfego pode ser apenas uma busca do cursor pelo Access. O acesso é particularmente ruim na recuperação eficiente de conjuntos de resultados do SQL. Você pode obter um melhor desempenho desativando a configuração de paralelização do SQL Server.

Você também deseja procurar por bloqueio. Jogar hardware em um problema de bloqueio nem sempre produz a melhoria dramática esperada. Se não houver muito bloqueio e as consultas forem satisfeitas pela RAM, e não pelo disco, você estará confiando basicamente no grunhido do processador e na capacidade deles de extrair dados pelos canais de memória. Nesse caso, o hardware mais rápido deve fornecer uma boa melhoria. Se você estiver com pressa (para superar esse problema) e crescer lentamente, isso pode ser bom o suficiente.

Como solução, adicionar hardware não é tão dimensionável quanto as melhorias no banco de dados. Se você tiver um aumento no crescimento, poderá encontrar dificuldades em seu novo hardware. Outro pensamento é que aplicativos bem-sucedidos atraem usuários. Se o aplicativo se tornar mais responsivo, é mais provável que os usuários gerem mais relatórios do que faria se precisassem tomar um café enquanto aguardavam a conclusão do relatório.

Se o esquema do banco de dados estiver realmente ruim, você poderá obter algumas vitórias de desempenho simplesmente observando a indexação nas tabelas. Concentre-se nas tabelas que você sabe que são consultadas com frequência. Você pode usar o Profiler para assistir a consultas executadas no servidor, apenas peça para procurar consultas que leiam muitos dados (como 100.000 páginas) e depois trabalhe em consultas que não leem muito. Você mencionou que algumas das tabelas não têm chaves. Existem chaves naturais nos dados, que não são impostas por restrições ou índices exclusivos?

As tabelas possuem índices em cluster? A falta de indexação em cluster pode causar todos os tipos de efeitos secundários.

Existem muitos índices não clusterizados, com muitas colunas? Geralmente, é uma tentativa de criar muitos índices de cobertura, em vez de implementar uma estratégia de indexação mais eficaz. O SQL Server pode efetivamente criar índices de cobertura dinamicamente durante uma consulta, se fizer sentido e houver suporte para índices não clusterizados e agrupados.

Por fim, vale a pena perguntar: A manutenção (reindexação e / ou atualização de estatísticas) está sendo feita nas tabelas?

essa é uma questão comercial, não técnica.

Como proprietário de uma empresa: Quão estratégico é o sistema para a empresa? quanto menos estratégico, menos eu me importo e conserto e dinheiro gasto é o dinheiro que eu poderia estar usando em outro lugar para expandir meus negócios.

O pessoal do computador me assusta quando todos entram em uma sala grande e discutem sobre design e me custam uma fortuna. Mantenha o sistema funcionando! se isso significa ajuste de desempenho (sem re-arquitetar) ou jogar mais hardware nele, é apenas uma prioridade se parar de funcionar.

Como consultor de TI: Seu sistema é legado e oculta custos operacionais. Podemos projetar um sistema adequado para você, que escalará e forneça uma plataforma para crescimento futuro e vantagem estratégica. Assine aqui e todos os seus sonhos se tornarão realidade.

Como funcionário de TI: posso ser o super-herói aqui e salvar a empresa, evitando um desastre iminente, otimizando o inferno dessa coisa! meu gerente vai me encher de presentes e elogios, pois terei salvado milhares de empresas.

Eu digo faça os dois.

Agora você está com 40% da CPU que você disse? Você já está reclamando (muito) do usuário? Caso contrário, você ainda tem espaço para respirar. Mais memória pode ser suficiente para fazê-lo por um tempo.

Pergunta para o caminho a seguir, você possui desenvolvedores de software internos? Se a resposta for NÃO, nem tente refazê-la. Você vai acabar exatamente onde está agora.

Supondo que você tenha desenvolvedores internos, seus desenvolvedores internos têm a capacidade de executar um projeto corretamente? Estou falando de uma linha do tempo completa, adequada (relística), basicamente a mesma como se fosse o projeto de um cliente. Caso contrário, não se preocupe, ou ele voltará para onde você está agora.

Até que as empresas reconheçam que também são clientes de si mesmas e precisem fornecer os mesmos recursos para projetos internos, você terminará exatamente onde está agora. Estive lá, fiz isso, adquiri uma cômoda inteira de camisetas.

Portanto, se você não pode fazê-lo corretamente, as duas opções estão prontas para uso imediato, que sua equipe odiará, porque agora você precisa se ajustar ao sistema do sistema que compra. Ou será personalizável e você ainda precisará gastar tempo no PROJECT personalizando-o.

OU Refatorar o que você tem. Lembre-se de que as pessoas esperam a mesma funcionalidade completa quando a nova aparecer, por isso, é por isso que você precisa fazer tudo de uma só vez. Se você o fatorar novamente, você terá a chance de descobrir como funciona e, em seguida, em vez de alterações ad-hoc, o planejará em muitos subprojetos pequenos.

Sem ver o sistema, eu provavelmente veria como normalizar o máximo que posso no back-end, mover o máximo do SQL para os processos armazenados. Em seguida, crie um novo front end a partir de formulários C # ou de um aplicativo da web. Se você conseguir obter a lógica de negócios e o SQL fora do front-end, será mais fácil refazê-lo mais tarde. Mantendo o que você faz em pequenos projetos, se ele for deixado de lado a qualquer momento ou parado, você terá feito progressos que serão usados.

Algumas boas respostas aqui já - mas posso apenas salientar que (supondo que haja desenvolvedores internos) uma quantidade relativamente pequena de trabalho tenha um grande impacto - adicione chaves primárias (você nem precisa alterar todas as suas consultas para use-os), adicione índices aos campos que você usa e ajuste suas consultas um pouco e você poderá ver um aumento absolutamente enorme. Compre um pouco de RAM agora para comprar o tempo e o espaço necessário para corrigi-lo e depois comece a trabalhar.

No assunto "conserte ou abandone", se os recursos do sistema funcionarem basicamente para você e fizerem o que você precisa, não reescreva a roda. Se seus usuários estão precisando fazer ginástica para usá-la porque ela não atende às suas necessidades, não faz sentido se esforçar.

Bem ... isso já faz um tempo, mas pensei em registrar o resultado aqui.

No final, passei pela linha VBA linha por linha para lidar com outro problema. Foi então que percebi que algumas chamadas para buscar conjuntos de linhas estavam bloqueando por mais de 20 a 30 segundos.

Quando eu os procurei, descobri que o conjunto de linhas era baseado em uma consulta do MS Access.

Isso estava selecionando dados de outra consulta do Access.

Isso foi selecionar dados de mais uma consulta do Access.

Tudo parecia ter sido arrastado e soltado usando o designer de consultas.

Analisei as meia dúzia de pontos problemáticos dos usuários e descobri que, sem falhas, eles eram exatamente iguais.

Portanto, removi completamente as pilhas de consultas encadeadas e substituí cada uma delas por uma única consulta de passagem que poderia ser escrita em T-SQL e executada diretamente no servidor.

A melhoria foi absolutamente vasta em todos os casos, sem falhas e não havia mais espera de consultas para ninguém.

E então eu saí da empresa. Não faço ideia se ainda está lá ... mas não sinto falta.

Estou postando uma resposta separada, em vez de apenas anexar à resposta de Dayton, porque há um custo que não está sendo levado em consideração pelas primeiras pessoas a postar uma resposta: um novo programa de software. Caso contrário, o que ele disse.

Uma das principais razões pelas quais as empresas desenvolvem seu próprio software é o fato de terem procedimentos comerciais que não correspondem a algo que está no mercado. O que é ótimo - os procedimentos comerciais individuais de uma empresa são uma parte significativa do valor que uma empresa traz para a mesa e SÃO a vantagem competitiva que uma empresa possui sobre o restante de seu mercado. Para substituir o software por algo genérico, seria necessário treinar novamente seu pessoal e sacrificar a vantagem competitiva, ou você teria que personalizar a solução para corresponder aos seus processos de negócios. Ambos são caros e demorados. Como consultor de negócios e administrador de sistemas, vi esses custos matarem pequenas empresas sozinhas.

A partir de suas declarações, parece que você está praticamente vinculado a processador / software. Eu faria duas coisas - adicionar índices (dentro dos limites), especialmente para colunas que atualmente não os usam. E eu escolheria o conjunto mais rápido de processadores possível, porque parece que é aí que você está vinculando se não tiver tantas leituras de unidade, exceto no pico.

(Além disso, eu atualizaria a edição do servidor o máximo possível - quando você colocar isso em prática, o Access 2000 e o SQL Server 2000 terão dez anos. Isso é muito velho em anos de computador!)

Isso precisa de uma reestruturação total (reestruturação). Reconstrua o sistema a partir do zero. Isso economizará muito a longo prazo (custos indiretos em manutenção). Nesse meio tempo, jogue o hardware nele. Penso que esta questão é mais um "caso comercial" do que uma investigação técnica. Do ponto de vista técnico, a resposta é um "jogo mais poderoso". Em termos de negócios, crie um novo sistema!

Resposta técnica:

Você tem várias sugestões de que as chaves primárias e a indexação devem ser cuidadosamente revisadas. O Access também gosta muito de usar uma coluna TimeStamp do SQL Server, também conhecida como RowVersion, em cada tabela, pois isso reduz muito tempo que o Access gasta decidindo se um registro foi alterado quando se trata de atualizar os registros.

Resposta comercial:

Uma nova solução de CRM dá muito trabalho no treinamento de pessoal e você nunca terá um sistema que atenda exatamente aos seus requisitos de negócios.

Eu encontraria uma boa pessoa do Access que também seja muito qualificada no SQL Server e faria com que passassem 3 ou 6 meses normalizando as tabelas e corrigindo os pontos problemáticos do usuário. Garanta que a pessoa trabalhe nos pisos saem como seus usuários, embora em um espaço silencioso, e esteja acessível. Embora não seja muito acessível. Os desenvolvedores não gostam de interrupções. S

Com base nas informações fornecidas, eu substituiria o sistema. De preferência com outro CRM que permita uma integração flexível com outros sistemas (que comprometeriam o seu ERP IS ).

A parte mais complicada será convencer a gerência e os usuários a precisar de uma atualização.

Gestão

Expresse suas preocupações sobre questões técnicas, baixo desempenho, medo de falhas bizantinas etc. etc. Apresente 2 CRMs alternativos. Fale sobre integração de negócios, a estratégia geral de ERP para os negócios e, mais importante, como isso tornará os funcionários mais produtivos e lucrativos. Use estudos de caso. Faça isso por mais de 15 minutos (a menos que eles desejem mais informações). Depois, você precisa convencer os usuários.

Comercial

Planos de treinamento (que um fornecedor pode fornecer [e que a gerência precisaria endossar]), comunicação contínua com os 20% principais de seus usuários (usuários avançados, aqueles que causam problemas) e um sólido compromisso de manter o sistema 100% operacional para o primeiro mês (o primeiro mês criará ou quebrará qualquer novo IS).

Existem muitos produtos de CRM por aí, escolha aquele que melhor se adapte às suas necessidades de negócios.

Jogar hardware apenas incentiva um projeto e gerenciamento mais precários, até que o sistema seja tão patético que não funcione bem nem no hardware mais recente e melhor. É hora de olhar para uma melhor implementação. Primeiro analise o que é necessário. Somente quando você entender completamente os requisitos, poderá começar a procurar a melhor maneira de implementá-los. Depois de ter certeza de que compreende os requisitos, comece a verificar se é melhor / mais econômico modificar o que você tem ou começar do zero, possivelmente com algo completamente diferente.

A longo prazo, provavelmente seria melhor refazer o banco de dados. Lançar mais hardware resolverá o problema por um tempo, mas se você continuar a usá-lo, terá que jogar mais hardware depois de um tempo.

Normalmente, quando há problemas de desempenho, você observa coisas como gargalos de E / S em discos rígidos / RAID, fragmentando o banco de dados, etc ... mas para coisas como fragmentação, você precisa que o banco de dados seja projetado adequadamente para tirar proveito dele. Pelo que parece, seu aplicativo nunca será capaz de escalar.

A longo prazo, refazer o banco de dados e o software front-end para refletir melhor suas necessidades atuais de negócios irá atendê-lo melhor a longo prazo. Seus usuários agradecerão, seu hardware durará mais tempo e economizará muito mais dinheiro a longo prazo do que jogar hardware gigantesco nessa questão.

Dada a sua descrição, a criação de um sistema sob medida totalmente novo não faz sentido - você vai acabar exatamente onde começou, ou talvez ainda pior do que está agora. Portanto, a menos que você consiga convencer alguém a comprar uma solução de terceiros, sua melhor aposta é refatorar da melhor maneira possível e usar o hardware.

Eu diria que você deve fazer duas coisas: 1) Análise de desempenho no servidor SQL. Parece que você identificou o lado do servidor como a origem dos atrasos; agora, você precisa saber quais consultas estão atrasadas e por quê. Com toda a probabilidade, você pode encontrar algumas consultas de ponto de acesso para otimizar que dariam grandes benefícios. Caramba, se você tem clientes que atualizam a cada poucos segundos, veja se é possível diminuir a taxa de atualização (a lista na tela REALMENTE precisa ser atualizada a cada 5 segundos? 30 está bom? Se não, cerca de 15? ) Coisas estúpidas, como aumentar os temporizadores de atualização, podem economizar muito em sobrecarga, se você conseguir se safar.

2) Jogue mais hardware nele. ESPECIALMENTE jogue grandes quantidades de RAM nele. Você quer tanta memória que o banco de dados caiba inteiramente na RAM. Fique de olho nas versões de seu sistema operacional e software ( aparentemente existem muitas regras nas versões do Windows e em qual hardware elas realmente suportam). Se você conseguir se convencer de que mais núcleos ajudariam, instale o máximo de CPUs e núcleos que conseguir.

Você mencionou RAM e processadores, mas não discos. Admito que já faz quase uma década desde que lidei com o SQL Server da MS, mas ele está vinculado aos discos tanto quanto qualquer outro banco de dados, se não puder caber tudo na memória.

Eu provavelmente tentaria primeiro encher a máquina com o máximo de RAM possível - depois, garantiria que os logs estivessem sendo gravados em discos que não estão sendo usados ​​para tabelas ou índices. Eu tentaria garantir que nenhuma tabela tenha seus índices no mesmo eixo.

Depois disso, eu me preocupo com o ajuste no nível do banco de dados, mas com isso, você precisará definir seus testes e uma meta de otimização para não quebrar as coisas ou piorar as consultas. Embora você tenha dito que as chaves primárias não mostraram muita vantagem em seu banco de dados de teste, verifique sua metodologia de teste - as chaves primárias podem permitir que alguns bancos de dados (não tenham certeza se o MS SQL é um deles) para usar o bloqueio no nível de registro , em vez de bloqueios no nível da tabela, que podem reduzir a contenção que pode não ser mostrada no teste com apenas alguns usuários.

Primeiro, concordo com Kyle Hodgson e adiciono PKs. É barato (somente hora) e você pode ver um aumento nas suas consultas. E os índices das colunas de junção nas suas 10 consultas mais feias? Onde estão as varreduras da tabela?

Segundo, que tal aparar dados no banco de dados? São retornadas mais linhas nas consultas do que realmente são necessárias? Também concordo com a sugestão de Kyle sobre RAM (mais dois GB).

Coloque tudo isso em sua redação (Joseph Kern) sobre o que você propõe para o ínterim enquanto traça o futuro. Pergunte à gerência e aos usuários o que acontece com a organização se o aplicativo de CRM atual não estiver disponível. Talvez isso os ajude a pensar no futuro.

Pegue o hardware!

O estanho não é apenas muito barato no momento, se você optar por um chip da série Xeon 55xx, ele gritará por qualquer coisa que possa jogar nele.

É apenas uma coisa de risco / recompensa - você pode gastar dinheiro e muito tempo melhorando o DB ou comprar seu caminho para lá mais rápido e mais barato.

Considere ativar o comutador de memória de 3 GB e adicionar outros 2 GB de memória.