Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22592
vugluscr
Да, технология для территориально уд. подразделений.
А какой у тебя вид деятельности? Когда людей по домам посадить можно?
(у меня есть такой, но я пока один так работаю, из дома)


Не всех. Маркетологи, программеры, контентщики вполне могуть работать по домам...

ИМХО оффтопик.
25 авг 06, 20:00    [3055925]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
На счет VPN - ну и что что вы поверх трех его построите? Там же получается организация одной сети...

А чем не подходит вариант c MQ сервисами? Все ведь давно разработано... На сервере есть очереди сообщений и есть подписчики - как только появляется возможность сервер отсылает подписчикам собщения (данные)...
25 авг 06, 20:54    [3056048]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22592
SanyL
А чем не подходит вариант c MQ сервисами? Все ведь давно разработано... На сервере есть очереди сообщений и есть подписчики - как только появляется возможность сервер отсылает подписчикам собщения (данные)...


Знаете-ли, к MSMQ меня-таки никто не отослал, когда я вытался в свое время на разных форумах решить этот вопрос. Кроме того, насколько я понимаю, этот подход все равно требует установки сервера сообщений, причем на контроллере домена, и клиентских компонентов. Т.е. мы получаем зависимость работы работы от другого сервера. Поправьте меня, если я не прав.
25 авг 06, 21:08    [3056071]     Ответить | Цитировать Сообщить модератору
 Неплохая идея использования возможностей ADO - вполне достойная FAQ по ADO  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
хорошо бы код этого фрагмента.
Ну текста тут как такового нет - смотри рисунок. Здесь выдвинута идея использования некоторых стандартных возможностей ADODB.Connection для оповещения об изменения в рекордсетах.

К справедливой критике этого подхода, указанной автором:
процесс, в результате работы которого должно возникнуть оповещение, должен иметь права процессадмина чтобы выполнить команду KILL, права на которую не могут быть делегированы. Впрочем, процессадмины имеют право только на KILL и на назначение этих прав другим пользователям, что опять же ограничивается командой KILL.
KILL не может быть использована внутри транзакции (в частности - в триггере). Если есть необходимость использования оповещения из триггера, можно запустить KILL отдельным процессом через sp_start_job.
если по каким-то причинам клиент не получит хотя бы одного события ExecuteComplete, то он перестанет следить за событиями сервера, так как процедура ожидания не запустится заново. В частности, это может произойти у программиста при работе с отладчиком, когда событие возникло, а клиентское приложение было в режиме паузы. Ну и на ADO стопроцентной надежды нет, в асинхронном режиме работает из рук вон плохо. Я сделал так - на имеющийся у меня ежеминутный (для других целей) таймер повесил проверку, если вдруг объект Command не находится в режиме adStateExecuting, то запускается процедура инициализации соединения.
я, наверное, добавлю еще несколько своих соображений:

1. Специфика базы MASTER, возможная зависимость ее от версии SQL - от этого ненадежность прямой работы в ней.
2. Невозможность организации прокси-сервера (как в случае оповещения по TCP/IP), те SQL должен напрямую иметь ВНЕШНИЙ IP. Комментарии излишни.
3. Оповещение по TCP/IP поддерживает ПУЛЬСАЦИЮ, (фрагмент кода в самом низу рисунка). Здесь конечно никакой пульсации нет и удаленные соединения через TCP/IP сеть будут рваться.
4. Еще одна причина неконкурентности такого оповещения относительно оповещений по TPC/IP - оповещение по TCP/IP передает произвольные ДАННЫЕ от сервера к клиенту, ну например в каком именно рекордсете произошло событие. Здесь, конечно, обьект ADODB.Connection таких возможностей не предоставляет.
5.
плохо масштабируемое решение
Я наверное присоединюсь к этому мнению, ибо вся логика развития доступа к данным построена НА СКОРЕЙШЕМ ОСВОБОЖДЕНИИ клиентом SQL-сервера. Для чего вообще в Микрософте делали ADO.NET?

К сообщению приложен файл. Размер - 0Kb
25 авг 06, 21:15    [3056077]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
Да зависимость получаете... Только не помню на счет именно на сервере с АД - надо почитать (даже помню что вроде необязательно)... Но не думаю что это вам так сильно помешает... А на счет клиента - так если вы посмотрите add/remove programs и зайдете на вкладку компанент windows - то поймете что установка на клиенте труда не занимает (1 минуты хватит)... Знаю что есть аналоги у других производителей...

Кстати если вы пишете чтото свое - то всеравно будет создан сервер (ваш, сервер не физический а программный) зависимость от которого получите, как и с MSMQ...

