Linked Desempenho e opções de servidor

Question

No trabalho temos dois servidores, um está em execução uma aplicação um monte de pessoas usam que tem um back-end SQL Server 2000. Estou livre para consultar isso por um longo tempo, mas não pode acrescentar nada para ele como procedimentos armazenados ou mesas extras.

Isto levou-nos ter um segundo SQL Server ligado ao primeiro e me construir uma biblioteca de procedimentos armazenados que dados de consulta de ambos os lados usando servidor vinculado. Algumas dessas consultas estão demorando mais do que o que eu gostaria.

Pode alguém me aponte para alguns bons artigos sobre usando servidores vinculados? Estou particularmente interessado em descobrir o que os dados estão sendo transferidos entre os dois como geralmente a maioria da instrução SQL pode ser realizada remotamente, mas tenho a sensação de que pode ser transferir as tabelas completas, geralmente é apenas uma junção para um pequeno última mesa localmente.

Também o que as opções de servidor vinculado que eu tenho atualmente:

• Agrupamento Compatível verdadeiro
• Data Access verdadeiro
• Rpc verdadeiro
• Rpc Fora true
• Use Falso Agrupamento remoto
• nome de agrupamento (em branco)
• Connection Timeout 0
• Consulta Timeout 0

EDIT:

Apenas pensei que eu iria atualizar este post eu usei openqueries com parâmetros dinâmicos por um tempo para aumentar o desempenho, obrigado pela dica. No entanto fazendo isso pode fazer consultas mais confuso como você acaba lidando com cordas. finalmente este verão, atualizado SQL Server para 2008 e implementou o espelhamento de dados ao vivo. Para ser honesto, as consultas abertas estavam se aproximando da velocidade de consultas locais para minhas tarefas, mas o espelhamento certamente fez o sql mais fácil de lidar.

Answer 1

Eu aconselharia openqueries dinâmicos em um loop cursor em vez de ligados junta. Esta é a única maneira que eu fui capaz de replicar MS Access' ligada juntar desempenho (pelo menos para tabelas remotas individuais)
Regular ligada junta no MS SQL são muito ineficientes puxando tudo especialmente em mesas gigantescas ..

- Eu gostaria de saber o que é tão ruim sobre openqueries dentro laços cursor? se feito corretamente, não há problemas de bloqueio.

Answer 2

Evite junta-se às tabelas de servidor vinculado.

Usando uma nomeação de quatro partes para sua junção pode ser usado, mas é mais caro. Seu juntar poderia conter critérios que podem ser usados ??para limitar o conjunto de dados a partir do servidor ligado e usar as colunas indexadas.

Exemplo:

SELECT loc.field1, lnk.field1
FROM MyTable loc
INNER JOIN RemoteServer.Database.Schema.SomeTable lnk
  ON loc.id = lnk.id
  AND lnk.RecordDate = GETDATE()
WHERE loc.SalesDate = GETDATE()

Esta consulta também está aplicando um critério na junção que pode ser usado pelo servidor vinculado antes da junção é calculado.

O método recomendado é o uso de OPENQUERY.

Ao evitar a juntar-se com o uso de OPENQUERY o servidor local apenas envia a consulta para ser executado remotamente em vez de enviar um conjunto de IDs para a junção.

Use o link para recuperar um conjunto de dados e realizar os cálculos localmente. Ou usar uma tabela temporária (para consultas ad hoc) ou inserir a linha em uma tabela permanente em um trabalho noturno.

transações início pode falhar dependendo se o coordenador de transação remota é definido no servidor gostava. Usando ele irá consumir mais recursos.

Considere também que você está batendo um servidor de produção executando um aplicativo, enquanto você não especificá-lo, eu acho que é seguro assumir que é a utilização de transações pesadas e fazer inserções e atualizações. Você está tirando recursos de distância da aplicação.

Seu objetivo parece ser a utilização dos dados para fins de relatório. Seu servidor pode ser configurado para ter um log simples em vez de fazer full-lo mais eficiente.

Você também vai evitar suas consultas de ser cancelada devido ao movimento de dados no servidor vinculado. Sempre estar consciente de definir o nível de isolamento adequado para suas consultas e sugestões de mesa como NOLOCK.

E POR FAVOR! Nunca coloque um OPENQUERY (ou qualquer servidor vinculado) dentro de um loop!

Answer 3

Quando você usa servidores vinculados para a junta como esta, é importante ter o servidor que está imediatamente ligado ao ( "local") ser o único com a maior parte dos dados, onde o servidor ligado está fornecendo somente uma pequena parte dos dados, caso contrário, sim, ele vai puxar o máximo de dados de que necessita para executar a associação.

As alternativas incluem a cópia de um subconjunto dos dados através de uma tabela temporária com tanto trabalho feito para emagrecer os resultados e qualquer pré-processamento que o servidor vinculado pode executar, em seguida, fazer a junção do lado "local".

Você pode achar que você pode facilmente aumentar o desempenho, invertendo a maneira que você faz, a conexão com o servidor que você não tem controle sobre (eles precisam fazer um servidor ligado para você) e, em seguida, se conectar ao seu servidor através do link . Se você precisa fazer grande trabalho com os dados onde você teria que criar sprocs - então empurrar os dados para o servidor e usar suas sprocs há

.

