[PL/SQl]помогите с запросом[помогли!]

fufa58

собственно в силу слабого пока знания вопроса неожиданно возникла проблемная задача.
в общем, есть таблица(большая, 4 миллиарда записей). Из интересных полей есть дата SYS_CREATION_DATE, номер транзакции SRV_TRX_S_NO, название фичера FTRCDGRP, тип фичера NEW_OR_PREV, название параметра FTRPRM, значение параметра FEATURES.
как все это работает: каждый фичер есть набор параметров. кроме того, известно прошлое значение параметров для этого фичера, текущие параметры от предыдущих отличаются полем NEW_OR_PREV (там N или P). могут существовать фичеры с одинаковыми именами в разных транзакциях, в одном фичере в пределах одинакового NEW_OR_PREV не может быть одноименных параметров. т.е. получается примерно такая табличка:


























SYS_CREATION_DATESRV_TRX_S_NOFTRCDGRPNEW_OR_PREVFTRPRMFEATURES

01.01.01 12:00:00		1CHPPAYNPARAM11

01.01.01 12:00:00		1CHPPAYNPARAM22

01.01.01 12:00:00		1CHPPAYPPARAM11

01.01.01 12:00:00		1CHPPAYPPARAM23

01.01.01 12:00:00		1CHCLIPNPARAM11

01.01.01 12:00:00		1CHCLIPNPARAM22

01.01.01 12:00:00		1CHCLIPPPARAM11


так вот. Параметр считается изменившимся (розовые элементы в таблице сверху если его значения в пределах данного фичера в пределах данной транзакции для new и previous либо различаются, либо если он существовал только в одном из этих состояний.
фичер соответственно считается изменившимся, если в нем есть изменившиеся параметры.
И зная все это надо построить статистику по промежуткам времени, сколько параметров/фичеров за данный промежуток было изменено. помогите плз :crazy:

0000

Т.е. для приведенной таблицы ответ 2?

fufa58

ну точнее ответ типа





01.01.01 12:00:0022


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

VoodooXP

ответ где?

fufa58

мне тут рассказали много чего интересного, так что ответ пока в виде цикла по часам с 
                SELECT NVL(SUM(uniq_param0 NVL(SUM(uniq_feature0) INTO par_ch_num, fch_ch_num

                FROM 

                (

                        SELECT COUNT(*) AS uniq_param, COUNT(DISTINCT ftrcdgrp) AS uniq_feature

                        FROM 

                        (

                                SELECT 

                                srv_trx_s_no, ftrcdgrp,

                                COUNT(*) over (PARTITION BY srv_trx_s_no, ftrcdgrp, ftrprm, features) AS cnt

                                FROM srvtrx_ftr 

                                WHERE

                                (sys_creation_date BETWEEN loop_date AND (loop_date+3599/86400

                                AND

                                partition_id = start_partition_id <- предварительно считается по формуле. 

                                AND

                                srv_trx_s_mod in (1,2,3,4,5)

                         )

                         WHERE CNT < 2

                         GROUP BY srv_trx_s_no

                 );

но по идее ещё будет слегка переделан. на тестовых базах обнаружилось отсутствие индексов :crazy:

VoodooXP

но по идее ещё будет слегка переделан. на тестовых базах обнаружилось отсутствие индексов
а как вообще там что-то работает без индексов на таких объемах данных? фуллсканит? :grin:

klyv

фуллсканит?
он всегда фулсканит. и это всегда индекс, покуда есть таковой (а обычно хотя бы по primary key он есть иногда это - тупо-таблица (вырожденный случай индекса - по id строчки)
и окгда он сканит по индексу, который выбирает только те значения, которые нам нужны (или почти только их наступает вселенское счастье

VoodooXP

собери статистику

VoodooXP

ну и индексы тоже надо правильно создавать

klyv

собери статистику
по чему?

klyv

ну и индексы тоже надо правильно создавать
дык и я о том же ;)

VoodooXP

запрос еще считает вовсе не то, что в первом посте...

0000

Ну ты молодец, что не поленился разобраться :)
Для меня в текущей постановки задача требует напрячь моск.
Автор, если хочешь получить больше ответов ПРОЩЕ сформулируй задачу, в частности хоть столбцы и значения переименуй в человечьи, не привязанные к твоему бизнесу.

fufa58

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

Vantucha

а как вообще там что-то работает без индексов на таких объемах данных? фуллсканит?
вот афтор пишет про данные за час, и еще вроде как цикл собирается по этому делать
если в итоге нужны результаты скажем за день, вполне возможно, что партициирование по дням + фуллскан будет выгоднее индексов

fufa58

ну так, к слову, у нас на партиции лежат данные за 4 дня, но статистика нужна почасовая.

klyv

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

Vantucha

спорное утверждение
когда выбирается процент данных близкий к 100, фулл скан по таблице практически всегда выгоднее full/range/skip сканов по индексу
ибо db file scattered read
кроме того, доступ по индексу всегда жрет буферный кэш, что в случаях с большим кол-вом данных отрицательно влияет не только на текущую, но и на другие сессии

klyv

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

fester

и сколько твоя процедурка работает, чтобы выдать данные, скажем, за одни сутки?
не проще ли какие-нить оконные функции юзать?
это я к тому, что каждый час (loop это фактически фулскан целой партиции, а мне кажется, что партиция у тебя не хилая.
Оставить комментарий
Имя или ник:
Комментарий: