LAST_ANALYZE null после dbms_stats.gather_table_stats - PullRequest
1 голос
/ 09 октября 2019

У нас есть репликация с goldengate из среды prod. Первоначально таблицы выгружались из продукта, после чего мы начали репликацию с помощью goldengate. Теперь мы хотим перенести данные в другую базу данных. Но планы запросов отличаются от среды prod. Мы думаем, что это потому, что вся статистика из базы данных репликации сломана / неверна. Количество строк, указанное в dba_tables, равно нулю, 0 или отличается на 50-80%. Мы попытались сделать dbms_stats.gather_table_stats на всех соответствующих таблицах. Это все еще сломано. Мы выполняем этот запрос для всех таблиц, которые имели неверную статистику:

dbms_stats.GATHER_TABLE_STATS(OWNNAME => 'SCHEMA', TABNAME => 'TABLE_NAME', CASCADE => true);

Мы не можем мигрировать с неверными планами запросов.

Мы используем Oracle Release 12.2.0.1.0 - Производство

EDIT: После ответа @Jon Heller мы увидели, что некоторые индексы разделены в среде prod, а не в репликации. Кроме того, глобальное предпочтение DEGREE - 32768 для репликации и NULL для продукта.

1 Ответ

1 голос
/ 10 октября 2019

Таблицы построены точно так же? Возможно, другая структура таблицы приводит к сбою статистики, например, если одна таблица разбита на части, а другая - нет. Попробуйте сравнить DDL:

select dbms_metadata.get_ddl('TABLE', 'TABLE1') from dual;

Я удивлен, узнав, что статистика неверна даже после сбора статистики. Особенно количество строк - начиная с 10g, это число всегда должно быть на 100% точным с настройками по умолчанию.

Можете ли вы перечислить точные команды, которые вы используете для сбора статистики? Кроме того, это растянуто, но, возможно, глобальные предпочтения были изменены в одной базе данных. Это было бы довольно плохо, но вы можете установить базу данных по умолчанию, чтобы просматривать только 0,00001% данных, что создавало бы ужасную статистику. Проверьте свои глобальные предпочтения между обеими базами данных.

--Thanks to Tim Hall for this query: https://oracle-base.com/dba/script?category=monitoring&file=statistics_prefs.sql
SELECT DBMS_STATS.GET_PREFS('AUTOSTATS_TARGET') AS autostats_target,
       DBMS_STATS.GET_PREFS('CASCADE') AS cascade,
       DBMS_STATS.GET_PREFS('DEGREE') AS degree,
       DBMS_STATS.GET_PREFS('ESTIMATE_PERCENT') AS estimate_percent,
       DBMS_STATS.GET_PREFS('METHOD_OPT') AS method_opt,
       DBMS_STATS.GET_PREFS('NO_INVALIDATE') AS no_invalidate,
       DBMS_STATS.GET_PREFS('GRANULARITY') AS granularity,
       DBMS_STATS.GET_PREFS('PUBLISH') AS publish,
       DBMS_STATS.GET_PREFS('INCREMENTAL') AS incremental,
       DBMS_STATS.GET_PREFS('STALE_PERCENT') AS stale_percent
FROM   dual;

Если сбор статистики по-прежнему приводит к разным результатам, единственное, о чем я могу думать, это коррупция. Возможно, настало время создать запрос на обслуживание Oracle.

(Это скорее расширенный комментарий, чем ответ, но для диагностики этой проблемы может потребоваться много кода. Обновите исходный вопрос, добавив дополнительную информациюкак вы его нашли.)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...