thesolidqjournal
administração de banco de dados 22
Por Gilberto Zampatti
SharePoint 2010 para o DBA
Uma arquitetura de Sharepoint muito mais flexível (e escalável) vem com um preço
– um fardo administrativo maior, principalmente para os DBAs.
Microsoft SharePoint e o SQL Server estão
O unidos pelo quadril. A plataforma de conteúdo
e colaboração do Sharepoint roda em cima do
sólido sistema de gerenciamento de banco rela-
cional do SQL Server, que é responsável pela per-
sistência e consistência da maioria dos dados e
metadados que compõem o Sharepoint.
Enquanto mais organizações se voltam para o
Sharepoint para gerenciar conteúdo essencial e
workflows, e o tamanho dessas implementações
continuam a crescer, os administradores precisam
estar cientes das melhores práticas para configu-
rar e gerenciar essas bases de dados SQL Server
para uma melhor performance e escalabilidade.
Hoje em dia, esses administradores são na sua
maioria DBA’s que estão intimamente familiariza-
dos com o SQL Server, mas que talvez não tenham
tanta experiência com o Sharepoint.
Com o Sharepoint 2010, nós temos uma arqui-
tetura que é muito mais flexível e escalável do que
no Sharepoint 2007. Mas o preço desse benefí-
cio é um fardo administrativo maior, principalmente
para os DBAs. Esse artigo fornece um overview
de vários aspectos importantes do Sharepoint 2010
para o DBA SQL Server, focado em:
1. A nova arquitetura do Sharepoint e o seu
impacto no SQL Server
2. Novas opções de armazenamento, com foco
especial nas funcionalidades de gerencia-
mento de binary large object (BLOB)
Vamos começar!
Interfaces Administrativas: Falta de
Padrões
Nas versões anteriores do Sharepoint, as interfa-
ces administrativas simples e amigáveis constan-
temente escondiam a verdadeira complexidade
do relacionamento do Sharepoint com o SQL Ser-
ver. Além disso, as interfaces para configurar a
farm de servidores do Sharepoint e implementar
os Web Applications falhavam em várias recomen-
dações de boas práticas para gerenciamento do
SQL Server.
Por exemplo, muitos profissionais de Sharepoint
e SQL Server alertam para a não utilização do Farm
Configuration Wizard, exceto para algumas confi-
gurações básicas. O wizard utiliza valores padrões
para tamanho e localização de arquivos para a con-
figuração inicial da farm e dos seus principais servi-
ços e para a criação da base de dados de configura-
ção, assim como a base de conteúdo da Central Admi-
nistration e outras bases de dados essenciais. O
wizard também utiliza GUIDs para gerar automatica-
mente o nome para cada base de dados. Com isso
você acaba encontrando diversas bases de dados
com nomes estranhos e muito pequenas na hierar-
quia de pastas pré-definidas na sua instância do SQL
Server. Apesar do SQL Server 2008 ser mais inteli-
gente, permitindo a definição de um conjunto de pas-
tas padrões mais articuladas isso ainda pode ser insu-
ficiente para as suas necessidades de armazena-
mento.
Da mesma forma, quando você utiliza a página de
gerenciamento de aplicativos na Central Administra-
tion para criar um novo Web Application, o banco de
dados criado é pequeno e mal localizado. Em minu-
tos, esse banco de dados terá que ser expandido para
receber o conjunto inicial de informações. Quando
você verificar o status da sua base de dados recém
criada, você irá notar a expansão dos seus arquivos
de dados e de logs – o primeiro sintoma de que um
banco de dados não está feliz.
Desse ponto de vista, o Sharepoint 2010 mudou
muito pouco. Os wizards de configuração nas inter-
© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj
 23

faces da Central Administration ainda utilizam os 1. Sistema Operacional: SharePoint Server

valores padrões do SQL Server para criar as bases
de dados.
Além disso, o novo modelo do Sharepoint 2010
de Service Applications aumenta ainda mais o
número de bases de dados do Sharepoint. A nova
arquitetura, que nós iremos ver daqui a pouco,
necessita de uma ou mais bases de dados para cada
application service. Entretanto, o Sharepoint 2010
perdeu um velho companheiro e suas bases de
dados – o modelo de Shared Service Provider – que
é um componente muito importante na arquitetura
do Microsoft Office Sharepoint Service (MOSS)
2007, mas que não é mais encontrado na nova pla-
taforma.
2010 (assim como o SharePoint 2010 Foun-
dation) requer o Windows Server 2008
(Standard ou Enterprise Edition) com ser-
vice pack 2 (SP2) ou Windows Server 2008
R2 (Standard ou Enterprise Edition). Ambos
os sistemas operacionais precisam de uma
atualização para suportar a autenticação
baseada em token sem segurança no trans-
porte ou criptografia de mensagens no WCF
(você pode baixar a atualização para o Win-
dows Server 2008 SP2 ou Windows Server
2008 R2).
2. RDBMS: Três versões do SQL Server são
suportadas:

