Instanciação do SQL Server: devo usar várias instâncias ou bancos de dados?

Instanciação do SQL Server: devo usar várias instâncias ou bancos de dados?

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

Infelizmente, também estamos em janelas de 32 bits.

Sou da opinião que seria melhor usar uma instância no servidor, habilitar o AWE para que a instância do servidor possa usar quase toda a memória RAM que temos e então executar cada um dos bancos de dados em uma instância.

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

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

Responder1

O SQL Server 2000 e 2005 Workgroup and Standard (32 bits, não tenho certeza sobre 64 bits) usará no máximo 2 GB de memória, portanto, ter duas instâncias permitiria que você usasse 4 GB completos. Isso seria verdade mesmo se você estivesse executando o SQL Standard de 32 bits no Windows x64, mais ainda, 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 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 diferentes conjuntos de logins para bancos de dados diferentes, o uso de instâncias separadas poderá facilitar o controle de logins.

Portanto, a resposta à 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 poderá 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 melhor valor de sua memória executando mais de uma instância do SQL Server.

Receio 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 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, pois 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 inserir de um banco de dados em outro, você os desejará na mesma instância para maior velocidade.

Responder2

32 bits é um beco sem saída.

No SQL2K5, o consumo de memória para coisas como compilação do plano, o tamanho do plano em si e, portanto, o cache do processo aumentaram significativamente em mais de 2k. Além disso, outros componentes, como o cache do token de permissão, tendem a crescer se você tiver muitos usuários (ou seja, representações de organizações grandes e de nível intermediário). Como tudo isso não pode se beneficiar do AWE, você terá dificuldade em encaixar um sistema ocupado em um espaço de memória de 32 bits. Se você tiver consultas e planos complexos, a agregação das instâncias poderá resultar em uma porcentagem muito alta do buffer pool sendo roubada para esses caches, deixando um pequeno buffer pool para os dados, resultando em remoção constante do cache de planos compilados e baixa expectativa de vida útil da página.

Por outro lado, múltiplas instâncias de SQL na mesma caixa tendem a pisar umas nas outras, provocando pressão de memória umas nas outras. 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 múltiplas instâncias pode sofrer problemas semelhantes, pois o sistema operacional irá antecipar os agendadores SQL entre as instâncias, resultando na destruição do cache da CPU.

Responder3

IMHO, eu diria que vocês, deuses da TI, estão errados nisso. Contanto que não haja nenhuma preocupação de segurança em ter vários bancos de dados em execução na mesma instância, esse é o caminho a seguir. Multi-instâncias sempre introduzem alguma sobrecarga, o que efetivamente proporcionará ao seu servidor um desempenho abaixo do ideal. Em termos de administração, também é melhor limitar-se a uma instância.

Responder4

Como sempre, depende:Os bancos de dados precisarão “conversar” entre si?

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

Se, no entanto, os dois bancos de dados estiverem completamente isolados e nunca se comunicarem entre si e, na verdade, não tiverem nada remotamente a ver um com o outro (ou seja, SharePoint e SAP), então duas instâncias poderão ser preferíveis. (A capacidade de executar em diferentes níveis de Service Pack ou limitar a memória usada por uma instância são duas vantagens que estou pensando.)

informação relacionada