Como alguém dimensiona o SQL Server 2008 (ou 2012)? Basicamente, entendo que há duas opções:
Aumentar escala:
Se a CPU for limitada, posso ver claramente passando de 1 núcleo de CPU para 2 a 4. Ou se o uso de RAM disparar, apenas adicionando mais RAM. O SQL Server 2008/2012 realmente pega a folga e aumenta dessa maneira, assumindo que NÃO há alterações no nível do aplicativo? Para minimizar a especulação, vamos supor que não estou fazendo algo estúpido como gravar ciclos de CPU, fazer junções cruzadas, etc.
Dimensionar:
Não está muito claro como a expansão funcionaria. Quero dizer, se eu adicionar outro servidor SQL ao lado do meu primeiro, como a consulta saberá em qual servidor executar? Existe algum balanceador de carga na frente (e ele vem com o software SQL Server?)? Isso envolve alterações no nível do aplicativo para expandir para o trabalho? Ou preciso fragmentar os dados e ter um código personalizado que chame o servidor de banco de dados correto, dependendo da chave de fragmentação de dados?
Agradeceria a opinião de pessoas mais experientes.
SQL Server não escala como tal . Ele aumenta a escala.
Existem 3 áreas para fazer isso, sujeitas a limitações de edição
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 a um sistema.
A expansão de um servidor (+ nós/espelho em espera) geralmente é bastante direta com RAM, SSDs, mais volumes de disco para distribuir 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 massiva.
Como o gbn diz, o SQL realmente não se expande como os outros RDBMs. No entanto, há um aspecto da expansão que muitas pessoas ignoram e que é sempre ter um sistema separado para fins de relatório.
Nunca permita que os relatórios sejam executados contra a produção. Construa você mesmo um banco de dados de relatórios em outro servidor.
Idealmente, seu sistema de relatório conteria apenas os dados de que os relatórios precisam e seria estruturado e otimizado de forma diferente do seu sistema de produção.
Os dados seriam alimentados 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 de log de transações, espelhamento (com instantâneo), replicação, etc.
Eu não recomendo esta abordagem no entanto. Backups completos e restaurados levam tempo, principalmente 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 instantâneos 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órios separado é o caminho a percorrer.
As diferentes edições do SQL Server têm diferentes limitações em termos de CPU e memória que vão usar. Mas, além disso, a resposta é sim - se ciclos de CPU ou páginas de memória livres estiverem disponíveis, o servidor normalmente os usará quando necessário, a menos que configurado de outra forma.
Basicamente, sim. A "dimensão horizontal" geralmente é feita quando você precisa evitar a contenção de bloqueio. Se você tiver consultas de execução longa com bloqueio extensivo, convém separá-las de consultas interativas em "tempo real" ou ciclos de atualização de consulta 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 alterações no middleware, se você tiver um design de 3 camadas).