Dan's questions

Em um SQL Server 2014, tenho um modelo tabular SSAS que está consultando uma tabela columnstore clusterizada relacional (com 800 milhões de registros), quando o modelo está sendo processado. A consulta é apenas uma instrução SELECT simples, sem junções, filtros, etc. Estou processando o modelo por meio de um comando XMLA, que está sendo acionado por um trabalho do SQL Server Agent. O processamento leva algumas horas.

Para ter uma ideia do andamento do processamento, gostaria de saber a quantidade de registros retornados até o momento pelo comando SELECT. Existe alguma maneira de fazer isso, quando eu sei o SPID da instrução SELECT?

sys.dm_exec_requestsnão parece conter nenhuma informação de contagem de registros.

Além disso, tentei procurar no DMV do Analysis Services, para ver se algum desses objetos poderia me fornecer as informações de que preciso, mas sem sorte.

A razão pela qual acho que deve ser possível obter essas informações de alguma forma é que, quando processo o modelo tabular por meio do IDE gráfico do SSMS, ele realmente mostra a contagem de linhas durante o processamento.

Atualização: Acontece que o sys.dm_exec_requestsDMV realmente tem uma row_countcoluna. Infelizmente, o conteúdo desta coluna não parece refletir a realidade. Durante a primeira hora de processamento, ele teve o valor de "3", mas sei por experiência que vários milhões de registros teriam sido retornados na primeira hora.

Nosso fluxo ETL tem uma instrução SELECT INTO de longa duração, que cria uma tabela em tempo real e a preenche com várias centenas de milhões de registros.

A declaração é algo comoSELECT ... INTO DestTable FROM SrcTable

Para fins de monitoramento, gostaríamos de ter uma ideia aproximada do andamento desta instrução, enquanto ela está sendo executada (aprox. rowcount, número de bytes gravados ou similar).

Tentamos o seguinte sem sucesso:

-- Is blocked by the SELECT INTO statement:
select count(*) from DestTable with (nolock)

-- Returns 0, 0:
select rows, rowmodctr
from sysindexes with (nolock)
where id = object_id('DestTable')

-- Returns 0:
select rows
from sys.partitions
where object_id = object_id('DestTable')

Além disso, podemos ver a transação em sys.dm_tran_active_transactions, mas não consegui encontrar uma maneira de obter a contagem de linhas afetadas em um determinado transaction_id(algo semelhante a @@ROWCOUNTtalvez, mas com o transaction_idargumento as).

Entendo que no SQL Server a instrução SELECT INTO é uma instrução DDL e DML em uma e, como tal, a criação implícita da tabela será uma operação de bloqueio. Ainda acho que deve haver alguma maneira inteligente de obter algum tipo de informação de progresso enquanto a instrução está em execução.

Estou trabalhando em um grande projeto de ETL e DW onde usamos TFS/source control junto com SSIS e SSDT.

Hoje, descobri que enquanto um pacote SSIS está executando um BULK INSERT em uma tabela de banco de dados, não é possível executar um SSDT Schema Compare com esse banco de dados. Isso é lamentável, pois alguns de nossos pacotes levam muito tempo para serem concluídos. Queremos usar a função Schema Compare para detectar alterações na estrutura do banco de dados para salvá-las em nosso projeto SSDT para controle de versão do banco de dados.

Analisando um pouco mais sobre isso, descobri que a função Schema Compare no SSDT executa um script SQL que chama a OBJECTPROPERTY()função do sistema nas tabelas do banco de dados. Especificamente no meu caso, qualquer chamada para OBJECTPROPERTY(<object_id>, N'IsEncrypted')parece estar bloqueada, quando <object_id>se refere a uma tabela que está sendo inserida em massa.

No Visual Studio, o SSDT Schema Compare simplesmente expira depois de um tempo e afirma que nenhuma diferença foi detectada.

Existe uma solução alternativa para esse problema no SSDT ou devo tentar arquivar um relatório de bug do MS Connect?

Como alternativa, como o BULK INSERT ocorre a partir de um pacote SSIS, talvez haja alguma maneira de fazer essa inserção sem bloquear OBJECTPROPERTYas chamadas na tabela? Edit: Em SSIS OLE DB Destinations, podemos remover a marca de seleção de "Lock Table", que faz o que diz, mas isso pode prejudicar o desempenho em algumas situações. Estou muito mais interessado em uma solução que permita que o SSDT Schema Compare faça seu trabalho, mesmo que alguns objetos estejam bloqueados.