Recomendações sobre armazenamento físico (Office SharePoint Server)

Atualizado em: 2010-04-29

Os discos e matrizes escolhidos — e o modo como você coloca os dados nesses discos e matrizes — pode afetar significativamente o desempenho do sistema. Se você não estiver familiarizado com Redundant Array of Independent Disks (RAID), consulte os seguintes recursos:

• Para obter uma introdução aos tipos de RAID usados com o Microsoft SQL Server 2008, consulte o artigo sobre níveis de RAID e SQL Server (https://go.microsoft.com/fwlink/?linkid=105581\&clcid=0x416).

• Para obter uma comparação dos níveis de RAID usados com o SQL Server 2008, consulte o artigo sobre comparação de diferentes implementações de níveis de RAID (https://go.microsoft.com/fwlink/?linkid=105582\&clcid=0x416).

Este tópico descreve primariamente o SQL Server 2008, embora também haja suporte para o Microsoft SQL Server 2005 e o Microsoft SQL Server 2000.

O uso de discos e matrizes RAID apropriados

A lista a seguir oferece algumas práticas recomendadas e orientações para a escolha do melhor nível de RAID e os discos rígidos:

• Discos ou matrizes em maior quantidade e com maior velocidade aprimoram o desempenho. A chave é manter baixa latência e enfileiramento em todos os discos.

• Para alta disponibilidade e desempenho (leitura/gravação aleatória), configure sua matriz para RAID 10.

• Consulte seu fornecedor ou a documentação do seu hardware de armazenamento antes de configurar matrizes RAID. Leve em conta se um banco de dados seria beneficiado com um menor tempo de resposta de leitura aleatória — por exemplo, para conteúdo da Web estático, em que RAID 5 e RAID 10 fornecem desempenho similar. Por outro lado, um menor tempo de resposta de gravação aleatória pode ser mais importante — por exemplo, em um site de colaboração com uso misto de leitura e gravação, em que RAID 10 tem a vantagem.

• Ao configurar uma matriz RAID, é crucial alinhar o sistema de arquivos ao deslocamento indicado pelo fornecedor. Na ausência de orientação do fornecedor, consulte o texto sobre Práticas recomendadas de E/S para pré-implantação do SQL Server (em inglês) (https://go.microsoft.com/fwlink/?linkid=105583\&clcid=0x416) (em inglês).

Para obter mais informações sobre o provisionamento de RAID e o subsistema de E/S do SQL Server, consulte o artigo sobre práticas recomendadas do SQL Server (em inglês) (https://go.microsoft.com/fwlink/?linkid=168612\&clcid=0x416) (em inglês).

Antes de implantar um novo farm, é recomendável submeter o subsistema de E/S a benchmark usando a ferramenta de parâmetro de comparação de subsistema de disco SQLIO. Para obter detalhes, consulte o artigo sobre a ferramenta de parâmetro de comparação de subsistema de disco SQLIO (em inglês) (https://go.microsoft.com/fwlink/?linkid=105586\&clcid=0x416) (em inglês).

Gerenciar de forma pró-ativa o aumento dos arquivos de dados e de log

• Pré-dimensionar os arquivos de dados e de log.

• Não dependa apenas do recurso de aumento automático. Em vez disso, gerencie manualmente o aumento dos arquivos de dados e de log. Você pode habilitar o aumento automático por questões de segurança, mas deve gerenciar de forma pró-ativa o aumento dos arquivos de dados e de log.

• Defina as configurações de aumento automático para atender às necessidades da sua implantação.

  • Quando estiver planejando bancos de dados de conteúdo que excedam o tamanho recomendado (100 GB), defina o valor de aumento automático do banco de dados como um número fixo de megabytes em vez de um percentual. Isso reduz a frequência com a qual o SQL Server aumenta o tamanho de um arquivo. O aumento de tamanho do arquivo é uma operação de bloqueio que envolve o preenchimento do novo espaço com páginas vazias.

    Dica

    O SQL Server 2008 que está sendo executado no Windows Server 2003 dá suporte à inicialização de arquivo instantânea. A inicialização de arquivo instantânea pode reduzir bastante o impacto de desempenho de uma operação de aumento do arquivo. Para obter mais informações, consulte o artigo sobre inicialização de arquivo de banco de dados (em inglês) (https://go.microsoft.com/fwlink/?linkid=132063&clcid=0x416) (em inglês).

  • Quando estiver planejando bancos de dados de conteúdo menores do que o tamanho recomendado (100 GB), defina os bancos de dados com 100 GB quando forem criados usando a propriedade ALTER DATABASE MAXSIZE.

  • Se o espaço em disco for limitado ou os bancos de dados não puderem ser dimensionados, configure o valor de aumento automático como um percentual fixo. Por exemplo, configure o valor do aumento automático como 10 por cento para bancos de dados com menos de 500 GB e como um número fixo de megabytes se um banco de dados exceder 500 GB.

• Mantenha um nível de pelo menos 25 por cento de espaço disponível nos discos para permitir padrões de crescimento e uso máximo. Se gerenciar o crescimento por meio da adição de discos a uma matriz RAID ou por meio da alocação de mais armazenamento, monitore cuidadosamente o tamanho do disco para evitar a falta de espaço livre.

Limitar o tamanho do banco de dados de conteúdo para aprimorar a capacidade de gerenciamento

Planeje o dimensionamento do banco de dados que aprimorará a capacidade de gerenciamento e o desempenho do ambiente.

• Na maioria das circunstâncias, para aprimorar o desempenho do Office SharePoint Server 2007, não é recomendável usar bancos de dados de conteúdo com superior a 100 GB. Caso seu design exija um banco de dados com mais de 100 GB, siga estas diretrizes:

  • Não use um banco de dados com mais de 100 GB para mais de um único conjunto de sites.

  • Use uma solução de backup diferencial, como o SQL Server 2008 ou o Microsoft System Center Data Protection Manager 2007, em vez das ferramentas internas de backup e recuperação.

  • Teste o servidor que está executando o SQL Server 2008 e o subsistema de E/S antes de migrar para uma solução que dependa de um banco de dados de conteúdo de 100 GB.

• Limite os bancos de dados de conteúdo que contêm vários conjuntos de sites a aproximadamente 100 GB.

Separar e priorizar seus dados entre discos

De modo ideal, coloque os logs dos bancos de dados tempdb, dos bancos de dados de conteúdo e de transações do SQL Server 2008 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:

• Ao priorizar dados entre discos mais rápidos, use a seguinte classificação:

  1. Arquivos de dados tempdb e logs de transações

  2. Arquivos de log de transações de bancos de dados

  3. Banco de dados de pesquisa

  4. Arquivos de dados do banco de dados

  Em um site de portal altamente orientado à leitura, priorize dados em vez de logs.

• Os dados de testes e de clientes mostram que o desempenho de farms do Office SharePoint Server 2007 pode ser significativamente prejudicado por E/S de disco insuficiente para tempdb. Para evitar esse problema, aloque discos dedicados para tempdb. Se uma alta carga de trabalho for projetada ou monitorada — ou seja, se a operação média de leitura ou de gravação exigir mais de 20 milissegundos — talvez você precise atenuar o afunilamento separando os arquivos em discos ou substituindo os discos por outros mais velozes.

• Para obter melhor desempenho, coloque o tempdb em uma matriz de RAID 10. O número de arquivos de dados de tempdb deverá ser igual ao número de CPUs principais, e esses arquivos devem ser definidos com tamanho igual. Conte processadores de núcleo duplo como duas CPUs para essa finalidade. Conte cada processador que dê suporte a hyper-threading como uma única CPU. Para obter mais informações, consulte o artigo sobre otimização do desempenho de tempdb (https://go.microsoft.com/fwlink/?linkid=148537\&clcid=0x416).

• Separe os dados de bancos de dados e de arquivos de log de transações em discos diferentes. Se os arquivos precisarem compartilhar discos porque são muito pequenos para justificar o uso de um disco ou faixa inteiros ou, ainda, porque há espaço em disco insuficiente, coloque arquivos com diferentes padrões de uso no mesmo disco, para minimizar solicitações de acesso simultâneas.

• Consulte seu fornecedor de hardware de armazenamento para obter informações sobre como configurar todos os logs e os bancos de dados de pesquisa para otimizar a gravação com vistas à sua solução de armazenamento específica.

• Alocar eixos dedicados para o banco de dados de pesquisa.

Usar vários arquivos de dados para grandes bancos de dados de conteúdo e o banco de dados de pesquisa do SSP

Para obter um desempenho melhor em grandes bancos de dados de conteúdo e no banco de dados de pesquisa do SSP, considere o uso de vários arquivos de dados.

Usar vários arquivos de dados para bancos de dados de conteúdo

Siga estas recomendações para obter o melhor desempenho:

• Crie arquivos somente no grupo de arquivos principal do banco de dados.

• Distribua os arquivos em discos separados.

• O número de arquivos de dados deve ser menor ou igual ao número de CPUs principais. Conte processadores de núcleo duplo como duas CPUs para essa finalidade. Conte cada processador que aceite hyper-threading como uma única CPU.

• Crie arquivos de dados com o mesmo tamanho.

Para obter mais informações sobre como criar e gerenciar grupos de arquivos, consulte o artigo sobre arquivos e grupos de arquivos de bancos de dados físicos (https://go.microsoft.com/fwlink/?linkid=117909\&clcid=0x416).

Use vários arquivos de dados para o banco de dados de pesquisa do SSP

Para o banco de dados de pesquisa, recomendamos que grupos de arquivos sejam utilizados para separar as tabelas usadas principalmente para rastreamento e processamento de consultas. O grupo de arquivos que hospeda as tabelas mais afetadas pelo rastreamento deve ser movido para um conjunto diferente de eixos do grupo de arquivos principal, de modo a fornecer maior redução no impacto sobre o subsistema de E/S.

As tabelas de bancos de dados listadas na tabela a seguir estão relacionadas principalmente ao rastreamento.

Siga estas recomendações para obter o melhor desempenho para bancos de dados de pesquisa:

• Transfira as tabelas do grupo de arquivos principal do banco de dados.

• Distribua os arquivos em discos separados.

Problemas conhecidos

As seções a seguir descrevem problemas conhecidos com o uso de grupos de arquivos para o banco de dados de pesquisa.

Backup e restauração

O backup e a restauração dos Produtos e Tecnologias do SharePoint não incluem reconhecimento de grupos de arquivos. Não há como indicar onde o novo grupo de arquivos deva ser restaurado. O processo de restauração tenta colocar o grupo de arquivos de rastreamento na mesma unidade em que ele estava quando foi feito o backup. Para restaurar, você deve ter unidades para os grupos de arquivos primários e de rastreamento com a mesma letra da unidade de backup inicial.

Futuras atualizações, service packs e hotfixes

Cada atualização, service pack e hotfix que você aplica ao servidor tem o potencial de modificar o índice que foi movido para o grupo de arquivos de rastreamento ou de adicionar um novo índice a uma das tabelas transferidas para o grupo de arquivos. Se um desses eventos ocorrer, o índice será transferido de volta para o grupo de arquivos primário ou será recriado nele.

Devido ao risco de modificação de índice, após aplicar qualquer atualização, você deverá repetir o processo de transferência das tabelas para o grupo de arquivos executando os scripts fornecidos no blog do Enterprise Search.

Requer pelo menos o SQL Server 2005. O SQL Server 2008 é preferível

O script de equipe do produto que é usado para mover os índices usa recursos lançados no SQL Server 2005 e que continuam no SQL Server 2008. Essa otimização só poderá ser realizada se você estiver executando o SQL Server 2005 ou posterior. .

Siga as recomendações de configuração do fornecedor

Para obter o melhor desempenho ao configurar uma matriz de armazenamento físico, siga as recomendações de configuração de hardware indicadas pelo fornecedor de armazenamento, em vez de seguir os valores padrão do sistema operacional.

Se você não receber orientação de seu fornecedor, recomendamos o uso do utilitário de configuração de disco DiskPart.exe para configurar o armazenamento para o SQL Server 2008. Para obter mais informações, consulte o artigo sobre práticas recomendadas de E/S para pré-implantação (em inglês) (https://go.microsoft.com/fwlink/?linkid=105583\&clcid=0x416) (em inglês).

Baixar este manual

Este tópico está incluído no seguinte manual baixável para facilitar a leitura e a impressão:

• Planejamento e arquitetura do Office SharePoint Server 2007, parte 2 (https://go.microsoft.com/fwlink/?linkid=85548\&clcid=0x416)

Consulte a lista completa de manuais disponíveis no artigo sobre conteúdo para download para o Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=89172\&clcid=0x416).