Práticas recomendadas para SQL Server 2008 em um farm do SharePoint Server 2010

Artigo
03/07/2017

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo descreve as práticas recomendadas para configurar e manter o Microsoft SQL Server 2008 em um ambiente do Microsoft SharePoint Server 2010. Essas práticas são ordenadas com base na sequência na qual devem ser aplicadas, da instalação e configuração do SQL Server 2008 para a implantação do SharePoint Server e a manutenção do farm.

Este artigo faz parte de uma série de artigos de Práticas Recomendadas para o SharePoint Server. Para obter mais artigos da série, consulte Práticas recomendadas (SharePoint Server 2010). Para obter informações adicionais e recursos sobre as Práticas Recomendadas para o SharePoint Server 2010, consulte a Central de Recursos de Práticas Recomendadas (https://go.microsoft.com/fwlink/?linkid=220280&clcid=0x416).

1. Use um servidor dedicado para o SQL Server 2008

Para garantir o desempenho ideal para as operações do farm, recomendamos que você instale o SQL Server 2008 em um servidor dedicado que não está executando nenhuma outra função de farm e não está hospedando bancos de dados para nenhum outro aplicativo. A única exceção é quando você está implantando o SharePoint Server 2010 em um servidor autônomo, o que não é recomendado para ambientes de produção de larga escala.

Observação

A recomendação para usar um servidor dedicado para o banco de dados também se aplica a qualquer ambiente no qual o SQL Server 2008 está virtualizado.

2. Defina as configurações específicas do SQL Server 2008 antes de implantar o SharePoint Server 2010

Para garantir comportamento e desempenho consistentes, defina as opções e configurações a seguir antes de implantar o SharePoint Server 2010.

Não habilite a criação automática de estatísticas em um SQL Server que oferece suporte ao SharePoint Server.
Defina o grau máximo de paralelismo (MAXDOP) como 1 para as instâncias do SQL Server que hospedam os bancos de dados do SharePoint Server 2010 para garantir que todas as solicitações sejam atendidas por um único processo do SQL Server.

Importante

Em um ambiente do SharePoint Server, qualquer outra configuração resultará na seleção de um plano de consulta abaixo do ideal para execução, o que diminuirá o desempenho geral.
Para facilitar a manutenção e a realocação do banco de dados caso seja necessário futuramente, configure os aliases de conexão do SQL Server para cada servidor de banco de dados em seu farm.

Para obter mais informações, consulte Definir as opções do SQL Server.

3. Proteja o servidor de banco de dados antes de implantar o SharePoint Server 2010

Recomendamos que você planeje e proteja o servidor de banco de dados antes de implantar o SharePoint Server 2010. Isso inclui proteger a função de servidor de banco de dados do SharePoint Server e do SQL Server. Para obter mais informações, consulte:

4. Configure os servidores de banco de dados para melhor desempenho e disponibilidade

Como nos servidores Web e servidores de aplicativos, a configuração dos servidores de banco de dados afeta a qualidade das execuções do SharePoint Server 2010. Determinados bancos de dados exigem a colocalização ou a separação de outros bancos de dados. Para obter mais informações, consulte:

Para bancos de dados altamente disponíveis que usam o espelhamento, consulte as diretrizes de práticas recomendadas em Práticas recomendadas para espelhamento de banco de dados e considerações sobre o desempenho (https://go.microsoft.com/fwlink/?linkid=185119&clcid=0x416).

5. Projete o armazenamento para obter taxas de transferência e capacidade de gerenciamento ideais

Recomendo que você separe e priorize os dados nos discos do servidor de banco de dados. De modo ideal, você deve colocar o banco de dados tempdb, os bancos de dados de conteúdo, o banco de dados de uso, os bancos de dados de pesquisa e os logs de transações do SQL Server 2008 em discos rígidos separados. A lista a seguir fornece algumas práticas recomendadas e recomendações para priorizar e gerenciar os dados e logs. Para obter mais informações, consulte Configurar bancos de dados.

Para sites de colaboração ou com muitas atualizações, use a seguinte classificação para distribuição do armazenamento:
1. arquivos de dados do tempdb e logs de transação nos discos mais rápidos
2. Arquivos de log de transações de banco de dados de conteúdo
3. Bancos de dados de pesquisa, com exceção do banco de dados de administração de Pesquisa
4. Arquivos de dados de banco de dados de conteúdo
Em um site de portal altamente orientado para leitura, priorize os dados e pesquise nos logs de transação da seguinte maneira:
1. arquivos de dados do tempdb e logs de transação nos discos mais rápidos
2. Arquivos de dados de banco de dados de conteúdo
3. Bancos de dados de pesquisa, com exceção do banco de dados de administração de Pesquisa
4. Arquivos de log de transações de banco de dados de conteúdo
Testes e dados de usuários mostram que o desempenho geral de farms pode ser muito prejudicado por E/S insuficiente de disco para o tempdb. Para evitar esse problema, aloque discos dedicados para o tempdb.
Para melhorar o desempenho, coloque o tempdb em uma matriz RAID 10. O número de arquivos de dados do tempdb deve ser igual ao número de núcleos CPUs e os arquivos de dados do tempdb devem ser definidos com um tamanho igual.
Separe dados de banco de dados e arquivos de log de transações em diferentes discos. Se os arquivos precisarem compartilhar discos porque os arquivos são muito pequenos para justificar o uso de um disco inteiro ou de uma faixa inteira, ou se faltar espaço em disco, coloque os arquivos que têm padrões de uso diferentes no mesmo disco para minimizar solicitações de acesso simultâneo.
Use vários arquivos de dados para bancos de dados de conteúdo muito usados, cada um em seu próprio disco
Para melhorar a capacidade de gerenciamento, limite o tamanho do banco de dados de conteúdo para 50 GB

A configuração correta dos subsistemas de E/S é muito importante para obter o desempenho e a operação ideais dos sistemas SQL Server. Para obter mais informações, consulte Storage Top 10 Best Practices

6. Gerencie de modo proativo o crescimento dos arquivos de dados e log

Recomendamos gerenciar de maneira proativa o crescimento dos arquivos de dados e log, considerando as seguintes recomendações:

Quando possível, expanda previamente todos os arquivos de dados e arquivos de log para seu tamanho final esperado ou aumente-os periodicamente em intervalos definidos, por exemplo, a cada mês ou a cada seis meses, ou antes da distribuição de um novo site com armazenamento intenso durante as migrações de arquivos.
Recomendamos que você habilite o crescimento automático de banco de dados como uma medida protetora para garantir que você não fique sem espaço para os dados e arquivos de log. Considere o seguinte:

Importante

Você deve considerar os problemas de desempenho e de operação associados com o uso do crescimento automático. Para obter mais informações, consulte Considerações sobre as configurações "autogrow" e "autoshrink" no SQL Server (https://go.microsoft.com/fwlink/?linkid=117750&clcid=0x416).
- Não confie nas configurações padrão para crescimento automático, use as diretrizes fornecidas em Definir opções do SQL Server.
- Defina os valores de crescimento automático como um percentual, em vez de um número fixo de megabytes. Quanto maior o banco de dados, maior deve ser o incremento de crescimento.
  
  Por exemplo, considere um cenário onde o conteúdo é aumentado gradualmente, em incrementos de 100MB, com o crescimento automático definido em 10MB. Em seguida, uma grande quantidade de armazenamento de dados é necessária para um novo site de gerenciamento de documentos, com tamanho inicial de 50 GB. Desejaríamos o crescimento em incrementos de 500 MB e não em increments de 10MB.
- Para um sistema de produção gerenciado, você deve considerar o crescimento automático como uma contigência para o crescimento inesperado. Não gerencie o crescimento de seus dados e log diariamente usando a opção de crescimento automático.
Mantenha um nível de pelo menos 25 por cento de espaço disponível nos discos para estabelecer padrões de crescimento e uso máximo. Se você estiver gerenciando o crescimento por meio da inclusão de discos em uma matriz RAID ou da alocação de mais armazenamento, monitore o tamanho do disco cuidadosamente para evitar ficar sem espaço.

7. Monitore continuamente o armazenamento e o desempenho do SQL Server

Recomendamos que você monitore continuamente o armazenamento e o desempenho do SQL Server para garantir que o servidor de banco de dados de produção esteja manipulando adequadamente a carga recebida. Além disso, o monitoramento contínuo permite que você estabeleça benchmarks que podem ser usados no planejamento de recursos.

Tenha uma visão holística do monitoramento de recursos; não limite o monitoramento aos recursos específicos ao SQL Server. É igualmente importante controlar os seguintes componentes de recursos de um servidor que está executando o SQL Server: CPU, memória, taxa de acertos do cache e subsistema de E/S.

Quando um ou mais dos componentes parecerem lentos ou sobrecarregados, analise a estratégia apropriada com base na carga de trabalho atual e projetada. Para obter mais informações, consulte:

8. Use a compactação de backup para acelerar os backups e reduzir os tamanhos de arquivo

A compactação de backup pode agilizar qualquer backup do SharePoint e está disponível no SQL Server 2008 Enterprise Edition ou no SQL Server 2008 R2 Standard Edition. Ao configurar a opção de compactação em seu script de backup ou ao configurar o servidor que está executando o SQL Server para compactar por padrão, você pode reduzir significativamente o tamanho do seus backups de bancos de dados e logs remetidos. Para obter mais informações, consulte Compactação de backup (SQL Server) (https://go.microsoft.com/fwlink/?linkid=129381&clcid=0x416) e Compactação de dados: estratégia, planejamento de capacidade e práticas recomendadas (https://go.microsoft.com/fwlink/?linkid=223674&clcid=0x416).

Agradecimentos

A equipe de Publicação de Conteúdo do SharePoint Server 2010 agradece aos seguintes contribuidores deste artigo:

Stephen Dillon, consultor sênior
Gus Apostal, gerente de programa sênior, SQL Server

Compartilhar via