Настройка производительности Oracle SQL с использованием огромных таблиц - PullRequest
3 голосов
/ 02 июня 2019

У меня есть запрос Oracle SQL, который включает в себя соединения с 4 большими таблицами и несколькими небольшими таблицами.Большие таблицы: TBL_1, TBL_2, TBL_3, TBL4, каждая из которых имеет приблизительно 8 миллионов записей.Остальные - это небольшие таблицы, содержащие менее 10 тыс. Записей.

Проблема: запрос занимает более 3 минут, даже если нет данных для возврата.

Статистика таблиц и индексов не превышаетДата.В этих таблицах нет устаревшей статистики.

Я пытался использовать подсказки, но это не сработало.

Пожалуйста, посмотрите мои наблюдения ниже:

Запрос:

    SELECT a.*, ROWNUM AS rnm
      FROM (  SELECT c.idntfr,
             pr.program_name AS "Program",
             e.case_number,
             (SELECT DECODE (s.status_name,
                     'EA', 'A',
                     'ED', 'D',
                     'EU', 'U',
                     s.status_name)
                FROM TBL_5 ms, status s
               WHERE     ms.status_type_cid = 7
                 AND mbr_sid = c.mbr_sid
                 AND ms.status_type_cid = s.status_type_cid
                 AND s.status_cid = ms.status_cid
                 AND ms.oprtnl_flag = 'A'
                 AND SYSDATE BETWEEN ms.from_date AND ms.TO_DATE),
             DECODE (
                LENGTH (TRIM (e.social_security_nmbr)),
                NULL, 'Not Available',
                (   SUBSTR (e.social_security_nmbr, 1, 3)
                 || '-'
                 || SUBSTR (e.social_security_nmbr, 4, 2)
                 || '-'
                 || SUBSTR (e.social_security_nmbr, 6, 4)))
                AS "SSN",
             e.last_name || ',' || e.first_name || ' ' || e.middle_name,
             TO_CHAR (e.injury_date, 'MM/dd/yyyy'),
             DECODE (e.gender_lkpcd,
                 'M', 'Male',
                 'F', 'Female',
                 'U', 'Unknown'),
             e.mbr_sid,
             pr.program_cid,
             e.last_name,
             e.social_security_nmbr,
             e.first_name AS
            FROM TBL_1 c,
             program pr,
             TBL_2 e,
             TBL_3 mai,
             TBL_4 uaxou
           WHERE     c.mbr_sid = e.mbr_sid
             AND c.mbr_sid = mai.mbr_sid
             AND c.oprtnl_flag = 'A'
             AND c.idntfr_type_cid = 423
             AND TRUNC (SYSDATE) BETWEEN c.from_date AND c.TO_DATE
             AND TRUNC (SYSDATE) BETWEEN e.from_date AND e.TO_DATE
             AND e.oprtnl_flag = 'A'
             AND e.status_cid = 2
             AND mai.oprtnl_flag = 'A'
             AND mai.status_cid = 2
             AND TRUNC (SYSDATE) BETWEEN mai.from_date AND mai.TO_DATE
             AND e.program_code = pr.program_code
             AND pr.oprtnl_flag = 'A'
             AND uaxou.user_acct_sid = 1
             AND uaxou.oprtnl_flag = 'A'
             AND SYSDATE BETWEEN uaxou.from_date AND uaxou.TO_DATE
             AND uaxou.org_unit_sid = mai.org_unit_sid
        ORDER BY "Program" ASC) a
     WHERE ROWNUM < 102;

Нет данных для следующего условия

    AND uaxou.user_acct_sid = 1

Ожидаемый результат: Время ответа должно быть меньше 4 секунд, если НЕТ данных не возвращено.

Объяснить план:

Plan hash value: 2272581586

---------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                             |   101 | 22220 |  1361   (1)| 00:00:01 |
|   1 |  NESTED LOOPS                         |                             |     1 |    58 |     7   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                        |                             |     1 |    58 |     7   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TBL_5                       |     1 |    31 |     6   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | XIF1TBL_5                   |     8 |       |     3   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN                  | XPKSTATUS                   |     1 |       |     0   (0)| 00:00:01 |
|   6 |   TABLE ACCESS BY INDEX ROWID         | STATUS                      |     1 |    27 |     1   (0)| 00:00:01 |
|*  7 |  COUNT STOPKEY                        |                             |       |       |            |          |
|   8 |   VIEW                                |                             |   169 | 37180 |  1361   (1)| 00:00:01 |
|   9 |    NESTED LOOPS                       |                             |   169 | 36166 |   767   (0)| 00:00:01 |
|  10 |     NESTED LOOPS                      |                             | 11904 | 36166 |   767   (0)| 00:00:01 |
|  11 |      NESTED LOOPS                     |                             |    62 | 11284 |   333   (0)| 00:00:01 |
|  12 |       NESTED LOOPS                    |                             |    45 |  6660 |   108   (0)| 00:00:01 |
|  13 |        NESTED LOOPS                   |                             |    33 |  3564 |     9   (0)| 00:00:01 |
|* 14 |         TABLE ACCESS BY INDEX ROWID   | PROGRAM                     |     5 |    70 |     2   (0)| 00:00:01 |
|  15 |          INDEX FULL SCAN              | XAK1OWCP_PROGRAM            |     2 |       |     1   (0)| 00:00:01 |
|* 16 |         TABLE ACCESS FULL             | TBL_2                       |    20 |  1880 |     4   (0)| 00:00:01 |
|* 17 |        TABLE ACCESS BY INDEX ROWID    | TBL_1                       |     1 |    40 |     3   (0)| 00:00:01 |
|* 18 |         INDEX RANGE SCAN              | TUNE_WS_19NOV10_X2          |     1 |       |     2   (0)| 00:00:01 |
|* 19 |       TABLE ACCESS BY INDEX ROWID     | TBL_3                       |     1 |    34 |     5   (0)| 00:00:01 |
|* 20 |        INDEX RANGE SCAN               | XIE2_TBL_3                  |     3 |       |     2   (0)| 00:00:01 |
|* 21 |      INDEX RANGE SCAN                 | XIF3TBL_4                   |   192 |       |     1   (0)| 00:00:01 |
|* 22 |     TABLE ACCESS BY INDEX ROWID       | TBL_4                       |     3 |    96 |     7   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("MS"."STATUS_TYPE_CID"=7 AND "MS"."OPRTNL_FLAG"='A' AND "MS"."TO_DATE">=SYSDATE@! AND 
          "MS"."FROM_DATE"<=SYSDATE@!)
   4 - access("MBR_SID"=:B1)
   5 - access("S"."STATUS_TYPE_CID"=7 AND "S"."STATUS_CID"="MS"."STATUS_CID")
   7 - filter(ROWNUM<102)
  14 - filter("PR"."OPRTNL_FLAG"='A')
  16 - filter("E"."PROGRAM_CODE"="PR"."PROGRAM_CODE" AND "E"."OPRTNL_FLAG"='A' AND "E"."STATUS_CID"=2 AND 
          "E"."FROM_DATE"<=TRUNC(SYSDATE@!) AND TRUNC(INTERNAL_FUNCTION("FROM_DATE"))<=TRUNC(TRUNC(SYSDATE@!)) AND 
          "E"."TO_DATE">=TRUNC(SYSDATE@!) AND TRUNC(INTERNAL_FUNCTION("TO_DATE"))>=TRUNC(TRUNC(SYSDATE@!)))
  17 - filter("C"."FROM_DATE"<=TRUNC(SYSDATE@!) AND "C"."TO_DATE">=TRUNC(SYSDATE@!))
  18 - access("C"."MBR_SID"="E"."MBR_SID" AND "C"."IDNTFR_TYPE_CID"=423 AND "C"."OPRTNL_FLAG"='A')
  19 - filter("MAI"."OPRTNL_FLAG"='A' AND "MAI"."STATUS_CID"=2 AND "MAI"."FROM_DATE"<=TRUNC(SYSDATE@!) AND 
          "MAI"."TO_DATE">=TRUNC(SYSDATE@!))
  20 - access("C"."MBR_SID"="MAI"."MBR_SID")
  21 - access("UAXOU"."USER_ACCT_SID"=1)
  22 - filter("UAXOU"."ORG_UNIT_SID"="MAI"."ORG_UNIT_SID" AND "UAXOU"."OPRTNL_FLAG"='A' AND 
          "UAXOU"."FROM_DATE"<=SYSDATE@! AND "UAXOU"."TO_DATE">=SYSDATE@!)

Это вывод запроса из v $ параметра

    NAME                                |   VALUE
    compatible                          |   12.2.0
    optimizer_adaptive_plans            |   TRUE
    optimizer_adaptive_reporting_only   |   FALSE
    optimizer_features_enable           |   12.2.0.1

Это план объяснения после добавления GATHER_PLAN_STATISTICS, показывающий фактические значения мощности:

    Plan hash value: 2272581586

    -------------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                             | Name                        | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
    -------------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                      |                             |      1 |        |      0 |00:00:00.01 |       0 |
    |   1 |  NESTED LOOPS                         |                             |      0 |      1 |      0 |00:00:00.01 |       0 |
    |   2 |   NESTED LOOPS                        |                             |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TBL_5                       |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  4 |     INDEX RANGE SCAN                  | XIF1TBL_5                   |      0 |      8 |      0 |00:00:00.01 |       0 |
    |*  5 |    INDEX UNIQUE SCAN                  | XPKSTATUS                   |      0 |      1 |      0 |00:00:00.01 |       0 |
    |   6 |   TABLE ACCESS BY INDEX ROWID         | STATUS                      |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  7 |  COUNT STOPKEY                        |                             |      1 |        |      0 |00:00:00.01 |       0 |
    |   8 |   VIEW                                |                             |      1 |    169 |      0 |00:00:00.01 |       0 |
    |   9 |    NESTED LOOPS                       |                             |      1 |    169 |      0 |00:00:00.01 |       0 |
    |  10 |     NESTED LOOPS                      |                             |      1 |  11904 |      0 |00:00:00.01 |       0 |
    |  11 |      NESTED LOOPS                     |                             |      1 |     62 |      0 |00:00:00.01 |       0 |
    |  12 |       NESTED LOOPS                    |                             |      1 |     45 |      0 |00:00:00.01 |       0 |
    |  13 |        NESTED LOOPS                   |                             |      1 |     33 |      0 |00:00:00.01 |       0 |
    |* 14 |         TABLE ACCESS BY INDEX ROWID   | PROGRAM                     |      1 |      5 |      1 |00:00:00.01 |       2 |
    |  15 |          INDEX FULL SCAN              | XAK1OWCP_PROGRAM            |      1 |      2 |      2 |00:00:00.01 |       1 |
    |* 16 |         TABLE ACCESS FULL             | TBL_2                       |      1 |     20 |      0 |00:00:00.01 |       0 |
    |* 17 |        TABLE ACCESS BY INDEX ROWID    | TBL_1                   |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 18 |         INDEX RANGE SCAN              | TUNE_WS_19NOV10_X2          |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 19 |       TABLE ACCESS BY INDEX ROWID     | TBL_3                       |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 20 |        INDEX RANGE SCAN               | XIE2_TBL_3                  |      0 |      3 |      0 |00:00:00.01 |       0 |
    |* 21 |      INDEX RANGE SCAN                 | XIF3TBL_4           |      0 |    192 |      0 |00:00:00.01 |       0 |
    |* 22 |     TABLE ACCESS BY INDEX ROWID       | TBL_4                   |      0 |      3 |      0 |00:00:00.01 |       0 |
    -------------------------------------------------------------------------------------------------------------------------------

    Predicate Information (identified by operation id):
    ---------------------------------------------------

       3 - filter(("MS"."STATUS_TYPE_CID"=7 AND "MS"."OPRTNL_FLAG"='A' AND "MS"."TO_DATE">=SYSDATE@! AND 
              "MS"."FROM_DATE"<=SYSDATE@!))
       4 - access("MBR_SID"=:B1)
       5 - access("S"."STATUS_TYPE_CID"=7 AND "S"."STATUS_CID"="MS"."STATUS_CID")
       7 - filter(ROWNUM<102)
      14 - filter("PR"."OPRTNL_FLAG"='A')
      16 - filter(("E"."PROGRAM_CODE"="PR"."PROGRAM_CODE" AND "E"."OPRTNL_FLAG"='A' AND "E"."STATUS_CID"=2 AND 
              "E"."FROM_DATE"<=TRUNC(SYSDATE@!) AND "E"."TO_DATE">=TRUNC(SYSDATE@!)))
      17 - filter(("C"."FROM_DATE"<=TRUNC(SYSDATE@!) AND "C"."TO_DATE">=TRUNC(SYSDATE@!)))
      18 - access("C"."MBR_SID"="E"."MBR_SID" AND "C"."IDNTFR_TYPE_CID"=423 AND "C"."OPRTNL_FLAG"='A')
      19 - filter(("MAI"."OPRTNL_FLAG"='A' AND "MAI"."STATUS_CID"=2 AND "MAI"."FROM_DATE"<=TRUNC(SYSDATE@!) AND 
              "MAI"."TO_DATE">=TRUNC(SYSDATE@!)))
      20 - access("C"."MBR_SID"="MAI"."MBR_SID")
      21 - access("UAXOU"."USER_ACCT_SID"=1)
      22 - filter(("UAXOU"."ORG_UNIT_SID"="MAI"."ORG_UNIT_SID" AND "UAXOU"."OPRTNL_FLAG"='A' AND 
              "UAXOU"."FROM_DATE"<=SYSDATE@! AND "UAXOU"."TO_DATE">=SYSDATE@!))

