Estou tentando melhorar o desempenho de um conjunto de exibições que temos em um servidor local, extraindo dados de outro conjunto de exibições em um banco de dados remoto do Azure.
Nosso provedor de sistema nos aconselhou a usar ApplicationIntent=ReadOnly, mas podemos otimizar ainda mais essas consultas, usando tempdbespaço no servidor remoto para criar tabelas temporárias, se somente leitura estiver definido?
Eu li esta resposta , que ajuda um pouco, mas gostaria de receber qualquer resposta direta sobre isso.
Observe que não sou DBA, portanto meu conhecimento é bastante limitado. Desde já, obrigado.
Todo o processo combina SSIS e várias exibições em um SQL Server local, extraindo os dados das várias exibições da fonte para tentar otimizar o feed.
o processo é o seguinte...
- Limpe os dados antigos, removendo as informações temporárias das tabelas de retenção.
- Localize uma lista de chaves do servidor de origem...
INSERT INTO Source.ResourceCapture (VisitNumber)
SELECT DISTINCT src.VISIT_NUMBER
FROM [SOURCE.DATABASE.WINDOWS.NET].[Database].[dbo].[Composition_Questionaire] src
WHERE src.Composition_Date >= GETDATE()-2 AND
src.Document_Title = 'Discharge Summary' AND
src.Status = 'final'
- Localize o restante dos dados (contendo a essência da informação a ser passada) usando um conjunto de consultas. É a
INSERTinstrução final que falha devido à quantidade de processamento necessária. O Azure retorna um erro indicando que estamos sem recursos.
INSERT INTO [Source].[Composition_Questionaire] (
[Resource_ID],[RTR_ID],[Visit_Number],[Status],[Composition_Date],[Composition_Time],
[Document_Title],[Document_Description],[Component_Title],[Component_Description],
[Finalised_By],[Component],[Question],[Response],[Instance],[Row_No],[Col_No])
SELECT
[Resource_ID],[RTR_ID],[Visit_Number],[Status],[Composition_Date],[Composition_Time],
[Document_Title],[Document_Description],[Component_Title],[Component_Description],
[Finalised_By],[Component],[Question],[Response],[Instance],[Row_No],[Col_No]
FROM
[SOURCE.DATABASE.WINDOWS.NET].[Database].[dbo].[Composition_Questionaire] src
WHERE
DOCUMENT_TITLE = 'Discharge Summary' AND
VISIT_NUMBER COLLATE SQL_Latin1_General_CP1_CI_AS IN (SELECT VisitNumber FROM Source.ResourceCapture)
NOTA: Sim - eu sei sobre o problema de otimizar usando a JOINem vez de IN, mas testei as duas formas e o processo ainda falha após 10 minutos. Também tentei ajustar o agrupamento do lado do fornecedor para o nosso (ou seja, dentro da INcláusula), sem sucesso.
- Tecnicamente, tudo após a etapa 3 é irrelevante, pois tudo funciona bem na caixa local.
- As chaves de recursos (basicamente, identificadores exclusivos) são criadas no banco de dados local para alimentar valores específicos nas tabelas de destino.
INSERT INTO Core.KeyMap (ResourceID, MaxDateTime)
SELECT Resource_ID, MaxDateTime = MAX(CONVERT(DATETIME, Composition_Date) + CONVERT(DATETIME, Composition_Time))
FROM Source.Composition_Questionaire
WHERE Resource_ID NOT IN (SELECT ResourceID FROM Core.KeyMap) AND
[Status] = 'final'
GROUP BY Resource_ID
- Reconstrua a tabela de recursos, removendo qualquer informação estranha.
- Crie os dados finais para a tabela primária.
- Importar dados de outro serviço para gerar informações demográficas.
- Mapeie as chaves do sistema de destino para as chaves de recursos criadas na etapa 6.
- Marque os dados transferidos como completos.
Todo o processo funcionou bem, inicialmente, o maior tempo sempre levado pela transferência de informações dos servidores do Azure para os nossos.
tive o mesmo problema em um servidor, o que fiz foi em vez de fazer visualizações em dados remotos, criei uma tabela de preparação que é atualizada a partir de uma visualização desse servidor remoto a cada 5 minutos e direcionei meus códigos para ler a tabela da visão (na verdade, apenas usei o mesmo nome de tabela como visão e renomeei a exibição) a consulta de um servidor vinculado a um banco de dados remoto pode demorar muito para responder dependendo de vários fatores, como:
portanto, a velocidade de busca pode variar e, com esse método, você sempre pode ter uma nova cópia para si mesmo no servidor de destino. você pode querer alterar a duração da sincronização para atender às suas necessidades de negócios.
Então, depois de pesquisar e testar um pouco, a maneira mais ideal de extrair os dados era aplicar os mesmos critérios iniciais à consulta que extrai os
Resource.VisitNumbervalores, conforme a etapa 2 do OP.Temos que garantir que todos os dados sejam extraídos das tabelas de origem (ainda não podemos ter certeza, pois o fornecedor não nos forneceu nenhuma documentação referente às estruturas de visualização/tabela de origem). As estruturas parecem semelhantes, mas o uso de dados pode ser diferente.
Cada tabela contém um formato semelhante (nota: não posso fornecer informações detalhadas sobre a estrutura da tabela, pois vemos apenas os campos das exibições e alguns deles são gerados a partir de dados JSON), com campos com nomes iguais e funções gerais. Além do mais:
É uma mistura maluca.
Então, para recapitular, convertemos este SQL...
...para isso...
Infelizmente, devido à nossa falta de conhecimento com o sistema de origem, não podemos garantir que as datas que especificamos estejam alinhadas do registro pai ao filho, então reservamos alguns dias para tentar obter tudo associado. Como sempre - precisamos de mais informações.
Eu gostaria de agradecer a todos por suas contribuições, foram muito bem-vindas.