Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Вопрос наболевший, но пока не вижу простых решений. Итак, есть пачка SQL процедур, которая должна в рамках одной транзакции выполнять "умное" перекладывание данных из одной кучки таблиц в другую. Суть в том, что в исходных данных периодически встречаются всевозможные сюрпризы, которые приводят к сбою при перекладывании данных. В случае сбоя хочется откатиться назад до последнего успешно переложенного среза данных, изучить проблему, исправить алгоритм перекладывания данных и/или схему конечной кучки таблиц, и возобновить перекладывание. В процессе выполнения процедур хочется логировать действия (сейчас в специальную табличку вставляются записи), чтобы в случае возникновения сбоев было легко понять место и причину сбоя. Внимание вопрос: как сделать так, чтобы откат прошел только для перекладываемых данных, но не для записей в таблице с отладочной информацией? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2009, 17:39 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
demidovich, В db2 9.7 есть автономные транзакции . В предыдущих версиях наиболее простой способ делать логирование через sql - это делать DECLARE GLOBAL TEMPORARY TABLE ... NOT LOGGED ON ROLLBACK PRESERVE ROWS а после окончания транзакции сливать данные оттуда в постоянную таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2009, 18:35 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Mark Barinstein, Про автономные транзакции - это то, что доктор прописал! Но мы, увы, на 9.1, причем для z/OS :( Поэтому и второй вариант нам тоже не подойдет (там только действия для COMMIT можно указать). Прошу прощения, что забыл про такую важную деталь, как версия и платформа! Еще идеи есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2009, 19:13 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
demidovich, Не использовать СУБД для ведения таблицы логов. В ОС встроены штатные средства регистрации событий. Например syslogd (Unix, Linux, z/OS). Для z/OS еще есть SMF (это правда больше для статистики), IXGLOGGER. Да и обычное логгирование в последовательные файлы тоже никто не отменял. ИМХО правильный выход - написать отдельную хранимую или функцию на платформенном языке (C/C++, HLASM, Java и т.п.), которая будет выполнять логгирование используя системные API или последовательные файлы. В дополнение можно написать еще одну, для извлечения логов и возврата их в виде выборки. PS: А для "перекладывания" данных вообще то существуют репликации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 11:33 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Можно ещё прочитать из transaction log изменения таблицы-лога программой Capture (читать replication guide) в СD - таблицу. там незакоммиченные записи будут видны. в таком случае откатились изменения или нет не очень интересно. но я тоже за то, чтобы написать маленькую процедурку на ассемблере и из неё писать в sequential dataset. а ещё больше за то, чтобы от хранимых процедур отказаться, а написать всю логику в отдельной программе. это можно сделать прямо на windows через DB2 connect windows, это проще чем на z/OS. отлаживайтесь таким образом, а потом программу можно портировать. gbibnt что-нибдь такое на embedded sql Код: plaintext 1. 2. 3. 4. 5. когда программа будет на мейнфрейме, SYSPRINT (или SYSOUT ?) можно будет перенаправить в sequential dataset ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 13:30 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Можно ещё прочитать из transaction log изменения таблицы-лога программой Capture (читать replication guide) в СD - таблицу. там незакоммиченные записи будут видны. в таком случае откатились изменения или нет не очень интересно. но я тоже за то, чтобы написать маленькую процедурку на ассемблере и из неё писать в sequential dataset. а ещё больше за то, чтобы от хранимых процедур отказаться, а написать всю логику в отдельной программе. это можно сделать прямо на windows через DB2 connect windows, это проще чем на z/OS. отлаживайтесь таким образом, а потом программу можно портировать. пишите что-нибдь такое на С++ с embedded sql Код: plaintext 1. 2. 3. 4. 5. 6. 7. когда программа будет на мейнфрейме, SYSPRINT (или SYSOUT ?) можно будет перенаправить в sequential dataset ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 13:34 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Новый Год, Вот только за печать в SYSOUT (SYSPRINT) могут сильно побить администраторы СУБД и/или системы. И еще, в z/OS внешние функции/хранимые исполняются в WLM-пространствах, поэтому функцию логгирования нужно писать аккуратно, помня что она может исполняться в параллельных потоках и адресных пространствах, а доступ к файлам так или иначе нужно сериализовывать, иначе на выходе можно запросто получить "кашу" или ошибку доступа. Поэтому и предлагается вариант с использованием API syslog. Насчет прикладной логики. Приложение лучше держать поближе к СУБД, т.к. сеть снижает производительность и повышает возможность сбоя во время работы. Писать программы на C/C++ или Java для z/OS ничуть не сложнее, чем для Windows или Linux (речь не про GUI приложения). Более того, "правильно" написанная программа на C/C++ (Embedded SQL или ODBC) во многих случаях пойдет в z/OS после компиляции. Т.е. разрабатывать программу можно и на персоналке, а сдавать работу в z/OS. Java-код идет вообще один к одному, без перекомпиляции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 14:07 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Всем спасибо за ответы! По поводу средств репликации: стандартные не годятся, мы рассматривали Data Propagator и собственный формат сообщений MQ. Нам хочется иметь наглядно реализованную логику обработки данных потратив минимум усилий. И иметь возможность быстро и легко менять эту логику. А SQL вполне подошел и показался проще, чем SQLj и тем более С хранимые процедуры (во многом из-за удобства и быстроты деплоймента). По поводу логирования: у меня на одном из первых этапов так и было сделано - лог велся в файле с помощью хранимой процедуры на java. Однако, было 3 минуса: 1) Сложно анализировать логи (за несколько часов может скопиться несколько миллионов записей) 2) В коде процедуры для логирования есть привязка к полному пути вывода, который зависит от конкретного полигона. 3) У меня создалось впечатление, что запись в таблицу заметно быстрее, чем запись в файл через java процедуру (я могу ошибаться, это было субъективное впечатление). За SYSOUT (SYSPRINT) администраторы и в самом деле побьют. В виду большого количества записей в лог хочется иметь отдельную песочницу для складирования таких записей. Если есть возможность циклической записи с затиранием старья - это даже плюс. По IXGLOGGER информацию не нашел. Любые конкретные примеры или ссылки с примерами приветствуются! С z/OS опыт работы очень маленький, так что штатные возможности я знаю очень и очень плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 15:58 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Евгений, ну зачем же за вывод в SYSPRINT сразу бить. Я же предложил его перенаправить //SYSPRINT DD DSN=XXX.XXX.XXX,DISP=SHR зато писать как здорово. если на Java проще написать, тем лучше, хотя мне и на С++ сойдёт. A сериализовывать процедуру точно надо выделить память в CSA (будут бить) создать System Level Name/Token pair (тоже буду бить), для этого нужно перейти в режим MODSET=SUP (опять будут бить) записать в токен адрес этой памяти в CSA потом эту сруктуру и пользовать для сериализации пусть все пусть один экземпляр ставит флажок, что занял ресурс, а остальные ждут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 16:01 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
demidovich, Использовать Java для выдачи в послед. файл это "несколько" избыточно. Во первых есть совсем ненулевое время задержки при старте WLM-пространства и раскрутки JVM внутри него. Во вторых, если для хранимой не запрещено параллельное исполнение и эту процедуру будут "дергать" сразу со многих потоков, то это приведет к порождению многих параллельных JVM (каждая будет кушать минимум 100МБ ОЗУ) и к блокировкам файлов. Поэтому если и делать отдельную процедуру для записи в файл, то лучше это делать на платформенном языке, например C. IXGLOGGER для вашего случая будет избыточно. А вот использование syslog нужно попробовать. В UNIX-части z/OS обычно по умолчанию запущен syslogd сервер. Для обращения к его функциям в языке C/C++ есть набор готовых функций (openlog(), syslog(), closelog()). Т.е. программа на C для логгирования в syslogd получится очень короткой. А уже сам сервер syslogd можно и нужно настроить на отписывание логов в отдельные файлы и их ротацию и/или на передачу логов на удаленный syslogd сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 16:21 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Новый Год, А что будет когда у нас запустится два WLM-пространства для этой процедуры? Будет блокировка на уровне системной процедуры. В зависимости от ситуации одно пространство может попасть в состояние WAITING FOR DATASETS. Тогда уж лучше динамически открывать набор данных, а не через DD. Придется это WLM-пространство ограничивать в параллельности работы. Вообще то можно просто запретить параллельный вызов хранимой на уровне DB2. Но, если процедуру логгирования будут использовать интенсивно, то можно попасть на задержки и блокировки при работе самого логгирования. Можно писать в OMVS файлы, используя PID процесса как часть имени файла. Но ИМХО лучше задействовать сервис syslog, системный сервис, который отлажен, и который возьмет на себя проблемы с параллельным вызовом. Java штука очень замечательная, только вот перед ее использованием для писания функций/хранимых DB2 нужно много думать, т.к. не для всякого функционала это будет оправданный выбор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 16:37 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Евгений, ну, пусть syslog, для начала. IXG* макросы посмотрел что такое. Писать можно долго, если " z/OS опыт работы очень маленький". B отдельное приложение логику всегда можно будет вынести. А там можно писать хоть в dataset, хоть в логгер, хоть в MQ. Наверно сейчас что быстрее то и нужно сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 18:03 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Евгений, Переварив все прочитанное, я склоняюсь именно к варианту использования syslog. Нет ли у Вас под рукой примеров использования этого самого syslog из хранимой процедуры на C? И как настроить вывод с помощью этой штуки в конкретный файл на HFS? Или хотя бы ссылку на хороший справочный ресурс по syslog дайте :) Честно говоря, я пока хранимые процедуры на C не писал (хотя опыт С++ программирования есть) и только теоретически представляю, что это такое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 18:47 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
demidovich, Настройка SYSLOGD в z/OS : Chapter 20. Syslog daemon Описание функций языка C/C++ : z/OS V1R8.0 XL C/C++ Run-Time Library Reference Ниже пример программы для записи в syslogd. Сразу предупреждаю, что для того чтобы из нее получилась полноценная хранимая нужно подумать и код дополнить. С этим смогу помочь не раньше чем через две недели (буду в отпуске). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Код: plaintext 1. 2. 3. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2009, 14:04 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
Евгений, Большое спасибо за пример и ссылки!!! Думаю, что этого мне должно хватить :) Хорошего отпуска! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2009, 14:16 |
|
||
|
Логирование действий в SQL процедурах
|
|||
|---|---|---|---|
|
#18+
demidovichЕвгений, Большое спасибо за пример и ссылки!!! Думаю, что этого мне должно хватить :) Хорошего отпуска! :) Спасибо! Очень прошу потом опубликовать здесь результаты применения(внедрения), что понравилось, что не понравилось, были ли проблемы и т.п. информацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2009, 15:15 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=36176773&tid=1603106]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
162ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 17ms |
| total: | 265ms |

| 0 / 0 |
