Возможен ли "нормальный" быстрый журнал

Администрирование баз данных (Pervasive.SQL, MS SQL, Oracle, утилита Support)

Модераторы: m0p3e, edward_K, Модераторы

Ответить
ilshat
Местный житель
Сообщения: 222
Зарегистрирован: 04 июн 2008, 14:35
Откуда: Стерлитамак
Контактная информация:

Возможен ли "нормальный" быстрый журнал

Сообщение ilshat »

Кто как работает с журналом?
Совершенно невозможно нормально в нем фильтровать :(
Мне нужно было отсечь по дате и по пользователю... Суппорт отожрал кучу памяти и ушел в несознанку на долгие часы... В итоге недождавшись я снял задачу. Стал искать по условиям - так там вообще полный абзац. Сейчас пишет 9% выполнялось 20 мин... Можно примерно прикинуть сколько будет это выполняться.
Приходим к тому, что нужно будет писать самим во внешней программе нормальный просмотрщик журнала. :(
Алексей
Местный житель
Сообщения: 2896
Зарегистрирован: 24 июн 2005, 12:12
Откуда: Иркутская область

Сообщение Алексей »

в саппорте какая версия атлантиса? Было такое шо тормозило, но потом вроде исправили.
ilshat
Местный житель
Сообщения: 222
Зарегистрирован: 04 июн 2008, 14:35
Откуда: Стерлитамак
Контактная информация:

Сообщение ilshat »

версия атлантиса 5.4.15
Пытался я получить отчетик "по условиям".
Да и в общем то нереально неудобно нет ни сортировко ни фильтраций ничего... а операций море :(
Polimer
Местный житель
Сообщения: 489
Зарегистрирован: 27 янв 2006, 12:46
Откуда: Москва

Сообщение Polimer »

Давно хотим написать свой интерфейс на портале.
Все данные для этого есть. Вопрос только в визуальном представлении. Может есть предложения :-)
Darikon
Постоянный обитатель
Сообщения: 188
Зарегистрирован: 17 июн 2008, 17:07
Откуда: Москва
Контактная информация:

Сообщение Darikon »

если быстро надо, сделай SQL запросом. Скорее всего, так и работают
ilshat
Местный житель
Сообщения: 222
Зарегистрирован: 04 июн 2008, 14:35
Откуда: Стерлитамак
Контактная информация:

Сообщение ilshat »

Написать свою прогу не хватает времени. Да еще эта заморочки с NREC...
Конечно если будет время напишу и буду пользоваться. Просто мало получить выборку - нужно еще саму запись просматривать.
А визуально может выглядеть и так в как в саппорте, только вот в саппорте невозможность получить сразу развернутую картинку по всем отфильтрованным записям тоже недостаток - могу распечатать либо список либо одну запись.
Я так понял пункт "по условиям" сделан так: открывается весь журнал и потом накладывается фильтр на таблицу. Иначе объяснить тормоза я не могу.
m0p3e
Местный житель
Сообщения: 1386
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва

Сообщение m0p3e »

На первасиве работа с журналом быстрее быть и не может, т.к. данные по изменениям в мемо полях живут. На MSSQL может работать молниеносно, т.к. журнал это фактически дублирующие таблицы J$(номер таблицы). Как дела обстоят на оракле не знаю пока, но подозреваю что аналогично на MSSQL.
ilshat
Местный житель
Сообщения: 222
Зарегистрирован: 04 июн 2008, 14:35
Откуда: Стерлитамак
Контактная информация:

Сообщение ilshat »

На MSSQL может работать молниеносно
Только вот реализация сделана видимо единой для всех БД.
J$(номер таблицы)
Спасибо за наводку. А я то все думал на кой эти таблы там живут и чем питаются.[/code]
Darikon
Постоянный обитатель
Сообщения: 188
Зарегистрирован: 17 июн 2008, 17:07
Откуда: Москва
Контактная информация:

Сообщение Darikon »

m0p3e
Ценная инфа! уже можно, хотя бы в запросах использовать :grin:
m0p3e
Местный житель
Сообщения: 1386
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва

Сообщение m0p3e »

Дык так и искал на MSSQL. Обычным способом попробуй найди запись об удалении документа, когда известен, например только номер! Повесишься нафиг. А на MSSQL набросал запросик - 2 минуты, запустил - 2 сек. :)
Иван
Местный житель
Сообщения: 200
Зарегистрирован: 28 апр 2009, 13:19
Откуда: Новороссийск

Re: Возможен ли "нормальный" быстрый журнал

Сообщение Иван »

я делаю примерно так под ораклом, типа выборка по проводкам, которые модифицировались в закрытом периоде бухконтура:

Код: Выделить всё

select sysdate as "data_viborki",gal.to_oradate2(b.lastdate) as "data_modif",gal.to_oratime2(b.lasttime) as "vremia_modif",
a.fnrec as nrec,gal.to_oradate2(a.fdatob) as "data_obor",
tuneval.fstrval as "grup",
c.xu$loginname as "usrname",
(case when b.operation=8 then 'удаление' when b.operation=4 then 'модифификация' else 'создание' end) as operation,
(case when a.j$$newoldrec=1 then 'новое знач.' else 'старое знач.' end) as "status",
a.fscheto as "dt_sch",
a.fsubossch as "dt_sub",
katpodr_d.fname as "podr_dt",
a.fschetk as "kt_sch",a.fsubschk as "kt_sub",katpodr_k.fname as "kt_podr",a.fsumob as "sumob",d.fname as "plansch",
katdoc.fname as "doc", a.fnodok as "docnum",
spkau1.fname as kauos1,spkau1.tcode as tablos1,spkau1.acode as kaukod1,
spkau2.fname as kauos2,spkau2.tcode as tablos2,spkau2.acode as kaukod2,
spkau3.fname as kauos3,spkau3.tcode as tablos3,spkau3.acode as kaukod3,
spkau4.fname as kauos4,spkau4.tcode as tablos4,spkau4.acode as kaukod4,
spkau5.fname as kauos5,spkau5.tcode as tablos5,spkau5.acode as kaukod5,
spkau6.fname as kauos6,spkau6.tcode as tablos6,spkau6.acode as kaukod6,
spkau7.fname as kauks1, spkau7.tcode as tablks1, spkau7.acode as kaukodk1, 
spkau8.fname as kauks2, spkau8.tcode as tablks2, spkau8.acode as kaukodk2, 
spkau9.fname as kauks3, spkau9.tcode as tablks3, spkau9.acode as kaukodk3, 
spkau10.fname as kauks4,spkau10.tcode as tablks4,spkau10.acode as kaukodk4,
spkau11.fname as kauks5,spkau11.tcode as tablks5,spkau11.acode as kaukodk5,
spkau12.fname as kauks6,spkau12.tcode as tablks6, spkau12.acode as kaukodk6 

from gal.x$journal b left join gal.j$9011 a on b.nrec=a.j$$link
left join gal.x$users c on b.usercode=c.atl_nrec
left join gal.planssch d on a.fcplanssch=d.fnrec
left join gal.katpodr katpodr_d on katpodr_d.fnrec=a.fkodspo
left join gal.katpodr katpodr_k on katpodr_k.fnrec=a.fkodspk
left join gal.katdoc katdoc on katdoc.ftidkgal=a.ftidkgal
left join gal.tuneval tuneval on (tuneval.fcuser=c.atl_nrec and tuneval.fstrempty='USER.DESGR')

left join spkau_view spkau1 on (a."FTBLOS[1]"=spkau1.tcode and a."FKAUOS[1]"=spkau1.fnrec)
left join spkau_view spkau2 on (a."FTBLOS[2]"=spkau2.tcode and a."FKAUOS[2]"=spkau2.fnrec)
left join spkau_view spkau3 on (a."FTBLOS[3]"=spkau3.tcode and a."FKAUOS[3]"=spkau3.fnrec)
left join spkau_view spkau4 on (a."FTBLOS[4]"=spkau4.tcode and a."FKAUOS[4]"=spkau4.fnrec)
left join spkau_view spkau5 on (a."FTBLOS[5]"=spkau5.tcode and a."FKAUOS[5]"=spkau5.fnrec)
left join spkau_view spkau6 on (a."FTBLOS[6]"=spkau6.tcode and a."FKAUOS[6]"=spkau6.fnrec)

left join spkau_view spkau7 on (a."FTBLKS[1]"=spkau7.tcode and a."FKAUKS[1]"=spkau7.fnrec)
left join spkau_view spkau8 on (a."FTBLKS[2]"=spkau8.tcode and a."FKAUKS[2]"=spkau8.fnrec)
left join spkau_view spkau9 on (a."FTBLKS[3]"=spkau9.tcode and a."FKAUKS[3]"=spkau9.fnrec)
left join spkau_view spkau10 on (a."FTBLKS[4]"=spkau10.tcode and a."FKAUKS[4]"=spkau10.fnrec)
left join spkau_view spkau11 on (a."FTBLKS[5]"=spkau11.tcode and a."FKAUKS[5]"=spkau11.fnrec)
left join spkau_view spkau12 on (a."FTBLKS[6]"=spkau12.tcode and a."FKAUKS[6]"=spkau12.fnrec)

where b.tablecode = 9011
and a.fdatob < (select datzakr.fdateval from gal.tuneval datzakr where datzakr.fnrec='8138000000023499')
and gal.to_oradate2(a.fdatob) is not null
and b.lastdate < gal.TO_ATLDATE(TO_DATE(to_char(sysdate-1,'dd/mm/yyyy'),'DD/MM/YYYY'))
Прохожий
Постоянный обитатель
Сообщения: 134
Зарегистрирован: 23 мар 2007, 05:38
Откуда: Дальний Восток, Хабаровск
Контактная информация:

Re: Возможен ли "нормальный" быстрый журнал

Сообщение Прохожий »

Смотря за какое время журнал хранить. Конечно, если там 2 прошлых года, что ж удивляться неторопливой работе? Хотя и неоптимизированность тоже налицо, поскольку запрос внешними средствами работает гораздо быстрее. У меня, например, журнал хранится всего за 2 последних месяца и проблем с журналом почти не испытываю.
Галактика 8.10, Oracle 10g patch 10.2.0.4
Шевцов Владимир
Постоянный обитатель
Сообщения: 175
Зарегистрирован: 09 окт 2009, 11:58
Откуда: г.Находка

Re: Возможен ли "нормальный" быстрый журнал

Сообщение Шевцов Владимир »

хм.. а какого размера у вас журнал?
у меня за два месяца это порядка 10 млн. записей - что уже вызывает ощутимые задержки при поиске.
архивирую помесячно - но этот самый архив потом загрузить целая проблема. очень долго ждать.
m0p3e
Местный житель
Сообщения: 1386
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва

Re: Возможен ли "нормальный" быстрый журнал

Сообщение m0p3e »

Под сиквелом писал процедуру перезаливки журнала в другую базу. Т.е. была база без данных содержащая только журнальную информацию. Поиск существенно упрощался. Запускалась процедура шедулером ночью.
При открытии архива каждый раз происходит заливка данных в таблицу в памяти. Процесс не быстрый...
Ответить