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

Откуда: Чебоксары
Сообщений: 56
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.
21 окт 14, 11:56    [16735508]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
iap
Member

Откуда: Москва
Сообщений: 47047
АцкийСкотона
iap, таки у вас есть способ решить проблему с которой я столкнулся или нет? :) давайте по существу пожалуйста. :)
Я, кажется, догадался.
Речь идёт о легендарном "универсальном триггере"?
Который по метаданным собирает запрос логгирования для полей любой таблицы,
к которой прицеплен такой "универсальный триггер"?
21 окт 14, 11:58    [16735533]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
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)
21 окт 14, 12:01    [16735558]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

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


Ф точку. Только триггер не посвящен целиком логированию, там еще бизнес-логика. :) И с чего же легендарный он? От завершения меня отделяет только эта идиотская задержка, которой я моуг по идее принебречь. Подождут пользаки уже немонго. Всеравно вола валяют почти весь день. :)
21 окт 14, 12:04    [16735590]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
iap
Member

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

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


Я тоже бросил затею делать это в самом триггере. :) Вот поэтому то мне и надо слизать псевдотаблички. Да бэ в другом процессе по ним неспешай пройтись. :) Ну и идея еще в универсальности кода логирования. Таблиц не одна сотня. Каждый раз переделывать везде- проще застрелиться.
21 окт 14, 12:15    [16735706]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
Shakill
Member

Откуда: мск
Сообщений: 1882
АцкийСкотона
Ну и идея еще в универсальности кода логирования. Таблиц не одна сотня. Каждый раз переделывать везде- проще застрелиться.
можно же написать генератор кода
21 окт 14, 12:20    [16735750]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
iap
Member

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


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

Откуда: Чебоксары
Сообщений: 56
Shakill, Облом ВЕЗДЕ. Сгенереный код тоже не видит инсертед\делетед. Я уже все перепробовал. Единственный сопоб- утащить эти таблички и потом их обрабатывать. :)
21 окт 14, 12:29    [16735822]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

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


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


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



Ну так что, знает кто причину почему тормозит выборка с псевдотаблиц?:)
21 окт 14, 12:32    [16735844]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
Shakill
Member

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


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

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

Кроме тогго, текст логгирования для триггеров КАЖДОЙ ТАБЛИЦЫ
можно получить универсальным запросом ОДИН РАЗ (скорость, как понимаете, уже не очень-то и важна!).
Да что там! Это логгирование можно оформить как отдельный триггер,
а бизнес-логика пусть будет в другом! Триггеров же может быть много!
Получится для каждой таблицы свой текст триггера, но сформированный не вручную, а запросом.
21 окт 14, 12:40    [16735899]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

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


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


Не катит. Таблиц сотни. Потом в таких шаблонах черт ногу сломит. Да и ошибки трудно будет искать.
21 окт 14, 12:43    [16735917]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
АцкийСкотона,

Scan count 566 - очень много. Интересно, какой результат будет, если вы уберете триггер и воспользуетесь кляузой OUTPUT в UPDATE?
21 окт 14, 12:49    [16735968]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
tarrus
Member

Откуда: Bergen
Сообщений: 831
АцкийСкотона
Shakill
пропущено...


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


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


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

Откуда: Москва (Муром)
Сообщений: 74925
АцкийСкотона
Ну так что, знает кто причину почему тормозит выборка с псевдотаблиц?:)


Начиная с 2005, для получения данных из псевдо таблиц используется версионное хранилище в tempdb. Она у Вас не может являться узким местом?
21 окт 14, 12:54    [16736018]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
ART-CODE
Member

Откуда:
Сообщений: 1092
Когда включаем репликацию на сервере (publisher), она сама вешает на все таблицы триггеры.
И создает спец. таблицы в которых накапливает не отреплецированные данные.
Чем не хорошая заготовка для системы логирования ?
21 окт 14, 12:55    [16736048]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
ART-CODE
Чем не хорошая заготовка для системы логирования ?


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

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

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


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

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

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

Шо я собственно и делаю путем SELECT * INTO #T_INSERTED FROM INSERTED

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

1. Повторяю еще раз. В триггере помимо кода логирования еще есть код, который не сгенерить.
2. Отдельных триггеров использовать возможности нет. Фист и ласт атрибуты заюзаны.
3. Скорость еще как тут важна, уж поверьте. :)
4. Код триггера должен в проекте быть, да бы иметь возможность рефакторинга.

Да что там! Это логгирование можно оформить как отдельный триггер,
а бизнес-логика пусть будет в другом! Триггеров же может быть много!

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

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

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

Итак, для вновь прибывших. :)
Меня интересует именно торможение при выборке из псевдотаблиц. Как логировать я уже сориентировался. :)
21 окт 14, 12:59    [16736096]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
Glory
Member

Откуда:
Сообщений: 104760
АцкийСкотона
Меня интересует именно торможение при выборке из псевдотаблиц

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

Откуда: Чебоксары
Сообщений: 56
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.
21 окт 14, 13:11    [16736201]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
ART-CODE
Member

Откуда:
Сообщений: 1092
АДО при апдейте апдейтит ВСЕ записи


Если я пишу
update sometable set somefield='1' where somrfiled='2'

то обновятся все записи ?
Никогда не встречался с таким поведением. В какой версии (mdac, sqlncli) такое ?
21 окт 14, 13:12    [16736207]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

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

Торможение - это бонус вашей универсальности.


Вообще то, чтобы изрекать тут что либо не по теме, прочитали бы сначала. Ну если вы не поняли, то объясню. Торможение псевдотаблиц не только не дает мне жить спокойно при доделывании универсального триггера, она так же тормозит остальную базнес-логику в триггере. Я уж не стал сразу гвоорить. Думал итак понятно будет. :)
21 окт 14, 13:13    [16736222]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
ART-CODE
Member

Откуда:
Сообщений: 1092
"Все" - в смысле, не только удовлетворяющие условию WHERE ?
21 окт 14, 13:14    [16736225]     Ответить | Цитировать Сообщить модератору
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу  [new]
АцкийСкотона
Member

Откуда: Чебоксары
Сообщений: 56
ART-CODE
АДО при апдейте апдейтит ВСЕ записи


Если я пишу
update sometable set somefield='1' where somrfiled='2'

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


Я хз в какой. Я разработкой интерфейса к нашей бд не занимаюсь. Просто мне сказали что так и происходит. Я бы конечно выловил запрос щас с клиента, да лень чота. Да и к теме не относится. :)
21 окт 14, 13:15    [16736233]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить