Quais são os motivos para ainda usar o SQL Server 2000?

Das perguntas no StackOverflow e em outros lugares, noto que ainda existem pessoas usando o SQL Server 2000. Para ser sincero, o maior efeito em mim é que preciso lembrar como costumávamos fazer as coisas sem expressões comuns de tabela.

Ainda assim, eu gostaria de saber se existem motivos reais (além de "não está quebrado") para continuar usando o SQL Server 2000. Por exemplo, eu sei que existem pessoas que precisam usar o .NET 1.1 porque precisam oferecer suporte Sistemas Windows 2000. Existem razões práticas semelhantes para não atualizar um sistema SQL Server 2000 para o SQL Server 2008 ou 2005?

A mente dos negócios geralmente é muito diferente da sua. Por que usar algo mais novo se não gera mais receita, mas apenas despesas (migração, reciclagem etc.)?

A melhor razão pela qual consigo pensar é uma variação de "não está quebrada" que é assim: Você tem um aplicativo de negócios que funciona com o SQL 2000, mas gera erros com o SQL 2005. Pode não ser a prioridade de negócios certa para sua organização neste momento, abra o capô do aplicativo (que não está quebrado) e faça com que ele funcione com um banco de dados mais recente.

Suporte legado

O SQL Server 2005 não é totalmente compatível com o SQL Server 2000. O Analysis Services possui grandes incompatibilidades. A mudança para o SQL Server 2005 tem um custo diferente de zero no teste de regressão e na portabilidade. Muitas organizações não precisam mudar, portanto, não irão mudar até que precisem.

A maioria dos fornecedores de DBMS (incluindo MS) suportará uma versão de um DBMS por 10 anos ou mais - mais do que a maioria dos outros tipos de software. Se você cruzar as palmas das mãos com prata (em quantidade suficiente), eles também entrarão em contratos específicos para estender o suporte em uma versão específica por mais tempo.

Outros motivos para se manter com versões mais antigas são realmente motivados por circunstâncias específicas, como evitar uma versão defeituosa conhecida (por exemplo, MySQL 5.1 ou SQL2000 anterior ao SP3) ou problemas de certificação ou compatibilidade.

Mantendo um banco de dados de produção do SQL Server 2000

Para um sistema operacional que funciona e está em uma fase madura de seu ciclo de vida sem muitas mudanças importantes, provavelmente não há motivo convincente para atualizar antes que o DBMS saia do suporte convencional. No entanto, você deve planejar um caminho de atualização ordenada para essa eventualidade. O Oracle é bastante conhecido pelas pessoas que mantêm sistemas de produção em versões antigas.

O SQL Server 2000 está chegando ao fim de sua vida útil, portanto você não gostaria de fazer um novo trabalho de desenvolvimento. No entanto, um aplicativo de produção deve ser mantido com um plano para sair quando necessário. Você provavelmente terá uma reescrita em suas mãos se seu aplicativo for escrito em VB6 ou ASP clássico - mas isso é um problema diferente; -}.

O balcão

Se eu tivesse um projeto greenfield, normalmente recomendaria a versão mais recente da plataforma DBMS, simplesmente porque ela oferece a maior janela de suporte ao fornecedor. Ninguém ainda deve ter o SQL Server 2000 como padrão corporativo para novos projetos - a EOL está muito próxima. Para um novo projeto, esse é de longe o argumento mais forte para mudar para uma versão mais recente. Argumentos sobre como economizar dinheiro não retêm água; o aplicativo terá custos de transferência desnecessários dentro de alguns anos se você iniciar o SQL2000 agora.

O ponto principal do trabalho em campo é que uma seleção excessivamente conservadora reduz a vida útil do aplicativo antes que uma atualização seja necessária. Normalmente, seria necessário um motivo específico para não ir para a versão atual de uma plataforma DBMS.

Não atualizamos porque temos um software financeiro que depende disso, e o fornecedor está apenas pensando em dar suporte a esse novo "SQL 2005" sobre o qual estão ouvindo o blog das crianças malucas ultimamente.

Francamente, dói- me ter uma mistura de coisas para apoiar, mas não tanto quanto machucaria todos na empresa ao surgir um problema com o sistema financeiro e, em seguida, fazer com que o fornecedor de software financeiro aponte para nós e rimos quando pedimos ajuda e mencionamos que os problemas começaram desde que atualizamos para o SQL 2005 antes que eles o ratificassem.

Também há muito a ser dito para não consertar as coisas se elas não estiverem realmente quebradas. Eu quero atualizar todos os meus servidores SQL para 2008 em algum momento ... eu realmente faço. Mas há muito mais coisas que eu poderia fazer que, na verdade, melhoram os resultados da empresa de maneiras compreensíveis e quantificáveis ​​para meus gerentes e usuários ... bem, isso sempre virá em primeiro lugar.

Você mencionou que os desenvolvedores não gostam de trabalhar com o SQL 2000 na sua resposta à resposta do Mastermind. Eu suspeito que um método de lidar com isso seria o que meus chefes usariam em mim se eu decidisse "não gostar" de dar suporte ao SQL 2000: "Obrigado por seu tempo trabalhando aqui, a porta está à sua esquerda". No final do dia, todos somos pagos para fazer as coisas funcionarem, gostemos ou não.

No nosso caso, é menos um caso de 'por que continuar usando 2000' do que 'a atualização custa QUANTO?'. A maioria dos nossos aplicativos não usa nada que precise de recursos específicos de 2005, então não há motivo convincente e provavelmente não será até que a Microsoft pare de dar suporte a ele.

Custo.

O software mais recente ainda é um software adicional, que custa dinheiro adicional.

Isso pode ser, e geralmente é, uma falsa economia devido às muitas desvantagens do uso de sistemas desatualizados, mas é a única razão real que faz sentido.

A nova licença do SQL Server 2008 (padrão) custa um pouco menos de US $ 2.000 para 1 servidor com 5 CALs ou US $ 6.000 para 1 licença de CPU. Posso ouvir meu antigo chefe dizendo "não está quebrado, mas vai custar quanto atualizar esses 2 servidores?" (naquele momento, 2 x CPU dupla exigindo licenças de CPU).

Tendo usado o SQL2000 por sete anos, minha primeira experiência em 2005 foi em um ambiente VMWare ESX. O desempenho foi ruim (o ISP estava fornecendo a experiência do VMWare e, quando começamos o teste de carga, descobrimos que eles estavam tendo grandes problemas, não apenas com o servidor, mas impactando nossa experiência) e combinados com tudo que estava sendo movido / renomeado (o antigo gerente da empresa estava muuuito muito mais rápido) - ficamos felizes em adiar a atualização. Estávamos aguardando o lançamento de 2008, então só estamos atualizando para 2008 (ou migrando alguns dados para o MySQL / PostgresSQL).

A Microsoft ainda estava dando suporte a mainstream para 2000 até algum tempo no ano passado, então foi apenas recentemente que tivemos um motivo mais convincente para atualizar.

As pequenas empresas também têm um problema de recursos - aprender, planejar, testar a atualização leva tempo e impacta em outras operações. Se você precisar atualizar outro aplicativo que esteja no SQL Server ao mesmo tempo, isso também poderá ficar muito caro.

Por um tempo, flertamos com a migração para o código aberto, e enquanto isso era uma possibilidade, também congelamos qualquer atualização.

Por que não atualizar para o sql server 2008, você pode realmente reduzir seu custo, devido à compactação de dados, manutenção mais fácil e melhor desempenho (índices filtrados)? Recentemente, atualizamos uma instalação do sql server 2000 e economizamos 75% do espaço em disco, e o desempenho aumentou dramaticamente.

Outra melhoria foi a simultaneidade devido ao novo mecanismo de bloqueio introduzido no sql server 2005.

/ Håkan Winther

As grandes organizações são adversas ao risco e ignorantes, o que leva a algumas decisões realmente idiotas. Quando eu fazia o Unix por volta de 2003/2004, estávamos presos a um ambiente Solaris 2.5.1 que foi lançado quando eu estava na 10ª série ou mais porque era uma tecnologia "comprovada" e era "muito caro" para atualizar.

Caro demais costuma falar com PHB por "Eu fui burro em fazer um orçamento para uma atualização de US $ 1000 em um projeto de US $ 10 milhões".

No caso do software de pilha da Microsoft, as pessoas geralmente são adversas à atualização porque não queriam lidar com o troll de licenciamento da empresa e compraram uma licença OEM da Dell / IBM / etc, e não sentem vontade de lidar com o problema. aros burocráticos envolvidos na modernização.

Eu não compro (trocadilhos) o argumento "custo inicial", mas infelizmente o custo inicial é algo que muitos PHBs obcecam, por isso é válido deixá-lo em pé.

Para mim, o único motivo convincente seria os aplicativos que o utilizam. Se você é um local do SharePoint 2003, por exemplo, NÃO HÁ MANEIRA de atualizar para o SQL 2005 ou 2008 sem também realizar uma atualização do SharePoint, o que não é uma questão trivial.

Em nossa organização, todo novo desenvolvimento deveria estar no SQL 2005/2008, mas temos tantos aplicativos herdados do 2000, que simplesmente não vale o tempo / energia / dinheiro para convertê-los todos.

Além dos problemas de compatibilidade (o DTS para SSIS é o maior para nós), também implementamos um conjunto de diretrizes / restrições de segurança no SQL 2005 que não tínhamos aplicado no SQL 2000. (sem usuários de dbo, apenas permissões de esquema, etc.)

Em nossa organização, há várias razões. Alguns são bem específicos para o nosso caso, e outros um pouco mais genéricos.

1) Incompatibilidades. Tivemos alguns casos em que o software que foi gravado internamente para o SQL2005 apresenta problemas ao instalar no SQL2000. O caso que eu vi recentemente acabou sendo devido a parâmetros explicitamente declarados que não existem em 2000 e a uma diferença no nome da tabela de índice do sistema. (sys.indexes x sysindexes)

2) Treinamento. Nossos desenvolvedores certamente conhecem 2005, e preferem estar desenvolvendo nele, ou 2008 já. No entanto, o trabalho de manter tudo operacional cabe ao NOC, não aos desenvolvedores. Ninguém em nosso NOC teve nenhum treinamento formal em SQL, e as diferenças entre os dois, apenas do ponto de vista da ferramenta administrativa, são suficientes para fazer disso uma consideração.

3) Custo da atualização dos produtos existentes. Para nós, este é um grande problema. Não estou falando do custo da licença da Microsoft aqui. Em nossos negócios, uma atualização em qualquer um de nossos produtos existentes (mesmo que não tenhamos feito a atualização retroativa de tudo o que já existe no campo) exigiria um processo caro e demorado de recertificação por meio de vários laboratórios de testes regulatórios e de certificação. Estamos construindo novos produtos no SQL2005, mas não atualizando os mais antigos por esse motivo.

O processo de certificação também significa que teríamos uma mistura de novas construções, onde determinadas jurisdições obteriam o SQL2000 e outras o SQL2005, com base em se as aprovações já haviam sido recebidas ou não. Preferimos, pelo motivo 2, manter nosso ambiente de produção o mais consistente possível.

4) diferenças gerais. Esta é realmente uma extensão do # 1. Há muitas pequenas coisas que mudaram, algumas das quais nos causam dores de cabeça. Por exemplo, o SQL2005 no Server2003 aplicará políticas de senha do Windows em contas sql. Não é uma coisa ruim por si só, mas quebra quase todo o nosso software (e muitos terceiros) devido à maneira como interagimos com o banco de dados.

Em suma, inércia.

Um bom post que já fez a mesma pergunta.

Eu sei que existem pessoas que precisam usar o .NET 1.1 porque precisam oferecer suporte aos sistemas Windows 2000.

Seguindo essa lógica, um motivo prático para executar o MSSQL 2000 é porque você pode oferecer suporte aos sistemas Windows NT 4!

Acredite ou não, mas o SQL Server 2005 é executado no Windows Server 2000.