Iпробовал различные подсказки USE_HASH (ce) и различные другие комбинации, ни одна не работала.

Одно интересное наблюдение, если я прокомментирую условие:

    --AND uaxou.user_acct_sid = 1

Результаты пришли через 7 секунд.(Очевидно, что данные возвращаются в этом случае).
Итак, что вызывает запрос так долго, когда данные не возвращаются?(т.е. это условие не комментируется AND uaxou.user_acct_sid = 1)

Я позволил медленному запросу завершиться, это заняло 10 минут 46 секунд.Данные не возвращаются

Вот план объяснения.Я не знаю, почему A-Time не совпадает с фактическим временем выполнения.

    Plan hash value: 2272581586

    -------------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                             | Name                        | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
    -------------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                      |                             |      1 |        |      0 |00:00:00.01 |       0 |
    |   1 |  NESTED LOOPS                         |                             |      0 |      1 |      0 |00:00:00.01 |       0 |
    |   2 |   NESTED LOOPS                        |                             |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TBL_5                       |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  4 |     INDEX RANGE SCAN                  | XIF1TBL_5                   |      0 |      8 |      0 |00:00:00.01 |       0 |
    |*  5 |    INDEX UNIQUE SCAN                  | XPKSTATUS                   |      0 |      1 |      0 |00:00:00.01 |       0 |
    |   6 |   TABLE ACCESS BY INDEX ROWID         | STATUS                      |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  7 |  COUNT STOPKEY                        |                             |      1 |        |      0 |00:00:00.01 |       0 |
    |   8 |   VIEW                                |                             |      1 |    169 |      0 |00:00:00.01 |       0 |
    |   9 |    NESTED LOOPS                       |                             |      1 |    169 |      0 |00:00:00.01 |       0 |
    |  10 |     NESTED LOOPS                      |                             |      1 |  11904 |      0 |00:00:00.01 |       0 |
    |  11 |      NESTED LOOPS                     |                             |      1 |     62 |      0 |00:00:00.01 |       0 |
    |  12 |       NESTED LOOPS                    |                             |      1 |     45 |      0 |00:00:00.01 |       0 |
    |  13 |        NESTED LOOPS                   |                             |      1 |     33 |      0 |00:00:00.01 |       0 |
    |* 14 |         TABLE ACCESS BY INDEX ROWID   | PROGRAM                     |      1 |      5 |      1 |00:00:00.01 |       2 |
    |  15 |          INDEX FULL SCAN              | XAK1OWCP_PROGRAM            |      1 |      2 |      2 |00:00:00.01 |       1 |
    |* 16 |         TABLE ACCESS FULL             | TBL_2                       |      1 |     20 |      0 |00:00:00.01 |       0 |
    |* 17 |        TABLE ACCESS BY INDEX ROWID    | TBL_1                       |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 18 |         INDEX RANGE SCAN              | TUNE_WS_19NOV10_X2          |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 19 |       TABLE ACCESS BY INDEX ROWID     | TBL_3                       |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 20 |        INDEX RANGE SCAN               | XIE2_TBL_3                  |      0 |      3 |      0 |00:00:00.01 |       0 |
    |* 21 |      INDEX RANGE SCAN                 | XIF3TBL_4                   |      0 |    192 |      0 |00:00:00.01 |       0 |
    |* 22 |     TABLE ACCESS BY INDEX ROWID       | TBL_4                       |      0 |      3 |      0 |00:00:00.01 |       0 |
    -------------------------------------------------------------------------------------------------------------------------------

    Predicate Information (identified by operation id):
    ---------------------------------------------------

       3 - filter(("MS"."STATUS_TYPE_CID"=7 AND "MS"."OPRTNL_FLAG"='A' AND "MS"."TO_DATE">=SYSDATE@! AND 
              "MS"."FROM_DATE"<=SYSDATE@!))
       4 - access("MBR_SID"=:B1)
       5 - access("S"."STATUS_TYPE_CID"=7 AND "S"."STATUS_CID"="MS"."STATUS_CID")
       7 - filter(ROWNUM<102)
      14 - filter("PR"."OPRTNL_FLAG"='A')
      16 - filter(("E"."PROGRAM_CODE"="PR"."PROGRAM_CODE" AND "E"."OPRTNL_FLAG"='A' AND "E"."STATUS_CID"=2 AND 
              "E"."FROM_DATE"<=TRUNC(SYSDATE@!) AND "E"."TO_DATE">=TRUNC(SYSDATE@!)))
      17 - filter(("C"."FROM_DATE"<=TRUNC(SYSDATE@!) AND "C"."TO_DATE">=TRUNC(SYSDATE@!)))
      18 - access("C"."MBR_SID"="E"."MBR_SID" AND "C"."IDNTFR_TYPE_CID"=423 AND "C"."OPRTNL_FLAG"='A')
      19 - filter(("MAI"."OPRTNL_FLAG"='A' AND "MAI"."STATUS_CID"=2 AND "MAI"."FROM_DATE"<=TRUNC(SYSDATE@!) AND 
              "MAI"."TO_DATE">=TRUNC(SYSDATE@!)))
      20 - access("C"."MBR_SID"="MAI"."MBR_SID")
      21 - access("UAXOU"."USER_ACCT_SID"=1)
      22 - filter(("UAXOU"."ORG_UNIT_SID"="MAI"."ORG_UNIT_SID" AND "UAXOU"."OPRTNL_FLAG"='A' AND 
              "UAXOU"."FROM_DATE"<=SYSDATE@! AND "UAXOU"."TO_DATE">=SYSDATE@!))

1 Ответ

2 голосов
/ 02 июня 2019

Адаптивные планы могут улучшить план выполнения.

Вы пометили вопрос как 12c, но похоже, что план выполнения по какой-то причине не использует адаптивные планы.Адаптивные планы позволяют Oracle изменять операции во время выполнения, такие как переключение между NESTED LOOPS и HASH JOINS.

NESTED LOOPS хороши для небольшого процента строк, а HASH JOINS хороши для большого процента строк.Поскольку все оценки ROWS малы, но запрос выполняется в течение трех минут, я думаю, что оптимизатор значительно недооценивает количество выражений и объединений и использует слишком много NESTED LOOP.

Если адаптивные планы быливключенный план выполнения должен иметь это в нижней части:

Note
-----
   - this is an adaptive plan

Поскольку это примечание отсутствует, я думаю, в вашей базе данных есть проблема с параметрами, препятствующая адаптивным планам.Запустите приведенный ниже запрос и посмотрите, отключена ли одна из функций или установлена ​​ли версия версии ниже 12:

select name, value
from v$parameter
where name in (
    'optimizer_adaptive_features', --12.1 only
    'optimizer_adaptive_plans', --12.2+
    'optimizer_adaptive_reporting_only',
    'optimizer_features_enable',
    'compatible'
    )