SharePoint 2010 somente 64-bit • A edição 64-bit do SQL Server 2005 com
SP3 e com o Cumulative Update (CU) 3
Para entender melhor as novidades do Sharepoint para SQL Server 2005 SP3.
2010 vamos começar olhando os pré-requisitos de • A edição 64-bit do SQL Server 2008 com
hardware e software. Você pode encontrar os deta- SP1 e com o Cumulative Update 2 (CU)
lhes no artigo do Technet: Hardware and software para SQL Server 2008 SP1; esse C.U. con-

Tabela 1: Requisitos Mínimos de Hardware para o Sharepoint 2010

Componente Requisito Mínimo

Processador 64-bit, 4 núcleos, 2.5 GHz mínimos por núcleo
RAM 4GB para desenvolvimento ou teste
8GB para instalações single-server e multi-server para uso em produção
Hard disk 80GB para a instalação
Para uso em produção você precisa de espaço em disco livre adicional para as operações do
dia-a-dia. Adicione o dobro da quantidade de memória RAM como espaço livre em disco para
uso em ambientes de produção.

requirements (SharePoint Server 2010), mas um dos siste de duas partes, então tenha cer-
requisitos chave é que o Sharepoint 2010 roda teza de que você baixou ambos os arqui-
somente em plataformas 64 bits. A tabela 1 resume vos. Quando você instalar o SQL Server
os requisitos mínimos de hardware. 2008 SP1 no Windows Server 2008 R2,
Os requisitos de software são um pouco mais você pode receber um aviso de compati-
elaborados. Durante o processo de instalação o bilidade. Você pode ignorar esse aviso e
Microsoft SharePoint 2010 Products Preparation continuar com a sua instalação.
Tool fornece à instalação diversos pré-requisitos de • SQL Server 2008 R2, que permite que
software, incluindo os papéis de Web Server Role você utilize as novas funcionalidades
e Application Server Role; para os nossos propósi- como planilhas do PowerPivot, o Add-in
tos mantenha esses pontos em mente: do Reporting Services for Sharepoint Tech-

© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj

 thesolidqjournal
administração de banco de dados 24

nologies para utilizar o Access Services os Web Applications associados, no Sharepoint

for Sharepoint 2010 e mais.
Apesar de existirem mais pré-requisitos de soft-
ware para o Sharepoint 2010, para o nosso over-
view dos itens relacionados ao SQL Server, esses
são os pontos chaves.
Service Application Model
Talvez a maior novidade do Sharepoint em arqui-
tetura está na introdução do modelo de Service
Applications, que substitui o modelo de Shared
Services Provider (SSP). Enquanto que o SSP
fornece um conjunto fixo de serviços para todos
2010 você pode agora escolher e configurar
qualquer combinação de serviços pré-estabeleci-
dos ou implementar serviços customizados.
Cada service application merece uma discus-
são completa, o que está fora do escopo deste
artigo, mas nós iremos ver três deles em mais
detalhes a seguir. O importante a reparar, de uma
perspectiva de DBA, é que a maioria dos serviços
pré-definidos necessita de uma ou mais bases de
dados cada. O serviço de busca por si só, por
exemplo, precisa de várias bases de dados. A
Tabela 2 lista algumas informações úteis sobre os
service applications mais importantes no novo
modelo.

Tabela 2: Principais Service Applications

Service Application Description DB CF SPF SPS SPE

Access Services Visualiza, edita e interage com bases de dados do Sim
Microsoft Access 2010 no browser
Business Data Connectivity Acessa sistemas de linha de negócio (LOB) Sim Sim Sim Sim Sim
Excel Services Visualiza e interage com arquivos do Excel no browser Sim
Managed Metadata Service Acessa hierarquias de taxonomia, palavras chaves e Sim Sim Sim Sim
tags sociais assim como publicação de Content T
ype através de site collections
Performance Point Services Fornece as funcionalidades do PerformancePoint Sim Sim
Office Web Apps Services Acessa documentos do Word 2010, PowerPoint 2010, Sim
e OneNote 2010 através do browser
Search Varre conteúdos e cria partições de indices e Sim Sim Sim Sim
consultas de busca nos servidores
Secure Store Service Fornece autenticação para múltiplos aplicativos Sim Sim Sim Sim
e serviços
State Service Fornece armazenamento temporário da sessão dos Sim Sim Sim
usuários para os componentes do Sharepoint Server
Usage and Health Data Coleta informações na farm sobre uso e saúde da farm Sim Sim Sim Sim
Collection e fornece a habilidade de visualizer vários relatórios
People Service Adiciona suporte para o My Sites, Profiles, Social Sim Sim Sim Sim
tagging, e outras funcionalidades sociais
Visio Graphics Service Visualiza e atualiza diagramas publicados do Visio Sim
pelo browser
Web Analytics Habilita visualização rica de padrões de uso Sim Sim Sim
processando e analisando os dados de acesso
Word Conversion Fornece um framework para realizar conversões Sim Sim
de documentos automatizadas
Legenda: DB=um ou mais bancos de dados necessários; CF=Cross Farm; SPF= disponível no SharePoint 2010 Foundation; SPS=disponível no
SharePoint 2010 Standard; SPE=disponível no SharePoint 2010 Enterprise

© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj

 25

Você irá perceber que essa nova arquitetura

é muito mais flexível (e escalável) do que a ante-
rior. Mas como eu disse anteriormente, o preço
para esse benefício é o fardo administrativo supe-
rior, principalmente para os DBAs. Esteja prepa-
rado para fazer muito mais planejamento sobre
tamanho e localização de bases de dados do que
nas versões anteriores do Sharepoint. O artigo do
MSDN Storage and SQL Server capacity planning
and configuration (SharePoint Server 2010) pos-
sui boas dicas sobre este tópico – diferente do seu
predecessor, o Sharepoint 2010 está muito bem
documentado no MSDN.

Usage and Health Data Collection

Eu quero aprofundar um pouco em alguns dos ser-
vice application que são de interesse para os DBAs,
começando com o Usage and Health Data Collec-
tion. Esse application service implementa um
banco de dados de log de uso e captura requisi-
ções em funcionalidades, serviços, Jobs e requi-
sições de páginas.
A Infra-estrutura de uso, mostrada na Figura 1,
fornece um canal para o armazenamento de infor-
mações de uso através da API de Uso. Essa infor-
mação é armazenada em cache no sistema de
arquivos local, em um arquivo de log de uso. Um
Figura 1: Infra-estrutura de coleta de informações de
Uso e de Saúde
job coleta esses arquivos e insere esses registros
no banco de dados de log. Os dados armazena-
dos no SQL Server podem então ser processados
e agregados para a criação de relatórios. Os dados
de uso do banco de dados podem ser acessados
através da API do SQL fornecida.
Web Analytics

Tabela 3: Relatórios de Análise Web no nível de Coleção de Sites

Relatórios de Coleções de Sites

Inventory Traffic Search
Storage Used Number of Page Views Number of Queries
Number of Sites Number of Daily Unique Visitors Top Queries
Number of Lists Number of Referrers Failed Queries
Number of Libraries Top Pages Best Bet Usage
Top Site Templates Top Visitors Best Bet Suggestions
Top Site Product Versions Top Referrers
Top Site Languages Top Destinations
Top List Templates Top Browsers
Top Library Templates

© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj

 thesolidqjournal
