SQL2005 vs SQL2008

2

Estamos investigando a substituição de um servidor SQL2000 existente no Windows2003 (32 bits) por um novo hardware e uma versão mais recente.

Estamos vendo um aplicativo que requer pelo menos o SQL2005, mas também será executado no SQL2008. Nossos outros DBs também devem ser executados.

Alguém teve alguma experiência boa ou ruim com qualquer versão?

O hardware que provavelmente obteremos será capaz de 64 bits, então rodar o SQL2008 de 64 bits também é uma opção.

Obrigado

    
por BillN 23.06.2009 / 20:32

10 respostas

7

Eles são ambos sólidos como rocha. Se você tiver a opção, vá direto para o SQL Server 2008 - há melhorias em cada versão, e mesmo se você for um dos tipos de pessoas que gostam de esperar até que um service pack seja lançado antes de instalar um aplicativo, o SQL Server 2008 O SP1 está fora há mais de um mês.

Aqui é um diretório dos novos recursos do SQL Server 2008. Também é inerente a cada lançamento (mas mais difícil de detectar) são melhorias no mecanismo de armazenamento que permitem ao SQL Server executar de forma mais otimizada e confiável.

    
por 23.06.2009 / 20:39
6

Você deve não ter problemas para transferir bancos de dados do SQL2000 para 2005 ou 2008, mas você desejará fazer um teste adequado dos aplicativos antes de fazer isso em um ambiente ativo (por via das dúvidas).

Ainda não tenho experiência com o SQL2008, mas movemos muitos DBs de 2000 para 2005 com apenas um pequeno problema com algum código em um aplicativo antigo. Esse problema foi devido a como algumas visualizações foram definidas / chamadas nesse projeto. Se uma visualização definir um campo como "SELECT [somefield] = NULL, [e], [the], [rest] FROM [sometable]", o aplicativo executará "SELECT * FROM [theview] WHERE [algum campo] = 'valor' "poderia causar um erro cast-of-varchar-to-int, às vezes (mas não em todos os casos) no SQL2005, onde nunca o fez no SQL2000. A solução simples era alterar a exibição para [somefield] = CAST (NULL AS NVARCHAR). Você provavelmente não encontrará esse problema em particular, e não tivemos outros, mas isso prova que você precisa fazer um teste de aplicativo completo em um ambiente de desenvolvimento / teste antes fazendo o salto para um serviço ao vivo .

Nós movemos bancos de dados de SQL2005 de 32 bits para servidores SQL2005 de 64 bits sem nenhum problema, e espero que ir de 64 para 32 funcione da mesma forma.

Tome nota que, uma vez movido para SQL2005, mover um banco de dados de volta para SQL2000 é um problema considerável, então trabalhe com meu ponto principal , certifique-se de testar completamente antes de mover seus próprios aplicativos . Além disso, certifique-se de obter uma palavra escrita clara de fornecedores externos envolvidos de que seus bancos de dados / código foram testados em relação à versão do SQL Server selecionada.

Editar: um outro ponto relevante: nossos aplicativos que movemos dessa maneira não fazem uso de serviços extras como indexação de texto completo, serviços de relatórios e assim por diante - apenas o principal serviço de banco de dados SQL - por isso não posso comentar se os aplicativos que usam esses recursos extras são migrados sem problemas.

    
por 23.06.2009 / 20:52
3

Fale com o fornecedor do aplicativo. Se eles não puderem te dizer, eu faria um teste piloto no SQL Server 2008 e verificaria se funciona. As probabilidades são boas. (E diga coisas desagradáveis ao seu fornecedor por não saber em quais plataformas o aplicativo funcionará.)

    
por 23.06.2009 / 20:39
2

O SQL Server 2008 também suporta recursos SQL mais recentes que alguns dos usuários do seu banco de dados podem apreciar. Se for somente produção, talvez não, mas se você tiver desenvolvedores conectando-se usando uma ferramenta de consulta, eles poderão apreciar esses recursos adicionais.

E eles podem achar que você é um tecladista e dar cookies, um abraço, um terceiro monitor ou algo igualmente incrível.

Pelo menos, se você fosse meu sysadmin, eu o faria.

    
por 23.06.2009 / 23:17
1

Você deve executar o sql 2008 de 64 bits. Se o aplicativo suportar 2008, você deve estar na versão mais recente. Note que você não pode comprar 2005, você vai comprar 2008 e fazer downgrade ou comprar 2008 e usá-lo.

    
por 23.06.2009 / 21:20
1

Acredito que a maior vantagem do 2k8 em relação ao 2k5 é a compactação de dados . Você tem compactação de página do que meios (muito menos) de E / S, bancos de dados menores para gerenciar, backups menores e assim por diante e assim por diante.

    
por 23.06.2009 / 22:10
1

Eu diria, use o SQL Server 2008, mas cuidado com a versão de 64 bits. Eu tenho usado a versão de 64 bits do SQL Server 2008 por meio ano, e eu acho que tem algumas grandes melhorias em relação ao SQL 2005, mas você deve saber que não há driver Jet de 64 bits para o Excel / Access. Se você precisa fazer alguma integração com o Excel, então você está preso com o SSIS no modo de 32 bits. (você ainda pode usar o SQL 2008 de 64 bits, mas não pode fazer OPENQUERY para o Excel / Access.

Se você também precisa acessar o Sybase, então você precisa abrir sua carteira e pagar muito por um driver de 64 bits do OpenLinc. Lembre-se, você precisa do OLEDB e do driver ODBC e é limitado a x conexões simultâneas e limitado a y núcleos de CPU. Vamos dizer que você tem (como no meu caso) um servidor com 4 processadores Quad e não precisa de mais do que 5 conexões, é como $ 20.000 ou algo parecido. E então você precisa de um servidor de teste com o OpenLinc!

/ Håkan Winther

    
por 24.06.2009 / 12:14
1

Um dos recursos que eu gosto no SQL 2008 é como algumas pessoas dizem Datacompression, mas o recurso que eu mais gosto é o índice filtrado.

Com esse recurso, você pode criar índices de cobertura em um pequeno subconjunto de dados para consultas especializadas. Isso melhorará muito o desempenho das consultas que usarão o índice filtrado.

Digamos que você tenha uma tabela como essa

CREATE TABLE [DWH].[contract](
    [ID] int IDENTITY(100000000,1) NOT NULL,
    [reportDate] [datetime] NOT NULL,
    [contractnumber] [varchar](15) NOT NULL,
    [_instrument_ID] [int] NULL,
    [_package_ID] [int] NULL,
    [_portfolio_ID] [int] NULL,
    [_counterpart_ID] [int] NULL,
    [ValueX] [datetime] NULL,
    [ValueY] [datetime] NULL,
    [ValueZ] [varchar](20) NULL,
    [Status] int not null,
 CONSTRAINT [PK_contract] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

CREATE NONCLUSTERED INDEX [IX_contract_1] ON [DWH].[contract] 
(
    [reportDate] ASC
)
INCLUDE ( [ValueX],[ValueY],[ValueZ]
) 
WHERE  STATUS=10
GO

Quando você usa a seguinte consulta, o mecanismo não precisa fazer uma pesquisa de índice e uma pesquisa de índice em cluster:

SELECT ValueX, ValueY, ValueZ FROM dwh.contract WHERE reportdate=GETDATE() AND Status=10

O SQL resolverá a consulta apenas com uma busca de índice, já que todos os dados necessários para a consulta existem no índice. E, além disso, o índice contém apenas registros com Status = 10, isso afetará o desempenho de INSERT / UPDATE / DELETE.

/ Håkan Winther

    
por 24.06.2009 / 12:39
1
O que quer que você decida, não compre uma licença do SQL Server 2005 quando puder comprar uma licença do SQL Server 2008 e uma nota inferior para executar o SQL Server 2005. Dessa forma, se você decidir executar o 2008, já terá uma licença. Eu recomendo strongmente executar o SQL Server 2008

    
por 25.06.2009 / 19:16
0

No geral, 2008 é um produto incrível, mas há alguns recursos descontinuados de 2000 a > 2005 e também descontinuados de 2005 a > 2008 (só é permitido um link por causa de rep, mas pesquise "Descontinuado Database Engine Functionality no SQL Server 2008" nos Manuais Online). Você deve estar atento para aqueles que poderiam ser pegadinhas para seus aplicativos / bancos de dados existentes. Há também alguns problemas de precisão com o modo de lidar com os datetimes que você pode executar (2008 tem maior precisão e isso pode fazer com que algumas consultas parem de funcionar se assumirem .000 por frações de segundo).

    
por 25.06.2009 / 19:39