Início / dba / Perguntas / 218472
Accepted
Andrew Hill
Asked: 2018-09-25 20:28:05 +0800 CST

causa de / como corrigir uma tabela com páginas reservadas em excesso

  • 772

Eu tenho várias tabelas com índices clusterizados no azure PaaS sql server que se tornaram muito maiores que seus dados, com contagem de páginas reservadas várias vezes maior que a quantidade real de dados na tabela. Essas tabelas são apenas inseridas (sem exclusões ou atualizações), embora de tempos em tempos sejam inseridas linhas, que falham na inserção devido à violação de PK.

  1. isso é um problema? - o azure está relatando que todo o espaço 'reservado' neste banco de dados está realmente em uso (um pouco esperado pelo que entendo sobre o que significa reservado)
  2. existe uma causa conhecida para esta explosão? - uma mesa de 10gb consumindo 70gb de espaço é um pouco excessivo.
  3. existe uma maneira de limpar isso?
  4. existe uma estratégia que eu possa empregar para evitar que isso aconteça novamente?

um exemplo

partition_id    object_id   index_id    partition_number    in_row_data_page_count  in_row_used_page_count  in_row_reserved_page_count  lob_used_page_count lob_reserved_page_count row_overflow_used_page_count    row_overflow_reserved_page_count    used_page_count reserved_page_count row_count
72057594050904064   274100017   1   1   1082295 1086782 5527998 0   0   0   0   1086782 5527998 61559096

Este é um objeto com fragmentação extrema conhecida (> 90%), no entanto, minha expectativa pessoal é que um layout ruim no disco não cause grandes quantidades de espaço desperdiçado, apenas latência de busca excessiva devido à minimização de leituras contíguas.

Além disso, supondo que as páginas individuais sob inserção aleatória sejam preenchidas e divididas em duas páginas pela metade, cada página deve oscilar entre 50% e 100% (média de 75%), resultando em uma sobrecarga de armazenamento de aproximadamente 25% para uma tabela / tabela altamente fragmentada. índice.

azure-sql-database

1 respostas

  1. Best Answer

    Por favor, examine o nível de fragmentação desses índices com a consulta abaixo. A fragmentação do índice pode ser a culpada.

    SELECT
 DB_NAME() AS DBName
 ,OBJECT_NAME(ps.object_id) AS TableName
 ,i.name AS IndexName
 ,ips.index_type_desc
 ,ips.avg_fragmentation_in_percent
 FROM sys.dm_db_partition_stats ps
 INNER JOIN sys.indexes i
 ON ps.object_id = i.object_id
 AND ps.index_id = i.index_id
 CROSS APPLY sys.dm_db_index_physical_stats(DB_ID(), ps.object_id, ps.index_id, null, 'LIMITED') ips
 ORDER BY ps.object_id, ps.index_id

    Se você reconstruir seus índices, recuperará esse espaço extra. Você reduzirá o tamanho desses índices e o tamanho do banco de dados geral. Execute a manutenção do índice com o seguinte script:

    DECLARE @TableName varchar(255)

 DECLARE TableCursor CURSOR FOR
 (
 SELECT '[' + IST.TABLE_SCHEMA + '].[' + IST.TABLE_NAME + ']' AS [TableName]
 FROM INFORMATION_SCHEMA.TABLES IST
 WHERE IST.TABLE_TYPE = 'BASE TABLE'
 )

 OPEN TableCursor
 FETCH NEXT FROM TableCursor INTO @TableName
 WHILE @@FETCH_STATUS = 0

 BEGIN
 PRINT('Rebuilding Indexes on ' + @TableName)
 Begin Try
 EXEC('ALTER INDEX ALL ON ' + @TableName + ' REBUILD with (ONLINE=ON)')
 End Try
 Begin Catch
 PRINT('Cannot do rebuild with Online=On option, taking table ' + @TableName+' down for douing rebuild')
 EXEC('ALTER INDEX ALL ON ' + @TableName + ' REBUILD')
 End Catch
 FETCH NEXT FROM TableCursor INTO @TableName
 END

 CLOSE TableCursor
 DEALLOCATE TableCursor

    Crie um Azure Runbook para desfragmentar índices regularmente e evite usar mais espaço de armazenamento.

    • 1

relate perguntas