O SQL Server 2014 CTP1 apresenta extensões para opções de operação online que serão boas notícias para empresas que hospedam bancos de dados muito grandes que exigem pouco ou nenhum tempo de inatividade.
Para definir o contexto, imagine que você esteja usando o SQL Server 2012 Enterprise Edition para o gerenciamento de índice online e os recursos de particionamento de índice e tente a seguinte reconstrução de índice em uma tabela particionada:
ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber] ON [dbo].[FactInternetSales] REBUILD PARTITION = ALL WITH (ONLINE= ON);
Testando isso no SQL Server 2012, conseguimos reconstruir todas as partições online sem erros. Mas e se quisermos especificar uma partição específica em vez de todas as partições?
ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber] ON [dbo].[FactInternetSales] REBUILD PARTITION = 1 WITH (ONLINE= ON);
Ao tentar fazer isso no SQL Server 2012 ou anterior, você verá a seguinte mensagem de erro:
Msg 155, Level 15, State 1, Line 4
'ONLINE' não é uma opção ALTER INDEX REBUILD PARTITION reconhecida.
Mas a partir do SQL Server 2014 (a partir de CTP1), as operações de índice de partição única online agora são suportadas. E isso é certamente um grande negócio para cenários de manutenção de mesa muito grandes, onde você preferiria, ou de fato, deve quebrar sua manutenção geral em partes menores durante um período de tempo. Você também pode querer fazer manutenção em nível de partição apenas para as partições que realmente exigem isso – por exemplo, as partições que realmente excedem um nível de fragmentação específico.
Para testar essa funcionalidade do SQL Server 2014 CTP1, usei o AdventureWorksDW2012 com uma versão do FactInternetSales que contém 61.847.552 linhas e particionada pela coluna ShipDate.
Reconstruindo todas as partições online para a tabela usando
PARTITION = ALL no meu ambiente de teste levou 3 minutos e 23 segundos. Em relação à duração geral, meus testes foram para índices que não eram tão fragmentados, então a duração de 3 minutos e 23 segundos representa uma duração média em alguns testes. Lembre-se também de que eu não tinha cargas de trabalho concorrentes em execução no momento, portanto, a reconstrução online está acontecendo sem ter que competir com outras cargas de trabalho significativas em relação ao índice em questão. A forma do plano de execução da consulta para a reconstrução do índice online usando
PARTITION = ALL foi o seguinte:
Plano de execução para reconstrução online de todas as partições
Observe que as operações são habilitadas para paralelo, exceto para o operador Constant Scan. No plano de execução da consulta, você pode ver 39 linhas na Constant Scan de referência externa que estão sendo passadas para o operador Distribute Streams e, em seguida, direcionando o Nested Loop.
O significado das 39 linhas? A consulta a seguir valida a contagem máxima do número de partição de
sys.dm_db_partition_stats . Para meu ambiente de teste, o resultado foi 39 para o número máximo de partição, correspondendo ao que vi para as linhas reais do Constant Scan:SELECT MAX([partition_number]) AS [max_partition_number]
FROM [sys].[dm_db_partition_stats]
WHERE [object_id] = OBJECT_ID('FactInternetSales'); Agora você também notará o operador Online Index Insert no plano anterior. Removendo o
ONLINE = ON opção do meu ALTER INDEX REBUILD (tornando-a uma operação offline) e mantendo a PARTITION = ALL opção, a única mudança foi ter um operador “Index Insert” em vez de um “Online Index Insert” no plano de execução da consulta – e também uma redução na duração, onde meu teste mostrou uma duração de execução de 1 minuto e 9 segundos em comparação com o online 3 minutos e 23 segundos. Em seguida, testei uma reconstrução online de uma partição com 5.678.080 linhas (lembre-se que a contagem total de linhas da tabela é de 61.847.552 linhas). Para este teste, a duração geral levou exatamente 1 minuto e teve a seguinte forma de plano de execução de consulta:
Plano de execução para reconstrução online de uma única partição
A primeira observação é que este é um plano em série. Observe também que eu disse que escolhi uma partição das 39 originais, embora essa partição específica representasse ~ 9% das linhas na tabela geral. Observe também que o Constant Scan mostra 1 linha em vez de 39, como eu esperaria.
E quanto à duração de uma única partição, reconstrução offline? No meu ambiente de teste, isso levou 11 segundos em comparação com a reconstrução online de 1 minuto. A forma do plano de execução da consulta para a reconstrução offline de uma única partição foi a seguinte:
Plano de execução para reconstrução offline de uma única partição
Observe que não há nenhum processo de Verificação Constante ou de Loops Aninhados associado e observe também que este plano agora tem operadores paralelos em relação ao plano serial anterior, mesmo que ambos estejam fazendo uma Verificação de Índice Agrupado para 5.678.080 linhas. Também fazer uma pesquisa de palavra-chave de “partição” no texto do plano XML para a operação de índice paralelo offline de partição única não resultou em nenhuma correspondência – em comparação com o plano serial, operação de índice de partição única online que tinha Partitioned =“true” para o Verificação de índice clusterizado e operadores físicos de inserção de índice on-line.
De volta à exploração principal…
Posso escolher algumas, mas não todas as partições em uma única execução? Infelizmente não.
O
ALTER INDEX e ALTER TABLE comandos têm a PARTITION = ALL argumento e então PARTITION = <partition number> argumento, mas não a capacidade de listar várias partições para uma única operação de reconstrução. No entanto, não estou reclamando muito disso, pois estou feliz por ter a capacidade de reconstruir uma única partição online e não é muito complicado executar a operação uma vez para cada reconstrução, no entanto, o impacto cumulativo na duração foi algo Eu queria explorar mais. Quanto tempo levaria para reconstruir todas as 39 partições separadamente e online versus
PARTITION = ALL duração de 3 minutos e 23 segundos? Sabemos que um benefício das recompilações online é a capacidade de ainda acessar a tabela ou o índice associado durante a operação de índice. Mas em troca dessa operação online, perderemos a vantagem de desempenho da reconstrução em comparação com uma reconstrução offline. E o que eu queria saber a seguir era como uma reconstrução on-line de partição um por um funcionaria em relação ao
PARTITION = ALL alternativo. Executando 39 operações de reconstrução separadas (uma reconstrução para cada partição exclusiva), a duração total da execução foi de 9 minutos e 54 segundos em comparação com
PARTITION = ALL que levou 3 minutos e 23 segundos, então claramente a abordagem fragmentada não é cumulativamente tão rápida quanto uma reconstrução online de todas as partições em uma instrução. Embora eu tenha conseguido fazer uma partição por vez, o benefício geral é a capacidade de separar nossas atividades de manutenção ao longo do tempo e manter o acesso aos objetos enquanto eles estão sendo reconstruídos, mas se você estiver procurando por uma reconstrução mais curta janela, as opções offline ainda são as mais rápidas, seguidas pelas online para PARTITION = ALL e então em último lugar, fazendo uma partição de cada vez. A tabela a seguir recapitula as comparações de duração – e, novamente, esses testes foram baseados no SQL Server 2014 CTP1 e um tamanho de tabela muito específico e configuração de convidado de VM, portanto, preste mais atenção às durações relativas entre os testes em vez das durações em si:
| Descrição do teste | Duração |
|---|---|
| Reconstrução offline de todas as partições | 1:09 |
| Reconstrução online de todas as partições | 3:23 |
| Reconstrução online de uma partição | 1:00 |
| Reconstrução offline de uma partição | 0:11 |
| Reconstrução online de todas as partições, uma partição por vez | 9:54 |
Agora há outros aspectos a serem explorados sobre este assunto também. Só porque uma operação está online não significa que não haja alguns momentos (ou mais) em que os bloqueios ainda sejam mantidos no objeto de destino. As operações de índice ainda têm comportamento de bloqueio para operações online – e o SQL Server 2014 também forneceu opções para isso, que explorarei em uma postagem separada.
