user2652379's questions

Atualmente estou projetando uma tabela de transações. Percebi que será necessário calcular os totais em execução para cada linha e isso pode ser lento no desempenho. Então criei uma tabela com 1 milhão de linhas para fins de teste.

CREATE TABLE [dbo].[Table_1](
    [seq] [int] IDENTITY(1,1) NOT NULL,
    [value] [bigint] NOT NULL,
 CONSTRAINT [PK_Table_1] PRIMARY KEY CLUSTERED 
(
    [seq] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

E tentei obter 10 linhas recentes e seus totais em execução, mas demorou cerca de 10 segundos.

--1st attempt
SELECT TOP 10 seq
    ,value
    ,sum(value) OVER (ORDER BY seq) total
FROM Table_1
ORDER BY seq DESC

--(10 rows affected)
--Table 'Worktable'. Scan count 1000001, logical reads 8461526, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Table 'Table_1'. Scan count 1, logical reads 2608, physical reads 516, read-ahead reads 2617, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--
--(1 row affected)
--
-- SQL Server Execution Times:
--   CPU time = 8483 ms,  elapsed time = 9786 ms.

Suspeitei TOPpelo motivo do desempenho lento do plano, então alterei a consulta assim e demorou cerca de 1 a 2 segundos. Mas acho que isso ainda é lento para a produção e me pergunto se isso pode ser melhorado ainda mais.

--2nd attempt
SELECT *
    ,(
        SELECT SUM(value)
        FROM Table_1
        WHERE seq <= t.seq
        ) total
FROM (
    SELECT TOP 10 seq
        ,value
    FROM Table_1
    ORDER BY seq DESC
    ) t
ORDER BY seq DESC

--(10 rows affected)
--Table 'Table_1'. Scan count 11, logical reads 26083, physical reads 1, read-ahead reads 443, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--
--(1 row affected)
--
-- SQL Server Execution Times:
--   CPU time = 1422 ms,  elapsed time = 1621 ms.

Minhas perguntas são:

• Por que a consulta da 1ª tentativa é mais lenta que a 2ª?
• Como posso melhorar ainda mais o desempenho? Eu também posso mudar esquemas.

Apenas para esclarecer, ambas as consultas retornam o mesmo resultado abaixo.

Eu sou novo no backup de banco de dados. Acabei de aprender sobre os tipos de backup com esta pergunta (Link) . Depois de ler the differential backup is cumulative since the last full, fiquei curioso se vários backups completos e diferenciais não são obrigatórios.

Por exemplo, eu tenho backups assim:

full_backup_2018_05_09_000000.bak
tran_backup_2018_05_09_000500.trn
tran_backup_2018_05_09_001000.trn
diff_backup_2018_05_09_001500.bak
tran_backup_2018_05_09_002000.trn
tran_backup_2018_05_09_002500.trn
diff_backup_2018_05_09_003000.bak
tran_backup_2018_05_09_003500.trn
tran_backup_2018_05_09_004000.trn
diff_backup_2018_05_09_004500.bak
tran_backup_2018_05_09_005000.trn
tran_backup_2018_05_09_005500.trn
full_backup_2018_05_09_010000.bak
...

Qual é a diferença entre isso e usar um backup completo e backups de log de transações como este?

full_backup_2018_05_09_000000.bak
tran_backup_2018_05_09_000500.trn
tran_backup_2018_05_09_001000.trn
tran_backup_2018_05_09_001500.trn
tran_backup_2018_05_09_002000.trn
tran_backup_2018_05_09_002500.trn
tran_backup_2018_05_09_003000.trn
tran_backup_2018_05_09_003500.trn
tran_backup_2018_05_09_004000.trn
tran_backup_2018_05_09_004500.trn
tran_backup_2018_05_09_005000.trn
tran_backup_2018_05_09_005500.trn
tran_backup_2018_05_09_010000.trn
...

Não usar restrições FK é a regra incontável da minha empresa. As restrições FK são usadas apenas ao projetar ERD e não ao criar tabelas.

De acordo com meu sênior, na prática, esses são obstáculos que consomem muito tempo quando estamos lidando com questões urgentes. Ele diz que quando precisamos usar instruções INSERT/UPDATE/DELETE imediatamente, as restrições bloqueiam a execução dessas instruções e escrever instruções enquanto mantém as restrições também consome tempo. Eu até ouvi que muitas outras empresas estão fazendo isso.

Embora eu entenda as dificuldades, não tenho certeza se essa é uma boa maneira, pois é bem oposta ao meu entendimento do DB. Essa empresa é meu primeiro emprego também, então não sei como outras empresas lidam com isso.

De forma prática, qual é a sua opinião sobre isso? Isso pode ser justificado? Existem maneiras melhores? Como outras empresas estão fazendo sobre este assunto?

ATUALIZAÇÃO: Parece que é uma abordagem bastante comum para empresas sul-coreanas. Perguntei a alguns outros seniores que trabalharam para outras empresas, e a maioria deles está dizendo que todos estão fazendo assim. E até um deles trabalhava para uma empresa financeira! Interessante...

Eu mudei esta consulta

SELECT ...
FROM linkedServer.DB.Schema.Table1 t1
LEFT JOIN linkedServer.DB.Schema.Table2 t2 ON t1.ORDER_ID = t2.ORDER_ID
WHERE t1.BRANCH_ID NOT IN (
        '009991', '009992', '009993', '009994', '009995', '009996', '009999', '900001', 
        '900002', '900003', '900004', '900005', '900006', '900007', '900008', '999991', 
        '999992', '999993', '999994', '999995'
        )
GROUP BY ...

nisso

SELECT ...
FROM linkedServer.DB.Schema.Table1 t1
LEFT JOIN linkedServer.DB.Schema.Table2 t2 ON t1.ORDER_ID = t2.ORDER_ID
WHERE t1.BRANCH_ID NOT IN (
        SELECT b.BRANCH_ID
        FROM TB_BRANCH b --25 rows in total
        WHERE b.START_DT = '99999999' --the result of this sub-query is fewer than list above.
        )
GROUP BY ...

então o desempenho caiu.

Por que essa grande mudança no plano de execução está acontecendo? Como posso evitar a queda de desempenho ao usar uma subconsulta na cláusula IN?