Eu preciso escrever um procedimento de armazenamento para atualizar a referência de link em meu banco de dados. O link pode estar contido em alguns campos nvarchar que contêm JSONs (que podem conter alguns URLs).
Para isso atualizo as tabelas em lotes de 8129 itens por iteração, para que a máquina não trave (em teoria).
Mas agora o código parece travar de qualquer maneira, não imprime nenhuma mensagem e o procedimento continua rodando (sem afetar nenhum dado) por muitos minutos, até que eu tenha que matar o procedimento (que por enquanto parece não afetar nenhum dado) .
Se eu tentar usar a mesma lógica em um exemplo de brinquedo, não tenho problemas, então acho que meu problema se deve ao fato de a tabela ser grande (algumas centenas de milhares de linhas).
Aqui o exemplo mínimo que está funcionando, exatamente o mesmo código na tabela maior trava aparentemente sem fazer nada (testado com SQL Server 2019).
Código do procedimento:
ALTER PROCEDURE [dbo].[SiteUrlChangeURL]
@FullOldUrl nvarchar(500),
@FullNewUrl nvarchar(500)
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
SET @FullOldUrl = ISNULL(@FullOldUrl,'');
SET @FullNewUrl = ISNULL(@FullNewUrl,'');
IF ( LEN(@FullOldUrl) <= 0 OR LEN(@FullNewUrl) <= 0 )
BEGIN
PRINT('Invalid parameters');
RETURN 1;
END
--ARTICLE
RAISERROR ('updating articles',0,1) WITH NOWAIT;
WHILE 1=1
BEGIN
UPDATE TOP (8196) [dbo].[tbl_ana_Articles]
SET [_ATTRIBUTES] = REPLACE([_ATTRIBUTES] , @FullOldUrl, @FullNewUrl)
,[_DOCUMENTS] = REPLACE([_DOCUMENTS] , @FullOldUrl, @FullNewUrl)
,[_SEO] = REPLACE([_SEO] , @FullOldUrl, @FullNewUrl)
,[_TRANSLATIONS] = REPLACE([_TRANSLATIONS] , @FullOldUrl, @FullNewUrl)
,[_TAGS] = REPLACE([_TAGS] , @FullOldUrl, @FullNewUrl)
,[_NOTES] = REPLACE([_NOTES] , @FullOldUrl, @FullNewUrl)
WHERE
[_ATTRIBUTES] like '%' + @FullOldUrl + '%' OR
[_DOCUMENTS] like '%' + @FullOldUrl + '%' OR
[_SEO] like '%' + @FullOldUrl + '%' OR
[_TRANSLATIONS] like '%' + @FullOldUrl + '%' OR
[_TAGS] like '%' + @FullOldUrl + '%' OR
[_NOTES] like '%' + @FullOldUrl + '%'
IF (@@ROWCOUNT <= 0)
BEGIN
BREAK;
END
END
RETURN 0;
Exemplo :
CREATE TABLE [dbo].[tbl_ana_Articles](
[ID] [int] IDENTITY(1,1) NOT NULL,
[ID_BRAND] [int] NOT NULL,
[CODE] [nvarchar](40) NOT NULL,
[CODFOR] [nvarchar](40) NOT NULL,
[COD_ALT01] [nvarchar](50) NOT NULL,
[COD_ALT02] [nvarchar](50) NOT NULL,
[COD_ALT03] [nvarchar](50) NOT NULL,
[ID_UOM] [int] NOT NULL,
[IS_ACTIVE] [bit] NOT NULL,
[_ATTRIBUTES] [nvarchar](max) NOT NULL,
[_DOCUMENTS] [nvarchar](max) NOT NULL,
[_SEO] [nvarchar](max) NOT NULL,
[_TRANSLATIONS] [nvarchar](max) NOT NULL,
[_TAGS] [nvarchar](max) NOT NULL,
[_NOTES] [nvarchar](max) NOT NULL,
[_METADATA] [nvarchar](max) NOT NULL,
[IS_B2B] [bit] NOT NULL,
[IS_B2C] [bit] NOT NULL,
[IS_PROMO] [bit] NOT NULL,
[IS_NEWS] [bit] NOT NULL,
[CAN_BE_RETURNED] [bit] NOT NULL,
[IS_SHIPPABLE] [bit] NOT NULL,
[HAS_SHIPPING_COSTS] [bit] NOT NULL,
[IS_PURCHEASABLE] [bit] NOT NULL,
CONSTRAINT [PK_tbl_ana_articles] PRIMARY KEY CLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
INSERT INTO [dbo].[tbl_ana_Articles]
([ID_BRAND]
,[CODE]
,[CODFOR]
,[COD_ALT01]
,[COD_ALT02]
,[COD_ALT03]
,[ID_UOM]
,[IS_ACTIVE]
,[_ATTRIBUTES]
,[_DOCUMENTS]
,[_SEO]
,[_TRANSLATIONS]
,[_TAGS]
,[_NOTES]
,[_METADATA]
,[IS_B2B]
,[IS_B2C]
,[IS_PROMO]
,[IS_NEWS]
,[CAN_BE_RETURNED]
,[IS_SHIPPABLE]
,[HAS_SHIPPING_COSTS]
,[IS_PURCHEASABLE])
VALUES
(1
,'COD1'
,'SUPPLIER1'
,'CATEGORY1'
,'CATEGORY1-BIS'
,'CATEGORY2'
,1
,1
,'{ "url" : "https://old.com" }'
,''
,''
,''
,''
,''
,''
,1
,0
,0
,0
,1
,1
,0
,1);
DECLARE @FullOldUrl AS NVARCHAR(50) = 'https://old.com';
DECLARE @FullNewUrl AS NVARCHAR(50) = 'https://new.com';
--ARTICLE
PRINT('updating articles');
WHILE 1=1
BEGIN
UPDATE TOP (8196) [dbo].[tbl_ana_Articles]
SET [_ATTRIBUTES] = REPLACE([_ATTRIBUTES] , @FullOldUrl, @FullNewUrl)
,[_DOCUMENTS] = REPLACE([_DOCUMENTS] , @FullOldUrl, @FullNewUrl)
,[_SEO] = REPLACE([_SEO] , @FullOldUrl, @FullNewUrl)
,[_TRANSLATIONS] = REPLACE([_TRANSLATIONS] , @FullOldUrl, @FullNewUrl)
,[_TAGS] = REPLACE([_TAGS] , @FullOldUrl, @FullNewUrl)
,[_NOTES] = REPLACE([_NOTES] , @FullOldUrl, @FullNewUrl)
WHERE
[_ATTRIBUTES] like '%' + @FullOldUrl + '%' OR
[_DOCUMENTS] like '%' + @FullOldUrl + '%' OR
[_SEO] like '%' + @FullOldUrl + '%' OR
[_TRANSLATIONS] like '%' + @FullOldUrl + '%' OR
[_TAGS] like '%' + @FullOldUrl + '%' OR
[_NOTES] like '%' + @FullOldUrl + '%'
IF (@@ROWCOUNT <= 0)
BEGIN
BREAK;
END
END
SELECT * FROM [dbo].[tbl_ana_Articles]
PRINT('Finished');
Aqui o plano de execução produzido pelo exemplo do brinquedo (não consigo obter o plano de execução do cenário real).
https://www.brentozar.com/pastetheplan/?id=SJhVTcMTo
Estou realmente intrigado sobre o que causou esse problema
--EDITAR:
Executei o procedimento novamente e descobri que, se deixar correr o tempo suficiente (~ 30 min), obtenho o comportamento correto. Então, aparentemente, tenho um problema de desempenho aqui. Não estou realmente interessado em desempenho aqui, porque o procedimento é usado apenas raramente (manualmente) durante a manutenção (somente se o site mudar de domínio).
Mas estou curioso para saber se cometi algum erro aqui, para obter um desempenho tão baixo
trabalhador
Posso tentar evitar acessar a tabela principal repetidamente em cada atualização, por dois motivos apresentados no plano de consulta:
Um operador de filtro porque os predicados não podem ser enviados ao lidar com tipos de dados máximos
Um carretel de mesa para proteção de Halloween
Seria potencialmente uma boa ideia fornecer alguma separação de fase manual , armazenando uma lista de chaves primárias para trabalhar em uma tabela temporária:
No mínimo, ajudaria a fornecer pistas melhores sobre qual parte da consulta é realmente lenta: encontrar os dados ou atualizar os dados.
Adicionar uma chave primária à tabela temporária também pode acelerar as coisas, mas é um cavalo para você correr.
Manter o controle dos valores atuais da chave primária como Martin sugeriu seguindo a postagem de Michael também seria útil, é claro:
Há outras coisas para experimentar também, como
PAGLOCK
dicasRECOMPILE
sobre oUPDATE
, o tamanho de cada lote, paralelismo, modo de lote na inicialSELECT
para preencher a tabela temporária, etc.Como todas as sugestões de ajuste de consulta, o sucesso ou não dependerá de uma variedade de fatores locais , como disse uma vez um pássaro sábio.