Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
Glory
Member

Откуда:
Сообщений: 104751
АцкийСкотона
Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере.

О Боже !
В каком отдельном потоке вы собрались обрабатывать локальную временную таблицу ???
Вы хоть читали в хелпе хоть что нибудь про временные таблицы ?
21 окт 14, 14:12    [16736756]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
Glory
АцкийСкотона
Повторяю еще раз.

Если сто раз повторить "халва", то во рту слаще не станет

АцкийСкотона
Мне надо чтобы "SELECT * INTO #T_INSERTED FROM INSERTED" выполнялось так же быстро, как и "SELECT * INTO #T_INSERTED2 FROM Charge_Details"(это таблица на которой триггер, если чо). Что непонятного?:) Ну не устраивает меня 45 секунд против 0,5.

Повторяю еще раз (гы) - кнопки "Работай быстро" не существует.
Если "переливание" всех данных из временной таблицы во временную таблицу работает медленно, то нет программных средств ускорения.

Халва. :)


Так почему из физической таблицы переливание 0,5 сек, а с инсертед 45 сек? У вас есть или нет ответ на этот вопрос? Или вам просто подискутировать охота?:)
21 окт 14, 14:12    [16736757]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
АцкийСкотона
Для тех, кто не читал тему целиком. Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка?
Да мне все равно, зачем вы ее производите. Если вам нужно "ехать", то процесс массового обновления записей надо строить по-другому, чтобы не лезть в псевдо-таблицы. Если "шашечки", ну, дисков там купите, SSD, плату флешовую за $50к для tempdb. Программиста, в конце концов, наймите, чтобы сделал все за вас.
21 окт 14, 14:14    [16736766]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
Glory
Member

Откуда:
Сообщений: 104751
АцкийСкотона
Так почему из физической таблицы переливание 0,5 сек, а с инсертед 45 сек?

Потому что это разные таблицы в разных базах. Сюрприз ???

АцкийСкотона
У вас есть или нет ответ на этот вопрос? Или вам просто подискутировать охота?:)

Какая дискуссия может быть при отсутствии у вас знаний предметной области ?
21 окт 14, 14:14    [16736767]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
msLex
Member

Откуда:
Сообщений: 9291
АцкийСкотона
Так почему из физической таблицы переливание 0,5 сек, а с инсертед 45 сек? У вас есть или нет ответ на этот вопрос? Или вам просто подискутировать охота?:)

Потому что, для переливания из inserted, серверу ее предварительно приходиться создавать и заливать туда данные.
21 окт 14, 14:15    [16736782]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
Glory
АцкийСкотона
Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере.

О Боже !
В каком отдельном потоке вы собрались обрабатывать локальную временную таблицу ???
Вы хоть читали в хелпе хоть что нибудь про временные таблицы ?

Так, не надо щас вот тут издыханий вашего ЧСВ а.
Всё просто. В триггере копируется во временную таблицу, в CLRке(вызываемой в триггере) херачится в XML оба буфера и отдается сервисброкером другому процессу. Другой процесс распарсит хмл, прочухает какие поля обновились, а какие нет. Сформирует результирующий ХМЛ. Создаст строки в таблице логов.
Вот. Заставили такие меня свою идею раскрыть. :)
Еще вопросы есть?
21 окт 14, 14:17    [16736797]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
Гавриленко Сергей Алексеевич
АцкийСкотона
Для тех, кто не читал тему целиком. Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка?
Да мне все равно, зачем вы ее производите. Если вам нужно "ехать", то процесс массового обновления записей надо строить по-другому, чтобы не лезть в псевдо-таблицы. Если "шашечки", ну, дисков там купите, SSD, плату флешовую за $50к для tempdb. Программиста, в конце концов, наймите, чтобы сделал все за вас.


На личности съезжаемс, товарищ? Вам по ходу кроме как трепнуть чушь больше интелект не позволяет. Прошу отлучиться от обсуждения данной темы. Вам по видимому место в болтологии. Никак не тут.
21 окт 14, 14:19    [16736816]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
АцкийСкотона
Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка?


В отдельном потоке обработать данные из локальной временной таблицы?! Чтоб "не задерживаться в триггере" есть Service Broker.
21 окт 14, 14:19    [16736818]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
iap
Member

Откуда: Москва
Сообщений: 47144
ART-CODE
Все, разобрались.
IF UPDATE(somefield) BEGIN
Срочно забудьте это навсегда!
Что, по-Вашему, делает функция UPDATE()?

Я не очень понял, в чём именно я был прав :))
21 окт 14, 14:19    [16736821]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
Glory
АцкийСкотона
Так почему из физической таблицы переливание 0,5 сек, а с инсертед 45 сек?

Потому что это разные таблицы в разных базах. Сюрприз ???

АцкийСкотона
У вас есть или нет ответ на этот вопрос? Или вам просто подискутировать охота?:)

Какая дискуссия может быть при отсутствии у вас знаний предметной области ?

Молодец, орёл! Конечно же физическая таблица и ее инсертед\делетед В РАЗНЫХ БАЗАХ.
Ваша копметентность в плане программирования БД пошатнулась в моих глазах. Прошу больше чуши не нести. Если есть что сказать по теме- с радостью выслуашую. Дальше бред мне слушать не интерсно.
21 окт 14, 14:21    [16736842]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
Arm79
Member

Откуда: МО, Раменское
Сообщений: 3695
АцкийСкотона
Мне сейчас объяснили что датапровайдеры по умолчанию при апдейте поля в датасете апдейтят ВСЕ поля в бд для этой записи.

Кто мешает не использовать датасет? Есть куча ORM, которые отслеживают изменения и пишут только их...
АцкийСкотона
Де вы видели ТЗ, которое диктует как работать фреймворкам?

Таких нет. Но если у программиста кривые руки, то, конечно, виноват фреймворк.
АцкийСкотона
Мне надо чтобы "SELECT * INTO #T_INSERTED FROM INSERTED" выполнялось так же быстро, как и "SELECT * INTO #T_INSERTED2 FROM Charge_Details"

попробуйте переписать на insert into #T_INSERTED (перечислите явно столбцы) select перечислите явно столбцы from INSERTED
АцкийСкотона
Для тех, кто не читал тему целиком. Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка?

Зря. К тому же для логирования можно Service Broker использовать.
21 окт 14, 14:23    [16736850]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
pkarklin
АцкийСкотона
Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка?


В отдельном потоке обработать данные из локальной временной таблицы?! Чтоб "не задерживаться в триггере" есть Service Broker.

Так я двумя постами выше же сказал что сервисброкером буду работать.
21 окт 14, 14:23    [16736851]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
АцкийСкотона
Гавриленко Сергей Алексеевич
пропущено...
Да мне все равно, зачем вы ее производите. Если вам нужно "ехать", то процесс массового обновления записей надо строить по-другому, чтобы не лезть в псевдо-таблицы. Если "шашечки", ну, дисков там купите, SSD, плату флешовую за $50к для tempdb. Программиста, в конце концов, наймите, чтобы сделал все за вас.


На личности съезжаемс, товарищ? Вам по ходу кроме как трепнуть чушь больше интелект не позволяет. Прошу отлучиться от обсуждения данной темы. Вам по видимому место в болтологии. Никак не тут.
Модератор: На личности съехали исключительно вы, я ни вас, ни ваш интеллект, ни то, где вам место, не обсуждал. Еще раз позволите себе такое поведение, и вы форум покинете.
21 окт 14, 14:23    [16736852]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
АцкийСкотона
Всё просто. В триггере копируется во временную таблицу, в CLRке(вызываемой в триггере) херачится в XML
Еще вопросы есть?


Угу. Как Вы из CLR достучитесть до локальной временной таблицы? Даже если достучались, с чего Вы решили, что CLR будет работать асинхронно по отношению к триггеру? Почему прямо в триггере не сформировать XML (на такую большу таблицу при полном апдейте, правда он будет не хилый) и поставить сообщение в очередь SB?
21 окт 14, 14:23    [16736855]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
Glory
Member

Откуда:
Сообщений: 104751
АцкийСкотона
Так, не надо щас вот тут издыханий вашего ЧСВ а.
Всё просто. В триггере копируется во временную таблицу, в CLRке(вызываемой в триггере) херачится в XML оба буфера и отдается сервисброкером другому процессу. Другой процесс распарсит хмл, прочухает какие поля обновились, а какие нет. Сформирует результирующий ХМЛ. Создаст строки в таблице логов.
Вот. Заставили такие меня свою идею раскрыть. :)
Еще вопросы есть?

Двойной фейспалм.
Заставить сервер создать временную таблицу inserted.
Чтобы скопировать ее во другую временную таблицу.
Чтобы на ее основе создать xml.
Чтобы его передать куда-то.
Чтобы его потом распарсить.
Чтобы что-то определить.
Чтобы на основе этого создать еще один xml.
Который потом добавить в таблицу.

Это тянет на Нобелевку
Пойдука я лучше в другие темы.
21 окт 14, 14:23    [16736858]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
Гавриленко Сергей Алексеевич
АцкийСкотона
пропущено...


На личности съезжаемс, товарищ? Вам по ходу кроме как трепнуть чушь больше интелект не позволяет. Прошу отлучиться от обсуждения данной темы. Вам по видимому место в болтологии. Никак не тут.
Модератор: На личности съехали исключительно вы, я ни вас, ни ваш интеллект, ни то, где вам место, не обсуждал. Еще раз позволите себе такое поведение, и вы форум покинете.

Пардон муа.
Предоставьте хотя бы слух об паттерне работы триггера, который как-то отрабатывает изменения строк своей таблицы, но апдейтит зависимые таблицы без сущностей INSERTED\DELETED.
Итак. Поехали. У меня два таблицы.
1. Шапки документов.
2. Строки документов.

Я поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATED.
21 окт 14, 14:27    [16736889]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
АцкийСкотона
Гавриленко Сергей Алексеевич
пропущено...
Модератор: На личности съехали исключительно вы, я ни вас, ни ваш интеллект, ни то, где вам место, не обсуждал. Еще раз позволите себе такое поведение, и вы форум покинете.

Пардон муа.
Предоставьте хотя бы слух об паттерне работы триггера, который как-то отрабатывает изменения строк своей таблицы, но апдейтит зависимые таблицы без сущностей INSERTED\DELETED.
Итак. Поехали. У меня два таблицы.
1. Шапки документов.
2. Строки документов.

Я поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATED.
Я вам по секрету скажу: это можно сделать без триггера быстро. Или с триггером долго. Выбирайте.
21 окт 14, 14:29    [16736912]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
АцкийСкотона
Предоставьте хотя бы слух об паттерне работы триггера, который как-то отрабатывает изменения строк своей таблицы, но апдейтит зависимые таблицы без сущностей INSERTED\DELETED.
Итак. Поехали. У меня два таблицы.
1. Шапки документов.
2. Строки документов.

Я поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATED.


Гм... Триггер, не единственный способ (а м.б. и не самый лучший) реализации поставленной задачи.
21 окт 14, 14:30    [16736913]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
iap
Member

Откуда: Москва
Сообщений: 47144
АцкийСкотона
Я поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATED
Для этого не нужен триггер (хотя вот у нас тоже в триггере сделано).

Индексированное представление вместо шапки!
21 окт 14, 14:30    [16736916]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
Arm79
АцкийСкотона
Мне сейчас объяснили что датапровайдеры по умолчанию при апдейте поля в датасете апдейтят ВСЕ поля в бд для этой записи.

Кто мешает не использовать датасет? Есть куча ORM, которые отслеживают изменения и пишут только их...
АцкийСкотона
Де вы видели ТЗ, которое диктует как работать фреймворкам?

