ОГРОМНАЯ разница во времени выполнения запроса между оракулом 10g и 9i - PullRequest
2 голосов
/ 06 мая 2010

Я выполняю следующий запрос:

SELECT * FROM all_tab_cols c
LEFT JOIN all_varrays v ON c.owner = v.owner
    AND c.table_name = v.parent_table_name
    AND c.column_name = v.parent_table_column

На сервере 10g это занимает ~ 2 с, на 9i это занимает 819 с (13 минут)! Что на самом деле вызывает эту огромную разницу в производительности, и как я могу это исправить?

Ответы [ 2 ]

3 голосов
/ 26 июня 2010

Оказывается, по умолчанию 9i не имеет статистики по системным таблицам, а 10g + - нет. Это то, что вызывает разницу в производительности - Oracle не знает, как он должен правильно подключиться к нему.

3 голосов
/ 06 мая 2010

Одним из возможных объяснений несоответствия является статистика словаря данных. В 10g Oracle представила процедуру DBMS_STATS.GATHER_DICTIONARY_STATS () , которая собирает статистику по схемам SYS и SYSTEM (и некоторым другим). Наличие статистики в словаре данных может привести к улучшению плана выполнения для некоторых запросов к представлениям базы данных.

Даже если вы запустите DBMS_STATS.GATHER_DATABASE_STATS (), он все равно будет собирать статистику для словаря данных, если вы явно не установите для параметра gather_sys значение false.

С помощью этого запроса вы можете проверить, какие операции сбора статистики были выполнены для базы данных 10g:

SQL> select * from  DBA_OPTSTAT_OPERATIONS
  2  order by start_time asc
  3  /

OPERATION                                                        TARGET
---------------------------------------------------------------- ----------------
START_TIME
---------------------------------------------------------------------------
END_TIME
---------------------------------------------------------------------------
gather_database_stats(auto)
10-APR-10 06.00.03.953000 +01:00
10-APR-10 06.18.21.281000 +01:00

<snip/>

gather_database_stats(auto)
03-MAY-10 22.00.05.734000 +01:00
03-MAY-10 22.03.08.328000 +01:00

gather_dictionary_stats
06-MAY-10 13.48.49.839000 +01:00
06-MAY-10 13.57.42.252000 +01:00


10 rows selected.

SQL>
...