Share via

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

  • Artigo

APLICA-SE A:yes-img-132013 yes-img-16 2016yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint no Microsoft 365

Ao configurar e manter bancos de dados relacionais do SharePoint Server 2016 e 2019 no SQL Server 2014 com o Service Pack 1 (SP1), SQL Server 2016 ou SQL Server RTM 2017, você precisa escolher opções que promovam desempenho e segurança. Da mesma forma, você tem que escolher opções de promovem a segurança e desempenho ao configurar e manter bancos de dados relacionais do SharePoint Server 2013 no SQL Server 2008 R2 com Service Pack 1 (SP1), no SQL Server 2012 e no SQL Server 2014.

As práticas recomendadas neste artigo estão ordenadas com na sequência na qual devem ser aplicadas, desde a instalação e configuração do SQL Server até a implantação do SharePoint Server e manutenção do farm. A maior parte das práticas se aplica a todas as versões do SQL Server. As práticas que são exclusivas de cada versão do SQL Server são mostradas em seções separadas.

Observação

[!OBSERVAçãO] Se você planeja usar componentes de Business Intelligence do SQL Server em um farm do SharePoint Server 2016, deve usar o SQL Server 2016 CTP 3.1 ou posterior. Agora você pode baixar o SQL Server 2016 CTP 3.1 ou posterior para usar o suplemento SQL Server Power Pivot para SharePoint. Você também pode usar o Power View instalando o SQL Server Reporting Services (SSRS) no modo integrado do SharePoint, e o suplemento SSRS front-end da mídia de instalação do SQL Server.

Para saber mais, baixe o novo white paper Como implantar o SQL Server 2016 PowerPivot e Power View no SharePoint 2016. Para mais detalhes sobre como configurar e implantar o business intelligence em um farm do SharePoint Server 2016 com vários servidores, baixe Como implantar o SQL Server 2016 PowerPivot e o Power View em um Farm do SharePoint 2016 de Várias Camadas.

Observação

[!OBSERVAçãO] Se você planeja usar componentes de Business Intelligence do SQL Server em um farm do SharePoint Server 2013, você deve usar o SQL Server 2012 com Service Pack 1 (SP1) ou o SQL Server 2014. Para saber mais sobre o BI do SQL Server 2012 com SP1 e o SharePoint Server 2013, veja Instalar os Recursos do SQL Server BI com o SharePoint 2013 (SQL Server 2012 SP1). Para saber mais sobre o SQL Server 2014 e o SharePoint Server 2013, veja Instalar os Recursos do Business Intelligence do SQL Server 2014.

Importante

As práticas recomendadas neste artigo se aplicam ao Sistema de Gerenciamento de Banco de Dados (Relational Database Management System - RDBMS) do SQL Server com o SharePoint Server.

Uso de um servidor dedicado para o SQL Server

Para garantir o desempenho ideal para operações de farm, recomendamos que você instale o SQL Server em um servidor dedicado que não execute outras funções de farm e não hospede bancos de dados para outros aplicativos. A única exceção é a implantação do SharePoint Server 2016 ou 2019 em uma função farm Single-Server ou do SharePoint 2013 em um servidor autônomo, que é destinado ao desenvolvimento ou teste, e não é recomendado para uso de produção. Para obter mais informações, confira Descrição do MinRole e dos serviços associados no SharePoint Servers 2016 e 2019 e Instalar o SharePoint Servers 2016 ou 2019 em um servidor.

Observação

A recomendação para usar um servidor dedicado para bancos de dados relacionais também se aplica à implantação do SQL Server em ambientes virtuais.

