Cruzar consultas de mecanismo de banco de dados SQL MS

Question

É possível ter consultas cruzadas de banco de dados que abranjam bancos de dados em dois diferentes MS SQL Servers 2008?

Em caso afirmativo, qual configuração, se houver, precisa ser feita no MS SQL? Além disso, alguém poderia me mostrar uma consulta de exemplo?

Scope Creep:
Ao ligar dois servidores:

• Isso une os servidores de alguma forma que pode causar desvantagens fora das consultas que abrangem os servidores vinculados?
• Esses servidores estão dispersos geograficamente. No entanto, as consultas que usam esse recurso serão geralmente raras. Quaisquer desafios específicos com este e servidor SQL a partir da experiência?

Answer 1

Isso é chamado de consulta distribuída e é bastante comum. Um servidor vinculado é a maneira mais comum e mais fácil de fazer o que você descreve; Se isso não funcionar, você pode tentar OPENQUERY ou OPENROWSET, mas provavelmente não precisará. Outros cobriram o "como" de criar um servidor vinculado, então não vou entrar em detalhes.

As consultas que usam um servidor vinculado podem sofrer um impacto no desempenho, mas o desempenho não é prejudicado no servidor como um todo. Como os servidores estão dispersos geograficamente, o impacto no desempenho será maior do que se estivessem na mesma LAN; você terá que tentar para ver se o desempenho é aceitável, mas assumindo que o servidor remoto tenha tempos decentes de resposta, você provavelmente ficará bem.

O mais importante a ser lembrado ao usar um servidor vinculado é manter os conjuntos de resultados retornados do servidor remoto o mais focado possível. O SQL Server não fornece um link ativo entre os dois servidores para fazer uma junção "ao vivo" entre objetos em servidores diferentes da mesma maneira que acontece quando tudo está no mesmo servidor. O que ele faz, em vez disso, é dividir a consulta distribuída em partes que podem ser executadas de forma independente nos servidores remotos, depois trazer os resultados de volta ao servidor de chamada (local) e concluir o trabalho. Isto significa que qualquer coisa - junções, condições, cálculos, etc. - que envolva mais de um servidor deve ser mantido no servidor local, e quaisquer dados que sejam necessários para suportar isso devem ser trazidos de volta . Como um exemplo simples, se uma tabela de 10.000.000 de linhas em um servidor remoto estiver associada a uma tabela de 15 linhas no servidor local, o SQL Server retornará todas as 10.000.000 linhas do servidor remoto para executar a junção! Não é preciso dizer que isso causará um impacto significativo no desempenho, especialmente em uma conexão mais lenta. Use planos de execução estimados para verificar as consultas remotas; usar coisas como colunas derivadas e CTEs para "explicitamente" criar consultas atômicas que podem ser passadas por atacado para o servidor remoto; e se você está vendo um problema sério, não tenha medo de dividir suas consultas em consultas separadas para forçá-lo a retornar um pequeno conjunto de resultados.

Espero que isso ajude!

    

Answer 2

Sim, você pode, com o servidor vinculado .

SELECT * FROM SERVER1.DBO.DB1.TABLE1

    

Answer 3

Advertência: Sou um dev, não um dba - minha visão pode variar; p

Config e como: servidores ligados e identificadores de 4 partes

Mas você deveria é uma pergunta mais complicada; a equipe de DBA em meu último lugar estava interessada em minimizar tais "abominações"; Tenho certeza de que eles tinham boas razões para o DBA; como acontece, eu concordei de uma perspectiva de desenvolvimento, puramente de manutenção / gerenciamento.

    

Answer 4

Quando eu crio servidores vinculados para minha organização, eu sempre mapeio todos os logins ("Para um login não definido na lista acima, as conexões serão: Not be made" - O primeiro botão na seção de segurança do servidor vinculado no gui) .

Eu tenho reclamações sobre isso, mas, do meu ponto de vista, quando mapeio logins explicitamente, sei quem está indo do servidor inicial para o servidor de destino. Curiosamente, nunca tive um auditor perguntando sobre servidores vinculados.