Добрый день, товарищи!
Столкнулся с проблемой долгой выборки из дрянотаблиц INSERTED\DELETED в [таблицу\временную_таблицу\табличную_переменную].

Конкретнее. Имеем два стейтмента.

SELECT "ПОЛЕ" INTO #T_INSERTED FROM INSERTED
и
SELECT "ПОЛЕ" INTO #T_INSERTED FROM "Таблица_на_которой_стоит_триггер"

В таблице 350000 записей. Проводится апдейт всех записей по некому полю, думаю не важно по какому.
Результат: 45сек и 0,5 сек. Притом результат один и тотже что выбирать ВСЕ столбцы, что один какой либо. Даже если написать
SELECT 1 INTO #T_INSERTED FROM INSERTED
, то всеравно будет тарабанить 45 сек.

Кто сталкивался? Есть вообще идеи почему к обращению к INSERTED\DELETED идет так долго?
з.ы. SELECT 1 FROM INSERTED тоже тарабанит 45 сек. Вообще без разницы что пытаешься сделать- время всегда одно и тоже. Ну за исключением попытки фильтрации и сортировки оных псевдотейблов.

Да, мне надо их потом, асинхронно обработать. Для логирования вобщем надо. :)

pkarklin,

Никаких. Нулл в типе ожидания.

2pkarklin, для инсертеда статистика ИО не доступна. По крайней мере мне не выдает. Только по физической табличке.

2Владислав Колосов, так я написал же что там. там сейчас два запроса. Вам прямо конкретные названия моих таблиц надо? Бесполезны они вам будут. :)

2iap, я с радостью с Вам потрещу по этой теме потом. Когда Вы столкнетесь с необходимостью логирования изменений большго объема. :)

msLex, в ресурсе тоже пусто.

2Владислав Колосов, товарищ, давайте вы найдете где-нибудь у себя в закромах табличку с 300000+ записей и с порядка 70 полями. Запустите апдейт какого-либо поля по всем записям, в триггере напишете SELECT 1 FROM INSERTED , заключив этот запрос в SELECT GETUTCDATE() . И только потом будете утверждать что я что то тут выдумываю. Договорились? ;)

pkarklin, "Table 'FD_Charge_Details'. Scan count 566, logical reads 8981, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0."

Владислав, Остальное в тирггере не выполняется. После обозначенных запросов ретурн поставл я.

iap, таки у вас есть способ решить проблему с которой я столкнулся или нет? :) давайте по существу пожалуйста. :)

iap, это вот таг. :)

iap, пардон. рука на контролэнтер дрогнула. :)

SET STATISTICS IO ON
SET STATISTICS TIME ON
SELECT GETUTCDATE(), 'START'


SELECT F_Division, LINK INTO #T_INSERTED FROM INSERTED
SELECT GETUTCDATE(), 'INSERTED'



SELECT * INTO #T_INSERTED2 FROM PE.FD_Charge_Details
SELECT GETUTCDATE(), 'FD_Charge_Details'


SET STATISTICS TIME OFF
SET STATISTICS IO OFF

pkarklin, Вот всё что в мессаге.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 13 ms.

SQL Server Execution Times:
CPU time = 48971 ms, elapsed time = 49592 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
Table 'FD_Charge_Details'. Scan count 566, logical reads 8981, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 4927 ms, elapsed time = 583 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

pkarklinАцкийСкотона,

SET установите в баче, который запускает UPDATE, а не в триггере.


тож самое. за исключением что промелькнули еще таблицы, ключи на которые я апдейтил. но затор не там же.

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'ED_Registr_Pts_Period'. Scan count 1, logical reads 266, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'ED_Registr_Pts'. Scan count 1, logical reads 402, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'ED_Network_Pts'. Scan count 1, logical reads 2949, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'FD_Charge_Details'. Scan count 566, logical reads 8981, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server parse and compile time:
CPU time = 11919 ms, elapsed time = 11951 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
Вот вход в триггер
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

Это селект из инсертеда.
SQL Server Execution Times:
CPU time = 49091 ms, elapsed time = 48702 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
Table 'FD_Charge_Details'. Scan count 566, logical reads 8981, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Это напрямую из таблицы на которой висит триггер.
SQL Server Execution Times:
CPU time = 5758 ms, elapsed time = 580 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 66768 ms, elapsed time = 61235 ms.

(342399 row(s) affected)

iapАцкийСкотонаiap, таки у вас есть способ решить проблему с которой я столкнулся или нет? :) давайте по существу пожалуйста. :)Я, кажется, догадался.
Речь идёт о легендарном "универсальном триггере"?
Который по метаданным собирает запрос логгирования для полей любой таблицы,
к которой прицеплен такой "универсальный триггер"?

Ф точку. Только триггер не посвящен целиком логированию, там еще бизнес-логика. :) И с чего же легендарный он? От завершения меня отделяет только эта идиотская задержка, которой я моуг по идее принебречь. Подождут пользаки уже немонго. Всеравно вола валяют почти весь день. :)

iapАцкийСкотонаОт завершения меня отделяет только эта идиотская задержкаВот именно!
Вот поэтому-то я давным-давно бросил эту идею.
Плавали - знаем.

