Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 SP, которая работает с объектами на другом сервере  [new]
?
Guest
Примитивная ситуация:
MyServer.MyDatabase.dbo.MyTable, НО
MyServer & MyDatabase приходят как параметры в SP.
В принципе, легко решается тоже если задекларировать переменную @MyString и сделать вот так :
SET @MyString = 'INSERT INTO '+ @MyServer +'.’ + @MyDatabase +’ .dbo.tblMyTable1 SELECT * FROM tblMyTable2'
Exec @MyString

А вот тут и начинается загвоздка. Сама по себе процедура сложная, но главное – очень длинная и в одну string не вмещается, можно конечно записать её в несколько переменных и запускать
Exec(@MyString+@MyString1+@MyString2..), но это уж как-то совсем коряво…
Может кто-то предложит лучшее решение?
25 фев 04, 19:07    [551309]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Gena G.
Member

Откуда: Oz
Сообщений: 977
Количество серверов и БД конечно? Тогда используйте CASE структуру
25 фев 04, 19:08    [551311]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Glory
Member

Откуда:
Сообщений: 104760
SET @MyString = 'INSERT INTO '+ @MyServer +'.’ + @MyDatabase +’ .dbo.tblMyTable1 exec myproc1' 

Exec(@MyString)
25 фев 04, 19:09    [551315]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
?
Guest
Количество серверов и баз конечно, но очень велико и может изменяться, к тому-же зависит от того из какой application вызвана процедура.
25 фев 04, 19:14    [551324]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
?
Guest
2Glory
что такое myproc1?
25 фев 04, 19:16    [551327]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
?
Guest
2Glory
Если это собственно мой select, то не получится, там внутри должны быть тоже ссылки на другие серверы.
25 фев 04, 19:19    [551334]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Фу. Обычно

declare @procname sysname


select @procname = ' ... '

insert into mytable
exec @RetCode = @procname


Очень рекомендую.
25 фев 04, 19:21    [551337]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
?
Guest
2Crimean

Действительно интересное решение.

select @procname = ' ... '