administração de banco de dados 26
O serviço compartilhado do Sharepoint chamado Web
Analytics permite que os usuários e administradores
processem e analisem os dados coletados em um
ou mais sites. O serviço Web Analytics usa a infra-
estrutura de serviços compartilhada e com uma inter-
face consistente com outros serviços.
Cada serviço Web Analytics possui um ou mais
Tabela 4: Relatórios de Análise Web no nível de Site
Relatórios de Sites
Traffic Inventory
Number of Page Views Number of Sites
Number of Daily Unique Visitors Number of Lists
Number of Referrers Number of Libraries
Top Pages Top Site Templates
Top Visitors Top Site Product Versions
Top Referrers Top Site Languages
Top Destinations Top List Templates
Top Browsers Top Library Templates
Web Analytics Components que compõem o pipe-
line de processamento. Esse pipeline utiliza os
dados coletados pelo SharePoint Web Analytics
para gerar os relatórios. As Tabelas 3 e 4 listam os
tipos de relatórios que o serviço Web Analytics
produz em diferentes níveis.
Duas bases de dados estão associadas com o
serviço Web Analytics:
1. Uma base de dados de Staging: Essa é a
base de dados que vai estar “trabalhando”;
ela contem os dados de uma forma não-
agregada além de metadados. Os dados
são inseridos em filas, e a retenção é con-
figurável e normalmente curta.
2. Uma base de dados de Relatório: Essa
base de dados contem os dados agregados
e as tabelas dos relatórios padrões, fatos
agregados, metadados e diagnósticos.
Vamos parar um minuto para verificar o pro-
cesso do Web Analytics:
1. Os servidores de Web front-end (WFE) cole-
tam a informação através da API AP-exten-
ded Core Usage
2. Os dados são salvos em arquivos .usage
em cada WFE.
3. Um timer job do WSS em cada WFE extrai
os dados relevantes armazenados nos arqui-
vos .usage e envia essa informação para o
banco de dados de Staging através dos Web
Services de Logging.
4. O componente Log Batcher processa os
dados em lotes na base de dados de Sta-
ging e armazena os dados processados de
volta na base de dados de Staging.
5. O Log Batcher implementa um componente
de detecção de spam nos dados, para mar-
car qualquer dado que possua valores maio-
res do que os limites permitidos.
6. O Usage Behavior Analyzer coleta os dados,
um lote de cada vez, e escreve esses dados
nas tabelas de fato no banco de dados de
Staging novamente.
7. As Fact Tables são lidas por um Consoli-
dador de Relatórios.
8. O Consolidador de Relatórios gera as tabe-
las agregadas e as armazena no data ware-
house (o banco de dados de relatório).
9. Table Valued Functions (TVFs), represen-
tando as consultas dos clientes aos dados,
são usadas para consultar os dados dos ban-
cos de dados de Web Analytics.
Quando você estiver criando um plano de capa-
cidade confiável para as bases de dados de Web
Analytics, tenha em mente o seguinte:
• A retenção dos dados é configurável de 1 a
25 meses.
• A Microsoft diz que 90 dias de dados, baseado
em 3 milhões de clicks por dia, precisam de
aproximadamente 250GB de espaço.
Search Services
O Search services é um dos pontos onde houve
maior melhora no Sharepoint 2010, e uma discus-
são completa desse serviço iria precisar de um
© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj
 27

artigo inteiro. Entretanto é importante destacar

algumas considerações sobre as novas funciona-
lidades de escalabilidade e flexibilidade do novo
Search Service.
Primeiro, o Sharepoint 2010 fornece duas for-
mas distintas e, em essência, complementares:
o Sharepoint Search service e o FastSearch Ser-
vice. Os principais elementos dessa nova arquite-
tura, ilustrada na Figura 2, são:

• Search Center: A interface do usuário para

disparar consultas e interagir com os resulta-
dos.
• Query servers: Os servidores de aplicativo que
recebem as requisições de consultas e as pro-
cessa, executando a consulta, recebendo os
resultados de volta, juntando os resultados caso
elas venham de múltiplas partições de índice
(mas NÃO de locais federados) e envia os resul-
tados de volta.
• Query federation: Utilizado para retornar os
Figura 2: componentes da tecnologia Search Service
resultados de índices que não sejam do Sha-
repoint; Federação de consulta utiliza um
padrão aberto, chamado OpenSearch, para
recuperar dados do Sharepoint ou outros meca-
nismos de busca para que você possa mostrar
esses resultados por si só, ou pode mostrar
lado-a-lado com outros resultados de busca.
• Indexing: O processo que extrai a informação
de itens para comparações mais eficientes; ele
cria indices full-text físicos de dados e captura
metadados.
• Index partition: Um sub-conjunto de um índice
completo.
• Crawling: O processo de abrir o conteúdo e
recuperar os dados para indexação; ele passa
por todas as URLs para gravar os itens em catá-
Figura 3: escalabilidade do MOSS 2007
logos de busca.
• Connectors: O que o SharePoint 2010 utiliza mostradas na Figura 2 (SharePoint 2010) e a Figura
para conectar e para recuperar dados de fontes 3 (MOSS 2007), você pode facilmente ver a dife-
de conteúdo; no SharePoint 2003 e no MOSS rença entre a escalabilidade entre o MOSS 2007
2007 a mesma tarefa era realizada pelos iFilters e o Sharepoint 2010.
e protocol handlers. Protocol Handlers ainda são Considerando um ambiente de médio porte, o
suportados mas estão se tornando obsoletos, MOSS 2007 Search Service pode inicialmente ser
o que significa que eles serão abandonados configurado com um servidor de banco de dados
no futuro próximo. e um servidor rodando o índice e as consultas.
Se você comparar as arquiteturas de busca Supondo que você precise escalar o ambiente,

© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj

 thesolidqjournal
