Alternative query options

Question

I am an assisting a co-worker on trying to improve an ugly query and I can't come up with good suggestions, based on all the business rules that have been applied.
The main rule is to try and convert everything from the production system into the data warehouse and if it cannot be converted, create a log for it.
Here is a short test case.
CREATE TABLE ATTY (atty_id number, nme varchar2(20));
INSERT INTO atty VALUES (1, 'Bob');
INSERT INTO atty VALUES (2, 'Perry');
INSERT INTO atty VALUES (3, 'Ben');
CREATE TABLE PHN (phn_id number, atty_id number, phn_no varchar2(15));
INSERT INTO phn VALUES (10,1,'800-555-1234');
INSERT INTO phn VALUES (11,2,'800-555-7890');
INSERT INTO phn VALUES (12,3,'800-555-6541');
CREATE TABLE ATTY_CASE_XREF (atty_id number, pers_id number, case_id number);
-- The attorney representing a person on a case.  Could be multiple people and/or attornies per case.
INSERT INTO atty_case_xref VALUES (2, 30, 40);
INSERT INTO atty_case_xref VALUES (2, 31, 40);
INSERT INTO atty_case_xref VALUES (3, 32, 41);
INSERT INTO atty_case_xref VALUES (2, 33, 41);
INSERT INTO atty_case_xref VALUES (1, 34, 42);  -- yes this points to nothing (aka bad data to deal with)
CREATE TABLE case (case_id number, docket varchar2(20));
-- Due to bad data, may not always have case for each reference above.
INSERT INTO case VALUES (40, '2013-abcdefg');
INSERT INTO case VALUES (41, '2013-pouyfbkjo');
COMMIT;
The test case query (a simplified version of the real one but captures the concepts)
SELECT ap.atty_id,
       ap.nme,
       p.phn_no,
       c.docket
  FROM atty ap
       INNER JOIN phn p
          ON ap.atty_id = p.atty_id
       INNER JOIN atty_case_xref acx
          ON ap.atty_id = acx.atty_id
       LEFT OUTER JOIN case c
         ON acx.case_id = c.case_id
UNION
SELECT ap.atty_id,
       ap.nme,
       p.phn_no,
       NULL
  FROM atty ap
       INNER JOIN phn p
          ON ap.atty_id = p.atty_id
       INNER JOIN atty_case_xref acx
          ON ap.atty_id = acx.atty_id;
The desired output (and what is output by the above SQL statement is) (order does not matter)
Atty_ID
NME
PHN_NO
DOCKET
1
Bob
800-555-1234
2
Perry
800-555-7890
2013-abcdefg
2
Perry
800-555-7890
2013-pouyfbkjo
2
Perry
800-555-7890
3
Ben
800-555-6541
2013-pouyfbkjo
3
Ben
800-555-6541
Basically, the first part (above the union) creates a record for each attorney on a case, even if a case record is not loaded.
The second part converts just a generic non case record for each unique attorney.
If attorney 1 is listed on 10 cases, need to create 11 records. One for each case and one with no case information 
The data warehouse table the data is loaded into serves two purposes.  It is a normal data table, but also acts as a code table.  That way if someone wants a list of all attorneys, they don't have to do a distinct, but can just query for a certain type of record (don't ask why).
The cost for the real version of this query is 248 Billion and was killed after several days of running as it was still building the result set.  The explain plan image I have shows the following row counts, ATTY = 96,255, PHN = 3,284,444, ATTY_CASE_XREF = 11,553,888, CASE = 14,421772.  We are looking for options that turn this into a one-pass run (or just reduce the cost) so it would complete in a reasonable time.
Any suggestions need to work on 10.2.  This seems like a good place for a MODEL clause, but I still struggle with that syntax.
And the cleanup
DROP TABLE atty purge;
DROP TABLE phn purge;
DROP TABLE atty_case_xref purge;
DROP TABLE case purge;

Answer 1

Glad you asked because I found out a couple of assumptions were no longer valid.  The code was developed on 10.2.0.4, and a copy still exists there, but apparently the client had upgraded their DB since I helped out many months ago.
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
SQL> select count(*) from dms_attyphn;
  COUNT(*)
  158612
SQL> select count(*) from dms_phn;
  COUNT(*)
  3284444
SQL> select count(*) from dms_atty;
  COUNT(*)
  96255
SQL> select count(*) from dms_ptyatty;
  COUNT(*)
  11553888
SQL> select count(*) from dms_case;
  COUNT(*)
  14421772
SQL> select count(*) from dm_phone;
  COUNT(*)
  2971525
I had also thought that DM_PHONE was empty, but an earlier part of the procedure that this query runs in populates a different set of phone data into the table, so the stats show it as empty, but in reality it had nearly 3 Million rows.
The actual query
SELECT DISTINCT p.cnv_phn_id,
                      p.cnv_phn_nbr,
                      pa.cnv_case_id,
                      ap.cnv_atty_id,
                      f_remove_site(ap.cnv_phn_cd) cnv_phn_cd,
                      ap.cnv_phn_cd_dscr,
                      a.cnv_idnt_id,
                      c.cnv_site_id
        FROM dms_attyphn ap
             INNER JOIN dms_phn p
                ON ap.cnv_phn_id = p.cnv_phn_id
             INNER JOIN dms_atty a
                ON a.cnv_atty_id = ap.cnv_atty_id
             INNER JOIN dms_ptyatty pa
                ON pa.cnv_atty_id = a.cnv_atty_id
             LEFT OUTER JOIN dms_case c
               ON pa.cnv_case_id = c.cnv_case_id
       WHERE NOT EXISTS (SELECT 1
                           FROM dm_phone dp
                          WHERE nvl(dp.pers_id_seq,'-1') = nvl(a.cnv_idnt_id,'-1')
                            AND nvl(dp.case_id_seq,'-1') = nvl(pa.cnv_case_id,'-1')
                            AND nvl(dp.phone_id,'-1')    = nvl(p.cnv_phn_id,'-1')
                            AND nvl(dp.type_cd,'-1')     = nvl(f_remove_site(ap.cnv_phn_cd),'-1'))
      UNION
      SELECT DISTINCT p.cnv_phn_id,
                      p.cnv_phn_nbr,
                      NULL,
                      ap.cnv_atty_id,
                      f_remove_site(ap.cnv_phn_cd) cnv_phn_cd,
                      ap.cnv_phn_cd_dscr,
                      a.cnv_idnt_id,
                      NULL
        FROM dms_attyphn ap
             INNER JOIN dms_phn p
                ON ap.cnv_phn_id = p.cnv_phn_id
             INNER JOIN dms_atty a
                ON a.cnv_atty_id = ap.cnv_atty_id
       WHERE NOT EXISTS (SELECT 1
                           FROM dm_phone dp
                          WHERE nvl(dp.pers_id_seq,'-1') = nvl(a.cnv_idnt_id,'-1')
                            AND dp.case_id_seq IS NULL
                            AND nvl(dp.phone_id,'-1')    = nvl(p.cnv_phn_id,'-1')
                            AND nvl(dp.type_cd,'-1')     = nvl(f_remove_site(ap.cnv_phn_cd),'-1'))
The NOT EXISTS are there to prevent this record from being loaded twice into the data warehouse.  On the initial load, this will not be an issue and we are discussing removing it from the initial load run.  For function f_remove_site(), I have come up with a few lines of SQL that will replace what that function does, in order to remove the SQL -> PL/SQL -> SQL context switches.
We do not have access via SQL*Plus to do trace/explain plan info so the following is taken from PL/SQL Developer (the format looked good in the pre block)
Description                     Object name          Cost            Cardinality     Bytes
SELECT STATEMENT, GOAL = ALL_ROWS               248006382352     19366615     1950133571
SORT UNIQUE                              248006382352     19366615     1950133571
  UNION-ALL                         
   FILTER                         
    HASH JOIN RIGHT OUTER                    260203          19207303     1939937603
     TABLE ACCESS FULL          DMS_CASE          111541          14421772     302857212
     HASH JOIN                              42334          19207303     1536584240
      HASH JOIN                              9204          159312          10195968
       HASH JOIN                         884          159312          7169040
        TABLE ACCESS FULL     DMS_ATTY          137          96255          1540080
        TABLE ACCESS FULL     DMS_ATTYPHN          309          158612          4599748
       TABLE ACCESS FULL     DMS_PHN               3043          3284444          62404436
      INDEX FAST FULL SCAN     DMS_PTYATTY_ID_IDX     17114          11553888     184862208
    TABLE ACCESS FULL          PHONE               12810          1          33
   FILTER                         
    HASH JOIN                              9204          159312          10195968
     HASH JOIN                              884          159312          7169040
      TABLE ACCESS FULL          DMS_ATTY          137          96255          1540080
      TABLE ACCESS FULL          DMS_ATTYPHN          309          158612          4599748
     TABLE ACCESS FULL          DMS_PHN               3043          3284444          62404436
    TABLE ACCESS FULL          PHONE               12735          1          33
As stated, the big question is, can we avoid the full table scan twice on the DMS_ATTY, DMS_ATTYPHN, and DMS_PHN tables.  That was my reason for creating the simple example, based on this larger complex query.