А вот этот `...’ и есть мой select? А если мне и в него надо переменные сервера впихнуть?
Какой тип у @RetCode?
25 фев 04, 20:10    [551355]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Crimean
Member

Откуда:
Сообщений: 13148
EXECUTE
Syntax
Execute a stored procedure:

[ [ EXEC [ UTE ] ]
{
[ @return_status = ]
{ procedure_name [ ;number ] | @procedure_name_var
}
[ [ @parameter = ] { value | @variable [ OUTPUT ] | [ DEFAULT ] ]
[ ,...n ]
[ WITH RECOMPILE ]
25 фев 04, 20:45    [551387]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
mikhail_n
Guest
Нет, это не Ваш select, это Вам предлагается написать порядка 2 в степени N разноимённых х_процедур (N - число Ваших linked server'ов), а потом динамически вызывать нужную хп в зависимости от фактически переданого набора серверов. Типа этакого аналога late binding в Т-SQL. Да, вот это полёт мысли... Как сказал поэт: "... жаль лишь что в пору эту счастливую жить не придётся ни мне, ни тебе..."
25 фев 04, 20:50    [551397]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
?
Guest
2Crimean
Спасибо. БОЛ я уже смотрела.
25 фев 04, 21:01    [551407]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Неееееет.
Написать процедуру обработки данных. Поднять ее на нужных серверах. И вызывать ее для обработки данных на этих серверах.
Если лень писать свою - пользовать sp_executesql.

Для непонятливых объясняю совсем доходчиво.
Если с сервера А надо передать на сервер Б некоторые данные, то делаем так:

На сервере А (источнике данных) добиваемся, чтобы нужные данные возвращались примерно так:

exec sp_executesql N'ляляля' и т.д.

На сервере Б (приемнике данных) делаем

insert into
exec ServerA.mydb..sp_executesql N'ляляля'

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

exec serverB.mydb..sp_executesql N'
insert into mytable
exec serverA.mydb..sp_executesql N''ляляля''
'

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

2 mikhail_n

Растите, растите крылья своим мыслям. А то ведь я тоже классика вспомню. Про рожденного ... мыслить.
:P

P.S.А БОЛ не только смотреть, его читать временами полезно. Но не всегда сразу понятно, о чем это они там.
25 фев 04, 21:24    [551426]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
I
Guest
2Crimean
БОЛ я изучаю. Glory предложил то-же самое, что и вы только в более вежливой и понятной форме. Проблема, как я уже писала, заключается в том, что внутри моего SELECT тоже есть ссылки на другие серверы, задаваемые параметрами.
25 фев 04, 21:38    [551435]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Crimean
Member

Откуда:
Сообщений: 13148
А я о том, что лучше при работе с разными серверами использовать не

exec ( 'insert ... ' )

а все же

exec @procname

замечание основано на многолетней постоянной работе с remote / linked серверами. Я не люблю динамический SQL. Ни в каком виде. А exec @procname
это не совсем динамический SQL. Можете поэкспериментировать как в раках базы, так и между базами и между серверами.
25 фев 04, 22:01    [551451]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
?
Guest
2Crimean
Спасибо. Я попробую.
25 фев 04, 22:03    [551453]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
mikhail_n
Guest
2Crimean

Большое Вам человеческое спасибо, то, что Вы опубликовали, тянет на откровение, просто изотерическое знание какое то. Ладно, на этом торжественную часть прошу считать законченной. По сути:

Количество серверов и баз конечно, но очень велико и может изменяться, к тому-же зависит от того из какой application вызвана процедура

Насколько я понял задачу, есть хп, в которую передаётся переменноё количество имён прилинкованных серверов (надо полагать ввиде строки с каким то фиксированным разделителем или м.б. там число входных параметров соответствует макс. числу серверов) плюс что там ещё необходимо чтобы слепить селект. После этого могут быть варианты:

1.Передан ServerА:

select * from ServerA.DatabaseA.dbo.TableA where ...

или

update ServerA.DatabaseA.dbo.TableA set ... where..

или ... всё что угодно

2.Передан ServerA and ServerB

select *
from ServerA.DatabaseA.dbo.TableA inner join ServerB.DatabaseB... on ...
where ...

или

delete from ServerA.... where ... in (select ... from ServerB...)

и т.д. и т.п...

Резюме: имеем 2 в степени N всевозможных перестановок и сочетаний. Я не утверждаю, что у ? присутствуют все 2**N варианта, но... см. цитату выше.

Теперь имеем - разбросано это добро по разным серверам. Гуру говорит - на каждом сервере слепи по хп, запускай их remotely, а результат сваливай локально в таблицу. Ну тут конкретно такие проблемы видятся - разные таблицы на разных серверах могут иметь разную структуру, поэтому в одну центральную таблицу могут не захотеть полезть. Так что или переменное количество времянок, или N постоянных (с предварительным truncate), что б уж точно на всех хватило. О, вот теперь нештяк. Были данные распределённые, а я их все к себе подгрёб. Вот тока однако вопрос - как это мне существенно поможет с моим скриптом? Мне как надо было перебирать тучу вариантов до, так надо и после - если я не хочу использовать динамический SQL. И при этом совершенно не важно где нахоятся данные - локально или распределённо - просто экспонента растёт так быстро, что до исполнения скрипта дело может и не дойти - типа рука бойца писать устанет.

Поэтому лучше чесно сказать девушке что архитектура её приложения неудачная, и до тех пор пока этот факт не изменится, будет она использовать динамический SQL, никуда не денется, ну может слегка приукрасит парой примочек которые "не совсем динамический SQL".
26 фев 04, 03:23    [551606]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Crimean
Member

Откуда:
Сообщений: 13148
2 mikhail_n

А по делу предложить нечего?
26 фев 04, 11:38    [552037]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
I
Guest
2mikhail_n
Всё правильно, только таблицы на разных серверах и в разных базах одинаковые, что несколько упрощает задачу. А с архитектурой я ничего поделать не могу. Изначально не предполагалось, что придётся собирать и сравнивать некоторую информацию по разным клиентам. Собсвенно задача для системы уникальная и запускаться к исполнению будет ночью или в конце рабочего дня. Я поняла о чем говорил Crimean, но тогда мне этих вложеных одна-в-другую прцедур понадобиться слишком много.
Спасибо всем.
26 фев 04, 17:42    [553256]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Если бы процесс, хотя бы схематично, был бы расписан по-подробнее, то, возможно, было бы и простое решение для этой проблемы.
Задачка при наличии одинаковых баз становится достаточно простой.
Вопрос будет только в возможностях передачи инфы с сервера на сервер и в возможности инициирования локальных расчетов, если это будет необходимо.
Это все от того , что в любом случае задача обработки инфы , распределенной по нескольким серверам , имеет две фазы решения - локальная обработка данных на каждом из участников и сбор информации на том участнике, который является координатором процесса.
Пачку "процедур-в-процедуре" делать не надо. Достаточно воспользоваться sp_executesql, но при этом предпочтительнее делать вызовы так, чтобы в каждом конкретном случае информация приходила туда, где будет сохраняться, а не сохранялась там, где было указано.
26 фев 04, 18:00    [553313]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
?
Guest
2Crimean
Хорошо.
'INSERT INTO '+ @MyServer +'.’ + @MyDatabase +’ .dbo.tblMyTable1 SELECT * FROM tblMyTable2 WHERE MyField in (SELECT MyField2 FROM ‘ + @MyServer2 +'.’ + @MyDatabase2 +’ .dbo.tblMyTable3)'
Как можно заслать @MyServer2, @MyDatabase2 во второй SELECT? Опять таки, я упрощаю на самом деле там их несколько и всё гораздо сложнее.
26 фев 04, 18:15    [553371]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Исходный запрос

'INSERT INTO '+ @MyServer +'.’ + @MyDatabase +’ .dbo.tblMyTable1
SELECT * FROM tblMyTable2 WHERE MyField in
(SELECT MyField2 FROM ‘ + @MyServer2 +'.’ + @MyDatabase2 ’ .dbo.tblMyTable3)'

Работаем мы, для порядку, на Server0.Base0

То есть у нас каскадные вычисления?

И запрос можно трактовать как:

Надо сделать на Server.Base "INSERT INTO tblMyTable1"
Для этого надо на Server.Base получить от Server0.Base0 "SELECT * FROM tblMyTable2 WHERE MyField in"
А для этого на Server0.Base0 надо получить с Server2.Base2 результат от "SELECT MyField2 FROM dbo.tblMyTable3".

Вариантов достаточно много.
Я предлагаю рассмотреть вот такой:

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

Server.Base для того, чтобы сделать INSERT запрашивает у Server2.Base2 результат от "SELECT MyField2 FROM dbo.tblMyTable3". Потом запрашивает у Server0.Base0 результат "SELECT * FROM tblMyTable2"
Потом сам делает обработку условия WHERE MyField in и остаток вставляет себе в tblMyTable1

Вариант еще один - Server.Base просит Server0.Base0 дать ему результат от "SELECT MyField2 FROM dbo.tblMyTable3", для этого Server0.Base0 просит Server2.Base2 "SELECT MyField2 FROM dbo.tblMyTable3".

Продолжать можно бесконечно долго...

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

Опять же, если задачу ЕЩЕ уточнить, то, возможно, будет еще более конкретное или простое решение...
26 фев 04, 19:30    [553487]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
?
Guest
2Crimean

Спасибо, я поняла идею. Пошла думать.
26 фев 04, 19:34    [553496]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Crimean
Member

Откуда:
Сообщений: 13148
В итоге "идея" заключается в том, что
- нужен тот, кто будет руководить. иначе будет бардак. любая операция должна начинаться по инициативе "диспетчера". если что-то ломается, то решение о том, откуда начинать, принимает дичпетчер. это не моя идея (в сторону), так работает, скажем, MS DTC, ну да ладно
- каждый участник умеет делать что угодно со своими данными и просить какую-то заранее оговоренную порцию данных (путем вызова заранее известной хранимки) от любого участника. участник, предполагается, умеет отдавать порции данных (у него есть заранее написанные хранимки и вобще некий набор хранимок типа системного каталога есть у всех участников и это все синхронно с точки зрения версий)

при таком построении не будет вопросов, что когда и кому делать, не будет вопросов с секурити - каждый ведь работает только в рамках своей базы, а в рамках своей базы все секурные вопросы решаются очень просто, а "снаружи" будут проситься только заранее оговоренные данные, отдачу которых можно жестко регламентировать (давать права на те самые хранимки). не будет вопросов и с порядком выполнения шагов - за всем следит диспетчер, все действия (начало и конец) у него логируются и после любого краха работа начинается с последнего ЗАКОНЧЕННОГО действия, по возможности откатив последнее незаконченное

и т.д.

а если все лезут ко всем , то это хаос :) вот в этом и была моя изначальная идея .
26 фев 04, 20:59    [553583]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
mikhail_n
Guest
А по делу предложить нечего?

2?

Ладно, попробую по делу. Да, то что предлагает Crimean должно упорядочить сбор всех необходимых данных на одном центральном сервере - диспетчере и, скорее всего, даст выигрыш по быстродействию. Можно и "..Написать процедуру обработки данных. Поднять ее на нужных серверах.." - при условии конечно, что Ваша, скажем так, server-среда не гетерогенная - т.е. не разбавленна всякими шалостями типа Ораклов и alike, чего, вообщем то, из Вашего постинга не следует. Однако будем по умолчанйю считать что Ваша среда гомогенная.

Дальше, Вы выбрали "звезду", написали диспетчера... Решило это Вашу проблему - слава богу, игнорируйте всё ниже следующее. Нет - гляньте дальше...

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

Ну что ж, с учётом того, что все таблицы имеют одинаковую структуру, можно попытаться. На диспетчере создаёте две таблицы - одну для хранения данных DataStore с тем же набором столбцов что и у остальных таблиц плюс одна дополнительно ID, IDENTITY, другую для хранения статистики

create table DataStat
(ServerName varchar(?) NOT NULL,
LowID int NOT NULL,
HighID int NOT NULL)

Дальше,

create procedure SomeName @proc sysname, @ServerName varchar(??) as

declare @LowID int, @HighID int, @LastID int

-- the following two lines are exclusive
-- intellectual property of Crimean
insert into DataStore(ColA, ColB,..../*,ID*/)
exec @ proc

select @LastID = max(HighID) from DataStat
select @LowID = min(ID) from DataStore where ID > @LastID
select @HighID = max(ID) from DataStore where ID > @LastID

insert into DataStat
values(@ServerName, @LowID, @HighID)

теперь, Ваш диспетчер вначале
truncate DataStore
truncate DataStat

и потом вызывает SomeName для каждого фактически переданого сервера. В результате всё локализовано в двух таблицах, так что при вменяемом числе реально встречающихся в жизни комбинаций серверов есть шанс написать статический скрипт. Хотя... мутно всё это пока, но и так весь обеденный перерыв ушёл на печать. На последок - будьте морально готовы к тому, что потратив N ж-пачасов (извините, но уж привык измерять работу программиста в этих единицах), реализуя чёй бы то ни было совет, с удивлением обнаружить что Ваш старый ugly динамический SQL работал быстрее чем новый - просто когда в локальную таблицу сливаются данные с удалённых серверов с частотой ...дцать раз в минуту, у сервера-диспетчера нет ни одного шанса собрать сколь-нибудь вменяемую статистику на эту таблицу.
26 фев 04, 22:04    [553617]     Ответить | Цитировать Сообщить модератору
 Re: SP, которая работает с объектами на другом сервере  [new]
Crimean
Member

Откуда:
Сообщений: 13148
2 mikhail_n

Пока идет вытягивание из "?" реальной схемы работы.
Все варианты и каскад и звезда и ... пока равновероятны и ни один может не подойти в явном виде. Возможно там действительно придется все переделывать, но большой динамический запрос всяко хуже , если , конечно , у руля этого запроса не стоит "клиент" с инструментом типа грид наперевес.

автор
Хотя... мутно всё это пока


Это и будет мутно. Тут никто реальное ТЗ не ставит и не реализует. Так, между делом советы бросают, не более того.

автор
потратив N ж-пачасов , реализуя чёй бы то ни было совет


А мысли не было, что собственные идеи иссякли? И что весьма отвлеченный пример может просто натолкнуть на новую идею?

автор
у сервера-диспетчера нет ни одного шанса собрать сколь-нибудь вменяемую статистику на эту таблицу


Не читаем классику aka BOL... Совсем, похоже...

P.S.Вы спросите, каков же тут мой интерес? Он есть, как ни странно. Тема мне достаточно близка и, возможно, какая-то комбинация идей "выстрелит". Соответственно, у меня будет шанс "потратив N ж-пачасов , реализуя чёй бы то ни было совет" (ц) mikhail_n попробовать применить эту комбинацию идей у себя с возможным получением прямых или косвенных выгод.
26 фев 04, 22:44    [553635]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить