Tricky query needing clever SQL...

Question

A table called alt_websearch_log records the time it takes to complete each search performed on a website. I am therefore able to write something like this:
select to_char(search_date,'DD/MON/YYYY'), count(*), avg(searchtime_secs), max(searchtime_secs)
from alt_websearch_log
group by to_char(search_date,'DD/MON/YYYY')
order by to_char(search_date,'DD/MON/YYYY') desc
...and it works fine, giving me a daily average search time over a period of weeks or months for reporting to management. The trouble is that I have to periodically rebuild the indexes that make this search work, and during the time that the rebuild is taking place -not surprisingly- search performance slows down quite a bit.
(Incidentally, I know not to rebuild indexes routinely, but these two are special, because they're Context indexes and the table on which they're built is itself completely reconstructed at weekends. It's a weird system, but we have to do it that way, for lots of reasons I ask you to take on trust, at least for now!)
My rebuilding code has been modified to insert a line into the alt_websearch_log table, so that I can select from it and see this sort of thing:
SESSION_ID SERVERNAME SEARCHTERMS SEARCHDATE
99999999999 LOCALDBSRVR START REBUILD 15/7/2008 16:00
And when the rebuild completes, I put a very similar line that says 'STOP REBUILD' at (say) 15/7/2008 18:00
So what I would like to be able to do is to run the same sort of query as I started with, but with all the searches that take place between a start and stop rebuild marker being ignored for the purposes of computing the average and maximum.
My problem is that I cannot conceive of a query that discards rows between a start and stop time that happens repeatedly (for example, I would have a START/STOP pair on 8th July, 1st July, 23 June and so on, but because manual rebuilds might sometimes happen, there's no definite pattern for when such pairs occur).
In other words, if the sorted data ran;
1/7/08 10:00 1.3secs
1/7/08 10.05 1.4 secs
1/7/08 10:10 start rebuild
1/7/08 10:11 2.5 secs
1/7/08 10:12 4.5 secs
1/7/08 10:15 stop rebuild
1/7/08 10:16 1.1 secs
2/7/08 11:00 1.1secs
2/7/08 11.03 1.1 secs
2/7/08 11:05 start rebuild
2/7/08 11:14 3.1 secs
2/7/08 11:16 3.6 secs
2/7/08 11:25 stop rebuild
2/7/08 11:36 1.2 secs
...I would want 1.3, 1.4 and 1.1 to be averaged to a total of 1.267 for 1/7/08, and the two 2 second plus searches on that to be ignored for reporting purposes. And then I'd need the average for 2/7/08 to be reported as 1.13 seconds, with the two 3+ second response times ignored, because they were recorded between that day's start/stop rebuild markers.
Whilst it is theoretically possible that a 'start' could begin at, say 5 to midnight and its corresponding 'stop' wouldn't be recorded until 5 past midnight, if it makes it any easier, you can assume that a start and a stop always share the same date.
It is also possible in real life that we might do more than one rebuild per day, but if it makes it any easier, it's OK to assume only one start/stop marker will be recorded per day. (Actually, it would be nice if you didn't have to assume that, because this is a situation I know we would definitely face at some point in the future).
I'd very much appreciate some insight into any SQL techniques that can be used to deal with this issue. I am guessing some of the modelling commands might be useful, but I don't know where to begin on that. I'm using 10.2.0.3 on Windows.
Sorry for the long question. Grateful for any help.

Answer 1

OK build a sample table,
create table alt_websearch_log
(search_date date,
search_time_secs numeric(9,2),
searchterms varchar2(50));
insert into alt_websearch_log values (to_date('1/7/08 10:00','dd/mm/yy hh24:mi'),1.3,'bob,sally');
insert into alt_websearch_log values (to_date('1/7/08 10:05','dd/mm/yy hh24:mi'),1.4,'dev');
insert into alt_websearch_log values (to_date('1/7/08 10:10','dd/mm/yy hh24:mi'),null,'start rebuild');
insert into alt_websearch_log values (to_date('1/7/08 10:11','dd/mm/yy hh24:mi'),2.5,'code');
insert into alt_websearch_log values (to_date('1/7/08 10:12','dd/mm/yy hh24:mi'),4.5,'nugget');
insert into alt_websearch_log values (to_date('1/7/08 10:15','dd/mm/yy hh24:mi'),null,'stop rebuild');
insert into alt_websearch_log values (to_date('1/7/08 10:16','dd/mm/yy hh24:mi'),1.1,'random');
insert into alt_websearch_log values (to_date('2/7/08 11:00','dd/mm/yy hh24:mi'),1.1,'search');
insert into alt_websearch_log values (to_date('2/7/08 11:03','dd/mm/yy hh24:mi'),1.1,'term');
insert into alt_websearch_log values (to_date('2/7/08 11:05','dd/mm/yy hh24:mi'),null,'start rebuild');
insert into alt_websearch_log values (to_date('2/7/08 11:14','dd/mm/yy hh24:mi'),3.1,null);
insert into alt_websearch_log values (to_date('2/7/08 11:16','dd/mm/yy hh24:mi'),3.1,null);
insert into alt_websearch_log values (to_date('2/7/08 11:25','dd/mm/yy hh24:mi'),null,'stop rebuild');
insert into alt_websearch_log values (to_date('2/7/08 11:36','dd/mm/yy hh24:mi'),3.1,null);
insert into alt_websearch_log values (to_date('2/7/08 11:39','dd/mm/yy hh24:mi'),1.1,'tube');
commit;then try this..
col av_stime for 99.99
col max_s_time for 99.99
select trunc(search_date),avg(SEARCH_TIME_SECS) av_stime,max(search_time_secs) max_s_time from
(select search_date,search_time_secs,
nvl((LAST_VALUE(decode(searchterms,'stop rebuild','stop rebuild','start rebuild','start rebuild',null) IGNORE NULLS) over
(ORDER BY search_date ROWS BETWEEN UNBOUNDED PRECEDING AND current row)),'stop rebuild') AS term
from alt_websearch_log) a
where term = 'stop rebuild'
group by trunc(search_date)
order by trunc(search_date) desc;
TRUNC(SEA AV_STIME MAX_S_TIME
02-JUL-08     1.60       3.10
01-JUL-08     1.27       1.40this work accross days and with multiple rebuilds, randolphs comments apply if
the logic is broken and a rebuild deosn't get logged correctly this will return odd
results. It may be safer to add an additional column to log the rebuilds as you will
have a problem is a user searches for one of the two key terms. Also I have
assumed the search_time_secs will be null when you log the rebuilds.
Chris