Last analyzed oracle что это
We are currently running Oracle 11g and I am looking into if we need to run statistics after a large import. We have statistics_level set to 'TYPICAL'. Based on this I'm thinking that we do NOT need to update statistics:
Starting with Oracle Database 11g, the MONITORING and NOMONITORING keywords have been deprecated and statistics are collected automatically.
However, after creating my database and running my modest import (100's of thousands to millions of records in a handful of tables and the creation of a number of indexes) all of the tables affected by the import show null for last_analyzed and stale_stats using the query below.
Should I expect certain queries to have poor performance in this state?
Should I expect the statistics to eventually run and last_analyzed and stale_stats to eventually be populated (the documentation suggests that these values are updated about every three hours by default)?
It has been my experience that for moderately sized databases (tables with millions of records and less than 10's of millions of records) that mucking around with stats is not necessary and generally causes more problems than it solves. Is this generally the case?
* * * NOTES ON OUR RESOLUTION * * *
We were using this:
We switched to this:
The analyze table statement took about 1:30 minutes in one environment and about 15:00 - 20:00 minutes in the second environment.
The gather_table_stats statement took about 0:30 to 1:00 minutes in both of the two instances we were able to examine.
Our plan moving forward is to switch our analyze table statements to gather_table_stats calls.
DBA_OBJECTS
Представление DBA_OBJECTS содержит информацию обо всех объектах базы данных, включая таблицы, индексы, пакеты, процедуры, функции, измерения, материализованные представления, планы ресурсов, типы, последовательности, синонимы, триггеры, представления и разделы таблиц (оно же секционирование). Как несложно догадаться, это представления удобно, когда нужно знать общую информацию относительно любого объекта базы данных. В листинге ниже показан запрос, предназначенный для нахождения времени создания и времени последней модификации объекта (LAST_DDL_TIME). Этот тип запроса поможет идентифицировать время модификации определенного объекта, что часто используется в процессе аудита.
2 ответа
STATISTICS_LEVEL и сбор статистики таблицы / индекса - это совершенно разные вещи. STATISTICS_LEVEL влияет на сбор статистики источника строки во время выполнения команды. Таким образом, вы можете сравнивать оценки оптимизатора и фактические значения для каждого шага курсора дисплея.
Таким образом, статистика таблиц / индексов используется для оптимизации плана выполнения, а STATISTICS_LEVEL - для сбора статистики выполнения при выполнении плана выполнения, и это в основном для диагностических целей.
Если last_analyzed равно нулю, это означает, что статистика таблицы еще не собрана.
stale_stats указывает, будет ли статистика считаться свежей или устаревшей, будет ли она собрана автоматически в следующий раз или нет. Настройки по умолчанию - 10 процентов. Если вы собираете статистику таблицы, а затем вставляете / обновляете / удаляете менее 10 процентов строк, статистика считается свежей. Когда вы достигнете 10 процентов измененных строк, они станут устаревшими.
Oracle по умолчанию автоматически собирает статистику таблиц / индексов во время периода обслуживания, который автоматически настраивается при создании базы данных. Обычно администраторы баз данных перенастраивают его, если есть особые требования.
Что касается STATISTICS_LEVEL , со значением по умолчанию TYPICAL это выглядит так:
Мы не видим ничего, кроме приблизительного количества строк. Если вы установите ALTER SESSION SET statistics_level = ALL , то
Теперь мы также видим фактическое количество строк и время, затраченное на выполнение каждого шага, а также количество последовательных чтений (столбец буферов).
Также имейте в виду, что выборка статистики выполняется не для каждой строки, а по умолчанию каждые 128 строк (можно изменить с помощью недокументированного параметра _rowsource_statistics_sampfreq )
(Husqvik подробно объяснил значение столбцов и параметров, в этом ответе рассматривается только способ сбора статистики.)
Существенные изменения данных могут легко привести к серьезным проблемам с производительностью. Если таблицы будут использоваться сразу после загрузки, им немедленно понадобится хорошая статистика.
Распространенная проблема в процессах ETL - это когда таблицы переходят с одной строки на миллион строк. Оптимизатор считает, что в больших таблицах по-прежнему есть только одна строка, и использует множество соединений вложенных циклов вместо хеш-соединений. Эти алгоритмы хорошо работают в разных контекстах; без хорошей статистики Oracle не знает правильного контекста.
Важно отметить, что NULL LAST_ANALYZED - не худший сценарий. Когда статистика отсутствует, Oracle будет использовать динамическую выборку для быстрого получения оценок статистики. Наихудший случай - это когда статистическое задание выполнялось прошлой ночью, когда таблица пуста; Oracle считает, что у него хорошая статистика, хотя на самом деле это не так.
Автозадача статистики может не успевать за большими изменениями. Автозадача статистики - это однопоточный процесс с низким приоритетом. Если автоматическому процессу осталось слишком много больших таблиц, возможно, он не сможет обработать их в течение периода обслуживания.
Хорошая новость в том, что в Oracle 11g наконец-то появились хорошие настройки по умолчанию. Обычно вам не нужно возиться с параметрами. В большинстве случаев нужно следовать простому правилу: если таблица значительно изменилась, запустите это:
*: «Значимый» - это субъективное слово. Изменение обычно является значительным с точки зрения относительного размера, а не абсолютного. Добавление одного миллиона строк в таблицу имеет значение, если таблица в настоящее время имеет одну строку, но не если в таблице есть миллиард строк.
Я столкнулся с этим вопросом в интервью и понятия не имел, как на него ответить:
Есть таблица с индексом для столбца, и вы запрашиваете:
Запрос занимает слишком много времени, и вы обнаруживаете, что индекс не используется. Если вы думаете, что производительность запроса будет лучше при использовании индекса, как вы можете заставить запрос использовать индекс?
Вы можете использовать подсказки оптимизатора
select /*+ INDEX(table_name index_name) */ from table и т. Д.
Может быть множество причин , по которым индекс не используется. Даже после того, как вы укажете подсказки , есть вероятность, что оптимизатор Oracle думает иначе и решит не использовать индекс . Вам нужно пройти часть EXPLAIN PLAN и посмотреть, сколько стоит инструкция с INDEX и без INDEX.
Предполагая, что Oracle использует CBO. Чаще всего, если оптимизатор считает, что использование INDEX обходится дорого, даже если вы указываете это в подсказках, оптимизатор проигнорирует и продолжит полное сканирование таблицы. Ваше первое действие должно проверить DBA_INDEXES, чтобы узнать, когда статистика LAST_ANALYZED. Если не проанализировать, вы можете установить таблицу, индексировать для проанализировать.
В крайнем случае вы можете попробовать настроить статистику самостоятельно.
Если вы думаете, что производительность запроса будет лучше при использовании индекса, как вы можете заставить запрос использовать индекс?
Сначала вы, конечно, должны убедиться, что индекс дает лучший результат для возврата полного набора данных, верно?
Подсказка индекса является здесь ключевым моментом, но наиболее актуальный способ ее указания заключается в использовании метода именования столбцов, а не метода именования индексов. В вашем случае вы бы использовали:
В более сложных случаях вы можете .
Для column_having_index есть соответствующий индекс, и его использование действительно увеличивает производительность, но Oracle его не использовал .
Вы должны собрать статистику в своей таблице, чтобы оптимизатор увидел, что доступ к индексу может помочь. Использование прямой подсказки - не лучшая практика.
Существует несколько важных представлений словаря базы данных, которые можно использовать для нахождения детальной информации о любом из объектов базы данных, о которых говорилось в этой главе. Администраторы баз данных также интенсивно используют представления словаря данных, чтобы управлять различными объектами схемы. Здесь приводится краткий список важнейших представлений, часть из которых упоминалась выше. Полные данные о типах информации, которую можно получить от каждого из этих представлений, доступны по команде DESCRIBE (например, DESCRIBE DBA_CATALOG).
В этой статье блога будут описаны некоторые важные представления словаря данных, которые помогут управлять объектами, не хранящими данные (т.е. объектами, которые не относятся к таблицам и индексам). Ниже приведен список важнейших представлений словаря данных для просмотра объектов базы данных.
- DBA_SYNONYMS. Информация о синонимах базы данных.
- DBA_TRIGGERS. Информация о триггерах.
- DBA_SEQUENCES. Информация о созданных пользователем последовательностях.
- DBA_DB_LINKS. Информация о связях базы данных.
Как упоминалось ранее, представление DBA_OBJECTS предоставляет важную информацию обо всех перечисленных объектах, наряду с некоторыми другими типами объектов базы данных. Однако перечисленные представления содержат детальную информацию о каждом объекте, такую как исходный текст триггера, которую вы не получите из представления DBA_OBJECTS.
Управление такими объектами, как таблицы и представления, осуществляется ссылкой на представления словаря данных, наподобие DBA_TABLES и DBA_VIEWS. Существуют также отдельные представления для секционированных таблиц. Давайте рассмотрим ключевые представления словаря данных, относящиеся к таблицам и индексам.
DBA_TAB_PARTITIONS
Представление DBA_TAB_PARTITIONS подобно представлению DBA_TABLES, но содержит детальную информацию о разделах таблиц. Благодаря DBA_TAB_PARTITIONS, можно узнать имя раздела, его максимальные значения, информацию о хранении раздела,статистику по разделу, а также прочую информацию, которая доступна в представлении DBA_TABLES. В листинге ниже показан простой запрос, использующий представление DBA_TAB_PARTITIONS.
DBA_TABLES
Представление DBA_TABLES содержит информацию обо всех реляционных таблицах базы данных. Представление DBA_TABLES — основной справочник для нахождения информации о хранении, количестве строк в таблице, состоянии протоколирования, информации буферного пула и многих других деталях. Ниже приведен простой пример запроса представления DBA_TABLES:
На заметку! Представление DBA_ALL_TABLES содержит информацию обо всех объектных и реляционных таблицах в базе данных, в то время как представление DBA_TABLES ограничено только реляционными таблицами.
Представление DBA_TABLES служит для нахождения таких вещей, как включено ли сжатие и отслеживание зависимостей на уровне строки, и была ли таблица уничтожена и помещена в корзину (Recycle Bin).
DBA_EXTERNAL_TABLES
Представление DBA_EXTERNAL_TABLES показывает подробности о любой внешней таблице в базе данных, включая их тип доступа, параметры доступа и информацию о каталоге.
DBA_PART_TABLES
Представление DBA_PART_TABLES содержит информацию о типе схемы раздела и прочих параметрах хранения разделов и подразделов. Узнать тип каждого раздела каждой секционированной таблицы можно с помощью следующего запроса:
DBA_TAB_COLUMNS
Предположим, вы нужно узнать среднюю длину каждой строки таблицы или значение по умолчанию каждого столбца (если таковое есть). Представление DBA_TAB_COLUMNS — отличный способ быстро получить всю детальную информацию о столбцах таблиц схемы, как показано в листинге ниже.
DBA_MVIEWS
Представление словаря DBA_MVIEWS сообщает все о материализованных представлениях в базе данных, в том числе информацию, включено ли для них средство переписывания запросов. В листинге ниже демонстрируется использования этого представления.
DBA_INDEXES
Представление словаря DBA_INDEXES служит для того, чтобы узнать все необходимое об индексах в базе данных, включая имя индекса, его тип, таблицу и табличное пространство, к которому он относится. Определенные столбцы, наподобие BLEVEL (сообщает уровень B-дерева индекса) и DISTINCT_KEYS (количество разных значений ключа индекс), наполняются, только если собрана статистика по индексу с использованием пакета DBMS_STATS.
DBA_VIEWS
Как известно, представления — это результаты запросов к некоторым таблицам базы данных. Представление словаря данных DBA_VIEWS позволяет увидеть SQL-запросы, лежащие в основе представлений. В листинге ниже показано, как получить текст представления OS_CUSTOMERS, принадлежащего пользователю oe.
Совет. Чтобы обеспечить полное отображение текста при использовании представления DBA_VIEWS, установите большое значение переменной long (например, SET LONG 2000). В противном случае вы увидите лишь несколько первых строк определения представления.
2 Answers 2
STATISTICS_LEVEL and gathering table/index statistics are entirely different things. STATISTICS_LEVEL affect if row source statistics are gathered during command execution. So then you're able to compare the optimizer estimates and actual values for each step in display cursor.
So table/index statistics are used for execution plan optimization and STATISTICS_LEVEL for gathering execution statistics when execution plan is being executed and it's mostly for diagnostic purposes.
When last_analyzed is null it means that table statistics hasn't been gathered yet.
stale_stats says whether the stats are considered fresh or stale, or if the stats will be gathered automatically next time or not. The default settings is 10 percent. If you gather table statistics and then insert/update/delete less than 10 percent of rows the statistics is considered fresh. When you reach 10 percent of modified rows they become stale.
Oracle by default gathers table/index statistics automatically during maintenance window which is automatically configured when a database is created. It's usually reconfigured by DBAs if there are specific requirements.
Regarding the STATISTICS_LEVEL , with default value TYPICAL it looks like this:
We don't see anything more than estimated number of rows. If you set ALTER SESSION SET statistics_level = ALL then
Now we see also the actual number of rows and time taken to execute each step as well as number of consistent reads (buffers column).
Also be aware that the statistics sampling is not done with every row but by default every 128 rows (can be changed using undocumented _rowsource_statistics_sampfreq parameter)
Thanks for the help, but what is the bottom line: can I just let Oracle do it's thing in the background or do I need to worry about doing things like analyze table like in the good old days?
I added one more paragraph to the answer. There is default maintenance window configuration for newly created database so statistics will be collected periodically according the rules I described above. We usually care about statistics when we rapidly change table content which can lead to execution plan changes and sub-optimal execution plans. In most cases the periodical gathering is enough in some is much better to gather or compute statistics manually. You should know your data and requirements, Gathering statistics, especially histograms could take much time and resources for big tables.
Yes, that is exactly the issue we are looking at: "Gathering statistics, especially histograms could take much time and resources for big tables." We have some large tables and our automated process analyzes these tables after doing a "bulk" update. However, some bulk updates only include a handful of records. In these cases there is a user expectation that the upload should not take very long (I'm just inserting a few records, this shouldn't take long). When analyze is run after these small uploads it takes a long time and fails this expectation. So.
It sounds like the best solution would be to run the analyze only after large "bulk" updates. A slightly less optimal solution would be to run analyze once after our initial large upload (assuming that the data in the database at that point are representative of the larger data set.
(Husqvik thoroughly explained the meaning of the columns and parameters, this answer only addresses how to gather statistics.)
Statistics should be manually gathered after any significant * change to a table. Oracle has a great default, automatic statistics gathering processes since 11g. But even with that new system there are still at least two good reasons to manually gather statistics. The default statistics gathering auto-task is normally meant for slowly-changing OLTP tables, not fast-changing data warehouse tables.
Significant data changes can easily lead to significant performance problems. If the tables are going to be used right after they are loaded then they need good statistics immediately.
A common problem in ETL processes is when tables go from 1 row to a million rows. The optimizer thinks there is still only one row in large tables and uses lots of nested loops joins instead of hash joins. Those algorithms work well in different contexts; without good statistics Oracle does not know the correct context.
It's important to note that a NULL LAST_ANALYZED is not the worst case scenario. When there are no statistics at all, Oracle will use dynamic sampling to generate quick statistics estimates. The worst case is when the statistics job ran last night when the table is empty; Oracle thinks it has good statistics when it really doesn't.
The statistics auto-task may not be able to keep up with large changes. The statistics auto-task is a low-priority, single-threaded process. If there are too many large tables left to the automatic process it may not be able to process them during the maintenance window.
The bad news is that developers can't ignore optimizer statistics. The DBAs can't just handle it later. It might help to read some of the chapters from the manuals, such as Managing Optimizer Statistics.
The goods news is that Oracle 11g finally has nice default settings. You usually don't need to muck around with the parameters. In most cases there's a simple rule to follow: if the table changed significantly, run this:
*: "Significant" is a subjective word. A change is normally significant in terms of relative size, not absolute. Adding one million rows to a table is significant if the table currently has one row, but not if the table has a billion rows.
Hi All,
Can any one please let me know the Meaning or purpose of "LAST_ANALYZED" from the below Query.For what purpose we use that word and how it will work?
SELECT table_name,num_rows,last_analyzed FROM ALL_TABLES WHERE table_name like 'PYM%'
DBA_TAB_MODIFICATIONS
Представление DBA_TAB_MODIFICATIONS показывает все изменения DML в таблице,произошедшие с момента последнего сбора статистики по этой таблице. Вот запрос к этому представлению:
База данных не обновляет представление DBA_TAB_MODIFICATIONS в реальном времени. Следовательно, вы можете и не увидеть изменений в различных таблицах, немедленно отраженных в этом представлении.
INDEX_STATS
Представление INDEX_STATS полезно для того, чтобы узнать, насколько эффективно индекс использует свое пространство. Крупные индексы имеют тенденцию со временем становиться несбалансированными, если происходит много удалений данных таблицы (а, следовательно, и индекса). Ваша цель — не упускать из виду эти крупные индексы,чтобы сохранять их сбалансированными.
Обратите внимание, что представление INDEX_STATS наполняется, только когда таблица подвергается анализу с помощью команды ANALYZE, как показано ниже:
Запрос из листинга ниже, использующий представление INDEX_STATS, помогает определить необходимость в перестройке индекса. Чтобы определить, следует ли перестраивать индекс, в запросе необходимо сосредоточиться на перечисленных ниже столбцах представления INDEX_STATS.
Answers
If the collection of DBMS_stat Stats should fail, you can always
check LAST_ANALYZED in USER_TABLES to see what tables have
been analyzed that day. Then you can analyze to your heart's content
all tables with a LAST_ANALYZED date earlier than sysdate.
The documentation is NOT extremely helpful in this case. I would like to know the answer to this same question, and your answer is more smart alecky than useful. Thanks for nothing.
What I need to know is what does Oracle mean by "analyzed." Does that mean the last time the table was "touched" for instance, like in a transaction? The last time is was updated? Does that mean certain statistics were collected? If yes, what statistics and where is that information located?
I had the same question, because I am trying to gather statistics of the table, but row count and how long the last load of records taken, and I would rather take data already collected by Oracle than insert SQL statements everywhere. if anyone can answer the original poster with details, that would be more helpful than posting the documentation that is thorough but not descriptive.
It means statistics was collected. In older versions statistics was collected using ANALYZE statement, that's why LAST_ANALYZED. In newer versions you can still use ANALYZE but DBMS_STATS package provides much more comprehensive interface to collect stats.
952934 wrote:
The documentation is NOT extremely helpful in this case. I would like to know the answer to this same question, and your answer is more smart alecky than useful. Thanks for nothing.
What I need to know is what does Oracle mean by "analyzed." Does that mean the last time the table was "touched" for instance, like in a transaction? The last time is was updated? Does that mean certain statistics were collected? If yes, what statistics and where is that information located?
Well in fact you have a slightly different question. This is why the answer did fit perfectly to your case.
And you highjacked a thread that is more than 3 years old.
В настоящее время мы используем Oracle 11g, и я изучаю, нужно ли нам запускать статистику после большого импорта. У нас есть statistics_level, установленный на "TYPICAL". Исходя из этого, я думаю, что нам НЕ нужно обновлять статистику:
Начиная с Oracle Database 11g, ключевые слова MONITORING и NOMONITORING объявлены устаревшими, и статистика собирается автоматически.
Однако после создания моей базы данных и выполнения моего скромного импорта (от сотен тысяч до миллионов записей в нескольких таблицах и создания ряда индексов) все таблицы, затронутые импортом, показывают null для last_analyzed и stale_stats с использованием запроса ниже.
Следует ли ожидать, что в этом состоянии некоторые запросы будут иметь низкую производительность?
Должен ли я ожидать, что в конечном итоге статистика будет запущена, а last_analyzed и stale_stats в конечном итоге будут заполнены (в документации предполагается, что эти значения обновляются каждые три часа по умолчанию)?
По моему опыту, для баз данных среднего размера (таблицы с миллионами записей и менее 10 миллионов записей) возиться со статистикой не нужно и обычно вызывает больше проблем, чем решает. Это вообще так?
* * * ПРИМЕЧАНИЯ К НАШЕЙ РЕЗОЛЮЦИИ * * *
Мы использовали это:
Мы перешли на это:
Оператор таблицы анализа занял около 1:30 минут в одной среде и около 15:00 - 20:00 минут во второй среде.
Оператор gather_table_stats занял от 0:30 до 1:00 минут в обоих из двух экземпляров, которые мы смогли изучить.
Наш план в дальнейшем - переключить наши операторы анализа таблиц на вызовы gather_table_stats.
DBA_IND_COLUMNS
Представления DBA_IND_COLUMNS по структуре подобно представлению DBA_CONS_COLUMNS и содержит информацию обо всех проиндексированных столбцах каждой таблицы. Эта информация важна при настройке производительности, когда вы замечаете,что запрос использует индекс, но вы не знаете точно, на каких столбцах этот индекс определен. Запрос, приведенный в листинге ниже, показывает, что таблица имеет индексы, определенные на неверных столбцах.
Совет. Взглянув на столбец INDEX_NAME, можно легко идентифицировать составные ключи. Если одно и то же вхождение INDEX_NAME появляется больше одного раза, значит, это составной ключ; и столбцы, являющиеся его частью, показаны в столбце COLUMN_NAME. Например,INVENTORY_PK — первичный ключ таблицы INVENTORIES, определенный на двух столбцах:PRODUCT_ID и WAREHOUSE_ID. Порядок столбцов в определении составного ключа можно узнать с помощью столбца COLUMN_POSITION.
Читайте также: