Oracle: hugely improve query performance -

i have next query i'm trying improve performance:

select atx.journal_id     ,ab.c_date acct_batch ab      join acct_tx atx on ab.acct_id = atx.acct_id        , ab.batch_id = atx.batch_id     join journal j on j.journal_id = atx.journal_id       , j.journal_type_id = 6     join acct on a.acct_id = atx.acct_id        , a.acct_type_id = 32     join payments p on p.payment_id = j.payment_id     join routing r on r.route_id = p.route_id        , r.acq_code = 'rz_ns'     join acq_acct aa on aa.acq_code = r.acq_code       , aa.acq_acct_code = r.acq_acct_code       , aa.slc = 'mxm' ab.c_date between to_date(to_char('01-jul-2015')) ,  last_day(sysdate); 

i've ran , reviewed explain plan , total cost 7388. out of this, expensive part join journal table, has cost of 6319.

the table has approximately 1.6 million rows 87 partitions, out of 2 contain rows (partition 6 1.4 million , partition 12 approximate rest of 200k rows).

the first thing i've tried re-write query avoid full-scan on matching actual journal_type_id 6, guess understanding incorrect, because cost remained 7388.

select atx.journal_id     ,ab.c_date acct_batch ab      join acct_tx atx on ab.acct_id = atx.acct_id        , ab.batch_id = atx.batch_id     join (select                journal_id               , payment_id            journal            journal_type_id = 6) j on j.journal_id = atx.journal_id     join acct on a.acct_id = atx.acct_id        , a.acct_type_id = 32     join payments p on p.payment_id = j.payment_id     join routing r on r.route_id = p.route_id        , r.acq_code = 'rz_ns'     join acq_acct aa on aa.acq_code = r.acq_code       , aa.acq_acct_code = r.acq_acct_code       , aa.slc = 'mxm' ab.c_date between to_date(to_char('01-jul-2015')) ,  last_day(sysdate); 

i did lot of resources , 1 of reason determined me re-write query this video.

i'm still actively looking ways of improving performance, thought i'd shoot question here maybe hints.

i think person video says first thing should done identify "driving table" (the 1 determines rows being selected - based on key), i'm looking way of re-writing query identify , use driving table , indexes as possible.

i don't know if i'm on right track yet, please stop me if think should proceed otherwise. also, please note total beginner in performance tuning, being first.

any appreciated.

update:

some of indexes contain columns used in queries are:

╔════════════╦═══════════════╦════════════╦═══════════╦═════════════╦═══════════════════════════════════╗ ║   table    ║   indexname   ║ uniqueness ║ indextype ║ partitioned ║              columns              ║ ╠════════════╬═══════════════╬════════════╬═══════════╬═════════════╬═══════════════════════════════════╣ ║ acct_batch ║ acct_batch_pk ║ unique     ║ normal    ║ no          ║ acct_id, batch_id                 ║ ║ acct_tx    ║ acct_tx_idx   ║ nonunique  ║ normal    ║ yes         ║ acct_id, batch_id                 ║ ║ acct_tx    ║ acct_tx_bidx  ║ nonunique  ║ normal    ║ yes         ║ journal_id, acct_id               ║ ║ journal    ║ journal_pk    ║ unique     ║ normal    ║ yes         ║ journal_id                        ║ ║ journal    ║ jtype_bidx    ║ nonunique  ║ normal    ║ yes         ║ journal_type_id, book_date        ║ ║ journal    ║ jtype_bidx_2  ║ nonunique  ║ normal    ║ yes         ║ mcode, journal_type_id, book_date ║ ║ journal    ║ jpay_bidx     ║ nonunique  ║ normal    ║ yes         ║ payment_id, journal_id            ║ ╚════════════╩═══════════════╩════════════╩═══════════╩═════════════╩═══════════════════════════════════╝ 

let me know if need see more indexes or details regarding other tables.

sample explain plan:

------------------------------------------------------------------------------------------------------------------------------- | id  | operation                                 | name              | rows  | bytes | cost (%cpu)| time     | pstart| pstop | ------------------------------------------------------------------------------------------------------------------------------- |   0 | select statement                          |                   |     1 |   160 |  7388   (1)| 00:01:29 |       |       | |*  1 |  filter                                   |                   |       |       |            |          |       |       | |   2 |   nested loops                            |                   |       |       |            |          |       |       | |   3 |    nested loops                           |                   |     1 |   160 |  7388   (1)| 00:01:29 |       |       | |*  4 |     hash join                             |                   |     4 |   604 |  7380   (1)| 00:01:29 |       |       | |   5 |      nested loops                         |                   |       |       |            |          |       |       | |   6 |       nested loops                        |                   |   107 | 14338 |  7372   (1)| 00:01:29 |       |       | |*  7 |        hash join                          |                   |    27 |  3186 |  7298   (1)| 00:01:28 |       |       | |   8 |         nested loops                      |                   |       |       |            |          |       |       | |   9 |          nested loops                     |                   |   102 | 10302 |   978   (0)| 00:00:12 |       |       | |  10 |           nested loops                    |                   |    11 |   638 |    37   (0)| 00:00:01 |       |       | |* 11 |            table access index rowid    | acq_acct          |    11 |   253 |     4   (0)| 00:00:01 |       |       | |* 12 |             index range scan              | aa_pk             |    16 |       |     2   (0)| 00:00:01 |       |       | |  13 |            table access index rowid    | routes            |     1 |    35 |     3   (0)| 00:00:01 |       |       | |* 14 |             index range scan              | r_a_bidx          |     1 |       |     2   (0)| 00:00:01 |       |       | |  15 |           partition range             |                   |    95 |       |    84   (0)| 00:00:02 |     1 |    84 | |* 16 |            index range scan               | p_r_id_bidx       |    95 |       |    84   (0)| 00:00:02 |     1 |    84 | |  17 |          table access local index rowid| payments          |     9 |   387 |   100   (0)| 00:00:02 |     1 |     1 | |  18 |         partition range               |                   |   107k|  1782k|  6319   (1)| 00:01:16 |     1 |    87 | |* 19 |          table access full                | journal           |   107k|  1782k|  6319   (1)| 00:01:16 |     1 |    87 | |  20 |        partition range iterator           |                   |     4 |       |     2   (0)| 00:00:01 |   key |   key | |* 21 |         index range scan                  | atx_a_idx         |     4 |       |     2   (0)| 00:00:01 |   key |   key | |  22 |       table access local index rowid   | acct_tx           |     4 |    64 |     3   (0)| 00:00:01 |     1 |     1 | |* 23 |      index range scan                     | ab_b_a_idx        |  5006 | 85102 |     8   (0)| 00:00:01 |       |       | |* 24 |     index unique scan                     | acc_pk            |     1 |       |     1   (0)| 00:00:01 |       |       | |* 25 |    table access index rowid            | acct              |     1 |     9 |     2   (0)| 00:00:01 |       |       | ------------------------------------------------------------------------------------------------------------------------------- 

first check statistics updated: optimizer heavily depends on stats! second should number of rows query: depending on number of rows each condition selects better full scan index search.