Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010)
Aplica-se a: SharePoint Foundation 2010, SharePoint Server 2010
Tópico modificado em: 2016-11-30
Este artigo descreve como planejar e configurar o armazenamento e a camada do banco de dados do Microsoft SQL Server em um ambiente do Microsoft SharePoint Server 2010.
As informações de planejamento de capacidade neste documento fornece diretrizes a serem usadas por você em seu planejamento. Elas se baseiam em testes realizados na Microsoft em ativos em uso. No entanto, os resultados obtidos por você podem variar com base nos equipamentos usados e nos recursos implementados.
Como o SharePoint Server geralmente é executado em ambientes em que os bancos de dados são gerenciados por administradores de bancos de dados do SQL Server separados, este documento é destinado ao uso conjunto por implementadores de farms do SharePoint Server e administradores de bancos de dados do SQL Server. Ele pressupõe um grande entendimento do SharePoint Server e do SQL Server.
Este artigo pressupõe que você está familiarizado com os conceitos apresentados em Capacity management and sizing for SharePoint Server 2010.
Processo de design e configuração do armazenamento e da camada do banco de dados dos Produtos SharePoint 2010
É recomendável que você divida o processo de design do armazenamento e da camada do banco de dados nas etapas a seguir. Cada seção fornece informações detalhadas sobre cada etapa de design, incluindo requisitos e práticas recomendadas de armazenamento:
Coletar requisitos de armazenamento e de espaço e E/S do SQL Server
Escolher a versão e a edição do SQL Server
Projetar a arquitetura de armazenamento com base em requisitos de capacidade e E/S
Estimar requisitos de memória
Entender os requisitos de topologia de rede
Configurar o SQL Server
Validar e monitorar o desempenho do armazenamento e 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 2010 influenciam o design do armazenamento. A quantidade usada de conteúdo, recursos e aplicativos de serviço, o número de farms e a necessidade de disponibilidade são fatores-chave.
Antes de começar a planejar o armazenamento, você deve conhecer os bancos de dados que o SharePoint Server 2010 pode usar.
Nesta seção:
Bancos de dados usados por Produtos do SharePoint 2010
Conhecer o SQL Server e o IOPS
Estimar as necessidades de IOPS e armazenamento central
Determinar as necessidades de IOPS e armazenamento de aplicativos de serviço
Determinar as necessidades de disponibilidade
Bancos de dados usados por Produtos do SharePoint 2010
Os bancos de dados instalados com o SharePoint Server 2010 dependem dos recursos usados no ambiente. Todos os ambientes do Produtos do SharePoint 2010 têm como base bancos de dados de sistema do SQL Server. Esta seção fornece um resumo dos bancos de dados instalados com o SharePoint Server 2010. Para saber mais, consulte Tipos e descrições dos bancos de dados (SharePoint Server 2010) e Modelo de banco de dados (https://go.microsoft.com/fwlink/p/?LinkId=187968).
| Versão e edição do produto | Bancos de dados |
|---|---|
SharePoint Foundation 2010 |
Configuração Conteúdo da Administração Central Conteúdo (um ou mais) Coleta de Dados de Uso e Integridade Conectividade de Dados Corporativos Serviço de Registro de Aplicativo (em caso de atualização do Catálogo de Dados Corporativos do Microsoft Office SharePoint Server 2007) Serviço de Configurações de Inscrição (se habilitado por meio do Windows PowerShell) |
Bancos de dados adicionais para o SharePoint Server 2010 Standard Edition |
Aplicativo de serviço de pesquisa:
Aplicativo de serviço de Perfil de Usuário:
Aplicativo de serviço do Web Analytics
Repositório seguro Estado Metadados Gerenciados Serviços de Automação do Word |
Bancos de dados adicionais para o SharePoint Server 2010 Enterprise Edition |
PerformancePoint |
Bancos de dados adicionais para o Project Server 2010 |
Rascunho Publicado Arquivo morto Relatórios |
Bancos de dados adicionais para o FAST Search Server |
Administração de pesquisa |
Se você estiver fazendo uma integração mais completa com o SQL Server, seu ambiente também poderá inclui bancos de dados adicionais, como ocorre nos seguintes cenários:
O Microsoft SQL Server 2008 R2 PowerPivot para Microsoft SharePoint 2010 pode ser usado em um ambiente do SharePoint Server 2010 que inclua o SQL Server 2008 R2 Enterprise Edition e o SQL Server Analysis Services. Se estiver em uso, você também deverá planejar o suporte para o banco de dados do aplicativo PowerPivot e a carga adicional no sistema. Para saber mais, consulte Planejar uma implantação do PowerPivot em um farm do SharePoint (https://msdn.microsoft.com/pt-br/library/ee210603(SQL.105).aspx).
O plug-in do Microsoft SQL Server 2008 Reporting Services (SSRS) pode ser usado com qualquer ambiente dos Produtos do SharePoint 2010. Se estiver usando o plug-in, planeje oferecer suporte para os dois bancos de dados do SQL Server 2008 Reporting Services e para a carga adicional necessária para o SQL Server 2008 Reporting Services.
Conhecer o SQL Server e o IOPS
Em qualquer servidor que hospede o SQL Server, é muito importante que o servidor obtenha a resposta mais rápida possível do subsistema de E/S.
Uma quantidade maior de discos ou matrizes mais rápidos fornecem IOPS (operações de E/S por segundo) suficientes, embora mantendo baixa latência e enfileiramento em todos os discos.
Uma baixa resposta do subsistema de E/S não pode ser compensada pela inclusão de outros tipos de recursos, como CPU ou memória; no entanto, ela pode influenciar e causar problemas para todo o farm. Planeje uma latência mínima antes da implantação e monitore os sistemas existentes.
Antes de implantar um novo farm, recomendamos que você faça submeta o subsistema de E/S a benchmarking usando a ferramenta de benchmarking de subsistema de disco SQLIO. Para obter detalhes, consulte Ferramenta de benchmarking de subsistema de disco SQLIO (https://go.microsoft.com/fwlink/p/?LinkID=105586).
Para obter informações detalhadas sobre como analisar os requisitos de IOPS do ponto de vista do SQL Server, consulte o documento sobre como analisar características de E/S e dimensionar sistemas de armazenamento para aplicativos de bancos de dados do SQL Server (https://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx).
Estimar as necessidades de IOPS e armazenamento central
O armazenamento da configuração e do conteúdo e as IOPS são a camada básica que você deve planejar em todas as implantações do SharePoint Server 2010.
Armazenamento de configuração e IOPS
Os requisitos de armazenamento para o banco de dados de Configuração e o banco de dados de conteúdo da Administração Central não são grandes. É recomendável alocar 2 GB para o banco de dados de Configuração e 1 GB para o banco de dados de conteúdo da Administração Central. Com o tempo, o banco de dados de Configuração pode crescer e passar de 1 GB, mas isso não acontece rapidamente — ele cresce aproximadamente 40 MB para cada 50 mil conjuntos de sites.
Os logs de transação do banco de dados de Configuração podem ser grandes. É recomendável, portanto, que você altere o modelo de recuperação do banco de dados de completo para simples.
Observação
Se desejar usar o espelhamento do banco de dados do SQL Server para fornecer disponibilidade para o banco de dados de Configuração, você deverá usar o modelo de recuperação completo.
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 das IOPS necessárias para bancos de dados de conteúdo não é uma atividade precisa. Ao testar e explicar as informações a seguir, pretendemos ajudar você a obter estimativas a serem usadas para determinar o tamanho inicial da sua implantação. No entanto, quando seu ambiente estiver em execução, esperamos que você recalcule suas necessidades de capacidade com base nos dados do ambiente real.
Para obter mais informações sobre nossa metodologia geral de planejamento de capacidade, consulte Capacity management and sizing for SharePoint Server 2010.
Estimar o armazenamento do banco de dados de conteúdo
O seguinte processo descreve como estimar de modo aproximado o armazenamento necessário para bancos de dados de conteúdo, sem considerar os arquivos de log:
Calcule o número esperado de documentos. Esse valor é expresso na fórmula como D.
A forma de cálculo do número de documentos será determinada pelos recursos que você estiver usando. Por exemplo, para Meus Sites ou sites de colaboração, é recomendável calcular o número esperado de documentos por usuário e multiplicar esse valor pelo número de usuários. Para sites de gerenciamento de registros ou de publicação de conteúdo, você pode calcular o número de documentos gerenciados e gerados por um processo.
Se você estiver migrando de um sistema atual, talvez seja mais fácil extrapolar o uso e a taxa de crescimento atual. Se estiver criando um novo sistema, avalie os compartilhamentos de arquivos existentes ou outros repositórios e faça a estimativa com base nessa taxa de uso.
Estime o tamanho médio dos documentos que você armazenará. Esse valor é referido como S na fórmula. Talvez seja conveniente estimar médias para diferentes tipos ou grupos de sites. O tamanho médio do arquivo para Meus Sites, repositórios de mídia e diferentes portais de departamentos pode variar significativamente.
Estime o número de itens da lista no ambiente. Esse valor é expresso na fórmula como L.
É mais difícil estimar itens da lista do que documentos. Geralmente usamos uma estimativa equivalente a três vezes o número de documentos (D), mas isso varia com base em como você espera usar 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 geralmente será muito menor do que o número máximo permitido de versões). Esse valor é expresso na fórmula como V.
O valor de V deve ser maior do que zero.
Use a seguinte fórmula para estimar o tamanho de seus bancos de dados de conteúdo:
Tamanho do banco de dados = ((D × V) × S) + (10 KB × (L + (V × D)))
O valor de 10 KB na fórmula é uma constante que estima aproximadamente a quantidade de metadados exigidos pelo SharePoint Server 2010. Se o seu sistema exigir o uso significativo de metadados, convém aumentar essa constante.
Como exemplo, se você pretendesse usar a fórmula para estimar a quantidade de espaço de armazenamento necessário para os arquivos de dados de um banco de dados de conteúdo em um ambiente de colaboração com as características a seguir, seriam necessários aproximadamente 105 GB.
| Entrada | Valor |
|---|---|
Número de documentos (D) |
200.000 Calculado como 10.000 usuários vezes 20 documentos |
Tamanho médio dos documentos (S) |
250 KB |
Itens da lista (L) |
600.000 |
Número de versões não atuais (V) |
2 Presumindo que o máximo permitido de versões é 10 |
Tamanho do banco de dados = (((200.000 x 2)) × 250) + ((10 KB × (600.000 + (200.000 x 2))) = 110.000.000 KB ou 105 GB
Recursos que afetam o tamanho dos bancos de dados de conteúdo
O uso dos seguintes recursos do SharePoint Server 2010 pode afetar significativamente o tamanho dos bancos de dados de conteúdo:
Lixeiras Enquanto um documento não for totalmente excluído das lixeiras de primeiro e 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 das lixeiras no tamanho dos bancos de dados de conteúdo. Para obter mais informações, consulte Definir configurações da Lixeira (SharePoint Server 2010).
Auditoria Os dados de auditoria podem compor e usar grandes quantidades de espaço em um banco de dados de conteúdo, especialmente se a auditoria de exibição estiver ativada. Em vez de permitir que os dados de auditoria se expandam sem limite, recomendamos que você habilite apenas a auditoria dos eventos que sejam importantes para cumprir requisitos regulatórios ou para controles internos. Use as seguintes diretrizes para estimar o espaço que precisará reservar para dados de auditoria:
Estime o número de novas entradas de auditoria para um site e multiplique esse número por 2 KB (as entradas geralmente estão limitadas a 4 KB, com um tamanho médio aproximado de 1 KB).
Com base no espaço que você deseja alocar, determine o número de dias de logs de auditoria que deseja manter.
Office Web Apps. Se o Office Web Apps estiver sendo usado, o cache do Office Web Apps poderá afetar significativamente o tamanho de um banco de dados de conteúdo. Por padrão, o cache do Office Web Apps é configurado como 100 GB. Para obter mais informações sobre o tamanho do cache do Office Web Apps, consulte Gerenciar o cache do Office Web Apps.
Estimar os requisitos de IOPS do banco de dados de conteúdo
Os requisitos de IOPS para bancos de dados de conteúdo variam muito de acordo com o modo como o seu ambiente está sendo usado e com a quantidade existente de espaço em disco e servidores. Em geral, é recomendável comparar a carga de trabalho prevista em seu ambiente com uma das soluções testadas. Para obter mais informações, consulte Recomendações e resultados de testes de desempenho e capacidade (SharePoint Server 2010).
Importante
O teste do conteúdo desta seção ainda não foi concluído. Verifique a existência de informações adicionais.
Estimar necessidades de armazenamento do aplicativo de serviço e IOPS
Depois de estimar as necessidades de armazenamento de conteúdo e de IOPS, você deverá determinar o armazenamento e as IOPS exigidas pelos aplicativos de serviço que estão sendo usados em seu ambiente.
Requisitos de IOPS e armazenamento de aplicativos de serviço do SharePoint Server 2010
Para estimar os requisitos de armazenamento dos aplicativos de serviço no sistema, primeiro você deve conhecer os aplicativos de serviço e saber como usá-los. Os aplicativos de serviço disponíveis no SharePoint Server 2010 que têm bancos de dados são listados na tabela a seguir.
| Aplicativo de serviço | Recomendação de estimativa de tamanho | ||||||||
|---|---|---|---|---|---|---|---|---|---|
Pesquisa |
A Pesquisa exige três bancos de dados. Seu ambiente pode incluir vários bancos de dados de Propriedade e Rastreamento. O banco de dados de administração de Pesquisa geralmente é pequeno: aloque 10 GB. Para estimar o armazenamento necessário para seus bancos de dados de Propriedade e Rastreamento, use os seguintes multiplicadores:
Os requisitos de IOPS para Pesquisa são significativos.
Para obter informações detalhadas sobre como estimar a capacidade necessária para Pesquisa, consulte Recomendações e resultados de testes de desempenho e capacidade (SharePoint Server 2010). O FAST Search Server 2010 for SharePoint tem uma arquitetura diferente. O banco de dados Rastreamento tem os mesmos requisitos do IOPS, mas o banco de dados Propriedade é usado somente para pesquisa de pessoas. Também há um banco de dados de administração Pesquisa adicional. Para saber mais sobre o FAST Search Server 2010 para o SharePoint, consulte Planejar topologia de farm (FAST Search Server 2010 para SharePoint) (traduzido por máquina) e Performance and capacity management (FAST Search Server 2010 for SharePoint). |
||||||||
Perfil do Usuário |
O aplicativo de serviço do Perfil do Usuário está associado a três bancos de dados: Perfil, Sincronização e Marcação Social. Para estimar o armazenamento necessário para os bancos de dados, use as seguintes informações:
Em um ambiente de colaboração dinâmica com 160.000 perfis de usuários, cinco grupos, 79.000 marcas, comentários e classificações (2.500 comentários, 76.000 marcas e 800 classificações) e configurações padrão, temos os seguintes tamanhos para esses bancos de dados:
|
||||||||
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 palavras-chave usados no sistema. Muitos ambientes incluirão várias instâncias do aplicativo de serviço Metadados Gerenciados. |
||||||||
Web Analytics |
O Web Analytics tem dois bancos de dados: Preparo e Relatórios. Muitos fatores influenciam o tamanho dos bancos de dados. Entre eles, estão o período de retenção, o volume diário de dados rastreados e o número de conjuntos de sites, sites e subsites no aplicativo Web que está sendo analisado. Para obter informações detalhadas sobre como estimar seus requisitos de tamanho e IOPS, consulte Recomendações e resultados de testes de desempenho e capacidade (SharePoint Server 2010). |
||||||||
Repositório seguro |
O tamanho do banco de dados do aplicativo de serviço de Repositório Seguro é determinado pelo número de credenciais no repositório e pelo número de entradas na tabela de auditoria. É recomendável alocar 5 MB para cada 1.000 credenciais para ele. A necessidade de IOPS é mínima. |
||||||||
Estado |
O aplicativo de serviço de Controle de Sessão tem um banco de dados. É recomendável alocar 1 GB para ele. A necessidade de IOPS é mínima. |
||||||||
Serviço Word Automation |
O aplicativo de serviço Word Automation tem um banco de dados. É recomendável alocar 1 GB para ele. A necessidade de IOPS é mínima. |
||||||||
PerformancePoint |
O aplicativo de serviço PerformancePoint tem um banco de dados. É recomendável alocar 1 GB para ele. A necessidade de IOPS é mínima. |
Determinar as necessidades de disponibilidade
A disponibilidade é um grau pelo qual um ambiente do SharePoint Server 2010 é percebido por usuários como disponível. Um sistema disponível é um sistema flexível — ou seja, incidentes que afetem o serviço ocorrem com pouca frequência e ações oportunas e eficientes são tomadas quando eles ocorrem.
Os requisitos de disponibilidade podem aumentar significativamente suas necessidades de armazenamento. Para obter informações detalhadas, consulte Planejar a disponibilidade (SharePoint Server 2010).
Escolher a versão e a edição do SQL Server
Embora o Produtos do SharePoint 2010 possa ser executado no Microsoft SQL Server 2008 R2, SQL Server 2008 ou no SQL Server 2005, é altamente recomendável que você considere a possibilidade de executar seu ambiente na Enterprise Edition do SQL Server 2008 ou do SQL Server 2008 R2 para aproveitar os recursos adicionais de desempenho, disponibilidade, segurança e gerenciamento por ela fornecidos. Para obter mais informações sobre os benefícios de usar o SQL Server 2008 R2 Enterprise Edition, consulte SQL Server 2008 R2 e Produtos do SharePoint 2010: melhores juntos (white paper) (SharePoint Server 2010).
Você deve avaliar especialmente sua necessidade dos seguintes recursos:
Compactação de backup A compactação de backup pode acelerar qualquer backup do SharePoint e está disponível no SQL Server 2008 Enterprise Edition ou no SQL Server 2008 R2 Standard Edition. Ao configurar a opção de compactação no seu script de backup, ou ao configurar o servidor que está executando o SQL Server para compactar por padrão, você pode reduzir significativamente o tamanho dos seus backups de banco de dados e logs enviados. Para saber mais, consulte Compactação de Backup (SQL Server) (https://msdn.microsoft.com/pt-br/library/bb964719(SQL.105).aspx?amp;clcid=0x409).
Observação
A compactação de dados do SQL Server não tem suporte nos Produtos do SharePoint 2010, exceto nos bancos de dados de aplicativos de serviço de pesquisa.
Criptografia de dados transparente Se os seus requisitos de segurança incluírem a necessidade de criptografia de dados transparente, você deverá usar o SQL Server Enterprise Edition.
Aplicativo de serviço do Web Analytics Se você planeja usar o aplicativo de serviço do Web Analytics para análise significativa, avalie o uso do SQL Server Enterprise Edition para que o sistema se beneficie do particionamento de tabelas.
Implantação de conteúdo Se você planeja usar o recurso de implantação de conteúdo, avalie o uso do SQL Server Enterprise Edition para que o sistema se beneficie dos instantâneos do banco de dados do SQL Server.
Remote BLOB storage Se você quiser aproveitar o remote BLOB storage em um banco de dados ou local fora dos arquivos associados a cada banco de dados de conteúdo, use o SQL Server 2008 ou o SQL Server 2008 R2 Enterprise Edition.
Administrador de Recursos O Administrador de Recursos é uma tecnologia introduzida no SQL Server 2008 que permite a você gerenciar cargas de trabalho e recursos do SQL Server especificando limites no consumo de recursos por meio de solicitações de entrada. O Administrador de Recursos permite que você diferencie cargas de trabalho e aloque CPU e memória conforme solicitado, com base nos limites que você especificar. Ele está disponível somente no SQL Server 2008 ou na edição SQL Server 2008 R2 Enterprise. Para saber mais sobre como usar o Administrador de Recursos, consulte Gerenciar cargas de trabalho do SQL Server com o Administrador de Recursos.
É recomendável usar o Administrador de Recursos com o SharePoint Server 2010 para:
Limitar a quantidade de recursos do SQL Server consumida pelos servidores Web visados pelo componente de rastreamento de pesquisa. Como prática recomendada, limite o componente de rastreamento a dez por cento da CPU quando o sistema estiver sobrecarregado.
Monitorar quantos recursos cada banco de dados consome no sistema — por exemplo, você pode usar o Administrador de Recursos para ajudar a determinar a melhor colocação de bancos de dados entre computadores que estão executando o SQL Server.
PowerPivot para SharePoint 2010 Permite que os usuários compartilhem análises e modelos de dados gerados por usuários e colaborem neles no Excel e no navegador enquanto atualiza automaticamente essas análises. Faz parte do SQL Server 2008 R2 Enterprise Edition Analysis Services.
Projetar a arquitetura de armazenamento com base em requisitos de capacidade e 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
Escolher tipos de disco
Escolher tipos de RAID
Escolher uma arquitetura de armazenamento
Há suporte para as arquiteturas de armazenamento DAS (armazenamento de conexão direta), SAN (rede de área de armazenamento) e NAS (armazenamento conectado à rede) com o SharePoint Server 2010, mas o suporte para NAS se restringe apenas ao uso com bancos de dados de conteúdo configurados para utilizar remote BLOB storage. Sua escolha depende de fatores da sua solução de negócios e da sua infraestrutura existente.
Qualquer arquitetura de armazenamento deve dar suporte para suas necessidades de disponibilidade e ter um desempenho adequado em IOPS e latência. Para ter suporte, o sistema deve retornar de modo consistente o primeiro byte de dados dentro 20 milissegundos (ms).
DAS (armazenamento de conexão direta)
O DAS é um sistema de armazenamento digital diretamente conectado a um servidor ou a uma estação de trabalho, sem uma rede de armazenamento intermediária. Os tipos de disco físico DAS incluem SAS (Serial Attached SCSI) e SATA (Serial Attached ATA).
Em geral, é recomendável que você escolha uma arquitetura DAS quando uma plataforma de armazenamento compartilhada não possa assegurar um tempo de resposta de 20 ms e capacidade suficiente para IOPS médio e máximo.
SAN (rede de área de armazenamento)
A SAN é uma arquitetura para conectar dispositivos remotos de armazenamento de computador (como matrizes de discos e bibliotecas de fitas) a servidores de um modo que os dispositivos sejam exibidos como conectados localmente ao sistema operacional (por exemplo, armazenamento em bloco).
Em geral, é recomendável escolher uma SAN quando os benefícios do armazenamento compartilhado sejam importantes para a sua organização.
Estes são alguns benefícios do armazenamento compartilhado:
Realocação mais fácil de armazenamento em disco entre servidores.
Pode atender a vários servidores.
Nenhuma limitação de número de discos que podem ser acessados.
NAS (armazenamento conectado à rede)
Uma unidade de NAS é um computador autônomo conectado a uma rede. Seu único objetivo é fornecer serviços de armazenamento de dados baseados em arquivos para outros dispositivos na rede. O sistema operacional e outros softwares na unidade de NAS fornecem a funcionalidade do armazenamento de dados, sistemas de arquivos e acesso a arquivos, bem como o gerenciamento dessas funcionalidades (por exemplo, armazenamento de arquivos).
Observação
O suporte para NAS se restringe apenas ao uso com bancos de dados de conteúdo configurados para utilizar remote BLOB storage. Qualquer arquitetura de armazenamento de rede deve responder a um ping dentro de 1 ms e deve retornar o primeiro byte de dados em 20 ms. Essa restrição não se aplica ao provedor FILESTREAM local do SQL Server porque ele apenas armazena dados localmente no mesmo servidor.
Escolher tipos de disco
Os tipos de disco usados no sistema podem afetar a confiabilidade e o desempenho. Com todos os outros fatores inalterados, unidades maiores aumentam o tempo médio de busca. O SharePoint Server 2010 dá suporte aos seguintes tipos de unidades:
SCSI
SATA
SAS
FC
Interface IDE
Unidade de estado sólido ou Disco Flash
Escolher tipos de RAID
O RAID (Redundant Array of Independent Disks) é usado geralmente para melhor as características de desempenho de discos individuais (por meio da distribuição de dados por vários discos) e para fornecer proteção contra falhas de disco individuais.
Todos os tipos de RAID dão suporte ao SharePoint Server 2010; no entanto, é recomendável usar o RAID 10 ou uma solução de RAID específica de um fornecedor com desempenho equivalente.
Ao configurar uma matriz RAID, certifique-se de alinhar o sistema de arquivos ao deslocamento que é dado pelo fornecedor. Na ausência de orientações do fornecedor, consulte as Práticas recomendadas de E/S de pré-implementação do SQL Server (https://go.microsoft.com/fwlink/p/?LinkID=105583).
Para saber mais sobre como provisionar o RAID e o subsistema de E/S do SQL Server, consulte Artigo sobre práticas recomendadas do SQL Server (https://go.microsoft.com/fwlink/p/?LinkId=168612).
Estimar requisitos de memória
A memória necessária para o SharePoint Server 2010 está diretamente relacionada ao tamanho dos bancos de dados de conteúdo hospedados em um servidor que executa o SQL Server.
À medida que você adiciona aplicativos de serviço e recursos, seus requisitos tendem a crescer. A tabela a seguir dá diretrizes sobre a quantidade de memória recomendável.
Observação
As nossas definições de implantações pequenas e médias são descritas na seção Arquiteturas de referência do artigo Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server 2010.
| Tamanho combinado de bancos de dados de conteúdo | RAM recomendada para computadores que executam o SQL Server |
|---|---|
Mínimo para pequenas implantações de produção |
8 GB |
Mínimo para médias implantações de produção |
16 GB |
Recomendação para até 2 terabytes |
32 GB |
Recomendação para o intervalo de 2 terabytes a 5 terabytes |
64 GB |
Recomendação para mais de 5 terabytes |
RAM adicional acima de 64 GB pode melhorar 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 2010. Para saber mais sobre os requisitos de sistema do SQL Server, consulte Requisitos de hardware e software para instalar o SQL Server 2008 (https://msdn.microsoft.com/pt-br/library/ms143506.aspx).
Estes são alguns dos outros fatores que podem influenciar a memória exigida:
O uso de espelhamento do SQL Server.
O uso frequente de arquivos maiores do que 15 megabytes (MB).
Entender os requisitos de topologia de rede
Planeje as conexões de rede dentro dos farms e entre eles. É recomendável usar uma rede de baixa latência.
A lista a seguir fornece algumas práticas recomendadas:
Todos os servidores no farm devem ter largura de banda e latência de LAN para o servidor que está executando o SQL Server. A latência não deve ser maior que 1 ms.
Não é recomendável uma topologia de WAN (rede de longa distância) em que um servidor que esteja executando o SQL Server seja implantado remotamente de outros componentes do farm através de uma rede com latência maior do que 1 ms. Essa topologia não foi testada.
Planeje uma rede WAN adequada se estiver planejando usar o espelhamento do SQL Server ou o envio de logs para manter um site remoto atualizado.
É recomendável que os servidores Web e os servidores de aplicativos tenham dois adaptadores de rede: um para gerenciar o tráfego do usuário final e o outro para gerenciar a comunicação com os servidores que executam o SQL Server.
Configurar o SQL Server
As seções a seguir descrevem como planejar a configuração do SQL Server para o SharePoint Server 2010.
Nesta seção:
Determinar quantas instâncias ou servidores são necessários
Configurar o armazenamento e a memória
Definir opções do SQL Server
Configurar bancos de dados
Estimar quantos servidores são necessários
Em geral, o SharePoint Server 2010 é designado para aproveitar o dimensionamento do SQL Server — ou seja, o SharePoint Server 2010 pode ter um desempenho melhor com um grande número de servidores de médio porte que executam o SQL Server do que com apenas alguns grandes servidores.
Sempre coloque o SQL Server em um servidor dedicado que não esteja executando qualquer outra função de farm ou hospedando bancos de dados de qualquer outro aplicativo, a menos que você esteja implantando o sistema em um servidor autônomo.
A seguir, é apresentada uma orientação geral sobre quando implantar um servidor adicional para executar o SQL Server:
Adicione outro servidor de banco de dados quando tiver mais de quatro servidores Web que estejam sendo executados em plena capacidade.
Adicione outro servidor de banco de dados quando o seu servidor atual tiver alcançado os limites efetivos de RAM, de CPU, de taxa de transferência de E/S de disco, de capacidade de disco ou de taxa de transferência de rede.
Observação
A Microsoft dá suporte a configurações de servidor que não seguem esta orientação.
Para promover o armazenamento seguro de credenciais quando estiver executando o aplicativo de serviço Repositório Seguro, é recomendável que o banco de dados de repositório seguro esteja hospedado em uma instância separada de banco de dados em que o acesso seja limitado a um administrador.
Configurar o armazenamento e a memória
No servidor que está executando o SQL Server 2008, é recomendável que o cache L2 por CPU tenha um mínimo de 2 MB para melhorar a memória.
Siga as recomendações de configuração de armazenamento do fornecedor
Para obter um desempenho ideal ao configurar uma matriz de armazenamento física, siga as recomendações de configuração de hardware informadas pelo fornecedor de armazenamento, em vez de adotar os valores padrão do sistema operacional.
Se você não tiver orientações do seu fornecedor, recomendamos que use o utilitário de configuração de disco DiskPart.exe para configurar o armazenamento para o SQL Server 2008. Para saber mais, consulte Práticas recomendadas de E/S de pré-implantação (https://go.microsoft.com/fwlink/p/?LinkID=105583).
Forneça o máximo de recursos possível
Verifique se os canais de E/S do SQL Server para os discos não são compartilhados por outros aplicativos, como o arquivo de paginação e os logs do IIS (Serviços de Informações da Internet).
Forneça o máximo possível de banda larga. Maior banda larga de barramento ajuda a melhorar a confiabilidade e o desempenho. Lembre-se de que o disco não é o único usuário da banda larga de barramento — por exemplo, você também deve considerar o acesso à rede.
Definir opções do SQL Server
As seguintes configurações e opções do SQL Server devem ser definidas antes da implantação do SharePoint Server.
Não habilite estatísticas de criação automática em um SQL Server que dê suporte ao SharePoint Server. O SharePoint Server define as configurações necessárias sobre provisionamento e atualização. As estatísticas de criação automática podem alterar significativamente o plano de execução de uma consulta de uma instância do SQL Server para outra instância do SQL Server. Portanto, para dar suporte consistente a todos os clientes, o SharePoint Server fornece dicas codificadas para consultas, quando necessário, para proporcionar o melhor desempenho em todos os cenários.
Para garantir o desempenho máximo, recomendamos que você defina o nível máximo de paralelismo (MAXDOP) como uma instância do SQL Server que hospede bancos de dados do SharePoint Server 2010. Para saber mais sobre como definir o nível máximo de paralelismo, consulte Opção nível máximo de paralelismo (https://go.microsoft.com/fwlink/p/?LinkId=189030).
Para aumentar a facilidade de manutenção, configure os aliases de conexão com o SQL Server para cada servidor de banco de dados no seu farm. Um alias de conexão é um nome alternativo que pode ser usado para conectar a uma instância do SQL Server. Para saber mais, consulte Tutorial: Definir um alias do SQL Server (SQL Server Management Studio) (https://msdn.microsoft.com/pt-br/library/ms175176.aspx?amp;clcid=0x409).
Configurar bancos de dados
As orientações a seguir descrevem práticas recomendadas de planejamento na configuração de cada banco de dados em seu ambiente.
Separe e priorize seus dados em discos
De modo ideal, você deve colocar o banco de dados tempdb, os bancos de dados de conteúdo, o banco de dados de Uso, os bancos de dados de pesquisa e os logs de transações do SQL Server 2008 em discos rígidos separados.
A lista a seguir fornece algumas práticas recomendadas de priorização de dados:
Ao priorizar dados em discos mais rápidos, use a seguinte classificação:
Arquivos de dados tempdb e logs de transações
Arquivos de log de transações do banco de dados
Bancos de dados de pesquisa, com exceção do banco de dados de administração de Pesquisa
Arquivos de dados de banco de dados
Em um site de portal fortemente orientado à leitura, priorize dados em relação a logs.
Testes e dados de clientes mostram que o desempenho de farms do SharePoint Server 2010 pode ser muito prejudicado por E/S insuficiente de disco para o tempdb. Para evitar esse problema, aloque discos dedicados para o tempdb. Se uma alta carga de trabalho estiver projetada ou monitorada — ou seja, a operação de leitura média ou a operação de gravação média exigir mais do que 20 ms — talvez você precise reduzir o afunilamento separando os arquivos em discos ou substituindo os discos por outros mais rápidos.
Para obter o melhor desempenho, coloque o tempdb em uma matriz RAID 10. O número de arquivos de dados tempdb deve ser igual ao número de CPUs, e os arquivos de dados tempdb devem ser definidos com o mesmo tamanho. Conte processadores de núcleo duplo como dois CPUs para este propósito. Conte cada processador que ofereça suporte a hyper-threading como um único CPU. Para saber mais, consulte Otimizar o desempenho do tempdb (https://msdn.microsoft.com/pt-br/library/ms175527.aspx).
Separe dados de banco de dados e arquivos de log de transações em diferentes discos. Se os arquivos precisarem compartilhar discos porque os arquivos são muito pequenos para justificar o uso de um disco inteiro ou de uma faixa inteira, ou se faltar espaço em disco, coloque os arquivos que têm padrões de uso diferentes no mesmo disco para minimizar solicitações de acesso simultâneo.
Consulte o fornecedor do seu hardware de repositório para obter informações sobre como configurar todos os logs e os bancos de dados de pesquisa a fim de otimizar a gravação em sua solução de repositório específica.
Use vários arquivos de dados para bancos de dados de conteúdo
Siga estas recomendações para melhorar o desempenho:
Crie apenas arquivos no grupo de arquivos primário do banco de dados.
Distribua os arquivos por discos separados.
O número de arquivos de dados deve ser menor ou igual ao número de núcleos de CPUs. Conte processadores de núcleo duplo como duas CPUs para essa finalidade. Conte cada processador que dê suporte a hyperthreading como uma CPU.
Crie arquivos de dados de mesmo tamanho.
Importante
Embora você possa usar as ferramentas de backup e recuperação internas do SharePoint Server 2010 para fazer backup e recuperar vários arquivos de dados, se você substituí-los no mesmo local, as ferramentas não poderão restaurar vários arquivos de dados em um local diferente. Por esse motivo, é altamente recomendável que, ao usar vários arquivos de dados para um banco de dados de conteúdo, você use as ferramentas de backup e recuperação do SQL Server. Para obter mais informações sobre como fazer backup e recuperar o SharePoint Server 2010, consulte Plano de backup e recuperação no SharePoint Server 2010.
Para saber mais sobre como criar e gerenciar grupos de arquivos, consulte Grupos de arquivos e arquivos de bancos de dados físicos (https://technet.microsoft.com/pt-br/library/ms179316.aspx).
Limite 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 os cenários e condições de uso específicas ofereçam suporte a tamanhos maiores. Para saber mais sobre limites de tamanho de bancos de dados de conteúdo, consulte a seção Limites de bancos de dados de conteúdo em Gerenciamento de capacidade do SharePoint Server 2010: Limites de software.
Normalmente recomendamos que um conjunto de sites não exceda 100 GB, a menos que seja o único conjunto de sites no banco de dados, para que você possa usar as ferramentas de backup granular do SharePoint Server 2010 para mover um conjunto de sites para outro banco de dados, caso seja necessário.
Para saber mais sobre repositórios de documentos de larga escala, consulte "Estimar os requisitos de desempenho e de capacidade para repositórios de documentos de larga escala", disponível nas Recomendações e resultados de testes de desempenho e capacidade (SharePoint Server 2010).
Gerencie de modo proativo o crescimento dos arquivos de dados e log
É recomendável gerenciar de maneira proativa o crescimento dos arquivos de dados e log, considerando as seguintes recomendações:
Sempre que possível, expanda previamente todos os arquivos de dados e log para seu tamanho final previsto.
É recomendável habilitar o aumento automático por razões de segurança. Não confie nas configurações padrão de aumento automático. Leve em conta as seguintes diretrizes ao configurar o aumento automático:
Quando planejar bancos de dados de conteúdo que ultrapassem o tamanho recomendado (200 GB), defina o valor de aumento automático do banco de dados para um número fixo de megabytes, e não para uma porcentagem. Isso reduz a frequência com que o SQL Server aumenta o tamanho de um arquivo. Aumentar o tamanho do arquivo é uma operação de bloqueio que envolve o preenchimento do novo espaço com páginas vazias.
Defina o valor de aumento automático para o banco de dados de Repositório de Propriedades do aplicativo de serviço de Pesquisa como 10 por cento.
Se não houver previsão de que o tamanho calculado do banco de dados de conteúdo alcance o tamanho máximo recomendado de 200 GB dentro de um ano, defina-o como o tamanho máximo que o banco de dados deve alcançar em um ano (com 20% de margem adicional de erro) usando a propriedade ALTER DATABASE MAXSIZE. Revise periodicamente essa configuração para verificar se ela ainda tem um valor adequado com base nas taxas de crescimento anteriores.
Mantenha um nível de pelo menos 25 por cento de espaço disponível nos discos para estabelecer padrões de crescimento e uso máximo. Se você estiver gerenciando o crescimento por meio da inclusão de discos em uma matriz RAID ou da alocação de mais armazenamento, monitore o tamanho do disco cuidadosamente para evitar ficar sem espaço.
Validar e monitorar o desempenho do armazenamento e do SQL Server
Teste se a solução de desempenho e backup do seu hardware permite que você cumpra seus SLAs (contratos de nível de serviço). Teste especificamente o subsistema de E/S do computador que está executando o SQL Server para garantir que o desempenho seja satisfatório.
Teste a solução de backup que você está usando para garantir que ela possa fazer backup do sistema dentro da janela de manutenção disponível. Se a solução de backup não puder atender aos SLAs exigidos por seu negócio, avalie a possibilidade de usar uma solução de backup incremental, como o System Center Data Protection Manager (DPM) 2010.
É importante manter registro dos seguintes componentes de recursos de um servidor que execute o SQL Server: CPU, memória, taxa de cache/ocorrências e subsistema de E/S. Quando um ou mais dos componentes parecer lento ou sobrecarregado, analise a estratégia apropriada com base na carga de trabalho atual e projetada. Para saber mais, consulte Solucionando problemas de desempenho no SQL Server 2008 (https://go.microsoft.com/fwlink/p/?LinkID=168448).
A seção a seguir relaciona os contadores de desempenho de uso recomendado para monitorar o desempenho dos bancos de dados do SQL Server que estão sendo executados em seu ambiente do SharePoint Server 2010. Também estão descritos valores aproximados de integridade para cada contador.
Para saber mais sobre como monitorar o desempenho e usar contadores de desempenho, consulte Monitorando o desempenho (https://technet.microsoft.com/pt-br/library/dd744567(WS.10).aspx?amp;clcid=0x416).
Contadores do SQL Server a serem monitorados
Monitore os seguintes contadores do SQL Server para garantir a integridade de seus servidores:
Estatísticas gerais Este objeto fornece contadores para monitorar a atividade geral em todo o servidor, como o número de conexões atuais e o número de usuários que se conectam e desconectam por segundo de computadores que executam uma instância do SQL Server. Avalie a possibilidade de monitorar o seguinte contador:
- Conexões de usuário Este contador mostra a quantidade de conexões de usuário no seu computador que executa o SQL Server. Se você vir esse número crescer 500 por cento em relação à linha de base, talvez experimente uma redução do desempenho.
Bancos de dados Este objeto fornece contadores para monitorar operações de cópia em massa, produtividade de backup e restauração e atividades de log de transações. Monitore as transações e o log de transações para determinar o volume de atividades dos usuários no banco de dados e o quanto o log de transações está ficando cheio. O volume de atividades dos usuários pode determinar o desempenho do banco de dados e afetar o tamanho do log, o bloqueio e a replicação. Monitorar a atividade de log de baixo nível para medir a atividade dos usuários e o uso de recursos pode ajudar você a identificar afunilamentos de desempenho. Avalie a possibilidade de monitorar o seguinte contador:
- Transações/s Este contador mostra a quantidade de transações por segundo em um determinado banco de dados ou no servidor inteiro. Esse número é mais para a sua linha de base e para ajudar você a solucionar problemas.
Bloqueios Este objeto fornece informações sobre bloqueios do SQL Server em tipos de recursos individuais. Avalie a possibilidade de monitorar os seguintes contadores:
Tempo de Espera Médio (ms) Este contador mostra a quantidade média de tempo de espera para cada solicitação de bloqueio que resultou em uma espera.
Tempo de Espera de Bloqueio (ms) Este contador mostra o tempo de espera para bloqueios no último segundo.
Esperas de Bloqueio/s Este contador mostra o número de bloqueios por segundo que não puderam ser atendidos imediatamente e precisaram esperar recursos.
Número de deadlocks Este contador mostra o número de deadlocks por segundo no computador que executa o SQL Server. O valor não deve ser maior do que 0.
Travas Este objeto fornece contadores para monitorar bloqueios internos de recursos do SQL Server chamados travas. A monitoração de travas para determinar a atividade dos usuários e o uso de recursos pode ajudar você a identificar os afunilamentos de desempenho. Avalie a possibilidade de monitorar os seguintes contadores:
Tempo Médio de Espera de Trava (ms) Este contador mostra o tempo médio de espera de trava para solicitações de trava que precisaram esperar.
Esperas de Trava/s Este contador mostra o número de solicitações de trava que não puderam ser atendidas imediatamente.
Estatísticas SQL Este objeto fornece contadores para monitorar a compilação e o tipo de solicitações enviadas para uma instância do SQL Server. A monitoração do número de compilações e recompilações de consultas e do número de lotes recebidos por uma instância do SQL Server indica a rapidez com que o SQL Server está processando as consultas de usuários e a eficiência com que o otimizador de consulta está processando as consultas. Avalie a possibilidade de monitorar os seguintes contadores:
Compilações de SQL/s Este contador indica o número de vezes que o caminho de código de compilação é inserido por segundo.
Recompilações de SQL/s Este contador indica o número de recompilações da instrução por segundo.
Gerenciador de Buffer Este objeto fornece 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, bem como contadores para monitorar o E/S físico enquanto o SQL Server lê e grava páginas de banco de dados. Avalie a possibilidade de monitorar o seguinte contador:
Taxa de Acertos do Cache do Buffer
Este contador mostra a porcentagem de páginas encontradas no cache do buffer sem a necessidade de ler do disco. A taxa é o número total de acertos de cache dividido pelo número total de pesquisas de cache nos últimos mil acessos a páginas. Como ler do cache é muito mais caro do que ler do disco, convém que essa taxa seja alta. Geralmente, você pode aumentar a taxa de acertos do cache do buffer aumentando a quantidade de memória disponível para o SQL Server.
Cache de Planos Este objeto fornece contadores para monitorar como o SQL Server usa a memória para armazenar objetos como procedimentos armazenados, instruções Transact-SQL ad-hoc e preparadas e gatilhos. Avalie a possibilidade de monitorar o seguinte contador:
Taxa de Acertos do Cache
Este contador indica a taxa entre acertos e pesquisas de cache para planos.
Contadores do servidor físico a serem monitorados
Monitore os seguintes contadores para assegurar a integridade dos computadores que executam o SQL Server:
Processador: % Tempo do Processador: _Total Este contador mostra a porcentagem de tempo que o processador está executando processos do aplicativo ou do sistema operacional diferentes de Ocioso. No computador que estiver executando o SQL Server, esse contador deverá ficar entre 50 por cento e 75 por cento. No caso de sobrecarga constante, investigue se existe uma atividade anormal de processos ou se o servidor precisa de CPUs adicionais.
Sistema: Comprimento da Fila de Processador Este contador mostra o número de threads na fila do processador. Monitore este contador para assegurar que ele permaneça inferior ao dobro do número de núcleos de CPU.
Memória: Mbytes Disponíveis Este contador mostra a quantidade de memória física, em megabytes, disponível para processos executados no computador. Monitore este contador para assegurar a manutenção de um nível de pelo menos 20 por cento do total de RAM física disponível.
Memória: Páginas/s Este contador mostra a taxa em que as páginas são lidas do disco ou nele gravadas para resolver falhas de página de hardware. Monitore este contador para assegurar que ele permaneça abaixo de 100.
Para saber mais e descobrir os métodos de solução de problemas de memória, consulte Monitorando o uso de memória no SQL Server 2005 (https://msdn.microsoft.com/pt-br/library/ms176018.aspx).
Contadores de disco a serem monitorados
Monitore os seguintes contadores para assegurar a integridade dos discos. Observe que os seguintes valores são medidos ao longo do tempo — não são valores que ocorrem durante um pico repentino e não se baseiam em uma única medição.
Disco Físico: % Tempo de Disco: DataDrive Este contador mostra a porcentagem do tempo decorrido em que a unidade de disco selecionada está ocupada atendendo a solicitações de leitura ou gravação – é um indicador geral de como o disco está ocupado. Se o contador PhysicalDisk: % Tempo de Disco for alto (mais do que 90 por cento), verifique o contador PhysicalDisk: Comprimento da Fila de Disco Atual para ver quantas solicitações do sistema estão aguardando o acesso ao disco. O número de solicitações de E/S em espera deve ser mantido em não mais de 1,5 a 2 vezes o número de eixos que constituem o disco físico.
Disco Lógico: Transferências de Disco/s Este contador mostra a taxa em que são executadas as operações de leitura e gravação no disco. Use este contador para monitorar as tendências de crescimento e fazer previsões adequadamente.
Disco Lógico: Bytes de Leitura de Disco/s e Disco Lógico: Bytes de Gravação de Disco/s Estes contadores mostram a taxa em que os bytes são transferidos do disco durantes as operações de leitura e gravação.
Disco Lógico: Média de Bytes de Disco/Leitura Este contador mostra o número médio de bytes transferidos do disco durante as operações de leitura. Esse valor pode refletir a latência do disco — operações de leitura maiores podem resultar em latência ligeiramente maior.
Disco Lógico: Média de Bytes de Disco/Gravação Este contador mostra o número médio de bytes transferidos para o disco durante as operações de gravação. Esse valor pode refletir a latência do disco — operações de gravação maiores podem resultar em latência ligeiramente maior.
Disco Lógico: Comprimento da Fila de Disco Atual Este contador mostra o número de solicitações pendentes no disco no momento em que os dados de desempenho são coletados. Para este contador, valores menores são melhores. Valores maiores do que 2 por disco podem indicar um afunilamento e devem ser investigados. Isso significa que um valor até 8 é aceitável para uma LUN (unidade lógica) constituída de quatro discos. Os afunilamentos podem criar uma lista de pendências capaz de se difundir para além do servidor atual que está acessando o disco e provocar longos tempos de espera para os usuários. As possíveis soluções para um afunilamento são adicionar mais discos à matriz de RAID, substituir os discos existentes por discos mais rápidos ou mover alguns dados para outros discos.
Disco Lógico: Comprimento Médio da Fila de Disco Este 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 da amostra. A regra é que deve haver no máximo duas solicitações pendentes de leitura e gravação por eixo, mas isso pode ser difícil de medir por causa da virtualização do armazenamento e de diferenças em níveis de RAID entre configurações. Procure 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 da matriz de armazenamento está sendo superutilizado ou que o compartilhamento do eixo com outros aplicativos está afetando o desempenho.
Disco Lógico: Média de s/Leitura e Disco Lógico: Média de s/Escrita Esses contadores mostram o tempo médio, em segundos, de uma operação de leitura ou escrita no disco. Monitore esses contadores para garantir que eles permaneçam abaixo de 85 por cento da capacidade do disco. O tempo de acesso ao disco aumenta exponencialmente se as operações de leitura ou escrita ocuparem mais do que 85 por cento da capacidade do disco. Para determinar a capacidade específica do seu hardware, consulte a documentação de fornecedor ou use a Ferramenta de Benchmarking de Subsistema de Disco SQLIO para calculá-la. Para saber mais, consulte Ferramenta de benchmarking do subsistema de disco SQLIO (https://go.microsoft.com/fwlink/p/?LinkID=105586).
Disco Lógico: Média de Disco s/Leitura Este contador mostra o tempo médio, em segundos, de uma operação de leitura do disco. Em um sistema bem ajustado, os valores ideais vão de 1 a 5 ms para logs (idealmente 1 ms em uma matriz em cache) e de 4 a 20 ms para dados (idealmente menos do que 10 ms). Latências maiores podem ocorrer durante momentos de pico, mas se forem registrados valores maiores regularmente, você deverá investigar a causa.
Disco Lógico: Média de Disco s/Gravação Este contador mostra o tempo médio, em segundos, de uma operação de gravação no disco. Em um sistema bem ajustado, os valores ideais vão de 1 a 5 ms para logs (idealmente 1 ms em uma matriz em cache) e de 4 a 20 ms para dados (idealmente menos do que 10 ms). Latências maiores podem ocorrer durante momentos de pico, mas se forem registrados valores maiores regularmente, você deverá investigar a causa.
Quando você usar configurações de RAID com os contadores Disco Lógico: Média de Bytes de Disco/Leitura ou Disco Lógico: Média de Bytes de 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 × gravações)] / 2
RAID 5
E/Ss por disco = [leituras + (4 × gravações)] / número de discos
RAID 10
E/Ss por disco = [leituras + (2 × gravações)] / número de discos
Por exemplo, se você tiver um sistema RAID 1 com dois discos físicos, e seus contadores marcarem os valores mostrados na tabela a seguir.
Contador Valor Média de Disco s/Leitura
80
Disco Lógico: Média de Disco s/Gravação
70
Comprimento Médio da Fila de Disco
5
O valor de E/S por disco pode ser calculado da seguinte forma: (80 + (2 × 70))/2 = 110
O comprimento da fila de disco pode ser calculado da seguinte forma: 5/2 = 2,5
Nessa situação, você tem um afunilamento de E/S limítrofe.
Outras ferramentas de monitoração
Você também pode monitorar a latência de disco e analisar tendências usando o modo de exibição de gerenciamento dinâmico sys.dm_io_virtual_file_stats no SQL Server 2008. Para saber mais, consulte sys.dm_io_virtual_file_stats (Transact-SQL) (https://msdn.microsoft.com/pt-br/library/ms190326.aspx).
See Also
Other Resources
Central de Recursos: Gerenciamento de capacidades do SharePoint Server 2010
Central de Recursos: Bancos de dados do SQL Server e SharePoint Server 2010