Banco de dados interno ruim - substituí-lo ou chuck hardware nele?

Question

Então - nós temos um banco de dados interno da empresa, o tipo usual de coisas: gerencia clientes, telefonemas, ofertas de vendas e acordos / esquemas de clientes.

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

O banco de dados de back-end é mal projetado e cresceu organicamente em mais de 10 anos, mantido por indivíduos menos qualificados. É mal 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 pesadamente em junções de multi-tabelas para algumas das partes mais utilizadas do sistema (por exemplo, aplicativo gerenciador de chamadas que fica no segundo monitor de todos por 8 horas por dia e executa uma consulta grande e 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 embutido mal escrito no código VBA, dezenas de "quirks" etc., e sempre que uma alteração é feita, algo não relacionado parece quebrar. Nós nos decidimos por um MDB que funciona "bem o suficiente" e agora tem uma política de não-mudança, já que não temos pesos pesados do Access internamente (e tampouco temos planos de contratá-lo).

A empresa 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 tem notavelmente piorado recentemente (esperando para se deslocar entre formulários, aguardando listas para preencher, etc)

Perfmon diz:

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

O profiler do SQL Server vê centenas de milhares de consultas a cada minuto. O uso da CPU nos clientes é praticamente zero, indicando que está aguardando consultas do lado do servidor para serem executadas. Eu coloquei essa carga de trabalho por meio do Orientador de Otimização do Mecanismo de BD, apliquei suas sugestões a um backup de teste, mas isso não fez muita diferença.

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

Para a pergunta.

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

• Podemos desfazê-lo e substituí-lo por um sistema inteiramente novo de CRM, seja sob medida ou parte sob medida
• Podemos prolongar a vida útil desse sistema, testando hardware nele.

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

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

Qualquer pensamento sobre esta situação, especialmente se você esteve aqui, seria muito apreciado.

Obrigado

    

Answer 1

Bem ... isso é um tempo atrás agora, mas eu pensei em registrar o resultado aqui.

No final, eu percorri o 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 20 a 30 segundos.

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

Isso foi selecionar dados de outra consulta do Access.

Isso estava selecionando dados de outra consulta do Access.

Todos pareciam ter sido arrastados e soltos juntos usando o designer de consulta.

Eu passei pela meia dúzia de pontos problemáticos do usuário e descobri que, sem falhar, eles eram todos exatamente iguais a isso.

Então eu removi as pilhas de consultas encadeadas inteiramente e substituí cada uma delas por uma única consulta de passagem que poderia ser escrita em T-SQL e executada diretamente no servidor.

A melhora foi absolutamente grande em todos os casos, sem falhas, e não houve mais espera por 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 disso.

    

Answer 2

Eu vou discordar de todos aqui. Chuck algum hardware nisso. É barato, rápido, fácil e lhe dará o tempo necessário para implementar uma solução de CRM adequada. A razão pela qual estou defendendo algo que é um anátema para todos, não apenas nesta diretoria, mas também no stackoverflow, é que eu sou gerente / gerente de projetos e estou no lado "Business" há algum tempo 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 do negócio provavelmente levará 2 meses. Também será inacreditavelmente caro desenvolver. Especialmente quando comparado com o custo de um servidor enganado.

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

    

Answer 3

Você pode não precisar fazer nenhum dos dois. 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 muito usadas em junções de várias tabelas

Antes de gastar muito dinheiro ou tempo, reserve algumas horas e adicione índices (ou chaves primárias, se puder) a qualquer tabela envolvida nessas junções ... especialmente para colunas usadas em uma cláusula where. Você poderia facilmente melhorar o desempenho por um fator de 10 em apenas algumas horas.

    

Answer 4

A falta de E / S de disco implica que as consultas são alimentadas principalmente com RAM. Se de repente suas tabelas quentes não couberem mais na RAM e o servidor começar a trabalhar com os discos, você poderá ter um mau caminho. 2GB ou RAM não é muito nestes dias, mas de volta à era SQL2000, teria sido considerável. Eu estou supondo que a quantidade de dados que o aplicativo normalmente manipula é menor do que a RAM que você tem. Você pode querer olhar para a quantidade de espaço "usado" nos arquivos de dados. Isso lhe dará uma idéia de quanto RAM o banco de dados pode consumir, no pior caso. O SQL Server não mantém os dados que não precisam 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 testar, porque a ativação e a desativação exigem uma reinicialização e isso é um grande incômodo em um servidor de produção.

"Centenas de milhares de consultas por minuto" se traduzem em milhares de consultas por segundo. Isso parece muito ocupado, mas grande parte desse tráfego pode ser acessado apenas 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 quer 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 atendidas pela RAM, em vez de pelo disco, você está basicamente confiando no grunhido do processador e em sua capacidade de extrair dados pelos canais de memória. Nesse caso, um hardware mais rápido deve proporcionar uma boa melhoria. Se você está com pressa (para superar este problema) e crescendo lentamente, isso pode ser bom o suficiente.

Como solução, a adição de hardware não é dimensionada, assim como as melhorias no banco de dados. Se você tiver um aumento no crescimento, poderá encontrar dificuldades em seu novo hardware. Outro pensamento é que os aplicativos bem-sucedidos atraem os usuários. Se o aplicativo se tornar mais responsivo, os usuários poderão ter mais chances de gerar mais relatórios do que se precisassem de um café enquanto aguardavam a conclusão do relatório.

Se o esquema do banco de dados for realmente ruim, você poderá obter alguns ganhos de desempenho simplesmente observando a indexação nas tabelas. Concentre-se em tabelas que você sabe ser consultado com frequência. Você pode usar o Profiler para ver as consultas em execução no servidor, basta avisá-lo para procurar por consultas que leiam muitos dados (como 100.000 páginas) e, em seguida, trabalhem para consultas que não leiam muito. Você mencionou que algumas das tabelas não possuem chaves. Existem chaves naturais nos dados, apenas não impostas por restrições ou índices exclusivos?

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

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

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

    

Answer 5

esta é uma questão de negócios e não uma questão técnica.

Como proprietário de uma empresa: Quão estratégico é o sistema para o negócio? quanto menos estratégico, menos eu me importo & consertando & qualquer dinheiro gasto, é dinheiro que eu poderia estar usando em outro lugar para crescer o meu negócio.

Computadores me assustam quando todos entram em uma grande sala & discutir sobre design & me custou uma fortuna. Mantenha o sistema funcionando! se isso significa ajuste de desempenho (sem nova arquitetura) ou mais hardware, é apenas uma prioridade se ele parar de funcionar.

Como consultor de TI: Seu sistema é legado e tem custos operacionais ocultos. Podemos projetar um sistema adequado para você, que será dimensionado e fornecerá uma plataforma para crescimento futuro & vantagem estratégica. Assine aqui & Todos os seus sonhos se tornarão realidade.

Como funcionário de TI: Eu posso ser o super-herói aqui & salve a empresa evitando um desastre iminente, otimizando o inferno dessa coisa! meu gerente vai me regar com presentes & louvor como eu salvei a empresa milhares.

    

Answer 6

Eu digo fazer as duas coisas.

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

Pergunta para o caminho a percorrer, você tem em casa desenvolvedores de software? Se as respostas forem NÃO, então nem tente refazer. Você vai acabar exatamente onde você está agora.

Supondo que você tenha desenvolvedores internos, seus desenvolvedores internos têm a capacidade de fazer um projeto corretamente? Estou falando de uma linha de tempo completa, adequadamente (relística), basicamente o mesmo que se fosse o projeto de um cliente. Se não, então não se incomode ou vai acabar de volta onde você está agora.

Até que as empresas se reconheçam, elas também são clientes de si mesmas e precisam dar os mesmos recursos aos projetos internos, e você acabará exatamente onde está agora. Foi lá, feito isso, tenho uma cômoda inteira de camisetas.

Então, se você não pode fazê-lo corretamente, você está duas opções fora da caixa, o que sua equipe odiará porque agora você tem que se encaixar no molde do sistema que você compra. Ou será personalizável e você ainda terá que gastar o tempo de PROJETO para personalizá-lo.

OR refatorie o que você tem. Lembre-se de que as pessoas vão esperar a mesma funcionalidade completa quando a nova entra, então é por isso que de qualquer outra maneira você tem que fazer tudo de uma vez. Se você re-fatorar, você tem a chance de descobrir como funciona e, em seguida, em vez de mudanças ad-hoc você planeja em muitos sub-projetos pequenos.

Sem ver o sistema, provavelmente verificaria a normalização tanto quanto possível no back-end, mova o máximo do SQL para Stored procs. Em seguida, construa um novo front end em C # Forms ou em um webapp. Se você conseguir que sua lógica de negócios e SQL fiquem fora do front-end, será mais fácil refazê-la mais tarde. Ao manter o que você faz em pequenos projetos, se for deixado de lado a qualquer momento ou parado, você terá feito progressos que serão usados.

    

Answer 7

Algumas boas respostas já estão aqui - mas posso apenas salientar que (supondo que haja desenvolvedores internos) uma quantidade relativamente pequena de trabalho terá um grande impacto - adicionar chaves primárias (você não deveria ter que alterar todas as suas consultas para usá-las), adicione índices aos campos que você usa e ajuste suas consultas um pouco e você poderá ver um aumento absolutamente grande. Compre um pouco de RAM agora para comprar o tempo e espaço que você precisa para consertá-lo e, em seguida, começar a trabalhar.

Sobre o assunto de "consertar ou largar", se os recursos do sistema funcionarem basicamente para você e fizerem o que você precisa, não reescreva a roda. Se os seus usuários estão tendo que fazer ginástica para usar a coisa porque ela não se ajusta às suas necessidades, então não adianta colocar esforço nela.

    

Answer 8

Estou postando uma resposta separada em vez de apenas anexar a A resposta de Dayton porque há um custo que não está sendo levado em conta pelas primeiras pessoas a postar uma resposta: O custo de retreinamento de usuários e o custo de mudar seus procedimentos de negócios para se encaixar em 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 é que elas têm procedimentos de negócios que não correspondem a algo que está no mercado. O que é ótimo - os procedimentos de negócios 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 tem sobre o restante de seu mercado. Substituir o software por algo genérico exigiria que você treinasse novamente o seu pessoal e sacrificasse a vantagem competitiva, ou 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 as pequenas empresas sozinhos.

A partir das suas declarações, parece que você tem muito processador / software. Eu faria duas coisas - adicionar índices (dentro de limites), especialmente para colunas que atualmente não os usam. E eu lançaria o conjunto mais rápido de processadores que você pode fazer, porque parece que é onde você está vinculado, se você não tem tantas leituras de unidade 'cept no pico.

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

    

Answer 9

Isso precisa de uma reestruturação total (re-arquitetura). Reconstrua o sistema a partir do zero. Isso economizará muito no longo prazo (custos indiretos de manutenção). Por enquanto, mande hardware para ele. Acho que essa questão é mais um "business case" do que uma investigação técnica. Em termos técnicos, a resposta é um "poder maior". Em termos de negócios, construa um novo sistema!

    

Answer 10

Resposta técnica:

Você tem um monte de sugestões indicando chaves primárias e a indexação deve ser revisada completamente. O Access também gosta de usar uma coluna SQL Server TimeStamp aka RowVersion em cada tabela, já que isso reduz muito o 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 é muito útil no treinamento de pessoas e você nunca terminará com um sistema que atenda exatamente às suas necessidades de negócios.

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

    

Answer 11

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

A parte mais difícil será convencer o gerenciamento e os usuários a precisarem de uma atualização.

Gerenciamento

Expresse suas preocupações sobre os problemas técnicos, baixo desempenho, medo de falhas bizantinas, etc. Em seguida, apresente 2 CRMs alternativos. Fale sobre integração de negócios, a estratégia geral de ERP para o negócio e, o mais importante, como isso tornará os funcionários mais produtivos e lucrativos. Use estudos de caso. Faça isso não mais do que 15 minutos (a menos que eles querem mais informações). Então você precisa convencer os usuários.

Usuários

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

Há muitos produtos de CRM disponíveis, escolha um que melhor atenda às suas necessidades de negócios.

    

Answer 12

O lançamento de hardware apenas incentiva o design e o gerenciamento mais fracos, até que o sistema seja tão patético que nem funcionará bem com o hardware mais recente e melhor. É hora de olhar para uma implementação melhor. Primeiro analise o que é necessário. Somente quando você entender completamente os requisitos, você poderá começar a procurar a melhor maneira de implementá-los. Quando tiver certeza de que entende os requisitos, comece a verificar se é melhor / mais rentável modificar o que você tem ou começar do zero, possivelmente com algo completamente diferente.

    

Answer 13

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

Normalmente, quando há problemas de desempenho, você olha para coisas como afunilamentos de i / o em discos rígidos / RAID, particionamento do banco de dados, etc ... mas para coisas como fragmentação, você precisa que o banco de dados seja adequadamente projetado para aproveitar isto. Pelo que parece, seu aplicativo nunca será capaz de escalar.

A longo prazo, refazer o banco de dados e o software de front-end para refletir melhor suas necessidades atuais de negócios o ajudará melhor no longo prazo. Seus usuários agradecerão, seu hardware durará mais e economizará muito mais dinheiro a longo prazo do que lançar hardware gigantesco na edição.

    

Answer 14

Dada a sua descrição, a criação de um sistema totalmente novo e personalizado é inútil - você vai acabar exatamente onde começou, ou talvez até pior do que está agora. Então, a menos que você consiga convencer alguém a comprar uma solução de terceiros, sua melhor aposta é refatorar o melhor que puder e usar hardware nele.

Eu diria que você deveria fazer duas coisas: 1) Análise de desempenho no servidor SQL. Você parece ter identificado o lado do servidor como a fonte dos atrasos, então agora você precisa saber quais consultas estão atrasadas e por quê. Em todas as probabilidades, você pode encontrar algumas consultas de hot-spot para otimizar o que lhe traria grandes benefícios. Heck, se você tem clientes que atualizam a cada poucos segundos, veja se você pode diminuir sua taxa de atualização (Será que a lista na tela realmente precisa atualizar a cada 5 segundos? 30 estaria OK? Se não, como cerca de 15? ). Coisas burras, como aumentar os timers de atualização, podem economizar muita sobrecarga, se você conseguir se safar.