Я тоже бросил затею делать это в самом триггере. :) Вот поэтому то мне и надо слизать псевдотаблички. Да бэ в другом процессе по ним неспешай пройтись. :) Ну и идея еще в универсальности кода логирования. Таблиц не одна сотня. Каждый раз переделывать везде- проще застрелиться.

Shakill, Облом ВЕЗДЕ. Сгенереный код тоже не видит инсертед\делетед. Я уже все перепробовал. Единственный сопоб- утащить эти таблички и потом их обрабатывать. :)

iapАцкийСкотонапропущено...


Я тоже бросил затею делать это в самом триггере. :) Вот поэтому то мне и надо слизать псевдотаблички. Да бэ в другом процессе по ним неспешай пройтись. :) Ну и идея еще в универсальности кода логирования. Таблиц не одна сотня. Каждый раз переделывать везде- проще застрелиться.Проще логгировать записи, в которых изменилось хоть что-то, целиком.
И с таким логом проще жить потом.

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



Ну так что, знает кто причину почему тормозит выборка с псевдотаблиц?:)

ShakillАцкийСкотонаShakill, Облом ВЕЗДЕ. Сгенереный код тоже не видит инсертед\делетед. Я уже все перепробовал. Единственный сопоб- утащить эти таблички и потом их обрабатывать. :)

насчет генератора кода я имел в виду не формирование динамики в триггере (хотя и туда можно передать через табличную переменную), а генерация самого триггера на основе шаблона и указания таблицы, на которой он будет висеть.

Не катит. Таблиц сотни. Потом в таких шаблонах черт ногу сломит. Да и ошибки трудно будет искать.

iapАцкийСкотонаТак чтобы их целиком логировать мне какраз таки и надо прежде сохранить псевдотаблицы.Странное утверждение.
Главное, что надо сделать - забыть об универсальности.
И заниматься логгированием каждой таблицы в отдельности.
Можно, например, создать таблицы-логи с почти идентичной оригиналам структурой
с помощью генерирования скриптов таблиц с обработкой полученного текста в каком-нибудь приличном редакторе.

Кроме тогго, текст логгирования для триггеров КАЖДОЙ ТАБЛИЦЫ
можно получить универсальным запросом ОДИН РАЗ (скорость, как понимаете, уже не очень-то и важна!).
Да что там! Это логгирование можно оформить как отдельный триггер,
а бизнес-логика пусть будет в другом! Триггеров же может быть много!
Получится для каждой таблицы свой текст триггера, но сформированный не вручную, а запросом.

Главное, что надо сделать - забыть об универсальности.
Увы, не могу без нее спать. :)

И заниматься логированием каждой таблицы в отдельности.
Сейчас итак так сделано. В каждом(необходимом) триггере в конце код логирования. И если схему логирвоания изменить, то мне придется помирать на применении новой идеи из-за 1000+ таблиц в базе.

Можно, например, создать таблицы-логи с почти идентичной оригиналам структурой
с помощью генерирования скриптов таблиц с обработкой полученного текста в каком-нибудь приличном редакторе.
Шо я собственно и делаю путем SELECT * INTO #T_INSERTED FROM INSERTED

Кроме тогго, текст логгирования для триггеров КАЖДОЙ ТАБЛИЦЫ
можно получить универсальным запросом ОДИН РАЗ (скорость, как понимаете, уже не очень-то и важна!).
1. Повторяю еще раз. В триггере помимо кода логирования еще есть код, который не сгенерить.
2. Отдельных триггеров использовать возможности нет. Фист и ласт атрибуты заюзаны.
3. Скорость еще как тут важна, уж поверьте. :)
4. Код триггера должен в проекте быть, да бы иметь возможность рефакторинга.

Да что там! Это логгирование можно оформить как отдельный триггер,
а бизнес-логика пусть будет в другом! Триггеров же может быть много!
1. Можно, но должно оно быть в определенном. :)
2. Когда их много очережность выполнения гарантируется только для First- и Last- триггера. Такое не катит мне. :)

Получится для каждой таблицы свой текст триггера, но сформированный не вручную, а запросом.
Логирующий код я итак могу сформировать в зависимости от таблицы и того, какие поля в ней изменены. Притом сделать это на лету. :)
К тому же, чтото никто не вспомнил тут про то, что АДО при апдейте апдейтит ВСЕ записи. :) Поэтому код триггера еще должен исключать неизмененные поля в записях да бы снизить жирность логов.

Вот думаете если бы всё просто можно было просто сделать как говорите я бы не сделал что ли. :) Я заморачиваюсь не просто так, а надо ибо.
Советы про то как логировать мне наверно не нужны. Я уже сам знаю как всё организовать. Мне только надо понять почему дико тормозит вборка из псевдотаблиц. Хоят в конечном итоге я на нее могу забить. Расчет у меня всеравно по нескольку часов идет. Что мне эти несчтастные 45-145 секунд. :)

Итак, для вновь прибывших. :)
Меня интересует именно торможение при выборке из псевдотаблиц. Как логировать я уже сориентировался. :)

