Query on GL_BALANCES Table is very slow

Question

Dear Members,
I have prepared a query on GL_BALANCES Table which is as follows:
SQL>
select (nvl(sum(gb.period_net_dr), 0) - nvl(sum(gb.period_net_cr), 0))
INTO V_AMT
from gl_balances gb,
gl_code_combinations gcc,
fnd_flex_value_hierarchies ffvh
where gb.set_of_books_id = 7
and gb.actual_flag = 'B'
and gb.period_year = P_YEAR --'2010'
and gb.budget_version_id = P_BUD_VER_ID--1234
and gb.code_combination_id = gcc.code_combination_id
and gcc.segment3 >= ffvh.child_flex_value_low
and gcc.segment3 <= ffvh.child_flex_value_high
and ffvh.flex_value_set_id = 1012576
and ffvh.parent_flex_value = P_FLEX_VAL;
The above query is taking long time to complete.
Plan of my query is as follows
SELECT STATEMENT, GOAL = CHOOSE     Cost=49885     Cardinality=1     Bytes=64
SORT AGGREGATE                                    Cardinality=1     Bytes=64
MERGE JOIN               Cost=49885     Cardinality=12     Bytes=768
SORT JOIN               Cost=49859     Cardinality=2192     Bytes=74528
HASH JOIN               Cost=49822     Cardinality=2192     Bytes=74528
TABLE ACCESS FULL     Object owner=GL     Object name=GL_BALANCES     Cost=47955     Cardinality=2192     Bytes=50416
TABLE ACCESS FULL     Object owner=GL     Object name=GL_CODE_COMBINATIONS     Cost=1854     Cardinality=526850     Bytes=5795350
FILTER                         
SORT JOIN                         
INDEX RANGE SCAN     Object owner=APPLSYS     Object name=FND_FLEX_VALUE_HIERARCHIES_N1     Cost=2     Cardinality=2     Bytes=60
Can any one please help me in tuning this query.
Thanks in advance.
Best Regards.

Answer 1

As per the other replies, you've not really given enough information to go on - what are you trying to achieve, versions, etc.
On my old apps 11.5.8 system, the explain plan for your query uses GL_CODE_COMBINATIONS_U1 rather than a full scan of gl_code_combinations.
Check your stats are up to date (select table_name, num_rows, last_analyzed from dba_tables where ...)
See if you can also use period_name and/or period_set_name (or period_num) from GL_Periods rather than period_year (i.e. use P_YEAR to lookup the period_name/period_set_name/period_num from gl_periods). It might be faster to do per period and then consolidate for the whole year, as there are indexes on gl_balances for columns period_name, period_set_name, period_num.
regards, Ivan