2) Jogue mais hardware nele. ESPECIALMENTE jogue enormes quantidades de aríete nela. Você quer muita memória que o banco de dados se encaixa inteiramente na RAM. Fique de olho no seu sistema operacional e nas versões de software (há aparentemente bastante regras com as versões do Windows e qual hardware eles realmente suportam). Se você puder se convencer de que mais núcleos ajudariam, elimine o mesmo número de CPUs e núcleos que conseguir.

    

Answer 15

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

Provavelmente eu tentaria primeiro encher a máquina com o máximo de RAM possível - então eu verificaria se os logs estão sendo gravados em discos que não estão sendo usados para tabelas ou índices. Eu então tentaria ter certeza de que nenhuma tabela teria 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 que você não quebre as coisas nem torne as consultas piores. Embora você tenha dito que as chaves primárias não mostraram muita vantagem em seu banco de dados de teste, você deve verificar sua metodologia de teste - as chaves primárias podem permitir que alguns bancos de dados utilizem o bloqueio de nível de registro , em vez de bloqueios no nível da tabela, o que pode reduzir a contenção que pode não ser mostrada nos testes com apenas alguns usuários.

    

Answer 16

Primeiro, eu concordo com Kyle Hodgson e adiciono PKs. É barato (apenas o tempo) e você pode ver um aumento em suas consultas. E quanto aos índices nas colunas de associação em suas 10 consultas mais feias? Onde estão as varreduras de tabela?

Em segundo lugar, que tal cortar dados no banco de dados? Mais linhas estão sendo retornadas nas consultas do que são realmente necessárias? Eu também concordo com a sugestão de Kyle de RAM (mais dois GB).

Coloque tudo isso em seu artigo (Joseph Kern) sobre o que você propõe para o período intermediário enquanto mapeia o futuro. Pergunte à gerência e aos usuários o que acontece com a organização se o aplicativo atual do CRM crater e não estiver disponível. Talvez isso ajude a pensar no futuro.

    

Answer 17

Obtenha o hardware!

Não só é muito barato no momento, se você optar por um chip da série Xeon 55xx, ele gritará por qualquer coisa que você possa lançar nele.

É apenas uma coisa de risco / recompensa - você pode gastar dinheiro e muito tempo para melhorar o banco de dados ou comprar o caminho até lá mais rápido e mais barato.

    

Answer 18

Considere inverter a opção 3GB de memória e adicionar outros 2GB de memória.