administração de banco de dados 28
você pode separar o servidor de consulta em uma
máquina separada. Se você precisar escalar ainda
mais, você pode adicionar um novo servidor de
consulta. Talvez você possa adicionar alguns file-
groups adicionais no SQL Server, como está
descrito nas Melhores práticas para perfor-
mance de consultas (Office SharePoint Server
2007). Mas isso é tudo – pelo menos no assunto
de escalabilidade.
No meio tempo, você também tem algumas limi-
tações aqui. Você tem o seu índice inteiro armaze-
nado no servidor de consulta e índice. Somente um
indexador está disponível, então ele é um gargalo
assim como um ponto único de falha, porque o
MOSS 2007 não suporta failover para esse servidor.
A instância do SQL Server também é um gargalo por-
que você não pode criar mais do que um banco de
dados de busca. Se o seu arquivos de índice cresce-
rem para tamanhos extremamente grandes, se torna
difícil ou até impossível passar por todo o arquivo de
índice, carregá-lo na memória e servir as requisições
de consultas com um tempo de resposta abaixo de
um segundo.
Agora examine como a escalabilidade da busca
melhorou no SharePoint 2010. Primeiro, é possível
ter múltiplos indexadores. Quando o banco de dados
que é usado para o processo de rastreamento cres-
cer muito, você pode dividir a base em um novo
banco de dados, dessa forma não tem apenas uma
base de dados de rastreio para impactar nas consul-
tas. É possível fazer o scale out adicionando novas
bases de dados de rastreio conforme a necessidade.
O arquivo de índice é independente dos indexado-
res, então agora eles são rastreadores stateless;
isso significa que você pode escalar os rastreado-
res independentemente.
Você pode ter um conjunto de rastreadores
para uma base de dados de rastreamento, e
uma outra base de dados de rastreamento com o
seu próprio conjunto de rastreadores – cada ras-
treador possuindo seu próprio conjunto de threads
de rastreamento e cada banco de dados de ras-
treamento tendo o seu throughput.
No lado das consultas, o SharePoint 2007 supor-
tava somente mirror dos índices – cada servidor de
consultas tinha uma cópia completa do índice. Com
o Sharepoint 2010, você pode particionar o índice.
Isso lhe permite reduzir o tamanho do arquivo de
índice, para que o conteúdo possa ser consultado
mais rápido e os resultados retornados mais rápi-
dos. Também é possível separar diferentes partes
do índice em diferentes máquinas no farm, fazendo
mais cavalos de potência disponíveis para servir as
requisições de consultas. Se o gargalo é as consul-
tas no full-text, a solução pode ser simplesmente
a criação de uma partição adicional para dividir a
carga entre o mesmo ou entre servidores adicio-
nais. O SharePoint 2010 também suporta o mir-
ror, da mesma forma que o SharePoint 2007 fazia,
então você tem redundância e pode separar a carga
entre cada uma das partições da consulta.
Para aumentar ainda mais a velocidade da con-
sulta, o SharePoint 2010 suporta múltiplas bases
de dados de propriedades. Então se o gargalo é na
consulta dos metadados, você pode adicionar novas
bases de dados de propriedades. Novamente, você
pode adicionar quantos desses componentes de
consulta você necessitar.
Finalmente, o SharePoint 2010 fornece a
base de dados de administração e o componente
de administração para cada serviço de busca, como
a Figura 4 mostra. O SharePoint 2007 usava a base
de dados SSP para armazenar todas as informa-
ções de configuração. No SharePoint 2010, essa
informação é armazenada agora na base de dados
de administração. O componente de administra-
ção é responsável por coisas como acordar os ras-
Figura 4: Escalabilidade do SharePoint 2010
© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj
 29

Tabela 5: Mehorando a escalabilidade da busca do SharePoint 2010

Para melhorar isso… Faça isso

Atualização do Índice /
tempo de rastreamento
Latência e throughput
das consultas
Disponibilidade da consulta
Disponibilidade do
rastreador/indexador
Se a máquina de rastreamento, adicione mais máquinas de rastreamento.
Se a base de dados de rastreamento está sofrendo por causa do I/O do SQL Server, adicione
novas bases de dados de rastreamento no mesmo SQL Server.
Se o SQL Server está com problemas de memória/CPU, adicione novos servidores SQL Server
com bases de dados de rastreamento adicionais.
Se o tempo gasto na execução das consultas no modo full-text é alto, particione o índice em
partições de consulta menores. Cada partição de consulta pode contar aproximadamente 10 mil-
hões de itens.
Se o throughput de consulta é baixo, adicione mais componentes de pesquisa para fazer o mir-
ror das partições de consulta.
Se você está com problemas de I/O na base de dados de propriedades do SQL Server, adicione
bases de dados de propriedades no mesmo servidor de banco de dados.
Se você está com problemas de memória/CPU, adicione novos servidores de banco de dados,
com bases de dados de propriedades adicionais.
Implante múltiplos servidores de consultas com mirror das partições, múltiplas partições e
múltiplas bases de dados de propriedades e utiliza servidores de banco de dados com mirror ou
clusterizados para armazenar as bases de dados de propriedades.
Utilize múltiplos rastreadores em servidores de rastreamento redundantes, e adicione múltiplas
bases de dados de rastreamento. Rastreadores associados com uma base de dados de rastreio
determinada podem ser distribuídos entre vários servidores de rastreamento para disponibili-
dade e distribuição de carga.