Em alguns casos, eu simplesmente tinha o servidor vinculado realizar uma criação noturno deste tipo de síntese que empurrou para o servidor local, e, em seguida, o servidor local realizado seu trabalho com a juntar-se.

Answer 4

dor real

Estamos habituados a ter vários servidores ligados na nossa loja e que acabou por ser como um PITA .

Em primeiro lugar, houve problemas graves de desempenho semelhante ao que você descreve. Fiquei chocado quando vi as estatísticas de E / S de rede. Apesar de todos os esforços, não conseguimos sugerir SQL Server em um comportamento razoável.

Outro problema foi que procs armazenados tinha esses nomes de servidores ligados codificado em todos os lugares, com nenhuma forma de substituí-los. Assim, os desenvolvedores não poderia facilmente testar em seus ambientes de simulação de desenvolvimento de qualquer funcionalidade que tocou servidores vinculados. Este foi um grande obstáculo para a criação de uma suíte de teste de unidade universalmente utilizável.

No final, abandonou servidores ligados completamente e mudou-se a sincronização de dados para web-services.

Answer 5

As consultas envolvendo semi-junta-se através de um servidor vinculado tendem a não ser muito eficiente. Você pode ser melhor fora de usar OPENQUERY para preencher dados em uma tabela temporária local e, em seguida, trabalhar sobre ela de lá.

Answer 6

Eu escrevi um aplicativo de servidor remoto vinculado no SQL 2000, um par de anos atrás e me deparei com os mesmos problemas de desempenho que você descreve. Eu acabei reescrevendo meus procedimentos armazenados várias vezes a fim de obter o melhor desempenho.

Eu usei tabelas temporárias extensivamente. Eu achei que era menos dispendioso para recuperar grandes quantidades de dados remotos em uma tabela temporária, em seguida, juntar-se a ele, manipulá-lo, etc. Juntando local para tabelas remotas foi muito lento como você desribe.

Tela Execução do Plano e Plano de exibição de execução estimado tendiam a ajuda, embora eu não entendi muito do que eu estava olhando.

Eu não sei se há realmente uma maneira eficiente de fazer estas consultas com um servidor remoto, porque parece que o SQL Server não pode tirar proveito de suas otimizações normais quando vai contra um servidor vinculado. Pode sentir como está a transferir a tabela inteira porque na verdade isso é o que está acontecendo.

Eu estou querendo saber se um cenário de replicação pode funcionar para você. Por ter os dados em seu servidor local, você deve ser capaz de escrever consultas normais que irá executar como desejado.

Eu não sei de qualquer bons artigos para apontá-lo para. Enquanto escrevo aplicações do SQL Server mais complicado, eu comecei a pensar que eu precisava de uma melhor compreensão de como o SQL Server trabalhou por baixo. Para esse fim nós compramos o MS Press interior Microsoft SQL Server 2005 série editada por Kalen Delaney aqui no trabalho. Volume 1: O mecanismo de armazenamento é definitivamente o lugar para começar, mas eu não ter chegado tão longe para ele. Desde meus últimos projetos não têm envolvido SQL Server, meu estudo de ele ficou frouxa.

Answer 7

Existe uma possibilidade de que você poderia configurar um banco de dados separado no servidor em vez de usar um servidor ligado?

Answer 8

Um muito generosa problema, que pode ter muitas soluções. Mas, como temos assistido a tantos usuários dizendo que já tentou de tudo.

O que resolveu o meu problema é ..

I atualizado sql server 2000 do SP2 para SP4 e se você já tem SP4 no servidor SQL 2000, em seguida, executar o Instcat.sql. Como por minha experiência, posso assegurar-lhe este trabalho, com certeza, se você está exausto com todas as outras soluções alternativas.

Obrigado, Mithalesh mithalesh.gupta@gmail.com

Answer 9

SQL dinâmico e uma função pode ser usada para contornar a questão nome hard-coded. Por exemplo, estou tentando uma implementação onde a função ufn_linkedDatabase (@purpose nvarchar (255)) com a entrada 'cpi.cpi' (propósito CPI, padrão sub-purpose) retorna '[SERVER-NAME.DOMAIN.LCL, 2000]. [CPI]' no ambiente de produção (onde usamos número de porta alternativo para SQL Server, eu não sei por que, inclusive no nome do servidor vinculado). Em seguida, um comando SQL é montado em varchar @template (max) com a expressão @ {cpi.cpi} representando o servidor ligado e banco de dados, e em seguida @workstring = REPLACE (@template, N'@{cpi.cpi}', ...). Como a função realmente obtém o nome do banco de dados é separado dos procedimentos - uma tabela de pesquisa é bom.

Issues - para fazer OPENQUERY (), que é provavelmente ainda melhor, pelo menos, a menos que a opção do servidor vinculado "agrupamento compatível" está definido "verdadeiro" de modo que mais da tarefa pode ser executada no servidor vinculado - importante, mesmo em um rede rápida, e sala do servidor de rede interna é respeitavelmente rápido - para fazer OPENQUERY () Eu provavelmente terá que lidar com 'cpi.cpi.server' e 'cpi.cpi.database' e 'cpi.cpi.server.database' separadamente. E, eu posso acabar escrevendo exatamente um aplicativo usando este projeto, caso em que ele é sobre-projetado. Ainda assim, isso significa que a função em si não tem que ser qualquer tipo de trabalho de fantasia.

Jogando hardware de rede rápida para o problema pode ser a resposta mais barato, de qualquer maneira.