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) такое ?

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