treadores e dizer para os rastreadores o que eles
devem rastrear. Se o componente administrativo
descobre que o rastreador está fora do ar, ele
atribui a tarefa de rastrear para outro servidor de
rastreamento na farm. Ele também sincroniza todos
os componentes entre todos os outros servidores
de busca na farm.
A Tabela 5 resume alguns dos passos que você
pode fazer para melhorar diferentes aspectos da
escalabilidade da funcionalidade de busca.
Outras Considerações e Sugestões
A seção anterior lhe forneceu um overview de
alto nível na nova arquitetura do Sharepoint 2010.
De forma geral, no SharePoint 2010, você tem que
trabalhar com muitas bases de dados – cada uma
com seu próprio aplicativo e modelagem de dados,
e cada uma necessitando de planejamento para ser
corretamente implantada, assim como geren-
ciada de acordo para garantir a eficiência.
A Microsoft não possuí uma ferramenta sofis-
ticada para criar e gerenciar as bases de dados
(essa é uma tarefa para os ISV’s e integradores).
Entretanto a equipe responsável pela instalação e
configuração da farm do SharePoint 2010 pode
utilizar:
• Central Administration Site e wizards. O site
de administração central fornece um cenário de
configuração simples, normalmente muito sim-
ples. A eficiência do SQL Server não é conside-
rada de forma suficiente por essas interfaces, uti-
lizando as opções padrões do SQL Server quando
criam uma nova base de dados.
• Ferramentas do SQL Server para criar pre-
viamente as bases de dados e PowerShell
para configurar o Sharepoint 2010. Essa
opção é a melhor forma de garantir que as
melhores práticas estão sendo utilizadas tanto
pelo SharePoint 2010 quanto pelo SQL Server.
Você pode criar as bases de dados para que elas
atendam os requisitos apropriados de tamanho
e alocação, e o SharePoint 2010 pode ser con-

© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj

 thesolidqjournal
administração de banco de dados 30
Tabela 6: Soluções de Backup da Farm
Método/Tecnologia Recuperável Tamanho de Backup Suportado
Systems Center Data Protection
Manager 2007 Y 500GB
Microsoft SharePoint
Server 2010 Y < 200GB
SQL Server N
VSS Writer Y Limitation specific to
solution implemented
figurado para reconhecer e utilizar essas bases
de dados pré-criadas.
Com relação a fase de planejamento para o SQL
Server, você pode encontrar muitos white papers
que fornecem informação sobre qual a melhor
forma de armazenamento para diferentes cenários
e técnicas para chegar ao máximo de performance.
Para o planejamento de capacidade do seu projeto
do SharePoint, você precisa tomar cuidado com
dois aspectos da nova arquitetura:
• O SharePoint Server 2010 pode armazenar até
50 milhões de itens em uma lista do SharePoint,
e até 1 milhão de itens em uma única pasta de
uma lista – isso leva a um banco de dados
com um alto volume de dados.
• As funcionalidades de backup do SharePoint
2010 possuem algumas limitações, como a
Tabela 6 mostra.
Como você pode ver, o System Center Data
Protection Manager (DPM) pode fazer backup de
até 500GB por farm e suporta backups full, diffe-
rential e incremental. Você também pode restau-
rar uma farm inteira utilizando o DPM.
Você pode também utilizar as ferramentas de
backup do próprio SharePoint 2010, no site de
Adminitração Central para fazero backup de uma
farm de até 200GB de tamanho. Essa forma de
backup suporta backups full e differential e pode
ser utiliza para restaurar uma farm inteira.
O suporte ao VSS writer, adicionado no Share-
Point 2007, requer uma ferramenta que utilize a API
do VSS para fazer o backup e restaurar, então qual-
Tipo de Backup Suportado
Full, differential, incremental
Full, differential
Full, differential
Tabela 7: Soluções de Backup das Configurações
Método/Tecnologia Recuperável
Systems Center DPM 2007 N
SharePoint Server 2010 Y
SQL Server N
VSS Writer Y
quer limitação será específica dessa ferramenta. O
VSS suporta tanto backups full quanto differential e
pode ser utilizado para restaurar uma farm inteira.
Além disso, você pode fazer o backup de bases
de dados individuais da farm pelo SQL Server, mas
você não pode restaurar uma farm inteira com
esse método, porque você não possuí as altera-
ções nos sistemas de arquivos, GAC, algumas con-
figurações e assim por diante.
Se você quiser fazer o backup e restore somente
das configurações do SharePoint, o DPM e o SQL
Server não irão funcionar, como a Tabela 7 mos-
tra. Você precisa ou utilizar as ferramentas do site
de administração central junto com o stsadm ou
PowerShell ou ainda utilizar uma ferramenta custo-
mizada que trabalha com o VSS Writer. Todas as
quatro formas de backup suportam recuperação
das bases de dados de conteúdo.
Para configurar o SharePoint 2010, a Microsoft
recomenda a utilização da linguagem de script do
PowerShell ao invés do stsadm.exe, porque o
stsadm.exe se tornou obsoleto e não será supor-
tado nas próximas versões. Outro motivo para escol-
her o PowerShell é que você pode utilizar muitos
cmdlets disponível para realizar tarefas que o
stsadm.exe e o psconfig.exe realizam, o que lhe dá
© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj

Tabela 8: Comparando os comandos PSConfig com os Cmdlets do PowerShell
PSConfig Command
configdb –create
configdb –connect
helpcollections -installall
Secureresources
services –install
Installfeatures
adminvs –provision
applicationcontent -install
um benefício secundário: a padronização dos seus
scripts.
A Tabela 8 mapeia os comandos do PSConfig
necessários para configurar e gerenciar o Share-
Point com os cmdlets do PowerShell equivalen-
tes para realizar a mesma tarefa.
O PowerShell também fornece todas as funcio-
nalidades que o stsadm possui, além de um novo
conjunto de comandos implementados exclusiva-
mente para satisfazer as novas funcionalidades do
SharePoint 2010. Para aprender mais sobre a utiliza-
ção do PowerShell com o SharePoint 2010 veja: Win-
dows PowerShell for SharePoint Server 2010.
Novas opções de armazenamento do
SharePoint 2010
O SharePoint 2010 (Foundation e Server) se benefi-
cia da funcionalidade do SQL Server 2008 chamada
FILESTREAM, e uma nova biblioteca chamada
RBS (Remote BLOB Storage), para armazenar e
gerenciar dados não estruturados como documen-
tos de texto, imagens e vídeos. O MOSS 2007, em
contraste, utiliza a arquitetura EBS (External BLOB
Storage) para fornecer algum gerenciamento
BLOB dentro do ambiente do SharePoint Services.
Como o SQ Server 2008 Books Online explica
na sessão “FILESTREAM Overview:”
“Esses dados não estruturados normalmente
são armazenados fora do banco de dados, sepa-
rados dos dados estruturados. Essa separação
pode provocar complexidades no gerencia-
mento de dados. Ou, se os dados estiverem
© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj
31
PowerShell Cmdlet
New-SPConfigurationDatabase
Connect-SPConfigurationDatabase
Install-SPHelpCollection
Initialize-SPResourceSecurity
Install-SPService
Install-SPFeature (provide the -AllExistingFeatures parameter)
New-SPCentralAdministration
Install-SPApplicationContent
associados a armazenamento estruturado, o
desempenho e os recursos de streaming dos
arquivos podem ser limitados.
O FILESTREAM integra o Mecanismo de
banco de dados do SQL Server a um sistema
de arquivos NTFS armazenando dados de
objetos binários grandes (BLOB)
varbinary(max) como arquivos no sistema de
arquivos. As instruções Transact-SQL podem
inserir, atualizar, consultar, pesquisar e fazer
backup de dados FILESTREAM. As interfa-
ces do sistema de arquivos do Win32 forne-
cem acesso de streaming aos dados.
O FILESTREAM usa o cache do sistema
NT para armazenar dados de arquivos. Isso
ajuda a reduzir qualquer efeito que os dados
FILESTREAM possam ter no desempenho
do Mecanismo de Banco de Dados. O pool
de buffers do SQL Server não é usado. Por-
tanto essa memória está disponível para
processamento de consulta.”
Esse novo suporte ao FILESTREAM é particu-
larmente importante para as bases de dados de
conteúdo do SharePoint: aonde mais nós pode-
mos encontrar um monte de dados não-estrutu-
rados gerenciados pelo SQL Server?
RBS é uma biblioteca API que está incorporada
como um add-on feature pack para o SQL Server
2008 e SQL Server 2008 Express. Desenvolvida para
mover o armazenamento dos BLOBs dos servido-
res de banco de dados para soluções de storage,
essa biblioteca API utiliza providers para se conectar
a um armazenamento dedicado de BLOB.
 thesolidqjournal
administração de banco de dados 32
Um desses providers é o provider FILESTREAM
(não o mesmo que a funcionalidade do SQL Server).
O provider FILESTREAM é suportado atualmente
somente em bases de dados locais no SharePoint
Foundation 2010, que suporta nativamente uma
implementação de armazenamento de BLOB que
acessa a API RBS através de um provider. Perceba
que o SharePoint Foundation 2010 não suporta imple-
mentações de armazenamento de BLOB remotas
que utiliza apenas a funcionalidade FILESTREAM.
Para aproveitar as vantagens dessa nova opção
de armazenamento você precisa habilitar a funcio-
nalidade de FILESTREAM do SQL Server e insta-
lar e configurar o RBS. Você pode encontrar deta-
lhes dessas tarefas no artigo do TechNet Install and
configure Remote BLOB Storage (RBS) with the
FILESTREAM provider(SharePoint Foundation 2010);
aqui estão os passos principais:
1. Para realizar a instalação e configuração e habi-
litar a funcionalidade de FILESTREAM, o usuá-
rio precisa ser um membro do grupo Adminis-
tradores nos servidores Web e nos servidores
de Aplicativos que são parte da farm do Share-
Point. O usuário também precisa ser no mínimo
dbcreator e dbsecurityadmin no SQL Server 2008
(ou SQL Server 2008 Express).
2. Habilite e configure a funcionalidade FILESTREAM
na instância do SQL Server que armazena as
bases de dados do SharePoint (para detalhes,
vejo o Books Online ou How to: Enable
FILESTREAM).
3. Altere qualquer base de dados de conteúdo
aonde vcê planeja fornecer suporte ao arma-
zenamento BLOB, criando uma encryption mas-
ter key, criando um filegroup para o tipo de
dados FILESTREAM, e criando um “arquivo”
para o filegroup (lembre-se que esse é na ver-
dade um caminho raiz para a hierarquia de pas-
tas que irá armazenar os arquivos BLOBs). As
boas práticas recomendam a criação em um
volume que não contenha o sistema operacio-
nal, um arquivo de paginação ou arquivos do
banco de dados tempdb.
4. Instale o add-in RBS no servidor de banco de
dados, em todos servidores Web e em todos
os servidores de aplicativos na farm do Sha-
repoint. O processo de instalação está clara-
mente descrito no artigo indicado acima do
TechNet, incluindo o script PowerShell que você
utiliza para habilitar o RBS.
Dizer que o RBS é uma forma eficiente de
manter a alta performance nos seus repositórios
so Sharepoint e no SQL Server e para reduzir o
crescimento de certas bases de conteúdo parece
ser óbvio. Entretanto, aproveitar essa nova capa-
cidade do Sharepoint pode mudar a forma que
você planeja a topologia da farm e certamente
lhe dá uma perspectiva não disponível nas ver-
sões anteriores do SharePoint, considerando a
falta de integração que caracterizavam as solu-
ções de EBS anteriores.
Explorando o Universo do Sharepoint/SQL
Server
Agora que nós temos um entendimento básico da
infra-estrutura do SharePoint 2010 podemos utilizar
esse artigo de overview como um passo inicial para
explorar mais boas práticas para administrar o uni-
verso do SharePoint/SQL Server. Em um artigo futuro
eu irei fazer um passo-a-passo de uma instalação e
configuração básica de uma farm do Sharepoint uti-
lizando algumas das sugestões que eu apresentei
aqui. Enquanto isso, dê uma olhada no SQL Server
and SharePoint Server 2010 Databases resource
center para começar a construir o seu conheci-
mento.
Sobre o Autor
Gilberto Zampatti, um Mentor na Solid
Quality Mentors Itália, é um instrutor e
consultor certificado em SQL Server e
SharePoint. Ele trabalha com o SQL Ser-
ver desde 1999 e com o SharePoint desde
2003. Junto com Gianluca Hotz da SolidQ
e outros velhos amigos ele fundou o User Group Italiano de
SQL Server e atualmente atua como secretário do grupo.
Gilberto constantemente palestra em conferências técni-
cas na Itália.
© The SolidQ™ Journal, Agosto 2010 – www.solidq.com/sqj