Связанный сервер с перекрестным соединением

Question

У меня есть два сервера. Один мой, а другой другой. На втором сервере я не могу создать какую-либо базу данных, добавить какие-либо функции или сохранить процедуры, но мне нужно вернуть информацию, чтобы выполнить перекрестное соединение с моей базой данных.

например,

select fieldA, fieldB from localTBL l
left join linkedserver.remoteDB.dboremoteTBL r on l.ID = r.ID

или же

select fieldA, fieldB from linkedserver.remoteDB.dboremoteTBL r
where r.ID in (select l.ID from localTBL l)

Я сделал это, но выступление было очень ужасным.

Можно ли сделать это с лучшей производительностью?

Answer 1

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

DECLARE @Id As int;
SELECT @Id = 45;

with cte (ID, fieldB)
AS
(
    SELECT ID, fieldB
    FROM linkedserver.remoteDB.dboremoteTBL
    WHERE ID = @Id
)

SELECT lt.fieldA, cte.fieldB
FROM localTbl lt
    INNER JOIN cte ON lt.ID = cte.ID
ORDER BY lt.ID;

Answer 2

Для повышения производительности на связанных серверах используйте openquery. В противном случае сначала вы возвращаете все данные с удаленного сервера, а затем применяете условие where.

В вашей ситуации сначала запустите подзапрос и верните список значений в переменную. Затем используйте эту переменную в вашем openquery.

Answer 3

Ага. Производительность будет ужасной. Это зависит от сети между вами и другой компанией, а также от любых аутентификаций и авторизаций, которые должны быть сделаны в пути.

Вот почему связанные серверы используются не очень часто, даже в пределах одной компании: производительность обычно плохая. (Я никогда не видел Связанного Сервера в отдельной компании и могу только сочувствовать!)

Если вы не можете обновить сетевое соединение между вами, вы не сможете выполнять запросы со связанного сервера.

Эта установка звучит как краткосрочное решение проблемы, которая требовала быстрого решения и продолжалась дольше, чем ожидалось. Если вы можете получить экономическое обоснование для того, чтобы тратить деньги на это, есть две альтернативы:

Самый дешевый вариант: локально кэшировать данные: запустить фоновую службу, которая перетаскивает последнюю версию данных из таблиц связанного сервера в набор таблиц в локальной базе данных, а затем выполняет запросы к локальным таблицам. Это зависит от того, насколько изменчивы удаленные данные и насколько актуальными должны быть ваши запросы. Форекс, если вы делаете такие вещи, как получение вчерашних данных о продажах, вы можете сделать ночной рывок. Если вам нужно больше актуальных данных, возможно, почасовая проверка. Иногда вы можете быть довольно разборчивыми, и если структуры данных поддерживают, то извлекают только те данные, которые изменились с момента последнего извлечения: это делает каждое извлечение намного меньшим и допускает более частые, может быть..

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