Order by disk sort porblem

Question

hi friends i have a querry which return 40.000 rows and 2 mb data. this querry works in 1-2 seconds. if i add simple order by to querry it work in 20 seconds.
i think because of disk sort. but i have another querry which have 270.000 row and 8 mb data its dont do disk sort. i write my querry, and in my opinion something force it disk sort instead of ram and row. but i dont find the problem.
thanks
SELECT p.nkisi_uygulama_id, p.nvardiya_id,
          p.dbaslangic_tarih AS dper_vardiya_bas_tarih,
          p.dbitis_tarih AS dper_vardiya_bit_tarih, p.nper_vardiya_id,
          v.nvad AS nvvardiya_ad, v.nvaciklama, v.nvbaslama_saat,
          v.ntoplam_saat, TO_CHAR (d.tarih, 'DAY') AS nvgun,
          TO_DATE (d.tarih || ' ' || v.nvbaslama_saat,
                   'DD.MM.YYYY HH24:MI'
                  ) AS dbaslangic_zaman,
            TO_DATE (d.tarih || ' ' || v.nvbitis_saat,
                     'DD.MM.YYYY HH24:MI'
          + CASE
               WHEN TO_DATE (d.tarih || ' ' || v.nvbitis_saat,
                             'DD.MM.YYYY HH24:MI'
                            ) <
                      TO_DATE (d.tarih || ' ' || v.nvbaslama_saat,
                               'DD.MM.YYYY HH24:MI'
                  THEN 1
               ELSE 0
            END AS dbitis_zaman,
          (SELECT bvardiya_izin
             FROM iky_tnm_vardiya_gun vi
            WHERE vi.nvardiya_id = v.nvardiya_id
              AND TO_CHAR (d.tarih, 'D') =
                     CASE
                        WHEN vi.ntip_gun_id = 781
                           THEN 1
                        WHEN vi.ntip_gun_id = 782
                           THEN 2
                        WHEN vi.ntip_gun_id = 783
                           THEN 3
                        WHEN vi.ntip_gun_id = 784
                           THEN 4
                        WHEN vi.ntip_gun_id = 785
                           THEN 5
                        WHEN vi.ntip_gun_id = 786
                           THEN 6
                        WHEN vi.ntip_gun_id = 787
                           THEN 7
                     END) AS bvardiya_izin
     FROM iky_tnm_vardiya v,
          iky_hrk_per_vardiya p,
          TABLE (pck_iky_func.f_tbl_per_vardiya_zaman ()) d
    WHERE p.nvardiya_id = v.nvardiya_id
      AND d.ID = p.nper_vardiya_id
      AND p.nvardiya_id IS NOT NULL
      AND TO_CHAR (d.tarih, 'D') IN (
             SELECT CASE
                       WHEN g1.ntip_gun_id = 781
                          THEN 1
                       WHEN g1.ntip_gun_id = 782
                          THEN 2
                       WHEN g1.ntip_gun_id = 783
                          THEN 3
                       WHEN g1.ntip_gun_id = 784
                          THEN 4
                       WHEN g1.ntip_gun_id = 785
                          THEN 5
                       WHEN g1.ntip_gun_id = 786
                          THEN 6
                       WHEN g1.ntip_gun_id = 787
                          THEN 7
                    END
               FROM iky_tnm_vardiya_gun g1
             WHERE
                    v.nvardiya_id = g1.nvardiya_id)
ORDER BY nkisi_uygulama_id;

Answer 1

Listen to Billy & Centinul. You'll need to figure out why the query is really slow, and the notes on tuning should help.
Looking at your query: the sorting won't help performance. Make sure it is not sorting to disk (you can use AUTOTRACE in SQL*PLUS or SQL*DEVELOPER for this).
Select list inline views are notorious for a couple of reasons. First, they can decrease performance by executing for every row. Second, under just the wrong conditions their actvity will not show up in execution plans - I just rewrote one as a insert/select from in 10gR2 to PL/SQL and the original execution plan only showed the insert with a cost of 2 (!); this is standard behavior on 9i (in my case I was able to consolidate multiple queries with a possible 50% per-line run time according to dbms_profiler).
Table functions are also problematic for a couple of reasons - they provide needed functionality, but due to the converstion there are no statistics available to effectively plan out the execution by the CBO. The cardinality hint might help this somewhat but you have to hard-code the numbers. Sometimes the despised rule-based optimizer can help with conversions where there are no statistics available but this needs to be examined very carefully
SQL looks so much more impressive when used with foreign languages :)