Tenho uma consulta propensa à sensibilidade de parâmetros e que sofre com seu parâmetro com valor de tabela. Sou preguiçoso e só quero resolver isso com dicas de consulta. Quando estou preguiçoso, consigo resolver a sensibilidade de parâmetros com OPTION (OPTIMIZE FOR UNKNOWN). Isso me gera três perguntas muito relacionadas:

1. Tem algum impacto em variáveisOPTION (OPTIMIZE FOR UNKNOWN) ​​com valor de tabela ?
2. Tem algum impacto nos parâmetrosOPTION (OPTIMIZE FOR UNKNOWN) com valor de tabela ?
3. Quais outras dicas de consulta podem ser usadas para influenciar estimativas de cardinalidade para parâmetrosOPTION(RECOMPILE) com valores de tabela ?

Tanto meus próprios experimentos quanto a documentação sugerem que essa é uma causa perdida. Parâmetros com valor de tabela estão sujeitos à detecção de parâmetros, mas tudo o que é detectado é a cardinalidade, então OPTION (OPTIMIZE FOR UNKNOWN)não deve fazer nada.

Quanto à questão de usar outras dicas de tabela, sei que posso alterar a estimativa para operações no parâmetro com valor de tabela (por exemplo, OPTION (USE HINT ('ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES')), mas não acho que as dicas possam influenciar a estimativa de cardinalidade para o parâmetro em si.

Este artigo clássico sobre segurança de concorrência foi claramente projetado para realizar o upsert de apenas uma linha por vez. Na minha situação, tenho uma entrada com valor de tabela e quero realizar o upsert de cada linha de forma segura em termos de concorrência. Sei que isso nem sempre é possível, mas quero chegar o mais perto possível. MERGEParece uma solução natural, mas desconfio dela e, na verdade, estou em uma situação em que é propensa a bugs . As duas abordagens restantes no artigo de Michael J. Swart são:

1. Dentro de uma transação com dicas de bloqueio (atualização mais comum)

CREATE PROCEDURE s_AccountDetails_Upsert ( @Email nvarchar(4000), @Etc nvarchar(max) )
AS 
SET XACT_ABORT ON;
BEGIN TRAN
 
  UPDATE TOP (1) dbo.AccountDetails WITH (UPDLOCK, SERIALIZABLE)
     SET Etc = @Etc
   WHERE Email = @Email;
 
  IF (@@ROWCOUNT = 0)
  BEGIN      
      INSERT dbo.AccountDetails ( Email, Etc )
      VALUES ( @Email, @Etc );
  END 
COMMIT

2. Dentro de uma transação com dicas de bloqueio (inserir mais comum)

CREATE PROCEDURE s_AccountDetails_Upsert ( @Email nvarchar(4000), @Etc nvarchar(max) )
AS 
SET XACT_ABORT ON;
BEGIN TRAN
 
  INSERT dbo.AccountDetails ( Email, Etc )
  SELECT @Email, @Etc
  WHERE NOT EXISTS (
      SELECT *
      FROM dbo.AccountDetails WITH (UPDLOCK, SERIALIZABLE)
      WHERE Email = @Email
  )
 
  IF (@@ROWCOUNT = 0)
  BEGIN      
      UPDATE TOP (1) dbo.AccountDetails
      SET Etc = @Etc
      WHERE Email = @Email;
  END 
COMMIT 

Eu poderia adaptar qualquer uma delas para usar variáveis ​​de tabela (por exemplo, suspeito que IF (@@ROWCOUNT = 0)precise ser totalmente removida), mas o uso de uma entrada com valor de tabela torna óbvio que devemos preferir a primeira ou a segunda solução? Se não, com base em quê a decisão deve ser tomada?

Tenho uma tabela particionada com uma chave primária rowstore e um índice columnstore não clusterizado. A chave principal de ambos (não que a ordem das chaves importe para o columnstore) é a mesma. Ao atualizar estatísticas, o SQL Server opta regularmente por varrer o índice columnstore. Isso demora muito para o meu gosto, então tentei

UPDATE STATISTICS My_Table
WITH PERSIST_SAMPLE_PERCENT = ON, SAMPLE 3 PERCENT

Para minha surpresa, as atualizações de estatísticas ainda demoravam muito. Os planos de execução sugerem que o índice do columnstore está sendo escaneado da mesma forma que antes.

Então, tenho uma pergunta: ao ler um índice columnstore, PERSIST_SAMPLE_PERCENT é ignorado em UPDATE STATISTICS? As atualizações automáticas de estatísticas parecem compartilhar esse problema.

Atualização: Suspeito que o problema pode ser o bitmap excluído.

Tenho um cluster do SQL Server 2022 Enterprise Edition com vários AGs.

Dois dos AGs consideram diferentes instâncias primárias. Ambos consideram suas secundárias legíveis e estão corretos em pensar assim.

Além de estar nessa configuração secundária legível, nada torna nenhum dos bancos de dados em nenhuma das instâncias somente leitura. Eles não são Grupos de Disponibilidade Básica.

Aqui está o choque: quando executo DBCC CHECKCATALOGa segmentação de um banco de dados secundário legível enquanto estou conectado a uma instância que não é o primário desse banco de dados, a consulta falha assim

Msg 3906, Nível 16, Estado 8, Linha 1

Falha ao atualizar o banco de dados "DB NAME" porque o banco de dados é somente leitura.

mas DBCC CHECKDBfunciona muito bem!

Procurei muito, mas não encontrei nada útil sobre isso.

• Este problema no GitHub da Solução de Manutenção de Ola Hallengren é idêntico, mas não tem solução. Ola, em quem confio ser um especialista nisso, parece pensar que é um bug dele e não da Microsoft.
• Este commit do git sugere que seu autor, dan-andreistefan, já viu isso antes. Não encontrei nenhum problema ou PR correspondente. Dan surgiu do vazio e resolveu o problema .
• Além das limitações em BAGs, não consigo encontrar nada na documentação oficial do SQL Server sobre fazer verificações de integridade em AGs. Está apenas no guia de licenciamento.

Como posso depurar isso? Por que DBCC CHECKDB, que é um superconjunto de DBCC CHECKCATALOG, funcionaria onde DBCC CHECKCATALOGfalha?

Suponha que eu tenha um banco de dados Enterprise Edition que tenha configurações completamente padrão e nada além de tabelas rowstore normais. Sem RCSI, sem isolamento de snapshot e sem gatilhos. Suponha que nada exija versionamento de linha .

Claramente, essas suposições significam que não pagarei o custo extra de 14 bytes por linha do controle de versão de linha. No entanto, os secundários AG legíveis são executados sob isolamento SNAPSHOT e o isolamento SNAPSHOT requer controle de versão de linha. Então, se eu colocar meu banco de dados em um Availability Group e adicionar um secundário legível, quais cópias do meu banco de dados (se houver) começarão a pagar o custo de 14 bytes por linha do controle de versão de linha? Isso muda se eu tiver um secundário não legível além do secundário legível? E se eu fizer failover e failback?

A documentação relevante, vinculada anteriormente, não faz comentários sobre isso. Eu mesmo planejo executar experimentos, mas AGs são notoriamente fáceis de cometer erros e não quero tirar conclusões incorretas.

Inicie o evento estendido auto_stats, filtre algum ruído e prepare-se para monitorá-lo.

CREATE EVENT SESSION [AutoStatsTest] ON SERVER 
ADD EVENT sqlserver.auto_stats(
    WHERE ([duration]>1 AND [object_id] > 0) ) 
ADD TARGET package0.ring_buffer

ALTER EVENT SESSION [AutoStatsTest] ON SERVER
STATE = START
GO

Encontre uma tabela temporal. Eu tinha uma cópia do banco de dados StackOverflow2010 em mãos, então simplesmente versionei Voteso sistema.

ALTER TABLE Votes ADD
ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN
    CONSTRAINT DF_InsurancePolicy_ValidFrom DEFAULT SYSUTCDATETIME(),
ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN
    CONSTRAINT DF_InsurancePolicy_ValidTo DEFAULT CONVERT(DATETIME2, '9999-12-31 23:59:59.9999999'),
PERIOD FOR SYSTEM_TIME(ValidFrom, ValidTo);
GO

ALTER TABLE Votes
    SET (SYSTEM_VERSIONING = ON);
GO

Com sua tabela temporal, faça algo que acione uma atualização automática de estatísticas. Isso funcionou para mim.

SELECT TOP (1000) [BountyAmount]
FROM [StackOverflow2010].[dbo].[Votes]
WHERE [PostId] < [BountyAmount]

UPDATE [StackOverflow2010].[dbo].[Votes]
SET BountyAmount = 4*PostId

SELECT TOP (1000) [BountyAmount]
FROM [StackOverflow2010].[dbo].[Votes]
WHERE [PostId] < [BountyAmount]

Agora inspecione o XML do seu Evento Estendido

SELECT target_data
FROM sys.dm_xe_session_targets AS xet
JOIN sys.dm_xe_sessions AS xe
ON (xe.address = xet.event_session_address)
WHERE xe.name = 'AutoStatsTest'

Se você for como eu, verá alguns campos que relatam um sample_percentage de 100%.

        <data name="sample_percentage">
            <type name="int64" package="package0">
            </type>
            <value>
                100
            </value>
        </data>

Considerando a duração (800 microssegundos na minha máquina patética), eu sabia que isso era um absurdo. Ao consultar sys.dm_db_stats_properties, descobri que a porcentagem real era muito menor que 100.

/*
Save yourself the pain of writing
the stats query
and just use sp_BlitzIndex from GitHub
*/
EXEC sp_blitzindex @databasename = 'StackOverflow2010', @tablename = 'Votes'

Em resumo, parece que o Evento Estendido auto_stats relata um sample_percentage incorreto para tabelas temporais . Isso é um bug do SQL Server ou é um mal-entendido meu? Se for um mal-entendido meu, onde posso ler mais? Eventos Estendidos individuais, até onde eu sei, são muito carentes de documentação.

Só vi isso acontecer com tabelas temporais. Já o encontrei tanto no SQL Server 2022 em uma máquina real (a tabela tinha vários terabytes, então gritei quando vi uma taxa de amostragem de 100% para a estatística da chave primária) quanto na minha máquina de teste local de 2019.

Adicionar um índice columnstore parece ajudar a reproduzir isso, mas não tenho 100% de certeza.

CREATE NONCLUSTERED COLUMNSTORE INDEX IX_ColStore
on dbo.Votes
(
    Id,
    PostId
)

Tenho absoluta certeza de que há um bug real aqui. No entanto, minhas tentativas de reproduzi-lo deram resultados inconsistentes. Suspeito que você precise de uma tabela com escala TB.

Atualização final: desisto de explicar isso. As estatísticas da tabela indicam que 90 vezes mais linhas do que as exibidas no plano de execução real (capturado em tempo real enquanto estava em produção, varrendo o índice columnstore não clusterizado) foram usadas para atualizar as estatísticas. O número de linhas no plano de execução real é 10.000 vezes menor que a contagem de linhas da tabela, e o evento estendido auto_stats indica que 100% das linhas da tabela foram lidas. É impossível que todas essas informações sejam verdadeiras ao mesmo tempo.

Suspeito que o que está causando tudo isso pode ser o bitmap excluído.

É notoriamente impossível decodificar o que o ponteiro wait_resource no Evento Estendido de Saúde do Sistema significa . Mas se todas as minhas longas esperas naquele Evento Estendido por um certo período de tempo estão relatando o mesmo ponteiro, então isso indica alguma coisa?

Estou enfrentando altas PAGELATCH_SHesperas para esse período de tempo e espero que o motivo pelo qual todos os ponteiros são os mesmos esteja relacionado a isso. Não incluí o XML aqui porque tenho certeza absoluta de que não ajudará a responder à pergunta. Estou apenas tentando entender se há algum caso em que eu deva prestar atenção ao valor wait_resource neste Evento Estendido quando ele é obviamente um ponteiro.

A documentação sobre os benefícios do particionamento lista o seguinte como o primeiro benefício de desempenho do particionamento de tabelas

o otimizador de consultas pode processar consultas de junção equivalente entre duas ou mais tabelas particionadas mais rapidamente quando as colunas de particionamento são as mesmas que as colunas nas quais as tabelas são unidas.

A mesma página fala um pouco mais sobre esse tópico mais adiante , mas não chega a nada além de dizer que unir tabelas particionadas que não são particionadas exatamente da mesma forma não obtém as mesmas otimizações que unir tabelas particionadas equivalentemente. Isso é, claro, irrelevante para o que a seção anterior alegou; qualquer comparação de desempenho entre duas formas de particionar tabelas não tem nada a ver com os benefícios do particionamento quando comparado a não particionar.

Isso me faz perguntar: unir tabelas particionadas equivalentemente é mais rápido do que unir duas tabelas com a mesma chave de índice clusterizado líder? Eu ficaria feliz com uma resposta experimental ou uma que usasse a teoria relevante para chegar a uma conclusão.

Eu li sobre os internos e li muitos white papers e blogs, mas acho que não vi isso abordado em lugar nenhum. Meu entendimento dos internos me leva a concluir que a abordagem particionada deve ser mais lenta do que a abordagem não particionada. Afinal, tudo o que o particionamento realmente faz é colocar outra chave de índice na frente da sua lista de chaves. Meus próprios experimentos descobriram o mesmo.

Hoje, aprendi da maneira mais difícil que você não pode verificar a corrupção de um secundário do Basic Availability Group . Dada essa limitação, como posso saber se é seguro fazer failover de um BAG? Pelo que sei, o secundário pode estar corrompido.

Com tabelas particionadas no SQL Server, há um problema notório de desempenho importante ao usar funções min/max ou TOP. Soluções alternativas do documento da Microsoft para isso aqui . Estou confiante de que isso não foi corrigido no SQL Server 2022. A Microsoft certamente teria atualizado a lista de soluções alternativas se dar a eles mais dinheiro fosse uma solução alternativa.

No entanto, isso mudou depois do SQL Server 2022? Tenho certeza de que vi um link funcional para este item do Connect em 2024. Hoje, não consigo encontrá-lo nem mesmo nas sugestões modernas do Azure para as quais todos os itens do Connect foram migrados. Isso me sugere que algo aconteceu com esse bug de uma década nos últimos anos.

Não posso responder isso sozinho, pois não tenho acesso ao SQL Server 2025 ou a qualquer outro recurso de ponta do Azure. Ouvi dizer que versões de pré-visualização do SQL Server 2025 foram lançadas.

Assumindo o SQL Server 2022 Standard Edition no Windows, eu simplesmente não consigo ver nenhum benefício em usar Basic Availability Groups em vez do Database Mirroring. Existe algo oferecido pelo Basic Availability Groups, mas não pelo Database Mirroring?

Em ambos os casos:

• Você só pode ter 1 primário e 1 secundário
• O secundário não é legível
• Os bancos de dados não podem ser agrupados de nenhuma forma, permitindo que eles falhem juntos
• A replicação pode ser sincronizada ou assíncrona
• O reparo automático de páginas está habilitado.

As únicas diferenças que encontrei entre os dois recursos são que os Grupos de Disponibilidade Básica não podem ser atualizados para a Edição Enterprise e que o Espelhamento de Banco de Dados está oficialmente obsoleto.

Entendo que os Grupos de Disponibilidade Básica são mais difíceis de configurar do que os espelhos, mas estou perguntando apenas sobre os benefícios dos Grupos de Disponibilidade Básica em relação ao Espelhamento de Banco de Dados.

Antes do SQL Server 2016, o particionamento de índices columnstore era considerado praticamente obrigatório porque os bloqueios tomados neles durante inserções/atualizações/exclusões eram extremos. No entanto, a partir do SQL Server 2016, os bloqueios tomados em índices columnstore são muito menos intensos . Por que, então, ainda é considerado uma prática recomendada particioná-los?

Estou ciente do truque onde você pode melhorar o alinhamento trocando uma partição, construindo um índice rowstore clusterizado, substituindo esse índice por columnstore e então trocando a partição novamente. No entanto, essa é apenas uma otimização de desempenho moderada que raramente sobrevive a uma reconstrução e foi amplamente tornada redundante pelos recursos de ordenação do SQL Server 2022 .

Quando olho a documentação para Accelerated Database Recovery e Read Committed Snapshot Isolation, parece que todas as desvantagens do Accelerated Database Recovery são compartilhadas pelo Read Committed Snapshot Isolation. Então, supondo que eu já tenha o Read Committed Snapshot Isolation habilitado, quais são as desvantagens do Accelerated Database Recovery?

Suspeito que não seja coincidência que tanto o Accelerated Database Recovery quanto o Read Committed Snapshot Isolation estejam habilitados por padrão no Azure. Suponha que seja o SQL Server 2019 ou o SQL Server 2022.

Se você é bem lido sobre particionamento, então você estará completamente ciente de que particionamento não é um recurso de desempenho para índices rowstore. No entanto, sempre que vejo argumentos feitos para isso, como feito de forma mais convincente aqui por Gail Shaw , os argumentos dependem da comparação de um índice não particionado com um índice particionado onde ambos os índices têm a chave de particionamento como sua chave principal. Argumentos como o de Gail funcionam com base no fato de que há uma diferença mínima de desempenho entre a eliminação de partições e a busca por um índice não particionado com sua suposta chave de particionamento como a primeira chave.

Esses argumentos são convincentes, mas e os casos em que a chave de particionamento não é a primeira chave do seu índice particionado? Nesses casos, obtemos os benefícios da eliminação de partições e nossa chave principal agora é usada para pesquisar um índice consideravelmente menor do que teríamos se deixássemos o mesmo índice não particionado. Isso parece que deve dar uma melhoria de desempenho em relação a deixar o mesmo índice não particionado.

Em resumo, minha pergunta é esta: Há benefícios de desempenho em particionar um índice que tem várias chaves se a coluna de particionamento não for a primeira chave do índice? Tudo o que deve ser necessário para responder a essa pergunta é um exemplo acompanhado de alguma teoria explicando por que os resultados são como são.

Suponha que uma tabela contenha apenas números inteiros e tenha um índice columnstore agrupado.

CREATE TABLE cci_account
(  
    AccountKey int NOT NULL,  
    UnitSold int,
    INDEX ColStore CLUSTERED COLUMNSTORE
);

então parece que somar uma coluna agrupada por outra é sempre rápido em tal tabela, por exemplo

SELECT
    AccountKey,
    SUM(UnitSold)
FROM
    cci_account
GROUP BY
    AccountKey;

Por que isso é tão rápido? Meu entendimento da arquitetura columnstore é que os segmentos que contêm AccountKeynão têm ideia de qual UnitSoldvalor está em suas linhas. Como, então, o SQL Server consegue agrupar tão rapidamente por AccountKey? Não consigo imaginar nenhum algoritmo que consiga isso.

Contexto

Tenho experimentado particionamento de tabelas e encontrei muitas surpresas. Atualmente, estou lendo o máximo de documentação que posso, mas há uma quantidade chocante dela . Acho que estou no segundo de seis white papers. Não vi essa pergunta mencionada em nenhum lugar da documentação.

O Problema

Usando DROP_EXISTING = ON, parece que algumas tabelas podem ser particionadas no local. Por exemplo, posso fazê-lo funcionar com um índice clusterizado exclusivo. No entanto, não posso fazer o mesmo com uma chave primária. Este guia concorda com minha conclusão e diz que particionar uma tabela com uma chave primária no local requer a remoção da chave primária primeiro. É como se houvesse uma restrição de sintaxe em vez de uma de funcionalidade.

Minha pergunta é esta: Quando uma tabela pode ser particionada sem descartar nada antes do particionamento? Em outras palavras, quando o particionamento pode ser feito no local?

Não estou perguntando especificamente sobre o que pode ser feito com DROP_EXISTINGem particular. Esse foi apenas um método que encontrei.

Suponha o SQL Server 2022. Não me importa se a operação é online ou não. Tenho uma pergunta diferente para algo bem parecido.

Código de demonstração

Em grande parte roubado de Paul White

CREATE PARTITION FUNCTION PF (integer) 
AS RANGE RIGHT
FOR VALUES 
(
    10000, 20000, 30000, 40000, 50000
);
GO
CREATE PARTITION SCHEME PS 
AS PARTITION PF 
ALL TO ([PRIMARY]);
GO
CREATE TABLE dbo.T1
(
    c1 integer NOT NULL,
    c2 integer NOT NULL,
    c3 integer NOT NULL,
    
    CONSTRAINT PK_T1
    PRIMARY KEY CLUSTERED (c1, c2, c3)
);

CREATE TABLE dbo.T2
(
    c1 integer NOT NULL,
    c2 integer NOT NULL,
    c3 integer NOT NULL,
    
    INDEX UIX_T2 UNIQUE CLUSTERED (c1, c2, c3)
);
GO

CREATE TABLE dbo.T3
(
    c1 integer NOT NULL,
    c2 integer NOT NULL,
    c3 integer NOT NULL,
    
    INDEX UIX_T3 UNIQUE NONCLUSTERED (c1, c2, c3)
);
GO


/* These work */
CREATE CLUSTERED INDEX UIX_T2 ON dbo.T2 (c1, c2, c3)
WITH (DROP_EXISTING = ON) ON PS(C1) 
GO

CREATE NONCLUSTERED INDEX UIX_T3 ON dbo.T3 (c1, c2, c3)
WITH (DROP_EXISTING = ON) ON PS(C1) 
GO

/* But I could never get the primary key to! */

Acima, você pode particionar índices exclusivos no lugar. No entanto, nada que eu tenha pensado em tentar funciona para chaves primárias. Tenho quase certeza de que isso REBUILDtambém pode fazer isso.

Em inglês simples, "Processamento de consulta paralela em tabelas e índices particionados" e "Paralelismo de tabela particionada" parecem a mesma coisa. No entanto, no SQL Server 2022, a Standard Edition tem "Paralelismo de tabela particionada" , mas não Processamento de consulta paralela em tabelas e índices particionados . Como os dois recursos diferem?

Fiz um esforço razoável para pesquisar na documentação, mas ainda não li todos os white papers. Não consegui aprender o que é cada recurso.

Esta questão é a mais bem avaliada neste site sobre heaps. Ela pergunta sobre o caso de uso de heaps. No entanto, acredito que heaps muito grandes (por exemplo, milhares de gigabytes) são um caso especial que merece sua própria pergunta.

À medida que o tamanho do seu índice clusterizado cresce, também aumenta a penalidade do índice clusterizado , ou seja, o número de leituras lógicas necessárias para obter as chaves restantes dos seus índices não clusterizados. O mesmo não é verdade para um heap. Acredito que os heaps são injustamente descartados porque muitas pessoas aprenderam todo o design de seu banco de dados em data warehouses (onde varreduras de chave primária e, portanto, índices clusterizados, são geralmente uma boa ideia) ou nunca trabalharam em um banco de dados grande o suficiente para sentir o custo de ter uma tabela realmente grande.

Isso me faz perguntar: heaps muito grandes e bem indexados têm casos de uso práticos que não são encontrados em tabelas clusterizadas muito grandes e bem indexadas?

Com medo de tornar esta questão muito ampla, deixe as seguintes restrições se aplicarem. Suponha:

• Um heap de 1 TB
• Uma caixa da edição padrão
• Um ambiente OLTP ( não um data warehouse).

Cumulativamente, isso significa que você está limitado a 128 GB de RAM de pool de buffer e não fará varreduras grandes regularmente na chave primária. Ler todo o heap do disco será miserável, então quaisquer respostas sobre usar a tabela como uma tabela de preparação ou somente backup não devem se aplicar.

Configurar

CREATE TABLE persons
(
  person_id int not null,
  name TEXT 
);

INSERT INTO persons VALUES
(1, 'Adam'),
(2, 'Paul'),
(3, 'Tye'),
(4, 'Sarah');

CREATE TABLE json_to_parse
(
  person_id int not null,
  block json
);

INSERT INTO json_to_parse VALUES
  (1, '{"size": "small", "love": "x"}'),
  (2, '{"size": "medium", "love": "xx"}'),
  (3, '{"size": "big", "love": "xxx"}');

O erro

Isso funciona sem problemas

SELECT
  *
FROM
  json_to_parse
CROSS JOIN LATERAL
  json_to_record(json_to_parse.block) AS my_json(size TEXT, love TEXT)
INNER JOIN
  persons
ON
  persons.person_id = json_to_parse.person_id;

mas isso não

SELECT
  *
FROM
  json_to_parse,
  json_to_record(json_to_parse.block) AS my_json(size TEXT, love TEXT)
INNER JOIN
  persons
ON
  persons.person_id = json_to_parse.person_id;

e recebo o erro "referência inválida para a entrada da cláusula FROM para a tabela "json_to_parse""

Por que esse segundo erro de consulta? Os documentos deixam bem claro que LATERALé opcional para funções com valor de tabela

As funções de tabela que aparecem em FROMtambém podem ser precedidas pela palavra-chave LATERAL, mas para funções a palavra-chave é opcional; os argumentos da função podem conter referências a colunas fornecidas pelos FROMitens precedentes em qualquer caso.

dbfiddle

Tenho lido sobre os índices columnstore do Microsoft SQL Server recentemente e fiquei preocupado que minha experiência não corresponda à do setor. Os índices columnstore são projetados para tornar os agregados fáceis. É dito com muita frequência que, por esse motivo, eles são ideais para tabelas de fatos.

Isso me deixa desconfortável. Na minha experiência, tabelas de fatos não são agregadas . A lista de colunas para cada tabela de fatos que já fiz tem o formato "chave primária seguida por várias colunas de dimensão, seguidas por cada bit de informação que armazenamos sobre a chave primária". Elas então são despejadas em alguma ferramenta de BI como PowerBI ou ThoughtSpot, para que pessoas não técnicas possam filtrar com base nas dimensões e descobrir o que quiserem saber. Elas podem agregar de tempos em tempos, mas esse certamente não é o uso principal da tabela. Espero que essas tabelas tenham bem mais de 100 colunas.

O design da tabela e o padrão de acesso que estou descrevendo são o que se espera de uma tabela de fatos? Ou estou descrevendo um tipo de tabela totalmente diferente, cujo nome desconheço?