Я использую SQL Server 2008 Enterprise. И я использую технологии Linked Server, чтобы связать другой экземпляр SQL Server 2008 Enterprise с другого сервера. Я пишу TSQL для управления объектами (например, таблицами) с обоих экземпляров сервера.
Мой вопрос: для связанного сервера есть большая проблема с производительностью? Если да, каковы основные узкие места в производительности и рекомендации, которым мы должны следовать?
заранее спасибо, Джордж
Мой вопрос: для связанного сервера есть большая проблема с производительностью? Если да, каковы основные узкие места в производительности и рекомендации, которым мы должны следовать?
По сравнению с чем? Для каких запросов? конечно, все зависит от того, что вы делаете. Для некоторых запросов снижение производительности будет незначительным, для других — массовым.
Есть ряд проблем, которые вы должны иметь в виду:
В прошлом я сталкивался с ситуациями, когда было на несколько порядков быстрее перемещать удаленные данные локально и индексировать их перед присоединением к ним.
Это зависит от того, что вы делаете.
Если вы выполняете запросы, соединяющие таблицы в двух экземплярах сервера, и передаете большие объемы данных, у вас есть узкое место, о котором вам нужно знать.
Если серверы находятся в своей собственной подсети с каналом 1 ГБ, вам не о чем беспокоиться. Я был бы обеспокоен, если бы два сервера были соединены общим медленным каналом.
Вам придется немного потрудиться, чтобы дважды передать результаты по сети (связанный сервер с SQL Server на вашем компьютере). Во-вторых, он должен разрешить имя и войти в систему, что не является большим успехом, но, тем не менее, является успехом.
В любом случае, я обнаружил, что единственным серьезным узким местом является переключение серверов, так как информация должна передаваться дважды.
Я часто использую связанные серверы для синхронизации данных между средами, главным образом потому, что считаю это самым простым решением для кодирования и управления.
Один совет, который я нашел, но, возможно, не подходит для других, заключался в том, чтобы запускать любые процедуры на сервере, который имеет больше всего данных или выполняет наибольшее количество обновлений/вставок. Например, у меня есть процедура, которая сравнивает две таблицы и вставляет/обновляет из A в B. Если бы я запускал ее на сервере A, это заняло бы во много раз больше времени, чем выполнение процедуры на B. Если у вас нет выбора, где запустить наш код, и вы застряли, скажем, на сервере А, то этот совет может не помочь.
Еще один совет — сократить количество возвращаемых данных до необходимого минимума. В то время как обычно данные возвращаются почти мгновенно на локальный сервер, если связанный сервер находится на некотором расстоянии, задержка может быть очень болезненной. Будьте строже, чем обычно, в доступе только к тем столбцам, которые вам нужны.
Я обнаружил, что если вы выполняете внешние соединения (влево/вправо), производительность быстро снижается. Иногда быстрее выбрать данные с удаленного сервера во временную таблицу и проиндексировать ее, чем объединять по сети. В большинстве случаев лучшая стратегия состоит в том, чтобы написать запрос так, как он имеет смысл, а затем настраивать его только в том случае, если производительность является реальной проблемой.
@George2,
Сэм Саффрон прав в этом случае. Когда соединение выполняется локально, SQL Server использует индексы для выполнения соединения, а затем выполняет поиск столбцов, не включенных в определение индекса.
С подключенным сервером для выполнения соединения необходимо сначала перенести всю таблицу с удаленного сервера, а затем выполнить соединение. Это бутылочное горлышко. Если вы можете предварительно отфильтровать все удаленные таблицы, прежде чем присоединять их к локальным таблицам, это значительно улучшит производительность (например, выберите в #temp таблицы с хорошим фильтром, чтобы уменьшить количество строк), тогда, если вам нужно выполнить несколько операций с этой таблицей, вы лучше сразу создать индекс.
