Badger's questions

A consulta a seguir funciona quando executada no console por meio do comando db2. Mas falha ao executar via DBeaver.

BEGIN NOT ATOMIC
  FOR R AS C CURSOR WITH HOLD FOR
    SELECT ROW_NUMBER() OVER() AS INDEX, ID
    FROM A_TABLE a
    WHERE a.ID BETWEEN 1 AND 1000
    ORDER BY a.ID
  DO
    UPDATE A_TABLE SET A_COL = 1 WHERE ID = R.ID;--
    IF MOD(R.INDEX, 100) = 0 THEN
      COMMIT;--
    END IF;--
  END FOR;--
  COMMIT;--
END;

DBeaver dá o seguinte resultado

Erro SQL [42601]: um token inesperado "END-OF-STATEMENT" foi encontrado após "WHERE ID = R.ID". Os tokens esperados podem incluir: "<psm_semicolon>".. SQLCODE=-104, SQLSTATE=42601, DRIVER=4.26.14

Você pode forçar o SQL Server a usar um índice na coluna computada para uma operação comutativa?

Infelizmente temos uma tabela no SQL Server da seguinte forma

CREATE TABLE [dbo].[Data](
  [ID] [int] NOT NULL,
  [ValDate] [datetime] NOT NULL,
  [ValHour] [int] NOT NULL,
  [ValMin] [int] NOT NULL,
  [Value] [float] NULL,
  [Flag_ID] [int] NOT NULL,
  CONSTRAINT [PK_Data] PRIMARY KEY CLUSTERED 
  ([ID],[ValDate],[ValHour],[ValMin]) ON [PRIMARY]
) ON [PRIMARY]

Mesmo que ValDate seja um DATETIME, ele armazena apenas a parte da data.

Alguns aplicativos antigos usando esse banco de dados fazem a seguinte consulta

SELECT ID, ValDate, ValHour, ValMin, Value
FROM DATA
WHERE ID = @id 
  AND @start < DATEADD(minute, ValMin, DATEADD(hour, ValHour, ValDate))
  AND DATEADD(minute, ValMin, DATEADD(hour, ValHour, ValDate)) <= @end

Isso fica mais lento com muitos dados, pois o SQL não pode usar as datas especificadas na cláusula WHERE para buscar e deve varrer cada entrada da tabela com ID = @id para encontrar todas as linhas.

Não podemos alterar os aplicativos, então decidi adicionar uma coluna computada e colocar um INDEX nela

ALTER TABLE dbo.Data ADD ComputedDateTime AS
  DATEADD(minute, ValMin, DATEADD(hour, ValHour, ValDate))
GO
CREATE NONCLUSTERED INDEX [Data_ComputedDateTime_IDX] ON [dbo].[Data]
  ([ComputedDateTime], [ID])
INCLUDE ([ValDate], [ValHour], [ValMin], [Value])

Isso torna a consulta original rápida, mas se eu mudar a ordem dos DATEADD's, adicionando o minuto à data e depois a hora o índice não é utilizado.

Então, suponho que isso seja porque o SQL Server não percebe que as operações são comutativas, ou seja (data + hora) + minuto = (data + minuto) + hora

Existe alguma maneira de acelerar os dois pedidos de computação, sem criar duas colunas computadas e dois índices?