На счет "к MSMQ меня-таки никто не отослал" - посмотрите мой первый пост в этом топике...

Потом если у вас совсем душа не лежит к этому софту - то можете хотябы технологию посмотреть, может заинтересует и на мысли интересные сможет натолкнуть... Однако, на мой взгляд, это именно то что вам надо.
25 авг 06, 21:23    [3056089]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Там в Command.Timeout единичка осталась (смотрел коды возврата). Для работы конечно там 600 надо.
25 авг 06, 21:25    [3056092]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Я к сожалению не понял ответа SANL - если это было для меня.

Что касается зависимости, ну вы ж понимаете насколько SYSPROCESS разный скажем в SQL 6.5 и SQL2005. Именно эту позицию я имел в первом своем пункте.
25 авг 06, 21:29    [3056098]     Ответить | Цитировать Сообщить модератору
 Re: Неплохая идея использования возможностей ADO - вполне достойная FAQ по ADO  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22592
sysadm2000
1. Специфика базы MASTER, возможная зависимость ее от версии SQL - от этого ненадежность прямой работы в ней.


Не понял. К базе master я никак не обращаюсь.

sysadm2000
2. Невозможность организации прокси-сервера (как в случае оповещения по TCP/IP), те SQL должен напрямую иметь ВНЕШНИЙ IP. Комментарии излишни.


Если я УЖЕ присоединился к SQL-серверу, значит все нужные настройки уже сделаны. И даже наоборот - для отдельного прокси сервера мне нужно организовывать ДОПОЛНИТЕЛЬНЫЕ настройки.

sysadm2000
3. Оповещение по TCP/IP поддерживает ПУЛЬСАЦИЮ, (фрагмент кода в самом низу рисунка). Здесь конечно никакой пульсации нет и удаленные соединения через TCP/IP сеть будут рваться.


Соединение с SQL-сервером не рвется даже при больших таймаутах. Видимо пульсация поддерживается самим соединением ADO-SQLSERVER

sysadm2000
4. Еще одна причина неконкурентности такого оповещения относительно оповещений по TPC/IP - оповещение по TCP/IP передает произвольные ДАННЫЕ от сервера к клиенту, ну например в каком именно рекордсете произошло событие. Здесь, конечно, обьект ADODB.Connection таких возможностей не предоставляет.


Да, это так. Но это небольшая проблема, так как данные в любом виде сервер предоставит клиенту. Главное - пнуть клиента, чтобы он их взял.
А если нужен обмен данными прямо в сообщении, зачем тогда SQL? Тут как раз можно воспользоваться MSMQ.

sysadm2000
5.плохо масштабируемое решение
Я наверное присоединюсь к этому мнению, ибо вся логика развития доступа к данным построена НА СКОРЕЙШЕМ ОСВОБОЖДЕНИИ клиентом SQL-сервера. Для чего вообще в Микрософте делали ADO.NET?


При работе с отвязанными клиентами - вполне справедливо. Но с точки зрения ресурсов - кто-то все равно должен поддерживать непрерывное TCP-соединение с клиентом, будет это SQL-сервер или другая прога.
Да и тот же функции оповещения ADO.NET. Не думаю, что SQL-сервер сможет оповестить клиента о событии, если все соединения в данный момент разорваны. Как он отыщет этого клиента?
25 авг 06, 21:29    [3056100]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22592
SanyL
На счет "к MSMQ меня-таки никто не отослал" - посмотрите мой первый пост в этом топике...


...год назад, когда я впервые занялся этим вопросом.

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


Я уже взглянул, спасибо за подсказку. Тем не менее, свою проблему я решил именно таким способом, который описал, а MSMQ буду иметь ввиду.
25 авг 06, 21:32    [3056103]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Не понял. К базе master я никак не обращаюсь.
Ну а где таблицы процессов брать?

Если я УЖЕ присоединился к SQL-серверу, значит все нужные настройки уже сделаны.
Хорошо, согласен.

Видимо пульсация поддерживается самим соединением ADO-SQLSERVER
Не уверен в случае WAITFOR

кто-то все равно должен поддерживать непрерывное TCP-соединение с клиентом
НИКТО НЕ ДОЛЖЕН - ЭТО И НАЗЫВАЕТСЯ МАСШТАБИРУЕМЫМ РЕШЕНИЕМ

Не думаю, что SQL-сервер сможет оповестить клиента о событии, если все соединения в данный момент разорваны
Notification - сложная и накрученная система. А ServiceBroker - это еще одна накрутка сверху на нее. Она следит, чтоб не рвались соединения. Но не SQL-соединения, а Notification-соединения. Ну SQL вся эта пирамида грузит конкретно. Не сомневаюсь в этом, хотя протестить под нагрузкой пока не довелось...

