Compartilhar via

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

  • Artigo

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

Quando configura e mantém bases de dados relacionais do SharePoint Server 2016 e 2019 no SQL Server 2014 com o Service Pack 1 (SP1), o SQL Server 2016 ou o SQL Server 2017 RTM, tem de escolher opções que promovam o desempenho e a 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 implementação do SharePoint Server 2016 ou 2019 numa função de farm de Single-Server ou do SharePoint 2013 num servidor autónomo, destinado ao desenvolvimento ou teste, e não é recomendado para utilização em produção. Para obter mais informações, consulte Descrição do MinRole e dos serviços associados no SharePoint Servers 2016 e 2019 e Instalar o SharePoint Servers 2016 ou 2019 num único 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 potenciais problemas de desempenho com a manutenção de várias instâncias do SQL, recomendamos que utilize uma única instância do SQL Server por servidor de base de dados implementado.

  • 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 geridos pelo SharePoint:

    • As estatísticas do SQL são geridas pela regra de estado de funcionamento "As bases de dados utilizadas pelo SharePoint têm estatísticas de índice desatualizadas" que chama proc_updatestatics
    • As bases de dados de conteúdo têm a propriedade Estatísticas de Atualização Automática definida como Falso

  • Para o SharePoint Servers 2016 e 2019, o administrador do SQL tem de criar Planos de Manutenção para bases de dados de conteúdos do SharePoint:

    • As estatísticas do SQL não são geridas pela regra de estado de funcionamento "As bases de dados utilizadas pelo SharePoint têm estatísticas de índice desatualizadas"
    • As bases de dados de conteúdo têm a propriedade Estatísticas de Atualização Automática definida como Verdadeiro `

  • 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, veja Descrição do MinRole e dos serviços associados no SharePoint Servers 2016 e 2019 e Armazenamento e planeamento e configuração de capacidade do SQL Server (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

O SQL Server 2012 introduziu a funcionalidade Grupos de Disponibilidade AlwaysOn. 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. Os Grupos de Disponibilidade AlwaysOn suportam agora 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.

Os Grupos de Disponibilidade AlwaysOn requerem um cluster de Clustering de Ativação Pós-falha do Windows Server (WSFC). 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 se separe e dê prioridade aos seus dados entre as unidades no servidor da base de dados. Idealmente, deve colocar a base de dados tempdb, bases de dados de conteúdo, base de dados de utilização, bases de dados de pesquisa e registos de transações em discos rígidos físicos separados. A lista seguinte fornece algumas orientações. Para obter mais informações, veja Configurar bases 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 ficheiros de dados tempdb e registos de transações
    2 Ficheiros de registo de transações da base de dados de conteúdos
    3 Bancos de dados de pesquisa, exceto pelo banco de dados de administração de Pesquisar
    4 Ficheiros de dados da base de dados de conteúdos

  • 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 ficheiros de dados tempdb e registos de transações
    2 Ficheiros de dados da base de dados de conteúdos
    3 Bancos de dados de pesquisa, exceto pelo banco de dados de administração de Pesquisar
    4 Ficheiros de registo de transações da base de dados de conteúdos

  • 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 gerido, considere o aumento automático como mera contingência para um crescimento inesperado. Não utilize a opção de aumento automático para gerir os seus dados e registar o crescimento diariamente. Em vez disso, defina o aumento automático para permitir um tamanho aproximado num ano e, em seguida, adicione uma margem de erro de 20%. Defina também um alerta para notificá-lo quando a base de dados tiver 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