user1261104's questions

Eu fiz um procedimento armazenado restoredatabaseque retorna código para restaurar um banco de dados. O script de saída fica assim:

restore database [DB]  from disk='F:\FULL1.bak' with norecovery
restore database [DB]  from disk='F:\DIFF1.bak' with norecovery
restore log [DB]  from disk='F:\log1.bak' with norecovery
restore log [DB]  from disk='F:\log2.bak' with norecovery
...
restore log [DB]  from disk='F:\logN.bak' with norecovery
restore database [DB] with recovery

Ao longo do SP, as linhas são adicionadas a um parâmetro @sql varchar(max)que, ao final, é impresso com print(@sql), e se o usuário especificou o sinalizador correto, é executado com exec(@sql). Ambos funcionam perfeitamente. No entanto, ao chamar o SP com sqlcmd assim:

set restoresql=exec restoredatabase @DB='Databasename', @Execute='y'
sqlcmd -h-1 -S SRV\T2 -U sa -P sa -d master -Q "%restoresql%" -o output.txt

O arquivo de saída output.txtsempre terá no máximo 4002 caracteres.

Eu tentei adicionar, -y 8000mas isso não ajuda. Como posso obter o arquivo de saída para me fornecer o script gerado completo?

Eu uso o script Ola Hallengrens para manutenção do índice. Antes de fazer isso, usei a seguinte consulta para ver quais índices estão mais fragmentados:

SELECT dbschemas.[name] as 'Schema',
dbtables.[name] as 'Table',
dbindexes.[name] as 'Index',
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
ORDER BY indexstats.avg_fragmentation_in_percent desc

No meu caso, o avg_fragmentation foi superior a 70% para 15 índices e superior a 30% para 28 índices.

Então, eu reconstruo cada índice usando a solução de Ola Hallengren. Quando executei a consulta novamente, este foi o resultado:

Fragmentação acima de 70% para 12 índices, acima de 30% para 15 índices.

Imaginei, o motivo era por causa do page_count, que era inferior a 1000 para cada um dos índices que ainda estavam muito fragmentados. Por exemplo, um dos índices com um page_count de 967 tem uma porcentagem de fragmentação de 98,98% ! Para mim, parece valer a pena reconstruir esse índice! Eu fiz, e depois, a fragmentação foi de 0% . Além disso, um índice com um page_countde 132 passou de 95% para 0%

Então, minha pergunta é: quais motivos haveria para NÃO reconstruir esses índices? Uma razão pode ser que a reconstrução custa tempo e recursos, mas como os índices são pequenos, isso não significa que custa relativamente poucos recursos e ainda seria benéfico reconstruí-la de qualquer maneira?

Existem várias perguntas relacionadas neste site, mas todas elas respondem à pergunta por que um índice não seria desfragmentado ou se os índices ainda são úteis se forem pequenos e você não os desfragmentar, enquanto aqui a declaração DIMINUI a fragmentação, com a questão é, por que não fazê-lo de qualquer maneira?