Производительность связанного сервера SQL Server

Question

Я использую SQL Server 2008 Enterprise. И я использую технологии Linked Server для связи другого экземпляра SQL Server 2008 Enterprise с другого сервера. Я пишу TSQL для управления объектами (например, таблицами) из обоих экземпляров сервера.

Мой вопрос: для связанного сервера существует большая проблема с производительностью? Если да, то в чем заключаются основные проблемы с производительностью и лучшая практика, которой мы должны следовать?

спасибо заранее, George

Answer 1

Мой вопрос для связанного сервера: есть большая проблема с производительностью? Если да, что является ключевым узким местом производительности и лучшая практика, которой мы должны следовать?

По сравнению с чем? Для каких запросов? конечно все зависит от того, что вы делаете. Для некоторых запросов снижение производительности будет незначительным, для других - массовым.

Есть несколько проблем, которые вы должны иметь в виду:

• Если вы будете объединять 2 таблицы из DB1 с 2 таблицами из DB2, и эти таблицы большие, вещи могут быть ужасными. В конце дня запросы будут выполняться где-то. БД должен будет вывести все результаты в основную БД и поддерживать целостность транзакций в основной БД. Это может быть очень дорого.
• Если вы начнете выполнять распределенные транзакции, то может стать уродливым , быстро.
• При объединении ресурсов между серверами ваши индексы на удаленном сервере могут оказаться бесполезными. Все данные должны перемещаться куда-то для соединений.
• Связанные ссылки на серверы могут прерываться в непредвиденное время и приводить к трудным диагностикам ошибок.

В прошлом я встречал ситуации, когда было на несколько порядков быстрее перемещать удаленные данные локально и индексировать их, прежде чем присоединять к ним.

Answer 2

Это зависит от того, что вы делаете.

Если вы выполняете запросы, объединяющие таблицы в двух экземплярах сервера, и передаете большие объемы данных, у вас есть узкое место, о котором вам нужно знать.

Если серверы находятся в собственной подсети со ссылкой 1 ГБ, вам не нужно сильно беспокоиться. Я был бы обеспокоен, если два сервера соединены общей медленной связью.

Answer 3

Я часто использую связанные серверы для синхронизации данных между средами, главным образом потому, что я считаю, что это самое простое решение для кодирования и управления.

Один совет, который я нашел, но, возможно, не подходит для других, состоял в том, чтобы запускать какие-либо процедуры на сервере, на котором больше всего данных или который выполняет наибольшее количество обновлений / вставок. Например, у меня есть процедура, которая сравнивает две таблицы и вставляет / обновляет от A до B. Если бы я запустил это на сервере A, это заняло бы много раз больше, чем выполнение процедуры на B. Если у вас нет выбора, где запустить наш код, и вы застряли, скажем, на сервере А, тогда этот совет может не помочь.

Еще один совет - уменьшить количество возвращаемых данных до необходимого минимума. В то время как обычно вы можете получить данные почти мгновенно на локальном сервере, если связанный сервер находится на некотором расстоянии, задержка может быть очень болезненной. Будьте строже, чем обычно, получая доступ только к тем столбцам, которые вам нужны.

Answer 4

Вам понадобится немного потрудиться, чтобы дважды передать результаты по сети (связанный сервер с SQL Server на вашем компьютере). Во-вторых, нужно разрешить имя и войти в систему, что не так уж и много, но, тем не менее, это хит.

Во всяком случае, я обнаружил, что единственным серьезным узким местом являются прыгающие серверы, поскольку он должен передавать информацию дважды.

Answer 5

Я обнаружил, что если вы выполняете внешние соединения (влево / вправо), производительность быстро снижается. Иногда быстрее выбрать данные с удаленного сервера во временную таблицу и проиндексировать их, чем объединять их по сети. В основном, лучшая стратегия - написать запрос так, как он имеет смысл, а затем настраивать его, только если производительность является реальной проблемой.

Answer 6

@ George2,

Сэм Шафран в этом случае прав. Когда соединение выполняется локально, SQL Server использует индексы для выполнения соединения, а затем выполняет поиск столбцов, не включенных в определение индекса.

При соединении с сервером для объединения сначала необходимо перенести всю таблицу с удаленного сервера, а затем выполнить соединение. Это горлышко бутылки. Если вы можете предварительно отфильтровать все удаленные таблицы перед их соединением с локальными таблицами, это значительно улучшит производительность (например, выберите в #temp таблицы с хорошим фильтром для уменьшения количества строк), тогда, если вам нужно выполнить несколько операций с этой таблицей, Лучше сразу создать индекс.