Neil P's questions

Estou usando polybase para importar um arquivo parquet.

Com o tempo, é provável que possamos adicionar ou remover colunas nomeadas no arquivo.

Quando adiciono uma coluna adicional, recebo o erro abaixo:

Falha no acesso ao arquivo externo devido a um erro interno: 'Arquivo test.parquet: HdfsBridge::CreateRecordReader - Erro inesperado encontrado ao criar o leitor de registro: HadoopExecutionException: incompatibilidade de contagem de colunas. O arquivo de origem tem 16 colunas, a definição de tabela externa tem 15 colunas.'

Isso ocorre porque adicionei uma coluna adicional que não estava na definição da tabela externa.

Como o parquet contém um esquema de arquivo e a tabela externa conhece o nome de cada coluna, existe uma maneira de ignorar a coluna extra não utilizada?

Você pode fazer uma conexão segura com uma instância do SQL Azure seguindo estas instruções do microsoft . No entanto, isso só funciona quando o usuário o especifica na string de conexão. Como configuro o SQL Azure para rejeitar qualquer conexão insegura, caso um usuário esqueça de definir a opção.

Eu tenho um conjunto de dados distorcido, onde a maioria das linhas se enquadra nos 10 maiores valores da minha melhor chave de distribuição candidata. Meus dados são compostos de duas tabelas grandes, que compartilham apenas duas chaves - minha melhor chave candidata, mais uma outra, mas essa é nula 80% das vezes, então eu a descontei como uma opção.

A sabedoria convencional diz que, se os dados estiverem distorcidos, devo usar uma distribuição round robin. Olhando para os planos de explicação produzidos por junções nas mesas, vejo que minha coluna candidata é a tecla de embaralhar para o movimento de embaralhar. Isso me faz questionar se devo alterar a distribuição de round robin para hash distribuído, economizando o tempo necessário para mover dados em cada execução.

Minha lógica está correta? Eu sinto que isso é contra a sabedoria convencional ao trabalhar com sql distribuído. Não espero nenhuma consulta em que essa junção não seja necessária, portanto, pode ser que outros vejam o benefício.

Eu tenho uma consulta que calcula row_Number(). A tabela tem um índice clusterizado nas mesmas colunas (e ordem) que o particionamento e a ordenação do número da linha.

Ao usar uma junção de mesclagem (muitos para um), uma classificação é necessária, mesmo que o índice clusterizado esteja na ordem correta. A remoção da junção também remove a operação de classificação.

O índice clusterizado que deve alimentar o cálculo row_number:

create clustered index [ClusteredIndex_e060df3fbf464a8eb9b6ea5d46a9a5f5] on [dbo].[log1]
(
    [client] asc,
    [orderId] asc,
    [campaign] asc,
    [id] asc,
    [DateStamp] asc
)

create clustered index [ClusteredIndex_dd0ee53e050d436cba2cab7c678a39e5] on [dbo].[LiveReference]
(
    [client] asc,
    [orderId] asc,
    [campaign] asc
)

A pergunta:

    with cr as 
(
    select distinct client, orderId,campaign
    from LiveReference
)

select e.[DateStamp]
  ,e.[campaign]
  ,e.[client]
  ,e.[orderId]
  ,e.[ad]
  ,e.[id]
  ,e.[source]
,row_number() over (partition by e.[client] ,
                        e.[orderId] ,
                        e.[campaign] ,
                        e.[id] 
                    order by e.[DateStamp]) as num
from [dbo].[log1] e 
inner join cr on 
                        e.client = cr.client
                        and e.campaign = cr.campaign
                        and e.orderId =  cr.orderId

que dá o plano abaixo:

A remoção da junção também remove a classificação:

select e.[DateStamp]
  ,e.[campaign]
  ,e.[client]
  ,e.[orderId]
  ,e.[ad]
  ,e.[id]
  ,e.[source]
,row_number() over (partition by e.[client] ,
                        e.[orderId] ,
                        e.[campaign] ,
                        e.[id] 
                    order by e.[DateStamp]) as num
from [dbo].[log1] e 

(Eu sei que isso também remove a filtragem realizada pela junção, mas isso não explica por que a exclusão dessas linhas altera a ordem)

Por que os resultados de uma junção ordenada não estariam na ordem correta?

Eu tenho uma junção de mesclagem no data warehouse do Azure. Meu plano de execução estimado atualmente mostra como muitos para muitos se juntam. Gostaria de saber se é possível conseguir uma junção de muitos para um. Atualmente, estou lutando para pensar em uma maneira de fazer isso, pois as chaves primárias e as restrições exclusivas não são suportadas. Existe alguma coisa disponível que me permita dizer que uma das tabelas sempre conterá valores exclusivos.

Eu tenho a mesma consulta que mostra como sendo executada no modo de lote quando executada como uma instrução de seleção, mas no modo de linha quando a mesma consulta é a parte selecionada de uma operação CTAS. Ambas as tabelas (mais a tabela resultante) são todas alinhadas à distribuição.

Por que é isso? Obviamente, eu gostaria que ele fosse executado em modo de lote, se possível.

Causa a execução do modo de linha:

create table mytable1
with
(
    distribution = hash(c1)
)
as

consulta:

with  filterData as 
(
    select 
        a
        ,b
        ,c
        ,d
        ,DateStamp
    from [DW_reporting].[table1] 
    where num > 0
)

    select 
        p.[DateStamp]
        ,p.[a1]
        ,p.b1
        ,p.c1
        ,p.d1
        ,e.a
        ,e.b
        ,case when e.d is not null then 1 else 0 end as Flag
    from SOmeOtherTable p
    left join filterData e on e.a = p.a1
                                            and e.c = p.c1
                                            and e.DateStamp < p.DateStamp       

Eu tenho uma junção muito cara no data warehouse que não está alinhada à distribuição. Infelizmente, a chave de junção é anulável e apenas metade dos dados tem um valor, o que significa que não seria um bom candidato para a chave de distribuição.

Seria possível criar uma visão particionada onde a metade nula da tabela fosse distribuída em rodízio e a outra metade fosse distribuída nos valores de chave disponíveis?

Estou tentando implantar um modelo tabular em um servidor usando o "Assistente de implantação do Analysis Services".

Ao tentar implantar, recebo o erro abaixo.

A solicitação JSON DDL falhou com o seguinte erro: Falha ao executar XMLA. Erro retornado: 'A coluna 'Date Offset' na tabela 'Date' tem associações inválidas especificadas.

A coluna em questão usa o cálculo abaixo, que foi encontrado aqui

INT([Date] - TODAY())

O que devo procurar para resolver esse erro?

Azure SQL DWH/PDW tem a EXPLAINpalavra-chave para mostrar o plano de consulta paralela. Isso é realmente útil para ver as operações de movimentação de dados, no entanto, eu queria saber se havia um equivalente ao plano de consulta tradicional do servidor sql. Estou trabalhando na suposição de que só porque não há nenhuma movimentação de dados, isso não significa necessariamente que a consulta está bem otimizada.

Provavelmente uma pergunta estúpida, mas eu queria saber se era possível transformar uma tabela inteira em uma partição de uma tabela maior?

Acho que não, pois as restrições de verificação não estão disponíveis para restringir a tabela no limite da partição.

O Azure SQL Data Warehouse tem limites no tamanho máximo de uma transação (conforme documentado aqui ). Como as operações de CTAS não podem ser realizadas dentro de uma transação, gostaria de saber se esses limites ainda se aplicam?

Imagine que estou executando vários lotes pelo estúdio de gerenciamento, separados pelo comando GO. Eu gostaria de saber como as transações implícitas se comportarão - a transação é confirmada por lote ou uma vez para toda a execução.

Gostaria de adicionar uma restrição de verificação a uma tabela no azure data warehouse .

Tenho o script abaixo:

alter table [FactTbl_Test] add constraint Ck_Test_id check ([Test_Id] != 'Unknown')

Isso causa o erro abaixo:

Erro de análise na linha: 2, coluna: 74: Sintaxe incorreta perto de 'verificar'.

Editar:

Também parece falhar com o mesmo erro se a restrição for criada dentro da declaração da tabela.

Estou usando [vColumnstoreDensity]para monitorar a integridade dos meus índices columnstore.

Percebi que tenho um índice que parece estranho.

Pelo que entendi, o índice columnstore preencherá um rowgroup antes de iniciar o próximo rowgroup. Para melhor desempenho de índice, grupos de linhas mais completos são melhores.

Dito tudo isso, tenho uma tabela que estou tendo problemas para entender. Mesmo após uma reconstrução de índice usando a maior classe de recurso (para fornecer a quantidade máxima de memória possível para o processo de compilação), a [vColumnstoreDensity]exibição ainda mostra esse índice como sendo distribuído por muitos rowgroups parcialmente cheios.

COMPRESSED_rowgroup_count

4936

COMPRESSED_rowgroup_rows

2693512978

COMPRESSED_rowgroup_rows_MIN

468

COMPRESSED_rowgroup_rows_MAX

739443

COMPRESSED_rowgroup_rows_AVG

545687

Editar:

Este é um índice columnstore clusterizado.

Eu tenho um cubo tabular com uma grande tabela particionada.

Eu gostaria de truncar algumas das partições (liberando espaço de memória), mas manter os metadados, para que eu possa reconstruí-los rapidamente, se necessário, posteriormente, sem precisar recriar a partição.

Isso é possível? Se sim, como pode ser feito?

É possível gerar a lista de objetos aos quais um usuário recebeu acesso explícito, para um determinado usuário?

Gostaria de ver uma lista de todos os itens para os quais um usuário tem permissões explícitas, excluindo quaisquer permissões herdadas por meio de funções etc.

Se eu tiver uma versão de linha em duas tabelas diferentes em um banco de dados, elas serão exclusivas em ambas as tabelas? Se não, existe alguma maneira de definir esse comportamento?

Eu tenho uma visão que une duas tabelas, gostaria de saber se esse comportamento é garantido, para que eu pudesse pegar o maior número de linha de qualquer tabela, para formar uma versão de linha para a visão.

Eu tenho duas tabelas que são idênticas e mantêm as mesmas linhas de dados.

um usa um varchar(255) para cada coluna da tabela, o outro é digitado corretamente para cada coluna (usando data, int, decimal etc.).

Usando a janela de propriedades do Management Studio, posso ver que a tabela que armazena todos os dados como varchar é muito menor, o que não era o que eu esperava ver. Meu entendimento era que um int usaria apenas 4 bytes de espaço e, portanto, usaria muito menos espaço do que um int armazenado como um varchar.

O que devo procurar para entender o que está acontecendo aqui? Ambas as tabelas possuem uma chave primária em uma coluna int e nenhum outro índice. Para fins de teste, eles foram preenchidos com conjuntos de dados idênticos da mesma consulta de origem.

Ao executar uma instrução de atualização, como a abaixo, recebo um erro informando que

As funções em janela só podem aparecer nas cláusulas SELECT ou ORDER BY.

UPDATE dbo.Dim_Chart_of_Account
SET Account_Order = LAG([Account_Order]) OVER (ORDER BY [Account_SKey])

Eu sei que isso pode ser facilmente contornado usando um cte atualizável, como abaixo

 WITH my_cte AS (
     SELECT [Account_Order], LAG([Account_Order]) OVER (ORDER BY [Account_SKey]) AS acc_order_lag
     FROM Dim_Chart_of_Account
)
UPDATE my_cte
SET [Account_Order] = acc_order_lag

Minha pergunta é: há algum motivo pelo qual isso não é permitido em uma instrução de atualização? Devo evitar o uso de um cte atualizável como solução alternativa?

Minha preocupação é que há problemas ao usar funções de janela com instruções de atualização e, portanto, gostaria de entender se esse é um método aceitável ou deve ser evitado.

Estou tentando usar transações explícitas no SSIS. O banco de dados com o qual estou trabalhando não tem o DTC ativado, então não posso usar o tratamento de transação embutido do SSIS.

Eu executei tarefas sql para inicializar, confirmar e reverter a transação, no entanto, apesar de ter definido "RetainSameConnection" como verdadeiro, ainda estou recebendo o erro abaixo:

[Execute SQL Task] Erro: Executando a consulta "ROLLBACK;" falhou com o seguinte erro: "A solicitação ROLLBACK TRANSACTION não tem BEGIN TRANSACTION correspondente.". Possíveis motivos de falha: Problemas com a consulta, propriedade "ResultSet" não definida corretamente, parâmetros não definidos corretamente ou conexão não estabelecida corretamente.