|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Что бы возвращались First Rows, то, насколько я понимаю, в плане не должно быть сортировки (можно попытаться избежать за счет прохода по индексу), в плане должен быть Nested Loops. Что бы было максимально быстро, пытаться исключить доступ к таблицам. Как минимум, что бы доступа к t_log не было вообще (только Index Full Scan) Ну и партиционирование, обработка запросов в несколько потоков. IMHO & AFAIK p.s. постановка задачи "ищем по like сами незнаем что, лишь бы что-то нашлось". Очень напомнило ТЗ на "секретную" систему мониторинга трафика ФСО. Когда трафик свален в таблицы, но никаких адекватных критериев поиска по ним не сформулировано. И (не знаю как называется должность) кто-то эти таблицы смотрит в PL/SQL Developer'е пытаясь "уязвимости" обнаружить ))) p.p.s. По нормальному, нужно в отдельную таблицу ключевые слова типа Навальный, Соболь и прочее выносить и триггером или job'ом сразу и проверять ))) ни оператор ни аналитик тут не нужен. Агенты ЦРУ и так всем известны. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 12:57 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev p.s. постановка задачи "ищем по like сами незнаем что, лишь бы что-то нашлось". имхо сдесь проще (обычная ситуация) анализируем лог (одна широкая табличка) по некоторому параметру основной отбор по индексу (допустим ранже) и чтоб не было сортировки (в плане нет сортировки) для анализа достаточно около 200 "первых" по индексу записей все ок когда индекс+фильтр набирают 200 записей скажем в "первом по индексу" миддионе строк (напр за 10сек) но есть фильтры, которые отбирают 199 записей в первом млн, следуящая 200 очень далеко по индеску и доберемся до нее за 20 мин Egoр хочет как-то указать что 199 тож хватает, и после 10сек поиска отрабатываем как для rownum<=199 (stop key) sample по времени ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 13:44 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Stax, А 198-ми записей хватит, а 20-ти, а одной, а если ни одной записи не будет получено за отведенное время, но записи там где то есть, хотя было это давно и неправда? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 14:28 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
graycode Stax, А 198-ми записей хватит, а 20-ти, а одной, а если ни одной записи не будет получено за отведенное время, но записи там где то есть, хотя было это давно и неправда? имхо неважно сколько (200 для примера привел) select * from (select /*+ index (t ii) */ from t sample интервал order by ii) r where rownum<200 не важно скоко вернет, мож и 0 строк, если за интервал не доберется ни до одной ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 14:45 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Stax, Автору топика уже предлагали ограничить выборку разумным интервалом по дате появления записи в таблице и вообще разбить на разделы, а лишний мусор удалить или слить в архив и затем удалить, однако автор упорно ищет философский камень. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 14:59 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
graycode Stax, Автору топика уже предлагали ограничить выборку разумным интервалом по дате появления записи в таблице и вообще разбить на разделы, а лишний мусор удалить или слить в архив и затем удалить, однако автор упорно ищет философский камень. уверен, он ето знает ищет другие возможности, которых возможно еще нет ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 15:03 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Stax Egoр, на правах попробовать шютку rownum < f_time200(rownum,sysdate,200) в ф-ции if time work < xxx then return 200 else return 1 /* rownum-1 */ end if ..... stax в случае FULL SCAN время выполнения может быть превышено в разы пока дойдет до первой подходящей строки. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 15:38 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
SY, тогда вернет 0, и возможно надо увеличивать интервал работы ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 15:41 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
SY Stax Egoр, на правах попробовать шютку rownum < f_time200(rownum,sysdate,200) в ф-ции if time work < xxx then return 200 else return 1 /* rownum-1 */ end if ..... stax А теперь помедитируй сколько раз выполнится f_time200(rownum,sysdate,200). Сравни с например: rownum < f_time200(rownum,sysdate,nvl2(col1,200,200)) Ну и в случае FULL SCAN время выполнения может быть превышено в разы пока дойдет до первой подходящей строки. SY. Соломон, большая просьба не злоупотреблять модераторскими возможностями для ЛИЧНЫХ целей. Если ступил, недочитал или т.п. то лучше признай, а не подтирай свои следы. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 15:45 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
на авторА теперь помедитируй сколько раз выполнится f_time200(rownum,sysdate,200). Сравни с например: rownum < f_time200(rownum,sysdate,nvl2(col1,200,200)) был ответ 22239790 ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 15:50 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Elic Соломон, большая просьба не злоупотреблять модераторскими возможностями для ЛИЧНЫХ целей. Если ступил, недочитал или т.п. то лучше признай, а не подтирай свои следы. А что редактировать собственные сообщения может только модератор??? SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 15:57 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Stax которых возможно еще нет А, возможно, есть. - Для ad-hoc запросов при типовых в аналитике предикатах равенства (тождества) могут подойти bitmap-индексы. - Для иных вариантов можно попробовать Orace Text или напрячься собственной реализацией доменного индекса для нечеткого поиска. - Для прерывания по timeout можно, к примеру, швыряться no_data_needed из pipelined ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 16:01 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Stax, спасибо В таком виде заработало Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Так, наверное, даже правильнее. Таймаут-таймауту рознь. А тут явно сказано, хошь-как-хошь, а 1е7 записей просмотри. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 16:09 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
SY А что редактировать собственные сообщения может только модератор??? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2020, 16:10 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Egoр, Интересный способ удалять гланды через одно место ... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2020, 00:02 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
graycode, У вас есть юзфулл предожения? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2020, 20:30 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Смотреть план запроса. С учетом "не заканчивается до победного конца" и "в таком виде заработало" не удивлюсь, если в исходном запросе Hash Join образовался. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2020, 20:35 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Egoр, Выше было много предложений ... Ограничивать период по идентификатору довольно странное решение, могу предложить разве что получать идентификатор соответствующий вашему Код: plsql 1. 2. 3. 4.
и затем использовать его в select * from r1 where log_id > :p_id and note like :note, в зависимости от прироста объемов хватит на неделю или месяц. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2020, 02:25 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Egoр Аналитик я. Моя бизнес задача - проанализировать протокол в системе. Я реально выдумываю условия поиска в зависимости от ситуации. Т.е. никаких формальных правил нет? Каждый раз новый поиск с новыми условиями по абсолютно любым полям протокола? А они какого типа - тупо CLOB? Если сортируется по log_id, то почему вместо выдирания всех протоколов с сортировкой в одном запросе не заменить на N запросов (по числу протоколов) с прямым отбором по log_id и уже доп.условиям? Это и быстрее выполняется, и ответы есть сразу, и можно остановиться на любом, не выполняя остальных. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2020, 03:29 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
graycode, Предложений было много, но все сводились к измению поставки задачи. Однако частое ее переформулирование привело к решению. А ваш последний вариант по сути есть усложнение моего. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2020, 11:29 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Правильный Вася, Ага. примерно так. Есть протокол. Есть некое внешнее неформализуемое событие. Нужно просмотреть последние записи протокола, которые могут иметь отношение к этому событию. Сколько этих записей - не известно. Начинаю с двухсот. Если не хватает, то увеличиваю, 500, 1000, 5000 ... И иной раз случается, что запсиси для выбранного условия в таблице заканчиваются. Ваше предложение, честно говоря, не понял. "заменить на N запросов по числе протоколов"? пртокол-то один. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2020, 11:47 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Egoр Ваше предложение, честно говоря, не понял. "заменить на N запросов по числе протоколов"? пртокол-то один. Из постановки задачи я понял, что log_id не уникальный, т.е. несколько записей относятся к одному протоколу, идентифицируемому этим log_id, а самих протоколов много. Тогда и можно брать протокол с конкретно его записями, а не все протоколы с их записями сразу. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2020, 18:10 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Egoр А ваш последний вариант по сути есть усложнение моего. Чего чего? С этого момента поподробнее пожалуйста, в чем усложнение? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2020, 20:37 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Egoр Леонид, вот запрос Код: plsql 1. 2. 3. 4. 5. 6.
работает великолепно, когда в t_log по log_id desc достаточно достаточно записей, соответствующих note like :note. Но если в t_log в по log_id desc есть только 199 записей like :note, а следующая только через сотню миллионов, то БД честно сканирует все эти сто миллионов, хотя уже на первом десятке можно было бы и остановится, если бы :note были вида 'SMTH%' то помогло бы создание индекса по note. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 11:26 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
graycode Egoр А ваш последний вариант по сути есть усложнение моего. Чего чего? С этого момента поподробнее пожалуйста, в чем усложнение? Для log_id > :p_id нужен :p_id Получить :p_id, соответствующий моему rownum < 1e7, можно через условие rownum < 1e7 Но зачем получать :p_id и подставлять его в log_id > :p_id, если уже rownum < 1e7 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 12:39 |
|
|
start [/forum/topic.php?fid=52&msg=40023397&tid=1880610]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
135ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 262ms |
0 / 0 |