Como escalar o SQL Server 2008 ou 2012?

Como se escala o SQL Server 2008 (ou 2012)? Basicamente, entendo que existem duas opções:

Ampliar:

Se a CPU estiver ligada, posso ver claramente passando de 1 núcleo da CPU para 2 a 4. Ou se o uso da RAM aumentar, basta adicionar mais RAM. O SQL Server 2008/2012 realmente pega a folga e aumenta a escala dessa maneira, assumindo que NÃO há alterações no nível do aplicativo? Para minimizar a especulação, suponha que eu não esteja fazendo algo estúpido, como queimar ciclos da CPU, fazer junções cruzadas etc.

Dimensionar:

Não está muito claro como o dimensionamento funcionaria. Quero dizer, se eu adicionei outro servidor SQL ao lado do meu primeiro, como a consulta sabe em qual servidor executar? Existe algum balanceador de carga na frente (e ele vem com o software SQL Server?)? Isso implica alterações no nível do aplicativo para que o dimensionamento funcione? Ou preciso compartilhar os dados e ter um código personalizado que chame o servidor de banco de dados correto, dependendo da chave de compartilhamento de dados?

Gostaria de receber sugestões de pessoas mais experientes.

O SQL Server não é dimensionado como tal . Ele aumenta.

Existem 3 áreas para fazer isso, sujeitas a limitações de edição

• Núcleos da CPU
• RAM
• Armazenamento

E é claro, use uma edição superior, por exemplo, Enterprise

O SQL Server não fragmenta e qualquer solução desse tipo (você pode pesquisar soluções de fragmentação do MySQL) adiciona complexidade e sobrecarga ao sistema.

A expansão de um servidor (+ nós em espera / espelho) geralmente é bastante direta com RAM, SSDs, mais volumes de disco para espalhar IO, unidades separadas para tempdb e logs etc.

Além disso, se você achar que o SQL Server está vinculado à CPU, geralmente é um design e / ou índices ruins e / ou consultas mal escritas, a menos que você tenha uma carga enorme.

Como o gbn diz, o SQL realmente não se expande como outros RDBMs. No entanto, há um aspecto da expansão que muitas pessoas ignoram e é sempre ter um sistema separado para fins de geração de relatórios.

Nunca permita que os relatórios sejam executados na produção. Crie um banco de dados de relatórios em outro servidor.

Idealmente, seu sistema de relatórios conteria apenas os dados necessários e seria estruturado e otimizado de maneira diferente do seu sistema de produção.

Os dados seriam inseridos no sistema de relatórios conforme necessário (ou seja, uma atualização de hora em hora da produção, alimentação diária, etc.).

Uma abordagem rápida e suja (e altamente ineficiente) é simplesmente ter uma cópia completa do banco de dados de produção em outro servidor. Essa cópia pode ser mantida por meio de backups completos, envio do log de transações, espelhamento (com instantâneo), replicação etc.

Eu não recomendo esta abordagem no entanto. Os backups completos e restaurados levam tempo, especialmente em bancos de dados maiores. A replicação é complicada e problemática. O envio de logs deixa você com um banco de dados somente leitura. O espelhamento com snapshots pode ser uma boa resposta, mas você ainda está preso a um esquema de produção que não é otimizado para fins de relatório.

Um sistema de relatório separado é o caminho a percorrer.

Se a CPU estiver ligada, posso ver claramente passando de 1 núcleo da CPU para 2 a 4. Ou se o uso da RAM aumentar, basta adicionar mais RAM. O SQL Server 2008/2012 realmente pega a folga e aumenta a escala dessa maneira, assumindo que NÃO há alterações no nível do aplicativo?

As diferentes edições do SQL Server têm limitações diferentes em termos de CPU e memória que eles vão usar. Mas, além disso, a resposta é sim - se houver ciclos de CPU vagos ou páginas de memória disponíveis, o servidor normalmente os usará quando necessário, a menos que configurado de outra forma.

Ou tenho que compartilhar os dados e ter um código personalizado que chama o servidor de banco de dados correto

Basicamente sim. O "dimensionamento externo" geralmente é feito quando você precisa evitar a contenção de bloqueio. Se você tiver consultas de longa execução com bloqueio extensivo, convém separá-las das consultas interativas "em tempo real" ou dos ciclos de atualização de consultas iniciados por usuários que operam algum tipo de interface e aguardam resposta imediata. Obviamente, cuidar disso exigiria alterações no aplicativo (ou pelo menos no middleware, se você tiver um design de três camadas).