 TechNet Magazine March 2007
TechNet Magazine March 2007
MARCH 2007
SQL Server

AJUSTE DO SQL SERVER

Este é o mês do SQL Server na TechNet Magazine. Nesta edição, você entenderá melhor como afinar o SQL Server. Aprenderá como atingir índices excelentes de integridade, de forma que o SQL Server possa executar consultas rápidas e colocar todas as informações de que você precisa ao alcance de suas mãos.

Você verá como o agrupamento do SQL Server oferece redundância e dá suporte a um melhor tempo de atividade. Também descobrirá, no seu ambiente, qual o significado da alta disponibilidade e como obtê-la. Finalmente, verá como acabar de uma vez por todas com seus dilemas com relação ao particionamento de tabelas.

Administração do Windows

E não se esqueça, neste mês, Mark Russinovich está de volta, com mais informações sobre o kernel do Windows Vista.
RECURSOS
SQL Server Novas ferramentas para diagnosticar a integridade dos índices

Para obter o melhor desempenho do SQL Server, é necessário supervisionar e manter índices íntegros. As novas funções e exibições de gerenciamento dinâmico oferecem uma janela para o SQL Server, ajudando-o a compreender melhor como seus índices estão funcionando e a descobrir possíveis problemas de desempenho.

Randy Dyess Atingir a alta disponibilidade do SQL Server

O SQL Server 2005 oferece várias opções para melhorar a disponibilidade do banco de dados, da replicação ao agrupamento e o envio de log. Examinaremos mais de perto as várias opções de configuração do SQL Server e o ajudaremos a descobrir quais são as mais adequadas para seu ambiente.

Zach Nichter Simplificar a manutenção do banco de dados com partições de tabelas

No passado, trabalhar com partições e tabelas muito grandes era uma tabela extenuante e entediante, mas, com o SQL Server 2005, o particionamento de tabelas ficou muito mais simples. Agora, você pode criar várias partições facilmente, mover essas partições, eliminar partições antigas e até mesmo alterar a forma como os dados são particionados. Assim:

Noah Gomez Dicas ótimas para o agrupamento do SQL Server

Um agrupamento de servidor fornece recursos de failover, assegurando mais tempo de atividade para suas operações críticas. Mas, para que um cluster seja eficiente, ele deve ser implementado corretamente. Seguem algumas dicas importantes que o ajudarão a desenvolver seu cluster mais rápido e a mantê-lo funcionando de maneira confiável.

Tom Moreau, PhD Administração do Windows Dentro do kernel do Windows Vista: Parte 2

Neste mês, continuamos nossa minuciosa discussão sobre as novidades do kernel do Windows Vista. Nesta edição, examinamos alguns avanços na forma como o Windows Vista gerencia a memória e explora as áreas de inicialização, desligamento e gerenciamento de energia do sistema.

Mark Russinovich
COLUNAS
Do editor

Estante de troféus

Joshua Trupin Caixa de ferramentas

Novos produtos para profissionais de TI

Greg Steen Destaque de utilitário

SyncToy

Jay Munro SQL Q&A

Horário de verão, memória do servidor e muito mais

Editado por Nancy Michell The Cable Guy

O protocolo DHCPv6

Joseph Davies Windows PowerShell

A eficiência das variáveis

Don Jones 		Ei, Equipe de Scripts!

Respondendo a suas perguntas sobre UOs... por apenas cinco centavos

A equipe de scripts da Microsoft Perguntas e respostas do Exchange

Logs de transações, Cmdlets, gerenciamento remoto e muito mais

KC Lemson e Nino Bilic Security Watch

Implantando o EFS: parte 2

John Morello Os arquivos da área de trabalho

A última palavra em PsTools

Wes Miller Por dentro da Microsoft.com

Guia de introdução ao espelhamento do banco de dados

Saleem Hakani Anotações de campo

O Doutor chegou

Matt Hester Segredos do Windows

Parecendo inteligente, sendo ignorante

Raymond Chen


 SQL Server: Novas ferramentas para diagnosticar a sa&#250;de do &#237;ndice
SQL Server Randy Dyess

Novas ferramentas para diagnosticar a saúde do índice
Visão geral:
  • Fragmentação de índices
  • Uso de índices
  • Atividade operacional dos índices
Faça download do código deste artigo: DyessSQLIndex2007_03.exe (151KB)

Um dos principais itens em qualquer lista de verificação para ajuste de desempenho do SQL Server é o refinamento dos índices em um banco de dados. A capacidade do otimizador de consultas do SQL Server de utilizar corretamente os índices durante a execução de uma consulta depende não só da criação de índices efetivos, mas
também do bom funcionamento desses índices. Uma série de DMVs (modos de exibição dinâmicos de gerenciamento) e DMFs (funções dinâmicas de gerenciamento) introduzidos no SQL Server™ 2005 podem ajudar os administradores de banco de dados a determinar a eficácia de seus índices e a descobrir problemas de desempenho.
DMVs e DMFs permitem examinar um servidor e retornar informações sobre o estado desse servidor que ajudem a monitorar o funcionamento e o desempenho da instância do servidor e a diagnosticar problemas. Os administradores de bancos de dados familiarizados com as versões anteriores do SQL Server perceberão que esses DMVs e DMFs substituirão o uso de comandos DBCC, a execução de certos procedimentos armazenados do sistema, a consulta de várias tabelas do sistema e a captura de eventos com o SQL Profiler.
Três funções e modos de exibição principais, ou seja, sys.dm_db_index_physical_stats, sys.dm_db_index_usage_stats e sys.dm_db_index_operational_stats, estão disponíveis para ajudá-lo a compreender se os seus índices estão funcionando conforme esperado. Eles permitem revisar a E/S e os padrões de bloqueio dos índices e compreender se os índices estão sendo utilizados pelo otimizador de consultas de uma forma a não resultar em uma disputa desnecessária no banco de dados.

Fragmentação de índices
A DMF sys.dm_db_index_physical_stats foi criada como substituição para o DBCC SHOWCONTIG e mostrará uma fragmentação de índice. Entretanto, ao contrário do DBCC SHOWCONTIG, que insere um bloqueio compartilhado (S) na tabela que contém o índice, sys.dm_db_index_physical_stats apenas insere um bloqueio compartilhado intencional (IS), o que reduz significativamente o bloqueio da tabela durante a execução da função.
Para determinar a fragmentação de um índice ao usar sys.dm_db_index_physical_stats, examine uma combinação de três colunas na saída da função. A fragmentação lógica de índices (fragmentação da extensão de heaps) pode ser determinada examinando o valor retornado na coluna avg_fragmentation_in_percent column. A fragmentação lógica é a porcentagem de páginas que estão desorganizadas no nível de folha de um índice, enquanto a fragmentação de extensão é a porcentagem de extensões fora de ordem no nível de folha de um índice. A fragmentação lógica e a fragmentação lógica de extensão podem afetar o desempenho de um índice, exigindo E/S adicional e movimentação do cabeçote de disco, pois esse cabeçote deve saltar de forma a ler as páginas em ordem. Você deve fazer o máximo para manter o nível da fragmentação lógica e da fragmentação de extensão o mais próximo possível de zero.
A fragmentação interna de um índice é a porcentagem de plenitude da página. É claro que você deseja ter a página de índice mais cheia possível, mas também precisa equilibrar a plenitude com base no número de inserções em páginas de índice de forma a manter o número de divisões de página no mínimo absoluto.
O argumento avg_page_space_used_in_percent de sys.dm_db_index_physical_stats deve ser examinado para determinar a plenitude da página de índice. Para configurar corretamente o quão próximo esse número se encontra de 100 por cento, ajuste o fator de preenchimento de um índice ao observar o número de divisões de página que estão ocorrendo. Em um determinado ponto, o número de divisões de páginas começará a aumentar dramaticamente, indicando que você definiu o fator de preenchimento de um índice como um nível maior que o necessário. O ajuste do fator de preenchimento de um índice exige tempo e os testes não devem ser feitos sem um planejamento correto. (Índices que não têm inserções aleatórias em um índice podem ter seus fatores de preenchimento definidos como 100 sem se preocuparem com divisões de páginas maiores.)
Para determinar os níveis de fragmentação de todos os índices na tabela AdventureWorks.HumanResources.Employee, você pode usar uma instrução como esta:
SELECT *
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,OBJECT_ID('HumanResources.Employee')
,NULL
-- NULL to view all indexes;
-- otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') -- We want all information
Use essa DMF para determinar automaticamente quais índices precisam ser reconstruídos, quais precisam ser reorganizados e quais precisam de manutenção. O exame dos valores das colunas avg_page_space_used_in_percent e avg_fragmentation_in_percent dessa DMF para a fragmentação de índice fora do limite aceito de lógica e densidade pode ajudar a determinar qual operação deve ser executada no índice.
Dependendo do estado dos índices, o exemplo mostrado na Figura 1 pode não retornar dados na sua cópia do exemplo do banco de dados da AdventureWorks, mas pode ser facilmente adaptado a outros bancos de dados.
Figure 1 Examinando a plenitude e a fragmentação de páginas (Close Figure 1)
--Reorganize the following indexes in the AdventureWorks database
USE AdventureWorks
GO

SELECT OBJECT_NAME([object_id]) AS 'Table Name',
index_id AS 'Index ID'
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 10
AND avg_fragmentation_in_percent < 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 75
AND avg_page_space_used_in_percent > 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes

--Rebuild the following indexes in the AdventureWorks database
USE AdventureWorks
GO

SELECT OBJECT_NAME([object_id]) AS 'Table Name',
index_id AS 'Index ID'
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes
Seria fácil armazenar os resultados das consultas em uma variável de tabela e efetuar um loop nessa variável para criar uma seqüência de caracteres dinâmica referente à instrução ALTER INDEX correta (consulte a Figura 2).
Figure 2 Criando uma seqüência de caracteres ALTER INDEX dinâmica (Close Figure 2)
--Rebuild the following indexes in the AdventureWorks database
USE AdventureWorks
GO

--Table to hold results
DECLARE @tablevar TABLE(lngid INT IDENTITY(1,1), objectid INT,
index_id INT)

INSERT INTO @tablevar (objectid, index_id)
SELECT [object_id],index_id
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes

SELECT 'ALTER INDEX ' + ind.[name] + ' ON ' + sc.[name] + '.'
+ OBJECT_NAME(objectid) + ' REBUILD'
FROM @tablevar tv
INNER JOIN sys.indexes ind
ON tv.objectid = ind.[object_id]
AND tv.index_id = ind.index_id
INNER JOIN sys.objects ob
ON tv.objectid = ob.[object_id]
INNER JOIN sys.schemas sc
ON sc.schema_id = ob.schema_id

Uso de índices
Embora sys.dm_db_index_physical_stats seja um eficiente substituto para o DBCC SHOWCONTIG e possa ajudar a revelar o funcionamento de um índice, você muitas vezes enfrentará o problema mais complexo de determinar quais índices são úteis para as consultas executadas com base em uma tabela. Freqüentemente, os desenvolvedores ou administradores de bancos de dados criam índices em uma tabela que eles acham que serão usados pelo otimizador de consultas durante a execução de uma consulta. Em edições anteriores do SQL Server, era muito mais difícil saber se esses índices estavam realmente sendo usados. Era necessário remover o índice e detectar se o desempenho das consultas estava sendo afetado ou capturar os planos de execução das consultas e verificar o uso do índice.
Existe um novo modo de exibição dinâmico de gerenciamento, sys.dm_db_index_usage_stats, que facilita a compreensão de como os índices estão sendo utilizados pelo otimizador de consultas e como as consultas são executadas com base em uma tabela. Esse modo de exibição pode ser examinado para determinar a utilidade de um índice, permitindo que você remova todos os índices que não estão sendo usados pelo otimizador de consultas. Já não é mais necessário preocupar-se com a possibilidade de um índice estar desperdiçando espaço de armazenamento ou de a manutenção de índices não usados estar prejudicando o desempenho do banco de dados.
Com o exame da saída desse DMV para a detecção de índices sem procuras e verificações, você pode determinar se um índice foi usado desde a última vez que o SQL Server foi iniciado. Entretanto, lembre-se de que muitos DMVs e DMFs não são preservados e serão zerados quando o SQL Server for reiniciado. Leve isso em considerado ao usar um DMV ou DMF para determinar o uso de um índice. O índice pode simplesmente não ter sido necessário desde a último vez em que o serviço foi reiniciado, mas é necessário nas consultas executadas aos finais de semana, ao final do mês ou a cada quinze dias.
Para visualizar todos os índices em uma instância que não foram usados desde o último reinício do serviço SQL Server, a seguinte instrução pode ser usada:
SELECT DB_NAME(database_id),OBJECT_NAME([object_id])
FROM sys.dm_db_index_usage_stats
WHERE user_seeks = 0
AND user_scans = 0
AND user_lookups = 0
AND system_seeks = 0
AND system_scans = 0
AND system_lookups = 0

Atividade operacional dos índices
Se você quiser compreender a atividade operacional dos índices, a DMF sys.dm_db_index_operational_stats será bastante útil. Use-a para visualizar a atividade de E/S, de bloqueio e de método de acesso em cada índice de um banco de dados, o que pode ajudar a compreender como esses índices estão sendo usados e a diagnosticar problemas de bloqueio de índices devido a atividades extensas de E/S ou à existência de uma área de tensão no índice.
Use as colunas de travamento de linha nessa DMF para ajudar a estabelecer o tempo necessário para as operações READ e WRITE adquirirem acesso aos recursos de um índice. Isso pode ajudá-lo a determinar se o subsistema de disco usado para armazenar o índice é adequado para a atividade de E/S desse índice. Também pode indicar se o design e o uso do índice introduziram uma área de tensão na qual a atividade extensa em uma ou mais páginas de um índice causa disputa pelos dados contidos nessas páginas. Essa disputa muitas vezes resulta no bloqueio excessivo de operações que tentam efetuar ações READ ou WRITE nessa área.
A Figura 3 mostra como determinar os padrões de bloqueio e de E/S para todos os índices na tabela AdventureWorks.HumanResources.Employee.
Figure 3 Determinando padrões de bloqueio e de E/S (Close Figure 3)
SELECT page_latch_wait_count --page latch counts
,page_latch_wait_in_ms --page latch wait times
,row_lock_wait_in_ms --row lock wait times
,page_lock_wait_in_ms --page lock wait times
,row_lock_count --row lock counts
,page_lock_count --page lock counts
,page_io_latch_wait_count --I/O wait counts
,page_io_latch_wait_in_ms --I/O wait times
FROM sys.dm_db_index_operational_stats (DB_ID('AdventureWorks')
,OBJECT_ID('HumanResources.Employee')
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
)

Descubra mais
Os DMVs e as DMFs apresentados neste artigo podem ser usados de várias outras formas além das descritas aqui. Aproveite para revisar os artigos no SQL Server Books Online que descrevem as funções e os modos de exibição apontados na barra lateral "Recursos adicionais", para compreender a ampla variedade de informações que podem ser retornadas e examinadas com o uso desses recursos.
Para conhecer alguns DMFs e DMVs de índices adicionais não discutidos neste artigo, consulte a publicação de blog feita pela equipe de otimização de consultas do SQL Server no endereço blogs.msdn.com/queryoptteam/570176.aspx (em inglês).
Recursos adicionais
  • sys.dm_db_index_physical_stats
  • sys.dm_db_index_usage_stats
  • sys.dm_db_index_operational_stats

Randy Dyess é orientador na Solid Quality Learning, onde é especialista em sistemas OLTP do SQL Server. Randy é autor de vários livros e artigos sobre o SQL Server. Além disso, é fundador e principal autor dos sites www.TransactSQL.Com e www.Database-Security.Info.
© 2007 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..


 SQL Server: Atingir a alta disponibilidade do SQL Server
SQL Server Zach Nichter

Atingir a alta disponibilidade do SQL Server
Visão geral:
  • Espelhamento
  • Instantâneos de banco de dados
  • Envio de log
  • Agrupamento
  • Replicação
Faça download do código deste artigo: NichterHA2007_03.exe (151KB)

Alta disponibilidade é um conceito que todos os administradores de banco de dados devem entender. Refere-se à prontidão e acessibilidade de um sistema. Às vezes, alta disponibilidade indica um tempo de resposta de segundos enquanto outras situações exigem tempos de respostas em

frações de segundo. Uma vez fiz consultoria em uma empresa onde os servidores da Web exigiam que as consultas do SQL tivessem tempos de resposta de ida e volta em milissegundos; se a resposta ultrapassasse o limite, o sistema do banco de dados era considerado com falha e o servidor da Web deveria ser reconectado no próximo servidor de banco de dados disponível.
Com a exigência de aplicativos cada vez mais rápidos feita pelos usuários, saber como atingir a alta disponibilidade e tempos de resposta rápidos o ajudará a planejar seus aplicativos dependentes de dados de forma adequada.
Felizmente, o SQL Server™ 2005 tem várias opções para melhorar a disponibilidade, incluindo a replicação, o agrupamento, o espelhamento do banco de dados, os instantâneos de bancos de dados e o envio de logs do banco de dados. Irei analisar esses recursos e fornecer algumas informações para que você possa decidir quais são os recursos certos para o seu ambiente. Vamos começar com a Figura 1, que descreve as opções de disponibilidade do SQL Server 2005.
Figure 1 Opções de alta disponibilidade (Close Figure 1)

Atributos da tecnologia | Replicação | Espelhamento do banco de dados | Agrupamento | Instantâneos de bancos de dados | Envio de log
Opção de alta disponibilidade |  |  |  |  |
Tolerar requisitos de alta transação |  |  |  |  |
Disponibilidade dos dados em tempo real |  |  |  |  |
A imagem dos dados é somente leitura |  |  |  |  |
Configuração de hardware exclusiva |  |  |  |  |
Baixo custo |  |  |  |  |
Fornece a recuperação de dados |  |  |  |  |
Failover automático |  |  |  |  |
Implementação/gerenciamento possivelmente complexo |  |  |  |  |
Possíveis considerações sobre o desempenho |  |  |  |  |

Definição de alta disponibilidade
Um de seus primeiros objetivos ao planejar um aplicativo de alta disponibilidade é definir o que isso significa em seu ambiente específico. Para algumas organizações, alta disponibilidade indica que deve haver um hardware redundante igual ao hardware de produção, o que requer que os dados e o hardware tenham duração e disponibilidade de 99,995% ou mais. Outras organizações podem exigir que apenas os dados propriamente ditos tenham alta disponibilidade, sem tanta preocupação com o desempenho do nível de produção caso um failover seja necessário. Definir a alta disponibilidade é importante para determinar a solução correta para sua situação.
Também é necessário identificar os tipos de interrupções que podem ocorrer e indicar como isso afeta seus SLAs (Contratos de nível de serviço). As interrupções que podem afetar a disponibilidade incluem o desempenho planejado, não planejado e degradado.
Uma interrupção planejada normalmente é uma janela de manutenção programada sobre a qual os usuários dos sistemas são informados com antecedência. Uma interrupção não planejada geralmente resulta de uma falha de hardware ou software que torna os dados inacessíveis. A degradação do desempenho também pode provocar interrupções e normalmente é medida no tempo de resposta do usuário final, que em geral faz um acordo com antecedência com os negócios e a organização de TI através de algum tipo de SLA.
Além de identificar possíveis fontes de interrupção, também é necessário determinar o nível de atividade dos dados e ser estes devem estar sempre online ou podem ficar quase na linha ou offline ocasionalmente. Decida também se a opção de disponibilidade estará no mesmo local geográfico ou em um local remoto. Os limites do orçamento provavelmente influenciarão em sua decisão final. Agora, vamos analisar cada opção de disponibilidade.

Espelhamento do banco de dados
Antes de mergulharmos no espelhamento do banco de dados, vamos definir a terminologia.
Principal é o servidor de produção principal que hospeda o banco de dados que envia os logs de transação continuamente para o servidor de espelhamento e o banco de dados.
Espelhamento é o servidor secundário que hospeda a cópia de backup do banco de dados. A cópia de espelhamento é sincronizada de modo consistente com o banco de dados principal.
Função indica a finalidade do servidor específico, se este atua como principal ou espelhamento.
Testemunha é a instância que monitora os servidores principal e de espelhamento à medida que realizam suas obrigações e pode iniciar um failover automático.
Parceiro pode ser o servidor principal ou o de espelhamento.
Em um ambiente típico, será feito um backup do banco de dados principal na instância principal e o backup será restaurado na instância de espelhamento (consulte a Figura 2). Após o banco de dados ser restaurado, o espelhamento deve ser configurado no servidor principal com a janela de propriedades do banco de dados principais no SQL Server Management Studio (SMSS) ou com os scripts T-SQL.
Figure 2 Database mirroring architecture
Figure 2 Database mirroring architecture (Clique na imagem para diminuir a exibição)
Figure 2 Database mirroring architecture
Figure 2 Database mirroring architecture (Clique na imagem para aumentar a exibição)
Após a configuração do espelhamento e o estabelecimento da sessão de espelhamento, os bancos de dados principal e espelhado serão sincronizados. O banco de dados principal enviará os logs de transação dos eventos ocorridos desde que o último backup foi aplicado no espelhamento. O espelhamento receberá o log e tentará aplicá-lo o mais rápido possível. Se estiver usando o SQL Server 2005 Enterprise Edition, esse processo terá vários threads; caso contrário, será uma operação de um único thread. Assim que os logs são aplicados no espelhamento, os bancos de dados são considerados sincronizados e permanecerão sincronizados até a sessão espelhada ser rompida.
Conforme os clientes executam novas transações, o servidor principal executa as transações no banco de dados principal e, ao fazer isso, envia os registros de log de transação do banco de dados principal para o log de retrabalho ou consultas de log do banco de dados espelhado, onde são selecionados e aplicados no banco de dados espelhado. Após a transação ser aplicada e confirmada no banco de dados de espelhamento, uma resposta é enviada ao principal anunciando que a transação foi confirmada no espelhamento. O principal não confirmará nenhuma transação nova que pode vir ao sistema até que o espelhamento reconheça o recebimento.
Em caso de falha, o espelhamento pode iniciar uma falha automática e a testemunha suporta processo determinando se o banco de dados principal está disponível. Quando a falha ocorre, o problema sobre o conteúdo do parceiro de espelhamento deve ser resolvido antes de se tornar novamente o parceiro principal. Após solucionar os problemas no parceiro de espelhamento, a volta ao servidor-parceiro de espelhamento é iniciada e os bancos de dados são sincronizados novamente. Após a sincronização, a sessão de espelhamento pode ser reiniciada.
Esse modo de espelhamento específico é um modo de alta segurança que fornece operações transacionais síncronas ativando a segurança transacional, mas um servidor-testemunha não é necessário já que não aproveita o failover automático; todos os failovers são iniciados manualmente. Há outro tipo de modo de espelhamento que fornece operações transacionais síncronas, o modo de alta disponibilidade. Esse modo requer não só a ativação da segurança transacional, mas também uma testemunha usada para failovers automáticas em caso de falha.
O terceiro e último modo disponível de espelhamento é o de alto desempenho. Esse modo requer a desativação da segurança transacional, permitindo o suporte operacional assíncrono que, por usa vez, permite a confirmação das transações no parceiro principal sem precisar aguardar a gravação do registro da transação no espelhamento. O modo de alto desempenho não requer um servidor-testemunha da configuração.
Observe que o espelhamento requer a mesma edição do SQL Server no principal e no espelhamento, mas não no testemunha, que pode ser o SQL Server Express Edition. Além disso, é importante que o banco de dados principal esteja no modo de recuperação total.
O ADO.NET 2.0 é integrado no SQL Server 2005 e inclui a capacidade de oferecer suporte ao espelhamento do banco de dados e fornecer um failover transparente para o aplicativo no ambiente espelhado. Isso permite que o aplicativo ADO.NET realize o failover automaticamente sem nenhuma codificação ou configuração adicional caso não seja possível estabelecer uma conexão com o banco de dados principal. A configuração é tão fácil quanto especificar um usuário comum entre os dois ambientes e o parceiro de failover na cadeia de conexão. O exemplo a seguir mostra uma seqüência de conexão do ADO.NET identificando o parceiro de failover para o ambiente do banco de dados espelhado:
"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
 Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"
O espelhamento do banco de dados é uma boa opção para sua empresa dependendo dos requisitos de aplicativos e de dados, mas você deve considerar algumas coisas para obter o desempenho ideal. Por exemplo, qual é a taxa de transação do sistema ou o volume de alteração de dados? Ao considerar o espelhamento do banco de dados, é fundamental determinar se a largura de banda e a velocidade da rede são suficientes para manipular o volume de dados e a taxa de processamento da transação. Além disso, considere a saturação do link. Isso é importante especialmente se o espelhamento estiver em um local geográfico diferente. O monitoramento prévio do sistema é fundamental para determinar se há algum limite ambiental que pode impedir a operação eficaz do espelhamento.
O espelhamento do banco de dados pode ser uma boa opção especialmente se estiver tentando manter os custos baixos. De fato, a arquitetura do espelhamento do banco de dados não requer nenhum disco compartilhado e nenhum recurso avançado ou especializado para executar o ambiente. E, diferente do agrupamento, o espelhamento do banco de dados não requer que os dois parceiros tenham o mesmo hardware. Além disso, é muito simples implementar o espelhamento usando o assistente de configuração encontrado na guia de espelhamento da janela de propriedades do banco de dados (consulte a Figura 3). Também recomendo a leitura do white paper “Práticas recomendadas do espelhamento do banco de dados e considerações sobre desempenho” em go.microsoft.com/fwlink/?LinkId=80897 para obter informações mais úteis.
Figure 3 Mirroring setup wizard
Figure 3 Mirroring setup wizard (Clique na imagem para diminuir a exibição)
Figure 3 Mirroring setup wizard
Figure 3 Mirroring setup wizard (Clique na imagem para aumentar a exibição)

Instantâneos de bancos de dados
Os instantâneos de bancos de dados são uma nova tecnologia oferecida no SQL Server 2005 Enterprise Edition, mas não são considerados opções de alta disponibilidade. Esses instantâneos devem ser usados como uma opção viável de recuperação ou criação de relatórios quando usados com outras tecnologias. Um instantâneo é simplesmente uma exibição somente leitura de um banco de dados em um momento específico.
O instantâneo é criado com um comando CREATE DATABASE como esse:
CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME =
    'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO
Quando o instantâneo do banco de dados é criado, usa um ou vários arquivos chamados de arquivos esparsos em vez dos arquivos de dados como um banco de dados típico faria. Esses arquivos esparsos são basicamente locais de hospedagem virtual que, a princípio, não consomem nenhum dado. São usados para preservar dados apenas se os dados forem alterados ou excluídos do banco de dados de origem. Os dados são gravados nos arquivos esparsos, uma página de dados por vez, e o instantâneo do banco de dados real exibe apenas os dados que foram alterados desde que o instantâneo foi criado. O resto dos dados vem das páginas de dados do banco de dados de origem.
Os arquivos de instantâneo do banco de dados têm o tamanho do banco de dados quando o instantâneo foi criado. O tamanho alocado não informa quantos dados realmente estão preservados. Para obter essa informação, execute uma instrução T-SQL como essa:
SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
    2030'), 1);
GO

Devido à maneira de armazenamento dos dados nos arquivos esparsos e no banco de dado de origem, quando um instantâneo do banco de dados é acessado, as páginas de dados dos arquivos do banco de dados original e as páginas dos arquivos esparsos do instantâneo são recuperadas. Os instantâneos podem residir apenas no servidor com o banco de dados de origem do qual o instantâneo foi criado devido à necessidade de compartilhar páginas de dados. Como essa arquitetura não ajuda a E/S no banco de dados de origem, os instantâneos não são uma opção válida de criação de relatórios a ser usada visto que não representam o verdadeiro estado do banco de dados.
Considere um cenário no qual o espelhamento no banco de dados é usado com instantâneos. Isso permite que os dados de relatório, o espelhamento e os bancos de dados do instantâneo sejam separados fisicamente do banco de dados principal. O instantâneo do banco de dados é programado com o SQL Server Agent e um script personalizado para fornecer instantâneos atualizados em intervalos regulares. O script de exemplo da Figura 4 mostra o procedimento armazenado usado para realizar isso. Esse script foi desenvolvido para ser usado dentro de um trabalho para gerenciar a criação e a eliminação de instantâneos de um banco de dados específico em seu ambiente. Isso possibilitaria uma solução aceitável de criação de relatórios porque os dados de relatório seriam isolados dos dados de produção.
Figure 4 Procedimento armazenado para a programação de instantâneos (Close Figure 4)
use msdb;
GO
set nocount on
GO

CREATE PROCEDURE usp_snaprefresh
     @database    sysname = NULL    --name of the database to snapshot
    ,@keepsnap    int        = 24   --# of hours to keep a snapshot
                                    --after it was created
                                    --use a value of '0' to keep all
                                    --existing snapshots
    ,@fileloc    sysname            --location for snapshot
        = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'
AS

DECLARE
     @dt            datetime        ,@cnt          int
    ,@databaseid    int             ,@snap         sysname
    ,@sql           nvarchar(1000)  ,@yy           varchar(4)
    ,@mm            varchar(2)      ,@dd           varchar(2)
    ,@h             varchar(2)      ,@m            varchar(2)
    ,@lname         sysname         ,@pname        sysname
    ,@file          sysname         ,@pos1         int
    ,@pos2          int

-- initialize variables
SELECT
     @dt = getdate()
    ,@cnt = 0, @pos1 = 0, @pos2 = 0
    ,@databaseid = db_id(@database)

-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
    RAISERROR ('Missing database name. Rerun the procedure specifying a
       valid database name.',16,1)
    RETURN (0)
END

--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
    -- determine if other snapshots exist for this server older than @
    -- keepsnap value hrs
    SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum],
        name INTO #t1
    FROM master.sys.databases
    WHERE source_database_id = @databaseid
        AND create_date < dateadd(hh,-(@keepsnap),getdate())

    IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
    BEGIN
        WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
        BEGIN
            SELECT @snap = name FROM #t1 WHERE RowNum = @cnt

            PRINT 'Dropping snapshot ''' + @snap + ''''

            SET @sql = 'DROP DATABASE ' + @snap

            EXEC(@sql)
            SELECT @cnt = @cnt + 1
        END
    END
END

-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
   month(@dt))
    ,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
         datepart(hh,@dt))
    ,@m = convert(varchar(2), datepart(mi,@dt))

-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m

-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files
WHERE file_id = 1'

EXEC(@sql)

--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1

-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
    SET @fileloc = @fileloc + '\'
END

-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database

EXEC(@sql)

-- cleanup
DROP TABLE tempdb..t1;
GO
No entanto, tenha em mente que os instantâneos de bancos de dados são considerados temporários porque não é possível fazer um backup desses instantâneos e eles não podem existir sem o banco de dados de origem. Se o arquivo esparso não tiver espaço, o instantâneo será considerado corrompido e deve ser eliminado.
Além disso, com os instantâneos do banco de dados, o desempenho do sistema pode ser degradado durante as operações de modificação de dados no banco de dados de origem porque as páginas de dados estão sendo gravadas no arquivo esparso de cada instantâneo dos arquivos de dados do banco de dados de origem. Isso, por sua vez, multiplica o número de gravações pelo número de instantâneos que um banco de dados tem.
As permissões de leitura são definidas pelo banco de dados de origem no ponto do instantâneo e não podem ser alteradas. O instantâneo deve residir na mesma instância do banco de dados de origem devido ao compartilhamento das páginas de dados e ao mesmo cache de buffer.
Avalie a possibilidade de usar os instantâneos como uma solução de criação de relatórios apenas se o espelhamento também estiver sendo usado; caso contrário, não haverá nenhum ganho de desempenho para o seu ambiente. Os instantâneos de bancos de dados são possivelmente a maneira mais rápida de preservar dados antes que uma operação questionável seja executada no sistema. Um banco de dados pode regressar ao estado do instantâneo ou os dados podem ser excluídos do instantâneo para substituir os dados no banco de origem.
É necessário determinar um padrão de nomeação para os bancos de dados do instantâneo. O padrão que eu uso é originaldatabasename_date_time.snp. Esse padrão especifica primeiramente o banco de dados de origem e, em seguida, o dia e a hora (no formato 24 horas) em que o instantâneo foi criado.

Envio de log
O envio de log é uma opção de alta disponibilidade limitada que utiliza o backup e a recuperação para estabelecer uma solução bem barata. O envio de log aproveita os backups de logs de transação em um intervalo programado para manter um banco de dados secundário atualizado.
O envio de log no SQL Server 2005 usa assistentes para percorrer o processo de configuração, programação, inicialização e monitoramento (consulte a Figura 5). O processo é simples e pode ser concluído em alguns minutos.
Figure 5 Log shipping setup wizard
Figure 5 Log shipping setup wizard (Clique na imagem para diminuir a exibição)
Figure 5 Log shipping setup wizard
Figure 5 Log shipping setup wizard (Clique na imagem para aumentar a exibição)

Após a identificação do banco de dados primário, uma programação é criada e a idade do arquivo determinada para os arquivos de backup. Em seguida, é necessário estabelecer os compartilhamentos de arquivo para os arquivos de backup. Após a configuração dos compartilhamentos, o local do arquivo do banco de dados secundário deve ser estabelecido e o banco de dados deve ser inicializado concluindo a restauração do banco de dados primário. Finalmente, as programações devem ser definidas para as cópias do arquivo de backup e os backups de logs de transação devem ser restaurados, junto com os alertas ou atrasos necessários para cada etapa.
Quando a configuração está concluída, o envio de log faz o backup do log de transação de um banco de dados em um intervalo programado, em um local de rede compartilhado. Após os arquivos serem enviados para o compartilhamento, o backup é ativado no banco de dados secundário em uma programação definida.
O envio de log funciona bem em muitas situações devido a sua simplicidade. É uma boa opção de alta disponibilidade que é barata e pode manipular um sistema de altas transações. O banco de dados secundário empregado no envio de log pode ser usado no modo somente leitura, o que é útil para um banco de dados de criação de relatórios. O envio de log requer uma sobrecarga mínima, mas precisa de uma diretriz de alertas para a manipulação de falhas.
Algumas coisas devem ser consideradas se você estiver pensando em usar o envio de log em seu ambiente, são elas: a configuração e o gerenciamento simples e o fato de poucos ou nenhum recurso especializado serem necessários. O envio de log não é uma solução de alta disponibilidade em tempo real; no entanto, é possível combiná-lo com o espelhamento do banco de dados para essa finalidade. É limitado por programações e operações, como backups, cópias de arquivos e restaurações. Também requer o failover manual. Por esses motivos, o envio de log fornece uma solução simples para o ambiente que não é tão sensível aos requisitos de tempo.

Agrupamento do SQL Server
O agrupamento do servidor funciona no nível do sistema operacional e envolve hardwares duplicados, bem como recursos do disco compartilhado para o acesso do cluster. O agrupamento talvez seja a opção menos intrusiva para os usuários finais, mas provavelmente também é a mais cara. Requer pelo menos a quantia de hardware necessária para executar uma instância não agrupada.
O tópico de agrupamento é bastante discutido e, em vez de explorar todos os detalhes aqui, farei uma breve visão geral. O agrupamento requer dois ou mais servidores e ambos devem ser instalados com a mesma versão do Windows® 2000, edições Advanced ou Datacenter ou do Windows Server® 2003, edições Enterprise ou Datacenter. Também requer a instalação do Microsoft® Cluster Services (MSCS), que trata da propriedade do recursos compartilhados entre os servidores e gerencia endereços IP, discos compartilhados e nomes de rede. O agrupamento também requer um recurso de disco compartilhado, normalmente na forma de uma SAN (Rede de área de armazenamento) ou do armazenamento SCSI conectado.
Uma instância do SQL Server também é considerada um recurso e as edições Standard e Enterprise do SQL Server 2005 podem ser instaladas em uma configuração em cluster. Consulte o artigo “Feature Comparison Chart for SQL Server 2005”, em microsoft.com/sql/prodinfo/features/compare-features.mspx, para obter uma lista dos recursos suportados pelas duas edições do SQL Server 2005.
Após o estabelecimento dos recursos no cluster, o nó secundário e do cluster mantém uma comunicação regular com o nó primário do cluster através de uma pulsação estabelecida em uma rede privada entre os dois nós do cluster. A pulsação é um ponto de verificação de intervalo criado para determinar se o primário falhou.
Caso o primário falhe, os recursos serão movidos para o nó secundário, mas o estado do servidor lógico será mantido. Isso permite que os clientes continuem funcionando com apenas uma pausa na interação. O processo inteiro de failover pode ocorrer entre 5 ou 30 segundos ou mais em alguns casos, dependendo do hardware, do software e dos componentes de rede envolvidos no cluster.
O agrupamento pode ser uma tecnologia cara e complexa que requer recursos especializados para resolver falhas do sistema; no entanto, fornece o failover mais uniforme para os usuários finais de qualquer opção de failover automático. Cada aplicativo é diferente e alguns talvez não reconheçam ou sejam compatíveis com cluster, o que requer a reconexão do aplicativo em ambientes desfavoráveis.

Replicação
A replicação do SQL Server 2005 também pode ser usada em arquiteturas de alta disponibilidade. Há quatro tipos de replicação: de instantâneos, transacional, ponto a ponto e mesclagem. Na realidade, ponto a ponto é apenas uma forma de replicação transacional que não irei discutir aqui.
Com a replicação, é possível que um local secundário e o banco de dados de alta disponibilidade em que cada bit é tão funcional quanto no banco de dados primário. Isso pode ser realizado com a replicação de mesclagem, que toma as transações dos bancos de dados primário e secundário e as mesclas e altera entre si. Como você pode imaginar, um procedimento de resolução de conflitos é necessário nessa configuração.
A replicação transacional é muito similar ao design lógico do espelhamento do banco de dados. As transações aplicadas no banco de dados primário são enviadas para o banco de dados secundário a fim de assegurar que o ambiente permaneça consistente. Assim que chegam, as transações são aplicadas no banco de dados secundário, que aguarda a aplicação da próxima transação no sistema.
A replicação de instantâneos é muito similar ao envio de log, pois ambos são executados em intervalos programados e atualizam o banco de dados secundário em alterações de massa em vez de aplicar cada transação nos dois sistemas assim que são confirmadas. As duas tecnologias são utilizadas da mesma maneira em muitos aspectos.
A replicação requer um conhecimento especializado, o que é uma grande preocupação para os ambientes que não contam com um administrador de banco de dados dedicado. A replicação pode ser um pouco complexa na solução de problemas e não requer um design mais envolvido se não for usado como uma opção de alta disponibilidade.
A replicação pode preencher adequadamente todos os requisitos de uma solução de alta disponibilidade. Essa tecnologia faz o que o espelhamento do banco de dados pode fazer no nível do registro usando a replicação transacional, mas sem a opção de failover automático. Supondo que você tenha recursos suficientes e um pouco de criatividade, criar scripts de uma solução para um failover automático não deve ser impossível.
Diferente do espelhamento do banco de dados, os bancos de dados de origem e de destino são totalmente acessíveis para os aplicativos cliente. A replicação fornece a mesma funcionalidade do envio de log com o uso da replicação de instantâneos.
No entanto, é preciso levar em conta que a tecnologia de replicação é uma batalha comprovada e bem documentada. Usar a replicação para uma solução de alta disponibilidade tem alguns problemas e o desempenho pode ser uma preocupação, mas apenas tanto quanto o espelhamento do banco de dados. Qualquer solução de alta disponibilidade projetada com replicação provavelmente terá uma arquitetura mais complicada de gerenciar; não necessariamente mais avançada, mas definitivamente mais envolvida. Além disso, um dos maiores obstáculos a considerar é o fato de que se a estrutura de tabelas do banco de dados for alterada ou se desejar adicionar uma tabela para ser replicada, é necessário quebrar e redefinir a publicação para finalizar as alterações nos dois bancos de dados.

Conclusão
Agora, você pôde ver como a criação de uma solução de alta disponibilidade para seu ambiente requer um toque de criatividade. Cada tecnologia de alta disponibilidade do SQL Server 2005 tem suas vantagens e desvantagens e leva a situações diferentes.
O envio de log, a replicação de instantâneos e até mesmo o espelhamento do banco de dados no modo de alto desempenho seriam bons quando separassem geograficamente um banco de dados primário da Web dos ambientes do banco de dados secundário (especialmente se os dados secundários não tiverem que ser disponibilizados em tempo real).
Se, por outro lado, o banco de dados secundário exigir dados em tempo real, a replicação transacional ou o espelhamento do banco de dados pode levar a carga se as taxas de transação do servidor primeiro forem baixas e o link entre os dois locais do ambiente for rápido e não saturado.
Considere também seu nível de conforto com estas tecnologias. Se você já tiver experiência com algumas tecnologias, provavelmente não haverá problemas. Se você for um gerente com nenhum administrador de banco de dados dedicado, tente esclarecer as tecnologias mais complexas como a replicação, na qual existe muita movimentação de partes e a resolução de problemas pode ser complexa. Avalie a possibilidade de contratar um consultor experiente de SQL Server para ajudá-lo a projetar, implementar e possivelmente treinar sua equipe para gerenciar uma nova solução de alta disponibilidade adequada para seu ambiente.
Se a alta disponibilidade em sua organização requer apenas a disponibilidade dos dados, uma alta porcentagem de tempo e de inatividade dos dados é um fator grave e o agrupamento pode ser a solução.
A conclusão de tudo isso é que o SQL Server 2005 tem fornecido várias opções novas para a implementação de alta disponibilidade, feitas sob medida para atender diferentes tipos de ambiente. Uma única opção de disponibilidade pode satisfazer suas necessidades ou você pode aproveitar uma combinação de tecnologias. Como você sabe, existem várias opções disponíveis.

Zach Nichter é um profissional de SQL Server com mais de 10 anos de experiência. Ele tem assumido várias funções de suporte do SQL Server, incluindo administrador de banco de dados, chefe de equipe, gerente e consultor. Atualmente, Zach trabalha na Levi Strauss & Co. como o arquiteto do banco de dados, enfocando o desempenho, o monitoramento, a arquitetura e outras iniciativas estratégicas do SQL Server.


 SQL Server: Simplificar a manuten&#231;&#227;o de banco de dados com parti&#231;&#245;es de tabelas
SQL Server Noah Gomez

Simplificar a manutenção de banco de dados com partições de tabelas
Visão geral:
  • Criando tabelas particionadas
  • Adicionando e mesclando partições
  • Criando e gerenciando índices particionados
Faça download do código deste artigo: GomezPartitioning2007_03.exe (156KB)

No passado, os administradores de banco de dados que gerenciavam tabelas contendo milhões de linhas de dados eram forçados a criar várias tabelas. Após o particionamento dessas tabelas, o administrador precisava vinculá-las
novamente durante a execução de muitas de suas consultas. A vinculação de partições envolvia a criação de um modo de exibição particionado ou de um procedimento armazenado por invólucro que descobrisse a localização dos dados e que executasse outro procedimento armazenado de forma a atingir somente as partições necessárias para o retorno do conjunto de dados.
Embora esses métodos funcionassem, eles eram cansativos. A administração de várias tabelas e seus índices, bem como os métodos usados para a vinculação das tabelas, muitas vezes causavam problemas de administração e de manutenção. Além disso, a criação de várias tabelas para particionar dados resultava em um certo grau de inflexibilidade, já que os procedimentos armazenados, os trabalhos de manutenção, os trabalhos DTS (Data Transformation Services), o código de aplicação e os outros processos tinham que compreender a natureza do particionamento. Portanto, para possibilitar a adição ou a exclusão dessas partições aparentes sem modificar o código, esses elementos eram geralmente criados de maneira não dinâmica e, como resultado, não eram eficientes.
As edições Enterprise e Developer do SQL Server™ 2005 permitem particionar grandes quantidades de dados contidos em uma única tabela em várias partições menores que podem ser gerenciadas e mantidas de forma mais eficiente. A capacidade de criar segmentos de dados acessados por meio de um ponto de entrada único reduz muitos dos problemas de administração inerentes ao método antigo de se fazer as coisas. O uso de um ponto de entrada único (nome de tabela ou nome de índice) oculta os diversos segmentos de dados do código do aplicativo e permite que o administrador ou o desenvolvedor altere as partições conforme necessário sem precisar ajustar a base do código.
Em resumo, você pode criar várias partições, mover essas partições, eliminar partições antigas e até mesmo alterar a forma como os dados são particionados, sem precisar ajustar o código no aplicativo, o qual simplesmente continua a chamar a mesma tabela base ou o mesmo nome de índice. Enquanto isso, é possível reduzir a quantidade de dados contida em índices individuais, o que, por sua vezes, diminui os tempos de manutenção desses índices. Também é possível aumentar a velocidade da carga de dados, fazendo o carregamento em partições vazias.
Tecnicamente, cada tabela do SQL Server 2005 é particionada e cada uma tem pelo menos uma partição. O que o SQL Server 2005 faz é permitir que os administradores de banco de dados criem partições adicionais em cada tabela. Partições de tabela e de índice são partições em nível de linha e bem definidas (o particionamento por colunas não é permitido) que permitem um ponto de entrada único (nome da tabela ou nome do índice) sem que o código do aplicativo precise saber quantas partições existem por atrás desse ponto de entrada. Partições podem existir na tabela base e nos índices associados à tabela.

Criando tabelas particionadas
Você utiliza funções de partição e esquemas de partição para criar uma tabela capaz de crescer além da partição única padrão. Esses objetos são os que possibilitam a divisão dos dados em segmentos específicos e que permitem controlar onde esses segmentos de dados estão localizados no design de armazenamento. Por exemplo, você pode dispersar os dados em várias matrizes de unidade com base na idade dos dados ou usando outros diferenciadores comuns. Observe que uma tabela pode ser particionada com base em uma de suas colunas e cada partição deve conter dados que não podem ser inseridos em outras partições.
Funções de partições Ao particionar uma tabela, a primeira decisão é como você deseja dividir os dados em diferentes segmentos. Uma função de partição é usada para mapear as linhas individuais de dados nas diferentes partições. Essas linhas individuais de dados podem ser mapeadas por qualquer tipo de coluna, com exceção dos tipos de dados text, ntext, image, xml, timestamp, varchar(max), nvarchar(max), varbinary(max) e alias ou de tipos de dados definidos pelo usuário do CLR (Common Language Runtime). Entretanto, a função de particionamento deve ser capaz de inserir uma linha de dados em apenas uma partição de tabela. Ela não permite que uma linha de dados pertença a várias partições ao mesmo tempo.
Para particionar uma tabela, você deve criar a coluna de particionamento na tabela de destino. Essa coluna de particionamento pode existir no esquema de tabela quando a tabela é criada pela primeira vez ou você pode alterar essa tabela e adicionar a coluna posteriormente. A coluna pode aceitar valores NULL, mas todas as linhas contendo esses valores serão inseridas, por padrão, na partição localizada na extremidade esquerda da tabela. Isso pode ser evitado especificando-se que os valores NULL sejam inseridos na partição localizada na extremidade direita da tabela no momento que você criar a função de particionamento. O uso da partição esquerda ou direita será uma decisão de design importante à medida em que você modificar o esquema de particionamento e adicionar mais partições ou excluir partições existentes.
Ao criar uma função de particionamento, você pode optar por uma função de partição LEFT ou RIGHT. A diferença entre partições LEFT e RIGHT é o local em que os valores de limite serão inseridos no esquema de particionamento. Partições LEFT (o padrão) incluem o valor de limite na partição, enquanto partições RIGHT inserem o valor de limite na partição seguinte.
Para compreender esse conceito um pouco melhor, observe estas partições LEFT e RIGHT simples:
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

CREATE PARTITION FUNCTION Right_Partition (int) AS RANGE RIGHT
FOR VALUES (1,10,100)
Na primeira função (Left_Partition), os valores 1, 10 e 100 são inseridos na primeira, na segunda e na terceira partição, respectivamente. Na segunda função (Right_Partition), os valores são inseridos na segunda, na terceira e na quarta partição.
Ao criar uma tabela particionada, é importante fazer com que as partições sejam as mais uniformes possíveis. Isso o ajudará a perceber o espaço necessário para uma partição. O uso de LEFT e RIGHT determinará o local em que os dados serão inseridos, o que, por sua vez, determinará o tamanho da partição e o tamanho dos índices criados nessa partição.
Use a função $PARTITION para determinar o número da partição no qual um valor de dados será colocado, como mostra a seguir:
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Right_Partition (10)
Na primeira instrução SELECT, o resultado será 2. A segunda instrução SELECT retornará 3.
Esquemas de partição Depois de criar a função e de decidir como os dados serão divididos, você precisará decidir em que local as partições individuais serão criadas no subsistema de disco. Use esquemas de partição para criar esse layout de disco. Esquemas de partição gerenciam o armazenamento de disco de partições individuais, utilizando grupos de arquivos para inserir cada partição em um local no subsistema de disco. Você pode configurar esquemas de partição de forma que todas as partições sejam inseridas em um único grupo de arquivos, que todas as partições sejam inseridas em diferentes grupos de arquivos ou que várias partições compartilhem grupos de arquivos. Esse último método dá ao administrador do banco de dados uma grande flexibilidade na dispersão da E/S de disco.
A Figura 1 mostra algumas das possíveis maneiras de atribuir um grupo de arquivo ou vários grupos de arquivos a um esquema de partição. Lembre-se de que os grupos de arquivos usados pelo esquema de partição já devem existir no banco de dados para que você possa criar o esquema de particionamento.
Figure 1 Atribuindo grupos de arquivos a um esquema de partição (Close Figure 1)
--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the different filegroups
CREATE PARTITION SCHEME Different_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      TO (Filegroup1, Filegroup2, Filegroup3, Filegroup4)
--Filegroups must currently exist in database

--Place multiple partitions into the different filegroups
CREATE PARTITION SCHEME Multiple_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      TO (Filegroup1, Filegroup2, Filegroup1, Filegroup2)
--Filegroups must currently exist in database
Se você criar os exemplos de funções de partição, como mostra a Figura 1, e utilizar o esquema de partição para criar uma tabela, será possível determinar em que local as linhas de dados individuais serão inseridas nas tabelas recém-particionadas. Em seguida, você pode visualizar a distribuição dessas linhas de dados depois de inseridas na tabela particionada. O código para fazer isso terá uma aparência semelhante à da Figura 2.
Figure 2 Inserindo linhas de dados e visualizando a distribuição (Close Figure 2)
--Prepare database
IF OBJECT_ID('Partitioned_Table') IS NOT NULL
DROP TABLE Partitioned_Table
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
      ALL TO ([PRIMARY])

CREATE TABLE Partitioned_Table
(
col1 INT
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

--Determine where values will be placed (this is not required)
--You should try to do this before executing the code
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (2)
SELECT $PARTITION.Left_Partition (3)
SELECT $PARTITION.Left_Partition (4)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (11)
SELECT $PARTITION.Left_Partition (12)
SELECT $PARTITION.Left_Partition (13)
SELECT $PARTITION.Left_Partition (14)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)
SELECT $PARTITION.Left_Partition (102)
SELECT $PARTITION.Left_Partition (103)
SELECT $PARTITION.Left_Partition (104)

--Insert data into partitioned table
INSERT INTO Partitioned_Table VALUES (1,'Description')
INSERT INTO Partitioned_Table VALUES (2,'Description')
INSERT INTO Partitioned_Table VALUES (3,'Description')
INSERT INTO Partitioned_Table VALUES (4,'Description')
INSERT INTO Partitioned_Table VALUES (10,'Description')
INSERT INTO Partitioned_Table VALUES (11,'Description')
INSERT INTO Partitioned_Table VALUES (12,'Description')
INSERT INTO Partitioned_Table VALUES (13,'Description')
INSERT INTO Partitioned_Table VALUES (14,'Description')
INSERT INTO Partitioned_Table VALUES (100,'Description')
INSERT INTO Partitioned_Table VALUES (101,'Description')
INSERT INTO Partitioned_Table VALUES (102,'Description')
INSERT INTO Partitioned_Table VALUES (103,'Description')
INSERT INTO Partitioned_Table VALUES (104,'Description')

--View the distribution of data in the partitions
SELECT ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('Partitioned_Table')

Modificando tabelas particionadas
Mesmo com um cuidadoso planejamento antecipado, em certas ocasiões, será necessário ajustar as tabelas particionadas depois de criá-las e preenchê-las. O esquema de partição pode funcionar conforme planejado, mas, por exemplo, talvez você precise adicionar novas partições à medida que novos dados forem acumulados ou ainda eliminar grandes quantidades de dados particionados de uma vez. Felizmente, as tabelas particionadas e as estruturas de particionamento subjacentes possibilitam que alterações sejam feitas depois que a tabela for ativada e preenchida com dados.
Adicionar partições Muitos planos de particionamento incluem a capacidade de adicionar uma nova partição no futuro. Esse ponto no tempo pode ser uma data específica ou pode depender de um valor em uma coluna de identidade incremental. Entretanto, se você não tiver planejado essa antecipação, ainda será possível adicionar novas partições a uma tabela particionada no futuro. Considere a tabela criada na Figura 2. Você pode adicionar uma nova partição a essa tabela, de forma a conter valores superiores a 500, como este:
--Determine where values live before new partition
SELECT $PARTITION.Left_Partition (501)  --should return a value of 4

--Create new partition
ALTER PARTITION FUNCTION Left_Partition ()
SPLIT RANGE(500)

--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (501)  --should return a value of 5
A capacidade de adicionar partições oferece excelente flexibilidade. A Figura 3 mostra como adicionar uma partição ao lado esquerdo da função. Nesse caso, é preciso especificar ao esquema de particionamento um local para inserir a nova partição, pois você usou todos os grupos de arquivos criados na ocasião da construção inicial desse esquema. Mesmo que você esteja usando o grupo de arquivos PRIMARY para todas as suas partições, ainda é preciso fornecer instruções para que o esquema de particionamento reutilize o grupo de arquivos PRIMARY para a nova partição.
Figure 3 Adicionando uma partição ao lado esquerdo da função (Close Figure 3)
--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (5)   --should return a value of 2
SELECT $PARTITION.Left_Partition (1)   --should return a value of 1
SELECT $PARTITION.Left_Partition (10)  --should return a value of 2

--Add new filegroups to the partitioning scheme
ALTER PARTITION SCHEME Primary_Left_Scheme
NEXT USED [PRIMARY]

--Create new partition
ALTER PARTITION FUNCTION Left_Partition ()
SPLIT RANGE(5)

--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (5)   --should return a value of 2
SELECT $PARTITION.Left_Partition (1)   --should return a value of 1
SELECT $PARTITION.Left_Partition (10)  --should return a value of 3
Mesclar duas partições O SQL Server permite eliminar partições únicas de uma tabela e preservar os dados simultaneamente. Isso pode ser usado para mesclar dados ativos mais antigos em dados arquivados ou para reduzir o número de partições existentes, facilitando a administração da tabela particionada. Também é possível usar esse método para mesclar partições, movendo dados de um grupo de arquivos para outro de forma a liberar espaço em disco em determinadas matrizes de unidade. O código na Figura 4 mostra como é possível mover dados de uma partição para outra no mesmo grupo de arquivos.
Figure 4 Movendo dados de uma partição para outra (Close Figure 4)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

INSERT INTO multiple_partition VALUES (1,'Description')
INSERT INTO multiple_partition VALUES (2,'Description')
INSERT INTO multiple_partition VALUES (3,'Description')
INSERT INTO multiple_partition VALUES (4,'Description')
INSERT INTO multiple_partition VALUES (10,'Description')
INSERT INTO multiple_partition VALUES (11,'Description')
INSERT INTO multiple_partition VALUES (12,'Description')
INSERT INTO multiple_partition VALUES (13,'Description')
INSERT INTO multiple_partition VALUES (14,'Description')
INSERT INTO multiple_partition VALUES (100,'Description')
INSERT INTO multiple_partition VALUES (101,'Description')
INSERT INTO multiple_partition VALUES (102,'Description')
INSERT INTO multiple_partition VALUES (103,'Description')
INSERT INTO multiple_partition VALUES (104,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Check where data would be placed
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)

--Merge two partitions
ALTER PARTITION FUNCTION Left_Partition()
MERGE RANGE (10)

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Check where data would be placed
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)
Mover uma única tabela de partição para uma tabela particionada Durante rotinas de carga, grandes quantidades de dados muitas vezes precisam ser carregadas no banco de dados e, em seguida, modificadas ou agregadas antes de serem movidas até a tabela real de dados. O particionamento do SQL Server 2005 permite mover uma tabela de partição única para uma tabela com várias partições. Isso significa que você pode carregar dados em uma única tabela de carga, modificar esses dados e depois mover a tabela inteira para uma tabela existente sem a sobrecarga de mover cada linha individual de dados. Essa camada de particionamento não envolve a alteração das estruturas de particionamento subjacentes, mas envolve a modificação da tabela particionada O código na Figura 5 mostra como é possível obter isso.
Figure 5 Movendo a tabela inteira para uma tabela existente (Close Figure 5)
--Prepare database
IF OBJECT_ID(‘multiple_partition’) IS NOT NULL
DROP TABLE multiple_partition
GO

IF OBJECT_ID(‘single_partition’) IS NOT NULL
DROP TABLE single_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = ‘Primary_Left_Scheme’)
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = ‘Left_Partition’)
DROP PARTITION FUNCTION Left_Partition
GO

--Create single partition table
CREATE TABLE single_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
)

--Table must have a CHECK Constraint
ALTER TABLE single_partition
WITH CHECK
ADD CONSTRAINT CK_single_partition
    CHECK (col1 > 100)

INSERT INTO single_partition VALUES (101,’Description’)
INSERT INTO single_partition VALUES (102,’Description’)
INSERT INTO single_partition VALUES (103,’Description’)
INSERT INTO single_partition VALUES (104,’Description’)

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

INSERT INTO multiple_partition VALUES (1,’Description’)
INSERT INTO multiple_partition VALUES (2,’Description’)
INSERT INTO multiple_partition VALUES (3,’Description’)
INSERT INTO multiple_partition VALUES (4,’Description’)
INSERT INTO multiple_partition VALUES (10,’Description’)
INSERT INTO multiple_partition VALUES (11,’Description’)
INSERT INTO multiple_partition VALUES (12,’Description’)
INSERT INTO multiple_partition VALUES (13,’Description’)
INSERT INTO multiple_partition VALUES (14,’Description’)
INSERT INTO multiple_partition VALUES (100,’Description’)

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID(‘multiple_partition’), OBJECT_
      ID(‘single_partition’))

--Move the single table into the partitioned table
ALTER TABLE single_partition SWITCH TO multiple_partition PARTITION 4

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID(‘multiple_partition’), OBJECT_ID(‘single_partition’))
Mover uma partição de uma tabela para outra Uma tarefa administrativa comum é mover dados mais antigos para tabelas de arquivamento separadas. O processo de arquivamento geralmente envolve uma série de instruções que podem gerar um uso adicional de recursos nos logs de transações. Entretanto, uma maneira fácil de arquivar grandes de quantidades de dados sem a sobrecarga de logs de transações é alternar de uma tabela para a outra a propriedade de uma partição. Esse recurso permite que o administrador do banco de dados mova segmentos de dados mais antigos a partir de suas tabelas ativas para tabelas arquivadas. Mas, como os dados não são realmente movidos, o tempo necessário pode ser muito inferior em comparação à movimentação de linhas de dados individuais. A Figura 6 mostra como é possível fazer isso.
Figure 6 Movendo dados mais antigos para tabelas arquivadas (Close Figure 6)
--Prepare database
IF OBJECT_ID('active_data') IS NOT NULL
DROP TABLE active_data
GO

IF OBJECT_ID('archive_data') IS NOT NULL
DROP TABLE archive_data
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Active_Scheme')
DROP PARTITION SCHEME Active_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Active_Partition')
DROP PARTITION FUNCTION Active_Partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Archive_Scheme')
DROP PARTITION SCHEME Archive_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Archive_Partition')
DROP PARTITION FUNCTION Archive_Partition
GO

--Create active function
CREATE PARTITION FUNCTION Active_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Create archive function
CREATE PARTITION FUNCTION Archive_Partition (int) AS RANGE LEFT
FOR VALUES (100,200,300)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Active_Scheme
AS PARTITION Active_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Archive_Scheme
AS PARTITION Archive_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE active_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Active_Scheme (col1)

CREATE TABLE archive_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Archive_Scheme (col1)

INSERT INTO active_data VALUES (1,'Description')
INSERT INTO active_data VALUES (2,'Description')
INSERT INTO active_data VALUES (3,'Description')
INSERT INTO active_data VALUES (4,'Description')
INSERT INTO active_data VALUES (10,'Description')
INSERT INTO active_data VALUES (11,'Description')
INSERT INTO active_data VALUES (12,'Description')
INSERT INTO active_data VALUES (13,'Description')
INSERT INTO active_data VALUES (14,'Description')
INSERT INTO active_data VALUES (100,'Description')

INSERT INTO archive_data VALUES (200,'Description')
INSERT INTO archive_data VALUES (300,'Description')
INSERT INTO archive_data VALUES (400,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Switch ownership of partition to another table
ALTER TABLE active_data SWITCH PARTITION 3 TO archive_data PARTITION 1

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))
Usar uma única partição para criar uma nova tabela Você pode mover uma única partição a partir de uma tabela existente particionada para uma tabela vazia não particionada. Fazendo isso, um administrador de banco de dados pode efetuar a manutenção de índices na partição única ou pode eliminar facilmente grandes quantidades de dados sem que o processo de exclusão seja registrado em log. O exemplo na Figura 7 mostra como mover uma partição até uma tabela vazia e, depois, usar essa nova tabela para eliminar os dados.
Figure 7 Movendo e eliminando dados (Close Figure 7)
--Prepare database
IF OBJECT_ID('active_data') IS NOT NULL
DROP TABLE active_data
GO

IF OBJECT_ID('archive_data') IS NOT NULL
DROP TABLE archive_data
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Active_Scheme')
DROP PARTITION SCHEME Active_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Active_Partition')
DROP PARTITION FUNCTION Active_Partition
GO

--Create active function
CREATE PARTITION FUNCTION Active_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Active_Scheme
AS PARTITION Active_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE active_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Active_Scheme (col1)

CREATE TABLE archive_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
)

INSERT INTO active_data VALUES (1,'Description')
INSERT INTO active_data VALUES (2,'Description')
INSERT INTO active_data VALUES (3,'Description')
INSERT INTO active_data VALUES (4,'Description')
INSERT INTO active_data VALUES (10,'Description')
INSERT INTO active_data VALUES (11,'Description')
INSERT INTO active_data VALUES (12,'Description')
INSERT INTO active_data VALUES (13,'Description')
INSERT INTO active_data VALUES (14,'Description')
INSERT INTO active_data VALUES (100,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Switch ownership of partition to another table
ALTER TABLE active_data SWITCH PARTITION 3 TO archive_data

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Drop all archive data without logging
DROP TABLE archive_data
GO

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

Índices particionados
A capacidade de particionar os dados de uma tabela implica a capacidade de criar índices particionados. Isso permite que o administrador do banco de dados faça o design da estrutura de índice com base nos dados divididos em vez de nos dados da tabela inteira. A criação de índices particionados resulta em árvores B individuais nos índices particionados. A divisão dos índices tem o efeito de criar índices menores que são mais facilmente mantidos pelo mecanismo de armazenamento durante a modificação, a adição e a exclusão de dados. Esses índices menores também podem ser mantidos individualmente pelo administrador do banco de dados, possibilitando uma manutenção de índices mais eficiente em grandes conjuntos de dados.
Criando índices particionados Ao criar índices particionados, você pode criar índices alinhados ou índices não alinhados. Para índices alinhados, crie o índice com uma relação direta com os dados particionados. (Para índices não alinhados, escolha um esquema de particionamento diferente.)
O método alinhado é o preferencial e será feito automaticamente se você criar a tabela de partições e, depois, criar os índices sem especificar um esquema de particionamento diferente. O uso de índices alinhados proporciona a flexibilidade de criar partições adicionais na tabela e a capacidade de alternar a propriedade de uma partição para outra tabela. Esses recursos costumam ser a causa de os administradores de banco de dados criarem tabelas particionadas em primeiro lugar e o simples uso do esquema de particionamento da tabela para os seus índices será provavelmente suficiente para a obtenção das suas metas de particionamento.
Você pode criar índices com base em tabelas nas quais os dados no índice não estão alinhados aos dados na tabela. Se os dados estiverem em uma tabela particionada, isso permitirá que você agrupe os dados de diferentes maneiras (dados particionados podem ser eficientemente agrupados a outros dados particionados pelo otimizador de consultas). Como alternativa, isso pode ser feito com uma tabela não particionada, possibilitando a criação de um índice particionado (com base na tabela única de partições) para simplificar a manutenção desse índice.
O código na Figura 8 criará um índice particionado e não agrupado em cluster em uma tabela particionada. O índice não agrupado em cluster será alinhado à tabela e utilizará a coluna de particionamento da tabela como chave de índice não agrupado em cluster.
Figure 8 Índice particionado e não agrupado em cluster em uma tabela particionada (Close Figure 8)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
    ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

--Create partitioned non-clustered index
CREATE NONCLUSTERED INDEX cl_multiple_partition ON multiple_
      partition(col1)

INSERT INTO multiple_partition VALUES (1,'Description')
INSERT INTO multiple_partition VALUES (2,'Description')
INSERT INTO multiple_partition VALUES (3,'Description')
INSERT INTO multiple_partition VALUES (4,'Description')
INSERT INTO multiple_partition VALUES (10,'Description')
INSERT INTO multiple_partition VALUES (11,'Description')
INSERT INTO multiple_partition VALUES (12,'Description')
INSERT INTO multiple_partition VALUES (13,'Description')
INSERT INTO multiple_partition VALUES (14,'Description')
INSERT INTO multiple_partition VALUES (100,'Description')
INSERT INTO multiple_partition VALUES (101,'Description')
INSERT INTO multiple_partition VALUES (102,'Description')
INSERT INTO multiple_partition VALUES (103,'Description')
INSERT INTO multiple_partition VALUES (104,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Verify index partitions
SELECT partition_id, index_id FROM sys.partitions pt
WHERE pt.[object_id] = OBJECT_ID('multiple_partition')
O código na Figura 9 criará um índice não alinhado e não agrupado em cluster em uma tabela particionada. Esse índice não agrupado em cluster usará colunas diferentes para sua chave de índice, que pode ser usada em junções combinadas com base em outras tabelas particionadas.
Figure 9 Índice não alinhado e não agrupado em cluster em uma tabela particionada (Close Figure 9)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Index_primary_Left_Scheme')
DROP PARTITION SCHEME Index_primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Index_Left_Partition')
DROP PARTITION FUNCTION Index_Left_Partition
GO

--Create partitioned index function
CREATE PARTITION FUNCTION Index_Left_Partition (int) AS RANGE LEFT
FOR VALUES (10,50,100)

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all index partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Index_primary_Left_Scheme
AS PARTITION Index_Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT
,col2 INT
) ON Primary_Left_Scheme (col1)

--Create non-aligned partitioned nonclustered index
CREATE NONCLUSTERED INDEX cl_multiple_partition ON multiple_
     partition(col2)
ON Index_primary_Left_Scheme (col2)

INSERT INTO multiple_partition VALUES (1,10)
INSERT INTO multiple_partition VALUES (2,10)
INSERT INTO multiple_partition VALUES (3,10)
INSERT INTO multiple_partition VALUES (4,10)
INSERT INTO multiple_partition VALUES (10,50)
INSERT INTO multiple_partition VALUES (11,50)
INSERT INTO multiple_partition VALUES (12,50)
INSERT INTO multiple_partition VALUES (13,50)
INSERT INTO multiple_partition VALUES (14,50)
INSERT INTO multiple_partition VALUES (100,100)
INSERT INTO multiple_partition VALUES (101,100)
INSERT INTO multiple_partition VALUES (102,100)
INSERT INTO multiple_partition VALUES (103,100)
INSERT INTO multiple_partition VALUES (104,100)

--Verify row count on partitioned data
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')
AND p.index_id = 0

--Verify row count on partitioned index
--Row counts will not match those found in the data partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')
AND p.index_id <> 0
Manter índices particionados No passado, o tempo necessário para a realização da manutenção de índices com base em tabelas grandes contendo milhões ou até mesmo bilhões de linhas de dados costumava exceder o tempo disponível dos administradores de banco de dados. Em muitas ocasiões, essa manutenção deixava de ser feita porque os dados ficavam bloqueados enquanto o índice estava sendo reconstruído. Com o SQL Server 2005, o administrador do banco de dados pode realizar a manutenção de índices online, sem bloquear a tabela subjacente por um longo período de tempo. Porém, até mesmo essa abordagem (na qual você faz a manutenção do índice enquanto os usuários estão acessando os dados) ainda pode tornar o sistema lento devido ao uso de recursos. Uma abordagem melhor é o particionamento de índices em segmentos menores e, depois, a realização da manutenção do índice com base nessas partições menores. Por exemplo, para fazer a manutenção de um índice com base em uma partição de índice, você poderia simplesmente acrescentar o snippet de código a seguir ao final do código apresentado na Figura 8.
ALTER INDEX cl_multiple_partition
ON multiple_partition
REBUILD Partition = 2
Observe que a manutenção do índice com base em partições únicas de índice deve ser feita offline e pode causar o bloqueio da tabela durante a manutenção do índice. Para evitar isso, você pode mover a partição única até uma partição separada, fazer a manutenção do índice e então mover essa partição de volta à tabela principal. Esse processo causará alguns problemas de desempenho enquanto a partição estiver sendo movida de volta à tabela e durante a atualização do índice em cluster, mas é menos problemático do que o bloqueio da tabela inteira e requer menos recursos do sistema.

Resumo
Como é possível perceber, o particionamento de tabelas do SQL Server 2005 proporciona uma flexibilidade muito maior para o armazenamento e a manutenção de dados em tabelas grandes, sem a necessidade de reformular o código do aplicativo ou os processos do SQL Server. Com essas capacidades, o SQL Server prova que é uma plataforma competente para bancos de dados críticos em nível empresarial.

Noah Gomez é administrador de banco de dados de desenvolvimento sênior do SQL Server na Verizon, sendo especializado em VLDBs e aplicativos em grande escala. Ele é membro da PASS (Professional Association for SQL Server) e fez parte da equipe de administradores de banco de dados da Verizon que trabalhou nos VLDBs de vários terabytes, vencedores dos prêmios Winter Corp. Top Ten Grand Prize em 2003.


 SQL Server: Dicas &#243;timas para o agrupamento do SQL Server
SQL Server Tom Moreau, PhD

Dicas ótimas para o agrupamento do SQL Server
Visão geral:
  • Executando o SQL Server em um cluster
  • Requisitos de hardware e software
  • Armazenando um nó em cluster
  • Opções econômicas

Um cluster de servidor permite conectar vários servidores físicos, ou nós, que atuam como parceiros de failover entre si. A redundância fornecida por um cluster resulta em mais tempo de atividade para operações
críticas. Implementei vários clusters durante os meus 13 anos de trabalho com o SQL Server™ e cada um tinha a sua própria série de problemas. Essa experiência permitiu a coleta de várias dicas que podem ajudar a facilitar e a favorecer o sucesso dos esforços de armazenamento em cluster.
Os clusters de servidores têm a vantagem dos recursos integrados de armazenamento em cluster das edições Enterprise da família do Windows Server®. De fato, para finalidades de armazenamento em cluster, o Windows Server 2003 é significativamente melhor que o Windows 2000 Advanced Server. Para maximizar os benefícios que serão obtidos com o armazenamento em cluster, você precisará do hardware certo e isso envolve certos gastos. Não basta juntar alguns servidores com um disco compartilhado e você não pode depender do fato de que componentes de hardware individuais possam estar no Windows® Catalog (anteriormente conhecido como Lista de compatibilidade de hardware). O sistema como um todo deve estar no Windows Catalog. Mas, não se preocupe, pois estão disponíveis algumas soluções de cluster econômicas aprovadas. A Figura 1 mostra uma configuração típica de cluster.
Figure 1 A typical cluster
Figure 1 A typical cluster (Clique na imagem para diminuir a exibição)
Figure 1 A typical cluster
Figure 1 A typical cluster (Clique na imagem para aumentar a exibição)
É claro que o armazenamento em cluster envolve muito mais do que hardware. Você também precisa escolher a edição correta do SQL Server 2005. A Enterprise Edition habilita o armazenamento em cluster, bem como outros recursos úteis, como a capacidade de utilizar mais CPUs, modos de exibição distribuídas e atualizáveis, transporte integrado de logs e uso automático de modos de exibição indexados. Se uma licença do Enterprise Edition já estiver disponível, considere o armazenamento em cluster, independentemente de você ter os dois a oito servidores necessários para formar um cluster tradicional (conversaremos sobre clusters de um nó em alguns instantes). Se você tiver o SQL Server 2005 Standard Edition, poderá instalar um cluster de dois nós.
O Windows Server 2003 Enterprise Edition e o Windows Server 2003 Datacenter Edition acompanham um armazenamento em cluster integrado. Tudo o que precisa ser feito é executar o Administrador de Cluster para configurar o seu cluster. Você pode adicionar todos os nós de uma vez ou pode adicionar um por vez. De forma semelhante, ao instalar o SQL Server, você pode optar por instalar um servidor individual não armazenado em cluster ou pode instalar uma instância virtual em um cluster. Se você optar por instalar uma instância virtual, poderá instalar em todos os nós do cluster, em apenas alguns nós ou até mesmo em apenas um nó.
Por fim, para alcançar a verdadeira meta do armazenamento em cluster (a alta disponibilidade), você precisa de pessoas qualificadas e procedimentos bem pesquisados a serem seguidos no caso de problemas. Embora o armazenamento em cluster seja uma boa garantia contra falhas de hardware, ele não impede erros de usuários, como a eliminação de uma tabela crítica por um DBA mentalmente esgotado no meio da madrugada.

Clusters de um nó
Mesmo que você precise apenas de um servidor no momento, considere a criação de cluster de um nó. Isso lhe dá a opção de atualizar para um cluster mais tarde, o que evita uma operação de reconstrução. Apenas se certifique de que o hardware escolhido esteja na parte de cluster do Windows Catalog.
Não é exclusivamente por questões de alta disponibilidade que a opção de adicionar um nó posteriormente pode vir a ser desejável. Considere o que aconteceria se você descobrisse que o seu servidor simplesmente não possui a capacidade necessária. Isso significa a necessidade de migração, o que exige tempo e esforços. Se você tiver um cluster de um nó, a migração será mais fácil e o tempo de inatividade será muito menor. Basta adicionar o novo nó ao cluster, adicionar os binários e os service packs do SQL Server ao novo nó e fazer failover no novo nó. Em seguida, adicione as atualizações disponibilizadas após o lançamento do service pack e, por fim, remova o nó antigo. O tempo de inatividade corresponde apenas ao tempo necessário para fazer o failover e adicionar as atualizações (se houver).

Adicionando nós
Como todos os nós em um cluster devem ser iguais, convém agir o mais rápido possível, em vez de tarde demais, para obter esse nó extra. Se você esperar muito tempo, o nó poderá sair de produção. Em um projeto, tive que reconstruir um nó em um cluster SQL Server 2000. O administrador da rede/sistema operacional estava lidando com a criação básica da máquina, quando entrei em ação para adicioná-la de volta ao cluster e prepará-la para operação como um nó do SQL Server. Tudo estava indo bem, até o momento de fazer failover para o novo nó. Para meu espanto, ocorreu um processo direto de failback. Para encurtar a história, embora eu tivesse preparado um documento detalhado sobre a criação de um novo cluster, incluindo a adição das contas de serviço de cluster e de serviço do SQL Server a ambos os nós, o documento não foi seguido explicitamente. O administrador não havia adicionado essas contas de serviço ao nó recriado e, portanto, os privilégios que elas tinham antes da reconstrução deixaram de existir.
Demorou muito tempo para fazer esse rastreamento. Um certo dia, tive a idéia de observar uma associação de grupo local. Após a adição das duas contas, o failover ocorreu sem maiores problemas. Então, comecei a ponderar. A recriação de um nó é algo que não é feito freqüentemente e, se o for, é apenas em caso de emergência. Embora eu tivesse um documento apropriado, ele não foi usado. Poderíamos ter automatizado a parte de segurança simplesmente gravando um breve script para adicionar essas contas e fazer todas as outras personalizações necessárias. Apesar disso, os recursos do SQL Server 2005 foram aprimorados. O instalador exige a definição de grupos em nível de domínio para as contas de serviço do SQL Server.
É claro que isso me fez pensar ainda mais. Você pode criar scripts que chama CLUSTER.EXE para adicionar o nó ao cluster do MSCS (Microsoft® Cluster Server). Tudo o que precisa ser feito é inserir no script o nome do nó para que esse script possam manipular o restante do processo. Em caso de emergências, a automação é realmente muito benéfica.

Clusters N+1
Às vezes, o motivo para a adição de um nó em um cluster não é a substituição de um nó. Você pode estar adicionando mais instâncias do SQL Server ao cluster, e cada uma delas precisa de recursos de disco à parte. Embora várias instâncias possam ser executadas em um único nó, elas compartilhariam a CPU e a RAM, podendo resultar em fraco desempenho. Teoricamente, apenas uma instância deve ser executada em um único nó. Como garantir isso no momento do failover? Simples: a resposta é que um nó não possui serviços em execução, enquanto cada um dos outros executa uma instância do SQL Server. De fato, essa é a definição de um cluster N+1: N instâncias em execução em N+1 nós. O nó extra é o backup.

Atualizando o SQL Server
A atualização de uma instância em cluster do SQL Server não é uma tarefa simples: ela está armazenada em cluster por um motivo, que é a necessidade de tempo de atividade. Mas, o SQL Server 2005 oferece vários aprimoramentos que valem a pena aproveitar e, pois isso, se e quando a atualização for necessária, você poderá proceder sem muito tempo de inatividade.
Quais são as suas opções? Em primeiro lugar, examinaremos a solução mais cara: a criação de um cluster totalmente novo, significando novos servidores e talvez uma nova SAN (rede de armazenamento). É provavelmente possível manter os comutadores de rede existentes, mas isso é tudo. É óbvio que essa abordagem não é barata, mas tem as suas vantagens. Em geral, novos componentes de hardware apresentam um desempenho melhor que os antigos, com capacidade de disco e velocidade cada vez maiores em um ritmo sempre crescente. Portanto, você terá um grande aumento no desempenho simplesmente com novos componentes de hardware. É possível até mesmo alugar os seus equipamentos apenas para se manter em uma posição melhor.
Quando o hardware adequado estiver preparado, será possível criar um novo SQL Server virtual nessa configuração, copiar os bancos de dados de produção e então inserir o novo sistema no seu próprio ritmo, possibilitando tempo suficiente para eliminar os bugs antes do dia da transição. Apenas lembre-se de criptografar os logins a partir do servidor existente. (Consulte support.microsoft.com/kb/246133. Também é aconselhável atualizar o script de criação de login para o caso de uma falha catastrófica.)
Para minimizar o tempo de inatividade, será provavelmente necessário usar o transporte de logs, a menos que os bancos de dados sejam bem pequenos e você tenha um período de tempo durante o qual nenhum usuário esteja conectado. É possível fazer o transporte de logs logo antes da transição. Depois, desconecte os usuários, recorte e transporte o log final e então aponte o aplicativo para a nova instância. (Verifique a seção de espelhamento de banco de dados a seguir para conhecer uma alternativa interessante para o transporte de logs.) Se você usar aliases de DNS, provavelmente não precisará nem mesmo apontar os aplicativos para a nova instância. Basta atualizar o alias de DNS. Essa abordagem tem a vantagem de que, se você chegar à metade do caminho da migração e tiver que reverter para o original, terá pelo menos esse original.
É possível seguir uma rota mais econômica, mas isso requer um planejamento mais antecipado. Um cluster pode suportar mais de uma instância do SQL Server, mas cada uma deve ter os seus próprios recursos de disco. Portanto, se você subdividindo a sua SAN, reserve um LUN para uma atualização futura. Para fazer a atualização, instale os binários do SQL Server nesse recurso de disco. Você pode testar o sistema e, quando estiver pronto, desligar o SQL Server atual, mover os recursos de disco a partir do grupo antigo do SQL Server, atualizar as dependências e colocar online a nova instância do SQL Server. Conecte os bancos de dados a partir da instância antiga e você está pronto para colocar tudo em operação. (Você já fez o backup antecipado de todos os dados, certo?)
Essa é a abordagem mais econômica, mas apresenta alguns riscos. Se algo der errado, não será possível desconectar os bancos de dados da nova instância e recolocá-los em operação. Você apenas poderá fazer restaurações de backups, o que pode envolver um sério tempo de inatividade.
Uma alternativa é colocar duas instâncias do SQL Server na SAN, supondo que haja espaço suficiente. Restaure os backups de produção (e o transporte de logs) para a nova instância e proceda exatamente como descrito anteriormente. Entretanto, existe agora um fallback. Após a migração, você poderá liberar os recursos da SAN da instância antiga. Os custos desse processo são alguns discos extras.

Balanceamento de carga
Vamos começar derrubando um mito comum. O armazenamento em cluster do MSCS é usado para alta disponibilidade e não para balanceamento de carga. Além disso, o SQL Server não tem recursos integrados e automáticos de balanceamento de carga. É necessário fazer o balanceamento de carga por meio do design físico do seu aplicativo. O que isso significa?
Conforme o crescimento de uma tabela, haverá uma certa degradação do desempenho, especialmente quando verificações de tabela entrarem em jogo. Quando você alcançar milhões ou bilhões de linhas, a solução tradicional será o uso de modos de exibição particionados, que são compostos de tabelas com esquemas idênticos vinculados por meio de instruções UNION ALL. Além disso, restrições CHECK são efetivadas para diferenciar as tabelas-membro, o que evita a duplicação de dados na visualização particionada. Se a coluna usada na restrição CHECK também fizer parte da chave primária, o modo de exibição poderá ser atualizado.
Se as tabelas-membro estiverem em seus próprios grupos de arquivos, será possível melhorar o desempenho se os arquivos nesses grupos estiverem em unidades físicas separadas. As tabelas podem estar até mesmo em bancos de dados separados. Entretanto, no SQL Server 2005, desde que todos os dados estejam no mesmo banco de dados, você poderá usar o particionamento de tabelas, que é muito mais fácil de implementar.
Digamos que você tenha feito o melhor possível com o particionamento de tabelas ou com os modos de exibição particionados (locais), mas o desempenho ainda esteja lento. Se tiver o SQL Server 2000 ou o SQL Server 2005, será possível usar modos de exibição particionados distribuídos. A principal diferença é que as tabelas-membro podem residir em instâncias diferentes do SQL Server e essas instâncias podem ser instaladas em um cluster N+1. Por que é uma boa idéia? Se qualquer tabela-membro for colocada offline em um modo de exibição particionado, esse modo de exibição inteiro ficará offline. Por isso, tornar esses membros parte de um cluster proporciona a segurança necessária para favorecer o desempenho e fornecer balanceamento de carga.

Você precisa realmente de um cluster?
Talvez existam alguns servidores sobressalentes disponíveis, mas eles não estão no Windows Catalog para clusters. É uma pena ter que comprar novos servidores unicamente para dar suporte a um cluster quando já existem servidores disponíveis.
O espelhamento de bancos de dados pode ser uma alternativa atraente para o armazenamento em cluster. O espelhamento envolve três elementos: uma instância que hospeda o banco de dados espelhado é conhecida como principal, o servidor de backup é conhecido como o espelho e, se você quiser failover automático, um terceiro servidor, conhecido como testemunha, será necessário. Em resumo, uma transação em um banco de dados no principal é executada novamente no espelho. Se o principal falhar, o failover do banco de dados poderá ocorrer no espelho, automaticamente se você tiver uma testemunha. É necessário configurar o espelhamento para cada um dos bancos de dados de aplicativos, mas não é possível espelhar bancos de dados do sistema.
O espelho é uma instância à parte do SQL Server, ao contrário de um cluster, e pode estar localizado a milhares de quilômetros de distância. Seus caches são preenchidos pela atividade de atualização que ocorre como resultado das transações duplicadas a partir do principal. Suponha, é claro, que não haja atividade no espelho além do recebimento de transações espelhadas do principal. O failover será geralmente mais rápido do que em um cluster, pois o SQL Server já está em execução no espelho. Como os caches estão pelo menos parcialmente preparados, o desempenho inicial não é tão lento como seria em um cenário em cluster. E, observe que, quando ocorre o failover de um banco de dados espelhado, as funções do principal e do espelho são invertidas.
A desvantagem do espelhamento de bancos de dados é a necessidade de duplicar a capacidade total de disco em comparação a um cluster. Você também precisará de mais potência de CPU se preferir o modo de sincronização sem perda de dados. Como já disso, a alta disponibilidade não é barata.

Uma abordagem combinada
Como um espelho pode estar localizado remotamente do principal, ele é uma boa opção para planos de DR (recuperação após desastres). Seu cluster pode ser sua primeira linha de defesa, mas o que acontecerá se você usar técnicas de armazenamento em cluster e de espelhamento? Em um failover de cluster, se você tiver uma testemunha como parte da configuração de espelhamento, o espelho se tornará o principal enquanto o SQL Server estiver entrando online. Entretanto, observe que o failover a partir do novo principal de volta para o novo espelho (em cluster) não é automático. Consequentemente, convém não habilitar o failover automático para bancos de dados espelhados quando eles forem usados em conjunto com um cluster.
A DR não é o único motivo para se usar o espelhamento. Ela também é útil caso você precise aplicar um service pack ou um hotfix ao principal, em cujo caso é possível fazer o failover manualmente para o espelho. Ao aplicar o service pack ou o hotfix, o servidor principal antigo está temporariamente offline e as transações confirmadas que ocorrem no novo principal são colocadas em fila, aguardando para serem enviadas de volta ao novo espelho (principal antigo). Após a conclusão da instalação do service pack ou do hotfix, a sincronização ocorrerá e, com o tempo, os dois servidores estarão completamente em sincronia. Agora, você poderá alternar as funções do principal e do espelho. O tempo de inatividade correspondeu a alguns segundos para o failover e o failback. Essa abordagem pode ser usada para migrar o SQL Server para outra máquina. Apenas não faça o failback.

O servidor virtual adiciona flexibilidade
A virtualização permite executar um ou mais sistemas operacionais simultaneamente em um único servidor físico. O software de virtualização adiciona outra camada de recursos ao conceito de cluster, pois você pode armazenar o software em cluster. Conseqüentemente, se o servidor no qual o host está em execução falhar, ele e seus sistemas operacionais convidados farão failover em um nó de backup. Essa seria uma forma muito fácil de migrar um servidor convidado. Além disso, o sistema operacional convidado não precisa estar habilitado para cluster. Portanto, seria possível executar o SQL Server Workgroup Edition dentro de um Windows Server 2003 convidado, em execução no Microsoft Virtual Server 2005 em um cluster. Indiretamente, você armazenou em cluster basicamente o Workgroup Edition (consulte a Figura 2).
Figure 2 Using a virtual server
Figure 2 Using a virtual server (Clique na imagem para diminuir a exibição)
Figure 2 Using a virtual server
Figure 2 Using a virtual server (Clique na imagem para aumentar a exibição)

No controle
Se você estiver encarregado de uma implementação do SQL Server, convém saber que o servidor sempre está disponível. O armazenamento em cluster do servidor ajuda a garantir que isso sempre acontecerá. Este artigo fornece algumas dicas merecidas para ajudá-lo a dar os primeiros passos e você encontrará mais informações úteis na barra lateral "Recursos de armazenamento em cluster".
Recursos de armazenamento em cluster
Para obter mais informações sobre os métodos usados aqui e os vários produtos necessários para configurar o cluster do SQL Server, consulte:
  • Armazenamento em cluster para failover do SQL Server 2005
  • Armazenamento em cluster para failover do SQL Server 2000
  • Windows Server 2003 R2 Enterprise Edition–Cluster Server
  • Guia do administrador do Microsoft Cluster Server
  • Microsoft Virtual Server 2005 R2

Tom Moreau, PhD, BSc, PhD, MCSE, MCDBA, é um consultor independente especializado em administração, design e implementação de bancos de dados SQL Server e que trabalha na região de Toronto. Tom usa o SQL Server desde 1993 e é MVP desde 2001. Ele escreveu mais de 100 artigos e participou como co-autor de um livro sobre o SQL Server. Agradecimentos ao MVP do SQL Server Geoff Hiten por essas úteis informações .


 Administra&#231;&#227;o do Windows: Dentro do kernel do Windows Vista: parte 2
Administração do Windows Mark Russinovich

Dentro do kernel do Windows Vista: parte 2
Visão geral:
  • Gerenciamento de memória
  • Inicialização e desligamento
  • Gerenciamento de energia

No mês passado, na primeira edição desta série de três partes, fiz uma análise dos aprimoramentos do kernel do Windows Vista nas áreas de processos e E/S.
Desta vez, abordarei os avanços na forma como o Windows Vista gerencia a memória, além dos principais melhoramentos na inicialização, desligamento e gerenciamento de energia do sistema (Parte 1).
Cada versão do Windows® apresenta avanços na escalabilidade e no desempenho, e o Windows Vista™ não foge à regra. O Gerenciador de Memória do Windows Vista inclui vários aprimoramentos, como o uso mais extensivo de técnicas de sincronização sem bloqueio, bloqueio mais refinado, empacotamento mais rigoroso da estrutura de dados, maior E/Ss de paginação, suporte às modernas arquiteturas de memória GPU e o uso mais eficiente do TLB (buffer de conversão à parte) de hardware. Além disso, o gerenciamento de memória do Windows Vista oferece agora alocação de espaço de endereço dinâmico para os requisitos de diferentes cargas de trabalho.
Quatro recursos de aprimoramento de desempenho que usam novas tecnologias estão estreando no sistema operacional com o Windows Vista: SuperFetch, ReadyBoost, ReadyBoot e ReadyDrive. Eles serão abordados detalhadamente mais adiante, neste artigo.

Espaço de endereço de kernel dinâmico
O Windows e os aplicativos executados nele tiveram muita dor de cabeça com os limites de espaço de endereço dos processadores de 32 bits. Por padrão, o kernel do Windows fica restrito a 2GB ou à metade do espaço de endereço virtual total de 32 bits, sendo a outra metade reservada para uso do processo cujo thread está em execução na CPU. Dentro de sua metade, o kernel precisa mapear a si mesmo, os drivers de dispositivos, o cache o sistema de arquivos, as pilhas do kernel, as estruturas de dados de códigos por sessão, além dos buffers pagináveis e não pagináveis (memória física bloqueada) alocados por drivers de dispositivos. Antes do Windows Vista, o Gerenciador de Memória determinava, no momento da inicialização, quanto do espaço de endereço deveria ser atribuído a cada fim, mas às vezes esta inflexibilidade levava a situações nas quais uma das regiões ficava cheia, enquanto outras tinham bastante espaço disponível. A exaustão de uma área pode levar a falhas de aplicativos e impedir que drivers de dispositivos concluam operações de E/S.
No Windows Vista de 32 bits, o Gerenciador de Memória gerencia o espaço de endereço do kernel dinamicamente, alocando e desalocando o espaço para diversos usos, conforme a demanda da carga de trabalho. Assim, a quantidade de memória virtual usada para armazenar buffers pagináveis pode aumentar quando drivers de dispositivos solicitam mais e diminuir, quando liberada pelos drivers. Assim, o Windows Vista poderá tratar uma variedade mais ampla de cargas de trabalho e, da mesma forma, a versão de 32 bits do próximo Windows Server®, cujo codinome é "Longhorn", será dimensionada para tratar mais usuários simultâneos do Terminal Server.
Obviamente, nos sistemas Windows Vista de 64 bits, atualmente as restrições de espaço de endereço não representam uma limitação prática e, portanto, não exigem qualquer tratamento especial, pois estão configuradas em seu máximo.

Prioridades de memória
Da mesma forma que o Windows Vista adiciona prioridades de E/S (conforme discutido na última edição), ele também implementa prioridades de memória. Para entender como o Windows usa as prioridades de memória, é necessário saber como o Gerenciador de Memória implementa seu cache de memória, chamado de Lista de Espera. Em todas as versões do Windows anteriores ao Windows Vista, quando uma página física (que geralmente tem 4KB de tamanho) de propriedade de um processo era recuperada pelo sistema, normalmente o Gerenciador de Memória a colocava no final da Lista de Espera. Se o processo quisesse acessá-la novamente, o Gerenciador de Memória pegava a página da Lista de Espera e ela era reatribuída ao processo. Quando um processo queria usar uma nova página de memória física e não havia memória livre disponível, o Gerenciador de Memória fornecia a página à frente de Lista de Espera. Basicamente, este esquema tratava igualmente todas as páginas em espera, usando apenas a hora em que foram colocadas na lista para classificá-las.
No Windows Vista, cada página de memória possui uma prioridade entre 0 e 7; dessa forma, o Gerenciador de Memória divide a Lista de Espera em oito listas que armazenam as páginas de cada prioridade. Quando o Gerenciador de Memória precisa pegar uma página da Lista de Espera, ele utiliza primeiro as páginas das listas de baixa prioridade. Geralmente, a prioridade de uma página reflete a prioridade do thread que gerou sua primeira alocação. (Se a página for compartilhada, ela refletirá as prioridades de memória mais altas dos threads do compartilhamento.) Um thread herda seu valor de prioridade de página do processo ao qual pertence. De forma especulativa, o Gerenciador de Memória usa prioridades baixas para as páginas que lê do disco ao antecipar os acessos de memória de um processo.
Por padrão, os processos possuem um valor de prioridade de página 5, mas as funções permitem que os aplicativos e o sistema alterem os valores de prioridade de página de threads e de processos. Só se percebe o real poder das prioridades de memória quando as prioridades relativas das páginas são entendidas no nível mais abrangente, que é a função do SuperFetch.

SuperFetch
Uma mudança significativa do Gerenciador de Memória se encontra na maneira como ele gerencia a memória física. O gerenciamento da Lista de Espera usado pelas versões anteriores do Windows possui duas limitações. Primeiro, a priorização de páginas depende apenas do comportamento pretérito recente dos processos e não antecipa seus requisitos futuros de memória. Segundo, os dados usados para a priorização se limitam à lista de páginas de propriedade de um processo em qualquer determinado momento. Essas limitações podem resultar em cenários como a "síndrome pós-almoço", quando você deixa seu computador por algum tempo e um aplicativo do sistema que utiliza a memória intensamente é executado (como uma verificação antivírus ou desfragmentação de disco). Esse aplicativo força a substituição do código e dos dados que seus aplicativos ativos armazenaram em cache na memória pelas atividades com intensa utilização de memória. Ao retornar, o desempenho é lento, pois os aplicativos precisam solicitar seus dados e códigos do disco.
O Windows XP introduziu o suporte à pré-busca, que melhorou o desempenho do início de aplicativos e de inicialização, executando grandes E/Ss de disco para pré-carregar a memória com o código e os dados do sistema de arquivos esperados, com base nas inicializações e inícios de aplicativos anteriores. O Windows Vista dá um grande passo com o SuperFetch, um esquema de gerenciamento de memória que aprimora a abordagem acessada menos recentemente com informações históricas e gerenciamento proativo de memória.
O SuperFetch é implementado em %SystemRoot%\System32\Sysmain.dll como um serviço do Windows executado dentro de um processo de Host de Serviço (%SystemRoot%\System32\Svchost.exe). O esquema depende do suporte do Gerenciador de Memória, de forma a poder recuperar os históricos de uso de páginas, além de direcionar o Gerenciador de Memória para pré-carregar dados e código de arquivos no disco ou de um arquivo de paginação na Lista de Espera e atribuir prioridades às páginas. Basicamente, o serviço SuperFetch estende o controle de páginas a dados e código que já estiveram na memória, mas que o Gerenciador de Memória reutilizou para criar espaço para novos dados e código. Ele armazena essas informações em arquivos de cenário com uma extensão .db no diretório %SystemRoot%\Prefetch, junto com os arquivos de pré-busca padrão usados para otimizar o início de aplicativos. Utilizando esse profundo conhecimento do uso da memória, o SuperFetch pode pré-carregar dados e código quando a memória física é disponibilizada.
Sempre que a memória fica livre, por exemplo, quando um aplicativo é encerrado ou libera memória, o SuperFetch solicita que o Gerenciador de Memória busque dados e código que foram removidos recentemente. Isso é feito na taxa de algumas páginas por segundo com E/Ss de prioridade muito baixa, de forma que o pré-carregamento não impacta o usuário ou outros aplicativos ativos. Portanto, se você abandonar o computador para almoçar e uma tarefa de segundo plano que utiliza muita memória fizer o código e os dados de seus aplicativos ativos serem removidos da memória durante sua ausência, freqüentemente o SuperFetch pode trazer tudo ou a maior parte deles de volta para a memória antes de você voltar. O SuperFetch também inclui suporte específico a cenários para hibernação, modo de espera, Troca Rápida de Usuário e início de aplicativos. Quando o sistema hiberna, por exemplo, o SuperFetch armazena dados e código no arquivo de hibernação que ele espera (com base nas hibernações anteriores) que seja acessado durante a continuação subseqüente. Por outro lado, quando você continua o Windows XP, os dados armazenados em cache anteriormente devem ser lidos novamente do disco ao serem referenciados.
Consulte a barra lateral "Observando o SuperFetch" para ver como o SuperFetch impacta a memória disponível.
Observando o SuperFetch
Depois de usar um sistema Windows Vista por algum tempo, você verá um valor pequeno no contador Memória Física Disponível na página Desempenho do Gerenciador de Tarefas. Isso se deve ao fato de o SuperFetch e o cache padrão do Windows usarem toda a memória física disponível para armazenar dados do disco em cache. Por exemplo, ao inicializar pela primeira vez, se você executar o Gerenciador de Tarefas imediatamente, deverá observar que o valor da Memória Disponível diminui conforme o valor da Memória em Cache aumenta. Ou, se você executar um programa que utiliza muita memória e sair dele (qualquer “otimizador de RAM” gratuito que aloca grandes quantidades de memória e depois a libera servirá) ou simplesmente copiar um arquivo muito grande, o valor de Disponível aumentará e o gráfico de Uso de Memória Física cairá conforme o sistema recupera a memória liberada. Contudo, ao longo do tempo o SuperFetch preenche novamente o cache com os dados que foram removidos da memória, então o valor de Em Cache aumentará e o valor de Disponível diminuirá.
Watching memory
Watching memory (Clique na imagem para diminuir a exibição)
Watching memory
Watching memory (Clique na imagem para aumentar a exibição)

ReadyBoost
A velocidade das CPUs e da memória estão ultrapassando rapidamente a dos discos rígidos; dessa forma, comumente os discos representam um afunilamento de desempenho do sistema. A E/S aleatória em disco é especialmente dispendiosa porque os tempos de busca do cabeçote do disco são da ordem de 10 milisegundos; uma eternidade para os processadores atuais de 3 GHz. A RAM é ideal para o armazenamento de dados de disco em cache, mas é relativamente cara. Entretanto, a memória flash é, em geral, mais barata e pode atender leituras aleatórias até 10 vezes mais rápido que um disco rígido normal. Portanto, o Windows Vista inclui um recurso chamado ReadyBoost para tirar proveito dos dispositivos de armazenamento de memória flash através da criação neles de uma camada de cache intermediária situada logicamente entre a memória e os discos.
O ReadyBoost consiste em um serviço implementado em %SystemRoot%\System32\Emdmgmt.dll, executado em um processo de Host de serviço e em um driver de filtro de volume, %SystemRoot%\System32\Drivers\Ecache.sys. (Emd é a abreviação de dispositivo de memória externa (External Memory Device), o nome de trabalho do ReadyBoost durante seu desenvolvimento.) Ao inserir um dispositivo flash, como uma chave USB, em um sistema, o serviço ReadyBoost examina o dispositivo para determinar suas características de desempenho e armazena os resultados de seu teste em HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, como mostrado na Figura 1.
Figure 1 ReadyBoost device test results in the registry
Figure 1 ReadyBoost device test results in the registry (Clique na imagem para diminuir a exibição)
Figure 1 ReadyBoost device test results in the registry
Figure 1 ReadyBoost device test results in the registry (Clique na imagem para aumentar a exibição)
Se você ainda não usa um dispositivo para o armazenamento em cache e o novo dispositivo tiver entre 256 MB e 32 GB, uma taxa de transferência de 2,5 MB/s ou mais para leituras aleatórias de 4 KB e uma taxa de transferência de 1,75 MB/s ou mais para gravações aleatórias de 512 KB, o ReadyBoost perguntará se você deseja dedicar até 4 GB do armazenamento para o cache de disco. (Apesar de o ReadyBoost poder usar o NTFS, ele limita o tamanho máximo do cache a 4 GB para acomodar as limitações do FAT32.) Se você concordar, o serviço criará um arquivo de cache chamado ReadyBoost.sfcache na raiz do dispositivo e solicitará que o SuperFetch pré-preencha o cache em segundo plano.
Depois que o serviço ReadyBoost inicializa o cache, o driver do dispositivo Ecache.sys intercepta todas as leituras e gravações nos volumes do disco rígido local (por exemplo, C:\) e copia todos os dados que estão sendo gravados no arquivo de cache criado pelo serviço. O Ecache.sys compacta os dados e, normalmente, atinge uma taxa de compactação de 2:1, de forma que um arquivo de cache de 4 GB geralmente contém 8 GB de dados. O driver criptografa todos os blocos gravados usando a criptografia AES com uma chave de sessão por inicialização gerada aleatoriamente para garantir a privacidade dos dados no cache, caso o dispositivo seja removido do sistema.
Quando o ReadyBoost observa leituras aleatórias que podem ser satisfeitas a partir do cache, ele as atende de lá, mas como os discos rígidos possuem um acesso de leitura seqüencial melhor que a memória flash, ele permite que as leituras que fazem parte de padrões de acesso seqüencial vão diretamente para o disco, mesmo que os dados estejam no cache.

ReadyBoot
O Windows Vista usa a mesma pré-busca de tempo de inicialização que o Windows XP usava quando o sistema tinha menos de 512 MB de memória, mas se o sistema tiver 700 MB ou mais de RAM, será utilizado um cache na RAM para otimizar o processo de inicialização. O tamanho do cache depende da RAM total disponível, mas é suficientemente grande para criar um cache razoável e ainda disponibilizar ao sistema a memória necessária para inicializar tranquilamente.
Após cada inicialização, o serviço ReadyBoost (o mesmo serviço que implementa o recurso ReadyBoost que acabamos de descrever) usa o tempo ocioso da CPU para calcular um plano de armazenamento em cache de tempo de inicialização para a próxima inicialização. São analisadas as informações de rastreamento de arquivos das cinco inicializações anteriores e identificados os arquivos que foram acessados, além de sua localização no disco. Os rastreamentos processados são armazenados em %SystemRoot%\Prefetch\Readyboot como arquivos .fx e o plano de armazenamento em cache é salvo em HKLM\System\CurrentControlSet\Services\Ecache\Parameters, em valores REG_BINARY nomeados de acordo com os volumes de disco internos aos quais se referem.
O cache é implementado pelo mesmo driver de dispositivo que implementa o cache do ReadyBoost (Ecache.sys), mas seu preenchimento é direcionado pelo serviço ReadyBoost enquanto o sistema é inicializado. O cache de inicialização é compactado da mesma forma que o cache do ReadyBoost, mas uma outra diferença entre o gerenciamento de cache do ReadyBoost e do ReadyBoot é que, no modo ReadyBoot, além das atualizações do serviço ReadyBoost, o cache não é alterado para refletir os dados lidos ou gravados durante a inicialização. O serviço ReadyBoost exclui o cache 90 segundos após o começo da inicialização ou se outras demandas de memória o assegurarem, e registra as estatísticas do cache em HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats, como mostrado na Figura 2. Os testes de desempenho da Microsoft mostram que o ReadyBoot oferece avanços de desempenho aproximadamente 20 % acima da pré-busca herdada do Windows XP.
Figure 2 ReadyBoot Performance statistics
Figure 2 ReadyBoot Performance statistics (Clique na imagem para diminuir a exibição)
Figure 2 ReadyBoot Performance statistics
Figure 2 ReadyBoot Performance statistics (Clique na imagem para aumentar a exibição)

ReadyDrive
O ReadyDrive é um recurso do Windows Vista que tira proveito das novas unidades de disco rígido híbridas, os chamados H-HDDs. O H-HDD consiste em um disco com memória flash não-volátil incorporada (também conhecida como NVRAM). Os H-HDDs típicos incluem entre 50MB e 512MB de cache, mas o limite de cache do Windows Vista é de 2TB.
O Windows Vista usa comandos ATA-8 para definir os dados do disco a serem mantidos na memória flash. Por exemplo, o Windows Vista gravará os dados de inicialização no cache ao desligar o sistema, permitindo um reinício mais rápido. Ele também armazena partes dos dados do arquivo de hibernação em cache quando o sistema hiberna, de forma que a continuação subseqüente seja mais rápida. Como o cache fica habilitado mesmo quando o disco não está girando, o Windows pode usar a memória flash como um cache de gravação em disco, evitando acelerar o disco quando o sistema está sendo executado com bateria. Manter o eixo do disco desativado economiza bastante energia consumida pela unidade de disco em uso normal.

Banco de dados de configuração de inicialização
O Windows Vista possui vários aspectos avançados de inicialização e desligamento. A inicialização foi melhorada com a introdução do Banco de Dados de Configuração de Inicialização (BCD) para armazenar a configuração de início do sistema operacional e do sistema, um novo fluxo e organização dos processos de inicialização do sistema, uma nova arquitetura de logon e suporte para serviços de início automático atrasado. As alterações do desligamento do Windows Vista incluem uma notificação pré-desligamento para serviços do Windows, o pedido de desligamento de serviços do Windows e uma mudança significativa na forma como o sistema operacional gerencia as transições de estado de energia.
Uma das alterações mais visíveis do processo de inicialização é a ausência do Boot.ini na raiz do volume do sistema. A configuração da inicialização, que nas versões anteriores do Windows ficava armazenada no arquivo de texto Boot.ini, agora é armazenada no BCD. Um dos motivos para o Windows Vista usar o BCD é que ele unifica as duas arquiteturas de atualização atuais com suporte do Windows: o MBR (registro mestre de inicialização) e a EFI (Extensible Firmware Interface). Em geral, o MBR é usado por sistemas desktop x86 e x64, enquanto a EFI é usada por sistemas baseados em Itanium (apesar de que, provavelmente, os computadores desktop serão fornecidos com suporte a EFI em breve). O BCD abstrai o firmware e possui outras vantagens sobre o Boot.ini, como o suporte para cadeias de caracteres Unicode e executáveis pré-inicialização alternativos.
Na realidade, o BCD é armazenado em disco em um hive do Registro que é carregado no Registro do Windows para acesso através de APIs do Registro. Em PCs, o Windows o armazena em \Boot\Bcd no volume do sistema. Em sistemas EFI, ele fica na partição do sistema EFI. Quando o hive é carregado, ele aparece sob HKLM\Bcd00000000, mas seu formato interno não é documentado, de forma que a edição exige o uso de uma ferramenta como %SystemRoot%\System32\Bcdedit.exe. As interfaces para manipular o BCD também são disponibilizadas para scripts e editores personalizados por meio do WMI (Windows Management Instrumentation) e você pode usar o Utilitário de Configuração do Sistema Windows (%SystemRoot%\System32\Msconfig.exe) para editar ou adicionar parâmetros básicos, como opções de depuração do kernel.
O BCD divide as configurações de inicialização de toda a plataforma, como a seleção do sistema operacional padrão e o tempo limite do menu de inicialização, das configurações específicas do sistema operacional, como as opções e o caminho do carregador de inicialização do sistema operacional. Por exemplo, a Figura 3 mostra que, ao executar Bcdedit sem opções da linha de comando, são exibidas as configurações da plataforma na seção Gerenciador de Inicialização do Windows, na parte superior da saída, seguidas das configurações específicas do sistema operacional, na seção Carregador de Inicialização do Windows.
Figure 3 Settings displayed in BCDEdit
Figure 3 Settings displayed in BCDEdit (Clique na imagem para diminuir a exibição)
Figure 3 Settings displayed in BCDEdit
Figure 3 Settings displayed in BCDEdit (Clique na imagem para aumentar a exibição)
Ao inicializar uma instalação do Windows Vista, este novo esquema divide as tarefas que foram tratadas pelo carregador do sistema operacional (Ntldr) em versões anteriores do Windows em dois executáveis diferentes: \BootMgr e %SystemRoot%\System32\Winload.exe. O Bootmgr lê o BCD e exibe o menu de inicialização do sistema operacional, enquanto o Winload.exe trata do carregamento do sistema operacional. Se você estiver executando uma inicialização simples, o Winload.exe carregara os drivers de dispositivos de inicialização e os arquivos principais do sistema operacional, incluindo o Ntoskrnl.exe, e transfere o controle para o sistema operacional; se o sistema estiver continuando a partir de uma hibernação, ele executará %SystemRoot%\System32\Winresume.exe para carregar os dados de hibernação na memória e continuar o sistema operacional.
O Bootmgr também inclui o suporte para executáveis pré-inicialização adicionais. O Windows Vista é fornecido com o Diagnóstico de Memória do Windows (\Boot\Memtest.exe) pré-configurado como uma opção para verificar a integridade da RAM, nas executáveis pré-inicialização de terceiros podem ser adicionados como opções que serão exibidas no menu de inicialização do Bootmgr.

Processos de inicialização
Nas versões anteriores do Windows, a relação entre vários processos do sistema não é intuitiva. Por exemplo, conforme o sistema é inicializado, o gerenciador de logon interativo (%SystemRoot%\System32\Winlogon.exe) inicia o serviço LSASS (Lsass.exe) e o Gerenciador de Controle de Serviços (Services.exe). Além disso, o Windows usa um contêiner de namespaces que chamou uma Sessão para isolar processos executados em sessões de logon diferentes. Mas, antes do Windows Vista, o usuário fazia logon na Sessão 0 compartilhada pelo console, a sessão usada por processos do sistema, o que criava possíveis problemas de segurança. Um desses problemas aparecia, por exemplo, quando um serviço do Windows mal escrito executado na Sessão 0 exibia uma interface do usuário no console interativo, permitindo que malwares invadissem a janela por meio de técnicas como as de ataque shatter e pudessem obter privilégios administrativos.
Para resolver esses problemas, a arquitetura de vários processos do sistema foi mudada no Windows Vista. O Gerenciador de Sessão (Smss.exe) é o primeiro processo no modo de usuário criado durante a inicialização, como nas versões anteriores do Windows, mas no Windows Vista ele inicia uma segunda instância de si mesmo para configurar a Sessão 0, que é dedicada unicamente a processos do sistema. O processo do Gerenciador de Sessão para a Sessão 0 inicia o Aplicativo de Inicialização do Windows (Wininit.exe), um processo de subsistema do Windows (Csrss.exe) para a Sessão 0 e, em seguida, sai. O Aplicativo de Inicialização do Windows continua, iniciando o Gerenciador de Controle de Serviços, o serviço LSASS e um novo processo, o Gerenciador de Sessão Local (Lsm.exe), que gerencia conexões do servidor de terminal com a máquina.
Quando um usuário faz logon no sistema, o Gerenciador de Sessão inicial cria uma nova instância de si mesmo para configurar a nova sessão. O novo processo Smss.exe inicia um processo de subsistema do Windows e o processo Winlogon para a nova sessão. O fato de o Gerenciador de Sessão principal usar cópias de si mesmo para inicializar novas sessões não oferece vantagens em um sistema cliente, mas nos sistemas Windows Server "Longhorn" que funcionam como servidores de terminal, várias cópias podem ser executadas simultaneamente para permitir o logon mais rápido de diversos usuários.
Com esta nova arquitetura, os processos do sistema, incluindo os serviços do Windows, são isolados na Sessão 0. Se um serviço do Windows executado na Sessão 0 exibe uma interface do usuário, o serviço Detecção de Serviços Interativa (%SystemRoot%\System32\UI0Detect.exe) notifica os administradores conectados, iniciando uma instância de si mesmo no contexto de segurança do usuário e exibindo a mensagem mostrada na Figura 4. Se o usuário selecionar o botão "Exibir esta mensagem", o serviço alternará a área de trabalho para a área de trabalho do serviço do Windows, onde pode interagir com a interface do usuário do serviço e, em seguida, voltar para sua própria área de trabalho. Para saber mais sobre o que acontece na inicialização, consulte a barra lateral "Exibindo Relações de Processos de Inicialização".
Figure 4 Service has displayed a window
Figure 4 Service has displayed a window (Clique na imagem para diminuir a exibição)
Figure 4 Service has displayed a window
Figure 4 Service has displayed a window (Clique na imagem para aumentar a exibição)
Exibindo Relações de Processos de Inicialização
Você pode usar o Process Explorer da Sysinternals (microsoft.com/technet/sysinternals) para ver a árvore de inicialização de processos do Windows Vista.
A captura de tela inclui a coluna Sessão, que pode ser adicionada por meio da caixa de diálogo da coluna do Process Explorer. O processo realçado é o Smss.exe inicial. Abaixo dele estão o Csrss.exe e o Wininit.exe da Sessão 0, que são justificados à esquerda porque seu processo pai, a instância do Smss.exe que configurou a Sessão 0, saiu. A árvore filha do Wininit consiste em Services.exe, Lsass.exe e Lsm.exe.
O Process Explorer identifica um conjunto de processos como sendo executados na Sessão 1, sendo essa a sessão na qual fiz logon por meio da conexão da Área de Trabalho Remota. O Process Explorer exibe os processos executados na mesma conta que ele realçados em azul. Finalmente, a Sessão 2 foi inicializada para preparar o logon de um usuário no console e a criação de uma nova sessão de logon. O Winlogon é executado nessa sessão, usando LogonUI para solicitar que o novo usuário do console “Pressione Ctrl+Alt+DELETE para Fazer Logon”, e nela o Logonui.exe solicitará as credenciais do usuário.
Startup process and session information
Startup process and session information (Clique na imagem para diminuir a exibição)
Startup process and session information
Startup process and session information (Clique na imagem para aumentar a exibição)

Provedores de Credenciais
Até mesmo a arquitetura de logon foi alterada no Windows Vista. Nas versões anteriores do Windows, o processo Winlogon carregava a DLL GINA (Graphical Identification and Authentication) especificada no Registro para exibir uma interface do usuário de logon que solicitava as credenciais do usuário. Infelizmente, o modelo GINA possui várias limitações, inclusive o fato de apenas uma GINA poder ser configurada, a criação de uma GINA completa ser difícil para terceiros e as GINAs personalizadas que possuem interfaces do usuário diferentes do padrão mudarem a experiência do usuário do Windows.
Em vez de uma GINA, o Windows Vista usa a nova arquitetura de Provedor de Credenciais. O Winlogon inicia um processo separado, o Host da Interface do Usuário de Logon (Logonui.exe), que carrega os provedores de credenciais configurados em HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. O Logonui pode hospedar vários provedores de credenciais simultaneamente; na verdade, o Windows Vista é fornecido com provedores interativos (Authui.dll) e de cartão inteligente (Smart-cardcredentialprovider.dll). Para assegurar uma experiência do usuário uniforme, o LogonUI gerencia a interface do usuário exibida para usuários finais, mas também permite que os provedores de credenciais especifiquem elementos personalizados como texto, ícones e editem controles.

Serviços de Início Automático Atrasado
Se você já fez logon em um sistema Windows logo após ele ser iniciado, provavelmente já passou por atrasos antes de sua área de trabalho ser totalmente configurada e você poder interagir com o shell e os aplicativos que iniciar. Enquanto você faz logon, o Gerenciador de Controle de Serviços inicia os vários serviços do Windows que são configurados como serviços de início automático e, portanto, são ativados no momento da inicialização. Muitos serviços executam inicializações com um alto consumo de CPU e disco, e que concorrem com suas atividades de logon. Para acomodar isso, o Windows Vista introduz um novo tipo de início de serviço chamado início automático atrasado, que os serviços podem usar se não precisarem estar ativos imediatamente após a inicialização do Windows.
O Gerenciador de Controle de Serviços inicia os serviços configurados para início automático atrasado depois que os serviços de início automático tiverem terminado de iniciar e define a prioridade do thread inicial como THREAD_PRIORITY_LOWEST. Esse nível de prioridade faz todas as E/Ss do disco executadas pelo thread terem uma prioridade de E/S Muito Baixa. Depois que a inicialização de um serviço é concluída, o Gerenciador de Controle de Serviços define sua prioridade como normal. A combinação de início atrasado, baixa prioridade de CPU e memória, e prioridade de disco em segundo plano reduz bastante a interferência com o logon de um usuário. Vários serviços do Windows, incluindo a Transferência Inteligente em Segundo Plano, o Cliente do Windows Update e o Windows Media® Center, usam o novo tipo de início para ajudar a melhorar o desempenho dos logons após uma inicialização.

Desligamento
Um problema que infernizou os criadores de serviços do Windows é que, durante o encerramento do Windows, eles têm, por padrão, um máximo de vinte segundos para executar a limpeza. As versões do Windows anteriores ao Windows Vista não davam suporte a um encerramento limpo, que aguardasse a saída de todos os serviços, porque um serviço com bugs pode manter um encerramento indefinidamente. Alguns serviços, como os que possuem operações de desligamento relacionadas à rede ou que possuem grandes quantidades de dados em disco, podem exigir mais tempo; assim, o Windows Vista permite que um serviço solicite a notificação pré-desligamento.
Quando o Windows Vista é desligado, o Gerenciador de Controle de Serviços notifica primeiro os serviços que solicitaram a notificação pré-desligamento. Ele aguardará indefinidamente que esses serviços saiam, mas se eles tiverem um bug e não responderem às consultas, o Gerenciador de Controle de Serviços desistirá e continuará após três minutos. Uma vez que todos os serviços tenham saído ou que o tempo limite tenha expirado, o Gerenciador de Controle de Serviços continuará com o desligamento do restante dos serviços no estilo herdado. Os serviços de Diretiva de Grupo e Windows Update registram as notificações pré-desligamento em uma nova instalação do Windows Vista.
Os serviços de Diretiva de Grupo e Windows Update também usam um outro recurso de serviços do Windows Vista: o pedido de desligamento. Os serviços sempre puderam especificar dependências de inicialização que o Gerenciador de Controle de Serviços segue para iniciar os serviços em uma ordem que os satisfaça, mas antes do Windows Vista eles não podiam especificar as dependências de desligamento. Agora, os serviços registrados para notificação pré-desligamento também podem se inserir na lista armazenada em HKLM\System\CurrentControlSet\Control\PreshutdownOrder e o Gerenciador de Controle de Serviços os desligará de acordo com seu pedido. Consulte a barra lateral "Identificando um Serviço de Pré-Desligamento e Início Automático Atrasado" para saber mais sobre esses serviços.

Gerenciamento de Energia
A suspensão e a hibernação são outras formas de desligamento, e os bugs no gerenciamento de energia em drivers e aplicativos foram motivo de grandes batalhas desde que o Windows 2000 introduziu o gerenciamento de energia na linha de sistemas operacionais Windows baseados no Windows NT®. Vários usuários esperavam que os sistemas de seus laptops fossem suspensos ou hibernassem ao fechar a tampa antes de embarcar em uma viagem e chegavam ao seu destino com uma maleta aquecida, uma bateria descarregada e dados perdidos. Isso porque o Windows sempre pediu o consentimento dos drivers de dispositivos e aplicativos para alterar o estado de energia e um único driver ou aplicativo sem resposta poderia impedir a transição.
No Windows Vista, o Gerenciador de Energia do kernel informa os drivers e aplicativos sobre as alterações no estado de energia, de modo que eles possam se preparar, mas não mais pede sua permissão. Além disso, o Gerenciador de Energia espera que os aplicativos respondam às notificações de alteração por no máximo 20 segundos, em vez dos dois minutos aguardados nas versões anteriores do Windows. Como resultado, os usuários do Windows Vista podem confiar mais no cumprimento das hibernações e suspensões pelos seus sistemas.

A seguir
Como mencionado anteriormente, esta é a segunda edição em uma série de três partes. A primeira parte abordou os aprimoramentos do kernel do Windows Vista nas áreas de processos e E/S. Desta vez, examinei os avanços do Windows Vista no gerenciamento de memória, inicialização e desligamento. Da próxima vez, concluirei a série descrevendo as alterações do kernel nas áreas de confiabilidade e segurança.
Identificando um Serviço de Pré-Desligamento e Início Automático Atrasado
O comando interno SC é atualizado no Windows Vista para mostrar os serviços configurados como serviços de início automático atrasado:
Using SC to display start type
Using SC to display start type (Clique na imagem para diminuir a exibição)
Using SC to display start type
Using SC to display start type (Clique na imagem para aumentar a exibição)
Infelizmente, o comando SC não relata os serviços que solicitaram notificação pré-desligamento, mas você pode usar o utilitário PsService da Sysinternals para ver se um serviço aceita a notificação pré-desligamento:
Viewing pre-shutdown status
Viewing pre-shutdown status (Clique na imagem para diminuir a exibição)
Viewing pre-shutdown status
Viewing pre-shutdown status (Clique na imagem para aumentar a exibição)

Mark Russinovich é um colega da área técnica da Microsoft na divisão de plataforma e serviços. Ele é co-autor do livro Microsoft Windows Internals (Microsoft Press, 2004) e palestrante assíduo em conferências de desenvolvedores e TI. Russinovich uniu-se à Microsoft com a recente aquisição da empresa de que foi co-fundador, a Winternals Software. Ele também criou a Sysinternals, onde publicou os utilitários Process Explorer, Filemon e Regmon.


 Do editor: Estante de trof&#233;us
Do editor
Estante de troféus
Joshua Trupin

PASSEI CERCA DE TRÊS DÉCADAS da minha vida sem ganhar nada. Meus bilhetes da loteria instantânea sempre acabavam com dois números errados e um rosto franzido. Abria os papéis de bala e lia “Desculpe, tente novamente”. Eu perdia as apostas de jogos decisivos dos times de futebol de Nova York.
Considerando esse péssimo histórico, não era de se admirar que eu fiquei emocionado quando ganhei alguma coisa. A TechNet Magazine acaba de receber quatro prêmios da STC (Sociedade de comunicação técnica). Trabalhamos arduamente em cada edição e é maravilhoso ter esse trabalho reconhecido. Quero reservar alguns momentos para agradecer à nossa equipe e aos autores por suas contribuições.
Nossa edição de março/abril de 2006 trouxe um guia claro e acessível do Active Directory na forma de um pôster de quebra-cabeça. Foi muito popular (na realidade, ainda recebemos pedidos diários de cópias desse pôster). A STC deu ao nosso pôster o prêmio de Excelência de guias de software.
Dois artigos nossos também receberam boas notas. Os artigos “Executando o Exchange em uma área de segurança” de Greg Taylor e Simon Shepherd (edição de agosto de 2006) e “Desconstruindo mitos comuns de segurança” de Jesper Johansson e Steve Riley (edição de maio/junho de 2006), ambos em inglês, foram elogiados pelo STC.
A própria TechNet Magazine recebeu um prêmio de Excelência em publicações científicas e profissionais. Fiquei muito orgulhoso desse reconhecimento e o mesmo posso dizer de todos que trabalham em nossa equipe.
Não se preocupe, não vamos parar por aqui. Nessa edição, Mark Russinovich explora mais alterações do kernel do Windows Vista (informações fundamentais e muito valiosas para qualquer profissional de TI envolvido na implementação da área de trabalho ou em serviços de suporte). Também estamos trazendo este mês uma cobertura completa do SQL Server, que serve para várias execuções, desde o uso dos metadados do índice até o particionamento da tabela e opções de alta disponibilidade para dicas de cluster.
Nunca descansamos na One TechNet Magazine Plaza. (Os prazos finais fazem isso por você.) No entanto, uma mudança ocasional é sempre bem-vinda. estaremos no Microsoft TechoEd em Orlando de 4 a 8 de junho de 2007 (consulte microsoft.com/teched). Venha encontrar alguns dos editores e autores premiados da TechNet Magazine. Temos algumas surpresas preparadas... Quem sabe você talvez também ganhe algum prêmio. - JOSHUA TRUPIN
Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Vijay Bharadwaj, Paul Bowden, Elden Christensen, Manish Karla, Michael Murgolo, Rajeev Nagar, John Peng, Mark Russinovich, Abraham Samuel, Mark Scurrell, Jim Truher, George Walters e Buck Woody.

Joshua Trupin


 Toolbox: Novos produtos para profissionais de TI
Toolbox
Novos produtos para profissionais de TI
Greg Steen

Gerenciar a sincronização da rede
ViceVersa Pro
www.tgrmn.com

A não ser que a sua infra-estrutura seja formada por uma única máquina, você provavelmente terá que mover arquivos no seu ambiente o tempo todo. Desde arquivos de log até edições de aplicativos a backups de bancos de dados, os dados sempre estão se movendo pela rede. E, é importante saber o que você precisa copiar para manter diferentes ambientes em sincronia. Para a maioria dos profissionais de TI, a movimentação manual desses arquivos entre ambientes não é uma opção, sem contar que em geral não se trata de uma boa idéia, já que pode resultar em más sincronizações.
O ViceVersa Pro da TGRMN Software permite automatizar e agendar facilmente essas tarefas. O aplicativo fornece quatro modos de cópia diferentes. A Sincronização básica fornece uma sincronização de origem para destino e a Sincronização avançada oferece sincronização bidirecional de arquivos e diretórios com rastreamento de arquivos. Os outros dois modos são Backup (que irá espelhar a origem) e Consolidação.
Enquanto o modo de Backup fará o espelhamento da origem para o destino, adicionando e excluindo arquivos a partir desse destino, você também pode escolher a replicação de arquivos, que apenas copiará os arquivos até o destino. Isso será muito útil no caso de usuários que excluem itens inesperadamente. O sincronizador bidirecional é executado como o nome sugere, com a adição do rastreamento de conflitos e de exclusões. Se um arquivo for alterado tanto na origem quanto no destino antes da próxima sincronização, um conflito será anotado e você poderá reconciliar o problema manualmente. O método de Consolidação é semelhante à sincronização bidirecional, mas não controla os conflitos ou as exclusões.
Protect against copy errors and data loss
Protect against copy errors and data loss (Clique na imagem para diminuir a exibição)
Protect against copy errors and data loss
Protect against copy errors and data loss (Clique na imagem para aumentar a exibição)
O ViceVersa Pro pode ajudar com as tarefas de transporte de logs usando os recursos integrados de compactação de arquivos e criptografia de arquivos no modo de Backup. O aplicativo compacta os arquivos de origem para o formato gzip padrão, que em seguida pode ser protegido por senha.
O aplicativo acompanha também uma boa comparação integrada de arquivos, mas, se você preferir, também poderá definir o ViceVersa Pro de forma a usar um programa externo de comparação de arquivos. Para suportar um ambiente global, o ViceVersa pode manipular caracteres e caminhos Unicode com mais de 256 caracteres. O aplicativo também possui um suporte integrado para sincronização de horário na Internet, para que você pode defini-lo de forma a apontar para a máquina NTP local ou para qualquer servidor NTP externo se permitir solicitações de saída a partir do ambiente no qual estará usando o aplicativo.
Às vezes, a utilização de largura de banda pode se tornar uma preocupação, especialmente se o tráfego estiver fluindo por uma VPN ou por uma WAN. Nesse caso, o ViceVersa permite regular a quantidade de largura de banda usada pelo aplicativo em cada tarefa de sincronização. Isso também pode ajudar a garantir a resposta em nível de produto a partir dos servidores que estão sendo usados como origem ou destino de cópias. Ou, se você preferir, poderá definir um limite máximo de utilização da CPU para também ajudar a garantir a disponibilidade na servidor quando o aplicativo estiver em execução.
O ViceVersa Pro protege contra erros de cópia e perda de dados usando um algoritmo de cópia seguro. O aplicativo também realiza exames de redundância cíclica de verificação para garantir a integridade dos dados. Você pode agendar tarefas de sincronização para execução em quase qualquer intervalo, incluindo o modo em tempo real (isso sincronizará arquivos à medida que eles forem adicionados ou excluídos nas pastas de sincronização).
Outro recurso interessante do ViceVersa Pro é que a interface com o usuário permite visualizar todas as operações antes da execução. Isso ajuda a garantir que você copie o que deseja copiar. Não é preciso terminar com alguns gigabites de arquivos de logs no diretório do sistema.
De modo geral, se você estiver procurando uma ferramenta de sincronização com recursos completos, o ViceVersa Pro poderá atender às suas necessidades.
Preço: US$ 59,95 por licença de usuário.

Administre os discos do seu sistema
Partition Manager 8.0 Professional Edition
www.partition-manager.com/corporate/professional
Se você estiver procurando um aplicativo para ajudá-lo a administrar os discos do seu sistema, definitivamente vale a pena considerar o Partition Manager 8.0 Professional Edition da Paragon Software.
Como funcionalidade central, o aplicativo com base no Windows® fornece uma interface intuitiva orientada por assistentes que permite criar, excluir, alterar a visibilidade e formatar facilmente partições de disco rígido, independentemente de elas estarem no formato FAT16/32, NTFS, Ext2/3 ou HPFS. Você também pode redimensionar partições existentes ou mover partições de um disco para outro.
Avançando mais uma etapa, é possível converter entre tipos de sistemas de arquivos, como NTFS a partir do FAT16/32 ou Ext2 para Ext3 e vice-versa. A cópia de uma partição entre discos redimensionará automaticamente a partição até o tamanho do disco, o que pode ser útil para estender a unidade de dados no sistema sem precisar copiar todos os arquivos manualmente. Um recurso útil da versão 8.0 é a capacidade de fazer um "Redimensionamento a quente", que permite aumentar o tamanho de uma partição NTFS ativa sem reinicializar o Windows.
Increase the size of an active NTFS partition £ without rebooting
Increase the size of an active NTFS partition £ without rebooting (Clique na imagem para diminuir a exibição)
Increase the size of an active NTFS partition £ without rebooting
Increase the size of an active NTFS partition £ without rebooting (Clique na imagem para aumentar a exibição)
Outro recurso útil da Pro Edition é que ela permite converter discos dinâmicos em discos básicos em clientes Windows 2000, Windows XP e Windows Server® 2003. O Partition Manager suporta discos de até pelo menos 500 GB (limite de teste da Paragon, não se trata de um verdadeiro limite físico), bem como unidades conectadas via FireWire e USB. O Partition Manager oferecerá suporte para unidades de disco rígido PATA (IDE), SATA e SCSI.
O Partition Manager permite criar um CD de recuperação (ou um DVD ou até mesmo um disquete) para ajudar a restaurar um sistema após uma falha de disco catastrófica. Ou, se você excluir por engano uma partição, mas o sistema ainda estiver ativa, será possível cancelar a exclusão dessa partição por meio da interface. É possível até mesmo alterar o tamanho do cluster do disco para ajudar a ajustar o desempenho. O aplicativo também oferece um modo de exibição "virtual pré-execução", permitindo avaliar as alterações no disco antes de confirmá-las fisicamente no disco.
Você também pode atualizar uma unidade de disco rígido no sistema com o Partition Manager 8.0. O aplicativo permite copiar uma partição ou uma imagem de unidade de disco rígido inteira em um novo disco, adaptando seu tamanho a uma partição de destino.
Por fim, o Partition Manager também contém um desfragmentador de disco incorporado que pode desfragmentar unidades até 99% cheias, embora convenha tomar uma medida antes que elas atinjam esse estado.
Preço: US$ 99,95 para a Professional Edition.

Adicione preenchimento automático ao SQL Editor
SQL Prompt: IntelliSense para SQL
www.red-gate.com/products/SQL_Prompt/index.htm

É tentador pensar que todos os bancos de dados são criados e estruturados com convenções de nomenclatura lógicas em um formato normalizado; mas infelizmente, todos nós sabemos que esse não é o caso. Ao fazer o papel do administrador do sistema ou do administrador do banco de dados, vejo-me na necessidade de consultar frequentemente a estrutura de tabelas ao criar ou executar consultas e ainda mais quando atuo como desenvolvedor.
Embora o SQL Server™ Management Studio para SQL Server 2005 tenha facilitado muito a minha vida por meio da integração de um navegador de objetos na seção do modo de exibição em árvore da interface, ainda me vejo desejando esse recurso com o qual me acostumei no IDE do Visual Studio®: o IntelliSense®. Felizmente, a Red-Gate Software oferece o SQL Prompt, que oferece preenchimento automático para os editores do Microsoft SQL Server.
O aplicativo é executado na narra de tarefas e detecta quando você começa a trabalhar em um editor. Em primeiro lugar, o SQL Prompt solicitará as informações de conexão para esse banco de dados para poder alcançar e armazenar em cache todos os dados de objetos. Isso acelera o desempenho e reduz a sobrecarga, mas, se você estiver constantemente modificando objetos na instância do banco de dados, precisara lembrar-se de limpar o cache (o que é uma ação simples de dois cliques) para ver suas alterações na lista de prompts.
Além dos IDEs do Visual Studio, do Enterprise Manager, do Query Analyzer e do SQL Server Management Studio, o SQL Prompt também é integrado diretamente ao UltraEdit e ao EditPlus 2. Na guia Opções da interface do usuário de configurações, você pode indicar quais são as palavras-chave SQL desejadas para acionar a lista de candidatas (como FROM, JOIN, EXEC e assim por diante). O acionamento do SQL Prompt em SQL JOINS ainda fornecerá a instrução ON (supondo que você tenha um conjunto de referências ou que os campos estejam igualmente nomeados). Aqui, você também pode definir atalhos de texto para a inserção de snippets de código. Por exemplo, o aplicativo define "ssf" seguido da tecla Tab para explicitar "SELECT * FROM". Você também pode fazer com que o SQL Prompt altere automaticamente as palavras-chave SQL para letras maiúsculas ao digitá-las. Isso e os snippets de código poupam um grande tempo sem dúvida.
Na guia Candidatas da interface do usuário de configurações, você pode definir se deseja que o SQL Prompt use nomes de colunas totalmente qualificados, se deseja prefixar com informações de proprietários/esquema, delimitar nomes entre colchetes e até mesmo definir os tipos de funções SQL que deseja apresentar na lista de candidatas. Se você usar SQL, convém adicionar essa ferramenta à sua lista de técnicas.
O SQL Prompt continuará gratuito até o lançamento da versão 3.0, que, na ocasião da elaboração deste documento, estava no beta final. O preço para a versão 3.0 ainda não foi informado.
Preço: gratuito.

Calcule o tamanho das páginas
Atomic Web Page Size Calculator
www.info-pack.com/pagesize
A largura de banda dos usuários finais está ficando cada vez maior e novas tecnologias estão ajudando a fornecer conteúdo da Web mais rapidamente a esses usuários, mais o tamanho das páginas ainda é importante. Todos esses bytes podem resultar em um grande custo de largura de banda para um site de alto tráfego.
O utilitário Atomic Page Size Calculator do Info-pack.com fornece uma maneira simples e econômica de verificar o tamanho das páginas de sites da Web. Tudo o que você precisa fazer é digitar a URL da página de tamanho questionável e o programa captura a página, calculando o tamanho de todos os elementos, incluindo as imagens externamente referenciadas, itens que talvez não apareçam em logs da Web referentes ao seu domínio primário.
Keep an eye on bandwidth cost
Keep an eye on bandwidth cost (Clique na imagem para diminuir a exibição)
Keep an eye on bandwidth cost
Keep an eye on bandwidth cost (Clique na imagem para aumentar a exibição)
O calculador oferece suporte par arquivos de página, imagem e JavaScript e, portanto, você pode obter dados sobre a maioria dos recursos na sua página. O aplicativo também o notificação quando encontrar um recurso "quebrado" 404. Quando você obter as informações sobre tamanho da URL, clique no botão Report para ver a decomposição desse tamanho e as estimativas do tempo que será necessário para o download dessa URL em várias velocidades de conexão.
Seria ótimo se esse aplicativo pudesse controlar várias URLs simultaneamente, mas talvez isso seja possível em uma versão futura. Se você procura uma maneira rápida de verificar o tamanho das páginas da sua equipe de desenvolvimento, esse aplicativo pode ser ideal.
Preço: US$ 19,95 direto.

Escreva para o Toolbox
Se você tiver uma ferramenta ou um utilitário favorito que queira apresentar aqui, escreva para o autor em tntools@microsoft.com.
Greg Steen é profissional de tecnologia, empresário e entusiasta. Ele está sempre buscando novos métodos e ferramentas para facilitar as operações e o desenvolvimento para os profissionais de TI.


 Destaque de utilit&#225;rio: SyncToy
Destaque de utilitário
SyncToy
Jay Munro
Faça download do código deste artigo: SyncToy (971KB)

UMA DOR DE CABEÇA QUE acomete da mesma maneira os profissionais de TI, administradores de rede e funcionários de Suporte Técnico são as chamadas de usuários cujos computadores se foram sem um backup. Às vezes, é difícil convencer até mesmo os caras mais espertos a salvar seu trabalho na rede e não apenas localmente. O SyncToy pode ajudar nisso.
Criado originalmente para sincronizar fotografias digitais entre a câmera, o computador e unidades externas, o SyncToy é uma forma flexível e confiável de fazer backup de quase qualquer tipo de arquivo. Executado no Windows Vista™, no Windows® XP e no Windows Server® 2003, o SyncToy funciona com unidades locais, externas ou USB, além de compartilhamentos de rede ou de grupos de trabalho.
O SyncToy usa uma arquitetura de pastas emparelhadas, na qual você especifica um diretório esquerdo e outro direito. Você pode criar quantos pares de pastas desejar e sincronizar um ou todos eles com um único clique. Para criar um par de pastas, é necessário percorrer um rápido assistente com quatro etapas, onde você digita ou copia um caminho, ou navega para o local das pastas esquerda e direita. O SyncToy reconhece a nomenclatura de arquivos UNC (como \\MeuServidor\Joe_smith\backup\), além de caminhos e mapeamentos de unidades locais (E:\doc_backup). Depois de inserir os caminhos, você escolhe uma dentre cinco ações que o SyncToy executará ao comparar as pastas.
Sync (Sincronizar) Copia os arquivos novos e atualizados nas duas direções. Se você renomear ou excluir um arquivo em uma pasta, essa ação será replicada na outra.
Echo (Eco) Copia arquivos novos e atualizados; exclui e renomeia apenas da pasta esquerda para a direita.
Subscribe (Inscrever-se) Copia os arquivos atualizados da direita para a esquerda, apenas se o arquivo já existir à esquerda. As alterações feitas à esquerda não serão replicadas à direita.
Contribute (Contribuir) Copia arquivos novos e atualizados da esquerda para a direita, ignorando as exclusões.
Combine (Combinar) Mantém várias máquinas em lockstep, copiando os arquivos que existem em um lado, mas não no outro. Os arquivos que são excluídos ou renomeados em um dos lados não são afetados ou replicados.
Depois de selecionar a ação, escolha um nome amigável para o par de pastas e pronto. Atualmente, o SyncToy não permite editar caminhos ou alterar o nome depois de criar um par de pastas; assim, se errar, selecione o par de pastas, clique para excluí-lo e crie-o novamente. Você pode definir opções, inclusive os arquivos e subdiretórios que serão incluídos e se os arquivos substituídos devem ser salvos na Lixeira (ativado por padrão).
Synchronizing files with SyncToy
Synchronizing files with SyncToy (Clique na imagem para diminuir a exibição)
Synchronizing files with SyncToy
Synchronizing files with SyncToy (Clique na imagem para aumentar a exibição)

A caixa de diálogo principal do SyncToy exibe pares de pastas à esquerda, junto com os caminhos, opções e ações do par selecionado. A opção All Folder Pairs (Todos os Pares de Pastas) lista todos os seus pares de pastas, e você pode Preview (Visualizar) ou Run All (Executar Todos) os pares marcados. Como seria esperado, Preview (Visualizar) passa pelas ações como se a sincronização estivesse sendo executada, mas as alterações não são realizadas. Vale a pena fazer isso se você for agendar sincronizações autônomas. Essa visualização exibe um relatório, que o informa sobre as operações que seriam feitas. Se estiver tudo correto, clique em Run (Executar).
O agendamento não é interno, apesar de o arquivo da Ajuda possuir uma demonstração muito boa para os agendadores do Windows Vista e do Windows XP. Os usuários não-técnicos podem precisar de ajuda nessa configuração, mas é necessário fazê-la apenas uma vez, pois todas as alterações dos pares de pastas, ações e opções são feitas no próprio SyncToy.
Como todos os Power Toys, o SyncToy, apesar de ser escrito nos mesmos padrões que os softwares regulares, não tem suporte da Microsoft, apenas por meio da documentação e dos fóruns da comunidade. Assim, você está sozinho. O arquivo da Ajuda foi criado para todos os níveis de uso e aborda os recursos de maneira bastante abrangente. A interface do usuário é suficientemente intuitiva para você entender os princípios básicos de primeira.
Então, baixe o SyncToy e mostre a seus usuários como fazer backup de arquivos. Todos poderão dormir melhor.

Jay Munro é escritor da equipe de Assistência ao Usuário do Windows da Microsoft, especializado em Internet Explorer. Anteriormente, ele foi líder de projeto nos laboratórios da PC Magazine.


 SQL Q&amp;A: Hor&#225;rio de ver&#227;o, Mem&#243;ria do servidor e mais
SQL Q&A
Horário de verão, Memória do servidor e mais
Editado por Nancy Michell

Horário de verão
P Considerando as alterações futuras no Horário de verão nos Estados Unidos de forma a obedecer ao Energy Policy Act de 2005, devo atualizar o SQL Server™?
R Não. Atualmente, não há atualizações específicas do SQL Server necessárias para oferecer suporte às alterações devido ao horário de verão. O SQL Server depende do sistema operacional subjacente para dados relacionados ao tempo, o que significa que, se o sistema operacional estiver reportando as datas e os horários corretos, o SQL Server reportará e usará os mesmos valores. Para estar em conformidade com as alterações futuras no horário de verão, você precisará atualizar as suas cópias do Windows® conforme descrito em support.microsoft.com/kb/928388. Isso será necessário em todos os sistemas operacionais Windows anteriores ao Windows Vista™ (que já inclui as alterações) para que eles mantenham a conformidade com as mudanças do horário de verão, incluindo os sistemas operacionais que executam o SQL Server. (A Austrália também está passando por algumas alterações. Consulte support.microsoft.com/kb/912475.)

Conectando-se com o Windows Vista
P Instalei o Windows Vista e, agora, não consigo me conectar com o SQL Server 2005 no meu sistema. Sou administrador local e era capaz de fazer essa conexão sem qualquer problema. O que aconteceu?
R Esse é um comportamento esperado no Windows Vista e no SQL Server 2005 sem o Service Pack 2 (SP2). O Windows Vista tem um novo modelo de segurança (Controle de contas de usuário) que, na verdade, captura sua associação no grupo do administrador local e solicita que você verifique as operações que exigem privilégios administrativos. Se você clicar no botão Permitir, as suas credenciais, que incluem o token de administrador, serão enviadas junto com o aplicativo. No caso do SSMS (SQL Server Management Studio), nenhuma caixa de diálogo é exibida porque a simples execução da ferramenta não exige permissões administrativas. O problema é que, por padrão, a função de administrador do sistema do SQL Server 2005 inclui o grupo de administradores locais a partir do sistema operacional, que a sua conta costumava usar no passado para acessar o SQL Server. Como o Windows Vista não está despachando essa permissão, você não obtém nenhum acesso.
Deve-se observar que a execução do SQL Server 2005 sem o SP2 não é suportada no Windows Vista e que o SP2 tem uma ferramenta que adicionará a sua conta para você. Se você ainda estiver aguardando o SP2, a correção será bastante simples. A sua conta de usuário Windows individual deverá ser adicionada ao SQL Server, no seu caso, à função do administrador do sistema. Para fazer isso, basta clicar com o botão direito no SQL Server Management Studio e selecionar Executar como Administrador. Conecte-se ao SQL Server e adicione a sua conta Windows à função do administrador do sistema. Consulte SQL Server Books Online para obter mais informações sobre como isso funciona.

Replicação transacional com modos de exibição
P Se eu tiver um modo de exibição publicado e atualizá-lo, sei que a transação será replicada. Entretanto, se eu atualizar a tabela base desse modo de exibição, essa transação será replicada? Além disso, se eu tiver uma tabela publicada e criar um modo de exibição dela e atualizar esse modo de exibição em vez da tabela base, essa transação será replicada?
R Supondo que a tabela base esteja configurada como um artigo em uma publicação (ou seja, você configurou a tabela base para replicação também), qualquer atualização na tabela base seria replicada.
Quando você replicar um modo de exibição, por padrão, tudo o que será replicado como parte de um modo de exibição é a parte de esquema desse modo de exibição ou código por detrás do modo de exibição e não os dados que dão suporte para ele (a menos que você tenha um modo de exibição indexado). Dessa forma, mesmo sem a replicação, a qualquer momento que você atualizar um modo de exibição, o que significa executar uma instrução DML (Data Manipulation Language) com o modo de exibição como destino, na verdade, apenas estará atualizando os dados na tabela adjacente e não o modo de exibição. Um modo de exibição é apenas um armazenamento lógico de uma instrução de consulta sem armazenamento físico conectado (novamente, a não ser que você esteja usando modos de exibição indexados).

Memória máxima do servidor
P Tenho uma máquina que executa o Windows Server® 2003 e o SQL Server 2000, com 5 GB de RAM. Digamos que eu use a opção /3GB para aumentar meu espaço de endereçamento virtual de modo do usuário, a opção /PAE para carregar a versão PAE (Physical Address Extension) do kernel do Windows e defina a opção AWE (Address Windowing Extensions) habilitada como 1 (e habilite páginas bloqueadas na memória). Com o AWE habilitado, a opção de memória máxima do servidor configurará apenas o tamanho do cache de dados ou o tamanho de todos os caches de buffer (dados, processos, sessões e assim por diante)? Como apenas o cache de dados pode usar a memória mapeada pelo AWE, se eu configurar a memória máxima do servidor como 4 GB, o cache de dados usará apenas 1 GB (a parte mapeada pelo AWE) ou ele pode usar esse 1 GB extra e continuar a usar ou competir com todos os outros consumidores de memória no espaço de endereçamento padrão?
R A memória máxima do servidor sempre limitará o tamanho do pool de buffer inteiro. Entretanto, o único consumidor que pode usar a memória mapeada pelo AWE é o cache de dados e nada mais.
Portanto, para a primeira pergunta, mesmo com o AWE habilitado, a memória máxima do servidor ainda limita o pool do buffer inteiro, mas os consumidores que não fazem parte do cache de dados nem mesmo usarão nenhuma parte da memória mapeada pelo AWE.
Para a segunda pergunta, o cache de dados ainda usará a memória mapeada pelo AWE além de qualquer outra memória no pool de buffer que o SQL Server determinar apropriada. Ele não ficará limitado apenas à memória do AWE e acabará sendo o único consumidor que usará a memória do AWE. Se você não tiver certeza sobre a função da opção /3GB, consulte o blog de Raymond Chen.

Criação de perfil e desempenho
P Tenho o SQL Server 2005 espelhado em produção. Quando inicio o SQL Server Profiler na máquina do banco de dados e escrevo os dados de rastreio em um arquivo, vejo uma queda drástica no desempenho. Por quê?
R O motivo da queda no desempenho depende do local em que o Profiler está sendo executado. Se você o estiver executando interativamente na máquina do servidor, a interface do usuário do Profiler estará consumindo memória e CPU no servidor, o que prejudicará o desempenho.
Se você estiver executando o Profiler interativamente em uma estação de trabalho, estará movendo as informações de eventos pela rede. Isso afeta o rendimento. Se for a mesma rede usada para espelhamento, você verá também perceberá um certo impacto. Além disso, se estiver armazenamento a saída do Profiler em um compartilhamento de rede, estará movendo dados pela rede e prejudicando o desempenho.
Provavelmente, a melhor maneira de aliviar tudo isso é executar o Profiler de forma não interativa no servidor que está executando a instância para a qual o perfil será criado e, então, canalizar a saída para um arquivo local. Você ainda estará consumindo recursos do servidor, mas essa abordagem geralmente apresenta o menor impacto. Isso funciona muito melhor do que o rastreio do Profiler (na memória). O rastreio de arquivos usa a memória do sistema de forma mais eficiente. Ele tem buffers maiores e os descarrega no disco de forma mais eficaz. Também não depende de processos externos (como o SQL Server Profiler).
Por fim, os dados de rastreio são gravados em um arquivo de disco enquanto o Profiler ainda está criando perfis. O arquivo de rastreio é compartilhado de forma que outras pessoas possam ver os dados de perfil em tempo real remotamente. Se você estiver chamando o arquivo de rastreio interativamente, significa que o Profiler foi chamado manualmente e a saída está sendo visualizada na tela. Rastreios podem ser criados programaticamente sem saída visual, o que explica por que você deve executar as coisas não interativamente.
É possível criar um compartilhamento sobre um diretório local, e outras pessoas podem acessar os arquivos que se encontram nesse local; em geral, esse procedimento não apresenta problemas. Como mencionado anteriormente, você não deseja enviar a saída de rastreio a um arquivo no compartilhamento remoto, especialmente para um que seja acessado por meio do mesmo canal de rede usado para espelhamento.
Você também deve selecionar apenas o conjunto mínimo de eventos necessários para a sua investigação. Para o local do arquivo de rastreio, é necessário escolher a unidade mais rápida no sistema (de preferência, diferente das unidades de logs de transações e de banco de dados do SQL Server). Se você ainda perceber uma degradação significativa no desempenho, divida os eventos em dois ou mais rastreios, cada um direcionado para uma unidade de disco rígido diferente. Mesmo que os rastreios estejam direcionados para a mesma unidade de disco rígido, você ainda terá os benefícios de uma divisão devido ao fato de que cada rastreio tem o seu próprio conjunto de buffers. Consulte sp_trace_create e todos os seus parentes no SQL Server Books Online para obter mais informações.

Problemas de armazenamento em cluster
P Estou tentando instalar o SQL Server em um cluster que executa o Windows Server 2003. Sempre que tento fazer isso, recebo um erro que afirma a falha na instalação ao executar as operações necessárias nos nós em cluster. Sqlstp.log indica:
Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...
O que pode estar ocorrendo?
R Existem vários motivos possíveis para essa falha. A instalação instala o Serviço do Windows NT® em todos os nós selecionados para gerenciar remotamente o processo de instalação nas máquinas individuais. Portanto, é necessário ficar atento a uma série de possíveis dificuldades.
Em primeiro lugar, os usuários de contas de domínios têm uma diretiva de grupo que nega a permissão "fazer logon como serviço". (Lembre-se de que a diretiva de domínio substitui a diretiva da máquina local.) Certifique-se de usar uma conta sem essas restrições.
Em segundo lugar, a conta conectada da máquina a partir da qual você executa a instalação deve ter acesso de administração em todos os nós devido ao seguinte fator: o processo de instalação Master requer acesso ao registro remoto a todas as máquinas; a instalação copia cnvsvc.exe para o diretório Windows da máquina remota ou a instalação usa as APIS padrão do Windows que usam apenas a permissão da conta conectada para acessar máquinas remotas. Por esses motivos, você deve fazer logon como administrador em todos os modos por padrão.

Plano de recuperação após desastres
P Estou considerando se devo usar o espelhamento do banco de dados (modo assíncrono) ou o transporte de logs para implementar minha estratégia de DR (recuperação após desastres) para meus bancos de dados SAP. Meus locais de produção e de DR terão uma conexão de banda larga de 100 Mb não dedicada à sessão de espelhamento. A conexão será compartilhada com diferentes sessões de espelhamento ou até mesmo com outros servidores de DR.
Se houver um problema de rede que impeça o envio do registro de log ao banco de dados espelho, haverá uma nova tentativa?
Quando a sessão de espelhamento for suspensa, haverá um período de retenção? E, além dos modos de exibição do sistema, existem informações de registro de log que eu possa usar para monitorar o tráfego de espelhamento e a transmissão de registros de log?
R Vamos começar respondendo a pergunta: qual é a lógica de novas tentativas do espelhamento de bancos de dados? É possível considerá-la de duas maneiras: Em primeiro lugar, se houver um problema de rede temporário, o estado da sessão de espelhamento será desconectado. Existe um valor de tempo limite padrão de 10 segundos, ou seja, um registro de log não pode ser enviado a partir do banco de dados principal ao banco de dados espelho. Nesses casos, o principal continuará a executar "exposto" e a transação será confirmada no lado do cliente. Quando o problema de rede for resolvido, a sessão de espelhamento será repetida automaticamente sem nenhuma intervenção do usuário. Ela tentará recuperar-se usando os registros de log, os parceiros serão sincronizados primeiro e, quando forem recuperados, o estado será sincronizado.
Em segundo lugar, se houver um problema de retrabalho, o estado da sessão de espelhamento será suspenso. Um problema de retrabalho significa que o banco de dados espelho não consegue confirmar os registros de log em seu banco de dados. Problemas de retrabalho são principalmente causados por um arquivo físico que não foi encontrado ou por espaço em disco insuficiente. Nesses casos, o principal continuará a executar exposto e, portanto, a transação será confirmada no lado do cliente. Após a correção manual do problema de retrabalho no servidor espelho, a sessão do espelho exigirá intervenção:
ALTER DATABASE <db> SET PARTNER RESUME;
No que se refere aos períodos de retenção, a resposta é que, independentemente de a sessão do espelho estar desconectada ou suspensa, os registros de log serão mantidos até que essa sessão seja restaurada e todos os registros desde o momento em que ela foi suspensa até o momento em que ela foi reinicia sejam estabilizados no espelho. Basicamente, enquanto a sessão de espelhamento estiver desconectada ou suspensa, o log no principal não pode ser truncado, porque isso quebraria a cadeia de retrabalho de logs. Isso significa que o log do principal crescerá ilimitado até a restauração da sessão. Portanto, não existe na verdade um limite de retenção na sessão de espelhamento. A única restrição real é o espaço em disco que o servidor principal possui para armazenar o log, pois o log não pode ser truncado.
Por fim, não há um arquivo de log específico que possa ser usado para monitorar o espelhamento. O SQL Server 2005 fornece uma ferramenta de GUI chamada Monitor de espelhamento de banco de dados para essa finalidade, que permite aos administradores de sistema visualizar e atualizar o status e configurar limites de aviso em várias métricas de desempenho do sistema. A partir dessa ferramenta, você recebe um alerta quando o espelhamento não apresenta um bom desempenho. A principal preocupação de desempenho com relação ao espelhamento do banco de dados é se os registros de log são processados de maneira oportuna. Para obter mais informações sobre o monitoramento do espelhamento de bancos de dados, consulte o artigo sobre monitoramento do status do espelhamento em msdn2.microsoft.com/fr-fr/library/ms365781.aspx.

Meus agradecimentos aos seguintes profissionais de TI da Microsoft por seus conhecimentos técnicos: Chad Boyd, Sandu Chirica, Alan Doby, Kaloian Manassiev, Luciano Moreira, Ivan Penkov, Sivagaminathan Rajarethinam, Deborah To, Patrick Woodward, Buck Woody, Stanley Yau e Warren Young.


 The Cable Guy: O protocolo DHCPv6
The Cable Guy
O protocolo DHCPv6
Joseph Davies

O protocolo DHCP foi criado para cuidar da atribuição de endereços IP e outras informações de rede para os computadores, de modo que eles possam se comunicar na rede automaticamente. Com uma rede IPv6, você não precisa realmente do DHCP para configurar endereços, mas pode haver bons motivos para usá-lo. O DHCP para IPv6 (DHCPv6) pode
fornecer configuração de endereços com monitoração de estado ou configuração sem monitoração de estado para hosts IPv6. Os hosts IPv6 podem usar vários métodos para configurar endereços:
Configuração Automática de Endereço sem Monitoração de Estado é usada para configurar endereços locais vinculados e endereços locais não vinculados adicionais por meio da troca de mensagens de Solicitação de Roteador e Anúncio de Roteador com roteadores vizinhos.
Configuração Automática de Endereço com Monitoração de Estado é usada para configurar endereços locais vinculados usando um protocolo de configuração, como o DHCP.
Um host IPv6 executa a configuração automática de endereço sem monitoração de estado automaticamente e usa um protocolo de configuração, como o DHCPv6, com base nos seguintes sinalizadores na mensagem de Anúncio de Roteador enviada por um roteador vizinho:
Sinalizador de Configuração de Endereço Gerenciado, também conhecido como sinalizador M. Quando definido como 1, esse sinalizador instrui o host a usar um protocolo de configuração para obter endereços com monitoração de estado.
Outro Sinalizador de Configuração com Monitoração de Estado , também conhecido como sinalizador O. Quando definido como 1, esse sinalizador instrui o host a usar um protocolo de configuração para obter outras configurações.
A combinação dos valores dos sinalizadores M e O pode resultar no seguinte:
Os Sinalizadores M e O Estão Definidos como 0. Essa combinação corresponde a uma rede sem uma infra-estrutura DHCPv6. Os hosts usam anúncios de roteadores de endereços locais não vinculados e outros métodos (como a configuração manual) para definir outras configurações.
Os Sinalizadores M e O Estão Definidos como 1. O DHCPv6 é usado para os dois endereços e outras configurações. Essa combinação é conhecida como DHCPv6 com monitoração de estado, em que o DHCPv6 atribui endereços com monitoração de estado a hosts IPv6.
O Sinalizador M Está Definido como 0 e o Sinalizador O Está Definido como 1. O DHCPv6 não é usado para atribuir endereços, apenas para atribuir outras configurações. Os roteadores vizinhos estão configurados para anunciar prefixos de endereços locais não vinculados dos quais os hosts IPv6 derivam endereços sem monitoração de estado. Essa combinação é conhecida como DHCPv6 sem monitoração de estado: o DHCPv6 não atribui endereços com monitoração de estado aos hosts IPv6, mas definições de configuração sem monitoração de estado.
O Sinalizador M Está Definido como 1 e o Sinalizador O Está Definido como 0. Nessa combinação, o DHCPv6 é usado para a configuração de endereços, mas não para outras configurações. Devido ao fato de normalmente os hosts IPv6 precisarem ser configurados com outras definições, como os endereços IPv6 de servidores DNS, essa é uma combinação improvável.
Como o DHCP para IPv4, os componentes de uma infra-estrutura DHCPv6 consistem em clientes DHCPv6 que solicitam configuração, servidores DHCPv6 que fornecem configuração e agentes de retransmissão DHCPv6 que passam as mensagens entre clientes e servidores quando os clientes estão em sub-redes que não possuem um servidor DHCPv6.

Mensagens DHCPv6
Da mesma forma que o DHCP para IPv4, o DHCPv6 usa mensagens do protocolo UDP. Os clientes DHCPv6 escutam mensagens DHCP na porta UDP 546. Os servidores e agentes de retransmissão DHCPv6 escutam mensagens DHCPv6 na porta UDP 547. A estrutura das mensagens DHCPv6 é muito mais simples que no DHCP para IPv4, que tem sua origem no protocolo BOOTP para dar suporte a estações de trabalho sem disco. A Figura 1 mostra a estrutura das mensagens DHCPv6 enviadas entre cliente e servidor.
Figure 1 DHCPv6 messages between client and server
Figure 1 DHCPv6 messages between client and server (Clique na imagem para diminuir a exibição)
Figure 1 DHCPv6 messages between client and server
Figure 1 DHCPv6 messages between client and server (Clique na imagem para aumentar a exibição)
O campo Tipo de Mensagem de um byte indica o tipo de mensagem DHCPv6. O campo ID da Transação de três bytes é determinado por um cliente e usado para agrupar as mensagens de uma troca de mensagens DHCPv6. Seguindo o campo ID da Transação, as opções de DHCPv6 são usadas para indicar a identificação de cliente e servidor, endereços e outras configurações. Para obter a lista de opções de DHCPv6 definidas, consulte RFC 3315, conforme referenciado na barra lateral "Recursos RFC do DHCPv6".
As opções de DHCPv6 são formatadas em TLV (tipo-tamanho-valor). A Figura 2 mostra a estrutura das opções de DHCPv6.
O campo Opção-Código de dois bytes indica uma opção específica. O campo Opção-Comprimento de dois bytes indica o comprimento do campo Opção-Dados em bytes. O campo Opção-Dados contém os dados da opção.
Existe uma estrutura separada para a troca de mensagens entre agentes de retransmissão e servidores, para o registro de informações adicionais. A Figura 3 mostra a estrutura desses tipos de mensagens.
Figure 2 Structure of DHCPv6 options
Figure 2 Structure of DHCPv6 options (Clique na imagem para diminuir a exibição)
Figure 2 Structure of DHCPv6 options
Figure 2 Structure of DHCPv6 options (Clique na imagem para aumentar a exibição)
O campo Contagem de Saltos de um byte indica o número de agentes de retransmissão que receberam a mensagem. Um agente de retransmissão receptor poderá descartar a mensagem, se ela exceder uma contagem de saltos máxima configurada. O campo Endereço do Link de 16 bytes contém um endereço local não vinculado que é atribuído a uma interface conectada à sub-rede na qual o cliente está localizado. A partir do campo Endereço do Link, o servidor pode determinar o escopo de endereços correto a partir do qual será atribuído um endereço. O campo Endereço de Mesmo Nível de 16 bytes contém o endereço IPv6 do cliente que enviou a mensagem originalmente ou o agente de retransmissão anterior que retransmitiu a mensagem. Além do campo Endereço de Mesmo Nível estão as opções de DHCPv6 que incluem a opção Mensagem de Retransmissão, que contém a mensagem retransmitida e outras opções. A opção Mensagem de Retransmissão fornece um encapsulamento das mensagens trocadas entre o cliente e o servidor.
Não há endereços de difusão definidos para o IPv6. Portanto, o uso do endereço de difusão limitado para algumas mensagens DHCPv4 foi substituído pelo uso do endereço de Todos_os_servidores_e_Agentes_de_Retransmissão_DHCP FF02::1:2 para DHCPv6. Por exemplo, um cliente DHCPv6 que tenta descobrir o local do servidor DHCPv6 na rede envia uma mensagem Solicit (Solicitação) de seu endereço local vinculado para FF02::1:2. Se houver um servidor DHCPv6 na sub-rede do host, ele receberá a mensagem Solicit e enviará uma resposta apropriada. O mais comum é um agente de retransmissão DHCPv6 na sub-rede do host receber a mensagem Solicit e encaminhá-la para um servidor DHCPv6.
Figure 3 Structure of messages between relay and server
Figure 3 Structure of messages between relay and server (Clique na imagem para diminuir a exibição)
Figure 3 Structure of messages between relay and server
Figure 3 Structure of messages between relay and server (Clique na imagem para aumentar a exibição)

Troca de mensagens com monitoração de estado
Uma troca de mensagens com monitoração de estado DHCPv6 para obter endereços IPv6 e configurações – quando os sinalizadores M e O em um anúncio de roteador recebido estão definidos como 1 – consiste normalmente nas seguintes mensagens:
  • Uma mensagem Solicit (Solicitação) enviada pelo cliente para localizar os servidores.
  • Uma mensagem Advertise (Anúncio) enviada por um servidor para indicar que ele pode fornecer endereços e configurações.
  • Uma mensagem Request (Solicitação) enviada pelo cliente para solicitar endereços e configurações de um servidor específico.
  • Uma mensagem Reply (Resposta) enviada pelo servidor solicitado que contém endereços e configurações.
Se houver um agente de retransmissão entre o cliente e o servidor, ele enviará as mensagens Relay-Forward (Retransmissão-Encaminhamento) do servidor que contêm as mensagens Solicit e Request do cliente. O servidor envia as mensagens Relay-Reply (Retransmissão-Resposta) do agente de retransmissão que contêm as mensagens Advertise e Reply para o cliente. Para obter uma lista completa das mensagens DHCPv6, consulte a Figura 4.
Figure 4 Mensagens DHCPv6 (Close Figure 4)

Mensagem DHCPv6 | Description (Descrição) | DHCP equivalente à mensagem IPv4
Solicit (Solicitação) | Enviada por um cliente para localizar servidores. | DHCPDiscover
Advertise (Anúncio) | Enviada por um servidor em resposta a uma mensagem Solicit para indicar a disponibilidade. | DHCPOffer
Request (Solicitação) | Enviada por um cliente para solicitar endereços ou configurações de um determinado servidor. | DHCPRequest
Confirm (Confirmação) | Enviada por um cliente para todos os servidores para determinar se a configuração de um cliente é válida para o link conectado. | DHCPRequest
Renew (Renovação) | Enviada por um cliente a um servidor específico para estender a vida útil dos endereços atribuídos e obter configurações atualizadas. | DHCPRequest
Rebind (Revincular) | Enviada por um cliente a qualquer servidor quando uma resposta à mensagem Renew não é recebida. | DHCPRequest
Reply (Resposta) | Enviada por um servidor a um cliente específico em resposta a uma mensagem Solicit, Request, Renew, Rebind, Information-Request, Confirm, Release ou Decline. | DHCPAck
Release (Liberação) | Enviada por um cliente para indicar que o cliente não está mais usando um endereço atribuído. | DHCPRelease
Decline (Recusa) | Enviada por um cliente a um determinado servidor para indicar que o endereço atribuído já está em uso. | DHCPDecline
Reconfigure (Reconfiguração) | Enviada por um servidor a um cliente para indicar que o servidor possui configurações novas ou atualizadas. Em seguida, o cliente envia uma mensagem Renew ou Information-Request. | N/D
Information-Request (Informação-Solicitação) | Enviada por um cliente para solicitar configurações (mas não endereços). | DHCPInform
Relay-Forward (Retransmissão-Encaminhamento) | Enviada por um agente de retransmissão para encaminhar uma mensagem a um servidor. A Relay-Forward contém uma mensagem de cliente encapsulada como a opção Relay-Message (Retransmissão-Mensagem) do DHCPv6. | N/D
Relay-Reply (Retransmissão-Resposta) | Enviada por um servidor para enviar uma mensagem a um cliente por meio de um agente de retransmissão. A Relay-Reply contém uma mensagem do servidor encapsulada como a opção Relay-Message (Retransmissão-Mensagem) do DHCPv6. | N/D

Troca de mensagens sem monitoração de estado
Uma troca de mensagens sem monitoração de estado DHCPv6 para obter apenas as configurações – quando o sinalizador M está definido como 0 e o sinalizador O está definido como 1 em um anúncio de roteador recebido – consiste normalmente nas seguintes mensagens: uma mensagem Information-Request (Informação-Solicitação) enviada pelo cliente DHCPv6 para solicitar configurações de um servidor e uma mensagem Reply (Resposta) enviada por um servidor que contém as configurações solicitadas.
Para uma rede IPv6 que possui roteadores configurados para atribuir prefixos de endereços sem monitoração de estado a hosts IPv6, a troca DHCPv6 de duas mensagens pode ser usada para atribuir servidores DNS, nomes de domínio DNS e outras configurações que não estão incluídas na mensagem de anúncio de roteador.

Suporte a DHCPv6 no Windows
O Windows Vista™ e a próxima versão do Windows Server®, cujo codinome é "Longhorn", incluem um cliente DHCPv6. O cliente DHCPv6 tenta a configuração baseada em DHCPv6, dependendo dos valores dos sinalizadores M e O nas mensagens de anúncio de roteador recebidas. Portanto, para usar o DHCPv6, é necessário configurar os servidores e agentes de retransmissão DHCPv6 para atender a cada sub-rede IPv6 e, em seguida, configurar seus roteadores IPv6 para definir esses dois sinalizadores com os valores apropriados. Se houver vários roteadores de anúncio para uma determinada sub-rede, eles devem ser configurados para anunciar os mesmos prefixos de endereços sem monitoração de estado e valores dos sinalizadores M e O. Os hosts IPv6 que executam o Windows® XP ou o Windows Server 2003 não incluem um cliente DHCPv6 e, portanto, ignoram os valores dos sinalizadores M e O nos anúncios de roteador recebidos.
Você pode configurar um roteador IPv6 executado no Windows Vista ou no Windows Server "Longhorn" para definir o sinalizador M como 1 em anúncios de roteador com o comando "netsh interface ipv6 set interface InterfaceName managedaddress=enabled". De maneira semelhante, é possível definir o sinalizador O como 1 em anúncios de roteador com o comando "netsh interface ipv6 set interface InterfaceName otherstateful=enabled".
A versão Beta 2 do Windows Server "Longhorn" dá suporte ao agente de retransmissão DHCPv6 e à configuração sem monitoração de estado DHCPv6 com o serviço do servidor DHCP. Você pode configurar o serviço do servidor DHCP para que as opções DHCPv6 sejam distribuídas a todos os clientes DHCPv6 na troca de mensagens DHCPv6 de duas mensagens descrita anteriormente. A Microsoft planeja incluir o suporte à operação com monitoração de estado do DHCPv6, incluindo a capacidade de criar escopos de endereços IPv6 no snap-in do DHCP, na versão Beta 3 do Windows Server "Longhorn".
Recurso RFC do DHCPv6
RFCs selecionados relacionados ao DHCPv6:
  • RFC 3315 DHCPv6 (Dynamic Host Configuration Protocol for IPv6)
  • RFC 2462 Configuração automática de endereço sem monitoração de estado IPv6
  • RFC 3633 Opções de prefixo IPv6 para o DHCP versão 6
  • RFC 3646 Opções de configuração DNS para DHCPv6
  • RFC 3736 Serviço DHCP sem monitoração de estado para IPv6

Joseph Davies é redator técnico da Microsoft, ensina e escreve sobre assuntos relacionados a sistemas de rede do Windows desde 1992. Ele tem cinco livros publicados pela Microsoft Press e é autor da coluna online mensal da TechNet, The Cable Guy.


 Windows Powershell: A efici&#234;ncia das vari&#225;veis
Windows Powershell
A eficiência das variáveis
Don Jones

Se você trabalha com uma linguagem de script com base em Windows, como o VBScript ou o KiXtart, já está acostumado em tratar variáveis como nada mais do que um tipo de mecanismo de armazenamento para dados. O Windows PowerShell também tem variáveis, mas elas são muito mais eficientes do que as variáveis em linguagens de scripts mais antigas. Na verdade, as variáveis do Windows
PowerShell são mapeadas para classes subjacentes no Microsoft® .NET Framework. E, no Framework, variáveis são objetos, o que envolve a sua capacidade de armazenar dados e também de manipular esses dados de várias maneiras. De fato, os sólidos recursos de variáveis no Windows PowerShell™ são o motivo pelo qual a linguagem de script do Windows PowerShell não contém funções intrínsecas de manipulação de dados. Essas funções não são necessárias, uma vez que as próprias variáveis já oferecem a funcionalidade.

Declarando variáveis
Embora o cmdlet New-Variable no Windows PowerShell permita a declaração de uma variável e a atribuição de um valor inicial a ela, não é necessário usar cmdlet. Em vez disso, você pode criar uma nova variável de forma dinâmica, simplesmente atribuindo um valor a ela:
$var = "Hello"

No Windows PowerShell, os nomes de variáveis sempre começam com um sinal de cifrão ($) e podem conter uma combinação de letras, números, símbolos ou até mesmo espaços (apenas de que, se você usar espaços, será necessário delimitar a variável entre chaves, como ${Minha variável} = "Olá"). Esse exemplo criou uma nova variável denominada $var e atribuiu a ela o valor inicial "Olá". Como, nesse caso, o valor é uma seqüência de caracteres, o Windows PowerShell usará o tipo de dados Seqüência de caracteres para armazenar o valor. No que diz respeito ao .NET Framework, essa é a classe System.String, que talvez tenha a funcionalidade mais integrada de qualquer tipo de variável. Digamos que, se quiser ver uma versão totalmente em minúsculas do valor em $var, eu possa fazer o seguinte:
PS C:\> $var.ToLower()
hello
PS C:\>
O método ToLower é integrado à classe System.String e gera uma representação totalmente em minúsculas do valor da seqüência de caracteres. Porém, ele não altera o conteúdo real da variável $var. Para ver uma lista completa de tudo o que a classe System.String é capaz de fazer, conduza uma variável de seqüência de caracteres para o cmdlet Get-Member, como a seguir:
$var | get-member
A Figura 1 mostra a saída, que inclui algumas dezenas de métodos usados para a manipulação de seqüências de caracteres. Quase toda a funcionalidade fornecida pelas funções de manipulação de seqüências de caracteres de VBScript é determinada em vez disso por métodos da variável de seqüência de caracteres no Windows PowerShell.
Figure 1 A look at the System.String class output
Figure 1 A look at the System.String class output (Clique na imagem para diminuir a exibição)
Figure 1 A look at the System.String class output
Figure 1 A look at the System.String class output (Clique na imagem para aumentar a exibição)

Muitos dos recursos da variável de seqüência de caracteres são mais úteis em um contexto administrativo do que as funções de seqüência de caracteres em uma linguagem como VBScript. Suponha que você tenha gravado um script que realize leituras em caminhos UNC (Universal Naming Convention) a partir de um arquivo e que faça algo com esses caminhos. Você deseja verificar se cada caminho lido está em um UNC antes de tentar usar um determinado caminho. O método StartsWith permite confirmar se o valor de uma string começa com os caracteres de barra invertida necessários para um UNC:
PS C:\> $path = "\\Server\Share"
PS C:\> $path.StartsWith("\\")
True
PS C:\>
Como StartsWith retorna um valor True ou False, é possível usá-lo em construções lógicas:
if ($path.StartsWith("\\")) {
 # code goes here
}
O Windows PowerShell fornece até mesmo uma forma de auto-preenchimento para métodos de variáveis, reduzindo a quantidade de digitação necessária. Se $var contiver uma string, você poderá digitar
$var.
e depois pressionar Tab, o que ativa o primeiro nome de método da variável $var. Pressionar Tab novamente faz com que o método seguinte seja acessado, enquanto pressionar Shift+Tab ativa o método anterior. Dessa forma, você pode percorrer todos os métodos de variáveis até encontrar o desejado.

Confusão de variáveis
Até agora, meus exemplos permitiram que o Windows PowerShell determinasse o tipo de dados das minhas variáveis. A atribuição de uma seqüência de caracteres a uma variável força essencialmente essa variável para que ela seja da classe System.String. Por outro lado, a atribuição de um número a uma variável geralmente faz com que a variável se torne um Inteiro (ou, mais especificamente, um Int32, que pode armazenar um intervalo específico de valores). Por exemplo, considere o seguinte:
PS C:\> $int = 5
PS C:\> $int | get-member

  TypeName: System.Int32
Essa saída truncada mostra que o Windows PowerShell está tratando $int como Int32, que possui o seu próprio conjunto de métodos e propriedades. E, de fato, seu conjunto de métodos e propriedades é muito menor do que o do tipo Seqüência de caracteres.
$int se tornou Int32 porque o valor não estava delimitado por aspas e porque era composto unicamente por dígitos. Se estivesse entre aspas, teria sido interpretado como System.String.
Permitir que o Windows PowerShell decida que tipo de dados deve ser usado nem sempre gera os resultados desejados. Suponha que você esteja lendo valores a partir de um arquivo e sempre queira que esses valores sejam tratados como seqüências de caracteres. Entretanto, alguns dos valores podem conter apenas dígitos, levantando a possibilidade de o Windows PowerShell tratá-los como Int32 ou outro valor numérico. Isso pode causar problemas para o script. Se o Windows PowerShell não reconhecer o valor como seqüência de caracteres, nenhum dos métodos da classe System.String estará disponível (e o seu script pode depender de um desses métodos não disponíveis).
Para solucionar o problema, você pode forçar o Windows PowerShell a tratar uma variável como um certo tipo, declarando esse tipo ao usar essa variável pela primeira vez. Por exemplo:
[string]$var = 5
Normalmente, $var teria sido Int32, mas, neste caso, forcei o Windows PowerShell a tornar $var uma Seqüência de caracteres, garantindo a possibilidade de usar todos os métodos associados à classe System.String. A declaração de tipo de variável também fornece um tipo prático de auto-documentação para o código, já que agora está óbvio qual é o tipo de dados que se espera inserir em $var. De fato, adotei o hábito de sempre declarar um tipo específico para todas as minhas variáveis, afastando a decisão totalmente do Windows PowerShell. Isso torna o comportamento dos meus scripts mais previsível e, em vários casos, poupou um considerável tempo de depuração.
Como é de se esperar, a declaração forçada de variáveis tem as suas repercussões, embora não sejam necessariamente más. Considere esse exemplo, que não declara o tipo da variável:
PS C:\> $me = 5
PS C:\> $me = "Don"
A variável $me era inicialmente Int32, mas o Windows PowerShell a alterou para uma Seqüência de caracteres quando o valor "Don" foi adicionado. O Windows PowerShell pode alterar o tipo de uma variável conforme necessário, desde que a variável ainda não tenha sido explicitamente definida como um tipo específico.
Nesse exemplo, forcei $me para ser um Int32 usando o nome do tipo [int]:
PS C:\> [int]$me = 5
PS C:\> $me = "Don"
Cannot convert value "Don" to type
"System.Int32". Error: "Input string
was not in a correct format."
At line:1 char:4
+ $me <<<< = "Don"
Depois, quando tentei atribuir um valor de seqüência de caracteres a ele, uma mensagem de erro foi exibida. Como forcei explicitamente $me para que ele fosse Int32, o Windows PowerShell esperava converter a seqüência de caracteres "Don" em um valor inteiro. Ele não pode fazer isso ou não conseguiu alterar o tipo de $me para Seqüência de caracteres.

Tantos tipos
Existem muitos tipos disponíveis no Windows PowerShell. De fato, é possível usar qualquer tipo do .NET Framework (e o número de tipos disponíveis às centenas). Entretanto, o Windows PowerShell define vários atalhos para tipos comuns de dados. A Figura 2 é apenas uma lista parcial, mostrando 10 dos atalhos de tipos mais comumente utilizados. Para obter uma lista completa, consulte a documentação do Windows PowerShell.
Figure 2 Atalhos de tipos comuns (Close Figure 2)

Atalho | Tipo de dados
[datetime] | Data ou hora
[string] | Seqüência de caracteres
[char] | Caractere simples
[double] | Número flutuante de precisão dupla
[single] | Número flutuante de precisão única
[int] | Inteiro de 32 bits
[wmi] | Instância ou coleção do WMI
[adsi] | Objeto de serviços do Active Directory
[wmiclass] | Classe do WMI
[Boolean] | Valor True ou False
Você também pode declarar o tipo de uma variável usando o nome completo da classe do .NET Framework, por exemplo:
[System.Int32]$int = 5
Essa técnica permite usar tipos que estão no .NET Framework, mas que não têm um atalho específico no Windows PowerShell.

Estendendo tipos
Talvez o mais interessante sobre o Windows PowerShell seja a sua capacidade de estender os recursos desses tipos de variáveis. Na pasta de instalação do Windows PowerShell (normalmente em %systemroot\system32\windowspowershell\v1.0, embora você venha a perceber que o caminho é um pouco diferente em sistemas de 64 bits), haverá um arquivo denominado types.ps1xml. É possível editar esse arquivo no Bloco de Notas ou em um editor XML, como o PrimalScript. Por padrão, a classe System.String não está listada, embora muitos outros tipos estejam. Entretanto, posso adicionar um novo recurso ao tipo System.String adicionando isso ao arquivo types.ps1xml.
Depois de fazer a alteração, preciso fechar e reabrir o Windows PowerShell. Também preciso ter certeza de que a diretiva de execução de scripts locais permita a execução de scripts não assinados, já que eu não assinei types.ps1xml:
Set-executionpolicy remotesigned
Agora, depois de reiniciar Windows PowerShell, posso usar a nova funcionalidade, dessa maneira:
PS C:\> [string]$comp = "localhost"
PS C:\> $comp.canping
True
PS C:\>
Como é possível perceber, adicionei uma propriedade CanPing à classe System.String. Isso retorna True ou False para indicar se o computador local é capaz de executar ping do endereço contido na seqüência de caracteres. Na Figura 3, você perceberá que a consulta do WMI utiliza uma variável especial, $this. A variável $this representa o valor atual contido na seqüência de caracteres e representa a forma como o conteúdo da seqüência de caracteres é transmitido em uma consulta do WMI.
Figure 3 Estender o tipo System.String (Close Figure 3)
<Type>
  <Name>System.String</Name>
  <Members>
    <ScriptProperty>
      <Name>CanPing</Name>
      <GetScriptBlock>
      $wmi = get-wmiobject -query "SELECT *
FROM Win32_PingStatus WHERE Address = '$this'"
      if ($wmi.StatusCode -eq 0) {
        $true
      } else {
        $false
      }
      </GetScriptBlock>
    </ScriptProperty>
  </Members>
</Type>

Deixe que uma variável faça o trabalho
O Windows PowerShell fornece tipos de variáveis flexíveis e cheios de recursos, além de um sistema igualmente flexível para estender a funcionalidade de tipos. Esses recursos tornam muito fácil a integração de muita eficiência aos seus scripts. De fato, as variáveis podem se tornar um elemento principal em scripts complexos, em muitos casos utilizando os recursos avançados normalmente encontrados em uma função mais complexa.
Aprenda mais online
Participe dessa série de Webcasts que ocorrerá na segunda terça-feira de cada mês, quando continuaremos a discutir a elaborada funcionalidade de scripts fornecida pelo Windows PowerShell. Visite o endereço microsoft.com/events/series/donjonesscripting.mspx para inscrever-se hoje mesmo.

20 de fevereiro de 2007 - Windows PowerShell: O curso rápido de scripts
Participe deste Webcast para aprender sobre variáveis, construções de linguagens, scripts e funções no Windows PowerShell. Nesse curso rápido de uma hora, demonstraremos como a linguagem de script simples, mas eficaz, no Windows PowerShell torna mais rápida a automação administrativa do Windows®. Também exploraremos várias ferramentas de terceiros que tornam os scripts do Windows PowerShell os mais simples possíveis.

20 de março de 2007 - Windows PowerShell: funções, filtros e eficácia
Aprenda a criar um código eficaz e modularizado nas funções e nos filtros do Windows PowerShell. Exploraremos as sólidas regras de criação de escopo no Windows PowerShell que permitem escapsular totalmente funções e filtros e que explicam como é possível reutilizar facilmente essas funções e esses filtros em projetos. Também demonstraremos como é possível adicionar as suas próprias funções personalizadas ao escopo global do Windows PowerShell, o que facilita a montagem nas pontas dos dedos de uma biblioteca de úteis funções de utilitários.

17 de abril de 2007 - Windows PowerShell e Windows Management Instrumentation
O Windows PowerShell pode acessar toda a eficiência e todos os recursos do WMI (Windows Management Instrumentation). Descreveremos não só como usar o Windows PowerShell para acessar o WMI, mas também como transmitir objetos e coleções do WMI por meio do pipeline do Windows PowerShell. Exploraremos como utilizar as propriedades e os métodos do WMI nos scripts do Windows PowerShell e ilustraremos os recursos de segurança e de configuração subjacentes no WMI.

22 de maio de 2007 - Windows PowerShell: convertendo a partir do VBScript
Deseja converter scripts, ou até mesmo as suas habilidades, do VBScript para o Windows PowerShell? Participe deste Webcast para aprender como. Exploraremos como o Windows PowerShell inclui todas as principais construções e recursos do VBScript, facilitando a conversão de habilidades do VBScript para esse novo ambiente administrativo. Ilustraremos como converter ferramentas no VBScript para a linguagem de script nativa no Windows PowerShell. Também examinaremos a estrutura exclusiva no Windows PowerShell e mostraremos como começar a usar a linguagem de script do Windows PowerShell para que os seus esforços se tornem ainda mais eficientes e eficazes.

19 de junho de 2007 - Windows PowerShell: Extensões subjacentes
Nesse Webcast, exploraremos como o Windows PowerShell utiliza o eficiente e flexível .NET Framework para controlar dados, fornecendo centenas de funções integradas para gerenciar seqüências de caracteres, datas e outros tipos de dados. Mas, você sabia que é possível estender essas funções usando scripts do Windows PowerShell? Mostraremos como criar variáveis de seqüências de caracteres que contêm não apenas um nome de computador, mas que também informam se esse computador está ativo e em execução. Aprenda a criar variáveis de data e hora que podem formatar seus dados automaticamente sem o uso de funções externas. Participe dessa sessão para aprender a criar todos os tipos de novas funcionalidades no Windows PowerShell em questão de minutos, tornando a administração do Windows mais rápida e mais fácil.

Don Jones é diretor de projetos e serviços da SAPIEN Technologies e co-autor do Windows PowerShell: TFM (SAPIEN Press). Entre em contato com Don no endereço www.ScriptingAnswers.com.


 Ei, Equipe de Scripts!: Respondendo a suas perguntas sobre UOs... por apenas 5 centavos
Ei, Equipe de Scripts!
Respondendo a suas perguntas sobre UOs... por apenas 5 centavos
A Equipe de Scripts da Microsoft
Faça download do código deste artigo: HeyScriptingGuy2007_03.exe (151KB)

P: Como posso exibir uma caixa de diálogo que permite selecionar um UO do Active Directory?

VOCÊ SABE, se nós da Equipe de Scripts ganhássemos um centavo toda vez que respondêssemos essa pergunta, teríamos, na verdade, apenas US$ 37,15, não é? É verdade, mas se ganhássemos um centavo por cada pessoa que quisesse fazer essa pergunta, mas que nunca chegou a perguntar, teríamos... bem, o valor não importa. Além do mais, não nos tornamos membros da Equipe de Scripts por dinheiro. Fazemos parte da Equipe de Scripts pela satisfação de ajudar as pessoas a realizar suas tarefas de administração do sistema de forma mais rápida e fácil.
Observação. Na verdade, tecnicamente nos tornamos membros da Equipe de Scripts por dinheiro. Mas nossos gerentes dizem: “Falando francamente, é possível que vocês ganhem muito dinheiro, mas apenas se estiverem dispostos a trabalhar muito e gerar resultados de alta qualidade.” Foi aí que decidimos que dinheiro não era tudo na vida.
Não importa. A questão é: muitas pessoas gostariam de saber como exibir uma caixa de diálogo que permitisse selecionar um UO e, desse modo, conectar-se a esse UO usando um script. “Vocês mostraram como exibir uma caixa de diálogo que permite escolher pastas”, diz um email recente, “e também mostraram como exibir uma caixa de diálogo que permite escolher arquivos. Por que vocês nunca mostraram como exibir uma caixa de diálogo que permite selecionar um OU do Active Directory®?"
Bem, para começar, nós realmente mostramos como exibir uma caixa de diálogo que permite selecionar uma pasta e você pode encontrar um exemplo disso aqui. Também mostramos a todos como exibir uma caixa de diálogo que permite selecionar arquivos; confira em microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx se não acreditar em nós. Esses artigos foram bem recebidos e sabemos que as pessoas estão empregando essas técnicas nos scripts. Então por que nunca mostramos às pessoas como exibir uma caixa de diálogo que permite selecionar OUs do Active Directory? É algum tipo de conspiração da Microsoft ou algo parecido?
Claro que não. (Opa... espera um minuto... é exatamente o que alguém envolvido em uma conspiração diria, não é?) A verdade é que existe um bom motivo para não termos mostrado como exibir uma caixa de diálogo que permite selecionar UOs do Active Directory: essa caixa de diálogo simplesmente não existe. Como dizem no beisebol, você não pode rebater no que não pode ver. E como dizemos na área de scripts, você não pode exibir o que não existe.
Isso é tudo para a coluna desse mês. Vejo vocês no mês que vem.
Não é bem assim. Segundo os editores da TechNet Magazine, isso não é tudo para esse mês. “E se uma caixa de diálogo como essa não existe?”, eles dizem. “Meu Deus, vocês fazem parte da Equipe de Scripts. Vocês não podem criar uma caixa de diálogo para resolver esse problema? Achamos que vocês podem fazer tudo que diz respeito aos scripts”.
Nem preciso dizer que os editores da TechNet Magazine estão profundamente enganados. Fazer tudo relacionado aos scripts? Não exatamente. Na verdade, nós da Equipe de Scripts sabemos como fazer apenas uma coisa relacionada aos scripts.
Felizmente, sabemos criar uma caixa de diálogo que permite selecionar um UO do Active Directory. Observe a Figura 1.
É um tipo de script longo, não é? Mas você conhece o nosso lema: você não pode fazer um omelete sem quebrar os ovos. Do mesmo modo, não é possível criar uma caixa de diálogo personalizada sem quebrar alguns ovos (ficamos com fome no meio dessa coluna e fomos fazer um lanche). Agora que estamos satisfeitos, veremos se conseguimos explicar como isso funciona.
O que estamos fazendo com o script é usar o modelo de objeto do Internet Explorer® para criar uma pseudocaixa de diálogo. Vamos criar uma instância do Internet Explorer, pegar uma coleção de UOs do Active Directory e, em seguida, exibir esses UOs em uma caixa de listagem em uma janela do Internet Explorer. Aguardamos até o usuário selecionar um UO, pegamos o ADsPath do item selecionado, fechamos a “caixa de diálogo” e partimos desse ponto.
Observação: esta será a caixa de diálogo mais estranha e interessante já criada? Sim se por “estranha e interessante” você estiver se referindo à estrutura da caixa que não tem nem mesmo um botão OK ou Cancelar. Mas, para nos defender, a idéia é simplesmente dar a estrutura básica. Se desejar personalizar ou modificar a caixa de diálogo, terá que fazer isso sozinho.
(Meu Deus, se recebêssemos um centavo cada vez que disséssemos “Desculpe, você terá que fazer isso sozinho” realmente estaríamos ricos. Envie suas doações para a Equipe de Scripts, CC: TechNet Magazine.)
Para que a explicação de nossa técnica caiba no espaço designado para nós, teremos que pular algumas etapas. Por exemplo, tudo que vamos mencionar sobre o seguinte bloco de código é que ele cria uma instância do Internet Explorer que tem 350 pixels por 400 pixels e, assim, oculta coisas como a barra de endereço e a barra de status:
Set objExplorer = CreateObject( _
    "InternetExplorer.Application")

objExplorer.Navigate "about:blank"
objExplorer.ToolBar = 0
objExplorer.StatusBar = 0
objExplorer.Width= 350
objExplorer.Height = 400
objExplorer.Left = 400
objExplorer.Top = 400
objExplorer.Visible = 1
Obviamente, tudo isso nos dá uma janela do Internet Explorer em branco. Para obter a lista de UOs em nosso domínio, precisamos fazer uma pesquisa no Active Directory. Não podemos explicar os detalhes da pesquisa do Active Directory hoje; para obter mais informações sobre isso, consulte nossa série de duas partes no Script Center em microsoft.com/technet/scriptcenter/resources/tales/sg0405.mspx. O que podemos fazer é dizer que este é o código usado para recuperar o Nome e o ADsPath de cada UO do domínio fabrikam.com:
objCommand.CommandText = _
    "SELECT Name, ADsPath FROM 'LDAP://DC=fabrikam,DC=com' WHERE objectCategory=
    'organizationalUnit' ORDER BY Name"
Ah, e só para facilitar as coisas, também classificamos os UOs em ordem alfabética por nome. A cláusula ORDER BY Name tem essa finalidade. (Sem problemas; afinal, estamos aqui para servi-lo.)
Quando chamamos o método Execute, voltamos a um conjunto de registros que consiste em todos os UOs encontrados no fabrikam.com. Desse modo, nossa próxima etapa é exibir cada UO em uma caixa de listagem.
Então, como fazemos isso? Primeiro, precisamos construir a caixa de listagem inteira na memória. Para os iniciantes, isso significa usar essa linha de código para armazenar a marca <SELECT> em uma variável chamada strHTML:
strHTML = "<select size = '20' name='OUList' style='width:300px'>"
O que estamos fazendo com essa linha de código? Bem, simplesmente estamos construindo uma caixa de listagem HTML padrão (o que é possível fazer usando a marca <SELECT>). No meio do caminho, damos à caixa de listagem o nome OUList e a configuramos para exibir 20 itens por vez e ter 300 pixels (300px). Se você conhecer um pouco de HTML, o código anterior será familiar.
Em seguida, temos que adicionar alguns itens (ou seja, alguns UOs) à caixa de listagem. Por uma coincidência surpreendente, nosso conjunto de registros é constituído pelas informações sobre cada UO de nosso domínio. Desse modo, podemos configurar um loop Do Until que percorre o conjunto de registros inteiro, capta as informações e adiciona cada UO à caixa de listagem. Dentro do loop, usamos o seguinte código (novamente, HTML padrão para adicionar itens à uma caixa de listagem) para adicionar cada UO, configurando o item para que o nome do UO seja exibido na lista e, caso você clique no UO na caixa de listagem, o ADsPath é transferido para o script:
strHTML = strHTML & "<option value= " & _
    Chr(34) & objRecordSet.Fields
    ("AdsPath").Value & Chr(34)
strHTML = strHTML & ">" & objRecordSet.
    Fields("Name").Value
Por que transferir o ADsPath para o script? É fácil. Imagine que, em vez disso, tivéssemos transferido o nome do UO. Se o nome for, por exemplo, Finance, será difícil vinculá-lo ao UO; além disso, “Finance” não é uma cadeia de vinculação ADSI válida propriamente dita. No entanto, se voltarmos ao ADsPath (LDAP://ou=Finance,dc=fabrikam,dc=com), a vinculação é moleza. Isso porque o ADsPath é exatamente do que precisamos para localizar e estabelecer a conexão com um objeto do Active Directory.
A propósito, estamos exibindo o Nome na caixa de listagem porque supomos que seus UOs têm nomes exclusivos. Talvez isso não aconteça; por exemplo, os UOs North America\Research e Europe\Research têm o mesmo nome (Research). Se os UOs tiverem nomes duplicados, use um property-say, ADsPath ou distinguishedName-in na caixa de listagem. Isso você deve decidir sozinho. (Uau! Mais um centavo!)
Por falar nisso, observe que ainda estamos construindo a caixa de listagem da memória: cada item adicionado à caixa está sendo adicionado à variável strHTML. Tudo isso faz parte do plano: salvamos o código inteiro da caixa de listagem na variável strHTML e, em seguida, usamos o valor dessa variável para adicionar realmente a caixa de listagem à nossa instância do Internet Explorer.
Após todos os UOs terem sido adicionados, usamos essa linha de código para significar o final da caixa de listagem:
strHTML = strHTML & "</select>"
Nesse momento, strHTML contém todas as marcas HTML necessárias para criar uma caixa de listagem e, o melhor de tudo, uma caixa na qual cada item representa um UO do Active Directory. Isso significa que agora podemos atribuir o valor de strHTML à propriedade InnerHTML de nosso documento do Internet Explorer:
objExplorer.Document.Body.InnerHTML = strHTML
Por sua vez, isso nos dá uma caixa de listagem que exibe todos os UOs de um domínio.
Calma, não vá embora; ainda não terminamos. Por exemplo, ainda precisamos de algum código que permita pausar o script até o usuário selecionar um UO na caixa de diálogo; sem esse código, a caixa de listagem seria exibida, mas o script continuaria em execução, independentemente da seleção do usuário. Credo! Para manter esse cenário, usamos o seguinte bloco de código:
Do While objExplorer.Document.Body.All.OUList.Value = ""
    Wscript.Sleep 300
Loop
O que estamos fazendo aqui é verificar repetidamente o valor de nossa caixa de listagem (o qual, como você talvez se lembre, chamamos de OUList, o mesmo nome que um dos rapazes da Equipe de Scripts deu para sua filha). Se o valor for uma cadeia vazia (indicando que nenhum item foi selecionado), simplesmente pausamos o script por 300 milissegundos, pesquisamos e verificamos novamente. Esse processo continua: a) sempre; b) até o usuário selecionar um item na caixa de listagem; ou c) até o usuário fechar a janela do Internet Explorer.
Suponha que o usuário não selecione um UO na caixa de listagem. Nesse caso, pegamos o valor (que é o ADsPath do UO) e o atribuímos a uma variável chamada strTargetOU:
strTargetOU = objExplorer.Document.Body.All.OUList.Value
Em seguida, usamos o método Quit para ignorar a instância do Internet Explorer conforme mostrado abaixo:
objExplorer.Quit
Nessa etapa, estamos quase terminando. Primeiro, verificamos se strTargetOU é igual a uma cadeia vazia:
If strTargetOU = "" Then
    Wscript.Quit
End If
Em caso afirmativo, o usuário terá fechado o Internet Explorer sem selecionar um UO; nós, por sua vez, usamos o método Wscript.Quit para encerrar o script. (Estamos imaginando que caso o usuário não tenha selecionado um UO, ele não está realmente interessado em executar o script.) No entanto, se strTargetOU não for igual a uma cadeia vazia, repetimos o valor da variável:
Wscript.Echo strTargetOU
Obviamente, em um script real, você provavelmente continuaria e se vincularia ao UO do Active Directory em vez de simplesmente repetir o ADsPath. Mas, você sabe o que eles dizem, ou pelo menos o que nós dizemos: você terá que fazer isso sozinho.
Como já mencionamos, e você pode observar na Figura 2, não é a caixa de diálogo mais estranha já criada, mas funciona e é mais fácil do que inserir um ADsPath (supondo que você mal conhece o ADsPath). Além disso, você tem a oportunidade de personalizar o código, e a caixa de diálogo, para satisfazer suas necessidades.
Figure 2 A simple script dialog
Figure 2 A simple script dialog

Se ganhássemos um centavo para cada coluna que já escrevemos sobre como exibir uma caixa de diálogo que permite selecionar um UO do Active Directory... Ganharíamos 5 centavos a mais do que a TechNet Magazine normalmente paga.
Não estamos reclamando de jeito nenhum.

A Equipe de Scripts da Microsoft trabalha para (na verdade, está empregada pela) Microsoft. Quando não está jogando/treinando/assistindo beisebol (e diversas outras atividades), ela administra o TechNet Script Center. Confirme isso em www.scriptingguys.com.


 Perguntas e respostas do Exchange: Logs de transa&#231;&#245;es, Cmdlets, gerenciamento remoto e muito mais
Perguntas e respostas do Exchange
Logs de transações, Cmdlets, gerenciamento remoto e muito mais
KC Lemson and Nino Bilic

P: Por que a equipe diminuiu o tamanho do log de transação para 1 MB no Microsoft® Exchange Server 2007?
R: Bem, no Exchange 2007 temos esse ótimo recurso chamado envio de log, que é a tecnologia por trás de vários recursos novos chamados LCR (Replicação contínua local) e CCR (Replicação contínua em cluster). Quando esse recurso está ativado em um nível SG (Grupo de armazenamento), os logs de transação SG são copiados do SG de produção em execução para o SG de cópia. Os logs do SG de cópia são reproduzidos no banco de dados para atualizá-lo. Isso obviamente é uma explicação simplificada do que ocorre, mas dá uma idéia geral.
O problema é que os logs de transação não podem ser enviados para o SG de cópia a não ser que log esteja fechado no SG de produção. Em outras palavras, o log e00 (log atual no primeiro grupo de armazenamento) não pode ser enviado até ser concluído, fechado e renomeado. Além disso, há configurações que controlam quantos logs podem estar por trás desse processo visto que existe uma transação entre disponibilidade e desempenho. (Essas configurações estão disponíveis ao executar o cmdlet Set-MailboxServer no Shell de gerenciamento do Exchange. O arquivo de ajuda fornece detalhes sobre os parâmetros exatos necessários.)
Para encurtar a história, diminuímos o tamanho do log de transação para minimizar a quantidade de dados que pode estar fora de sincronização entre duas cópias do Grupo de armazenamento. Isso acontece, podemos dizer, quando a unidade de disco rígido do banco de dados de produção falha e é necessário tomar alguma ação para iniciar o SG a partir da cópia. Logs de transações menores permitem uma menor perda de dados.
No entanto, não podemos garantir que você perderá apenas 1 MB de dados. Como se tratam de logs de transação, é possível que o arquivo de log de 1 MB perdido contenha, por exemplo, uma transação COMMIT para 5 MB de dados. Nesse caso, você estaria perdendo esses 5 MB de dados na cópia (embora talvez tenha recebido cinco logs com os dados propriamente ditos, o último log com um pequeno bit de dados e a transação COMMIT necessária são fundamentais).
Por fim, você deve avaliar se este é um risco aceitável para suas necessidades de negócios. Uma pequena perda de dados com o tempo de recuperação de apenas alguns minutos pode ser perfeitamente aceitável em comparação à horas do trabalho de restauração. Esse assunto certamente será abrangido em mais detalhes em outras edições!

P: Agora que os logs de transação estão menores, poderemos “executá-los” mais rápido?
R: Em se tratando do Exchange, “executar” refere-se aos nomes dos logs de transação. No Exchange Server 2003, nos logs de transação são nomeados da seguinte maneira:
E nn fffff.log
O nn é o prefixo que varia de acordo com o SG. Como nn será o mesmo durante toda a vida do SG, o número de logs de transação com nomes exclusivos que podem ser criados para o grupo de armazenamento é basicamente o valor “fffff”, que é aproximadamente um milhão de logs (nota: coloque cor de rosa no canto da boca e gargalhe como louco). Alguns de nossos clientes têm executado até esse limite em servidores de email ocupados.
A partir do Exchange Server 2000, fornecemos um hotfix para exibir um evento no log de aplicativo quando esse limite for atingido. (Acesse support.microsoft.com/kb/896001 para obter mais informações.)
Bem, com esse problema a menos, o que acontece no Exchange 2007? Acabamos de dizer que os logs de transação de 5 MB (o tamanho nas versões anteriores do Exchange) foram reduzidos para 1 MB (o tamanho no Exchange 2007). Isso significa que apenas um quinto dos dados podem ser executados com nomes exclusivos de log de transação?
A resposta é não. No Exchange 2007, o nome dos logs de transação está no seguinte formato:
E nn ffffffff.log
Observe que podemos trabalhar com logs “ffffffff” em comparação a apenas “fffff” nas versões anteriores do Exchange. Devido à matemática interna do ESSE (Mecanismo de armazenamento extensível), o Exchange 2007 não pode criar todos os logs “ffffffff”. Em vez disso, são criados logs “7fffffec”, que ainda é um número muito grande (se não acreditar, converta esse valor de hexadecimal em decimal).
O que isso significa em termos práticos? Em termos práticos, isso quer dizer que com o Exchange 2007 você pode criar aproximadamente 2048 vezes mais logs do que nas versões anteriores do Exchange. Vamos considerar logs com um quinto do tamanho:
2048 / 5 = 409.6
Como você pode ver, o novo esquema de nomeação de logs pode manipular 409 vezes mais dados do que o antigo! E lembre-se que isso é por SG, não por servidor, visto que cada grupo de armazenamento terá um prefixo de arquivo de log diferente (como e00, e01 e assim por diante). Já dissemos que é possível criar 50 SGs por servidor na versão Enterprise do Exchange 2007? Não acreditamos que alguém executará mais logs de transação em breve!

P: Como posso gerenciar meus servidores Exchange 2007 remotamente?
R: Existem algumas opções para gerenciar os servidores Exchange 2007 remotamente. Primeiramente, é possível instalar as ferramentas de gerenciamento do Exchange 2007 em um computador separado do servidor Exchange, contanto que o computador esteja executando a versão de 32 bits ou de 64 bits do Windows Server® 2003 Service Pack 1 (SP1) ou posterior, o Windows Server 2003 R2 ou o Windows XP SP2 ou posterior. Observe que a instalação de qualquer função do servidor (acesso do cliente, caixa de correio, margem e assim por diante) no hardware de 32 bits não é suportada nos ambientes de produção, mas é suportada para a instalação das ferramentas de gerenciamento em um computador de 32 bits. Observe também que por ser a versão inicial do Exchange Server 2007, as ferramentas de gerenciamento não são suportadas no Windows Vista™.
Em algumas organizações, o departamento de TI cria um único servidor para ser o servidor de gerenciamento, instalando todas as ferramentas necessárias para vários produtos nesse servidor. Em seguida, os administradores que precisam usar essas ferramentas acessam o servidor de gerenciamento através do servidor terminal para realizarem a administração remota. Em outras configurações, os usuários instalam as ferramentas de gerenciamento em suas próprias áreas de trabalho.
Do console ou do shell, é possível realizar operações nos servidores de sua organização. No console, os servidores são visíveis para que seja possível realizar operações em qualquer um de forma remota. No shell, muitas tarefas suportam um sinalizador de filtragem como -server se desejar abranger uma operação em um único servidor. No entanto, existem algumas exceções para os comandos que devem ser executados localmente, como o comando Get-NetworkConnectionInfo.

P: Em sua última coluna, você disse quanto de RAM é recomendado para um servidor Exchange 2007. Que dizer sobre o tamanho do arquivo da página?
R: Para evitar possíveis erros fora da memória virtual nos servidores Exchange 2007, recomendamos as seguintes diretrizes para determinar o tamanho do arquivo da página do seu sistema.
Se o servidor tiver menos de 8 GB de RAM, o tamanho mínimo do arquivo da página deve ser o valor da RAM mais 10 MB. Assim, se o servidor tem 4 GB de RAM, o tamanho mínimo seria 4 GB mais 10 MB. No entanto, o tamanho recomendado de arquivo da página é o valor da RAM multiplicado por 1,5. Portanto, para o servidor de 4 GB, o ideal seria 6 GB.
Além disso, o tamanho mínimo do arquivo da página é calculado da mesma maneira para um servidor com mais de 8 GB de RAM, isto é, o valor da RAM mais 10 MB. No entanto, o tamanho recomendado é recomendado de modo diferente. Basicamente, em um servidor com mais de 8 GB de RAM, você deve multiplicar apenas 1,5 vez o valor da RAM caso obtenha erros fora da memória virtual com arquivos de página menores.
Observe que os erros mencionados nesse caso não têm nada a ver com a fragmentação da memória virtual (um problema com os servidores Exchange 2000 e Exchange 2003). Esses são erros instantâneos reais registrados pelo sistema que indicam se o tamanho do arquivo da página está aumentando ou se o arquivo é muito pequeno.

P: Gostaria de saber como usar o Shell de gerenciamento do Exchange, mas nunca usei uma linha de comando para administrar meus sistemas antes. Por onde começo?
R: Primeiro, vamos começar com alguns princípios básicos. Cada cmdlet do Shell de gerenciamento do Exchange é composto por apenas um verbo e um substantivo. Existem apenas alguns verbos úteis usados pelo Shell de gerenciamento do Exchange: “Get” é usado para recuperar propriedades de objetos, “Set” para alterar propriedades de um objeto, “New” para criar novos objetos e assim por diante. Os substantivos do Shell de gerenciamento do Exchange incluem muitos conceitos que todos os administradores do Exchange já conhecem (por exemplo, Mailbox, Contact, Queue e OWAVirtualDirectory). Há também novos conceitos no Exchange Server 2007 (como TransportRule, StorageGroupCopy e UMAutoAttendant). Desse modo, na prática, um cmdlet básico seria parecido com New-Mailbox (para criar uma caixa de correio) ou Get-Mailbox (para recuperar uma lista de caixas de correio da organização).
No entanto, a maioria dos cmdlets precisará de mais especificações sobre o que exatamente você está tentando realizar. Se desejar alterar uma propriedade de uma caixa de correio, por exemplo, deverá especificar a caixa de correio e a propriedade. Isso é feito com parâmetros. Se New-Sandwich fosse um cmdlet, os parâmetros poderiam ser -NumberOfTomatoSlices 4, -Bread Wheat e uma variedade de outras opções similares que especificam em mais detalhes a forma do sanduíche (-FlufferNutter $true-ahhhh yum).
Após entender a divisão verbo-substantivo, é possível usar a exposição da linha de comando no assistente EMC (Console de gerenciamento do Exchange) para se familiarizar com as operações realizadas por cada cmdlet. No EMC, execute o assistente para criar um novo usuário. No final do assistente, após a conclusão da operação, você verá uma cópia do comando executado pelo assistente no escopo (veja a Figura 1). Pressione Ctrl + C para copiar o conteúdo dessa caixa de diálogo e colar o cmdlet no Bloco de notas e reunir seus próprios arquivos em lote simples.
Figure 1 Command-line exposure for creating a new user
Figure 1 Command-line exposure for creating a new user (Clique na imagem para diminuir a exibição)
Figure 1 Command-line exposure for creating a new user
Figure 1 Command-line exposure for creating a new user (Clique na imagem para aumentar a exibição)
Se desejar praticar usando cmdlets (mas sem causar danos), um belo truque é colocar -WhatIf no final do comando. Ao fazer isso, o sistema informará o que faria executando o comando sem fazer nenhuma alteração real no sistema.
Após se familiarizar com cmdlets básicos como *-Mailbox, você provavelmente tentará alguns outros. Para localizar mais cmdlets, use o cmdlet Get-ExCommand. Uma lista de todos os cmdlets de gerenciamento do Exchange será exibida. (Isso deve ser feito durante a execução do Shell de gerenciamento do Exchange. Basta abrir o Microsoft Command Shell ou o Windows PowerShell™ não permitirá a realização desta tarefa ou de qualquer outra tarefa de gerenciamento do Exchange.) A lista é enorme, portanto, use a correspondência de curingas para encontrar o que está procurando. Por exemplo, Get-ExCommand *database* retornará uma lista de todos os cmdlets do Exchange que têm “database” (banco de dados) no nome, como Dismount-Database, Move-DatabasePath e New-MailboxDatabase.
Se você souber parte do substantivo que está procurando, percorra as opções. Por exemplo, digite Get-Mailbox e pressione a tecla Tab para percorrer todos os cmdlets com mailbox no substantivo do nome da tarefa. É possível inclusive combinar a correspondência de curingas e a conclusão de tabulação. Por exemplo, é possível digitar Get-*Mailbox* e percorrer as opções possíveis.
Outro truque simples é usar prompts. Cada cmdlet tem um conjunto de parâmetros que são necessários por padrão (os parâmetros básicos necessários para realizar a operação). Os cmdlets “Get”, como Get-Mailbox, não precisam de nenhum parâmetro. Por padrão, Get-Mailbox retorna uma lista de todas as caixas de correio da organização inteira. (A lista terá no máximo 1000, por padrão. Para alterar esse máximo, digite Get-Mailbox -ResultSize 2000, por exemplo.) Cmdlets que criam ou modificam objetos (como Set ou New) solicitam as informações necessárias sobre o objeto que deseja criar ou modificar. Se New-Mailbox for executado, por exemplo, o shell solicitará a senha, o banco de dados, o nome, entre outras informações individualmente.
Para saber mais sobre os parâmetros possíveis de um determinado cmdlet, use o sistema de ajuda: Help Move-DatabasePath. (Também é possível digitar apenas Move-DatabasePath, Move-DatabasePath -? e assim por diante; tentamos abranger as bases.) A ajuda fornecerá uma descrição do cmdlet e uma lista dos parâmetros junto com a finalidade de cada um. A ajuda também pode ser acessada com o cmdlet Get-Help. (Não é bom digitar apenas Get-Help? Você não gostaria que algum conhecido seu pudesse executar esse cmdlet no mundo real?)
Outra maneira de descobrir possíveis parâmetros de um cmdlet é usar a conclusão de tabulação nos nomes dos parâmetros. Digite Get-Mailbox -S e pressione Tab para percorrer os possíveis parâmetros que começam com S.
E, obviamente, existe o extenso sistema de ajuda. Se você não encontra o que está procurando offline, não se esqueça de conferir regularmente o conteúdo de ajuda atualizado em go.microsoft.com/fwlink/?linkid=79421 e o guia de referência rápida em go.microsoft.com/fwlink/?linkid=64647.
Tudo isso é iniciado com o Console de gerenciamento do Exchange, mas essas informações raramente cobrem a superfície do poder e da flexibilidade da linha de comando. Falaremos mais sobre isso em colunas futuras.

P: No ESM (Gerenciador do sistema Exchange) do Exchange Server 2003, podíamos ver facilmente o tamanho da caixa de correio de todos os usuários. Esse recurso parece que não existe mais no Exchange 2007. É possível fazer isso no Exchange 2007?
R: No novo console do Exchange 2007, é possível obter o tamanho de uma caixa de correio na página de propriedades gerais da própria caixa de correio. Se desejar essa informação para vários usuários, use o Shell de gerenciamento do Exchange.
Se executar Get-MailboxStatistics, os dados de um servidor inteiro serão obtidos (não apenas de um banco de dados específico). Por padrão, o tamanho não é mostrado, é necessário executar o cmdlet com Format-List para obter o tamanho:
get-mailboxstatistics | format-list
Talvez seja ainda melhor escolher o que deseja ver e produzi-lo em uma tabela. Nesse exemplo, obtivemos o nome de exibição da caixa de correio, o tamanho total do item, o tamanho total do item excluído e o banco de dados no qual a caixa de correio está:
Get-MailboxStatistics | Select-Object
displayname,totalitemsize,
totaldeleteditemsize,databasename
| Format-Table
Dependendo das informações que está procurando, poderá usar formatações diferentes para a saída. Nesse exemplo, Format-Table funciona melhor do que Format-List

KC Lemson é gerente-chefe de programa na equipe do Exchange Server. Seu número PIN ATM é 0000, não gaste tudo isso em um só lugar.
Nino Bilic, chefe técnico, gasta seu tempo livre colecionando cheques de US$ 1.000 de Bill em agradecimento ao encaminhamento de seu email.


 Security Watch: Implantando o EFS: Parte 2
Security Watch
Implantando o EFS: Parte 2
John Morello

Você pode considerar uma implantação do EFS (Sistema de Arquivos com Criptografia) como tendo essencialmente duas partes: a parte de design de back-end cujo foco está no gerenciamento de certificados e nos agentes de recuperação e a parte de implantação do EFS voltada para o usuário. No mês passado, discuti a parte de back-end e as opções para recuperação de dados e chaves,
bem como as opções para a provisão de certificados para os clientes. Agora, pretendo me concentrar nos aspectos da implantação que serão vistos pelos usuários finais, como os aprimoramentos no Windows® Explorer, a escolha dos locais do sistema de arquivos que serão criptografados e como gerenciar as opções de criptografia com a Diretiva de Grupo.

Determinando se o EFS já está em uso
Depois de optar pela implantação do EFS, a primeira etapa é determinar o estado atual do uso do EFS na sua organização. Lembre-se de que o EFS pode ser usado no modo autônimo, no qual o usuário final é unicamente responsável pela criação e pelo backup dessas chaves de criptografia. Talvez existam usuários avançados na sua organização que já tenham usado o EFS dessa maneira e, portanto, é importante determinar quem são eles de forma a garantir uma transição uniforme e fluente para uma implantação mais gerenciada.
Quando o EFS é implantado pela primeira vez por um determinado usuário em um computador, o Windows cria a seguinte entrada de registro em HKEY_CURRENT_USER:
HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash
O Microsoft® SMS (Systems Management Server), os scripts de logon do Active Directory ou outras ferramentas podem ser usadas para verificar a presença dessa entrada em máquinas na sua empresa. Se um usuário tiver esse valor de registro presente, significa que ele usou o EFS em um determinado ponto. Entretanto, esse valor não indica necessariamente que alguém esteja atualmente usando o EFS ou que qualquer um de seus dados esteja criptografado. Portanto, quando uma máquina é encontrada com esse valor de registro, ela deve ser mais rigorosamente examinada para determinar se existem arquivos criptografados.
O uso de cipher.exe e a transmissão das opções /U e /N fornecerá instruções para que a codificação relate o estado de criptografia de arquivos e diretórios em um computador. Por exemplo, se você quiser determinar se os dados em um sistema estão criptografados, basta executar o seguinte comando:
cipher /U /N
A verificação do registro e o relatório de codificação podem ser combinados em um único script de forma a verificar a presença do valor do registro e, se presente, para gerar um relatório dos arquivos atualmente criptografados no computador. Após a geração desses relatórios, você saberá quais usuários têm quais arquivos criptografados e estará pronto para migrá-los até um design centralmente gerenciado.
Para controlar o aplicativo de Diretiva de Grupo durante a implantação, é útil criar dois grupos de segurança no seu domínio de forma a separar os computadores nos quais o EFS está em uso dos computadores nos quais o EFS não está em uso. Por exemplo, "SG-ComputersUsingEFS" conteria as contas de computador dos computadores nos quais o EFS já está em uso, enquanto "SG-ComputersNotUsingEFS" conteria todas as outras máquinas nas quais o EFS ainda não está em uso.

Controlando o uso do EFS com a Diretiva de Grupo
Depois que você souber quem está e não está usando o EFS, a próxima etapa na implantação do cliente será desabilitar o uso do EFS autônomo para qualquer usuário que não o esteja utilizando. Essa etapa é importante no processo de implantação porque é mais fácil habilitar e configurar o EFS corretamente na primeira vez do que migrar os usuários que estão usando certificados auto-assinados. Você apenas deve realizar essa etapa depois de determinar quais usuários já estão usando o EFS, porque, ao desabilitar o EFS por meio da Diretiva de Grupo, os usuários não serão capazes de acessar nenhum arquivo que esteja atualmente criptografado. Essa diretiva pode ser encontrada no Editor de Objetos de Diretivas de Grupos, em Configuração do Computador\Configurações do Windows\Configurações de Segurança\Diretivas de Chave Pública/Sistema de Arquivos com Criptografia.
Conforme mencionado anteriormente, esse valor deve apenas ser habilitado em computadores no qual o EFS não esteja em uso, para não prejudicar o trabalho de um usuário que já esteja usando o EFS. Portanto, no meu exemplo, a ACL (lista de controle de acesso) no GPO (objeto de diretiva de grupo) que desabilita o EFS permite apenas que o grupo "SG-ComputersNotUsingEFS" aplique a Diretiva de Grupo.

Criptografar ou não criptografar
Depois de determinar quais sistemas estão atualmente usando o EFS e depois de ter desabilitado o EFS em todos os outros sistemas até o gerenciamento da implantação, a próxima etapa é determinar o que será criptografado nessa implantação gerenciada. Dependendo de como os sistemas clientes são gerenciados, esse processo pode variar desde simplista até bem complexo.
A primeira coisa a considerar ao cogitar os arquivos que devem ser criptografados é se os usuários são ou não administradores em seus sistemas. Se os usuários forem administradores locais, você de fato apenas poderá instruí-los e incentivá-los a criptografar os dados confidenciais, mas não poderá realmente controlar esses dados de maneira administrada. A razão disso é simples: um administrador local pode criar arquivos e diretórios em qualquer local no sistema de arquivos. Portanto, embora você possa criptografar os locais comuns, como Meus Documentos, se o usuário criar um novo diretório em outro local e salvar informações confidenciais, será difícil garantir que esses dados também ficarão protegidos. Além de todos os outros benefícios de segurança obtidos quando os usuários finais não são administradores locais, isso também torna o EFS bem mais gerenciável e seguro.
A próxima informação essencial que devemos lembrar sobre o EFS é que ele consiste em um sistema de criptografia por usuário. Em outras palavras, tudo o que for criptografado por um determinado usuário apenas poderá ser descriptografado pelo mesmo usuário e por mais ninguém, incluindo a conta SYSTEM (com a óbvia exceção do Agente de recuperação de dados, ou DRA). Isso significa que, se um executável ou uma DLL for criptografado com a chave de um usuário e outra entidade de segurança no sistema tentar acessá-lo, essa outra entidade de segurança receberá um erro de acesso negado. Dessa forma, em geral, você não deve criptografar arquivos ou diretórios que incluam um código executável que talvez precise ser executado por várias entidades de segurança em um sistema. O Windows impedirá a criptografia de arquivos em %SystemRoot% ou arquivos que contenham o atributo SYSTEM, mas não é incomum que alguns fornecedores de software instalem binários em %ProgramFiles% referentes a serviços que podem ser executados pela conta SYSTEM. Por exemplo, essa é uma abordagem comum que os fornecedores de laptop podem usar ao instalar softwares de gerenciamento de energia e dispositivos que são executados como um serviço.
Com esses dois fatos em mente, quais são as melhores práticas para alvos de criptografia do EFS? A resposta remonta para como os sistemas dos usuários são normalmente configurados. Em um ambiente bem gerenciado com uma imagem de sistema operacional padronizada, você provavelmente poderá automatizar o processo de criptografia para os usuários com base nos locais de armazenamento de dados pré-determinados a partir da sua imagem. Por exemplo, se os usuários apenas puderem salvar dados em %userprofile%\Meus Documentos, apenas será necessário criptografar esse diretório. (Observação: preste atenção ao criptografar Meus Documentos se usar a redirecionamento de pastas. Se Meus Documentos for redirecionado para um servidor, esse servidor precisará ser Confiável para Delegação e ter acesso ao perfil do usuário. Nesses casos, é geralmente mais fácil apenas criptografar o cache de Arquivos Offline, o que discutiremos mais tarde nesta coluna.)
Em um ambiente menos gerenciado (no qual os usuários podem gravar em vários locais do sistema de arquivos), é possível usar a abordagem de automatizar a criptografia de alguns locais de armazenamento comuns e depois de instruir os usuários a criptografar outros locais por conta própria. Independentemente do seu ambiente, você deve sempre criptografar em nível de diretório em vez de em nível de arquivo. Isso faz com que todos os arquivos criados nesse diretório, incluindo os temporários, sempre sejam criptografados.

Locais de criptografia recomendados
Como regra geral, os locais em que você deve criptografar normalmente são: %userprofile%\Meus Documentos, %userprofile%\Application Data\Microsoft\Outlook (supondo que você esteja usando o Microsoft Office Outlook® como cliente de mensagens) e %userprofile%\Desktop. Criptografar Meus Documentos protege o local padrão para arquivos salvos no Windows XP. A proteção do diretório do Outlook garante que os emails com conteúdo sensível armazenados localmente em cache também sejam criptografados, o que é particularmente importante para usuários que executam o Modo em Cache padrão do Outlook 2003 . Por fim, a área de trabalho costuma ser usada como um tipo de diretório temporário no qual os usuários podem inserir documentos atuais de trabalho ou apresentações dadas com freqüência. É claro que, na sua organização, você pode ter modificado os locais padrão de alguns desses diretórios e, portanto, as suas opções de criptografia do EFS deverão refletir os locais que são normalmente usados na organização.
Além dessas práticas gerais, você também deve determinar se existem aplicativos que possam salvar informações sensíveis em locais alternativos. Por exemplo, alguns aplicativos salvar informações do usuário em %ProgramFiles%\AppName em vez de no perfil do usuário. É importante determinar se os seus sistemas de clientes possuem esses aplicativos, para que você possa proteger adequadamente todos os dados utilizados. No cenário mais favorável, o aplicativo poderia ser configurado para salvar alterações em outro caminho específico para o perfil de usuário (como Meus Documentos), no qual nenhuma alteração adicional do EFS fosse necessária. Em um cenário mais desfavorável, se o aplicativo exigir que os dados sejam armazenados no diretório Arquivos de Programas, o EFS poderia ser usado para criptografar apenas o subdiretório específico de Arquivos de Programas.
Por fim, tome cuidado se você planeja criptografar o diretório temporário (%TMP% e %TEMP%). Muitos instaladores de aplicativos usam esse diretório para a expansão do conteúdo de pacotes de instalação e, depois, realizam operações de movimentação de arquivos nos arquivos expandidos para inseri-los no caminho apropriado de %ProgramFiles%. Como um arquivo movido no mesmo volume mantém seus atributos originais, o arquivo continuará a ser criptografado depois de ser inserido em %ProgramFiles%. Dessa forma, se um usuário diferente do que executa o instalador tentar usar esse arquivo, seu acesso a ele será negado. Muitas vezes, esses problemas não se manifestam em mensagens de erro de aplicativo evidentes que indicam a causa básica. Por causa disso, geralmente recomendo que %TMP% apenas seja criptografado em ambientes bem-gerenciado em que os usuários finais não instalam aplicativos por conta própria.

Protegendo arquivos offline
Arquivos offline são um recurso do Windows 2000 e posterior que permite aos usuários finais fazer uma cópia local dos dados armazenados em um servidor de arquivos. Dessa forma, esse recurso permite ao usuário trabalhar nesses dados enquanto estiver desconectado do servidor e sincronizar as alterações de volta ao servidor quando estiver conectado. Entretanto, o recurso Arquivos Offline não consiste em um diretório simples contendo cópias de arquivos do servidor. Trata-se de um banco de dados compartilhado em todo o sistema e que é executado no contexto da conta SYSTEM. No Windows XP, esse banco de dados pode ser protegido com o EFS. Considere o que isso significa tendo como base a discussão anterior sobre o fato que o EFS é específico para cada usuário. Como pode o EFS, que é específico para cada usuário, criptografar um banco de dados usado por várias entidades de segurança?
Quando um usuário que executa o Windows XP escolhe a opção no Windows Explorer para criptografar arquivos offline, a rotina de criptografia utilizada é diferente da usada para as outras operações de criptografia que o usuário pode iniciar. Em vez de utilizar o par de chaves pessoal do usuário para o processo do EFS (que impediria o acesso de SYSTEM aos arquivos), a conta SYSTEM gera automaticamente um par de chaves para uso com o EFS e usa esse par de chaves para criptografar o cache no lado do cliente. Isso apresenta uma crítica implicação de segurança já que, se alguém puder obter subseqüentemente o código para execução como SYSTEM, poderá descriptografar os dados no cache. Se um laptop for roubado, é comum que um atacante redefina a senha do administrador e faça logon como administrador. Após a execução como administrador, é correspondentemente muito simples forçar a execução do código como SYSTEM e então acessar o cache. (Observe que esse comportamento foi alterado no Windows Vista™. Agora, o Windows Vista usa a chave individual do usuário para criptografar Arquivos Offline específicos para cada usuário.)
Para proteger contra esse tipo de ataque, o laptop pode ser configurado para armazenar a chave de criptografia do banco de dados SAM (Gerenciamento de Contas de Segurança) offline, seja como uma entrada de senha no momento da inicialização (modo 2) ou em um disquete durante o processo de inicialização (modo 3). Ambas as abordagens podem ser excessivamente trabalhosas, já que exigem uma interação não automatizável com o computador durante o processo de inicialização, criando problemas potenciais com o gerenciamento de sistemas automatizados. Entretanto, se o EFS for ser usado em um computador com Arquivos Offline, é essencial que uma dessas opções seja usada para proteger os dados no cache. Eu costumo recomendar o uso da senha no momento da inicialização (consulte a Figura 1). O motivo para isso é que, se a maleta para laptop de um usuário for roubada, o disquete provavelmente já estará inserido no laptop ou então estará quase certamente na maleta junto com o laptop.
Figure 1 Automate EFS operations
Figure 1 Automate EFS operations

Habilitando o EFS
Depois de determinar o que criptografar no cliente, a próxima etapa consiste em realizar a operação de criptografia propriamente dita. Esse processo pode ser obtido por meio de um script de logon ou outro processo que executará um script no cliente que chama cipher.exe para realizar a operação de criptografia. Se você tiver usuários autônomos existentes do EFS no seu ambiente, conforme discutido no exemplo anterior, recomendo a migração desses usuários primeiro.
Para migrar esses usuários autônomos, a primeira etapa é fornecer certificados gerenciados aos sistemas de clientes, conforme discutido no fascículo de fevereiro de 2007 desta coluna (microsoft.com/technet/technetmag/issues/2007/02/SecurityWatch). Após a inscrição de todos os sistemas para obtenção desses certificados gerenciados, cipher deverá ser executado com a opção /U para atualizar todos os arquivos existentes com as novas chaves de agente de recuperação e de criptografia. Nesse ponto, todos os sistemas no grupo SG-ComputersUsingEFS estariam utilizando o EFS de forma gerenciada, incluindo chaves centralmente emitidas (e potencialmente arquivadas) e agentes de recuperação centralmente gerenciados.
Para implantar o EFS para usuários que não utilizam o EFS no momento, primeiro você deve remover a Diretiva de Grupo que impede o uso do EFS. Quando esse procedimento estiver concluído e os usuários estiverem inscritos para certificados gerenciados, um script de logon poderá ser executado para criptografar os caminhos de chaves discutidos anteriormente. Este é um exemplo de script bem simples:
cipher /e /s /a "%userprofile%\My Documents"

cipher /e /s /a "%userprofile%\Application Data\Microsoft\Outlook"

cipher /e /s /a "%userprofile%\Desktop"
Depois de habilitar o EFS nos diretórios desejados, considere a definição de duas opções adicionais para aumentar a segurança da implantação do EFS, ambas relacionadas aos dados paginados da memória para o disco. Observe que, para cada um desses cenários, a quantidade de dados que pode ser recuperada por um usuário com más intenções está limitada ao que foi carregado na memória ou paginado em disco durante o uso legítimo. Em outras palavras, se um usuário tiver dados sensíveis protegidos pelo EFS na máquina e não tiver visualizado esses dados (e, portanto, não os tiver carregado na memória), eles não serão um risco em casos de ataques.
O arquivo de página é usado pelo Windows como memória virtual (muitas vezes indicada como espaço de troca em outros sistemas operacionais) e contém seções brutas de dados na memória gravados em texto simples na unidade de disco rígido. Isso pode colocar em risco os dados sensíveis em um sistema protegido pelo EFS, já que, se um atacante for capaz de recuperar o arquivo de página, poderá potencialmente utilizar ferramentas de laboratório para extrair dados usáveis desse arquivo. Como o arquivo de página propriamente dito não pode ser criptografado no Windows XP (observe que ele pode ser criptografado no Windows Vista), a melhor opção será forçar o Windows a apagá-lo quando o sistema for desligado. Isso pode ser feito por meio da Diretiva de Grupo, conforme ilustrado na Figura 2.
Figure 2 Setting group policy
Figure 2 Setting group policy (Clique na imagem para diminuir a exibição)
Figure 2 Setting group policy
Figure 2 Setting group policy (Clique na imagem para aumentar a exibição)
A desvantagem dessa configuração é o aumento significativo do tempo necessário para desligar uma máquina, particularmente se ela tiver muita memória. (Por padrão, o tamanho do arquivo de página está diretamente relacionado à quantidade de memória física no computador.) Isso porque, para apagar o arquivo de página, o Windows deve gravar fisicamente em cada página da unidade de disco antes do desligamento.
A hibernação do arquivo no Windows contém um despejo da memória física da máquina quando o modo de gerenciamento de energia está definido de forma a habilitar a hibernação. Quando a hibernação ocorre, o Windows grava todo o conteúdo da memória física em disco no arquivo de hibernação, permitindo que o computador seja restaurado exatamente para o mesmo estado no momento em que o usuário estiver pronto para continuar a trabalhar. Como o arquivo de página, o arquivo de hibernação não pode ser criptografado no Windows XP. Entretanto, ao contrário do arquivo de página, a hibernação não pode ser diretamente desabilitada a partir de um GPO. Em vez disso, você deve usar um script para chamar powercfg.exe com a opção /HIBERNATE de forma a desabilitar (ou reabilitar) a hibernação.
Depois de concluir as tarefas iniciais de criptografia e configuração, considere a limpeza do espaço de lacuna nos discos da sua implantação. Esse processo pode causar interrupções e exigir bastante tempo, mas apresenta o benefício da segurança em ambientes de alta segurança. O espaço de lacuna é a área de um disco não contém dados atualmente ativos no sistema, mas que, devido ao modo de operação dos discos rígidos, pode conter algumas informações sensíveis de arquivos anteriormente usados. Em outras palavras, como uma operação de exclusão de arquivo não substitui na prática todos os setores ocupados por um arquivo no disco (apenas remove o ponteiro da tabela de arquivos), os dados excluídos podem continuar a existir no disco. Nesses casos, esses dados podem ser recuperados por ferramentas de laboratório capazes de ler esse espaço de lacuna e remontar os arquivos a partir dele. Para limpar seguramente esses dados residuais, execute cipher com a opção /W. Isso força cipher a substituir repetidamente todos os setores marcados como disponíveis no disco. Desde que todas as operações futuras de arquivos em dados sensíveis ocorram em diretórios protegidos pelo EFS, não será necessário executar esse comando regularmente.

Aprimorando o Windows Explorer para o EFS
Por padrão, as opções de criptografia e descriptografia para arquivos e diretórios estão de certa forma arraigadas nos menus de propriedades avançadas do Windows Explorer. É possível optar por aprimorar essas experiência do usuário com o EFS, colocando as opções "Criptografar" e "Descriptografar" no menu de contexto do Windows Explorer (exibido após um clique com o botão direito do mouse). Além disso, o Windows Explorer pode ser configurado para mostrar arquivos e diretórios protegidos pelo EFS com uma cor diferente (verde) dos outros arquivos. Isso pode ajudar os usuários a saber se um arquivo ou diretório está criptografado sem ter que fazer busca detalhada no menu de propriedades avançadas. Por fim, você pode adicionar uma opção para definir quais usuários têm acesso ao arquivo ou diretório. Para habilitar essas opções, faça as seguintes alterações no Registro através de um script que chama o reg.exe:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"EncryptionContextMenu"=dword:00000001

"ShowCompColor"=dword:00000001

[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]
@="rundll32 efsadu.dll,AddUserToObject %1"

EFS no Windows Vista
O EFS passou por uma série de importantes melhorias no Windows Vista que o tornam mais fácil de implantar e gerenciar, além de aumentarem sua segurança. Entre essas melhorias, a principal consiste no suporte completo para o armazenamento de chaves EFS em cartões inteligentes. Trata-se de um recurso especialmente importante para operações que já utilizam o logon via cartão inteligente, pois o mesmo cartão também pode ser usado para armazenar as chaves EFS dos usuários. Esse suporte para cartões inteligentes também se estende a certificados de agentes de recuperação, de forma que os certificados sensíveis do DRA também possam ser armazenados em cartões.
O Windows Vista também suporte a criptografia de itens anteriormente impossível ou muito difícil de se fazer no Windows XP. O Windows Vista pode criptografar o arquivo de páginas, dispensando a necessidade de definir a opção de limpeza do arquivo de página da memória virtual. Todo o design do recurso Arquivos Offline novamente elaborado no Windows Vista. Além do desempenho e da estabilidade muito melhores (bem como uma interface em geral mais simplificada), o armazenamento em cache no lado do cliente ocorre para cada usuários, significando que é possível criptografar seguramente o cache sem o uso do modo 2 ou 3 de SYSKEY. Essas duas melhorias eliminam grandes obstáculos de implantação para os ambientes atuais com base no Windows XP.
Por fim, o Windows Vista permite que administradores configurem a criptografia para a pasta de documentos diretamente por meio da Diretiva de Grupo, sem precisar usar o script de separação. A Figura 3 ilustra as novas propriedades do EFS disponíveis por meio do GPO no Windows Vista.
Figure 3 EFS properties in Windows Vista
Figure 3 EFS properties in Windows Vista (Clique na imagem para diminuir a exibição)
Figure 3 EFS properties in Windows Vista
Figure 3 EFS properties in Windows Vista (Clique na imagem para aumentar a exibição)

Conclusão
O EFS fornece aos administradores do Windows uma opção altamente segura para proteger dados móveis. O EFS é escalável, gerenciável e fornece mecanismos flexíveis de recuperação de dados. No Windows Vista, o EFS é ainda mais aprimorado com recursos avançados para gerenciamento e implantação simplificados, bem como suporte para armazenamento de chaves com base em cartões inteligentes. Para organizações que desejam proteger dados, mesmo quando uma máquina estiver fisicamente perdida, o EFS fornece uma solução poderosa que já faz parte da sua plataforma Windows existente.
Onde procurar mais informações
Para obter mais informações sobre os tópicos discutidos nesta coluna, consulte os recursos a seguir:
  • A coluna Security Watch de fevereiro de 2007
  • Criptografando o sistema de arquivos no Windows XP e no Windows Server 2003
  • Como usar o utilitário SysKey para proteger o banco de dados do gerenciador de contas de segurança do Windows

John Morello graduou-se com louvor na LSU (Universidade do Estado da Louisiana) e trabalha na Microsoft há seis anos, em várias funções. Na condição de consultor sênior, Morello criou soluções de segurança para as empresas da Fortune 100 e clientes civis federais e da defesa. Atualmente, ele é gerente de programa do grupo Windows Server e trabalha em segurança e tecnologias de acesso remoto.


 Os arquivos da &#225;rea de trabalho: PsTools Primer
Os arquivos da área de trabalho
PsTools Primer
Wes Miller
Faça download do código deste artigo: MillerTheDesktopFiles2007_03.exe (150KB)

Até o ano passado, eu trabalhava na Winternals Software, que foi adquirida pela Microsoft em julho de 2006. A Winternals vendia softwares comerciais, mas os fundadores da empresa, Mark Russinovich e Bryce Cogswell, também tinham uma empresa separada chamada Sysinternals que distribuía muitas ferramentas como freeware. Alguns desses aplicativos de freeware tinham
até mesmo se tornado componentes do Winternals Administrator's Pak. Mark e Bryce também licenciavam essas ferramentas para empresas que procuram usá-las fora dos termos de licença típicos de freeware.
Uma das minhas ferramentas favoritas da biblioteca Sysinternals (na verdade várias ferramentas) é o conjunto PsTools, agora disponível em microsoft.com/technet/sysinternals/utilities/pstools.mspx. Mark nomeou as ferramentas após o utilitário de listagem do processo UNIX, ps. Conforme mencionado no site de download das ferramentas, há utilitários Windows® internos da linha de comando que podem realizar algumas funções iguais às dessas ferramentas. No entanto, além da exclusiva funcionalidade significativa, uma grande diferença é o fato de o conjunto PsTools poder ser usado de forma local ou remota (obviamente, se os sistemas remotos foram configurados de modo correto). Melhor ainda, o processo de execução remota é quase tão simples quanto o de execução local.
O conjunto PsTools inclui vários aplicativos individuais, listados na Figura 1. Assim como os demais detalhes da Sysinternals, não há instalador, apenas aplicativos. Basta colocá-los em uma pasta do caminho e pronto!
Figure 1 Utilitários do PsTools (Close Figure 1)

Ferramenta | Descrição
PsExec | Permite executar processos em qualquer contexto de usuário.
PsFile | Mostra os arquivos abertos remotamente em um sistema.
PsGetSid | Exibe o SID (Identificador de segurança do Windows) de um computador ou usuário.
PsInfo | Lista informações sobre um sistema Windows.
PsKill | Interrompe processos por nome ou ID.
PsList | Lista informações detalhadas sobre a execução de processos.
PsLoggedOn | Mostra todos os usuários conectados localmente e todos os usuários de compartilhamento de recursos remoto.
PsLogList | Despeja registros de log de eventos do Windows.
PsPasswd | Altera senhas de contas de usuário.
PsService | Exibe e controla serviços do Windows.
PsShutdown | Encerra, reinicia ou coloca o computador no modo de suspensão ou hibernação.
PsSuspend | Suspende os processos em execução.
Você pode perceber que alguma dessas funcionalidades (especialmente a PsLogList) pode ser realizada através da WMI (Instrumentação de gerenciamento do Windows) e de alguns scripts complexos. Mas o importante é que cada utilitário do conjunto PsTools foi desenvolvido para realizar uma tarefa específica de modo simples e fácil.
Vou falar sobre cada ferramenta e dar um exemplo simples do porquê e como é possível utilizá-la. Primeiramente, farei uma breve introdução do funcionamento das ferramentas propriamente ditas e do tipo de pré-requisitos necessários para seu funcionamento.

Como as ferramentas funcionam?
Geralmente, todas as ferramentas funcionam do mesmo modo. No sistema host, inicie o PsTool desejado. Embora muitas possam ser executadas localmente, essas ferramentas fornecem a funcionalidade máxima quando executadas em um sistema remoto ou em vários sistemas de uma vez. (PsExec é uma exceção específica que vem à mente, como você verá em meu exemplo abaixo.) Utilizando o argumento da linha de comando fornecido, o utilitário se copia no compartilhamento administrativo do sistema remoto, que é igual a %SystemRoot% (diretório do Windows) no sistema remoto.
Após ser copiado no diretório remoto, o aplicativo se inicia e instala um serviço do Windows. Esse serviço do Windows realiza a tarefa solicitada, usando as credenciais fornecidas no momento da inicialização. Se uma interface de usuário final do sistema cliente for exigida por uma ferramenta específica, esse serviço inicia um binário adicional no contexto do usuário. (Lembre-se de que os serviços não podem lançar UIs interativas diretas.) O serviço retransmite as informações necessárias para o console iniciado. E, finalmente, o serviço se desinstala.
Como vocês podem perceber, as ferramentas são poderosas e autônomas. Embora elas envolvam vários binários e vários processos, você como usuário não precisa se preocupar com isso, basta executar a ferramenta desejada e ela funciona.
Para usar as ferramentas, há os seguintes pré-requisitos: Windows NT®, Windows 2000, Windows XP ou Windows Server® 2003 (as versões x86 ou x64 do Windows são suportadas, mas as versões do Itanium não são); o compartilhamento padrão da rede administrativa ativado no sistema remoto no qual as ferramentas estão sendo executadas (admin$); e as portas do compartilhamento de arquivos e de impressora abertas no sistema remoto (se estiver utilizando o Windows Firewall, o firewall de conexão com a Internet ou outro produto de firewall).

PsExec
PsExec é minha ferramenta favorita (e provavelmente não pelo motivo que vocês talvez imaginem). Durante a melhor parte de dois anos, estive executando como “não administrador” em meus sistemas, executo como usuário, não como administrador. Em vez disso, tenho um script curto chamado run.vbs que uso para executar aplicativos como administrador local (é possível executá-los tão facilmente quanto qualquer usuário). A Figura 2 mostra o conteúdo do script, que também está disponível no site da TechNet Magazine em technetmagazine.com/code07.aspx. O script supõe que o PsTools está na variável Path do sistema.
Figure 2 Run.vbs (Close Figure 2)
SET WshShell = WScript.CreateObject("WScript.Shell")
SET WshSysEnv = WshShell.Environment("SYSTEM")
SET FSO = CreateObject("Scripting.FileSystemObject")
IF WScript.Arguments.Count <> 0 Then
    FOR EACH arg IN WScript.Arguments
        iArgCount = iArgCount + 1
        strCmdArg = (arg)
        strCmdArray = Split(strCmdArg, " ", 2, 1)
        IF iArgCount = 1 THEN
        strExe = strCmdArray(0)
        ELSEIF iArgCount = 2 THEN
        strRun = strCmdArray(0)
        ELSE
        strParams = strParams&" "&strCmdArray(0)
        END IF
    NEXT
END IF
'/t:0A && title ***** Admin *****
        strExt = LCase(Right(strExe, 3))

IF strExt <> "exe" AND strExt <> "bat" AND strExt <> "cmd" THEN
WshShell.Run "psexec.exe -d -i -e -u COMPUTERNAME\USER -p PASSWORD  cmd /c start "&strExe&"
    "&strRun&" "&strParams, 0, FALSE
ELSE
WshShell.Run "psexec.exe -d -i -e -u COMPUTERNAME\USER -p PASSWORD "&strExe&" "&strRun&"
    "&strParams, 0, FALSE
END IF

    SET WshShell = NOTHING
    SET WshSysEnv = NOTHING
    SET FSO = NOTHING
Esse script simples é um exemplo de uso do PsExec com a funcionalidade adicionada por Mark enquanto trabalhávamos em nosso produto Protection Manager na Winternals: a capacidade de um usuário limitado fornecer mais credenciais com privilégio para iniciar o PsExec localmente. Obviamente, o uso mais comum de PsExec é executá-lo de forma remota (por exemplo, para executar um utilitário que não fornece sua própria estrutura remota, de script ou de automação). Alguns recursos principais do PsExec incluem a capacidade de copiar um binário em sistemas remotos que serão executados, bem como a capacidade de ditar a afinidade do processador. Outro recursos útil do PsExec é a capacidade de criar scripts em muitos computadores ao mesmo tempo fornecendo um arquivo de script.
Veja o uso simplificado do PsExec:
PsExec \\computer -u username -p password command
É possível expandir isso usando os comutadores usados na Figura 3.
Figure 3 Comutadores do PsExec (Close Figure 3)

Comutador | Descrição
-a | Especifica a afinidade do processador.
-c | Indica se o aplicativo deve ser copiado no sistema remoto.
-d | Especifica que não é necessário aguardar a finalização do processo antes de sair (não aguarda mensagens de êxito ou falha).
-e | Carrega usando o perfil da conta especificada.
-f | Copia o aplicativo mesmo que já exista um no sistema remoto. Verifique se a versão atual (ou uma específica) está sendo executada.
-i | Executa o aplicativo de modo interativo no sistema remoto (necessário se desejar que o usuário final veja qualquer interface do aplicativo).
-l | Executa o aplicativo como um usuário limitado. Remove o token do grupo Administradores e distribui privilégios de processo no nível em que estariam para um membro do grupo Usuários. Útil para executar aplicativos da Internet de alto risco com privilégios mínimos.
-n | Especifica o tempo limite que deve ser aguardado antes da falha de conexão nos computadores remotos.
-priority | Executa o processo na prioridade especificada. Isto é, especifica como o Windows deve definir a prioridade do processo para uma determinada tarefa (-low, -belownormal, -abovenormal, -high ou -realtime ).
-s | Executa o processo usando a conta System (útil para executar o Regedit e acessar chaves de registro com privilégios).
-v | Copia o aplicativo apenas se o que está sendo copiado for mais recente.
-x | Exibe a interface do usuário na área de trabalho segura do Winlogon, funciona apenas no sistema local.
@file | Executa o comando em todos os computadores especificados no arquivo de texto.

PsFile
PsFile é uma ferramenta com um foco menor do que PsExec. Especificamente, essa ferramenta é usada para verificar quais arquivos foram abertos, e por quem, no sistema remoto. Isso pode ser útil se desejar rastrear quais arquivos estão abertos antes de reiniciar um servidor. Se você precisar descobrir qual usuário bloqueou o arquivo, talvez impedindo sua edição ou exclusão, é possível notificá-lo manualmente ou fechá-lo com o PsFile. O uso do PsFile está ilustrado abaixo:
PsFile \\computer -u username -p password
Isso simplesmente retoma uma lista das manipulações de arquivo abertas no sistema remoto. Além do uso padrão, também é possível adicionar um parâmetro Id à instrução, especificando o nome do arquivo sobre o qual deseja obter informações ou fechar. Também é possível incluir o comutador -c, que fecha o arquivo identificado com o parâmetro Id.

PsGetSid
PsGetSid também é uma ferramenta muito focada. Ela informa o SID (Identificador de segurança) de um computador, usuário ou grupo. Isso pode ser útil se desejar assegurar que os sistemas do domínio não tenham SIDs duplicados ou se simplesmente desejar verificar os SIDs de todos os usuários ou grupos de um sistema. O uso do PsGetSid está ilustrado abaixo:
PsGetSid \\computer -u username -p password account
Observe que a conta pode especificar um usuário, computador ou grupo. Embora a sintaxe do PSGetSid seja simples, alguns parâmetros adicionais também estão disponíveis. O parâmetro SID especifica a conta (grupo ou computador) de um SID específico e @file executa o comando em todos os computadores listados no arquivo de texto especificado.

PsInfo
PsInfo é usado para fornecer informações detalhadas do sistema. Isso obviamente seria mais útil para os scripts criados em vários sistemas remotos, com a saída enviada para um arquivo (como um arquivo CSV em Excel® compatível com o banco de dados). Observe que esse utilitário é operado por um conceito importante que é diferente da maioria das outras ferramentas: por padrão, se um nome de computador não for fornecido, PsInfo tentará consultar todos os computadores do domínio. O uso do PsInfo está ilustrado abaixo:
PsInfo  \\computer -u username -p password
Embora a sintaxe seja simples, comutadores e parâmetros adicionais também estão disponíveis, como mostra a Figura 4.
Figure 4 Comutadores do PsInfo (Close Figure 4)

Comutador | Descrição
-h | Mostra todas as atualizações do Windows.
-s | Mostra todos os aplicativos instalados no sistema.
-d | Mostra informações do disco/volume do sistema.
-c | Mostra os resultados em formato CSV.
-t | Especifica outro delimitador para o arquivo CSV diferente do valor padrão \t.
Filter | Mostra apenas os dados que coincidem com um filtro específico.
@file | Executa o comando em todos os computadores listados no arquivo de texto especificado.

PsKill
PsKill é um utilitário excelente para a finalização de processos em sistemas locais ou remotos. O uso é muito simples e permite interromper rapidamente um processo junto com todos os processos filho. O uso do PsKill é muito parecido com o das outras ferramentas já mencionadas:
PsKill -t \\computer -u username -p password process id | process name
É possível especificar a ID ou o nome do processo que deseja interromper.

PsList
Não uso muito o PsList porque sou fã do Process Explorer (consulte microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx para obter mais informações). Mas como não existe uma versão remota do Process Explorer, o PsList se torna um fax razoável para algumas das principais funcionalidades do Process Explorer. Na realidade, o PsList é uma lista remota de um ou mais processos que estão em execução em um sistema remoto.
O uso do PsList é muito simples:
PsList \\computer -u username -p password account
Assim como nas outras ferramentas, o parâmetro account pode especificar um usuário, computador ou grupo. Parâmetros adicionais são mostrados na Figura 5.
Figure 5 Comutadores do PsList (Close Figure 5)

Comutador | Descrição
-t | Mostra informações no nível de thread.
-m | Fornece informações detalhadas da memória para cada processo.
-x | Mostra informações de processo, memória e thread.
-t | Mostra informações como uma árvore de processos (pense na exibição da árvore do Process Explorer).
-s [n] | Executado no modo do gerenciador de tarefas durante o número de segundos especificado. Isso permite a exibição relativamente em tempo real das informações do processo remoto.
-r [n] | Especifica a freqüência (em segundos) da atualização durante a execução no modo do gerenciador de tarefas.
name | Mostra informações sobre os processos que começam com o nome especificado.
-e | Coincide exatamente com o nome do processo.
pid | Exibe informações sobre um processo específico.
O PsList é poderoso e fácil de usar e, sem usar a área de trabalho remota, permite visualizar os processos remotos detalhadamente. Com essas informações, é possível passar para o PsKill ou o PsSuspend se, por exemplo, houver algum processo que deva ser interrompido.

PsLoggedOn
A premissa por trás de PsLoggedOn é auto-explicativa. O utilitário mostra quem está conectado no sistema. Podem ser logons locais (interativos) ou logons de compartilhamento de rede. Similar ao PsFile, esse recurso pode ser útil para determinar quem está usando o servidor que você talvez queira realizar a manutenção. O uso é muito simples:
PsLoggedOn \\computer
O PsLoggedOn tem apenas dois parâmetros opcionais: -l mostra apenas os logons locais (não os de rede) e -x exclui o tempo de logon.
Embora seja básico, o PsLoggedOn permite obter informações facilmente que talvez tivessem que ser investigadas em alguns locais do Windows.

PsLogList
Um dos utilitários normalmente mais úteis, o PsLogList é uma ferramenta para despejar os logs de evento do Windows em um formato de texto que pode ser usado por leitores de log, bancos de dados ou onde desejar. A principal vantagem é o fato de este utilitário converter as entradas do log de evento do formato binário em algo que pode ser facilmente transformado ou automatizado. (Obviamente, no Windows Vista™, os logs de evento estão disponíveis nativamente como XML, mas esse assunto fica para outro dia.)
O uso do PsLogList é:
PsLogList \\computer -u username -p password
Vários comutadores e parâmetros adicionais também estão disponíveis, como mostra a Figura 6.
Figure 6 Comutadores do PsLogList (Close Figure 6)

Comutador | Descrição
-a | Despeja apenas os eventos após a data especificada.
-b | Despeja apenas os eventos antes da data especificada.
-c | Limpa o log de evento permanentemente após despejar a saída desejada.
-d | Exibe apenas as informações para o número de dias especificado.
-e | Exclui eventos com a ID especificada (até 10 podem ser especificadas).
-f | Filtra tipos de eventos (aviso, erro e outros).
-g | Exporta o log de evento como um arquivo EVT, requer o comutador -c.
-h | Exibe apenas as informações para o número de horas especificado.
-l | Despeja a partir do arquivo EVT especificado.
-m | Exibe apenas as informações para o número de minutos especificado.
-n | Exibe apenas o número especificado de eventos mais recentes.
-o | Mostra apenas os eventos de uma origem específica (-o SRService para o serviço de restauração de sistemas Windows, por exemplo).
-q | Exclui eventos de uma origem específica (o oposto de -o).
-r | Ordem invertida, despeja dos eventos mais antigos para os mais recentes do log.
-s | Lista os registros de cada linha dos campos delimitados.
-t | Especifica algo diferente de uma vírgula como delimitador da saída -s.
-w | Aguarda os novos eventos serem preenchidos e despejados em tempo real. Isso é aplicável apenas no sistema local.
-x | Despeja os dados estendidos dos logs de evento.
eventlog | Especifica qual log de evento deve ser despejado. System é o padrão.
@file | Executa o comando em todos os computadores especificados no arquivo de texto.
Os logs de evento do Windows podem ser uma ferramenta de diagnóstico incrivelmente poderosa, mas o difícil é obter os dados no ponto em que podem ser manipulados ou consolidados. O PsLogList realiza esse truque.

PsPasswd
O PsPasswd é um utilitário simples, mas poderoso, desenvolvido com algumas das mesmas funções de Net.exe, mas com remotabilidade e automatização em mente.
PsPasswd  \\computer -u username -p password Username Newpassword
É possível especificar um computador, nenhum computador (o sistema local) ou, se o computador for especificado como \\*, o utilitário será executado em todos os computadores do domínio atual. O PsPasswd tem apenas um parâmetro adicional disponível: @file executa o comando em todos os computadores especificados no arquivo de texto. Mais uma vez, é um utilitário muito básico que é muito útil para vários sistemas.

PsService
O PsService permite visualizar e editar informações do SCM (Gerenciador de controle de serviços) em um ou mais sistemas da rede e é possível até mesmo procurar o nome de um serviço específico nos sistemas da rede.
PsService \\computer -u username -p password command options
Ao executar o PsService, o comando representa um dos comandos listados na Figura 7 e options especifica um atributo a ser aplicado em um determinado comando. Se nenhum comutador de comando adicional for fornecido, o PsService fará um despejo completo das informações do SCM.
Figure 7 Comandos do PsService (Close Figure 7)

Comando | Descrição
query | Consulta um serviço específico.
config | Consulta as informações de configuração de um serviço específico.
setconfig | Define as informações de configuração de um serviço específico.
start | Inicia um serviço.
stop | Interrompe um serviço.
restart | Reinicia (interrompe e inicia) um serviço.
pause | Pausa um serviço.
cont | Retoma um serviço pausado.
depend | Mostra quais serviços dependem de um serviço específico.
find | Procura na rede uma instância específica do serviço.
security | Fornece as informações de segurança de um serviço específico.
Desse modo, é possível encarar o PsService como uma poderosa versão da linha de comando remota de Services.msc, mas que também permite procurar serviços na rede (possivelmente mais perigosos) e definir informações de configuração.

PsShutdown
PsShutdown é outro dos meus favoritos. Embora alguns digam que a Microsoft inclui uma ferramenta que manipula essa tarefa (shutdown.exe), não é a mesma coisa. A principal diferença é a função do PsShutdown, a saber, sua capacidade de encerrar ou reiniciar um sistema remoto. Além disso, ele permite colocar o sistema no modo de espera ou hibernação (não apenas encerramento ou reinicialização), bloquear um sistema e reiniciá-lo após exibir uma mensagem para o usuário durante um determinado período de tempo.
PsShutdown \\computer -u username -p password
Vários parâmetros adicionais também estão disponíveis para serem usados com o PsShutdown, como mostra a Figura 8.
Figure 8 Comutadores do PsShutdown (Close Figure 8)

Comutador | Descrição
-a | Interrompe um encerramento já em andamento iniciado pelo PsShutdown.
-c | Permite que um usuário interativo interrompa o encerramento.
-d | Suspende o computador (espera).
-e | Códigos de motivo de encerramento. Recomendo a consulta ao site da Microsoft para obter ajuda sobre esses códigos, pois podem causar problemas ao serem usados com o PsShutdown e o shutdown.exe interno. Acesse msdn2.microsoft.com/en-us/library/aa376885.aspx para obter mais informações.
-f | Força a finalização de todos os aplicativos em execução.
-h | Coloca o computador em hibernação.
-k | Desliga o computador (reinicia se o desligamento não for suportado).
-l | Bloqueia o computador.
-m | Especifica a mensagem a ser exibida para qualquer usuário interativo.
-n | Especifica o tempo limite que deve ser aguardado antes da falha de conexão nos computadores remotos.
-o | Desconecta o usuário do console.
-r | Reinicia o computador.
-s | Encerra, mas não desliga o computador.
-t | Tempo esperado antes de executar o comando de encerramento ou a hora específica para desligar.
-v | Exibe a mensagem para os usuários até o encerramento.
@file | Executa o comando em todos os computadores especificados no arquivo de texto.
Como vocês podem perceber, o PsShutdown é um utilitário de controle de energia do sistema extremamente configurado e ainda assim relativamente fácil de usar.

PsSuspend
O PsSuspend é um utilitário útil se desejar obter um processo não autorizado sob controle temporariamente ou se simplesmente desejar obter um processo de alto uso da CPU que não está girando temporariamente sem perder nenhum contexto de dados ou aplicativo.
PsSuspend \\computer -u username -p password process ID
É possível obter a ID do processo usando o PsList. Após suspender um processo, use o comutador -r para retomá-lo. Observe que o conceito de suspensão e retomada de um processo também é implementado pelo Process Explorer, embora funcione apenas localmente. Obviamente, o PsSuspend pode suspender e retomar processos tanto remota como localmente, o que é uma vantagem da implementação interna do Process Explorer.

Conclusão
Na minha opinião, o PsTools é um conjunto imprescindível de utilitários. Com os demais utilitários da Sysinternals (a saber, Regmon, Filemon, Process Explorer e agora Process Monitor), o PsTools é o primeiro programa que coloco em meu caminho ao reinstalar o Windows em qualquer sistema. Espero que essa coluna tenha trazido novas informações sobre o PsTools e, caso contrário, espero que tenham aprendido algo mais sobre as ferramentas. Muito obrigado a Mark Russinovich, obviamente, por fornecer essas ferramentas gratuitamente durante todos esses anos e por me ajudar com o conteúdo dessa coluna.

Wes Miller é gerente de desenvolvimento da Pluck (www.pluck.com) em Austin, Texas. Antes disso, Wes trabalhou na Winternals Software, em Austin, e na Microsoft, como gerente de programas e gerente de produtos do Windows. Para entrar em contato com Wes, você pode enviar um email para technet@getwired.com.


 Por dentro da Microsoft.com: Guia de introdu&#231;&#227;o ao espelhamento do banco de dados
Por dentro da Microsoft.com
Guia de introdução ao espelhamento do banco de dados
Saleem Hakani

Se o seu banco de dados fica offline, você provavelmente começa a chorar, não é? No entanto, se estiver usando o SQL Server 2005 com SP1, o recurso de espelhamento do banco de dados pode impedir um desastre. Esta nova tecnologia de alta disponibilidade permite manter um modo de espera ativo do banco de dados para ser usado quando o servidor do banco de dados de produção ficar
indisponível por qualquer motivo. O recurso de espelhamento do banco de dados funciona através da transferência dos registros de log da transação de um banco de dados do servidor primário para o secundário, que serve como o modo de espera ativo. Com o espelhamento do banco de dados, as alterações de dados são registradas no log de transação antes que qualquer alteração nas páginas de dados reais seja feita, assim como as atualizações do SQL Server™ sempre funcionam. Os registros de log são colocados primeiramente no buffer de log do banco de dados principal, na memória, e, em seguida, persistidos no disco. Esses logs de transação são copiados e reproduzidos no banco de dados do servidor de espelhamento. Com isso, as alterações do banco de dados do servidor principal são duplicadas no banco de dados de espelhamento. Observe que apenas o banco de dados principal é acessível às conexões do cliente. Quando o banco de dados principal recebe alterações solicitadas pelos clientes, o servidor principal envia essas alterações ativas para o servidor de espelhamento; o espelhamento não toma nenhuma dessas decisões. Quando o espelhamento do banco de dados está ativado e o banco de dados principal falha, o banco de dados espelhado fica disponível.

Mecânica do espelhamento do banco de dados
O espelhamento do banco de dados funciona com todos os hardwares padrão que suportam o SQL Server 2005 e assegura que não haja nenhuma perda de dados caso um banco de dados falhe. O banco de dados de espelhamento sempre será atualizado com a transação atual que está sendo processada no servidor do banco de dados primário. A Figura 1 ilustra o fluxo de dados.
Se o servidor principal falhar, você pode ter certeza de que o servidor de espelhamento tem uma cópia instantânea exata do banco de dados principal e também da última transação ocorrida. Assim, o espelhamento está sempre pronto para assumir a função do servidor principal.
Figure 1 Data replication to the mirror
Figure 1 Data replication to the mirror (Clique na imagem para diminuir a exibição)
Figure 1 Data replication to the mirror
Figure 1 Data replication to the mirror (Clique na imagem para aumentar a exibição)
Na topologia do espelhamento do banco de dados, será necessário um terceiro servidor chamado testemunha se desejar ativar o failover automático do principal para o servidor de espelhamento e vice-versa. O servidor-testemunha pode ser qualquer computador que suporte o SQL Server 2005.

Modos operacionais
A topologia de espelhamento de banco de dados utilizada depende da segurança da transação e dos modos operacionais escolhidos. Os modos operacionais suportados pelo espelhamento do banco de dados incluem os de alta segurança (com ou sem failover automático) e de alto desempenho.
Alta segurança (com failover automático) - Esse modo suporta a máxima disponibilidade do banco de dados com transferência de dados síncrona e failover automático no banco de dados de espelhamento. Esse módulo operacional é mais útil quando há uma comunicação rápida e muito confiável entre os servidores principal e de espelhamento e o failover automático é necessário para um único banco de dados. Nesse esquema, o banco de dados principal aguarda a ocorrência de uma transação até receber uma mensagem do servidor de espelhamento informando que este fortaleceu o log da transação no disco.
Alta segurança (sem failover automático) - Esse modo suporta a máxima disponibilidade do banco de dados com transferência de dados síncrona, mas sem failover automático no banco de dados de espelhamento. Nesse modo, se a instância do servidor de espelhamento ficar indisponível, a instância do servidor principal continuará a funcionar, mas não será capaz de espelhar os dados. Se o servidor principal falhar, o espelhamento do banco de dado será suspenso, mas será possível forçar o failover do serviço manualmente.
Alto desempenho - Nesse modo operacional, a transferência de dados é assíncrona. O servidor principal não aguarda um reconhecimento do espelhamento assim como nos dois modos acima. O servidor de espelhamento faz o melhor para manter-se informado sobre o servidor principal, mas não é garantido em nenhum momento e todas as transações mais recentes do principal serão fortalecidas no log de transação do servidor de espelhamento. Se o servidor principal falhar, o espelhamento do banco de dado será suspenso, mas será possível forçar o failover do serviço manualmente.

Estabelecendo a base
A configuração do espelhamento do banco de dados é um processo simples se for estabelecida uma base sólida com as práticas recomendadas:
Edição do servidor Verifique se os servidores principal e de espelhamento estão executando a mesma edição do SQL Server 2005; é possível usar a edição Standard ou Enterprise.
Disponibilidade do servidor-testemunha Se pretende usar a alta segurança com failover automático, verifique se o servidor-testemunha está disponível e se o SQL Server 2005 (qualquer edição) está instalado. O servidor-testemunha pode ser executado em qualquer sistema de computador confiável que suporte o SQL Server 2005.
Imagem de espelhamento Verifique se a instância do servidor de espelhamento tem trabalhos, logins, pacotes do SQL Server Integration Service (SSIS), partições de disco, locais de arquivo e configuração do servidor idênticos aos da instância do servidor principal. Configurar o servidor de espelhamento exatamente como o principal permite que o servidor de espelhamento funcione da mesma maneira do principal.
Recuperação total É importante que todos os bancos de dados que participam do espelhamento sejam configurados no modelo de recuperação TOTAL.
Master e TempDB Verifique se todas as instâncias do servidor em uma topologia de espelhamento usam o agrupamento e a página de código Master e TempDB. Ter diferentes agrupamentos e páginas de código pode causar problemas durante a configuração do espelhamento do banco de dados.
Backup Se o banco de dados a ser espelhado for grande, faça um backup completo do banco de dados primeiro e, em seguida, restaure-o na instância do servidor de espelhamento usando a opção NORECOVERY.
Planeje com antecedência Determine todos os nomes de servidor, números de porta, contas de segurança e locais onde os bancos de dados residem e registre-os. Consulte a barra lateral “Práticas recomendadas do espelhamento do banco de dados” para obter uma lista de verificação.
Após ter cuidado da base, você está pronto para lidar com a configuração do espelhamento do banco de dados em seu ambiente.
Práticas recomendadas do espelhamento do banco de dados
  1. Use servidores parceiros que tenham CPU, memória, armazenamento e capacidade de rede idênticos.
  2. Verifique se ambos têm as mesmas edições de SQL Server e do sistema operacional, pacotes de serviço e atualizações.
  3. Instale o SQL Server em diretórios e estruturas de unidade iguais nas instâncias do servidor principal e de espelhamento.
  4. Se o desempenho se tornar uma preocupação, pense em usar uma placa de interface de rede dedicada para separar o carregamento.
  5. Assim como nos servidores parceiros, verifique se as instâncias do servidor principal e de espelhamento são idênticas em relação à CPU, memória, armazenamento e capacidade de rede. Assegurar que os dois servidores tenham a mesma estrutura de diretório, o mesmo esquema de particionamento de disco e a mesma configuração do SQL Server elimina a necessidade de fazer alterações em ambos durante ou após o failover no parceiro de espelhamento.
  6. Verifique se todos os aplicativos podem conectar e executar todas as ações necessárias e se todos os logins ativos do SQL Server (e suas permissões) na instância do servidor principal também estão presentes na instância do servidor de espelhamento. É possível usar a tarefa de logins de transferências do SQL Server 2005 Integration Services para realizar isso.
  7. Copie os trabalhos, alertas, pacotes SSIS, bancos de dados de suporte, definições vinculadas do servidor, dispositivos de backup, planos de manutenção e perfis de mensagem do banco de dados do SQL Server Agent, entre outras coisas, do servidor principal para o servidor de espelhamento.
  8. Estabeleça um procedimento para que quando qualquer modificação for feita no principal (como alterações no hardware, software, configurações do SQL Server ou qualquer objeto do banco de dados), essas alterações sejam automaticamente repetidas ou replicadas e transferidas na instância do servidor de espelhamento.
  9. Realize vários failovers de teste antes de disponibilizar o espelhamento.

Configuração do espelhamento do banco de dados
Vamos configurar o espelhamento do banco de dados usando o modo operacional de alta segurança com failover automático. (Conforme mencionado anteriormente, isso significa que uma instância do servidor-testemunha é necessária). Em meu exemplo, aqui usarei os nomes de servidor e de banco de dados mostrados na Figura 2, que também especifica a função de cada servidor.
Tenha em mente que como a configuração pode afetar o desempenho enquanto o log de transação pendente é copiado do servidor principal no servidor de espelhamento, talvez seja melhor realizar a configuração inicial do espelhamento do banco de dados durante as horas de pouco movimento.
A configuração do espelhamento é feita em três etapas: criação de pontos de extremidade nos servidores participantes, backup e restauração do banco de dados principal e ativação das sessões de espelhamento em todos os servidores participantes.
Antes de estabelecer uma sessão do espelhamento do banco de dados, é necessário estabelecer o mecanismo de comunicação entre todos os servidores que participam no espelhamento do banco de dados. Para tal, crie pontos de extremidade em todos os servidores executando essa instrução em ServerA e ServerB:
Create Endpoint Mirroring_Endpoint
State= Started as TCP (Listener_Port=5001)
For Database_Mirroring (Role=Partner);
Para o ServerC (que atuará como testemunha), altere (Role=Partner) para (Role=Witness) e execute a instrução. Isso controla a porta TCP ouvida por cada instância.
Na próxima etapa, faça o backup completo do banco de dados seguido pelo backup de log do banco de dados DBM_Demo do servidor principal e, em seguida, restaure-o na instância do servidor de espelhamento usando a opção NORECOVERY. (Usar NORECOVERY assegura que o banco de dados de espelhamento esteja no estado de restauração para que os logs de transação possam ser aplicados.)
Eis a instrução T-SQL para realizar o backup completo do banco de dados DBM_Demo do ServerA (a instância do servidor principal):
Backup Database DBM_Demo to DISK='E:\MSSQL\Bak\DBM_Demo_FULL.bak';
Se alguma alteração for feita no banco de dados após a realização do backup completo, talvez seja necessário fazer o backup do log do banco de dados; caso contrário, isso não é necessário.
Se for necessário, use a seguinte instrução T-SQL para realizar o backup do log do banco de dados DBM_Demo do ServerA:
Backup Log DBM_Demo to Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak';
Após realizar todos os backups, mova os arquivos de backup para o ServerB ou para um local compartilhado para que seja possível restaurá-los no ServerB. Depois de fazer isso, restaure também qualquer transação (os backups de log realizados desde o último backup completo do banco de dados do ServerA).
É possível usar a seguinte instrução T-SQL para restaurar os backups completo e de log no ServerB usando a opção NORECOVERY:
--Restore full database backup on the mirror --server instance
Restore Database DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_FULL.bak' with NORECOVERY;
Por fim, use a seguinte instrução T-SQL para restaurar o backup de log no servidor de espelhamento usando a opção NORECOVERY:
Restore Log DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak' with NORECOVERY;
Quando terminar de restaurar todos os backups, você estará pronto para realizar a etapa final, ativando a sessão de espelhamento do banco de dados em todos os servidores participantes.
A configuração da sessão de espelhamento do banco de dados requer um endereço de rede do seguidor para cada instância. Esse endereço deve identificar a instância fornecendo um endereço de sistema e o número da porta na qual a instância está ouvindo. A sintaxe do endereço de rede do servidor é similar a:
TCP://<System-address>:<port>
<System-address>: é um nome de domínio totalmente qualificado ou um endereço IP; para obter essa informação, execute IPCONFIG no computador local de um prompt de comando.
<Port> foi estabelecida durante a criação dos pontos de extremidade.
É possível iniciar a sessão de espelhamento do banco de dados no ServerB do seguinte modo:
Alter Database DBM_Demo
Set Partner= 'TCP://ServerA.com:5001';
Em seguida, execute a seguinte instrução T-SQL para iniciar a sessão no ServerA:
Alter Database DBM_Demo
Set Partner='TCP://ServerB.com:5001';
Finalmente, ative a sessão de espelhamento no ServerC (servidor-testemunha) do seguinte modo:
Alter Database DBM_Demo
Set Witness='TCP://ServerC.com:5001';
O espelhamento do banco de dados agora está pronto para ser executado em seu ambiente. Qualquer objeto adicionado ou modificado no banco de dados DBM_Demo será transferido para a cópia do ServerB. No entanto, se o banco de dados do ServerA ficar indisponível, um failover pode ocorrer, alterando a função do banco de dados espelhado para a função principal.
Agora que o espelhamento do banco de dados está ativado e em execução, você sempre terá um modo de espera ativo pronto se seu banco de dados de produção falhar.

Saleem Hakani é engenheiro sênior de banco de dados da Microsoft com mais de 14 anos de experiência em sistemas de banco de dados. Ele fundou e lidera a comunidade Microsoft SQL e é responsável por fornecer padrões e automatização ao SQL Server através da organização do Windows Live. Saleem possui os certificados MCTS, MCDBA e MCSA. Para entrar em contato com ele, envie um email para Saleem@sqlcommunity.net.


 Anota&#231;&#245;es de campo: O Doutor chegou
Anotações de campo
O Doutor chegou
Matt Hester

NÃO FAZ MUITO TEMPO , cheguei à conclusão de que ser um profissional de TI é um pouco parecido com ser médico. Tive essa idéia quando estava usando o Windows Vista™ pela primeira vez. Na época, estava com problemas de conectividade de rede. Após horas de ping, ipconfig e de algumas reinicializações, vi uma nova palavra que instiga a curiosidade natural que todos os profissionais de TI têm: “diagnosticar”. Normalmente, quando trabalho em um sistema operacional, vejo palavras e frases como “reparar”, “status”, “gerenciador de tarefas” e “enviar relatório de erros” que me ajudam a navegar pelos caminhos do sistema operacional. Mas a palavra “diagnosticar” me fez pensar nas similaridades desses dois profissionais.
Em primeiro lugar, os médicos e os profissionais de TI possuem exames de qualificação e certificações que nos permitem colocar alguns acrônimos depois de nossos nomes. Esses acrônimos identificam nossas especializações e, felizmente, causam uma boa impressão na parede os nos cartões de visita.
Assim como os médicos, os profissionais de TI também têm muitos recursos para solucionar problemas. Os médicos consultam seus colegas e pesquisam informações em publicações profissionais e na Internet. Nós profissionais de TI também consultamos nossos colegas e fazemos pesquisas na Internet e em publicações técnicas (especialmente na TechNet Magazine é claro!) para nos ajudar a solucionar problemas.
Além disso, médicos e profissionais de TI recorrem a ferramentas confiáveis. Os médicos têm instrumentos de tentativa e acerto, como o estetoscópio; nós temos o ping. Ambos permitem que escutemos o que está acontecendo.
O último ponto em comum é a natureza social. Quando médicos e profissionais de TI participam de eventos sociais, normalmente achamos essencial ocultar nossas identidades profissionais. Infelizmente, em uma festa recente, as pessoas descobriram de algum modo o que eu fazia e, repentinamente, me tornei muito popular. Mas essa popularidade tem um preço: também perdi minha identidade como um ser humano encantador. Simplesmente me transformei no “técnico de PC” e, conseqüentemente, o especialista de suporte do local a contra gosto para todos os convidados da festa: “Ei, técnico de PC, por que meu computador quebrou essa manhã?”, “Ei, técnico de PC, onde está Qualquer tecla?”, “Ei, técnico de PC, você pode consertar meu Mac?”. A pior parte é que eu vi um médico na sala com um largo sorriso de cumplicidade olhando para mim enquanto dançava sem parar.
Mas voltando ao meu problema de conectividade: após três horas de tentativas mal sucedidas de conexão, cliquei no botão Diagnosticar e reparar recém descoberto. Imaginem meu choque e constrangimento quando vi a tela de resposta mostrada abaixo:

(Clique na imagem para diminuir a exibição)
Boquiaberto e com o rosto vermelho, olhei pela sala para ter certeza de ninguém estava observando. Então, me aproximei do computador e conectei o cabo. Desde esse dia feliz, tenho trabalhado cada vez mais com o Windows Vista e usado muito o recurso de diagnóstico. Isso economizou um enorme tempo que levaria para encontrar a raiz de muitos problemas. Isso também se encaixa muito bem no painel de controle Relatórios e soluções de problema, que permite pesquisar informações adicionais online. Confira antes de arrancar seus cabelos.
No final desse dia, quando estava indo dormir feliz por ter sido bem-sucedido ao identificar e solucionar meu problema de conectividade de rede, pensei: isso significa que eu devo jogar mais golfe e dirigir um novo carro esporte luxuoso?

Matt Hester é apresentador da TechNet da equipe Microsoft Across America. Para saber mais sobre suas apresentações, acesse technetevents.com/mhester. Confira também o blog dele em blogs.technet.com/matthewms.


 Segredos do Windows: Parecendo inteligente, sendo ignorante
Segredos do Windows
Parecendo inteligente, sendo ignorante
Raymond Chen

QUANDO VOCÊ insere um CD no seu computador, talvez o Windows® pergunte o que deve fazer, mesmo que você o tenha informado da última vez. Por que o Windows esquece as configurações de reprodução automática? Bem, ele não esquece, está apenas verificando.
Havia dois problemas com a maneira como o Windows XP tratava a reprodução automática do CD. Primeiro, vários usuários descobriram que, depois de instalar um programa que dá suporte à reprodução automática do CD, não sabiam como torná-lo seu novo programa padrão. Se tivessem selecionado um programa anteriormente e marcado "Sempre executar a ação selecionada", não havia uma maneira fácil de descobrir para desfazer essa marcação e fazer a caixa de diálogo de reprodução automática do CD aparecer novamente, de forma que o usuário tivesse a oportunidade de selecionar o novo programa como padrão.
Segundo, determinados programas medíocres, na instalação, alteravam secretamente as configurações não-documentadas de reprodução automática do CD para se definir como o manipulador padrão, substituindo a opção do usuário.
Simplificando, para os usuários, os dois problemas eram os seguintes: "Acabei de instalar este programa e quero que ele seja o programa de reprodução de CDs padrão" e seu oposto "Acabei de instalar este programa e não quero que ele seja o programa de reprodução de CDs padrão".
Windows Vista treats autoplay settings globally
Windows Vista treats autoplay settings globally (Clique na imagem para diminuir a exibição)
Windows Vista treats autoplay settings globally
Windows Vista treats autoplay settings globally (Clique na imagem para aumentar a exibição)
O Windows XP Service Pack 2 (SP2) apresentou um novo comportamento de reprodução automática de CDs, em uma tentativa de resolver esses problemas. Ao perceber que um novo manipulador de reprodução automática de CDs está disponível, agora o Windows mostra a caixa de diálogo de reprodução automática de CDs mais uma vez. Isso lhe dá a oportunidade de escolher aquele novo programa que acabou de instalar ou de desmarcá-lo, se ele foi suficientemente grosseiro para se definir como o novo player padrão.
A caixa de diálogo de reprodução padrão do CD também é aberta na primeira vez em que você insere um CD após atualizar para o Windows XP SP2. Esta é uma caixa de diálogo do tipo "antes tarde do que nunca", para resolver a questão dos manipuladores que foram instalados antes de você atualizar para o Windows XP SP2.
Antigamente, o sistema operacional precisava se preocupar somente em fornecer recursos para a interface dos desenvolvedores. Mas, no atual cenário dos softwares, ele também precisa saber como parar os programadores que tentam usar a interface inapropriadamente.
Existe um outro caso em que pode parecer que o Windows esqueceu suas configurações de reprodução automática. Ao inserir um dispositivo de armazenamento removível, como uma unidade USB, pode aparecer um prompt, apesar de você já ter selecionado uma opção e marcado "Sempre executar a ação selecionada". Isso não se deve ao fato de o Windows ter esquecido suas configurações, mas por ele lembrá-las todas perfeitamente.
Quando você seleciona uma opção para um dispositivo de armazenamento removível, o Windows lembra da configuração desse dispositivo. Se você conectar um outro dispositivo, receberá um novo prompt, pois não especificou o comportamento desejado para ele. O objetivo deste design é permitir que você possa definir que sua câmera digital adote como padrão "Exibir imagens", enquanto o player de música adota "Reproduzir música". (Se o dispositivo não possuir um número de série, ao conectá-lo em uma outra porta, ele será tratado como um dispositivo diferente.)
Em resposta à confusão criada pelo design do Windows XP, esse comportamento foi alterado no Windows Vista™. Agora, as configurações de reprodução automática são tratadas de maneira global e não por dispositivo. Se você disser "Nenhuma ação", o Windows Vista não executará nenhuma ação, independentemente do dispositivo que for inserido ou o local onde ele for conectado. Às vezes, para fazer o sistema operacional parecer mais inteligente é necessário torná-lo ignorante.

Raymond Chen, The Old New Thing (blogs.msdn.com/oldnewthing), e o livro de mesmo título (Addison-Wesley, 2007) tratam da história do Windows e da programação Win32. Ele é conhecido por fazer ensaios de 7º grau em seu tempo livre.