Quais são os motivos objetivos de negócios para preferir o SQL Server 2012 em relação ao 2008 R2?

Minha empresa está enfrentando a decisão de comprar o SQL Server 2012 Denali ou o SQL Server 2008 R2 para um novo servidor de banco de dados. Estou procurando por razões objetivas para escolher um sobre o outro.

Nossas exigências:

• Edição padrão (por razões financeiras e falta de recursos corporativos)
• Carga de trabalho OLTP (isso significa que não precisamos das novas funções de janelas e índices de armazenamento de colunas)
• Tamanho do banco de dados de 10 a 100 GB
• Não são necessários recursos de inteligência de negócios. Somente o mecanismo relacional é necessário
• Espelhamento de banco de dados síncrono

Atualmente, os seguintes motivos são conhecidos por mim:

Denali do SQL Server 2012

• Versão mais recente disponível

SQL Server 2008 R2

• Tecnologia comprovada

Não consigo encontrar muitas razões técnicas para preferir uma à outra. Basicamente, tudo se resume a escolher a tecnologia comprovada que está sendo executada com sucesso em relação à versão mais nova e melhor disponível.

Quais são as razões objetivas para tomar a decisão?

Todo mundo está empolgado com o AlwaysOn e o ColumnStore, mas muitos dos benefícios do SQL Server 2012 não são exclusivos das edições de última geração. Não quero parecer um porta-voz, mas fiz muitas apresentações no SQL Server 2012 e acho que ele tem muito a oferecer em qualquer edição que combina com você.

• Bancos de dados parcialmente contidos, que permitem mover bancos de dados entre servidores ou ambientes com menos poucos grilhões (ou seja, logons no nível do servidor e dependências de agrupamento do servidor - as versões futuras lidarão com itens mais espinhosos, como servidores vinculados e trabalhos do agente).

• Agora, o Management Studio é uma ferramenta muito melhor, alinhada ao Visual Studio. O IntelliSense é melhor e vários outros recursos facilitam a edição. Agora, é claro que você pode ter o 2008 R2 em seu servidor e usar a versão 2012 do SSMS, mas não tenho certeza de como isso funciona em termos de licenciamento, e algumas lojas não desejam versões mistas (prefiro ter as ferramentas mais recentes em minha estação de trabalho até para gerenciar servidores de nível inferior). Eu escrevi no blog sobre as mudanças desde o início, quando ainda havia bugs, então ignore os negativos, pois a maioria ou todos são corrigidos no RTM. Tremo agora quando tenho que usar uma versão anterior do SSMS.

• Os aprimoramentos de metadados permitem inspecionar conjuntos de resultados de objetos e consultas ad hoc, além de permitir que você modele melhor a saída das consultas.

• As Funções de servidor personalizadas permitem definir um conjunto de permissões muito mais granular para os usuários em um nível de função, em vez de conceder / revogar uma a uma, ou apenas ceder à complexidade e fornecer a eles sysadmin.

• O FileTable permite gerenciar uma pasta como uma tabela de documentos, mas ainda ter controle externo sobre o conteúdo (imagine poder fazer isso com o T-SQL e imagine como seria difícil fazer no cmd ou no PowerShell:) UPDATE C:\Docs\*.* SET ReadOnly = 1 WHERE Author = 'Bob' AND Created < '20100101';. O FileStream atende ao WinFS e obtém alguma usabilidade para inicializar.

• Os aprimoramentos do T-SQL permitem que você faça muitas coisas problemáticas nas versões anteriores:

  • THROW (pense nisso como re-raise)
  • OFFSET/FETCH (paginação mais simples, padrão ANSI)
  • SEQUENCE (mecanismo de IDENTIDADE centralizado, como no Oracle)
  • Aprimoramentos de janelas / enquadramento (várias coisas aqui, como uma execução impressionante totaliza o desempenho)
  • IIF()/ CHOOSE()/ CONCAT()/EOMONTH()
  • Construtores de data / hora (por exemplo DATETIMEFROMPARTS) semelhantes aos DateSerialdo VB
  • PARSE()/ FORMAT()- como seus equivalentes .NET
  • TRY_CONVERT()/ TRY_PARSE()- retorna NULLse CONVERT/ PARSEfalhar

• O Extended Events possui uma interface aprimorada para configuração / visualização e, finalmente, cobre completamente a funcionalidade de rastreamento / auditoria (incluindo um rastreamento de causalidade muito melhor).

• Muitos novos DMVs , procedimentos do sistema e aprimoramentos do ShowPlan para diagnóstico e solução de problemas de desempenho. Veja também o que o CSS está chamando de " The Black Box Recorder ".

• O Server Core permite que você execute em um servidor mínimo e sem todos os componentes da interface do usuário (menor área de superfície significa que é mais seguro e com manutenção reduzida, pois menos partes do sistema operacional estão sujeitas ao Windows Update).

• A Pesquisa de texto completo obtém alguns aprimoramentos importantes no desempenho subjacente, bem como pesquisa semântica (pense em palavras-chave) e proximidade personalizável / NEAR.

• O AWE não é mais suportado , o que significa que sua instância do SQL Server no x86 com 32 GB de RAM poderá usar apenas 4 GB - então você finalmente terá motivação para sair do seu antigo hardware de 32 bits.

A seguir, são apresentados apenas alguns exemplos sobre "evidências reais a favor ou contra a confiabilidade na primeira versão de qualquer nova versão", conforme solicitado. Isso não pretende ser uma análise completa, mas uma sugestão sobre o que você pode querer pesquisar.

Você pode pesquisar no Google "Lista de problemas corrigidos pelo SQL Server 2008 Service Pack 1" e "Lista de problemas corrigidos pelo SQL Server 2008 Service Pack 3" no site do MSDN. Compare o número e a gravidade dos problemas nas duas listas. Na IMO, a primeira lista é mais longa e possui mais itens que podem arruinar o meu dia, como:

• Mensagem de erro quando você se conecta a uma instância nomeada do SQL Server em um computador cliente que esteja executando o Windows Vista ou Windows Server 2008
• O Log Reader Agent ignora algumas transações quando o Log Reader Agent é executado para replicar transações
• Mensagem de erro ao executar uma consulta que envolve uma operação de associação externa no SQL Server 2008
• Mensagem de erro ao executar uma operação de atualização ou exclusão em uma tabela que não possui um índice em cluster criado no SQL Server 2008
• Uma consulta que usa parâmetros e a opção RECOMPILE retorna resultados incorretos quando você executa a consulta em várias conexões simultaneamente no SQL Server 2008

Vamos detalhar mais um nível e considerar apenas um comando, o MERGE. Foi lançado como parte do SQL 2008 com vários problemas, descritos nos seguintes links:

• Um interessante MERGE Bug ,
• Bug e correção do SQL Server 2008 RTM MERGE ,
• Erro MERGE quando a restrição de chave estrangeira é criada no índice não clusterizado (2008RTM) ,
• Erro de instrução MERGE quando INSERT / DELETE usado e filtrado índice ,
• Os planos de consulta MERGE permitem violações de restrição FK e CHECK ,
• A instrução MERGE ignora a Integridade Referencial ,
• DELETE e MERGE parametrizados permitem violações de restrição de chave estrangeira .

Como tal, na época do lançamento original do SQL 2008, decidi não usar o MERGE. Estou usando muito o MERGE agora, no 2008 R2, e acho que é realmente um ótimo recurso.

Editar: aqui está a lista de defeitos no SQL 2012 que foram corrigidos recentemente . Espero que ajude.

Outra edição: escolhi MERGE para uma análise mais detalhada, porque é uma melhoria muito importante. De fato, é um passo importante para alcançar a Oracle e melhora nossa produtividade. Como tal, o MERGE foi muito comercializado no momento do lançamento do SQL 2008. No entanto, ele não estava completamente pronto para uso em sistemas de produção sérios quando foi lançado originalmente, e não havia maneira fácil de conhecê-lo nas apresentações / artigos / postagens do blog e similares.

Da mesma forma, o isolamento de instantâneo é um novo recurso impressionante que simplesmente funciona, mas invocar UDFs escalares nas restrições CHECK não funciona em todos os casos e, como tal, não deve ser usado na produção quando precisamos de integridade dos dados. No entanto, os dois novos recursos foram recomendados nas apresentações "O que há de novo no SQL xxxx", além de livros, artigos etc., e com entusiasmo semelhante.

Precisamos ter muito cuidado com os novos recursos - nem todos serão úteis / confiáveis ​​/ com desempenho.

Um ponto que não foi mencionado aqui é completamente irrelevante para o conjunto de recursos. Se você estiver fazendo uma nova compilação, poderá adiar a atualização do banco de dados por um pouco mais de tempo, para economizar custos de migração.

Para um projeto greenfield, você tem espaço para respirar os bugs e aumentá-los com o fornecedor, se eles aparecerem, portanto não é um processo totalmente descontrolado. Eu participei de um dos primeiros projetos de data warehouse no SQL Server 2005, assim como foi para a RTM e nos demos bem com isso.

Se o conjunto de recursos do 2008R2 fizer o que você deseja, a decisão está sob algum risco de bugs / soluções alternativas em relação ao valor de adiar a necessidade de atualizar e salvar um ciclo de atualização.

Quando você está comprando um novo, a escolha é muito diferente da que você está pensando em atualizar. Comprando novo, acredito que você sempre deve comprar a versão mais recente possível. A versão de 2008 não será mais suportada muito antes da versão de 2012. É melhor começar de novo com o mais recente, pois você usará esse back-end por um longo tempo.

Quanto à necessidade do primeiro service pack, ele será lançado antes que você perceba e, como você está desenvolvendo um novo desenvolvimento, os problemas corrigidos provavelmente não o afetarão tanto quanto um banco de dados herdado com milhões de registros.

Agora, se você está apenas obtendo um novo servidor, mas colocando um banco de dados antigo, a questão se torna: do que você está atualizando? Se o banco de dados já for um banco de dados de 2008, será significativamente menos arriscado usar a mesma versão. Se você estiver atualizando, verifique se é possível atualizar diretamente para 2012 a partir da sua versão.