[sql performance] inline view , group by , max, join

Question

Hi. everyone.
I have a question with regard to "group by" inline view ,
max value, join, and sql performance.
I will give you simple table definitions in order for you
to understand my intention.
Table A (parent)
C1
C2
C3
Table B (child)
C1
C2
C3
C4 number type(sequence number)
1. c1, c2, c3 are the key columns of tabla A.
2. c1, c2, c3, c4 are the key columns of table B.
3. table A is the parent table of Table B.
4. c4 column of table b is the serial number.
(c4 increases from 1 by "1" regarding every (c1,c2,c3)
the following is the simple example of the sql query.
select .................................
from table_a,
(select c1, c2, c3, max(c4)
from table_b
group by c1, c2, c3) table_c
where table_a.c1 = table_c.c1
and table_a.c2 = table_c.c2
and table_a.c3 = table_c.c3
The real query is not simple as above. More tables come
after "the from clause".
Table A and table B are big tables, which have more than
100,000,000 rows.
The response time of this sql is very very slow
as everyone can expect.
Are there any solutions or sql-tips about the late response-time?
I am considering adding a new column into "Table B" in
order to identify the row, which has max serial number.
At this point, I am not sure adding a column is a good
thing in terms of every aspect.
I will be waiting for your advice and every response
will be appreciated even if it is not the solution.
Have a good day.
HO.
Message was edited by:
user507290

Answer 1

For such big sources check that
1) you use full scans, hash joins or at least merge joins
2) you scan your source data as less as possible. In the best case each necessary table only once (for example not using exists clause to effectively scan all table via index scan).
3) how much time you are spending on sorts and hash joins (either from v$session_longops directly or some tool that visualises this info). If you are using workarea_size_policy = auto, probably you can switch to manual for this particular select and adjust sort_area_size and hash_area_size big enough to do as less as possible sorts on disk
4) if you have enough free resources i.e. big box probably you can consider using some parallelism
5) if your full scans are taking big time check what is your db_file_multiblock_read_count, probably increasing it for this select will give some gain.
6) run trace and check on what are you waiting for
7) most probably your problem is IO bound so probably you can do something from OS side to make IO faster
8) if your query now is optimized as much as you can, disks are running as mad and you are using all RAM then probably it is the most you can get out of your box :)
9) if nothing helps then you can start thinking about precalculations either using your idea about derived column or some materialized views.
10) I hope you have a test box and at least point (9) do firstly on it and see whether it helps.
Gints Plivna
http://www.gplivna.eu