Diversão com compressão (columnstore) em uma mesa muito grande – parte 3

• particionou a tabela em 8 partições (uma por núcleo);
• coloque o arquivo de dados de cada partição em seu próprio grupo de arquivos; e,
• defina a compactação de arquivo em todas as partições, exceto a "ativa".

ALTER TABLE dbo.BatchQueue ADD 
  RowsAdded int,
  StartTime datetime2, 
  EndTime   datetime2;

CREATE TABLE dbo.OpAffinity
(
  SchedulerID int NOT NULL,
  SessionID   int NULL,
  CONSTRAINT  PK_OpAffinity PRIMARY KEY CLUSTERED (SchedulerID)
);

CREATE PROCEDURE dbo.DoMyBatch
  @PartitionID   int,    -- pass in 1 through 8
  @BatchID       int     -- pass in 1 through 4
AS
BEGIN
  DECLARE @BatchSize       bigint, 
          @MinID           bigint, 
          @MaxID           bigint, 
          @rc              bigint,
          @ThisSchedulerID int = 
          (
            SELECT scheduler_id 
	      FROM sys.dm_exec_requests 
    	      WHERE session_id = @@SPID
          );
 
  -- try to get the requested scheduler, 0-based
  IF @ThisSchedulerID <> @PartitionID - 1 
  BEGIN
    -- surface the scheduler we got to the application, but force a delay
    RAISERROR('Got wrong scheduler %d.', 11, 1, @ThisSchedulerID);
    WAITFOR DELAY '00:00:05';
    RETURN -3;
  END
  ELSE
  BEGIN
    -- we are on our scheduler, now serializibly make sure we're exclusive
    INSERT Utility.dbo.OpAffinity(SchedulerID, SessionID)
      SELECT @ThisSchedulerID, @@SPID
        WHERE NOT EXISTS 
        (
          SELECT 1 FROM Utility.dbo.OpAffinity WITH (TABLOCKX) 
            WHERE SchedulerID = @ThisSchedulerID
        );
 
    -- if someone is already using this scheduler, raise roar:
    IF @@ROWCOUNT <> 1
    BEGIN
      RAISERROR('Wrong scheduler %d, try again.',11,1,@ThisSchedulerID) WITH NOWAIT;
      RETURN @ThisSchedulerID;
    END
 
    -- checkpoint twice to clear log
    EXEC OCopy.sys.sp_executesql N'CHECKPOINT; CHECKPOINT;';
 
    -- get our range of rows for the current batch
    SELECT @MinID = MinID, @MaxID = MaxID
      FROM Utility.dbo.BatchQueue 
      WHERE PartitionID = @PartitionID
        AND BatchID = @BatchID
        AND StartTime IS NULL;
 
    -- if we couldn't get a row here, must already be done:
    IF @@ROWCOUNT <> 1
    BEGIN
      RAISERROR('Already done.', 11, 1) WITH NOWAIT;
      RETURN -1;
    END
 
    -- update the BatchQueue table to indicate we've started:
    UPDATE msdb.dbo.BatchQueue 
      SET StartTime = sysdatetime(), EndTime = NULL
      WHERE PartitionID = @PartitionID
        AND BatchID = @BatchID;
 
    -- do the work - copy from Original to Partitioned
    INSERT OCopy.dbo.tblPartitionedCCI 
      SELECT * FROM OCopy.dbo.tblOriginal AS o
        WHERE o.CostID >= @MinID AND o.CostID <= @MaxID
        OPTION (MAXDOP 1); -- don't want parallelism here!
 
    /*
        You might think, don't I want a TABLOCK hint on the insert, 
        to benefit from minimal logging? I thought so too, but while 
        this leads to a BULK UPDATE lock on rowstore tables, it is a 
        TABLOCKX with columnstore. This isn't going to work well if 
        we want to have multiple processes inserting into separate 
        partitions simultaneously. We need a PARTITIONLOCK hint!
    */
 
    SET @rc = @@ROWCOUNT;
 
    -- update BatchQueue that we've finished and how many rows:
    UPDATE Utility.dbo.BatchQueue 
      SET EndTime = sysdatetime(), RowsAdded = @rc
      WHERE PartitionID = @PartitionID
        AND BatchID = @BatchID;
 
    -- remove our lock to this scheduler:
    DELETE Utility.dbo.OpAffinity 
      WHERE SchedulerID = @ThisSchedulerID 
        AND SessionID = @@SPID;
  END
END

EXEC dbo.DoMyBatch @PartitionID = /* PartitionID - 1 through 8 */, @BatchID = 1;
EXEC dbo.DoMyBatch @PartitionID = /* PartitionID - 1 through 8 */, @BatchID = 2;
EXEC dbo.DoMyBatch @PartitionID = /* PartitionID - 1 through 8 */, @BatchID = 3;
EXEC dbo.DoMyBatch @PartitionID = /* PartitionID - 1 through 8 */, @BatchID = 4;

Monitoramento

SELECT r.session_id, r.[status], r.scheduler_id, partition_id = o.SchedulerID + 1, 
  r.logical_reads, r.total_elapsed_time, r.last_wait_type, longest_wait_type = 
  (
    SELECT TOP (1) wait_type 
      FROM sys.dm_exec_session_wait_stats
      WHERE session_id = r.session_id AND wait_type <> 'WAITFOR' 
      ORDER BY wait_time_ms - signal_wait_time_ms DESC
  )
  FROM sys.dm_exec_requests AS r 
  INNER JOIN Utility.dbo.OpAffinity AS o
      ON o.SessionID = r.session_id
  WHERE r.command = N'INSERT'
  ORDER BY r.scheduler_id;
 
SELECT SchedulerID = PartitionID - 1, Duration = DATEDIFF(SECOND, StartTime, EndTime), *
  FROM Utility.dbo.BatchQueue WITH (NOLOCK) 
  WHERE StartTime IS NOT NULL -- AND EndTime IS NULL
  ORDER BY PartitionID;

Outros testes

• Copiar os dados para a nova tabela sem tentar controlar a afinidade. Eu tirei a lógica de afinidade do procedimento e deixei toda a coisa de "espero que você consiga o programador certo" ao acaso. Isso levou mais tempo porque, com certeza, o empilhamento do agendador realizou ocorrer. Por exemplo, neste ponto específico, o agendador 3 estava executando dois processos, enquanto o agendador 0 estava fazendo uma pausa para o almoço:
  Onde você está, agendador número 0?
• Aplicando a página ou linha compressão (tanto online/offline) para a fonte antes a cópia com afinidade (offline), para ver se compactar os dados primeiro pode acelerar o destino. Observe que a cópia também pode ser feita online, mas, como o int de Andy Mallon para bigint conversão, requer alguma ginástica. Observe que, neste caso, não podemos aproveitar a afinidade da CPU (embora pudéssemos se a tabela de origem já estivesse particionada). Fui esperto e fiz um backup da fonte original e criei um procedimento para reverter o banco de dados de volta ao seu estado inicial. Muito mais rápido e fácil do que tentar reverter para um estado específico manualmente.
  

  -- refresh source, then do page online:
  ALTER TABLE dbo.tblOriginal REBUILD WITH (DATA_COMPRESSION = PAGE, ONLINE = ON);
  -- then run SQLQueryStress
   
  -- refresh source, then do page offline:
  ALTER TABLE dbo.tblOriginal REBUILD WITH (DATA_COMPRESSION = PAGE, ONLINE = OFF);
  -- then run SQLQueryStress
   
  -- refresh source, then do row online:
  ALTER TABLE dbo.tblOriginal REBUILD WITH (DATA_COMPRESSION = ROW, ONLINE = ON);
  -- then run SQLQueryStress
   
  -- refresh source, then do row offline:
  ALTER TABLE dbo.tblOriginal REBUILD WITH (DATA_COMPRESSION = ROW, ONLINE = OFF);
  -- then run SQLQueryStress

• E, finalmente, reconstruir primeiro o índice clusterizado no esquema de partição e, em seguida, construir o índice columnstore clusterizado em cima disso. A desvantagem deste último é que, no SQL Server 2017, você não pode executá-lo online… mas poderá fazê-lo em 2019.
  Aqui precisamos eliminar a restrição PK primeiro; você não pode usar DROP_EXISTING , pois a restrição exclusiva original não pode ser imposta pelo índice columnstore clusterizado e você não pode substituir um índice clusterizado exclusivo por um índice clusterizado não exclusivo.
  Msg 1907, Level 16, State 1
  Não é possível recriar o índice 'pk_tblOriginal'. A nova definição de índice não corresponde à restrição imposta pelo índice existente.
  Todos esses detalhes fazem deste um processo de três etapas, apenas a segunda etapa online. A primeira etapa eu só testei explicitamente OFFLINE; que foi executado em três minutos, enquanto ONLINE Parei depois de 15 minutos. Uma daquelas coisas que talvez não devesse ser uma operação de tamanho de dados em ambos os casos, mas deixarei isso para outro dia.
  
  

  ALTER TABLE dbo.tblOriginal DROP CONSTRAINT PK_tblOriginal WITH (ONLINE = OFF);
  GO
   
  CREATE CLUSTERED INDEX CCI_tblOriginal -- yes, a bad name, but only temporarily
    ON dbo.tblOriginal(OID)
    WITH (ONLINE = ON)
    ON PS_OID (OID); -- this moves the data
   
   
  CREATE CLUSTERED COLUMNSTORE INDEX CCI_tblOriginal
    ON dbo.tblOriginal
    WITH                 
    (
      DROP_EXISTING = ON,
      DATA_COMPRESSION = COLUMNSTORE_ARCHIVE ON PARTITIONS (1 TO 7),
      DATA_COMPRESSION = COLUMNSTORE ON PARTITIONS (8)
      -- in 2019, CCI can be ONLINE = ON as well
    )
    ON PS_OID (OID);
  GO

Resultados

• Se sua prioridade é economizar espaço o mais rápido possível , sua melhor aposta é aplicar a compactação de linha no local. Se você quiser minimizar a interrupção, use online; se você quiser otimizar a velocidade, use offline.
• Se você deseja maximizar a compactação sem interrupção , você pode atingir uma redução de armazenamento de 90% sem nenhuma interrupção, usando a compactação de página online.
• Se você quiser maximizar a compactação e a interrupção, tudo bem , copie os dados para uma nova versão particionada da tabela, com um índice columnstore clusterizado e use o processo de afinidade descrito acima para migrar os dados. (E, novamente, você pode eliminar essa interrupção se for um planejador melhor do que eu.)