Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
привет, форумчане. Я работаю в компании, по обслуживанию Колл-центов. У меня есть такая проблема, возможно кто-то поможет с решением(как вариант). У меня есть БД c: 1. таблицы: [DialerDetail], [Main] 2. процедура InsertScriptCall(вызывается при сохранении результата со скрипта(сайта)) и InsertDialerCall(вызывается при сохранении результатов звонков с дайлера) Процедура "InsertScriptCall" - сохраняет результат в таблицу [Main] Процедура "InsertDialerCall" - вытягивает данные с таблицы [DialerDetail], сводит данные и переносит в таблицу [Main]. В этих процедурах идет проверка на уникальность записей в таблице [Main] допустим по ключам RCD и RCKD. Если есть такие ключи, то происходит Update записи, если не находи, то происходит Insert Сложившееся проблема: Эти две процедуры могут вызваться одновременно и в итоге могут создаться дублирующие строчки с одинаковым RCD и RCKD. Я это заметил, когда увидел дубли и у них Дата создания отличается в пару долисекунд. Создание уникального индекса RCD и RCKD не вариант, так как есть ситуация, где надо создать еще одну строчку с теми же RCD и RCKD. Какие варианты мы рассматривали: 1. Прописать: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTION COMMIT TRANSACTION SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED В итоге получили много deadlock 2. пробовали еще вместо Update и Insert написать Merge, но появляется много зависших сессий. 3. думали создать еще одну таблицу для сохранения результатов процедуры "InsertScriptCall", например [ScriptResult]. и потом делать Job, которая по очереди перетягивает данные с таблицы [ScriptResult] и [DialerDetail] все в таблицу [Main] и тогда не будет дублей по одновременной вставке. Какие у вас есть варианты? Буду очень благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2019, 13:00 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
не гинеколог, но ... оставить основную таблицу в покое сделать две буферные таблицы на каждую нужду отдельно ночью сводить при необходимости в основную эти два буфера можно сделать память-оптимизированными для острастки как более злобный вариант - соорудить из этого всего вью, вставлять в неё подсунув потребителям вместо основной таблицы под её именем а основную таблицу переименовать новым красивым именем видел где-то у мс методику подмены вью, но не находится, может и выдумываю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2019, 14:38 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
ybuivovkСоздание уникального индекса RCD и RCKD не вариант, так как есть ситуация, где надо создать еще одну строчку с теми же RCD и RCKD.Фильтрованный уникальный индекс, который будет отсеивать такие ситуации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2019, 15:14 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
ybuivovk, конкурирующие процедуры можно разделить при помощи sp_getapplock. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2019, 15:41 |
|
||
|
Блокировки
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовybuivovk, конкурирующие процедуры можно разделить при помощи sp_getapplock. Одобряю. Вот тока, нынешние программизды понятия критической секции не проходили. ЗЫ. Прикола ради, можно блокировать не процедуру целиком, а значение "RCD и RCKD" ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2019, 16:11 |
|
||
|
|

start [/forum/topic.php?fid=46&fpage=104&tid=1687904]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
34ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 260ms |
| total: | 366ms |

| 0 / 0 |
