Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Недавно решил модернизировать существующую систему журналирования и ряд «автоматизаций» с использованием ServiceBroker. Вроде как асинхронность журналирование не будет тормозить, в при критической нагрузке — очередь постепенно в нужно порядке разгребется. Так как это вроде как «другой поток/подключение» не нужно париться с тем чтоб не потерять логи при rollback-ах. Сделал контракты, очереди, активаторы, скрипты тестовые — все ОК. Все делает как нужно, ошибки тож хорошо ловит (пробовал на делении на ноль), ничего не ломается. Но дальше начинается магия. Запускаю пачкой юнит тесты (из C# вызываются хранимки с «новым» журналированием). Ошибок нет. Логи — пустые. Очередь — пустая. Запускаю отдельно тест через отладчик — все норм, данные в логах есть. Запускаю ХП из SMS – логи есть. Отлаживаю дебаггером в SMS в которой есть ошибка (обращение к несуществующему объекту). Пошагово иду, и там где логи должны записываться — таблица пустая, ни до ошибки, ни самой ошибки, ни после. Хранимки логов вызваются, в очередь сообщения отправляются, но активатор не вызывается. Запускаю без дебаггера с «ошибкой» - логов тоже нет. Запускаю приложение .NET, жму кнопочки, вызываются другие ХП с таким же логированием, логи есть. Тут же еще раз дебаггером в SMS – логов нет. Правлю хранимку, чтоб не было ошибки, запускаю, без отладки — логи есть. Продолбался с этим конец рабочего дня. Сейчас сижу и ломаю голову. Это у меня что-то глючит или или в режиме дебаггера какой-то другой режим работы брокера? Или если ошибка посерьезнее чем деление на ноль, то запись в очередь умирает и это как-то просчитывается? И у брокера активатор работает не совсем в "отдельном потоке" и "отдельном подключении к БД"? Или брокера для логов использовать не камельфо? Есть какие-то нюансы которые я не учел? Куда пропадают логи когда пачкой работают юнит тесты? сервер - 2014 Standart ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2018, 20:47 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
по этой статейке с брокером работаю https://germangorelkin.blogspot.com/2017/07/ms-sql-server.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2018, 21:02 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
КифирчикТак как это вроде как «другой поток/подключение» не нужно париться с тем чтоб не потерять логи при rollback-ах.Вот с этим как раз и нужно "париться", т.к. при откате транзакции все, что отсылалось в очередь также откатывается. Обходится через event notifications - 17329722 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2018, 21:07 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
invm, я правильно понимаю, что "на пальцах", это примерно как я сделал, за исключением что попадание сообщения в очередь не через хранимку с dialog conversation а с использованием sp_trace_generateevent ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2018, 22:03 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчикя правильно понимаю, что "на пальцах", это примерно как я сделал, за исключением что попадание сообщения в очередь не через хранимку с dialog conversation а с использованием sp_trace_generateevent ?Т.е. разница в поведении при откате транзакции для вас несущественна? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2018, 09:26 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
invm, конечно существенна я подразумевал реализацию а не поведение. и судя по всему тип сообщения службы только [ http://schemas.microsoft.com/SQL/Notifications/PostEventNotification%5D]http://schemas.microsoft.com/SQL/Notifications/PostEventNotification] ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2018, 09:41 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчикя подразумевал реализацию а не поведение.Реализация да, через SB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2018, 10:07 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
invm, слепил из вашей заготовки и своего кода. на вскидку, ничего не упустил? Код: 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. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2018, 10:25 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчикна вскидку, ничего не упустил?Вроде нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2018, 10:38 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, тесты откатывают транзакции и вместе с ними сообщения брокера. Вам для журналирования надо использовать механизм event notification, который передаёт сообщения брокеру независимо от отката. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2018, 11:16 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Всем спасибо за наводки. Заработало на "боевой" базе. Правда еще пришлось танцевать с бабунами. допиливание чтоб на базе это все завелось (может кому пригодится) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. признаюсь не до конца осознал последствия trustworthy и changedbowner, но это заработало ))) а внутри обработчика сообщений пришлось добавить строку set QUERY_GOVERNOR_COST_LIMIT 0; иначе брокер вылетал с ошибкой авторthe query has been canceled because the estimated cost of this query (8570) exceeds the configured threshold of 6000 Видать обработка XML со своими данными запиханного в BinaryData оказалась сравнительно ресурсоемкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 15:51 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, подзравляю, теперь ваш любой db_owner может стать сисадмином сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 16:12 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчикпризнаюсь не до конца осознал последствия trustworthy и changedbowner, но это заработало )))А зачем из процедуры активации обращаться к внешним ресурсам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 16:17 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, кстати вам еще следуют учитывать что для уведомлений о событиях диалоги не закрываются. они висят до тех пор пока не будет удалено уведомление. Если у вас эта система логирования предполагает работать с высокой нагрузкой, следует озаботится вопросом что вы будете делать с открытыми диалогами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 17:08 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
felix_ffКифирчик, подзравляю, теперь ваш любой db_owner может стать сисадмином сервера. invm >признаюсь не до конца осознал последствия trustworthy и changedbowner, но это заработало ))) А зачем из процедуры активации обращаться к внешним ресурсам? уточните плиз, вопрос относительно trustworthy или changedbowner? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 17:09 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, совокупность. сделав овнером базы пользователя из группы сисадмин вы расширили его права, любой пользователь группы db_owner может сделать execute as user = 'dbo' тем самым переключив себя на контекст 'sa' но он пока еще закрыт в базе. поставив trustworthy вы открыли песочницу, тем самым пользователь теперь не заперт в базе а получает доступ прав уровня sysadmin ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 17:12 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
felix_ffКифирчик, кстати вам еще следуют учитывать что для уведомлений о событиях диалоги не закрываются. они висят до тех пор пока не будет удалено уведомление. Если у вас эта система логирования предполагает работать с высокой нагрузкой, следует озаботится вопросом что вы будете делать с открытыми диалогами это не спасает? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 17:14 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, не спасет. срабатываение события посылает в очередь только тип сообщения [ http://schemas.microsoft.com/SQL/Notifications/EventNotification%5D]http://schemas.microsoft.com/SQL/Notifications/EventNotification] никакого enddialog ему не приходит, поэтому у вас нижние ветки if никогда не сработают. [ http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog%5D]http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog] поступит в очередь только при удалении уведомления инструкцие drop event notification здесь вам по сути надо организовать логику вычитали сообщение закрыли диалог со стороны цели. Код: sql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 17:28 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, диалог надо закрывать с двух сторон - и на сервисе А и на сервисе Б. Сервис А в данном случае контролирует система Event Notification, а сервис Б - ваша процедура. Вы получаете и обрабатываете сообщение и закрываете со своей сторону диалог в любом случае, независимо от типа полученного сообщения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 17:40 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
felix_ff, Код: sql 1. 2. 3. 4. 5. в таком варианте, очередь обрабатывает только одно первое сообщение, все остальные sp_trace_generateevent я не вижу ((( Владислав Колосов диалог надо закрывать с двух сторон - и на сервисе А и на сервисе Б. Сервис А в данном случае контролирует система Event Notification, а сервис Б - ваша процедура. Вы получаете и обрабатываете сообщение и закрываете со своей сторону диалог в любом случае, независимо от типа полученного сообщения. Я не совсем понимаю "закрыть со своей стороны" Со своей стороны я вызываю Код: sql 1. 2. 3. как закрыть диалог с "моей стороны"? или "моя сторона" подразумевается процедура активации очереди? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 17:53 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчикуточните плиз, вопрос относительно trustworthy или changedbowner?Да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 17:58 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, ну напишите так чтобы у вас при активации очереди цикл читал сообщения из очереди, если вдруг в цикле меняется conversation_handle или инструкция receive не возвращет сообщения, закрывается последний прочитанный диалог. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. а лучше вычитывать в буффер Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2018, 18:55 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
КифирчикНедавно решил модернизировать существующую систему журналирования и ряд «автоматизаций» с использованием ServiceBroker. Вроде как асинхронность журналирование не будет тормозить, в при критической нагрузке — очередь постепенно в нужно порядке разгребется. Интересно, в чем разница: писать в очередь или сразу писать в журнал? ЗЫ. Битва с ветряными мельницами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2018, 06:06 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
aleks222КифирчикНедавно решил модернизировать существующую систему журналирования и ряд «автоматизаций» с использованием ServiceBroker. Вроде как асинхронность журналирование не будет тормозить, в при критической нагрузке — очередь постепенно в нужно порядке разгребется. Интересно, в чем разница: писать в очередь или сразу писать в журнал? ЗЫ. Битва с ветряными мельницами? Хороший вопрос, заставил задуматься... Но он был бы справедлив, если бы запись в очередь равнялась записи в таблицу. У нас простая схема (запись в таблицу) работает уже лет пять, и как показывает практика, в этих записях хрен разберешься. одновременно работают хранимки вызванные пользователем, джобы, триггеры (через которые мы выполняем автоматизацию с соседней системой). Куча проблем с ответом на вопросы кто кого вызвал, откуда, к какому именно вызову относится строка, к какому бизнес объекту. Логи на хранимки/модули нужно как-то включать/выключать по мере необходимости. В случае ошибки - откатываются и логи, и следов ошибки вообще нет. Ну и триггеры соседней системы также откатываются. В итоге, в виду того что часть работы это аутосорс у заказчика, он временами звонит, и говорит "вот, у меня тут вчера так то и так то глюкнуло, разберитесь", и начинается бурный секс с этим потоком данных. И нужно определенное "наитие" и бутылка водки чтоб в этом разобраться и возможно подправить последствия. В целом толку от этого лога очень мало. Это "простая" система. И даже на ней, коллеги следящие за перфомансом, комментят записи в логи получают профит. Недавно придумали новую систему, которая должна решить проблемы перечисленные выше: - дополнительно пишется ID "бизнес процесса", внутри которого может быть несколько ХП у которых тоже пишется свой не похожий на соседние ID - есть поле для "бизнес объекта" - есть система включения/выключение логирования (через табличку) - упрощена запись (длинная, с указанием кучи аргументов только первая строка) - не теряются логи после отката транзакции (через промежуточное хранение в табличной переменной) То есть логгирование хранимки в таком варианте - это минимум две записи о начале/окончании, и при каждой записи обращения к таблице настроек и мета информации плюс запись в логи. Это определенно окажет еще большее влияние на производительность. Также, попадаются ошибки из-за которых все равно логи откатываются, вариант с табличной переменной работает не идеально. Вчера на ноуте запустил тест, в котором ОЧЕНЬ много логов пишется через обсуждаемый вариант логирования (через брокера и event-ы) (упрощенный, только вставка без использование мета информации). Тесты за минуту забили в очередь 100к записей, которые асинхронно минут 15..20 распихивались в таблицу логов. По мне так это пример что это минимально нагружает хранимые процедуры. Также, мне кажется крайне важным асинхронно развязаться с триггерами соседней системы, не камельфо в них выполнять свои хранимые процедуры. И судя по всему тут доктор прописал использовать ServiceBroker. Сейчас появилась возможность, и я начал копать в сторону ServiceBroker-a, и решил начать с логов. Что касается ветряных мельниц - с точки зрения того что есть куча других задач, приходится делать фоново, да и без этого и так работает, то это определенно на ветряную мельницу смахивает. С точки зрения "хочется чтоб было не через ж#пу" и меньше долбаться с анализом проблем - это не мельница а крепость на пути к светлому будущему ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2018, 12:38 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
КифирчикПо мне так это пример что это минимально нагружает хранимые процедуры. Тебе уже сказали: все очереди сервис брокера - суть таблицы. Т.е. твой пример пишет два раза. И это, канешно, быстрее, чем один раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2018, 14:42 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
felix_ffКифирчик, совокупность. сделав овнером базы пользователя из группы сисадмин вы расширили его права, любой пользователь группы db_owner может сделать execute as user = 'dbo' тем самым переключив себя на контекст 'sa' но он пока еще закрыт в базе. поставив trustworthy вы открыли песочницу, тем самым пользователь теперь не заперт в базе а получает доступ прав уровня sysadmin какую тогда "правильную" стратегию выбрать? сделать отдельного пользователя не в группе db_owner и не sysadmin, и в собственники базы его? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2018, 16:29 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, я не знаю Вашей инфраструктуры. если у вас бизнес логика позволяет иметь овнером бд пользователя с наименьшими привилегиями, то желательно тогда овнером делать имено такого пользователя. правильная стратегия если вам нужно использовать СБ между базами, это создание сертификатов и настройка безопасности на их основе. тоже касаемо выдачи прав для пользоветей: давая какому то юзеру alter trace вы ему дали возможность создавать серверную трассировку. поэтому теперь этот логин может спокойно следить за запросами даже в тех базах в которые сам не отмаплен. или поднапрячь сервак какой нибудь кошерной трассой на отлов lock:aсquired к примеру.ъ в этом варианте лучше сделать процедуру обертку, и подписать ее сертификатом у которого овнер с нужным правом, а пользователю уже дать право на execute этой процедуры обертки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2018, 19:29 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, Может уже поделитесь, зачем понадобилось включать trustworthy? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2018, 20:02 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
invmКифирчик, Может уже поделитесь, зачем понадобилось включать trustworthy? Да хз ) На моем компе все и без этого работает. На объекте на одном сервере завелось, на другом нет. В трассировке еле откопал по поводу сообщение о нехватке прав (примерно). Сравнил базы, отличие было в trustworthy. Вспомнил что в одном из примеров по ServiceBroker мне попадалось что автор его включал. Включил, пересоздал очередь и привязки - заработало. Касаемо инфраструктуры С MSSQL работает сервер приложения, под одним логином. Плюс соседнее приложение. базы, примерно так BASE_TASK1 BASE_TASK2 BASE_TASK3 BASE_LOG Наш сервер приложений работает от user1, сторонний - от user2, у обоих во всех этих база db_datareader/writer, и grant exec. Разделение на базы во много логическое, то есть имеются связи между базами. Сеть закрытая, IT отдел в сервера не лезет. Я бы сказал сертификаты тут избыточное усложнение, и усложнит жизнь коллегам. И таких серверов несколько, между собой связаны репликациями. в базах BASE_TASK1, BASE_TASK2б, BASE_TASK3 есть обертки над sp_trace_generateevent, примерно как в спойлере Код: 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. в базе BASE_LOG - очередь, сервис брокер и обработчик очереди, который вызывает ХП которая делает insert в BASE_LOG.log.AppLog Код: 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. подозреваю мои проблемы могу быть вызваны тем что я использовал with as owner ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2018, 20:44 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, а вы с какой ошибкой то боролись включением trustworthy. на service broker он может повлиять только в том случае если у вас диалог межбазовых очередей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2018, 00:42 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
felix_ffКифирчик, а вы с какой ошибкой то боролись включением trustworthy. на service broker он может повлиять только в том случае если у вас диалог межбазовых очередей. Сейчас выключил на обеих базах, и без него все работает (( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2018, 09:58 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Ниже кусок кода как мне видится "правильно бы сделать" собственником всех баз делам отличного пользователя, под которым не работают клиенты и который не может TRACE EVENT в базах - два пользователя user_task, для работы клиентов, и user_log, у которого будут права на TRACE EVENT user_task вызывает ХП обертки над TRACE EVENT которые run as user_log но не работает - "Нет разрешения на запуск "SP_TRACE_GENERATEEVENT" чего в коде не хватает? Код: 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. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2018, 12:15 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, вы путаете контекст переключения, в вашем случае надо использовать execute as login вместо execute as user сделайте Код: 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. увидите разницу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2018, 16:20 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
о внимательней посмотрел, там у вас намешано. легче сделать так: Код: 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. тогда вам не надо парится с переключением контекстов и их правами. у вас права выданные логину trace_login будут применены на вызов модуля который подписан соответствующим сертификатом. писал по памяти может где то с синтаксисом накосячил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2018, 16:45 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
felix_ff, Сработало ) На память получилось очень точно ))) Понятно, то есть нельзя просто так сказать "выполни от этого логина", он должен как то "логиниться", и это возможно автоматически если создать логин с сертификатом. Код: 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. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. Осталось срастить очередями, понять что-там с диалогами точно происходит и натянуть свои более сложные обработчики. Единственное, НО, решение в итоге получается не такое уж и тривиальное, если через год за базу возьмутся менее опытные коллеги, что-то сломается, может получиться что им будет проще свой велосипед чем это отремонтировать. И есть вопросы как это будет себя вести с бэкапами и переносом баз. Сертификат как я понимаю живет в сервере, если я переношу базу на другой сервер - то там нужно сертификат "подгружать"и обновлять add signature to log.spLogSimple? или делать новый сертификат и переподписывать log.spLogSimple? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2018, 11:33 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
КифирчикПонятно, то есть нельзя просто так сказать "выполни от этого логина", он должен как то "логиниться", и это возможно автоматически если создать логин с сертификатом. https://docs.microsoft.com/ru-ru/previous-versions/sql/sql-server-2008-r2/ms188304(v=sql.105) КифирчикСертификат как я понимаю живет в сервереСертификат живет в той БД, где был создан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2018, 11:42 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Еще одна паталогия. Столбец слева - это время вызова eventa, берется перед самим вызовом, то есть реальное время сработки вызова в ХП. Столбец справа - это временная метка записи в таблицу с логами, то есть порядок обработки сообщений (desc). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Предполагалось что Stamp сможет определить верный порядок вызовов Event, но в столбце LogDateTime данные вперемешку. В инструкции к RECEIVE сказано - "Результирующий набор, возвращенный инструкцией RECEIVE, неявно упорядочен." То есть очередь как получила, так и выдает (видимо в обратном порядке, order by к очереди не применимо). Получается event-ы доходят в очередь не всегда в порядке их вызова? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2018, 18:04 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчик, именно, очередь сообщений гарантируется только в рамках одного диалога, а не кучи диалогов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2018, 18:33 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Мде... еще два вопроса: 1) conversation, диалог, относительно Notify event, где его рамки? вызов одной ХП? или пакета? 2) можно ли сделать так чтоб сами notify event и сообщения типа "The activated proc '[log].[AsyncLogQueueProcessing]' running on queue 'VTSDB2_LOG.log.AsyncLogQueue' output the following: 'exec spLogSimpleDo1'" не валились в журнал MSSQL? это как-нибудь настраивается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2018, 22:33 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
КифирчикМде... еще два вопроса: 1) conversation, диалог, относительно Notify event, где его рамки? вызов одной ХП? или пакета? 2) можно ли сделать так чтоб сами notify event и сообщения типа "The activated proc '[log].[AsyncLogQueueProcessing]' running on queue 'VTSDB2_LOG.log.AsyncLogQueue' output the following: 'exec spLogSimpleDo1'" не валились в журнал MSSQL? это как-нибудь настраивается? 1) не совсем понятен вопрос. вы имеете ввиду до какого момента сообщения будут валиться в один и тот же диалог? если вопрос в этом то точно не подскажу, надо экспериментировать. вообще в рамках одного уведомления должен быть один диалог, но я встречал ситуации когда это не так. что бы сообщения не копились мы писали задание которое раз в неделю пересоздавало уведомление. 2) у вас сообщения в журнал могут сыпаться если у вас уведомление о событии не получается доставить. что детально в сообщении лога написано? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2018, 00:03 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Кифирчикconversation, диалог, относительно Notify event, где его рамки? вызов одной ХП? или пакета?Вас это вообще не должно волновать. Отметка времени должна приходить вместе с логируемым сообщением. Не следует привязываться к порядку поступления сообщений и, тем более, к порядку строк в таблице логов. Не нужно завершать диалог на каждый чих. Не вы этот диалог начали - не вам и завершать. Завершать нужно лишь в ответ на EndDialog и Error и без опции with cleanup (мой косяк в примере). Данная опция служит для аварийного завершения. И проверьте что твориться в sys.conversation_endpoints в msdb и VTSDB2_LOG. Кифирчикможно ли сделать так чтоб сами notify event и сообщения типа "The activated proc '[log].[AsyncLogQueueProcessing]' running on queue 'VTSDB2_LOG.log.AsyncLogQueue' output the following: 'exec spLogSimpleDo1'" не валились в журнал MSSQL? это как-нибудь настраивается?Уберите весь диагностический вывод из процедуры log.AsyncLogQueue. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2018, 10:07 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
Блин, точно "The activated proc '[log].[AsyncLogQueueProcessing]' running on queue 'VTSDB2_LOG.log.AsyncLogQueue' output the following: 'exec spLogSimpleDo1' это PRINT 'exec spLogSimpleDo1' внутри AsyncLogQueueProcessing invmВас это вообще не должно волновать. Отметка времени должна приходить вместе с логируемым сообщением. Не следует привязываться к порядку поступления сообщений и, тем более, к порядку строк в таблице логов. К сожалению отметки времени не уникальны, могут приходить две (и даже 5) одинаковые, и тогда проблематично понять в какой последовательности они появились. Если диалог в очереди имеет границы например в рамках одного @spid, или внутри одной ХП - то это позволило бы точно сохранить порядок вызовов, исходя из порядка появления сообщений в очереди. Иначе - нужно формировать Stamp перед отправкой логируемого сообщения. Или последовательность длинючую использовать. Нужно и правда сделать эксперимент, сохраняя в обработчике очереди handle диалога. Мало ли, мне бы это много упростило ) sys.conversation_endpoints LOG Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. msdb Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. в таблицах все очень плохо? должны быть пустые? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2018, 15:34 |
|
||
|
Service broker для логирования, глюки
|
|||
|---|---|---|---|
|
#18+
КифирчикК сожалению отметки времени не уникальны, могут приходить две (и даже 5) одинаковые, и тогда проблематично понять в какой последовательности они появились. Если диалог в очереди имеет границы например в рамках одного @spid, или внутри одной ХП - то это позволило бы точно сохранить порядок вызовов, исходя из порядка появления сообщений в очереди. Иначе - нужно формировать Stamp перед отправкой логируемого сообщения. Или последовательность длинючую использовать. Заведите в VTSDB2_LOG sequence, дергайте из него значения в других БД и передавайте полученное в сообщении. Кифирчикв таблицах все очень плохо? должны быть пустые?Нет, все более-менее. Из той, которая в LOG, нужно прибить строки с state_desc = 'CLOSED' путем вызовов end conversation ... with clean up ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2018, 15:48 |
|
||
|
|

start [/forum/topic.php?all=1&fid=46&tid=1688572]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
83ms |
get tp. blocked users: |
2ms |
| others: | 249ms |
| total: | 431ms |

| 0 / 0 |
