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