Ну не кто не говорит, что эта идея совсем плохая. Просто она ОГРАНИЧЕННАЯ. Заточенная на АДО, на админский логин, на версию SQL, не невозможность получить в оповещении какие-либо данные и тд
25 авг 06, 21:41    [3056126]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Я имел ввиду конечно масштабируемость - это отсутсвие SQL-соединений. TCP-соединения никак на масштабируемость решения не влияют. Надо смотреть решения в прокси-сервере оповещений. У него есть конечно какие-то ограничения по числу коннектов. Но я знаю, как сделать его практически неограниченно масстабируемым. Это иное, более сложное решение, чем примененное сейчас. Основанное на вызовах асинхронных делегатов в другом потоке. Ну думаю, пару тысяч коннектов прокси выдержит и без этой фишки.
25 авг 06, 21:46    [3056138]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22592
sysadm2000
Не понял. К базе master я никак не обращаюсь.
Ну а где таблицы процессов брать?


Зачем их вообще брать? Достаточно функции @@spid.

sysadm2000
Видимо пульсация поддерживается самим соединением ADO-SQLSERVER
Не уверен в случае WAITFOR


Ну так проверил. В случае работы с прокси-сервером соединение рвалось минут за пять неактивности (видимо промежуточными шлюзами при соединении через интернет).

sysadm2000
Ну SQL вся эта пирамида грузит конкретно. Не сомневаюсь в этом, хотя протестить под нагрузкой пока не довелось...


Дык. Может в итоге мой вариант и дешевле выйдет :)

sysadm2000
Заточенная на АДО, на админский логин, на версию SQL


Насколько я понял из сегодняшней переписки, связку ADO.NET+SQL2005 мало кто использует на данный момент. Ну, конечно, с этой идеей я все-таки опоздал года эдак на четыре :), но если хотя бы двум-трем людям идея окажется полезной, значит не зря все это...

Привязки к админскому логину здесь нет, под SQL2005-м - работает.
25 авг 06, 21:52    [3056151]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Дык. Может в итоге мой вариант и дешевле выйдет
По масштабируемости с Notification+Broker? Не сомневаюсь... Но уверен, что не дешевле TCP/IP оповещения...

Привязки к админскому логину здесь нет
KILL будет из какого логина выдан?

Насчет пульсации я пожалуй погорячился. Видимо ADO ее выполняет.

связку ADO.NET+SQL2005 мало кто использует на данный момент
Такой вывод нельзя делать оценивая переписку этого топика. Для такой оценки надо:
1.Просмотреть разделы этого форума по ADO.NET, ASP.NET, VB.NET
2.Оценить количество сайтов на указанных технологиях - http://www.rambler.ru/srch?set=www&words=.aspx&btnG=%CD%E0%E9%F2%E8%21
3.Осознать, что САМЫЕ посещаемые сайты в россии сделаны исключительно технологиях https://www.mts.ru, http://www.beeline.ru/, http://www.webmoney.ru , http://www.megafon.ru/, http://www.interfax.com/, http://www.microsoft.com, https://www.sql.ru, http://www.rsdn.ru, http://www.mosbuild.com ,.....
25 авг 06, 22:55    [3056291]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22592
sysadm2000
Привязки к админскому логину здесь нет
KILL будет из какого логина выдан?


UP
из процессадминского. Но не из админского.
25 авг 06, 23:00    [3056310]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Не уловил эту мысль. KILL надо выдавать НА ЧУЖОЙ ОЖИДАЮЩИЙ ПРОЦЕСС.
Те скажем мы модифицировали рекордсет одним юзером (A), каким-то третьим путем (не описанным здесь***) определили, что модификации ЭТОГО рекордсета ждет НЕКТО (B) - нашли его SPID в таблице SYSPROCESS и выдали из ПРОЦЕССА (A) KILL НА ПРОЦЕСС (B), ОЖИДАЮЩИЙ МОДИФИКАЦИИ.
***логика (кто-кого ждет) тут не обсуждается вообще...
25 авг 06, 23:10    [3056329]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22592
sysadm2000
Не уловил эту мысль. KILL надо выдавать НА ЧУЖОЙ ОЖИДАЮЩИЙ ПРОЦЕСС.


Да, но права на KILL не зависят от того, "свой" этот процесс или "чужой"

