Eu apenas altero o tamanho da coluna, por que o aviso "alterar um tipo de dados de coluna resulta em um índice muito grande"?
Qual é o conceito por trás disso, algum artigo relevante para eu entender isso?
De acordo com meu estudo, descobri que muitas pessoas mencionam que o índice de cobertura ajudaria a reduzir o bloqueio de "pesquisa de chave". Eu estava ansioso para testá-lo e entendê-lo, mas meus testes não mostraram o resultado esperado.
Primeiro eu executo o código abaixo, tento atualizar a tabela na primeira transação sem commit e depois em outra sessão, executo uma query para selecionar o col2 e col3 da tableA. De acordo com o livro, a segunda sessão será bloqueada pela primeira sessão.
-- Create the table for testing
CREATE TABLE [TableA]
(
[col1] INT,
[col2] INT,
[col3] INT,
[col4] CHAR(100) DEFAULT('abc') NOT NULL
);
GO
DECLARE @int INT;
SET @int = 1;
-- Load data into the table
WHILE (@int <= 1000)
BEGIN
INSERT INTO [TableA]
([col1], [col2], [col3], [col4])
VALUES (@int*2, @int*2, @int*2, @int*2);
SET @int = @int + 1;
END
GO
CREATE CLUSTERED INDEX [cidx_TableA]
ON [TableA] ([col1]);
-- Create a non-clustered index
CREATE NONCLUSTERED INDEX [idx_TableA_col2]
ON [TableA] ([col2]);
GO
BEGIN TRANSACTION
UPDATE [TableA] SET col3=999 WHERE Col2=4
--Rollback
--ON another session, I query this.
SELECT [col2],col3 FROM [TableA]
WHERE [col2]=66
option (recompile)
A segunda sessão fez usando a chave de pesquisa para o índice do cluster cidx_TableA e retornou o resultado, espero que não retorne nenhum resultado porque suponha que ele travaria pela atualização na primeira sessão. Por quê?
Ainda não criei o índice de cobertura, pois não fez nenhum bloqueio. Então, o índice de cobertura realmente funcionou?
Eu tenho 1 replicação de transação (topologia ponto a ponto). Depois de configurar, descobri que os dados na tabela 2 eram diferentes.
A primeira tabela de pares [VPMYN204].[AdventureWorks2019].[Person].[AddressType] tem 6 linhas. E a segunda tabela [AdventureWorks2019].[Person].[AddressType] tem 7 linhas.