Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
Столкнулся со следущей проблемой. Допустим на сервере есть всего 2 лицензии(все очень условно). И вот подключаются одновременно 3 пользователя. 1 и 2 из которых пытаются выпольнить довольно длительную операцию поиска по тексту, в то время как 3-му надо всего навсего прочесть пару строк(это все к примеру). Можно ли как-то приостановить поиск одного (1 или 2) пользователя, и выполнить короткий запрос 3-го, а после опять продолжить поиск, но уже не сначала, а продолжить. Вообще можно ли как-нибудь устанавливать приоритеты на выполнение запросов. ВОТ Зараннее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2002, 12:30 |
|
||
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
Глория!!! Отвечай! Мне тоже очень интересно!!! Помните топик про индексы, которые сервер не использует (как бы зря не использует)??? А дело всё, видимо, в приоритетах запросов. Без нагрузки на сервер время выполнения запроса с индексами (с использованием индексов) и без оных было одинаковым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2002, 13:06 |
|
||
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
Глория!!! Отвечай! Мне тоже очень интересно!!! Помните топик про индексы, которые сервер не использует (как бы зря не использует)??? А дело всё, видимо, в приоритетах запросов. Без нагрузки на сервер время выполнения запроса с индексами (с использованием индексов) и без оных было одинаковым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2002, 13:08 |
|
||
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
Вот те на! неужели никто знает. Хотя бы где посмотреть. Очень срочно нужно! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2002, 13:50 |
|
||
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
Документированных возможностей НЕТ. Возможно через свою расширенную хранимую процедуру (пример имеется в книге Ken Henderson "The Guru's Guide to SQL Server ...."), но это довольно сомнительный путь, с точки зрения усточивости работы всего сервера. IMHO оптимизвции производительности нужно(и можно) достигать засчет анализа узких мест(это может быть не только запрос, но и оборудование) и их "расширения" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2002, 14:00 |
|
||
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
2 Glory Хорошо, хотя ничего хорошего , а возможно ли как-нибудь убивать процесс с длительным поиском. В кончном счете пользователь и сам знает что поиск штука долгая. Как можно организовать свою, ну опять же "приоритетность", что ли, и затем в поцедурах, требующих "немедленного" реагирования, просто напросто выкидовать длятельные запросы. Понимаю, что пользователь который что-то хочет "поискать" грубо говотя "обречен" , и все же? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2002, 14:32 |
|
||
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
2 Glory Да у вас случайно нет ссылочки на Ken Henderson "The Guru's Guide to SQL Server ...." Спасибо за помощь! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2002, 14:42 |
|
||
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
Как можно организовать свою, ну опять же "приоритетность", На стороне сервера, для текущего коннекта BOL - Transact-SQL Reference - SET - SET QUERY_GOVERNOR_COST_LIMIT для всех запросов BOL - Administering SQL Server - Managing Servers - Setting Configuration Options - query governor cost limit Option На стороне клиента - асинхронный режим выполнения и своя "логика" определения "жертвы" ЗЫ Можно также задуматься о применении OLAP средств, если есть действительно долгие запросы (хотя не факт, есть скажем теже самые секционированные представления) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2002, 14:45 |
|
||
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
У меня есть сама книга. Интернетовских вариантов не встречал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2002, 14:47 |
|
||
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
в самом деле для меня достаточно непонятен вопрос лицензирования... в общем - то никогда не сталкивался с такого рода ограничениями... может кто прокомментирует? на глаза попалась фраза из одной из технических статей. ... О дополнительных лицензиях можно тоже не беспокоиться, если выбрана модель лицензирования "Per server". В этом случае с одной машины может быть сколько угодно коннектов к sql-серверу, это все равно будет занимать ровно одну клиентскую лицензию. в самом деле выходит если пользователь открывает дополнительный коннект скажем из адошного рекордсета при выборе per user ему нужна будет еще лицензия? а для чего userid и workstationid в свойствах соединения? а что будет если у всех (равноправных)клиентов они одинаковые? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2002, 07:48 |
|
||
|
Приоритеты выполнения запросов?
|
|||
|---|---|---|---|
|
#18+
>...меня достаточно непонятен вопрос лицензирования... Это не только для тебя непонятно. Это вообще логике не поддается, почему при модели лицензирования "Per Server" на каждое клиентское место (независимо от числа коннектов оттеда) расходуется одна лиценция, а при модели "Per Site" одна лицензия расходуется на каждый коннект. > а для чего userid и workstationid в свойствах соединения? к лицензиям это не имеет никакого отношения. Лицензии считает сторонняя (по отношению к MSSQL) утилита, которая не в курсе о параметрах подключения. Ей интересен только сам факт коннекта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2002, 11:08 |
|
||
|
|

start [/forum/topic.php?fid=46&fpage=3488&tid=1823237]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 265ms |
| total: | 383ms |

| 0 / 0 |
