O tamanho do meu banco de dados é enorme e, recentemente, notei que uma nova tabela adicionada há alguns meses é a culpada.
Aqui está o script da tabela.
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Entry_tracker](
[S.Number] [int] IDENTITY(1,1) NOT NULL,
[EntryId] [varchar](50) NOT NULL,
[EventNumber] [varchar](18) NOT NULL,
[Data] [varbinary](max) NOT NULL,
[TrackDateTime] [datetime] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
ALTER TABLE [dbo].[Entry_tracker] ADD CONSTRAINT [DF_Entry_tracker_TrackDateTime] DEFAULT (getdate()) FOR [TrackDateTime]
GO
Coletei informações sobre essa tabela e descobri que a tabela tem cerca de 16 milhões de linhas e o tamanho da tabela é de 1,4 TB.
Ainda assim, acho que o tamanho da mesa é enorme para o não. de registros.
Esta tabela não é consultada pelo aplicativo. Ele apenas armazena diferentes versões das mesmas entradas de outra tabela.
Verifiquei as informações de fragmentação e mostra 0 fragmentação média com 93% de espaço médio usado.
Como estou usando o SQL Server 2016, pensei que poderia usar a compactação de tabela, então tentei sp_estimate_data_compression_savings
estimar possíveis economias de espaço. No entanto, os resultados não mostram economia.
size_with_current_compression_setting(KB)
é igual asize_with_requested_compression_setting(KB)
Alguém pode me orientar para encontrar o problema com esta tabela?
É realmente importante, pois isso está ocupando muito espaço em disco.
Agradeço sua ajuda.
Por quê? O que te fez dizer isso?
Por isso, contém versões, que podem ser grandes ou pequenas, especialmente dadas:
[Data] [varbinary](max) NOT NULL,
Você verificou as
datalength()
fileiras para ver se você tem algumas fileiras grandes lá comendo espaço?Parece-me que, com base nos dados, o tamanho que recebe a função parece razoável. O controle de versão raramente é pequeno, a menos que seja apenas bytes alterados e você use vários algoritmos para entender quais bytes, como e se ele se baseia em versões alteradas anteriormente ou não.