| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Microsoft SQL Server |
  |
||
| Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 4 5 6 вперед Ctrl→ все |
 Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|
|
АцкийСкотона 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 во временную таблицу
|
|||
|
iap Member Откуда: Москва Сообщений: 47198 |
Речь идёт о легендарном "универсальном триггере"? Который по метаданным собирает запрос логгирования для полей любой таблицы, к которой прицеплен такой "универсальный триггер"? |
||
| 21 окт 14, 11:58 [16735533] Ответить | Цитировать Сообщить модератору | |||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
|
АцкийСкотона Member Откуда: Чебоксары Сообщений: 56 |
тож самое. за исключением что промелькнули еще таблицы, ключи на которые я апдейтил. но затор не там же. 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 во временную таблицу
|
|||||
|
АцкийСкотона Member Откуда: Чебоксары Сообщений: 56 |
Ф точку. Только триггер не посвящен целиком логированию, там еще бизнес-логика. :) И с чего же легендарный он? От завершения меня отделяет только эта идиотская задержка, которой я моуг по идее принебречь. Подождут пользаки уже немонго. Всеравно вола валяют почти весь день. :) |
||||
| 21 окт 14, 12:04 [16735590] Ответить | Цитировать Сообщить модератору | |||||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
|
iap Member Откуда: Москва Сообщений: 47198 |
Вот поэтому-то я давным-давно бросил эту идею. Плавали - знаем. |
||
| 21 окт 14, 12:12 [16735679] Ответить | Цитировать Сообщить модератору | |||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||||
|
АцкийСкотона Member Откуда: Чебоксары Сообщений: 56 |
Я тоже бросил затею делать это в самом триггере. :) Вот поэтому то мне и надо слизать псевдотаблички. Да бэ в другом процессе по ним неспешай пройтись. :) Ну и идея еще в универсальности кода логирования. Таблиц не одна сотня. Каждый раз переделывать везде- проще застрелиться. |
||||
| 21 окт 14, 12:15 [16735706] Ответить | Цитировать Сообщить модератору | |||||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
|
Shakill Member Откуда: мск Сообщений: 1887 |
|
||
| 21 окт 14, 12:20 [16735750] Ответить | Цитировать Сообщить модератору | |||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||||
|
iap Member Откуда: Москва Сообщений: 47198 |
И с таким логом проще жить потом. |
||||
| 21 окт 14, 12:21 [16735757] Ответить | Цитировать Сообщить модератору | |||||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|
|
АцкийСкотона Member Откуда: Чебоксары Сообщений: 56 |
Shakill, Облом ВЕЗДЕ. Сгенереный код тоже не видит инсертед\делетед. Я уже все перепробовал. Единственный сопоб- утащить эти таблички и потом их обрабатывать. :) |
| 21 окт 14, 12:29 [16735822] Ответить | Цитировать Сообщить модератору | |
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||||
|
АцкийСкотона Member Откуда: Чебоксары Сообщений: 56 |
Так чтобы их целиком логировать мне какраз таки и надо прежде сохранить псевдотаблицы. К тому же, я уже упоминал, в триггере не только логирование. Есть еще триггеры с бизнес-логикой. И дикое торможение этих дурацких таблиц так же снижает и ее. Ну так что, знает кто причину почему тормозит выборка с псевдотаблиц?:) |
||||
| 21 окт 14, 12:32 [16735844] Ответить | Цитировать Сообщить модератору | |||||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
|
Shakill Member Откуда: мск Сообщений: 1887 |
насчет генератора кода я имел в виду не формирование динамики в триггере (хотя и туда можно передать через табличную переменную), а генерация самого триггера на основе шаблона и указания таблицы, на которой он будет висеть. |
||
| 21 окт 14, 12:37 [16735876] Ответить | Цитировать Сообщить модератору | |||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
|
iap Member Откуда: Москва Сообщений: 47198 |
Главное, что надо сделать - забыть об универсальности. И заниматься логгированием каждой таблицы в отдельности. Можно, например, создать таблицы-логи с почти идентичной оригиналам структурой с помощью генерирования скриптов таблиц с обработкой полученного текста в каком-нибудь приличном редакторе. Кроме тогго, текст логгирования для триггеров КАЖДОЙ ТАБЛИЦЫ можно получить универсальным запросом ОДИН РАЗ (скорость, как понимаете, уже не очень-то и важна!). Да что там! Это логгирование можно оформить как отдельный триггер, а бизнес-логика пусть будет в другом! Триггеров же может быть много! Получится для каждой таблицы свой текст триггера, но сформированный не вручную, а запросом. |
||
| 21 окт 14, 12:40 [16735899] Ответить | Цитировать Сообщить модератору | |||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||||
|
АцкийСкотона Member Откуда: Чебоксары Сообщений: 56 |
Не катит. Таблиц сотни. Потом в таких шаблонах черт ногу сломит. Да и ошибки трудно будет искать. |
||||
| 21 окт 14, 12:43 [16735917] Ответить | Цитировать Сообщить модератору | |||||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|
|
pkarklin Member Откуда: Москва (Муром) Сообщений: 74930 |
АцкийСкотона, Scan count 566 - очень много. Интересно, какой результат будет, если вы уберете триггер и воспользуетесь кляузой OUTPUT в UPDATE? |
| 21 окт 14, 12:49 [16735968] Ответить | Цитировать Сообщить модератору | |
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||||
|
tarrus Member Откуда: Bergen Сообщений: 831 |
В единообразном коде, хранящемся в системе контроля версий, изменяемом централизованно и единообразно для всех таблиц? Скорее в вашей затее черт ногу сломит. |
||||
| 21 окт 14, 12:49 [16735973] Ответить | Цитировать Сообщить модератору | |||||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
|
pkarklin Member Откуда: Москва (Муром) Сообщений: 74930 |
Начиная с 2005, для получения данных из псевдо таблиц используется версионное хранилище в tempdb. Она у Вас не может являться узким местом? |
||
| 21 окт 14, 12:54 [16736018] Ответить | Цитировать Сообщить модератору | |||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|
|
ART-CODE Member Откуда: Сообщений: 1105 |
Когда включаем репликацию на сервере (publisher), она сама вешает на все таблицы триггеры. И создает спец. таблицы в которых накапливает не отреплецированные данные. Чем не хорошая заготовка для системы логирования ? |
| 21 окт 14, 12:55 [16736048] Ответить | Цитировать Сообщить модератору | |
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
|
pkarklin Member Откуда: Москва (Муром) Сообщений: 74930 |
Там нет данных о том, кто проводил модификацию? |
||
| 21 окт 14, 12:57 [16736065] Ответить | Цитировать Сообщить модератору | |||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||||
|
АцкийСкотона Member Откуда: Чебоксары Сообщений: 56 |
Главное, что надо сделать - забыть об универсальности. Увы, не могу без нее спать. :) И заниматься логированием каждой таблицы в отдельности. Сейчас итак так сделано. В каждом(необходимом) триггере в конце код логирования. И если схему логирвоания изменить, то мне придется помирать на применении новой идеи из-за 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 во временную таблицу
|
|||
|
Glory Member Откуда: Сообщений: 104751 |
Торможение - это бонус вашей универсальности. |
||
| 21 окт 14, 13:03 [16736135] Ответить | Цитировать Сообщить модератору | |||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||||||||||||
|
АцкийСкотона Member Откуда: Чебоксары Сообщений: 56 |
Это еще мало. Аутпут мне бесполезен по идее. Но как он проходит сейчас поосмтрю.
Попробуйте сначала хотя бы номрально представить себе код, который генерит триггеры, хранящийся в системе контроля версий. :) Потом представьте что у вас изменилось 100-300 таблиц. Потом еще некоторые талбицы объеденились, некоторые разъеденились в новые. И заетм представьте себе как вы будете свой ацкий гениальный генерирующий триггеры код рефакторить. Обязательно мне сообщите сколько времени у вас ушло с сколько ведер слюны вы наплевали.
Реплика- страшный сон. Вообще про нее не говорите мне пожалуйста. Намного правильнее заюзать технологии "Change tracking" или "Change Data Capture". Но увы и ах! На БД с "Memory optimized tables" данные технологии включить невозможно. Очередной дикополезнобесполезный функционал от мелкософта(эт я про MET).
Честно сказать не понял. Можно поподробней про этом момент? Там насоклько знаю никакой версионности. Псевдотаблички на самом деле есть одна таблица, содержащая инсертед и делетед записи. Доступ через которые осуществляется через INSERTED\DELETED. |
||||||||||||
| 21 окт 14, 13:11 [16736201] Ответить | Цитировать Сообщить модератору | |||||||||||||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||
|
ART-CODE Member Откуда: Сообщений: 1105 |
Если я пишу update sometable set somefield='1' where somrfiled='2' то обновятся все записи ? Никогда не встречался с таким поведением. В какой версии (mdac, sqlncli) такое ? |
||
| 21 окт 14, 13:12 [16736207] Ответить | Цитировать Сообщить модератору | |||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||||
|
АцкийСкотона Member Откуда: Чебоксары Сообщений: 56 |
Вообще то, чтобы изрекать тут что либо не по теме, прочитали бы сначала. Ну если вы не поняли, то объясню. Торможение псевдотаблиц не только не дает мне жить спокойно при доделывании универсального триггера, она так же тормозит остальную базнес-логику в триггере. Я уж не стал сразу гвоорить. Думал итак понятно будет. :) |
||||
| 21 окт 14, 13:13 [16736222] Ответить | Цитировать Сообщить модератору | |||||
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|
|
ART-CODE Member Откуда: Сообщений: 1105 |
"Все" - в смысле, не только удовлетворяющие условию WHERE ? |
| 21 окт 14, 13:14 [16736225] Ответить | Цитировать Сообщить модератору | |
| Re: Долгая выборка из INSERTED\DELETED во временную таблицу
|
|||||
|
АцкийСкотона Member Откуда: Чебоксары Сообщений: 56 |
Я хз в какой. Я разработкой интерфейса к нашей бд не занимаюсь. Просто мне сказали что так и происходит. Я бы конечно выловил запрос щас с клиента, да лень чота. Да и к теме не относится. :) |
||||
| 21 окт 14, 13:15 [16736233] Ответить | Цитировать Сообщить модератору | |||||
| Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 4 5 6 вперед Ctrl→ все |
| Все форумы / Microsoft SQL Server | |
|
x