Criando partições para gerenciar subconjuntos de dados
Particionando uma tabela ou um índice, você pode mover subconjuntos de dados de forma rápida e eficiente usando a instrução Transact-SQL ALTER TABLE...SWITCH da seguinte maneira:
Adicionando uma tabela como partição a uma tabela particionada já existente.
Alternando a partição de uma tabela particionada para outra.
Removendo uma partição para formar uma tabela única.
Esses cenários podem ser úteis quando for adicionar novos dados a uma tabela particionada e for remover regularmente dados antigos da mesma tabela particionada. Esta operação envolve grandes ou pequenas quantidades de dados em vários cenários. Se os novos dados que você está adicionando tiverem de ser carregados, apagados ou transformados, eles poderão ser tratados como uma entidade separada para serem adicionados como uma partição. Dados antigos podem ser arquivados ou armazenados. Independentemente de a coleção ser grande ou pequena, a transferência é rápida e eficiente, pois, diferente da instrução INSERT INTO SELECT FROM, os dados não são fisicamente movidos. Somente os metadados sobre onde eles estão armazenados mudam de uma partição para outra.
Exemplo de cenário
Sob o cenário de particionamento do exemplo de banco de dados AdventureWorks2008R2, o Ciclos da Adventure Works arquiva seus dados antigos da tabela TransactionHistory em uma tabela TransactionHistoryArchive alternando as partições entre as duas tabelas. Isto é realizado particionando TransactionHistory no campo TransactionDate. O intervalo de valores para cada partição é de um mês. A tabela TransactionHistory mantém as transações mais recentes do ano, enquanto TransactionHistoryArchive mantém as transações mais antigas. Particionando as tabelas dessa forma, o valor de um único mês de dados de um ano pode ser transferido mensalmente de TransactionHistory para TransactionHistoryArchive.
No início de cada mês, os dados do último mês atualmente na tabela TransactionHistory são enviados para a tabela TransactionHistoryArchive. Para realizar esta tarefa, ocorre o seguinte:
A tabela TransactionHistoryArchive deve ter o mesmo esquema de design da tabela TransactionHistory. Deve haver também uma partição vazia para receber os novos dados. Nesse caso, TransactionHistoryArchive é uma tabela particionada que consiste em apenas duas partições. Uma partição contém todos os dados antes de setembro de 2003 e a outra, todos os dados de setembro de 2003 em diante. Essa última partição está vazia.
.gif "Estrutura das tabelas antes de alternar o particionamento")
A função de partição da tabela TransactionHistoryArchive é modificada para dividir sua partição vazia em dois, com uma das partições definida para receber a nova partição para os dados de setembro de 2003.
.gif "Primeira etapa da alternância de particionamento")
A primeira partição da tabela TransactionHistoryArchive, que contém todos os dados criados durante setembro de 2003, é alternada para a segunda partição da tabela TransactionHistoryArchive. Observe que uma restrição de verificação deve ser definida na tabela TransactionHistory para especificar que não há dados anteriores a 1º de setembro (TransactionDate >= '9/01/2003'). Essa restrição garante que a partição 1 contém apenas os dados de setembro de 2003 e que está pronta para ser alternada para a partição que mantiver somente os dados de setembro de 2003 da tabela TransactionHistoryArchive. Observe também que quaisquer índices, que não estejam alinhados com suas respectivas tabelas, deverão ser descartados ou desabilitados antes da alternância. Porém, eles poderão ser recriados após a alternância. Para obter mais informações sobre o alinhamento dos índices particionados, consulte Diretrizes especiais para índices particionados.
.gif "Segunda etapa da alternância de particionamento")
A função de partição da tabela TransactionHistory é modificada para mesclar suas duas primeiras partições em uma única partição. Essa partição, agora partição 1, contém todos os dados criados em outubro de 2003 e estará pronta para ser alternada para TransactionHistoryArchive no mês seguinte, desde que a restrição de verificação existente seja alterada para especificar que não há dados mais antigos de 1º de outubro (TransactionDate >= '10/01/2003').
.gif "Terceira etapa da alternância de particionamento")
A função de partição da tabela TransactionHistoryArchive é modificada novamente para mesclar sua segunda partição, que contém os dados de setembro que acabaram de ser adicionados, com a primeira partição. Essa ação levará a tabela TransactionHistoryArchive de volta para sua condição original na qual sua primeira partição manterá todos os dados e a sua segunda partição estará vazia.
.gif "Quarta etapa da alternância de particionamento")
A função de partição da tabela TransactionHistory foi modificada novamente para dividir sua última partição em duas partições, de modo que o mês mais recente esteja separado do mês anterior e a partição esteja pronta para receber novos dados.
.gif "Quinta etapa da alternância de particionamento")
Para obter um script do Transact-SQL que implementa este cenário, consulte o exemplo ReadMe_SlidingWindow. Para obter informações sobre exemplos, consulte Considerações para instalar exemplos e bancos de dados de exemplo do SQL Server.