Configuração das definições específicas do SQL Server antes de implantar o SharePoint Server

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

  • Devido a possíveis problemas de desempenho com a manutenção de várias instâncias sql, recomendamos que você use uma única instância de SQL Server por servidor de banco de dados implantado.

  • Não permitem a criação automática de estatísticas de bancos de dados de conteúdo do SharePoint. A habilitação da criação automática de estatísticas não tem suporte do SharePoint Server. O SharePoint Server configura as definições necessárias durante o provisionamento e a atualização. Habilitar manualmente as estatísticas de criação automática em um banco de dados do SharePoint pode alterar significativamente o plano de execução de uma consulta. Os bancos de dados do SharePoint usam um procedimento armazenado que mantém as estatísticas (proc_UpdateStatistics) ou depende do SQL Server para fazer isso.

  • Para o SharePoint Server 2013, os planos de manutenção são gerenciados pelo SharePoint:

    • As estatísticas sql são gerenciadas pela regra de integridade "Bancos de dados usados pelo SharePoint têm estatísticas de índice desatualizadas" que chama proc_updatestatics
    • Bancos de dados de conteúdo têm a propriedade Estatísticas de Atualização Automática definida como False

  • Para o SharePoint Servers 2016 e 2019, o administrador do SQL deve criar planos de manutenção para bancos de dados de conteúdo do SharePoint:

    • As estatísticas de SQL não são gerenciadas pela regra de integridade "Bancos de dados usados pelo SharePoint têm estatísticas de índice desatualizadas"
    • Bancos de dados de conteúdo têm a propriedade Estatísticas de Atualização Automática definida como True `

  • Defina o grau máximo de paralelismo (MAXDOP) para 1 para as instâncias doSQL Server que hospedam os bancos de dados do SharePoint para verificar se um único processo do SQL Server serve a cada solicitação.

    Importante

    Definir o grau máximo de paralelismo para qualquer outro número pode fazer com que seja usado um plano de consulta inferior ao ideal, que degradará o desempenho do SharePoint Server.

  • Para ajudar a simplificar a manutenção, por exemplo, facilitar a migração de bancos de dados para outro servidor, crie aliases de DNS que apontem para o endereço IP de todas as instâncias do SQL Server. Para saber mais sobre aliases de DNS ou nome do host, confira o artigo Como adicionar um alias de nome do host a uma instância do SQL Server.

Para obter mais informações sobre essas configurações e opções do SQL Server, consulte Definir opções do SQL Server.

Proteção do servidor de banco de dados antes da implantação do SharePoint Server

Recomendamos que você planeje e proteja os servidores de banco de dados antes de implantar o SharePoint Server. Para obter mais informações, consulte:

Configuração de servidores de banco de dados para desempenho e disponibilidade

Como acontece com servidores front-end e servidores de aplicativo, a configuração para servidores de banco de dados o desempenho do SharePoint Server. Alguns bancos de dados têm que estar no mesmo servidor que outros bancos de dados. Por outro lado, alguns bancos de dados não podem estar no mesmo servidor que outros bancos de dados. Para obter mais informações, consulte Descrição do MinRole e serviços associados no SharePoint Servers 2016 e 2019 e Armazenamento e SQL Server planejamento e configuração de capacidade (SharePoint Server).

Para obter diretrizes sobre bancos de dados altamente disponíveis que usam espelhamento, confira Espelhamento de banco de dados (SQL Server).

Cluster de Failover do SQL Server e Grupos de Disponibilidade AlwaysOn

SQL Server 2012 introduziu o recurso Grupos de Disponibilidade Always On. Esse recurso é uma solução de alta disponibilidade e recuperação de desastres que é uma alternativa a soluções de envio de log e espelhamento de banco de dados. Always On Grupos de Disponibilidade agora dão suporte a até nove réplicas de disponibilidade.

Observação

[!OBSERVAçãO] O espelhamento de banco de dados será depreciado em versões futuras do SQL Server. É recomendável usar Grupos de Disponibilidade AlwaysOn.

Always On Grupos de Disponibilidade exigem um cluster WSFC (Clustering de Failover) do Windows Server. Um grupo de recursos de WSFC é criado para todos os grupos de disponibilidade criados. Para obter mais informações, consulte os seguintes recursos:

Projeto de armazenamento para obter a taxa de transferência e a capacidade de gerenciamento ideais

Recomendamos que você se separe e priorize seus dados entre as unidades no servidor de banco de dados. Idealmente, você deve colocar o banco de dados tempdb, bancos de dados de conteúdo, banco de dados de uso, bancos de dados de pesquisa e logs de transações em discos rígidos físicos separados. A lista a seguir fornece algumas diretrizes. Para obter mais informações, consulte Configurar bancos de dados.

  • Para sites de colaboração ou com atualização intensa, use a seguinte classificação para distribuição de armazenamento.

    O item com a classificação mais alta deve estar nas unidades mais rápidas.

    Rank Item
    1 arquivos de dados tempdb e logs de transações
    2 Arquivos de log de transações do banco de dados de conteúdo
    3 Bancos de dados de pesquisa, exceto pelo banco de dados de administração de Pesquisar
    4 Arquivos de dados do banco de dados de conteúdo

  • Em um site de portal altamente orientado à leitura, priorize os dados e as pesquisas nos logs de transação como a seguir.

    O item com a classificação mais alta deve estar nas unidades mais rápidas.

    Rank Item
    1 arquivos de dados tempdb e logs de transações
    2 Arquivos de dados do banco de dados de conteúdo
    3 Bancos de dados de pesquisa, exceto pelo banco de dados de administração de Pesquisar
    4 Arquivos de log de transações do banco de dados de conteúdo

  • Os dados de teste e de usuário mostram que a E/S de disco insuficiente para o tempdb pode impedir significativamente o desempenho geral do farm. Para evitar este problema, aloque discos dedicados para a unidade que armazena arquivos de dados tempdb.

  • Para obter o melhor desempenho, use uma matriz RAID 10 para a unidade que armazena arquivos de dados do tempdb. O número de arquivos de dados do tempdb deve ser igual ao número de núcleos da CPU, e cada arquivo de dado do tempdb deve ser definido com o mesmo tamanho.

  • Separe dados de banco de dados e arquivos de registro de transação em discos diferentes. Caso os dados e arquivos de log precisem compartilhar discos devido a limitações de espaço, coloque os arquivos que têm padrões diferentes de uso no mesmo disco para minimizar solicitações de acesso concorrentes.

  • Use vários arquivos de dados para bancos de dados de uso intenso e coloque cada um deles em seu próprio disco

  • Para aprimorar a capacidade de gerenciamento, monitore e faça ajustes conforme necessário para manter os bancos de dados de conteúdo abaixo de 200 GB em vez de restringir o tamanho do banco de dados.

    Observação

    Se você restringir o tamanho do banco de dados no SQL Server, poderá causar um tempo de inatividade quando a capacidade for excedida.

A configuração correta dos subsistemas de E/S é muito importante para o desempenho e a operação de sistemas SQL Server. Para saber mais, confira Monitoramento do uso do disco

Dica

Pense que a forma como você mede a velocidade do disco varia entre os arquivos de dados e os arquivos de log. Talvez as unidades mais distantes para os dados dos banco de dados não sejam as mais distantes para os arquivos de log. Considere padrões de uso, E/S e tamanho do arquivo.

Gerenciamento proativo do aumento de arquivos de dados e de log

A seguir, são apresentadas recomendações para gerenciar proativamente o aumento de arquivos de dados e de log:

  • Sempre que possível, aumente todos os arquivos de dados e arquivos de log para o tamanho final esperado ou periodicamente nos períodos definidos, por exemplo, mensalmente ou semestralmente, ou antes da implementação de um site de armazenamento intenso, como durante as migrações de arquivo.

  • Habilite o aumento automático como uma medida de proteção para garantir que você não fique sem espaço para dados ou arquivos de log. Considere o seguinte:

    Importante

    [!IMPORTANTE] Você deve levar em consideração as operações e os problemas de desempenho associados ao uso do aumento automático. Para saber mais, confira Considerações sobre as configurações "autogrow" e "autoshrink" no SQL Server.

    • As configurações padrão para um novo banco de dados são para aumento em incrementos de 1 MB. Como essa configuração padrão de aumento automático resulta em aumentos no tamanho do banco de dados, não confie na configuração padrão. Em vez disso, use as orientações fornecidas em Configuração das opções do SQL Server.

    • Defina os valores de aumento automático para um número fixo de megabytes em vez de um percentual. Quanto maior o banco de dados, maior deve ser o incremento do aumento.

      Observação

      Tenha cuidado ao configurar o recurso de aumento automático para os bancos de dados do SharePoint. Se o banco de dados for configurado com um aumento automático em percentual, por exemplo, à taxa de aumento de 10%, um banco de dados com 5 GB aumenta 500 MB toda a vez que o arquivo de dados for expandido. Nesse cenário, você pode ficar sem espaço em disco.

      Considere, por exemplo, um cenário cujo conteúdo é aumentado gradualmente, digamos, a incrementos de 100 MB e o aumento automático é definido a 10 MB. De repente, um novo site de gerenciamento de documentos necessita de uma grande quantidade de armazenamento de dados, talvez com tamanho inicial de 50 GB. Para essa adição grande, o aumento a incrementos de 500 MB é mais apropriado do que incrementos de 10 MB.

    • Para um sistema de produção gerenciado, considere o crescimento automático apenas uma contingência para um crescimento inesperado. Não use a opção de crescimento automático para gerenciar os dados e o crescimento do log no dia-a-dia. Em vez disso, defina o crescimento automático para permitir um tamanho aproximado em um ano e adicione uma margem de 20% de erro. Defina também um alerta para notificá-lo quando o banco de dados for executado com pouco espaço ou se aproximar de um tamanho máximo.

  • Mantenha um nível mínimo de espaço disponível de, pelo menos, 25% em todas as unidades para acomodar os padrões de aumento e de pico de uso. Se você adicionar unidades a uma matriz RAID ou alocar mais armazenamento a ser gerenciado, monitore cuidadosamente a capacidade para evitar ficar sem espaço.

Monitoramento contínuo do armazenamento e desempenho do SQL Server

Recomendamos que você monitore continuamente o armazenamento e desempenho SQL Server para verificar se cada servidor de banco de dados manipula adequadamente a carga recebida. Além disso, a monitoração contínua permite que você estabeleça parâmetros de comparação a serem usados para planejamento de recursos.

Tenha uma visualização abrangente da monitoração de recursos. Não limite a monitoração de recursos que são específicas para o SQL Server. É igualmente importante acompanhar os seguintes recursos nos computadores que estão executando o SQL Server: CPU, memória, cache/taxa de acerto e o subsistema de E/S.

Quando um ou mais recursos de servidor parecem lentos ou sobrecarregados, considere as seguintes orientações de desempenho com base na carga de trabalho atual e projetada.

Uso da compactação de backup para acelerar backups e reduzir os tamanhos de arquivo

A compactação de backup pode acelerar as operações de backup do SharePoint. Ela está disponível no SQL Server Standard e Enterprise Edition. Se você definir a opção de compactação no script de backup ou configurar o SQL Server para compactar por padrão, poderá reduzir significativamente o tamanho dos backups de banco de dados e logs fornecidos. Para saber mais, veja Compactação de backup (SQL Server) e Compactação de dados ou Habilitar a compactação em uma tabela ou índice

Reconhecimento

A equipe de publicação de conteúdo do SharePoint Server agradece os seguintes colaboradores para deste artigo:

  • Kay Unkroth, Gerente de Programas Sênior, SQL Server

  • Chuck Heinzelman, Gerente de Programas Sênior, SQL Server

Confira também

Conceitos

Visão geral do SQL Server em ambientes do SharePoint Server 2016 e 2019

Configuração e planejamento da capacidade de armazenamento do SQL Server (SharePoint Server)

Outros recursos

Proteção do SharePoint: proteger o SQL Server em ambientes do SharePoint