Таких нет. Но если у программиста кривые руки, то, конечно, виноват фреймворк.
АцкийСкотона
Мне надо чтобы "SELECT * INTO #T_INSERTED FROM INSERTED" выполнялось так же быстро, как и "SELECT * INTO #T_INSERTED2 FROM Charge_Details"

попробуйте переписать на insert into #T_INSERTED (перечислите явно столбцы) select перечислите явно столбцы from INSERTED
АцкийСкотона
Для тех, кто не читал тему целиком. Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка?

Зря. К тому же для логирования можно Service Broker использовать.


1. я не интерфейс программирую, бд. про поведение датапровайдеров мне сами интерфесчики рассказали когда натолкнулись на это.
2. руки непричом. интерфейс делали давно. логирование появилось позже.
3. да хоть SELECT 1 FROM INSERTED написать. всеравно 45-47 секунд.
4. Что именно зря? Зачем мне лопатить миллионы записей в лог именно во время их апдейта? Пару минут и подождать могут. Не лезут же пользаки после каждой операции в лог, смотреть что там где проапдейтилось. Да большство планктона вообще не подозревает об существовании логирования. Хотя на основании которого переодически по шапке получает за ковыряние в базе.
21 окт 14, 14:35    [16736945]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
Гавриленко Сергей Алексеевич
АцкийСкотона
пропущено...

Пардон муа.
Предоставьте хотя бы слух об паттерне работы триггера, который как-то отрабатывает изменения строк своей таблицы, но апдейтит зависимые таблицы без сущностей INSERTED\DELETED.
Итак. Поехали. У меня два таблицы.
1. Шапки документов.
2. Строки документов.

Я поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATED.
Я вам по секрету скажу: это можно сделать без триггера быстро. Или с триггером долго. Выбирайте.


Так я ж жду, говорите.
21 окт 14, 14:36    [16736959]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
ART-CODE
Member

Откуда:
Сообщений: 1095
iap,
UPDATE()
Есть, конечно, свои минусы.
возвращает TRUE независимо от того, была ли попытка применить операторы INSERT или UPDATE удачной.
Давно сам ее не использовал (лет 7 уже), потому забыл.

Ну, можно просто сравнивать старое и новое значение.
Возможно, COLUMNS_UPDATED есть.

не очень понял, в чём именно я был прав

Да, можно искать измененные данные, если они были изменены специально, осмысленно,
а не вся таблица скопом перезаписывается и ищи в этой каше - какая же строка на самом деле обновилась.
Изначально было сказано, что обновляются ВСЕ ЗАПИСИ.
И лишь потом пришло уточнение что не все записи а все поля.
21 окт 14, 14:38    [16736982]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
iap
АцкийСкотона
Я поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATED
Для этого не нужен триггер (хотя вот у нас тоже в триггере сделано).

Индексированное представление вместо шапки!


Не прокатит. У строк должны быть ссылки на сущность их содержащую. Таблиц в базе не ДВЕ. А сотни. Многие взаимодействуют со многими.

Вообще реализация БД это не тема данной беседы. Архитектура релизована так как реализована. Насколько мне изместно конкурентов у нас по этой тебе адекватных нет. Давайте больше реализацию БД обсуждать не будем.
21 окт 14, 14:38    [16736987]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
ART-CODE
iap,
UPDATE()
Есть, конечно, свои минусы.
возвращает TRUE независимо от того, была ли попытка применить операторы INSERT или UPDATE удачной.
Давно сам ее не использовал (лет 7 уже), потому забыл.

Ну, можно просто сравнивать старое и новое значение.
Возможно, COLUMNS_UPDATED есть.

не очень понял, в чём именно я был прав

Да, можно искать измененные данные, если они были изменены специально, осмысленно,
а не вся таблица скопом перезаписывается и ищи в этой каше - какая же строка на самом деле обновилась.
Изначально было сказано, что обновляются ВСЕ ЗАПИСИ.
И лишь потом пришло уточнение что не все записи а все поля.


