sys.dm_tran_version_store_space_usage relata sempre zero espaço usado

Eu estava aprendendo sobre RCSI quando descobri algo estranho no Banco de Dados SQL do Azure.

O DMV sys.dm_tran_version_store_space_usagesempre relata 0 como o espaço usado pelo armazenamento de versão, mesmo se eu executar uma carga de trabalho CRUD antes.

Para demonstrar esse comportamento, criei um pequeno teste.

-- Server info
select @@version as sql_version;

-- Database info
select
    is_read_committed_snapshot_on,
    snapshot_isolation_state_desc
from sys.databases
where database_id = db_id();

-- Just to be sure the current database has its version store empty
select reserved_page_count as pre_workload_space_count
from sys.dm_tran_version_store_space_usage
where database_id = db_id();

-- Test workload
drop table if exists RCSI_TEST;

create table RCSI_TEST (
    id uniqueidentifier default newid()
);
go

insert into RCSI_TEST default values;
go 100

update RCSI_TEST
set id = newid();

delete from RCSI_TEST;

-- Metrics
select reserved_page_count as post_workload_page_count
from sys.dm_tran_version_store_space_usage
where database_id = db_id();

waitfor delay '00:01:30'; -- Just to be sure! ;)

select reserved_page_count as post_cleaning_space_count
from sys.dm_tran_version_store_space_usage
where database_id = db_id();

Executei este script no SQL Server 2019 Developer Edition (no Docker) e em um Banco de Dados SQL do Azure (camada S0, 10DTU) e aqui estão os resultados.

SQL Server 2019

sql_version
Microsoft SQL Server 2019 (RTM-CU8) (KB4577194) - 15.0.4073.23 (X64)Sep 23 2020 16:03:08    Copyright (C) 2019 Microsoft Corporation    Developer Edition (64-bit) on Linux (Ubuntu 18.04.5 LTS) <X64>

is_read_committed_snapshot_on   snapshot_isolation_state_desc
1                               ON

pre_workload_space_count
0

post_workload_page_count
8

post_cleaning_space_count
0

Banco de Dados SQL do Azure

sql_version
Microsoft SQL Azure (RTM) - 12.0.2000.8     Oct  1 2020 18:48:35    Copyright (C) 2019 Microsoft Corporation

is_read_committed_snapshot_on   snapshot_isolation_state_desc
1                               ON

pre_workload_space_count
0

post_workload_page_count
0

post_cleaning_space_count
0

O SQL Server 2019 parece se comportar corretamente, relatando 8 páginas de dados no armazenamento de versão logo após a carga de trabalho e, em seguida, limpo após um minuto ou mais. No Banco de Dados SQL do Azure, no entanto, o espaço usado é sempre zero! Isso é um comportamento correto? O que isso significa?

Books Online relata que esse DMV é compatível com o SQL Server e o Banco de Dados SQL do Azure, mas também diz "A consulta a seguir pode ser usada para determinar o espaço consumido em tempdb, por armazenamento de versão de cada banco de dados em uma instância do SQL Server. " . Tanto quanto sei, os Bancos de Dados SQL do Azure têm um escopo limitado para sua instância pai por design. Essa pode ser a causa raiz?

https://learn.microsoft.com/it-it/sql/relational-databases/system-dynamic-management-views/sys-dm-tran-version-store-space-usage?view=sql-server-ver15

Eu sei que os Bancos de Dados SQL do Azure são executados em RCSI por padrão e também que eles têm uma quantidade fixa de espaço tempdb com base na camada que você obtém, então eu estava preocupado em preencher isso com transações de longa duração ou outros processos mantendo muitos registros no armazenamento de versão por muito tempo. Mas eu não posso gerenciar algo que não posso medir, certo?