Configuração e planejamento da capacidade de armazenamento do SQL Server (SharePoint Server)
APLICA-SE A:2013 2016 2019 Subscription Edition SharePoint no Microsoft 365
As informações de planejamento de capacidade que fornecemos contêm diretrizes para ajudar você a planejar e a configurar a camada de armazenamento e de banco de dados do SQL Server em um ambiente do SharePoint Server. Essas informações se baseiam em testes realizados na Microsoft em propriedades em tempo real. Entretanto, seus resultados podem variar com base no equipamento usado e nos recursos e na funcionalidade implementada para seus sites.
Saiba mais sobre o Gerenciamento de limites de armazenamento de site para o SharePoint no Microsoft 365.
Embora os testes não tenham sido executados no SQL Server 2014 (SP1), o SQL Server 2016, o SQL Server 2017 RTM ou o SQL Server 2019, pode utilizar estes resultados de teste como um guia para o ajudar a planear e configurar o armazenamento e a camada de base de dados do SQL Server em ambientes sharePoint Server Subscription Edition, 2019 ou 2016. Para treinamento sobre como configurar e ajustar o SQL Server 2012, consulte SQL Server 2012 para SharePoint Server 2013. Os resultados do teste são os mesmos que no SharePoint 2013.
Este documento destina-se à utilização conjunta dos implementadores de farm do SharePoint Server e dos administradores de bases de dados do SQL Server, uma vez que o SharePoint Server é frequentemente executado em ambientes em que as bases de dados são geridas por administradores de bases de dados do SQL Server separados. Ele supõe um entendimento significativo do SharePoint Server e do SQL Server.
Este artigo supõe que você esteja familiarizado com os conceitos apresentados em Capacity management and sizing for SharePoint Server 2013.
Processo de configuração e design da camada de banco de dados e armazenamento para o SharePoint Server 2016 e mais recente
Recomendamos a divisão do processo de design de camada de armazenamento e de banco de dados nas etapas a seguir. Essas seções fornecem informações detalhadas sobre cada etapa de design, incluindo requisitos e práticas recomendadas de armazenamento:
Obter armazenamento e requisitos de espaço e de E/S do SQL Server
Projetar a arquitetura de armazenamento baseada em requisitos de capacidade e de E/S
Validar e monitorizar o armazenamento e o desempenho do SQL Server
Coletar requisitos de armazenamento e de espaço e E/S do SQL Server
Vários fatores de arquitetura do SharePoint Server influenciam o design de armazenamento. Os principais fatores são: a quantidade de conteúdo, os recursos habilitados, os aplicativos de serviço implantados, número de farms e requisitos de disponibilidade.
Antes de começar a planejar o armazenamento, você deverá compreender os bancos de dados que o SharePoint Server pode usar.
Nesta seção:
Estimar as necessidades de armazenamento e de IOPS principais
Estimar necessidades de armazenamento de aplicativos de serviço e IOPS
Bancos de dados usados pelo SharePoint Server
As bases de dados instaladas com o SharePoint Servers (Subscription Edition, 2019 ou 2016) dependem das aplicações de serviço utilizadas no ambiente. Todos os ambientes do SharePoint Server dependem dos bancos de dados do sistema do SQL Server. Esta secção fornece um resumo das bases de dados instaladas com o SharePoint Servers. Para obter informações detalhadas sobre o banco de dados, consulte Tipos e descrições do banco de dados no SharePoint Server.
Alguns bancos de dados do SharePoint Server, do Mecanismo de Banco de Dados do SQL Server e do SQL Server Reporting Services (SSRS) têm recomendações ou requisitos de local. Para obter informações sobre esses locais de banco de dados, consulte Tipos e descrições dos bancos de dados no SharePoint Server. O Guia de referência rápida: bancos de dados dos SharePoint Servers 2016 e 2019 está disponível para download como um arquivo PDF ou Visio.
Os bancos de dados a seguir são os bancos de dados do sistema SharePoint Server e são instalados automaticamente.
Configuração
Conteúdo da Administração Central
Conteúdo (um ou mais)
A lista a seguir mostra os aplicativos de serviço SharePoint Server com bancos de dados:
Serviço de gerenciamento de aplicativos
Aplicativos para SharePoint
Business Data Connectivity
Metadados gerenciados
Serviços do PerformancePoint
Project Server (somente SharePoint Server 2013)
Serviço de Pesquisa
Administração de Pesquisa
Relatórios de Análise
Rastreamento
Link
Serviço de Repositório Seguro
Serviço de Tradução do SharePoint
Serviço Power Pivot do SQL Server
Serviço de Controle de Sessão
Serviço de Configurações de Inscrição
Coleta de Dados de Uso e Integridade
Serviço Perfil de Usuário
Perfil
Marcação de etiqueta de conteúdo social
Sincronização
Serviços de Automação do Word
A lista a seguir mostra os bancos de dados SharePoint Foundation 2013:
Configuração
Conteúdo da Administração Central
Conteúdo (um ou mais)
Serviço de gerenciamento de aplicativos
Pesquisar aplicativo de serviço:
Administração de pesquisa
Relatórios de Análise (um ou mais)
Rastreamento (um ou mais)
Link (um ou mais)
Serviço de Repositório Seguro
Aplicativo de Serviço de Configurações de Assinatura (se habilitado por meio do Windows PowerShell)
Serviço de Conjunto de Dados de Uso e Integridade
Serviço de Conversão do Word
Se estiver a integrar mais com o SQL Server, o seu ambiente também poderá incluir mais bases de dados, como no cenário seguinte. O POWER Pivot do SQL Server para SharePoint só pode ser utilizado num ambiente do SharePoint Server 2016 se utilizar o SQL Server 2016 RTM Enterprise Edition e o SQL Server 2016 SQL Server Analysis Services (SSAS). Se estiver a ser utilizado, também tem de planear suportar a base de dados da aplicação Power Pivot e a carga adicional no sistema. 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.
O suplemento SQL Server 2016 Reporting Services (SSRS) pode ser usado com qualquer ambiente do SharePoint Server 2016. Se estiver a utilizar o suplemento, planeie suportar as duas bases de dados do SQL Server Reporting Services e a carga adicional necessária para o SQL Server Reporting Services.
É possível usar o SQL Server 2012 PowerPivot para SharePoint 2013 em um ambiente do SharePoint 2013 que inclui o SQL Server 2008 R2 Enterprise Edition e o SQL ServerAnalysis Services. Se estiver a ser utilizado, também tem de planear suportar a base de dados da aplicação Power Pivot e a carga adicional no sistema. Para obter mais informações, veja Planear uma implementação do PowerPivot num farm do SharePoint, Power Pivot – Descrição Geral e Aprendizagem e Power View – Descrição Geral e Aprendizagem.
O plug-in do SQL Server 2008 R2 Reporting Services (SSRS) pode ser usado com qualquer ambiente do SharePoint 2013. Se estiver a utilizar o plug-in, planeie suportar as duas bases de dados do SQL Server 2008 R2 Reporting Services e a carga adicional necessária para o SQL Server 2008 R2 Reporting Services.
Observação
A integração do SQL Server Reporting Services com o SharePoint Server 2019 já não é suportada. Para obter mais informações, veja Reporting Services Report Server (Modo SharePoint) e Combinações suportadas do SharePoint e do servidor do Reporting Services.
Noções básicas do SQL Server e do IOPS
Em qualquer servidor que hospede uma instância do SQL Server, é importante que o servidor atinja a resposta mais rápida possível do subsistema de E/S.
Discos ou matrizes mais rápidos e em maior número oferece operações de E/S suficientes por segundo (IOPS) enquanto mantêm baixa latência e enfileiramento em todos os discos.
Você não pode adicionar outros tipos de recursos, como CPU e memória, para compensar a resposta lenta do subsistema de E/S. Entretanto, ele pode influenciar e causar problemas no farm. Planeje latência mínima antes da implantação e monitore seus sistemas existentes.
Antes de implementar um novo farm, recomendamos que compare o subsistema de E/S com o Utilitário Diskspd. Esta ferramenta funciona em todas as versões do Windows Server com todas as versões do SQL Server. Saiba mais em Utilitário Diskspd: uma ferramenta de teste de armazenamento robusta.
Testes de estresse também fornecem informações valiosas para SQL Server. Para saber mais, veja Benchmarking de armazenamento com DiskSpd.
Para obter informações detalhadas sobre como analisar requisitos do IOPS de uma perspectiva do SQL Server, veja Analisar características de E/S e dimensionando sistemas de armazenamento para aplicativos de banco de dados do SQL Server .
Estimar as necessidades de armazenamento e de IOPS principais
A configuração e o armazenamento de conteúdo e o IOPS são a camada base que você deve planejar em todas as implantações do SharePoint Server.
Configuração, armazenamento e IOPS
Os requisitos de armazenamento para o banco de dados de Configuração e banco de dados de conteúdo do Administração Central não são grandes. Recomendamos que você aloque 2 GB para o banco de dados de Configuração e 1 GB para o banco de dados de conteúdo do Administração Central. Ao longo do tempo, a base de dados de configuração pode crescer para além de 1 GB. Ele não aumenta rapidamente aproximadamente 40 MB para cada 50.000 conjuntos de sites.
Logs de transação para o banco de dados de configuração podem ser grandes. É recomendável fazer backup regularmente do log de transações para o banco de dados de configuração a fim de forçar o truncamento. Se você estiver usando espelhamento de banco de dados ou grupos de disponibilidade Always On do SQL Server, também deverá manter o banco de dados em execução no modo de recuperação total. Para mais informações, confira O log de transações (SQL Server).
Dica
Se você não estiver usando uma solução de alta disponibilidade do SQL Server que exija o uso do modelo de recuperação total, considere alterar o banco de dados de configuração para o modelo de recuperação simples.
Os requisitos de IOPS para o banco de dados de configuração e o banco de dados de conteúdo da Administração Central são mínimos.
Armazenamento de conteúdo e IOPs
A estimativa do armazenamento e do IOPS necessários para bancos de dados de conteúdo não é uma atividade precisa. Ao testarmos e explicarmos as informações a seguir, pretendemos ajudar você a derivar estimativas a serem usadas para determinar o tamanho inicial de sua implantação. Entretanto, quando seu ambiente estiver em execução, esperamos que você revisite suas necessidades de capacidade com base nos dados do seu ambiente de produção.
Para obter mais informações sobre nossa metodologia de planejamento de capacidade geral, confira Gerenciamento de capacidade e dimensionamento no SharePoint Server 2013.
Fórmula para estimar o armazenamento de banco de dados de conteúdo
O processo a seguir descreve como estimar aproximadamente o armazenamento necessário para bancos de dados de conteúdo, sem considerar arquivos de log:
Use a fórmula a seguir para estimar o tamanho de seus bancos de dados de conteúdo:
Tamanho do banco de dados = ((D x V) x S) + (10 KB x (L + (V x D)))
Observação
[!OBSERVAçãO] O valor de 10 KB na fórmula é uma constante que estima aproximadamente a quantidade de metadados necessários ao SharePoint Server. Se o seu sistema exigir um uso significativo de metadados, talvez seja necessário aumentar essa constante.
Calcule o número de documentos esperado. Esse valor é conhecido como D na fórmula.
Como você calcula o número de documento será determinado pelos recursos que estiver usando. Por exemplo, para Meus Sites ou sites de colaboração, recomendamos que você calcule o número de documentos esperado por usuário e multiplique pelo número de usuários. Para o gerenciamento de registros ou sites de publicação de conteúdo, é possível calcular o número de documentos gerenciados e gerados por um processo.
Se você estiver migrando de um sistema atual, pode ser mais fácil extrapolar sua taxa de crescimento e uso atual. Se você estiver criando um novo sistema, examine seus compartilhamentos de arquivo existentes ou outros repositórios e estimativa com base na taxa de uso.
Estime o tamanho médio dos documentos que você armazenará. Esse valor é conhecido como S na fórmula. Pode valer a pena estimar médias para diferentes tipos ou grupos de sites. O tamanho médio do arquivo para o Meus Sites, repositórios de mídia e diferentes portais de departamento podem variar significativamente.
Estime o número de itens de lista no ambiente. Esse valor é conhecido como L na fórmula.
Os itens de lista são mais difíceis de estimar do que documentos. Geralmente, utilizamos uma estimativa de três vezes o número de documentos (D), mas a fórmula de estimativa irá variar consoante a forma como espera utilizar os seus sites.
Determine o número aproximado de versões. Estime o número médio de versões que qualquer documento de uma biblioteca terá. Esse valor normalmente será muito menor do que o número de versões máximo permitido. Esse valor é conhecido como V na fórmula.
O valor V deve ser superior a zero.
Como um exemplo, use essa fórmula e as características da tabela a seguir para estimar o espaço de armazenamento necessário para arquivos de dados em um banco de dados de conteúdo para um ambiente de colaboração. O resultado é que você precisará de aproximadamente 105 GB.
Input | Valor |
---|---|
Número de documentos (D) | 200.000 Calculado supondo 10.000 usuários vezes 20 documentos |
Tamanho médio de documentos (S) | 250 KB |
Itens de lista (L) | 600.000 |
Número de versões não atuais (V) | 2 Supondo que o número máximo de versões permitido é de 10 |
Tamanho do banco de dados = (((200.000 x 2)) x 250) + ((10 KB x (600.000 + (200.000 x 2))) = 110.000.000 KB ou 105 GB
Observação
[!OBSERVAçãO] E/S de Arquivo Eficiente no SharePoint Server é um método de armazenamento no qual um arquivo é dividido em partes armazenadas e atualizadas separadamente. Essas partes são enviadas juntar quando um usuário solicita o arquivo. Isso aumenta o desempenho de E/S mas normalmente não aumenta o tamanho do arquivo. Entretanto, arquivos pequenos podem ver um pequeno aumento no armazenamento de disco necessário.
Recursos que influenciam o tamanho de bancos de dados de conteúdo
Os seguintes recursos do SharePoint Server podem afetar o tamanho dos bancos de dados de conteúdo:
Lixeiras Até um documento ser totalmente excluído da lixeira de primeiro e de segundo estágio, ele ocupará espaço em um banco de dados de conteúdo. Calcule quantos documentos são excluídos a cada mês para determinar o efeito de lixeiras no tamanho dos bancos de dados de conteúdo.
Auditoria Os dados de auditoria podem rapidamente compor e usar grandes quantidades de espaço em um banco de dados de conteúdo, especialmente se a exibição da auditoria estiver ativada. Em vez de permitir que os dados de auditoria cresçam sem limites, recomendamos que você habilite a auditoria somente nos eventos em que for importante atender necessidades regulamentares ou controles internos. Use as diretrizes a seguir para estimar o espaço que deverá ser reservado para dados de auditoria:
Estime o número de novas entradas de auditoria para um site e multiplique esse número por 2 KB (geralmente as entradas são limitadas a 4 KB, com um tamanho médio de cerca de 1 KB).
Com base no espaço que você deseja alocar, determine o número de dias de logs de auditoria que você deseja manter.
Observação
O Servidor do Office Online é a nova versão do Servidor dos Office Web Apps. Utilizar o Office Online Server com o SharePoint Servers 2016, 2019, a Subscription Edition não afeta o tamanho da base de dados de conteúdos. Para implantar o Servidor do Office Online no farm do SharePoint Server 2016, confira Implantar o Servidor do Office Online.
Estimar requisitos de IOPS de banco de dados de conteúdo
Os requisitos de IOPS para bases de dados de conteúdos variam com base na forma como o seu ambiente está a ser utilizado, no espaço disponível em disco e no número de servidores que tem. Em geral, recomendamos que você compare a carga prevista em seu ambiente a uma das soluções que testamos. Para obter mais informações e pode ser aplicado à versão mais recente do SharePoint, veja Resultados e recomendações do teste de capacidade e desempenho (SharePoint Server 2013).
Nos testes, descobrimos que os bancos de dados de conteúdo tendem a ficar em um intervalo de 0,05 IOPS/GB até cerca de 0,2 IOPS/GB. Também descobrimos que uma prática recomendada é aumentar a extremidade superior para 0,5 IOPS/GB. Esta proporção aumentada é mais do que o necessário e pode ser muito mais do que precisará no seu ambiente. Se utilizar o espelhamento, esta proporção aumentada resulta em muito mais E/S do que as bases de dados de conteúdo primárias. Tenha em atenção que as bases de dados de conteúdo espelhado nunca são leves.
Estimar necessidades de armazenamento de aplicativos de serviço e IOPS
Depois de estimar as necessidades de armazenamento de conteúdo e de IOPS, você deverá determinar o armazenamento e o IOPS necessários aos aplicativos de serviço em uso em seu ambiente.
Requisitos de armazenamento de aplicativos de serviço e de IOPS do SharePoint Server
Para estimar os requisitos de armazenamento para os aplicativos de serviço no sistema, primeiro você deverá estar ciente dos aplicativos de serviço e de como eles serão usados. Os aplicativos de serviço que estão disponíveis no SharePoint Server 2016 e que têm bancos de dados são listados nas tabelas a seguir. Os dados de armazenamento e IOPS para todas as aplicações de serviço no SharePoint Server Subscription Edition, 2019 ou 2016 permanecem iguais aos do SharePoint Servers 2010 e 2013.
Requisitos de IOPS e de armazenamento do aplicativo de serviço Pesquisar
Banco de dados | Dimensionamento | IOPS de disco | Tamanho do disco | 10 M itens | 100 M |
---|---|---|---|---|---|
Rastreamento | Um BD por 20 M itens SQL IOPS: 10 por DPS |
Médio/Alto | Médio | 15 GB Log de 2 GB |
110 GB Log de 50 GB |
Link | Um BD por 60 M itens SQL IOPS: 10 por 1 M itens |
Médio | Médio | 10 GB Log de 0.1 GB |
80 GB Log de 5 GB |
Relatórios de Análise | Dividir ao atingir de 100 a 300 GB | Médio | Médio | Dependente do uso | Dependente do uso |
Administração de Pesquisa | Um BD | Baixo | Baixo | 0,4 GB Log de 1 GB |
Dados de 1 GB Log de 2 GB |
Requisitos de armazenamento do aplicativo de serviço e recomendações de IOPS
Aplicativo de serviço | Recomendação de estimativa de tamanho |
---|---|
Perfil de Usuário | O aplicativo de serviço Perfil de Usuário está associado a três bancos de dados: Perfil, Sincronização e Marcação Social. Nota: os testes para os requisitos de armazenamento da base de dados do Perfil de Utilizador e as recomendações de IOPS ainda não estão concluídos. Verifique novamente para obter informações adicionais. Para saber mais de banco de dados de Perfil de Usuário, veja Tipos e descrições dos bancos de dados no SharePoint Server. |
Serviço de Metadados Gerenciados | O aplicativo de serviço Metadados Gerenciados tem um banco de dados. O tamanho do banco de dados é afetado pelo número de tipos de conteúdo e de palavras-chave usadas no sistema. Vários ambientes incluirão múltiplas instâncias do aplicativo de serviço Metadados Gerenciados. |
Serviço de Repositório Seguro | O tamanho banco de dados de aplicativos de serviço de Repositório Seguro é determinado pelo número de credenciais no armazenamento e pelo número de entradas na tabela de auditoria. Recomendamos que aloque 5 MB por cada 1000 credenciais. Ele tem IOPS mínimo. |
Serviço de Controle de Sessão | O aplicativo Serviço de Controle de Sessão tem um banco de dados. Recomendamos que você aloque 1 GB para ele. Ele tem IOPS mínimo. |
Serviços de Automação do Word | O aplicativo de serviço Automação do Word tem um banco de dados. Recomendamos que você aloque 1 GB para ele. Ele tem IOPS mínimo. |
Serviços do PerformancePoint | O aplicativo de serviço do PerformancePoint tem um banco de dados. Recomendamos que você aloque 1 GB para ele. Ele tem IOPS mínimo. |
Serviço Conectividade de Dados Corporativos | O aplicativo Serviço de Conectividade de Dados Corporativos tem um banco de dados. Esse banco de dados é pequeno e um crescimento significativo é improvável. Ele tem IOPS mínimo. Os Serviços PerformancePoint não são aplicáveis à Edição da Subscrição. |
Gerenciamento de Aplicativos | O aplicativo de serviço Gerenciamento de Aplicativos tem um banco de dados. Esse banco de dados é pequeno e um crescimento significativo é improvável. Ele tem IOPS mínimo. |
Power Pivot | O aplicativo Serviço do Power Pivot tem um banco de dados. Esse banco de dados é pequeno e não tem impacto significativo em E/S. Recomendamos que você use o mesmo IOPS como o banco de dados de conteúdo do SharePoint. As bases de dados de conteúdo têm requisitos de E/S significativamente mais elevados do que a base de dados da aplicação do serviço Power Pivot. |
Determinar necessidades de disponibilidade
A disponibilidade é o quanto um ambiente do SharePoint Server é visto pelos utilizadores como estando disponível. Um sistema disponível é um sistema resiliente ou seja, incidentes que afetam o serviço ocorrem com pouca frequência, e ações oportunas e efetivas são tomadas quando eles ocorrem.
Os requisitos de disponibilidade podem aumentar significativamente a necessidade de armazenamento. Para obter informações detalhadas, confira Crie uma arquitetura e uma estratégia de alta disponibilidade para o SharePoint Server. Além disso, confira o white paper do SQL Server 2012 Guia de arquitetura do Always On: criando soluções de alta disponibilidade e recuperação de desastres com Grupos de Disponibilidade Always On.
Escolher a versão e a edição do SQL Server
Recomendamos que, para a Edição de Assinatura do SharePoint Server, 2019 ou 2016, considere executar seu ambiente no Edição Enterprise dos seguintes SQL Servers para aproveitar os outros recursos de desempenho, disponibilidade, segurança e gerenciamento que essas versões fornecem.
SQL Server 2019 (Edição de Assinatura do SharePoint, 2019 e 2016)
SQL Server 2017 RTM (SharePoint Server 2016 e 2019)
SQL Server 2016 (SharePoint Server 2016 e 2019)
SQL Server 2014 com Service Pack 1 (SP1) (SharePoint Server 2016 apenas)
Para obter mais informações sobre os benefícios destas versões, consulte Funcionalidades Suportadas pelas Edições do SQL Server 2014, Edições e funcionalidades suportadas do SQL Server 2016, Edições e funcionalidades suportadas do SQL Server 2017 e Edições e funcionalidades suportadas do SQL Server 2019 (15.x)).
Recomendamos que, para o SharePoint Server 2013, considere executar o seu ambiente na Enterprise Edition do SQL Server 2008 R2 com o Service Pack 1 (SP1), o SQL Server 2012 ou o SQL Server 2014 para tirar partido das outras capacidades de desempenho, disponibilidade, segurança e gestão fornecidas por estas versões. Para saber mais sobre os benefícios do SQL Server 2008 R2 com SP1, do SQL Server 2012 e do SQL Server 2014 Enterprise Edition, veja Recursos com suporte nas edições do SQL Server 2014, Recursos com suporte nas edições do SQL Server 2012 e Recursos com suporte nas edições do SQL Server 2008 R2.
Em particular, você deve considerar se necessita dos seguintes recursos:
Compactação de Backup A compactação de backup pode acelerar os backups do SharePoint e está disponível em todas as edições do SQL Server 2008 e posteriores. Quando define a opção de compactação no script de backup ou configura o servidor com o SQL Server para compactar por padrão, você pode reduzir significativamente o tamanho dos backups de banco de dados e dos logs enviados. Para saber mais, confira Compactação de backup (SQL Server).
Observação
A compactação de dados do SQL Server não tem suporte para o SharePoint Server, exceto para os bancos de dados de aplicativos do serviço Pesquisar.
Criptografia de dados transparente Se os seus requisitos de segurança incluem a necessidade de criptografia de dados transparente, você deverá usar o SQL Server Enterprise Edition.
Implantação de conteúdo Se você planeja usar o recurso de implantação de conteúdo, considere o SQL Server Enterprise Edition de forma que o sistema possa aproveitar as vantagens de instantâneos de banco de dados.
Observação
Se você estiver usando um provedor de armazenamento de Blobs remoto que não dê suporte a instantâneos de banco de dados, não poderá usar instantâneos para implantação ou backup de conteúdo.
Armazenamento de BLOB remoto Se você quiser aproveitar as vantagens do armazenamento de BLOB remoto para um banco de dados ou local fora dos arquivos associados a cada banco de dados de conteúdo, deverá usar o Enterprise Edition do:
Edição de Assinatura do SharePoint Server:
SQL Server 2016
SQL Server 2017 RTM
SQL Server 2019
SharePoint Server 2019:
SQL Server 2016
SQL Server 2017 RTM
SQL Server 2019
SharePoint Server 2016:
SQL Server 2014 (SP1)
SQL Server 2016
SQL Server 2017 RTM
SQL Server 2019
SharePoint 2013:
SQL Server 2008 R2 com SP1
SQL Server 2012 Enterprise Edition
Administrador de recursos O Resource Governor é uma tecnologia introduzida no SQL Server 2008 para permitir a você gerenciar cargas de trabalho e recursos do SQL Server ao especificar limites ao consumo de recursos por solicitações de entrada. O Resource Governor permite que você diferencie cargas e aloque CPU e memória à medida que forem solicitados, com base nos limites especificados. Para obter mais informações sobre como utilizar o Resource Governor, veja Resource Governor.
Recomendamos que você use o Resource Governor com o SharePoint Server para:
Limitar a quantidade de recursos do SQL Server consumidos pelos servidores Web direcionados pelo componente de rastreamento de pesquisa. Como prática recomendada, recomendamos a limitação do componente de rastreamento para 10 por cento da CPU quando o sistema estiver sob carga.
Monitore quantos recursos são consumidos por cada banco de dados no sistema por exemplo, você pode usar o Resource Governor para ajudar você a determinar o melhor posicionamento de bancos de dados entre computadores que estejam executando o SQL Server.
Microsoft Power Pivot para SharePoint Permite que os utilizadores partilhem e colaborem em análises e modelos de dados gerados pelo utilizador no Excel na Web enquanto atualizam automaticamente essas análises. Tem de ter o Office na Web para utilizar o Excel na Web com o Power Pivot para SharePoint e o SharePoint Server 2016. Você pode usar o SQL Server 2014 (SP1) ou SQL Server 2016 RTM Enterprise Edition e SQL Server Analysis Services para business intelligence com SharePoint Server 2016. No entanto, você só pode usar Power Pivot para SharePoint com SQL Server 2016 RTM, não com SQL Server 2014 (SP1).
Power Pivot para SharePoint 2013 Permite que os usuários compartilhem e colaborarem em modelos e em análises de dados gerados pelo usuário no Excel e no navegador e, ao mesmo tempo, atualiza automaticamente essas análises. Ele faz parte do SQL Server 2008 R2 Analysis Services (SSAS) Datacenter e Enterprise Edition, do SP1 do SQL Server 2012 Analysis Services (SSAS) Enterprise Edition e do SQL Server 2014 Analysis Services (SSAS) Enterprise e Business Intelligence Edition.
Projetar a arquitetura de armazenamento baseada em requisitos de capacidade e de E/S
A arquitetura de armazenamento e os tipos de disco selecionados para o seu ambiente podem afetar o desempenho do sistema.
Nesta seção:
Escolher uma arquitetura de armazenamento
O SharePoint Server dá suporte às arquiteturas de armazenamento Direct Attached Storage (DAS), Storage Area Network (SAN) e Network Attached Storage (NAS), embora o NAS só tenha suporte para uso com bancos de dados de conteúdo configurados para usarem armazenamento de Blobs remoto. Sua escolha dependerá de fatores em sua solução comercial e em sua infraestrutura existente.
Qualquer arquitetura de armazenamento deve dar suporte às suas necessidades de disponibilidade e ter um desempenho adequado em IOPS e latência. Para ter suporte, o sistema deverá retornar consistentemente o primeiro byte de dados em 20 milissegundos (ms).
DAS (armazenamento de conexão direta)
O DAS é um sistema de armazenamento digital diretamente anexado a um servidor ou estação de trabalho, sem uma rede de armazenamento entre eles. Os tipos de disco físico do DAS incluem Serial Attached SCSI (SAS) e Serial Attached ATA (SATA).
Em geral, recomendamos que você escolha uma arquitetura DAS quando uma plataforma de armazenamento compartilhado não puder garantir um tempo de resposta de 20 ms e capacidade suficiente para IOPS médio e de pico.
Storage Area Network (SAN)
SAN é uma arquitetura para anexar dispositivos de armazenamento de um computador remoto (como matrizes de disco e bibliotecas de fita) a servidores de tal maneira que os dispositivos apareçam como anexados localmente ao sistema operacional (por exemplo, armazenamento de bloco).
Em geral, é recomendável escolher uma SAN quando os benefícios do armazenamento compartilhado sejam importantes para a sua organização.
Os benefícios do armazenamento compartilhado incluem:
É mais fácil realocar armazenamento de disco entre servidores.
Pode servir vários servidores.
Nenhuma limitação no número de discos que podem ser acessados.
NAS (Network Attached Storage)
Uma unidade NAS é um computador autocontido conectado a uma rede. Sua única finalidade é fornecer serviços de armazenamento de dados baseado em arquivo para outros dispositivos na rede. O sistema operacional e outro software na unidade NAS oferecem a funcionalidade de armazenamento de dados, sistemas de arquivos e acesso a arquivos, além do gerenciamento dessas funcionalidades (por exemplo, armazenamento de arquivos).
Observação
[!OBSERVAçãO] O NAS tem suporte somente para uso com bancos de dados de conteúdo configurados para usar o armazenamento de Blobs remoto (RBS). Qualquer arquitetura de armazenamento de rede deve responder a um ping em 1 ms e deve retornar o primeiro byte de dados em 20 ms. Essa restrição não se aplica ao provedor de FILESTREAM do SQL Server local, porque só armazena dados localmente no mesmo servidor.
Observação
[!OBSERVAçãO] Há certa confusão sobre o uso da Internet Small Computer System Interface (iSCSI) e supõe que ela seja um protocolo de NAS. Se você acessar esse armazenamento iSCSI por meio do Common Internet File System (CFIS), será um protocolo de NAS. Isso significa que você não poderá usar esse armazenamento com bancos de dados de conteúdo se eles não forem configurados para usar o RBS. Se, no entanto, você acessar esse armazenamento iSCSI por meio de um disco rígidos anexado localmente, será considerado como uma arquitetura de SAN. Isso significa que você poderá usá-lo com NAS.
Escolher tipos de disco
Os tipos de disco usados no sistema podem afetar a confiabilidade e o desempenho. Se todo o resto for igual, unidades maiores aumentam o tempo médio de busca. O SharePoint Server dá suporte aos seguintes tipos de unidades:
Small Computer System Interface (SCSI)
SATA
Serial-attached SCSI (SAS)
Fibre Channel (FC)
Integrated Device Electronics (IDE)
Unidade de Estado Sólido (SSD) ou Unidade Flash
Escolher Tipos de RAID
Com frequência, o RAID (Redundant Array of Independent Disks) é usado para aprimorar as características de desempenho de discos individuais (ao dividir dados entre vários discos) e para oferecer proteção contra falhas de disco individuais.
Todos os tipos de RAID têm suporte para o SharePoint Server. Entretanto, recomendamos que você use o RAID 10 ou uma solução de RAID específica do fornecedor com desempenho equivalente.
Quando você configurar uma matriz RAID, alinhe o sistema de arquivos ao deslocamento fornecido pelo fornecedor.
Para saber mais sobre o provisionamento de RAID para SQL Server, confira RAID.
Estimar requisitos de memória
A memória necessária ao SharePoint Server está diretamente relacionada ao tamanho dos bancos de dados de conteúdo que você está hospedando em um servidor que esteja executando o SQL Server.
À medida que você adiciona aplicativos e recursos de serviço, seus requisitos provavelmente aumentarão. A tabela a seguir oferece orientação sobre a quantidade de memória recomendada.
Tamanho combinado de bancos de dados de conteúdo | RAM recomendada para o computador executar o SQL Server |
---|---|
Mínimo para implantações de produção pequenas | 8 GB |
Mínimo para implantações de produção médias | 16 GB |
Recomendação para até 2 terabytes | 32 GB |
Recomendação para o intervalo entre 2 terabytes e 5 terabytes | 64 GB |
Recomendação para mais de 5 terabytes | RAM adicional acima de 64 GB pode aumentar a velocidade de cache do SQL Server |
Observação
Esses valores são maiores do que os recomendados como valores mínimos para o SQL Server devido à distribuição de dados necessária para um ambiente do SharePoint Server. Para obter mais informações sobre os requisitos do sistema do SQL Server, consulte Requisitos de hardware e software para instalação do SQL Server 2014 e Requisitos de hardware e software para instalação do SQL Server para os SQL Servers 2016 e 2017.
Para saber mais sobre especificações e limites de capacidade do SQL Server, confira Calcular limites de capacidade por edição do SQL Server e Especificações de capacidade máxima para SQL Server.
Outros fatores que podem influenciar a memória necessária incluem:
O uso de espelhamento do SQL Server.
O uso frequente de arquivos com mais de 15 megabytes (MB).
Compreender os requisitos de topologia de rede
Planeje as conexões de rede nos farms e entre farms. Recomendamos que você use uma rede com baixa latência.
A lista a seguir oferece algumas práticas recomendadas e recomendações:
Todos os servidores do farm devem ter largura de banda e latência de LAN par o servidor que esteja executando o SQL Server. A latência não deve ser maior do que 1 milissegundo.
Não recomendamos uma topologia de rede de longa distância (WAN) na qual um servidor que esteja executando o SQL Server seja implantada remotamente de outros componentes do farm em uma rede com latência maior de 1 ms porque essa topologia não foi testada.
Planeje uma rede WAN adequada se quiser usar o pacote de implementação do Always On, espelhamento, o envio de logs ou o Cluster de Failover do SQL Server para manter um site remoto atualizado.
Recomendamos que servidores Web e servidores de aplicativos tenham dois adaptadores de rede: um adaptador de rede para manipular o tráfego de usuário e outro para manipular a comunicação com os servidores que estejam executando o SQL Server.
Observação
Se você usar iSCSI, verifique se o adaptador de rede é dedicado à comunicação de rede ou iSCSI, não a ambos.
Configurar o SQL Server
As seções a seguir descrevem como planejar a configuração do SQL Server para o SharePoint Server.
Nesta seção:
Estimar quantos servidores são necessários
Em geral, o SharePoint Server é projetado para aproveitar as vantagens do dimensionamento do SQL Server. Por exemplo, o SharePoint Server pode ter um desempenho melhor com vários servidores de tamanho médio que estejam executando o SQL Server do que com vários servidores grandes apenas.
Sempre coloque SQL Server em um servidor dedicado que não esteja executando outras funções de farm ou hospedando bancos de dados para qualquer outro aplicativo. A única exceção a essa recomendação é se você implantar o sistema em um servidor autônomo para um desenvolvimento ou um ambiente de teste orientado a algo diferente de desempenho. Embora o SQL Server possa ser executado no mesmo servidor do SharePoint, recomendamos a execução do SQL Server em um servidor separado para melhorar o desempenho.
As instruções a segui são uma orientação geral para quando você implantar um servidor adicional que executará uma instância do SQL Server:
Adicione outro servidor de banco de dados quando tiver mais de quatro servidores Web que estejam sendo executados em sua capacidade total.
Adicione outro servidor de banco de dados quando seu servidor atual tiver atingido seus limites de recurso efetivos de RAM, CPU, taxa de transferência de ES de disco, capacidade de disco ou taxa de transferência de rede.
Saiba mais em Calcular limites de capacidade por edição do SQL Server e Especificações de capacidade máxima para SQL Server.
Para promover o armazenamento seguro de credenciais ao executar o aplicativo de serviço do Repositório Seguro, recomendamos que o banco de dados do Repositório Seguro seja hospedado em uma instância de banco de dados separada onde o acesso será limitado a um administrador.
Configurar armazenamento e memória
No servidor que esteja executando o SQL Server, recomendamos que o cache L2 por CPU tenha um mínimo de 2 MB para aprimorar a memória.
Seguir recomendações de configuração de armazenamento do fornecedor
Para obter o desempenho ideal ao configurar uma matriz de armazenamento físico, siga as recomendações de configuração de hardware oferecidas pelo fornecedor do armazenamento em vez de confiar nos valores padrão do sistema operacional.
Se você não recebeu orientações do fornecedor, recomendamos usar os cmdlets de armazenamento do PowerShell que estão disponíveis para Windows Server 2012 R2. Saiba mais em Cmdlets de armazenamento no Windows PowerShell.
Fornecer o máximo de recursos possível
Verifique se os canais de E/S do SQL Server para os discos não estejam compartilhados por outros aplicativos, como o arquivo de paginação e os logs de Serviços de Informações da Internet (IIS).
Forneça o máximo de largura de banda de barramento possível. Uma largura de banda de barramento maior aumenta a confiabilidade e o desempenho. Considere que o disco não é o único usuário da largura de banda de barramento por exemplo, você também deve contabilizar o acesso da rede.
Definir opções do SQL Server
As seguintes configurações e opções do SQL Server devem ser configurados antes da implantação do SharePoint Server.
Não ative a criação automática de estatísticas num servidor que aloja o SQL Server e suporte o SharePoint Server. O SharePoint Server define as configurações necessárias no provisionamento e na atualização. As estatísticas decriação automática podem alterar o plano de execução de uma consulta de uma instância do SQL Server para outra instância do SQL Server. Por tanto, para fornecer suporte consistente para todos os clientes, o SharePoint Server oferece dicas codificadas para consultas como necessário para fornecer o melhor desempenho em todos os cenários.
Para garantir o desempenho ideal, recomendamos que você defina o grau máximo de paralelismo (MAXDOP) como 1 para instâncias do SQL Server que hospedam bancos de dados do SharePoint Server. Para saber mais sobre como definir o grau máximo de paralelismo, veja Configurar o grau máximo de paralelismo Opção de Configuração do Servidor.
Configurar bancos de dados
A orientação a seguir descreve práticas recomendadas de planejamento à medida que você configura cada banco de dados em seu ambiente.
Separar e priorizar seus dados entre discos
O ideal é colocar o banco de dados tempdb, bancos de dados de conteúdo, banco de dados, bancos de dados de pesquisa e SQL Server 2019, SQL Server 2017 RTM, SQL Server 2016, SQL Server 2014 (SP1), SQL Server 2012 e SQL Server 2008 R2 com logs de transação SP1 em discos rígidos físicos separados.
A lista a seguir oferece algumas práticas recomendadas e recomendações para a priorização de dados:
Quando você priorizar dados entre discos mais rápidos, use a seguinte classificação:
Arquivos de dados e logs de transação de Tempdb
Arquivos de log de transação de banco de dados
Bancos de dados de pesquisa, exceto pelo banco de dados de administração de Pesquisar
Arquivos de dados de banco de dados
Em um site de portal orientado para leitura pesada, priorize os dados em detrimento dos logs.
Os testes e os dados do cliente mostram que o desempenho do farm do SharePoint Server pode ser impedido por E/S de disco insuficiente para tempdb. Para evitar esse problema, aloque discos dedicados para tempdb. Se uma carga de trabalho alta for projetada ou monitorada ou seja, a ação de leitura média ou a ação de gravação média exige mais de 20 ms talvez seja necessário reduzir o gargalo separando os arquivos entre discos ou substituindo os discos por discos mais rápidos.
Para melhor desempenho, posicione o tempdb em uma matriz RAID 10. O número de arquivos de dados de tempdb deve ser igual ao número de CPUs de núcleo e os arquivos de dados de tempdb devem ser definidos em um tamanho igual. Conte processadores dual core como duas CPUs para essa finalidade. Conte cada processador que dê suporte a hyper-thread como uma única CPU. Saiba mais em Otimizando o desempenho de tempdb.
Separe dados de banco de dados e arquivos de log de transações entre discos diferentes. Se os arquivos tiverem de compartilhar discos porque os arquivos são muito pequenos para garantir um disco ou faixa inteiro, ou se você tiver pouco espaço em disco, coloque arquivos com padrões de uso diferentes no mesmo disco para minimizar solicitações de acesso simultâneo.
Confira seu fornecedor de hardware de armazenamento para obter informações sobre como configurar todos os logs e os bancos de dados de pesquisa para otimização de gravação para sua solução de armazenamento particular.
Usar vários arquivos de dados para bancos de dados de conteúdo
Siga estas recomendações para obter o melhor desempenho:
Só crie arquivos no grupo de arquivos principal para o banco de dados.
Distribua os arquivos por discos separados.
O número de arquivos de dados deve ser melhor ou igual ao número de CPUs de núcleo. Conte processadores dual core como duas CPUs para essa finalidade. Conte cada processador que dê suporte a hyper-thread como uma única CPU.
Crie arquivos de dados de mesmo tamanho.
Importante
[!IMPORTANTE] Embora você possa usar as ferramentas de backup e de recuperação internas do SharePoint Server para fazer backup e recuperar vários arquivos de dados, se você substituir no mesmo local, as ferramentas não poderão restaurar vários arquivos de dados em um local diferente. Por esse motivo, recomendamos que, ao usar vários arquivos de dados para um banco de dados de conteúdo, você use ferramentas de backup e de recuperação do SQL Server. Para obter mais informações sobre como fazer backup do SharePoint Server e recuperá-lo, consulte Planejamento de backup e recuperação no SharePoint Server.
Para obter mais informações sobre como criar e gerenciar grupos de arquivos, consulte Arquitetura de arquivos e grupos de arquivos.
Limitar o tamanho do banco de dados de conteúdo para melhorar a capacidade de gerenciamento
Planeje o dimensionamento do banco de dados para melhorar a capacidade de gerenciamento, o desempenho e a facilidade de atualização do seu ambiente.
Para ajudar a garantir o desempenho do sistema, recomendamos que você limite o tamanho de bancos de dados de conteúdo a 200 GB, exceto quando cenários e condições de uso específicos dão suporte a tamanhos maiores. Para obter mais informações sobre limites de tamanho do banco de dados de conteúdo, consulte a seção "Limites do banco de dados de conteúdo" em Limites de software para os SharePoint Servers 2016 e 2019.
Geralmente, nós recomendamos que um conjunto de sites não exceda 100 GB, a menos que ele seja o único conjunto de sites no banco de dados de forma que você possa usar as ferramentas de backup granulares do SharePoint Server para mover um conjunto de sites para outro banco de dados, caso seja necessário.
Gerenciamento proativo do aumento de arquivos de dados e de log
Recomendamos que você gerencie proativamente o crescimento de dados e de arquivos de log ao considerar as seguintes recomendações:
O máximo possível, aumente por antecipação todos os dados e arquivos de log até seus tamanhos finais esperados.
Recomendamos que você habilite o crescimento automático por motivos de segurança. Não configure as configurações de crescimento automático padrão. Considere as diretrizes a seguir ao configurar o crescimento automático:
Quando você planeja bancos de dados de conteúdo que excedam o tamanho recomendado (200 GB), defina o valor de crescimento automático do banco de dados como um número fixo de megabytes em vez de usar uma porcentagem. Esta definição reduz a frequência com que o SQL Server aumenta o tamanho de um ficheiro. O aumento do tamanho do arquivo é uma ação de bloqueio que envolve o preenchimento do novo espaço com páginas vazias.
Se não for esperado que o tamanho calculado da base de dados de conteúdos atinja o tamanho máximo recomendado de 200 GB no próximo ano, defina-o como o tamanho máximo que a base de dados deverá atingir dentro de um ano ( com uma margem adicional de 20 por cento para o erro ) através da propriedade ALTER DATABASE MAXSIZE . Examine periodicamente essa configuração para garantir que ainda seja um valor adequado, dependendo das taxas anteriores de crescimento.
Mantenha um nível de pelo menos 25% de espaço disponível nos discos para permitir o crescimento e padrões de uso de pico. Se você estiver gerenciando o crescimento ao adicionar discos a uma matriz RAID ou se estiver alocando mais armazenamento, monitore o tamanho do disco de perto para impedir a falta de espaço.
Validar e monitorar o desempenho do armazenamento e do SQL Server
Teste se o seu desempenho e se a sua solução de backup em seu hardware permite que você cumpra seus contratos de nível de serviço (SLAs). Em particular, teste o subsistem de E/S do computador que esteja executando o SQL Server para garantir que o desempenho seja satisfatório.
Teste a solução de backup que você esteja usando para garantir que ela possa fazer backup do sistema na janela de manutenção disponível. Se a solução de backup não conseguir atender aos SLAs exigidos por sua empresa, considere o uso de uma solução de backup incremental, como o Microsoft System Center Data Protection Manager.
É importante controlar os seguintes componentes de recurso de um servidor que esteja executando o SQL Server: CPU, memória, proporção de cache/ocorrências e subsistema de E/S. Quando um ou mais componentes parecerem lentos ou sobrecarregados, analise a estratégia adequada com base na carga de trabalho atual e prevista. Para obter mais informações, consulte Monitorar e Ajustar o Desempenho.
A seção a seguir lista os contadores de desempenho que recomendamos que você use para monitorar o desempenho dos bancos de dados do SQL Server que estejam sendo executados em seu ambiente do SharePoint Server. Também listados estão os valores íntegros aproximados para cada contador.
Para obter detalhes sobre como monitorar desempenho e usar contadores de desempenho, confira Monitor de Desempenho do Windows e Monitorar o desempenho.
Contadores do SQL Server a serem monitorados
Monitore os seguintes contadores do SQL Server para garantir a integridade de seus servidores:
Estatísticas gerais Esse objeto oferece contadores para monitorar atividade geral em todo o servidor, como o número de conexões atuais e o número de usuários conectando e desconectando por segundo de computadores que estejam executando uma instância do SQL Server. Considere o monitoramento do seguinte contador:
- Conexões de usuário Esse contador mostra o número de conexões de usuário em seu computador que está executando o SQL Server. Se você perceber que esse número aumentou em 500% a partir de sua linha de base, talvez veja uma redução de desempenho.
Bancos de dados Esse objeto oferece contadores para monitorar operações de cópia em massa, taxa de transferência de backup e restauração e atividades de log de transações. Monitore transações e o log de transações para determinar a atividade de usuário que está ocorrendo no banco de dados e o quão cheio o log de transações está se tornando. A atividade de usuário pode determinar o desempenho do banco de dados e afetar o tamanho do log, o bloqueio e a replicação. O monitoramento da atividade de log de baixo nível para medir a atividade de usuário e o uso de recurso pode ajudar você a identificar gargalos de desempenho. Considere o monitoramento do seguinte contador:
- Transações/seg Esse contador mostra o número de transações em um determinado banco de dados ou em um servidor inteiro por segundo. Esse número é mais para sua linha de base e para ajudar você a solucionar problemas.
Bloqueios Esse objeto oferece informações sobre bloqueios do SQL Server em tipos de recurso individuais. Considere o monitoramento dos seguintes contadores:
Tempo Médio de Espera (ms) Esse contador mostra o tempo médio de espera para cada solicitação de bloqueio que resultou em uma espera.
Tempo de Espera de Bloqueio (ms) Esse contador mostra o tempo de espera para bloqueios no último segundo.
Esperas de bloqueio/seg Esse contador mostra o número de bloqueios por segundo que não poderiam ser satisfeitos imediatamente e tinham de esperar por recursos.
Número de deadlocks/seg Esse contador mostra o número de deadlocks no computador que está executando o SQL Server por segundo. Este número não deve aumentar acima de 0.
Travas Esse objeto oferece contadores para monitorar travamentos de recurso internos do SQL Server chamados travamentos. O monitoramento dos travamentos para determinar a atividade do usuário e o uso de recursos pode ajudar a identificar gargalos de desempenho. Considere o monitoramento dos contadores a seguir:
Tempo Médio de Espera de Trava (ms) Esse contador mostra o tempo de espera de travamento para solicitações de travamento que tiverem de aguardar.
Esperas de Travamento/seg Esse contador mostra o número de solicitações de travamento que não puderam ser concedidas imediatamente.
Estatísticas de SQL Esse objeto fornece contadores para monitorar a compilação e o tipo de solicitações enviados para uma instância do SQL Server. O monitoramento do número de compilações e de recompilações de consulta e o número de lotes recebidos por uma instância do SQL Server oferece a você uma indicação da rapidez com que o SQL Server está processando consultas de usuário e com que efetividade o otimizador de consultas está processando as consultas. Considere o monitoramento dos seguintes contadores:
Compilações de SQL/seg Esse contador indica o número de vezes que o caminho de código de compilação é inserido por segundo.
Recompilações de SQL/seg Esse contador indica o número de recompilações de instruções por segundo.
Gerenciador de Buffer Esse objeto oferece contadores para monitorar como o SQL Server usa a memória para armazenar páginas de dados, estruturas de dados internas e o cache de procedimento, além de contadores para monitorar a E/S física à medida que o SQL Server lê e grava páginas de banco de dados. Considere o monitoramento do seguinte contador:
Taxa de Ocorrências no Cache do Buffer
Esse contador mostra a porcentagem de páginas que foram encontradas no cache do buffer sem precisarem ser lidas do disco. A taxa é o número total de ocorrências no cache dividido pelo número total de pesquisas de cache nos mil últimos acessos de página. Como a leitura do cache é muito menos cara do que a leitura do disco, é desejável que essa taxa seja alta. Geralmente, você pode aumentar a taxa de ocorrências no cache do buffer aumentando a memória disponível para o SQL Server.
Planejar o cache Esse objeto oferece contadores para monitorar a forma como o SQL Server usa a memória para armazenar objetos como procedimentos armazenados, instruções Transact-SQL preparadas e não preparadas e gatilhos. Considere o monitoramento do seguinte contador:
Taxa de Ocorrência no Cache
Esse contador indica a taxa entre ocorrências no cache e pesquisas de planos.
Contadores de servidor físico a serem monitorados
Monitore os seguintes contadores para garantir a integridade de seus computadores que estejam executando o SQL Server:
Processador: % de Tempo de Processador: _Total Esse contador mostra a porcentagem de tempo em que o processador está executando processos de aplicativo ou de sistema operacional diferentes de Ocioso. No computador que esteja executando o SQL Server, esse contador deve ser mantido entre 50% e 75%. Se houver sobrecarga constante, investigue se existe uma atividade de processo anormal ou se o servidor precisa de mais CPUs.
Sistema: Comprimento de Fila de Processador Esse contador mostra o número de threads na fila do processador. Monitore esse contador para garantir que ele permaneça menos de duas vezes o número de CPUs de núcleo.
Memória: Mbytes Disponíveis Esse contador mostra a memória física, em megabytes, disponível para processos executados no computador. Monitore esse contador para garantir que você mantenha um nível de pelo menos 20% do total disponível de RAM física.
Memória: Páginas/seg Esse contador mostra a taxa na qual as páginas são lidas ou gravadas em disco para resolver falhas de página impressa. Monitore esse contador para garantir que ele permaneça abaixo de 100.
Para saber mais e conhecer os métodos de solução de problemas de memória, veja os seguintes recursos:
SQL Server 2014 (SP1) -Monitorar o uso da memória
SQL Server 2017, SQL Server 2017, & SQL Server 2019 -Monitor Memory Usage
Para saber mais e ver métodos de solução de problemas de memória, confira o artigo Monitorando o uso da memória para SQL Server 2008 R2 com SP1, Monitorando o uso da memória para SQL Server 2012 e Monitorando o uso da memória para SQL Server 2014.
Contadores de disco a ser monitorados
Monitore os seguintes contadores para garantir a integridade de discos. Os seguintes valores representam valores medidos ao longo do tempo, não valores que ocorrem durante um pico repentino e não valores baseados numa única medição.
Disco Físico: % Tempo de Disco: DataDrive Esse contador mostra a porcentagem de tempo decorrido em que a unidade de disco selecionada está ocupada servindo solicitações de leitura e gravação - geralmente é um indicador da ocupação do disco. Se o contador PhysicalDisk: % Tempo de Disco for alto (mais de 90%), verifique o contador PhysicalDisk: Comprimento de Fila de Disco Atual para ver quantas solicitações do sistema estão aguardando acessos ao disco. O número de solicitações de E/S aguardando deve ser mantido em até 1,5 a 2 vezes o número de eixos que compõem o disco físico.
Disco Lógico: Transferências de Disco/seg Esse contador mostra a taxa na qual operações de leitura e gravação são executadas no disco. Use esse contador para monitorar tendências de crescimento e prever com precisão.
Disco Lógico: Bytes de Leitura de Disco/seg e Disco Lógico: Bytes de Gravação de Disco/seg Esses contadores mostram a taxa na qual os bytes são transferidos do disco durante operações de leitura e de gravação.
Disco Lógico: Média de Bytes no Disco/Leitura Esse contador mostra o número médio de bytes transferidos do disco durante operações de leitura. Esse valor pode refletir latência operações de leitura maiores podem resultar em latência ligeiramente maior.
Disco Lógico: Média de Bytes no Disco/Gravação Esse contador mostra o número médio de bytes transferidos para o disco durante operações de gravação. Esse valor pode refletir latência de disco - operações de gravação maiores podem resultar em latência ligeiramente maior.
Disco Lógico: Comprimento de Fila de Disco Atual Esse contador mostra o número de solicitações pendentes no disco no momento em que os dados desempenho são coletados. Para esse contador, valores menores são melhores. Valores maiores de 2 por disco podem indicar um gargalo e devem ser investigados. Por conseguinte, um valor de até 8 é aceitável para uma unidade lógica (LUN) composta por quatro discos. Os gargalos podem criar uma lista de pendências que poderá se espalhar para além do servidor atual que esteja acessando o disco e resultar em tempos de espera maiores para usuários. Soluções possíveis para um gargalo são adicionar mais discos à matriz RAID, substituir discos existentes por discos mais rápidos ou mover alguns dados para outros discos.
Disco Lógico: Comprimento Médio de Fila de Disco Esse contador mostra o número médio de solicitações de leitura e gravação que foram enfileiradas para o disco selecionado durante o intervalo de exemplo. A regra é que deve haver duas ou menos solicitações de leitura ou gravação pendentes por eixo. No entanto, esta contagem de pedidos pode ser difícil de medir devido à virtualização do armazenamento e às diferenças nos níveis RAID entre configurações. Procure por comprimentos de fila de disco maiores do que a média em combinação com latências de disco maiores do que a média. Essa combinação pode indicar que o cache de matriz de armazenamento está sendo superutilizada ou que o eixo compartilhado com outros aplicativos está afetando o desempenho.
Disco Lógico: Média de Disco por s/Leitura e Disco Lógico: Média de Disco por s/Gravação Esses contadores mostram o tempo médio, em segundos, de uma operação de leitura ou gravação no disco. Monitore esses contadores para garantir que eles permaneçam abaixo dos 85% da capacidade do disco. O tempo de acesso ao disco aumenta exponencialmente caso as operações de leitura ou gravação sejam mais de 85% da capacidade do disco. Para determinar a capacidade específica para seu hardware, veja a documentação do fornecedor ou use o Utilitário Diskspd, ferramenta de teste de armazenamento para calculá-lo. Para obter mais informações, consulte Diskspd: Uma ferramenta robusta de desempenho de armazenamento.
Disco Lógico: Média de Disco por seg/Leitura Esse contador mostra o tempo médio, em segundos de uma operação de leitura do disco. Em um sistema bem ajustado, os valores ideais estão entre 1 e 5 ms para logs (idealmente 1 ms em uma matriz com cache) e entre 4 e 20 ms para dados (idealmente menos de 10 ms). Latências mais altas podem ocorrer durante tempos de pico. Entretanto, se valores altos ocorrerem regularmente, você deverá investigar a causa.
Disco Lógico: Disco Médio seg/Escrita Este contador mostra o tempo médio, em segundos, de uma operação de escrita no disco. Em um sistema bem ajustado, os valores ideais estão entre 1 e 5 ms para logs (idealmente 1 ms em uma matriz com cache) e entre 4 e 20 ms para dados (idealmente menos de 10 ms). Latências mais altas podem ocorrer durante tempos de pico. Entretanto, se valores altos ocorrerem regularmente, você deverá investigar a causa.
Quando você estiver usando configurações de RAID com os contadores Disco Lógico: Média de Bytes no Disco/Leitura ou Disco Lógico: Média de Bytes no Disco/Gravação, use as fórmulas listadas na tabela a seguir para determinar a taxa de entrada e saída no disco.
Nível de RAID | Fórmula |
---|---|
RAID 0 | E/Ss por disco = (leituras + gravações) / número de discos |
RAID 1 | E/Ss por disco = [leituras + (2 x gravações)] / 2 |
RAID 5 | E/Ss por disco = [leituras + (4 x gravações)] / número de discos |
RAID 10 | E/Ss por disco = [leituras + (2 x gravações)] / número de discos |
Por exemplo, se você tiver um sistema RAID 1 com dois discos físicos, e se seus contadores estiverem nos valores mostrados na tabela a seguir.
Contador | Valor |
---|---|
Média de Disco por seg/Leitura** | 80 |
Disco Lógico: Média de Disco por seg/Gravação** | 70 |
Comprimento Médio de Fila de Disco** | 5 |
O valor E/Ss por disco pode ser calculado da seguinte maneira: (80 + (2 × 70))/2 = 110
O disk queue length pode ser calculado da seguinte maneira: 5/2 = 2.5
Nesta situação, você tem um gargalo de E/S limítrofe. E
Outras ferramentas de monitoramento
Também pode monitorizar a latência do disco e analisar tendências com a vista de gestão dinâmica sys.dm_io_virtual_file_stats no SQL Server 2008. Para obter mais informações, veja sys.dm_io_virtual_file_stats (Transact-SQL).
SQL Server 2012 para SharePoint Server 2013
Graças a Bill Baer, Gestor Sénior de Marketing de Produtos da Microsoft e Brian Alderman, CEO e Fundador da MicroTechPoint por fornecer uma série de módulos de formação online do SQL Server 2012. Agradecimentos especiais ao Channel 9 da Microsoft por hospedar esses módulos de treinamento online. Os seguintes módulos de preparação fornecem detalhes sobre as definições da base de dados do SQL Server 2012 para o ajudar a aprender a melhorar o desempenho, a disponibilidade e a segurança do SharePoint Server 2016.
Ajustando o SQL Server 2012 para o SharePoint 2013: (03) Configurações de servidor para o SQL Server
Confira também
Conceitos
Visão geral do SQL Server em ambientes do SharePoint Server 2016 e 2019
Otimizar o desempenho do SharePoint Server 2013
Práticas recomendadas para o SQL Server em um farm do SharePoint Server
Planejamento de desempenho no SharePoint Server 2013
Gerenciamento de capacidade e dimensionamento no SharePoint Server 2013
Planejamento de capacidade para o SharePoint Server 2013
Outros recursos
Visão geral do SQL Server em um ambiente do SharePoint Server 2013