И лишь потом пришло уточнение что не все записи а все поля.
БЛ базы обновляет конкретные. Это клиентская часть в некоторых реализациях апдейтит все поля строки БД, которые были в датасете.
21 окт 14, 14:41    [16737022]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
АцкийСкотона
Вообще реализация БД это не тема данной беседы. Архитектура релизована так как реализована. Насколько мне изместно конкурентов у нас по этой тебе адекватных нет. Давайте больше реализацию БД обсуждать не будем.

Если так, то нужна конкретика.

Вот я попытался воспроизвести проблему, у меня не получилось такой задержки (правда я на 2014 ctp1 проверял, нет на работе 2014rtm).
+
set nocount on;
use master;
go
if db_id('d') is not null drop database d;
go
create database [d];
go
use [d];
go
create table t(
	[01] varchar(50),[02] varchar(50),[03] varchar(50),[04] varchar(50),[05] varchar(50),[06] varchar(50),[07] varchar(50),[08] varchar(50),[09] varchar(50),[10] varchar(50),
	[11] varchar(50),[12] varchar(50),[13] varchar(50),[14] varchar(50),[15] varchar(50),[16] varchar(50),[17] varchar(50),[18] varchar(50),[19] varchar(50),[20] varchar(50),
	[21] varchar(50),[22] varchar(50),[23] varchar(50),[24] varchar(50),[25] varchar(50),[26] varchar(50),[27] varchar(50),[28] varchar(50),[29] varchar(50),[30] varchar(50),
	[31] varchar(50),[32] varchar(50),[33] varchar(50),[34] varchar(50),[35] varchar(50),[36] varchar(50),[37] varchar(50),[38] varchar(50),[39] varchar(50),[40] varchar(50),
	[41] varchar(50),[42] varchar(50),[43] varchar(50),[44] varchar(50),[45] varchar(50),[46] varchar(50),[47] varchar(50),[48] varchar(50),[49] varchar(50),[50] varchar(50),
	[51] varchar(50),[52] varchar(50),[53] varchar(50),[54] varchar(50),[55] varchar(50),[56] varchar(50),[57] varchar(50),[58] varchar(50),[59] varchar(50),[60] varchar(50),
	[61] varchar(50),[62] varchar(50),[63] varchar(50),[64] varchar(50),[65] varchar(50),[66] varchar(50),[67] varchar(50),[68] varchar(50),[69] varchar(50),[70] varchar(50)
);

declare @i int = 0;
declare @sql nvarchar(max) = N'insert t select replicate(''a'',abs(checksum(newid())%50))';
while @i < 69 begin
	set @sql+=N',replicate(''a'',abs(checksum(newid())%50))'
	set @i+=1;
end
set @i = 0;
while @i < 350000 begin	
	exec sp_executesql @sql;
	set @i+=1;
end;
go
alter trigger tr_t_u on t for update
as
select getdate();
select a = 1 into #inserted from inserted;
select getdate();
select a = 1 into #t from t;
select getdate();
go

update t set [01] = replicate('a',abs(checksum(newid())%50));

Случай, что вторая выборка в первый раз идет ощутимо быстрее, примерно 45 секунд против 5 секунд (на моей машине), за счет того, что в первый раз данные поднимаются в кэш, второй раз быстро, и могут вымываться между тестами - мы ведь исключаем? т.е. проблема у вас воспроизводится постоянно и не зависит от того в каком порядке идут в тестовом триггере выборка из inserted и таблицы?

Соответственно, если хотите конкретики - модифицируйте скрипт так, чтобы проблема воспроизвелась, либо предоставьте свой.

Если это проблема воспроизводится только у вас, из-за вашей конфигурации оборудования/настроек/магнитных полей, то необходимо предоставить информацию по ожиданиям. Вы писали:
автор
Никаких. Нулл в типе ожидания.

Может вы не правильно смотрели, или не в тот момент? Попробуйте собрать ожидания при помощи события sqlos.wait_info

Короче, чтобы адресовать вашу проблему предметно нужно либо иметь репро, либо иметь какие-то данные того, что происходит на сервере.
21 окт 14, 14:59    [16737238]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить