Eu estava enfrentando alguns problemas de desempenho com uma consulta ontem e, após uma investigação mais aprofundada, notei o que acredito ser um comportamento estranho com um índice columnstore clusterizado do qual estou tentando chegar ao fundo.
A mesa é
CREATE TABLE [dbo].[NetworkVisits](
[SiteId] [int] NOT NULL,
[AccountId] [int] NOT NULL,
[CreationDate] [date] NOT NULL,
[UserHistoryId] [int] NOT NULL
)
com o índice:
CREATE CLUSTERED COLUMNSTORE INDEX [CCI_NetworkVisits]
ON [dbo].[NetworkVisits] WITH (DROP_EXISTING = OFF, COMPRESSION_DELAY = 0) ON [PRIMARY]
Atualmente, a tabela tem 1,3 bilhão de linhas e estamos constantemente inserindo novas linhas nela. Quando digo constantemente, quero dizer o tempo todo. É um fluxo constante de inserção de uma linha de cada vez na tabela.
Insert Into NetworkVisits (SiteId, AccountId, CreationDate, UserHistoryId)
Values (@SiteId, @AccountId, @CreationDate, @UserHistoryId)
Plano de execução aqui
Eu também tenho um trabalho agendado que é executado a cada 4 horas para excluir linhas duplicadas da tabela. A consulta é:
With NetworkVisitsRows
As (Select SiteId, UserHistoryId, Row_Number() Over (Partition By SiteId, UserHistoryId
Order By CreationDate Asc) RowNum
From NetworkVisits
Where CreationDate > GETUTCDATE() - 30)
DELETE
FROM NetworkVisitsRows
WHERE RowNum > 1
Option (MaxDop 48)
O plano de execução foi colado aqui .
Enquanto investigava o problema, notei que a NetworkVisitstabela tinha aproximadamente 2.000 rowgroups, com cerca de 800 deles em estado aberto e nenhum perto do máximo permitido (1048576). Aqui está uma pequena amostra do que eu estava vendo:
Executei uma reorganização no índice, que comprimiu todos, exceto 1 rowgroup, mas esta manhã verifiquei novamente e novamente temos vários rowgroups abertos - aquele que foi criado ontem após a reorganização, depois 3 outros criados aproximadamente na época da exclusão trabalho correu:
TableName IndexName type_desc state_desc total_rows deleted_rows created_time
NetworkVisits CCI_NetworkVisits CLUSTERED COLUMNSTORE OPEN 36754 0 2019-12-18 18:30:54.217
NetworkVisits CCI_NetworkVisits CLUSTERED COLUMNSTORE OPEN 172103 0 2019-12-18 20:02:06.547
NetworkVisits CCI_NetworkVisits CLUSTERED COLUMNSTORE OPEN 132628 0 2019-12-19 04:03:10.713
NetworkVisits CCI_NetworkVisits CLUSTERED COLUMNSTORE OPEN 397718 0 2019-12-19 08:02:13.063
Estou tentando determinar o que possivelmente pode estar causando isso para criar novos rowgroups em vez de usar o existente.
É possivelmente pressão de memória ou contenção entre a inserção e a exclusão? Esse comportamento está documentado em algum lugar?
Estamos executando o SQL Server 2017 CU 16 Enterprise Edition neste servidor.
O INSERTé MAXDOP 0, o DELETEé MAXDOP 48. Os únicos rowgroups fechados são os do inicial BULKLOADe depois do REORG_FORCEDque eu fiz ontem, então os motivos de trim sys.dm_db_column_store_row_group_physical_statssão REORGe NO_TRIMrespectivamente. Não há rowgroups fechados além desses. Não há atualizações sendo executadas nesta tabela. Calculamos em média cerca de 520 execuções por minuto na instrução insert. Não há particionamento na mesa.
Estou ciente de inserções de gotejamento. Fazemos a mesma coisa em outros lugares e não estamos enfrentando o mesmo problema com vários grupos de linhas abertas. Nossa suspeita é que tenha a ver com a exclusão. Cada grupo de linhas recém-criado está próximo ao horário do trabalho de exclusão agendado. Existem apenas dois armazenamentos delta mostrando linhas excluídas. Na verdade, não excluímos muitos dados desta tabela, por exemplo, durante uma execução ontem, ela excluiu 266 linhas.
