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.
fonte
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.
fonte
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.
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).
fonte