Oracle: различие в производительности между базами данных на одном сервере в 300 раз

Question

Я работаю с новой и старой базой данных на сервере Oracle 9.2.0.3.0.

Запросы к таблицам в новой базе данных примерно в 300 раз медленнее, чем идентичные запросы к таблицам в старой базе данных.

Эти базы данных очень похожи, но есть некоторые различия:

Таблица, которую я тестирую в старой, имеет один столбец CHAR (проиндексированный) и 12 столбцов NUMBER. Таблица, которую я тестирую в новой, имеет один столбец NUMBER (проиндексированный) вместо столбца CHAR, 13 столбцов NUMBER и 10 новых столбцов VARCHAR2, размер которых ограничен 40-100. Обе таблицы индексируются одинаково (кроме типа столбца затем ...)

Обе таблицы содержат около 1900000 записей. Мой запрос получает один и тот же план выполнения в обоих случаях (индекс используется, полное сканирование не выполняется) Базы данных находятся в отдельных табличных пространствах, но на одном диске. Старое табличное пространство используется примерно на 70%, а новое - на 94%, в остальном настроено идентично (насколько я вижу). Фрагментация в табличном пространстве не плохая, но хуже в старой (да!) Поскольку в новой таблице больше столбцов, она использует в три раза больше блоков, чем в старой таблице.

Есть идеи, как поступить?

Обновление 1: После выполнения запроса 10 раз на новой базе данных он уменьшился примерно в 80 раз. Улучшение! Тем не менее, еще не решена.

Обновление 2: Запросы действительно немного отличаются из-за изменения типа столбца. Сначала старый (быстрый), а затем новый (в 80-300 раз медленнее).

SELECT fhin, SUM(cost) 
FROM olddb.oldtable 
WHERE month in ('1004 ') AND fhin IN ('1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '22', '23', '24', '25', '26', '27', '28', '29', '30', '40', '99') 
GROUP BY fhin

SELECT fhin, SUM(cost) 
FROM newdb.newtable 
WHERE month IN (201004) AND fhin IN ('1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '22', '23', '24', '25', '26', '27', '28', '29', '30', '40', '99') 
GROUP BY fhin;

Пожалуйста, не спрашивайте, почему запрос выглядит так, как будто он не мой; -)

Обновление 3: Объяснение статистики по старому запросу:

execution schema (my translation to English)
----------------------------------------------------------
0      SELECT STATEMENT Optimizer=CHOOSE
1    0   SORT (GROUP BY)
2    1     TABLE ACCESS (BY INDEX ROWID) OF 'OLDTABLE'
3    2       INDEX (RANGE SCAN) OF 'OLDTABLE' (NON-UNIQUE)

Statistics
----------------------------------------------------------
      0  recursive calls
      0  db block gets
    182  consistent gets
    101  physical reads
      0  redo size
    903  bytes sent via SQL*Net to client
    398  bytes received via SQL*Net from client
      3  SQL*Net round trips to/from client
      1  sorts (memory)
      0  sorts (disk)
     28  rows processed

объяснить статистику для нового запроса:

execution schema (my translation)
----------------------------------------------------------
0      SELECT STATEMENT Optimizer=CHOOSE (Cost=36 Card=30 Bytes=360)
1    0   SORT (GROUP BY) (Cost=36 Card=30 Bytes=360)
2    1     TABLE ACCESS (BY INDEX ROWID) OF 'NEWTABLE' (Cost=11 Card=13857 Bytes=166284)
3    2       INDEX (RANGE SCAN) OF 'NEWTABLE' (NON-UNIQUE) (Cost=1 Card=22502)

Statistics
----------------------------------------------------------
      0  recursive calls
      0  db block gets
  11019  consistent gets
  11018  physical reads
      0  redo size
    906  bytes sent via SQL*Net to client
    398  bytes received via SQL*Net from client
      3  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
     28  rows processed

Полагаю, они не были такими похожими. Есть идеи?

Обновление 4: Спасибо за отличную помощь! Проблема все еще не решена, но мой клиент недоступен в течение следующих двух недель. Тогда я попробую все и вернусь сюда с дальнейшими обновлениями!

Обновление 5: Я снова на сайте! Я провел анализ фактора кластеризации, предложенный А. Мушем, и обнаружил, что:

Table   Clustering Factor   Rows    Blocks
Old     12633               1930000 12645
New     938379              1890000 39677

Я думаю, проблема в том, что у нас плохой кластерный фактор в новой базе данных. Любые идеи или ссылки о том, как это исправить?

Обновление 6: Благодаря подсказке Адама я нашел эту статью об индексах B-дерева Oracle и коэффициенте кластеризации http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth.pdf и следовал инструкциям по оптимизации коэффициента кластеризации, переупорядочив таблицу по индексированный столбец. Проблема решена!

Answer 1

Заметили ли вы, что плохой запрос в 50-100 раз превышает количество операций ввода-вывода хорошего запроса?

Fast Version I/O:
    182  consistent gets 
    101  physical reads 

Slow Version I/O
  11019  consistent gets 
  11018  physical reads 

Мне было бы очень интересно увидеть фактор кластеризации (ALL_INDEXES.CLUSTERING_FACTOR) движущего индекса (один на месяц?) Для каждой системы и сравнить его с количеством строк (COUNT(*)) и блоки (DBA_SEGMENTS.BLOCKS) из базовой таблицы.

Answer 2

Является ли fhin столбцом, который изменил тип? В этом случае в списке, по-прежнему сравнивающем значения с символами, можно объяснить проблему.

Answer 3

1. Это постоянно в 300 раз медленнее? Или в старой базе данных все было кэшировано?

2. Также вы сказали что-то, что заставляет меня задуматься.

Базы данных находятся в отдельных табличные пространства, но на том же диске.

Конечно, они находятся в разных табличных пространствах - они должны быть. Вы хотели сказать что-то еще?

3. Проводится ли сравнение, когда обе базы данных работают? Другими словами, имеет ли старая база данных такое же количество доступных ресурсов? Вы распределили всю память для старой БД и ничего не оставили для новой? Я бы выключил старую БД, увеличил память для новой и попробовал снова сравнить.

Answer 4

Если запрос идентичен, вызывает ли изменение типа столбца неявное to_char () данных индекса? Это может сильно тормозить; хотя если план выполнения говорит, что он все еще использует индекс, то это кажется маловероятным. Звучит так, будто вы делаете простой запрос к одной таблице, но если нет, то есть ли соединение из столбца indexed (number) с одним в другой таблице, которая все еще char Я бы подумал, что для изменения типа столбца потребуется, по крайней мере, некоторая настройка запроса.

Answer 5

Статистика обновлена ​​для новой базы данных?