pkarklinАцкийСкотона,
Scan count 566 - очень много. Интересно, какой результат будет, если вы уберете триггер и воспользуетесь кляузой OUTPUT в UPDATE?
Это еще мало. Аутпут мне бесполезен по идее. Но как он проходит сейчас поосмтрю.


tarrusАцкийСкотонапропущено...
Не катит. Таблиц сотни. Потом в таких шаблонах черт ногу сломит. Да и ошибки трудно будет искать.
В единообразном коде, хранящемся в системе контроля версий, изменяемом централизованно и единообразно для всех таблиц? Скорее в вашей затее черт ногу сломит.
Попробуйте сначала хотя бы номрально представить себе код, который генерит триггеры, хранящийся в системе контроля версий. :) Потом представьте что у вас изменилось 100-300 таблиц. Потом еще некоторые талбицы объеденились, некоторые разъеденились в новые. И заетм представьте себе как вы будете свой ацкий гениальный генерирующий триггеры код рефакторить. Обязательно мне сообщите сколько времени у вас ушло с сколько ведер слюны вы наплевали.


ART-CODEКогда включаем репликацию на сервере (publisher), она сама вешает на все таблицы триггеры.
И создает спец. таблицы в которых накапливает не отреплецированные данные.
Чем не хорошая заготовка для системы логирования ?
Реплика- страшный сон. Вообще про нее не говорите мне пожалуйста. Намного правильнее заюзать технологии "Change tracking" или "Change Data Capture". Но увы и ах! На БД с "Memory optimized tables" данные технологии включить невозможно. Очередной дикополезнобесполезный функционал от мелкософта(эт я про MET).


pkarklinАцкийСкотонаНу так что, знает кто причину почему тормозит выборка с псевдотаблиц?:)
Начиная с 2005, для получения данных из псевдо таблиц используется версионное хранилище в tempdb. Она у Вас не может являться узким местом?
Честно сказать не понял. Можно поподробней про этом момент? Там насоклько знаю никакой версионности. Псевдотаблички на самом деле есть одна таблица, содержащая инсертед и делетед записи. Доступ через которые осуществляется через INSERTED\DELETED.

GloryАцкийСкотонаМеня интересует именно торможение при выборке из псевдотаблиц
Торможение - это бонус вашей универсальности.

Вообще то, чтобы изрекать тут что либо не по теме, прочитали бы сначала. Ну если вы не поняли, то объясню. Торможение псевдотаблиц не только не дает мне жить спокойно при доделывании универсального триггера, она так же тормозит остальную базнес-логику в триггере. Я уж не стал сразу гвоорить. Думал итак понятно будет. :)

ART-CODEАДО при апдейте апдейтит ВСЕ записи

Если я пишу

то обновятся все записи ?
Никогда не встречался с таким поведением. В какой версии (mdac, sqlncli) такое ?

Я хз в какой. Я разработкой интерфейса к нашей бд не занимаюсь. Просто мне сказали что так и происходит. Я бы конечно выловил запрос щас с клиента, да лень чота. Да и к теме не относится. :)

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

GloryАцкийСкотонаТорможение псевдотаблиц не только не дает мне жить спокойно при доделывании универсального триггера, она так же тормозит остальную базнес-логику в триггере.
Ну это же ваш выбор. Вы привели столько доводов в ответ на все возражения. И столько раз уверяли, что знаете, что делаете.
Что выбрали - то и получили.
Это не мой выбор. Это так задумано вообще. Есть таблицы. На них триггера. Люди с таблицами работают. Триггера срабатывают. Чтото там делают... Сэ ля ви же. Я то причом тут?:)


iapАцкийСкотонаАДО при апдейте апдейтит ВСЕ записи. :)Да неужели?!
К тому же, что мешает выполнять свой явный UPDATE?

Что касается логгирования только записей с изменениями,
то этому здесь посвещено столько постов, что как же Вы их не увидели-то?
Я и сам пару десятков раз участвовал...

Да! О порядке вызовов триггеров.
Если есть зависимость от порядка их вызова, то это уже плохой признак.
Но какая, чёрт возьми, разница, в каком по порядку будет выполняться логгирование?!


К тому же, что мешает выполнять свой явный UPDATE?
В клиенте? Вы работали сишарпом к бд хоть раз? Мне сейчас объяснили что датапровайдеры по умолчанию при апдейте поля в датасете апдейтят ВСЕ поля в бд для этой записи. Что бы сделать апдейт только апдейченых(гы), то там надо както заморачиваться еще. Не вдавался в подробности вобщем.


Что касается логгирования только записей с изменениями,
то этому здесь посвещено столько постов, что как же Вы их не увидели-то?
Я и сам пару десятков раз участвовал...
Да блин. Да не надо мне помощи в логировании. У меня есть отличный механизм. Мне только надо разобраться почему выборка с псевдотаблиц тормозит так. Сколько раз повторить еще?:)


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


Я и сам пару десятков раз участвовал...
Прошу прощенья за нескромный вопрос. А хоть раз реально помогли вопрошающим? Или как и мне только и говорите что я везде неправ? ;)