O tamanho do arquivo MDF não está sendo atualizado após adicionar arquivo(s) de log transacional no SQL 2022

Estou trabalhando na migração do SQL Server do SQL 2016 para o SQL 2022.

Tenho um processo em que, após o banco de dados ser restaurado (para o estado "Standby / Somente leitura") da fita completa (de um terceiro fornecedor), devo adicionar cada arquivo de log por hora (bak) a esse banco de dados "Standby / Somente leitura".

Eu estava tentando executar o código T-SQL que estava funcionando no SQL 2016 (nos últimos 4 anos) neste novo ambiente (SQL 2022), e a primeira mensagem de erro que recebi foi nesta parte:

 EXEC master.sys.xp_cmdshell @cmd 

Então, pesquisei no Google e executei este código:

 EXEC sp_configure 'show advanced options', 1
 GO
 RECONFIGURE
 GO
 EXEC sp_configure 'xp_cmdshell', 1
 GO
 RECONFIGURE
 GO

Quando executei o código, parece não haver nenhuma mensagem de erro, mas não vejo o arquivo de log do banco de dados aumentar de tamanho.

Estou colocando todo o meu código T-SQL aqui para referência:

USE Master; 
GO  
SET NOCOUNT ON 

-- 1 - Variable declaration 
DECLARE @dbName sysname
DECLARE @fileName sysname
DECLARE @standby sysname
DECLARE @backupPath NVARCHAR(500) 
DECLARE @cmd NVARCHAR(500) 
DECLARE @fileList TABLE (backupFile NVARCHAR(255)) 
DECLARE @lastFullBackup NVARCHAR(500) 
DECLARE @lastDiffBackup NVARCHAR(500) 
DECLARE @backupFile NVARCHAR(500) 

-- 2 - Initialize variables 
SET @dbName = 'us_xxxx_multi_replica1' 
SET @fileName = 'LOG_us_xxxx_multi_replica' 
SET @backupPath = 'F:\Yesterday\' 
SET @standby = 'F:\us_xxxx_multi_replica_RollbackUndo_2024-09-17_19-33-23.bak'

-- 3 - get list of files 
SET @cmd = 'DIR /b "' + @backupPath + '"'

INSERT INTO @fileList(backupFile) 
EXEC master.sys.xp_cmdshell @cmd 

-- 5 - check for log backups 
DECLARE backupFiles CURSOR FOR  
   SELECT backupFile  
   FROM @fileList 
   WHERE backupFile LIKE '%.bak'  
   AND backupFile LIKE @fileName + '%' 

OPEN backupFiles  

-- Loop through all the files for the database  
FETCH NEXT FROM backupFiles INTO @backupFile  

WHILE @@FETCH_STATUS = 0  
BEGIN  
   SET @cmd = 'RESTORE LOG [' + @dbName + '] FROM DISK = '''  
       + @backupPath + @backupFile + ''' WITH STANDBY = ''' + @standby + ''''

   FETCH NEXT FROM backupFiles INTO @backupFile  

EXEC (@cmd)

END 

CLOSE backupFiles  
DEALLOCATE backupFiles  

Abaixo está um exemplo de resultado após o processamento no SQL 2022 (com o qual estou tendo um problema):

  Processed 0 pages for database 'us_xxxx_multi_replica', file 'us_template_pccmulti_rrdb_replica' on file 1.
  Processed 952 pages for database 'us_xxx_multi_replica', file 'us_template_pccmulti_rrdb_replica_log' on file 1.
  System objects could not be updated in database 'us_xxxx_multi_replica' because it is read-only.
  System objects could not be updated in database 'us_xxxx_multi_replica' because it is read-only.
  RESTORE LOG successfully processed 952 pages in 1.845 seconds (4.029 MB/sec).

Abaixo está um exemplo de resultado após execução no SQL 2016 (onde não há problema):

Processed 2336 pages for database 'us_xxx_multi_replica', file 'us_template_pccmulti_rrdb_replica_log' on file 1. 
System objects could not be updated in database 'us_xxx_multi_replica' because it is read-only. 
System objects could not be updated in database 'us_xxx_multi_replica' because it is read-only. 
RESTORE LOG successfully processed 2336 pages in 0.531 seconds (34.361 MB/sec). 
Processed 0 pages for database 'us_xxx_multi_replica', file 'us_template_pccmulti_rrdb_replica' on file 1.

Qual pode ser o problema?

BTW, quando o SQL 2022 foi instalado nesta VM, o SQL 2019 já estava instalado (veio com a VM). Nossa TI instalou o SQL 2022 manualmente, então estou me perguntando se há algum tipo de problema de permissão/configuração que não foi definido corretamente.

Porque quando executei este código T-SQL no SQL 2019, não encontrei o problema de

EXEC master.sys.xp_cmdshell @cmd 

desde o começo.

Atualizar:

1. Não descobri o motivo pelo qual tive que resolver o problema com 'xp_cmdshell' no SQL 2022 (mas não no SQL 2019), mas está funcionando bem.

2. Percebi que o arquivo ldf no SQL 2016 não mostrou aumento de tamanho, mas apenas aumento no arquivo mdf. Então, acho que não preciso me preocupar com nenhuma alteração no tamanho do arquivo ldf.

3. Consegui ver as diferenças verificando os dados em si.