|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаВыборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. О Боже ! В каком отдельном потоке вы собрались обрабатывать локальную временную таблицу ??? Вы хоть читали в хелпе хоть что нибудь про временные таблицы ? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:12 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
GloryАцкийСкотонаПовторяю еще раз. Если сто раз повторить "халва", то во рту слаще не станет АцкийСкотонаМне надо чтобы "SELECT * INTO #T_INSERTED FROM INSERTED" выполнялось так же быстро, как и "SELECT * INTO #T_INSERTED2 FROM Charge_Details"(это таблица на которой триггер, если чо). Что непонятного?:) Ну не устраивает меня 45 секунд против 0,5. Повторяю еще раз (гы) - кнопки "Работай быстро" не существует. Если "переливание" всех данных из временной таблицы во временную таблицу работает медленно, то нет программных средств ускорения. Халва. :) Так почему из физической таблицы переливание 0,5 сек, а с инсертед 45 сек? У вас есть или нет ответ на этот вопрос? Или вам просто подискутировать охота?:) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:12 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаДля тех, кто не читал тему целиком. Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка?Да мне все равно, зачем вы ее производите. Если вам нужно "ехать", то процесс массового обновления записей надо строить по-другому, чтобы не лезть в псевдо-таблицы. Если "шашечки", ну, дисков там купите, SSD, плату флешовую за $50к для tempdb. Программиста, в конце концов, наймите, чтобы сделал все за вас. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:14 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаТак почему из физической таблицы переливание 0,5 сек, а с инсертед 45 сек? Потому что это разные таблицы в разных базах. Сюрприз ??? АцкийСкотонаУ вас есть или нет ответ на этот вопрос? Или вам просто подискутировать охота?:) Какая дискуссия может быть при отсутствии у вас знаний предметной области ? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:14 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаТак почему из физической таблицы переливание 0,5 сек, а с инсертед 45 сек? У вас есть или нет ответ на этот вопрос? Или вам просто подискутировать охота?:) Потому что, для переливания из inserted, серверу ее предварительно приходиться создавать и заливать туда данные. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:15 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
GloryАцкийСкотонаВыборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. О Боже ! В каком отдельном потоке вы собрались обрабатывать локальную временную таблицу ??? Вы хоть читали в хелпе хоть что нибудь про временные таблицы ? Так, не надо щас вот тут издыханий вашего ЧСВ а. Всё просто. В триггере копируется во временную таблицу, в CLRке(вызываемой в триггере) херачится в XML оба буфера и отдается сервисброкером другому процессу. Другой процесс распарсит хмл, прочухает какие поля обновились, а какие нет. Сформирует результирующий ХМЛ. Создаст строки в таблице логов. Вот. Заставили такие меня свою идею раскрыть. :) Еще вопросы есть? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:17 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
Гавриленко Сергей АлексеевичАцкийСкотонаДля тех, кто не читал тему целиком. Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка?Да мне все равно, зачем вы ее производите. Если вам нужно "ехать", то процесс массового обновления записей надо строить по-другому, чтобы не лезть в псевдо-таблицы. Если "шашечки", ну, дисков там купите, SSD, плату флешовую за $50к для tempdb. Программиста, в конце концов, наймите, чтобы сделал все за вас. На личности съезжаемс, товарищ? Вам по ходу кроме как трепнуть чушь больше интелект не позволяет. Прошу отлучиться от обсуждения данной темы. Вам по видимому место в болтологии. Никак не тут. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:19 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаВыборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка? В отдельном потоке обработать данные из локальной временной таблицы?! Чтоб "не задерживаться в триггере" есть Service Broker. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:19 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
ART-CODEВсе, разобрались. Код: sql 1.
Срочно забудьте это навсегда! Что, по-Вашему, делает функция UPDATE()? Я не очень понял, в чём именно я был прав :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:19 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
GloryАцкийСкотонаТак почему из физической таблицы переливание 0,5 сек, а с инсертед 45 сек? Потому что это разные таблицы в разных базах. Сюрприз ??? АцкийСкотонаУ вас есть или нет ответ на этот вопрос? Или вам просто подискутировать охота?:) Какая дискуссия может быть при отсутствии у вас знаний предметной области ? Молодец, орёл! Конечно же физическая таблица и ее инсертед\делетед В РАЗНЫХ БАЗАХ. Ваша копметентность в плане программирования БД пошатнулась в моих глазах. Прошу больше чуши не нести. Если есть что сказать по теме- с радостью выслуашую. Дальше бред мне слушать не интерсно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:21 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаМне сейчас объяснили что датапровайдеры по умолчанию при апдейте поля в датасете апдейтят ВСЕ поля в бд для этой записи. Кто мешает не использовать датасет? Есть куча ORM, которые отслеживают изменения и пишут только их... АцкийСкотонаДе вы видели ТЗ, которое диктует как работать фреймворкам? Таких нет. Но если у программиста кривые руки, то, конечно, виноват фреймворк. АцкийСкотонаМне надо чтобы "SELECT * INTO #T_INSERTED FROM INSERTED" выполнялось так же быстро, как и "SELECT * INTO #T_INSERTED2 FROM Charge_Details" попробуйте переписать на insert into #T_INSERTED (перечислите явно столбцы) select перечислите явно столбцы from INSERTED АцкийСкотонаДля тех, кто не читал тему целиком. Выборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка? Зря. К тому же для логирования можно Service Broker использовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:23 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
pkarklinАцкийСкотонаВыборку из инсертед я произвожу да бы потом в отдельном потоке ее обработать. Чтобы не задерживаться на этом в триггере. Теперь понятно зачем мне выборка? В отдельном потоке обработать данные из локальной временной таблицы?! Чтоб "не задерживаться в триггере" есть Service Broker. Так я двумя постами выше же сказал что сервисброкером буду работать. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:23 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаГавриленко Сергей Алексеевичпропущено... Да мне все равно, зачем вы ее производите. Если вам нужно "ехать", то процесс массового обновления записей надо строить по-другому, чтобы не лезть в псевдо-таблицы. Если "шашечки", ну, дисков там купите, SSD, плату флешовую за $50к для tempdb. Программиста, в конце концов, наймите, чтобы сделал все за вас. На личности съезжаемс, товарищ? Вам по ходу кроме как трепнуть чушь больше интелект не позволяет. Прошу отлучиться от обсуждения данной темы. Вам по видимому место в болтологии. Никак не тут. Модератор: На личности съехали исключительно вы, я ни вас, ни ваш интеллект, ни то, где вам место, не обсуждал. Еще раз позволите себе такое поведение, и вы форум покинете. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:23 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаВсё просто. В триггере копируется во временную таблицу, в CLRке(вызываемой в триггере) херачится в XML Еще вопросы есть? Угу. Как Вы из CLR достучитесть до локальной временной таблицы? Даже если достучались, с чего Вы решили, что CLR будет работать асинхронно по отношению к триггеру? Почему прямо в триггере не сформировать XML (на такую большу таблицу при полном апдейте, правда он будет не хилый) и поставить сообщение в очередь SB? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:23 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаТак, не надо щас вот тут издыханий вашего ЧСВ а. Всё просто. В триггере копируется во временную таблицу, в CLRке(вызываемой в триггере) херачится в XML оба буфера и отдается сервисброкером другому процессу. Другой процесс распарсит хмл, прочухает какие поля обновились, а какие нет. Сформирует результирующий ХМЛ. Создаст строки в таблице логов. Вот. Заставили такие меня свою идею раскрыть. :) Еще вопросы есть? Двойной фейспалм. Заставить сервер создать временную таблицу inserted. Чтобы скопировать ее во другую временную таблицу. Чтобы на ее основе создать xml. Чтобы его передать куда-то. Чтобы его потом распарсить. Чтобы что-то определить. Чтобы на основе этого создать еще один xml. Который потом добавить в таблицу. Это тянет на Нобелевку Пойдука я лучше в другие темы. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:23 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
Гавриленко Сергей АлексеевичАцкийСкотонапропущено... На личности съезжаемс, товарищ? Вам по ходу кроме как трепнуть чушь больше интелект не позволяет. Прошу отлучиться от обсуждения данной темы. Вам по видимому место в болтологии. Никак не тут.Модератор: На личности съехали исключительно вы, я ни вас, ни ваш интеллект, ни то, где вам место, не обсуждал. Еще раз позволите себе такое поведение, и вы форум покинете. Пардон муа. Предоставьте хотя бы слух об паттерне работы триггера, который как-то отрабатывает изменения строк своей таблицы, но апдейтит зависимые таблицы без сущностей INSERTED\DELETED. Итак. Поехали. У меня два таблицы. 1. Шапки документов. 2. Строки документов. Я поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATED. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:27 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаГавриленко Сергей Алексеевичпропущено... Модератор: На личности съехали исключительно вы, я ни вас, ни ваш интеллект, ни то, где вам место, не обсуждал. Еще раз позволите себе такое поведение, и вы форум покинете. Пардон муа. Предоставьте хотя бы слух об паттерне работы триггера, который как-то отрабатывает изменения строк своей таблицы, но апдейтит зависимые таблицы без сущностей INSERTED\DELETED. Итак. Поехали. У меня два таблицы. 1. Шапки документов. 2. Строки документов. Я поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATED.Я вам по секрету скажу: это можно сделать без триггера быстро. Или с триггером долго. Выбирайте. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:29 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаПредоставьте хотя бы слух об паттерне работы триггера, который как-то отрабатывает изменения строк своей таблицы, но апдейтит зависимые таблицы без сущностей INSERTED\DELETED. Итак. Поехали. У меня два таблицы. 1. Шапки документов. 2. Строки документов. Я поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATED. Гм... Триггер, не единственный способ (а м.б. и не самый лучший) реализации поставленной задачи. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:30 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаЯ поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATEDДля этого не нужен триггер (хотя вот у нас тоже в триггере сделано). Индексированное представление вместо шапки! ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:30 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
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.10.2014, 14:35 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
Гавриленко Сергей АлексеевичАцкийСкотонапропущено... Пардон муа. Предоставьте хотя бы слух об паттерне работы триггера, который как-то отрабатывает изменения строк своей таблицы, но апдейтит зависимые таблицы без сущностей INSERTED\DELETED. Итак. Поехали. У меня два таблицы. 1. Шапки документов. 2. Строки документов. Я поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATED.Я вам по секрету скажу: это можно сделать без триггера быстро. Или с триггером долго. Выбирайте. Так я ж жду, говорите. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:36 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
iap, UPDATE() Есть, конечно, свои минусы.возвращает TRUE независимо от того, была ли попытка применить операторы INSERT или UPDATE удачной. Давно сам ее не использовал (лет 7 уже), потому забыл. Ну, можно просто сравнивать старое и новое значение. Возможно, COLUMNS_UPDATED есть. не очень понял, в чём именно я был прав Да, можно искать измененные данные, если они были изменены специально, осмысленно, а не вся таблица скопом перезаписывается и ищи в этой каше - какая же строка на самом деле обновилась. Изначально было сказано, что обновляются ВСЕ ЗАПИСИ. И лишь потом пришло уточнение что не все записи а все поля. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:38 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
iapАцкийСкотонаЯ поменял сумму в строке. Как триггер строк должен выйти на шапки и изменить общую сумму кроме как с использованием INSERTED\UPDATEDДля этого не нужен триггер (хотя вот у нас тоже в триггере сделано). Индексированное представление вместо шапки! Не прокатит. У строк должны быть ссылки на сущность их содержащую. Таблиц в базе не ДВЕ. А сотни. Многие взаимодействуют со многими. Вообще реализация БД это не тема данной беседы. Архитектура релизована так как реализована. Насколько мне изместно конкурентов у нас по этой тебе адекватных нет. Давайте больше реализацию БД обсуждать не будем. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:38 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
ART-CODEiap, UPDATE() Есть, конечно, свои минусы.возвращает TRUE независимо от того, была ли попытка применить операторы INSERT или UPDATE удачной. Давно сам ее не использовал (лет 7 уже), потому забыл. Ну, можно просто сравнивать старое и новое значение. Возможно, COLUMNS_UPDATED есть. не очень понял, в чём именно я был прав Да, можно искать измененные данные, если они были изменены специально, осмысленно, а не вся таблица скопом перезаписывается и ищи в этой каше - какая же строка на самом деле обновилась. Изначально было сказано, что обновляются ВСЕ ЗАПИСИ. И лишь потом пришло уточнение что не все записи а все поля. И лишь потом пришло уточнение что не все записи а все поля. БЛ базы обновляет конкретные. Это клиентская часть в некоторых реализациях апдейтит все поля строки БД, которые были в датасете. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:41 |
|
Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
---|---|---|---|
#18+
АцкийСкотонаВообще реализация БД это не тема данной беседы. Архитектура релизована так как реализована. Насколько мне изместно конкурентов у нас по этой тебе адекватных нет. Давайте больше реализацию БД обсуждать не будем. Если так, то нужна конкретика. Вот я попытался воспроизвести проблему, у меня не получилось такой задержки (правда я на 2014 ctp1 проверял, нет на работе 2014rtm). Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41.
Случай, что вторая выборка в первый раз идет ощутимо быстрее, примерно 45 секунд против 5 секунд (на моей машине), за счет того, что в первый раз данные поднимаются в кэш, второй раз быстро, и могут вымываться между тестами - мы ведь исключаем? т.е. проблема у вас воспроизводится постоянно и не зависит от того в каком порядке идут в тестовом триггере выборка из inserted и таблицы? Соответственно, если хотите конкретики - модифицируйте скрипт так, чтобы проблема воспроизвелась, либо предоставьте свой. Если это проблема воспроизводится только у вас, из-за вашей конфигурации оборудования/настроек/магнитных полей, то необходимо предоставить информацию по ожиданиям. Вы писали: авторНикаких. Нулл в типе ожидания. Может вы не правильно смотрели, или не в тот момент? Попробуйте собрать ожидания при помощи события sqlos.wait_info Короче, чтобы адресовать вашу проблему предметно нужно либо иметь репро, либо иметь какие-то данные того, что происходит на сервере. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 14:59 |
|
|
start [/forum/topic.php?fid=46&msg=38782932&tid=1700245]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
165ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 285ms |
0 / 0 |