order by 1;

РЕДАКТИРОВАТЬ 1

Я не уверен, почему адаптивные планы не работают для вас.Если никто не может понять это, то нам нужно исследовать фактические значения плана выполнения, чтобы точно определить, какие операции выполняются медленно.

Существует как минимум два способа получить фактические числа.Если вы можете изменить и повторно запустить ошибочный запрос, вы можете использовать подсказку GATHER_PLAN_STATISTICS .

--Run slow query and wait for it to finish:
select /*+ gather_plan_statistics */ * from dual;

--Find the SQL_ID of the query using some distinctive text:
select *
from v$sql
where lower(sql_fulltext) like '%gather_plan_statistics%';

--Generate execution plan with actual values.
select *
from table(dbms_xplan.display_cursor(sql_id => 'SQL_ID from above', format=>'allstats last'));

Если вы не можете изменить запрос, вы можете использовать отчеты SQL Monitor, чтобы найтифактические значения.(Для этой функции требуется Enterprise Edition и лицензия для пакета настройки.)

--Generate SQL Monitoring Report:
select dbms_sqltune.report_sql_monitor(sql_id => 'SQL_ID from above') from dual;

EDIT 2

Вы на 100% уверены, что нашли нужноеSQL_ID?Возможно, вы захотите перепроверить GV$SQL.Иногда дело переключается, если SQL подается из приложения или блока PL / SQL.И редко реальный оператор SQL устареет GV$SQL, если кто-то запустит alter system flush shared_pool;, или будет собрана статистика, или если вы будете ждать слишком долго.

Если это действительно правильный план выполнения, нет временитратится на запрос.Обычно это означает, что время должно быть потрачено сетью, отправляющей результаты, или приложением, обрабатывающим результаты.Но так как строк не возвращено, проблема с сетью или приложением кажется маловероятной.

Если время тратится на базу данных, но не на этот запрос, то я бы предположил, что это либо проблема синтаксического анализа, либопроблема рекурсивного запроса.Проблемы с анализом могут быть обнаружены путем трассировки, но они вызваны чрезвычайно необычными проблемами или запросами, и, скорее всего, это не так.

Возможно, один из запросов, которые Oracle использует для сбора метаданных, занимает слишком много времени.Для многих запросов Oracle необходимо выполнить другие запросы, которые проверяют привилегии, динамическую выборку и т. Д. Вам может понадобиться настроить один из этих других запросов, и следующие операторы могут помочь в этом болезненном процессе:

--Clear existing run times (be careful running this on production).
--(This won't flush queries that are actively running.)
alter system flush shared_pool;

--Run your slow SQL statement here.
--...

--Now look for anything "weird" that has taken up most of the time. 
select elapsed_time/1000000 seconds, gv$sql.*
from gv$sql
order by seconds desc;
...