O que devo fazer para dimensionar um banco de dados Sql2008?

Question

Estou prestes a ampliar o nosso banco de dados sql2008. Simples. Mas eu talvez precise escalar os nossos bancos de dados sql.

Para uma situação de escala simples (ou seja, distribuir a carga de processamento), existem algumas boas práticas iniciais recomendadas? Eu sei que há tantas soluções que serão específicas do produto - > muitos escreve & não muitas leituras, muitas leem & não muitos escrevem, um pouco de ambos, etc. etc ..

Mas para um site que é bastante lido (em vez de escrever pesado), existe um ponto de partida comum? por exemplo. pegue uma segunda caixa sql, adicione alguma coisa de sincronização e vá embora.

    

Answer 1

Até que ponto os dados das outras caixas precisam ser atualizados?

O MSSQL tem uma ótima configuração de relacionamento de sincronização unidirecional. Você tem que estar licenciado para versões apropriadas do SQL Server (eu não acho que esteja incluído no mais básico), mas é excepcionalmente fácil de configurar.

O único problema é que você só pode gravar em um local, todos os outros locais precisam ser somente leitura. Para sincronização bidirecional (se você for escrever) é muito mais complexo.

Então, em suma, uma segunda caixa com uma coisa de sincronização funcionará muito bem, mas você também precisará fazer seu próprio balanceamento de carga (ou seja, ter um servidor da web lendo um servidor sql, outro servidor da web ler o outro sql servidor), como eles ainda aparecem como instâncias separadas. Caso contrário, você está em clustering que é outra chaleira de peixe.

Então, essa coisa de sincronização - o que é e como você configura? Bem, no seu SQL Management Studio (SSMS) você verá uma pasta para "Replication" no painel de navegação, com publicações e assinaturas.

Em poucas palavras, você irá:

• Publicar um banco de dados no servidor de banco de dados principal
• Inscrever-se em uma publicação nos servidores secundários, somente leitura
• Os assinantes serão sincronizados em um agendamento (isso pode ser constante para replicação quase instantânea)

Há muitos artigos, portanto, basta procurar no Google SQL Server Replication.

No que diz respeito ao hardware, nosso servidor db primário é um Dual-Quad-Core com 4GB de RAM. Nossos escravos são Dual-Core com 4gb de ram. Você pode comprar muitos servidores nesse nível. Claro, tudo depende do tipo de carga que você espera.

    

Answer 2

a questão é mais complexa que alguns posts podem responder. Há muitas opções para dimensionar seus servidores, apenas para citar alguns: cluster de failover, envio de log, replicação, espelhamento de banco de dados.

Eu recomendaria um livro maravilhoso que pode ser baixado aqui: Pro SQL Server 2005 Alta disponibilidade

Espero que você encontre respostas para suas perguntas

    

Answer 3

Hoje em dia, o hardware é muito poderoso e barato, então você pode percorrer um longo caminho usando apenas um servidor decente. Se, como você diz, seu banco de dados é principalmente para leitura, então um Poweredge 2950 com 16GB de RAM e seis discos de 15K RAID5 (ou 6) é uma base muito poderosa para um SQL Server; adicione quantos núcleos quiser, mas mesmo os núcleos quádruplos não são tão caros. Eu acho que o 2950 vai levar até 64GB de RAM, embora isso seja caro !

Seu hardware já pode ser tão poderoso. Se assim for você está olhando para uma mudança de poder e custo, e se assim for, eu acho que você precisa de um conselho melhor do que apenas alguns posts no ServerFault: -)

JR

    

Answer 4

bem, é difícil responder à pergunta nesse sentido, que você (devs) teve que pensar sobre esse problema ao projetar o banco de dados. Mas dê uma olhada nos bancos de dados compartilhados para uma alta taxa de leitura / gravação, o que pode ser mais fácil de implementar. Outra solução pode ser replicação.

aproveite, m