sysadm2000
нашли его SPID в таблице SYSPROCESS и выдали из ПРОЦЕССА (A) KILL НА ПРОЦЕСС (B), ОЖИДАЮЩИЙ МОДИФИКАЦИИ.


Да. Только поиск идет не в SYSPROCESS (как я уже упоминал, база master не опрашивается напрямую), а во внутренней таблице подключенных зарегистрированных пользователей (которая, кстати, и так есть в базе для других целей, например для определения, кто из пользователей сейчас "онлайн"). Это позволяет убить "правильный" ожидающий процесс другого пользователя, а не какой попало.
25 авг 06, 23:20    [3056361]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
А ну если своим софтом создавать свой аналог SYSPROCESS, тогда да, насчет MASTER и админского логина - пункт снимается тоже. Правда я не совсем понимаю, как отловить тогда, чей именно это подвисший коннект. Логин у всех одинаковый, все висят на одной команде Waitwor. Чем юзер (B) отличается от юзера (С)? Ну если только перед Waitfor прогнать ОБЫЧНУЮ (не асинхронную) команду и в ней вернуть @@SPID. Тогда да - из кода выше можно просто сделать класс, который имеет входное свойство - ConnectionString и EVENT Notification. И лепить это класс везде, где требуется оповещение. Только если кто будет делать из кода, который лежит выше - обратите внимание, что после Notification.Close нужно еще Motification=nothing (кроме Timeout=600) - иначе не избежать утечек памяти...

--

Еще я не понял SanyL, который проталкивал идею MSMQ. Это же и есть оповещение по TCP/IP, в противовес которому автор топика выдвинул идею использоваться ВСТРОЕННЫЕ возможности АДО.

Только вместо
Dim TCP = new System.Net.Sockets.TcpListener
программирование ведеться в пространстве имен
Dim MSMQ = new System.Messaging.Message
Ну там чуть другая адресация (типа ".\\MyPapeMyNotification$\\"), ну и некоторые приблуды насчет более гарантированной доставки пакетов засчет резервированного канала.
Знаете-ли, к MSMQ меня-таки никто не отослал
Я просто думаю, что автор топика не очень хорошо понимает технику программирования MSMQ и думает, что драйвер оповещения на MSMQ будет СУЩЕСТВЕННО отличаться от драйвера оповещения просто на TCP или UDP.
26 авг 06, 06:07    [3056809]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
aleks2
Guest
Shocker.Pro
I
триггер (реагирующий на нужное событие), который прерывает ожидание в вызванной клиентом процедуре.


ИМХО чтобы прервать процедуру, нужно, чтобы она выполняла какие-нибудь действия (например в цикле) - а это дополнительная нагрузка на сервер, в то время, как waitfor сервер не грузит.


Ожидание снятия блокировки... эээ... тоже не грузит сервер. Анализируй это.

Зачем рвать/устанавливать соединение, когда проще ждать разблокировки , например, таблички или даже строки в табличке в той же самой асинхронной процедуре?
26 авг 06, 09:46    [3056852]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
sysadm2000

Еще я не понял SanyL, который проталкивал идею MSMQ. Это же и есть оповещение по TCP/IP, в противовес которому автор топика выдвинул идею использоваться ВСТРОЕННЫЕ возможности АДО.


Лично я понял что автор пытается создать некоторое ее подобие, а одной из мыслей высказанных мною - организовать все на подобии данной системы... Но кроме того, если ты не заметил, но всеже автора заинтересовал в некоторой степени данный вариант... Да речь шла о том чтобы ни ставить ни чего дополнительного на клиента - но иногда стоит посмотреть в сторону...
26 авг 06, 10:22    [3056870]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22592
sysadm2000
Ну если только перед Waitfor прогнать ОБЫЧНУЮ (не асинхронную) команду и в ней вернуть @@SPID. Тогда да - из кода выше можно просто сделать класс, который имеет входное свойство - ConnectionString и EVENT Notification.


И опять UP. Ничего никуда не возвращается:

Shocker.Pro
1) На клиенте есть процедура инициализации соединения. Она запускается при старте клиента и создает объект Connection, предназначенный специально для оповещения, его нельзя использовать для других целей. В этой процедуре клиент уведомляет сервер о собственном подключении и сервер регистрирует у себя в таблице подключенных клиентов SPID этого соединения.

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

aleks2
Ожидание снятия блокировки... эээ... тоже не грузит сервер. Анализируй это.Зачем рвать/устанавливать соединение, когда проще ждать разблокировки


Можно и так. ИМХО, все же больше грузит... Поток waitfor скорее всего переводит поток в режим sleeping, а ожидание разблокировки должен как-то проверять освобождение. Впрочем, не готов рассуждать о вещах, в которых плохо разбираюсь. Только для этого метода требуется еще один процесс, который будет удерживать все эти блокировки для каждого клиента по отдельности, значит это еще ресурсы... И как поведет себя сам сервер, увидев столь длительную блокировку, не посчитает ли он этот процесс зависшим и не убъет ли... В общем, мне кажется, этот метод сложнее, хотя обладает несомненным преимуществом - не нужны права на KILL.

SanyL
Да речь шла о том чтобы ни ставить ни чего дополнительного на клиента - но иногда стоит посмотреть в сторону...


Да, кстати, скажу - почему. В случае аварии (тьфу, тьфу, тьфу) желательно как можно быстрее восстановить работоспособность сервера, счет идет на минуты. Если сервер умирает аппаратно, значит надо запускать sql на другой тачке, и чем меньше там надо будет делать настроек, тем лучше. Опять же, сеть развивается, меняются IP, шлюзы, имена и т.п., приходится перенастраивать два приложения, вместо одного.
26 авг 06, 10:58    [3056899]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10824
Блог
Есть ещё один минус :( https://www.sql.ru/articles/mssql/2005/101906InsideSQLServer2000UMS.shtml#10
26 авг 06, 11:02    [3056903]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22592
Александр Гладченко
Есть ещё один минус :( https://www.sql.ru/articles/mssql/2005/101906InsideSQLServer2000UMS.shtml#10


Вот началась конструктивная критика, которую я ждал вчера

Гм. Как-то не очень внятно написано. С одной стороны, можно сделать вывод, что число исполнителей не может превысить 255. С другой стороны мы знаем, что SQL-сервер способен обслуживать сотни тысяч пользовалетей одновременно, и вряд ли такой лимит может удовлетворить эти нужды. Опять же не понял: UMC не дает переключаться процессору на другой поток во время исполнения запроса, но мы-то знаем, что несколько запросов вполне могут выполняться одновременно даже на одном процессоре... В общем, статья требует пояснений во многих местах (по крайней мере для меня :).

Тем временем, пока выходные, попробую создать три сотни соединений с waitfor и посмотрю, как сервер будет себя вести.
26 авг 06, 11:43    [3056927]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
aleks2
Guest
Shocker.Pro

aleks2
Ожидание снятия блокировки... эээ... тоже не грузит сервер. Анализируй это.Зачем рвать/устанавливать соединение, когда проще ждать разблокировки


Можно и так. ИМХО, все же больше грузит... Поток waitfor скорее всего переводит поток в режим sleeping, а ожидание разблокировки должен как-то проверять освобождение.


waitfor тоже должен проверять, что наступил час Ч. Не считай создателей сервера идиотами, которые при ожидании снятия блокировки опрашивают в цикле: "ё блокировка?"
26 авг 06, 12:14    [3056954]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10824
Блог
Shocker.Pro

Вот началась конструктивная критика, которую я ждал вчера

Гм. Как-то не очень внятно написано. С одной стороны, можно сделать вывод, что число исполнителей не может превысить 255. С другой стороны мы знаем, что SQL-сервер способен обслуживать сотни тысяч пользовалетей одновременно, и вряд ли такой лимит может удовлетворить эти нужды.


255 - это по умолчанию в 2000-м, в 2005-м этот параметр сделали динамическим. Никто не мешает увеличить это значение, если нужно...

Shocker.Pro

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


Увы, это похоже так, и не противоречит многопотоковости... Занимается ведь не процессор, а исполнитель (это абстракция потока/нити). Когда исполнитель впадает в ожидание, насколько я понял, он просто прописывает себя в списке ожидающих и ждёт, когда его из этого состояния выведут другие исполнители (если не вдаваться в детали).
26 авг 06, 12:26    [3056969]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22592
Александр Гладченко
Увы, это похоже так, и не противоречит многопотоковости... Занимается ведь не процессор, а исполнитель (это абстракция потока/нити). Когда исполнитель впадает в ожидание, насколько я понял, он просто прописывает себя в списке ожидающих и ждёт, когда его из этого состояния выведут другие исполнители (если не вдаваться в детали).


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

Хотя может быть под состоянием ожидания подразумевается, например, ожидание поступления данных из дисковой подсистемы во время выполнения, скажем, сканирования индексов... То есть выборка-то выполняется, но в конкретный момент не требует ресурсов процессора. Тогда понятно, о чем речь. Тогда получается, что запрос с мощными формульными расчетами может существенно затормозить выполнение других запросов.
26 авг 06, 13:08    [3057013]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить