Instância do SQL Server: Devo usar várias instâncias ou bancos de dados?

Question

Eu tenho um servidor razoável conectado a uma SAN que estará executando servidores SQL para múltiplos do mesmo aplicativo. Não há problemas de segurança com um aplicativo sendo capaz de ler o banco de dados do outro.

Estamos também em janelas de 32 bits também.

Eu sou da opinião de que seria melhor usar uma instância no servidor, habilitar o AWE para que a instância do servidor possa usar quase todo o RAM que temos e depois executar cada um dos bancos de dados na instância.

No entanto, eu fui rejeitado pelos deuses do departamento de TI, então estou muito curioso para ouvir seus pensamentos sobre isso. Do ponto de vista do desempenho, estou incorreto que uma instância de SQL é melhor que duas?

Eu sei que poderíamos fazer algumas coisas de failover, mas fazer isso em uma lâmina só parece ser um exagero para mim.

    

Answer 1

O SQL Server 2000 e 2005 Workgroup e Standard (32 bits, não tenho certeza sobre 64 bits) usarão apenas um máximo de 2 GB de memória, portanto, com duas instâncias, você poderá usar os 4 GB completos. Isso seria verdade mesmo se você estiver executando o SQL Standard de 32 bits no x64 Windows, mais de fato, já que você deseja uma instância por 2 GB de memória.

Em princípio, usar uma única instância com dois bancos de dados é mais rápido do que duas instâncias com um banco de dados cada, embora eu não esteja convencido de que seja uma grande diferença. Ter instâncias separadas pode ser útil para o gerenciamento. Por exemplo, se você usar logins SQL e houver conjuntos diferentes de logins para bancos de dados diferentes, o uso de instâncias separadas pode facilitar o controle de logins.

Então a resposta para sua pergunta é "Depende": -)

JR

Comentário de Re Spence: O SQL Server Standard no Windows de 32 bits pode usar no máximo 2 GB de memória. O SQL Server Enterprise pode usar 3 GB se você usar a opção / 3GB. No Windows 2003 Enterprise com AWE, até pelo menos 16 GB de memória podem ser usados (possivelmente mais) para que você possa obter um melhor valor da memória executando mais de uma instância do SQL Server.

Eu tenho medo que a resposta ainda seja "depende". Se você tiver muita memória, ou seja, 8 GB ou 16 GB, então você deseja colocar os maiores bancos de dados em instâncias separadas para que eles possam ter 2 GB (ou 3 GB com / 3 GB) cada. Se você tiver apenas 4 GB, provavelmente usaria uma única instância e a opção / 3GB como a pequena quantidade de memória extra usada por ter duas instâncias não valeria a sobrecarga.

Como outros comentaram abaixo, pode haver outras considerações. Se você fizer referência a dois bancos de dados ao mesmo tempo, por exemplo em uma consulta de seleção ou se você inserir de um banco de dados em outro, você os deseja na mesma instância para velocidade.

    

Answer 2

32 bits é um beco sem saída.

No SQL2K5, o consumo de memória para coisas como planejar a compilação, o próprio tamanho do plano e, consequentemente, o cache do proc, aumentaram significativamente em mais de 2k. Além disso, outros componentes, como o cache de tokens de permissão, tendem a crescer se você tiver muitos usuários (ou seja, grandes org e mid tier se fazem passar). Como todos esses recursos não podem se beneficiar do AWE, é difícil adaptar um sistema ocupado a um espaço de memória de 32 bits. Se você tiver consultas e planos complexos, a agregação das instâncias pode resultar em uma porcentagem muito alta do buffer pool sendo roubado para esses caches deixar um pequeno buffer pool para os dados, resultando em despejo de planos de constante de cache e baixa expectativa de duração da página.

Por outro lado, várias instâncias de SQL na mesma caixa tendem a pisar nos dedos uns dos outros, provocando pressão de memória uma na outra. Como os gerenciadores de memória das instâncias não se comunicam entre si, é muito mais difícil encontrar um equilíbrio em comparação com uma única instância. Além disso, o agendamento do processador de várias instâncias pode sofrer de problemas semelhantes, pois o sistema operacional interromperá os agendadores de SQL entre as instâncias, resultando em lixo na cache da CPU.

    

Answer 3

IMHO, eu diria que vocês, deuses, estão errados neste. Contanto que não haja nenhuma preocupação de segurança em lidar com vários bancos de dados sendo executados na mesma instância, esse é o caminho a ser seguido. Instâncias múltiplas sempre introduzem alguma sobrecarga, o que efetivamente dará ao seu servidor um desempenho abaixo do ideal. Em termos de administração, também é melhor manter uma instância.

    

Answer 4

Uma vantagem de várias instâncias é que ela dimensiona efetivamente seu tempdb - o que pode ser um benefício de desempenho se seu aplicativo usar muito o tempdb e você tiver o tempdb de cada instância em eixos diferentes.

    

Answer 5

Como sempre, isso depende: Os bancos de dados precisarão "conversar" uns com os outros?

Se for para o mesmo aplicativo, você encontrará momentos em que deseja que um banco de dados leia ou grave no outro. Se esse for o caso, dois bancos de dados em uma única instância são preferíveis. (Nenhum servidor vinculado, logins compartilhados, tempdb compartilhado são todas as vantagens aqui.)

Se, no entanto, os dois bancos de dados estiverem completamente isolados e nunca se comunicarem entre si e de fato não tiverem nada a ver um com o outro (por exemplo, SharePoint e SAP), duas instâncias podem ser preferíveis. (A capacidade de executar em níveis diferentes do Service Pack, ou limitar a memória usada por uma instância, são duas vantagens do topo da minha cabeça.)

    

Answer 6

Temos um aplicativo que usa procedimentos armazenados grandes e complexos que encapsulam a maior parte de nossa lógica de negócios.

Nossas máquinas operam em janelas de 32 bits. Anteriormente, nosso backend consistia em uma instância do SQL com vários bancos de dados.

Agora mudamos para uma arquitetura onde temos várias instâncias no servidor.

O desempenho do nosso aplicativo caiu muito no mesmo dia em que o testamos no novo framework e a maioria de nossos formulários (especialmente aqueles que extraem seus dados de procs armazenados grandes e complexos) expirou.