Таблица доступа к полному оракулу, что это значит
Обновлено: 04.07.2024
ДОСТУП К ТАБЛИЦЕ ПОЛНЫЙ. Это также известно как полное сканирование таблицы. Читает всю таблицу — все строки и столбцы — в том виде, в каком она хранится на диске. Хотя операции многоблочного чтения значительно повышают скорость полного сканирования таблицы, они по-прежнему остаются одной из самых дорогостоящих операций.
Кроме того, что означает полное сканирование таблицы?
Полное сканирование таблицы (также известное как последовательное сканирование) – это сканирование базы данных, при котором каждая строка таблицы считывается в последовательном (последовательном) порядке, а встречающиеся столбцы проверяются на соответствие условиям.
Также знаете, что такое план объяснения и как его использовать? План объяснения — это представление пути доступа, используемого при выполнении запроса в Oracle. Определяет оптимальный путь доступа для выполнения запроса. Оптимизатор на основе правил (RBO) использует набор эвристик для определения пути доступа.
Проще говоря, как остановить полное сканирование таблицы?
- Используйте ANALYZE TABLE имя_таблицы, чтобы обновить распределения ключей для отсканированной таблицы.
- Используйте FORCE INDEX для просканированной таблицы, чтобы сообщить MySQL, что сканирование таблицы очень затратно по сравнению с использованием данного индекса:
Что такое полное сканирование таблицы в Oracle?
Что такое полное сканирование таблицы (FTS) в Oracle. Полное сканирование таблицы (FTS) Во время полного сканирования таблицы все отформатированные блоки таблицы, находящиеся ниже верхней отметки (HWM), сканируются последовательно, и проверяется каждая строка, чтобы определить, удовлетворяет ли она условию запроса where.
В чем разница между сканированием таблицы и сканированием индекса?
Сканирование таблицы выполняется для таблицы, на которой нет индекса (куча) — оно просматривает строки в таблице, а сканирование индекса выполняется для индексированной таблицы — самого индекса.
Полный ответ -->
Что такое полное сканирование таблицы в SQL Server?
Полное сканирование таблицы. Полное сканирование таблицы происходит, когда индекс либо не используется, либо нет индекса для таблиц, используемых оператором SQL. Полное сканирование таблицы обычно возвращает данные намного медленнее, чем при использовании индекса. Чем больше таблица, тем медленнее возвращаются данные при выполнении полного сканирования таблицы.
Полный ответ -->
Что такое индексирование SQL?
Индекс – это структура на диске, связанная с таблицей или представлением, которая ускоряет извлечение строк из таблицы или представления. Эти ключи хранятся в структуре (B-дереве), которая позволяет SQL Server быстро и эффективно находить строку или строки, связанные со значениями ключа.
Полный ответ -->
Что лучше: сканирование по индексу или поиск?
Сканирование по индексу означает, что из таблицы извлекаются все строки, а поиск по индексу означает, что из таблицы извлекаются выбранные строки. INDEX SCAN: Таким образом, сканирование является эффективной стратегией, если таблица небольшая или большинство строк соответствуют предикату.
Полный ответ -->
В чем разница между сканированием и запросом в Dynamodb?
Операция запроса использует объединенный индекс хэша и диапазона и доступна только для таблиц с составным первичным ключом. Scan, с другой стороны, просматривает всю таблицу, а затем фильтрует результаты.
Полный ответ -->
Что такое сканирование таблиц и индексов в SQL Server?
Сканирование индекса или таблицы — это когда SQL Server должен сканировать данные или страницы индекса, чтобы найти соответствующие записи. Сканирование — это противоположность поиска, при котором поиск использует индекс для точного определения записей, необходимых для выполнения запроса.
Полный ответ -->
Что такое полное сканирование?
Полное сканирование выполняется по всей файловой системе. При полном сканировании VIPRE проверяет каждый файл на жестком диске, который не содержится в созданном вами исключении. Полное сканирование – это наиболее тщательный тип сканирования, но и самый медленный.
Полный ответ -->
Что такое полное сканирование индекса в Oracle?
Полное сканирование индекса — это механизм, при котором Oracle не считывает все необходимые записи из индекса, проходя по дереву от вершины до листа для строк.
Полный ответ -->
Какова стоимость плана объяснения?
COST – это конечный результат работы оптимизатора на основе затрат (CBO), цель которого – выбрать, какой из множества возможных планов следует использовать для выполнения запроса. CBO рассчитывает относительную стоимость для каждого плана, а затем выбирает план с наименьшей стоимостью.
Полный ответ -->
Что такое сбор статистики в Oracle?
Вы можете использовать этот пакет для сбора, изменения, просмотра, экспорта, импорта и удаления статистики. Вы также можете использовать этот пакет для идентификации или именования собранной статистики. Пакет DBMS_STATS может собирать статистику по индексам, таблицам, столбцам и разделам, а также статистику по всем объектам схемы в схеме или базе данных.
Полный ответ -->
Как MySQL измеряет производительность запросов?
- Скопируйте рабочую базу данных в тестовую среду.
- Настройте MySQL для записи и захвата всех запросов на подключение и запросов к рабочей базе данных.
- Смоделируйте вариант использования, который вы пытаетесь протестировать.
- Отключите ведение журнала запросов.
Полный ответ -->
Что такое хэш-соединение в объяснении Plan Oracle?
Хэш-соединение — это операция, при которой выполняется полное сканирование меньшей из двух таблиц (ведущая таблица), а затем создается хеш-таблица в оперативной памяти. Затем хеш-таблица используется для извлечения строк в большей таблице.
Полный ответ -->
Как повысить производительность запросов Oracle?
- Индексировать все предикаты в предложениях JOIN, WHERE, ORDER BY и GROUP BY.
- Избегайте использования функций в предикатах.
- Не используйте подстановочный знак (%) в начале предиката.
- Избегайте ненужных столбцов в предложении SELECT.
- По возможности используйте внутреннее соединение вместо внешнего.
Полный ответ -->
Что такое план объяснения в Oracle?
Понимание EXPLAIN PLAN. Оператор EXPLAIN PLAN отображает планы выполнения, выбранные оптимизатором Oracle для операторов SELECT, UPDATE, INSERT и DELETE. План выполнения оператора — это последовательность операций, которые Oracle выполняет для запуска оператора. Исходное дерево строк является ядром плана выполнения.
Полный ответ -->
Что такое сканирование с пропуском индекса?
Сканирование с пропуском индекса — это новый план выполнения в Oracle 10g, при котором запрос Oracle может обходить передний край составного индекса и получать доступ к внутренним ключам индекса с несколькими значениями.
Полный ответ -->
Что такое фильтр и доступ в плане объяснения?
В чем разница между предикатами Access и Filter в плане выполнения Oracle? Если я правильно понимаю, "доступ" используется для определения того, какие блоки данных нужно прочитать, а "фильтр" применяется после того, как блоки будут прочитаны. Следовательно, фильтрация — это «зло».
Полный ответ -->
Что такое план объяснения буферной сортировки?
Буферная сортировка использует механизм буферизации традиционной сортировки, но сама сортировка не выполняется. Система просто буферизует данные в UGA или PGA, чтобы избежать многократного сканирования таблицы с реальными блоками данных. Если в sql-запросе есть подзапрос, то результат подзапроса будет помещен в буфер PGA с использованием буферной сортировки.
Мой личный самый любимый ресурс по операциям с планом выполнения — это список Джулиана Дайка, однако он представлен с другой точки зрения.
Доступ к индексу и таблице
ИНДЕКС УНИКАЛЬНОГО СКАНИРОВАНИЯ
Индекс UNIQUE SCAN выполняет только обход B-дерева. База данных использует эту операцию, если ограничение уникальности гарантирует, что критерии поиска будут соответствовать не более чем одной записи. См. также главу 1, «Структура индекса SQL».
СКАНИРОВАНИЕ ИНДЕКСНОГО ДИАПАЗОНА
ПРОВЕРКА ИНДЕКСНОГО ДИАПАЗОНА выполняет обход B-дерева и отслеживает цепочку конечных узлов, чтобы найти все совпадающие записи. См. также главу 1, «Структура индекса SQL».
Так называемые предикаты индексного фильтра часто вызывают проблемы с производительностью для INDEX RANGE SCAN. В следующем разделе объясняется, как их идентифицировать.
ИНДЕКС ПОЛНОЕ СКАНИРОВАНИЕ
Читает весь индекс — все строки — в порядке индекса. В зависимости от различных системных статистических данных база данных может выполнять эту операцию, если ей нужны все строки в индексном порядке, например, из-за соответствующего предложения order by. Вместо этого оптимизатор может также использовать INDEX FAST FULL SCAN и выполнять дополнительную операцию сортировки. См. главу 6, "Сортировка и группировка".
ИНДЕКС БЫСТРОЕ ПОЛНОЕ СКАНИРОВАНИЕ
Читает весь индекс — все строки — в том виде, в каком он хранится на диске. Эта операция обычно выполняется вместо полного сканирования таблицы, если в индексе доступны все необходимые столбцы. Подобно TABLE ACCESS FULL, INDEX FAST FULL SCAN может извлечь выгоду из операций многоблочного чтения. См. главу 5, "Кластеризация данных".
ДОСТУП К ТАБЛИЦЕ ПО ИНДЕКСУ ROWID
Извлекает строку из таблицы, используя ROWID, полученный в результате предыдущего поиска по индексу. См. также главу 1, «Структура индекса SQL».
ДОСТУП К ТАБЛИЦЕ ПОЛНЫЙ
Это также называется полным сканированием таблицы. Читает всю таблицу — все строки и столбцы — в том виде, в каком она хранится на диске. Хотя операции многоблочного чтения значительно повышают скорость полного сканирования таблицы, они по-прежнему остаются одной из самых дорогостоящих операций. Помимо высокой скорости ввода-вывода, полное сканирование таблицы должно проверять все строки таблицы, поэтому оно также может потреблять значительное количество процессорного времени. См. также «Полное сканирование таблицы».
От своего имени
Присоединяется
Обычно операции соединения обрабатывают одновременно только две таблицы. Если в запросе больше соединений, они выполняются последовательно: сначала две таблицы, затем промежуточный результат со следующей таблицей. Таким образом, в контексте соединений термин "таблица" может также означать "промежуточный результат".
ВЛОЖЕННЫЕ ЦИКЛЫ СОЕДИНЯЮТСЯ
Объединяет две таблицы, извлекая результат из одной таблицы и запрашивая в другой таблице каждую строку из первой. См. также «Вложенные циклы».
Хэш-соединение загружает записи-кандидаты с одной стороны соединения в хэш-таблицу, которая затем проверяется на наличие каждой строки с другой стороны соединения. См. также «Хэш-соединение».
Объединение слиянием объединяет два отсортированных списка наподобие застежки-молнии. Обе стороны соединения должны быть предварительно отсортированы. См. также «Сортировка слияния».
Сортировка и группировка
Сортирует результат в порядке следования предложений. Эта операция требует больших объемов памяти для материализации промежуточного результата (не конвейерного). См. также «Порядок индексации».
СОРТИРОВАТЬ ПО STOPKEY
Сортирует подмножество результата в соответствии с предложением order by. Используется для первых N запросов, если конвейерное выполнение невозможно. См. также «Запрос первых N строк».
Сортирует набор результатов в группе по столбцам и объединяет отсортированные результаты на втором этапе. Эта операция требует больших объемов памяти для материализации промежуточного набора результатов (не конвейерного). См. также «Индексирование группы по».
ГРУППА СОРТИРОВКИ ПО NOSORT
Агрегирует предварительно отсортированный набор в соответствии с предложением group by. Эта операция не буферизует промежуточный результат: она выполняется конвейерным образом. См. также «Индексирование группы по».
Группирует результат с помощью хеш-таблицы. Эта операция требует больших объемов памяти для материализации промежуточного набора результатов (не конвейерного). Вывод не упорядочен каким-либо осмысленным образом. См. также «Индексирование группы по».
Топ-N запросов
Эффективность запросов top-N зависит от режима выполнения базовых операций. Они очень неэффективны при прерывании неконвейерных операций, таких как SORT ORDER BY .
Прекращает базовые операции, когда нужное количество строк было выбрано. См. также «Запрос первых N строк».
ОКНО NOSORT STOPKEY
Использует оконную функцию (предложение over), чтобы прервать выполнение, когда было выбрано нужное количество строк. См. также «Использование оконных функций для эффективного разбиения на страницы».
Об авторе
Маркус Винанд — представитель SQL Renaissance. Его миссия — познакомить разработчиков с эволюцией SQL в 21 веке. Маркуса можно нанять в качестве тренера, спикера и консультанта через winand.at.
Купить его книгу на Amazon
Суть настройки SQL на 200 страницах
Мягкая обложка и PDF также доступны в магазине Маркуса.
Нанять Маркуса
этот запрос показывает полный доступ к таблице при проверке с помощью плана объяснения??
--------------------------------- -------------------------------------------------- -
| Идентификатор | Операция | Имя | Ряды | Байты | Стоимость |
------------------------------------------------------------ -------------------------------------------------- --
| 0 | ВЫБЕРИТЕ ЗАЯВЛЕНИЕ | | 6306 | 911К| 86423 |
| 1 | ХЭШ ГРУППА | | 6306 | 911К| 86423 |
| 2 | ВЛОЖЕННЫЕ ЦИКЛЫ АНТИ | | 6306 | 911К| 86210 |
| 3 | ВЛОЖЕННЫЕ ЦИКЛЫ | | 6306 | 621К| 71330 |
| 4 | ВЛОЖЕННЫЕ ЦИКЛЫ | | 12631 | 1147К| 45957 |
| 5 | ВЛОЖЕННЫЕ ЦИКЛЫ | | 12631 | 925К| 20573 |
| 6 | ХЭШ-СОЕДИНЕНИЕ | | 4975 | 276К| 6377 |
| 7 | ДОСТУП К ТАБЛИЦАМ ПО ИНДЕКСУ ROWID| AP_INVOICES_ALL | 4975 | 218К| 4835 |
| 8 | ИНДЕКС ДИАПАЗОН СКАН | AP_INVOICES_N3 | 81850 | | 275 |
| 9 | ДОСТУП К СТОЛУ ПОЛНЫЙ | ПОСТАВЩИКИ | 106К| 1244К| 1535 |
| 10 | ДОСТУП К ТАБЛИЦАМ ПО INDEX ROWID | AP_INVOICE_DISTRIBUTIONS_ALL | 3 | 54 | 5 |
| 11 | ИНДЕКС ДИАПАЗОН СКАН | AP_INVOICE_DISTRIBUTIONS_U1 | 9 | | 2 |
| 12 | ДОСТУП К ТАБЛИЦАМ ПО INDEX ROWID | PO_DISTRIBUTIONS_ALL | 1 | 18 | 2 |
| 13 | ИНДЕКС УНИКАЛЬНОЕ СКАНИРОВАНИЕ | PO_DISTRIBUTIONS_U1 | 1 | | 1 |
| 14 | ДОСТУП К ТАБЛИЦАМ ПО INDEX ROWID | PO_LINE_LOCATIONS_ALL | 1 | 8 | 2 |
| 15 | ИНДЕКС УНИКАЛЬНОЕ СКАНИРОВАНИЕ | PO_LINE_LOCATIONS_U1 | 1 | | 1 |
| 16 | ДОСТУП К ТАБЛИЦАМ ПО INDEX ROWID | AP_HOLDS_ALL | 1 | 47 | 4 |
vendor_id имеет уникальный индекс в таблице po_vendors, и я использовал его для условия соединения.
почему я получаю полный доступ к таблице и как этого избежать?
Ответы
Да, таблица PO_VENDORS имеет индекс
СОЗДАТЬ УНИКАЛЬНЫЙ ИНДЕКС PO_VENDORS_U1 НА PO_VENDORS
(VENDOR_ID)
СОЗДАТЬ УНИКАЛЬНЫЙ ИНДЕКС PO_VENDORS_U2 НА PO_VENDORS
(VENDOR_NAME)
Это два уникальных индекса в таблице po_vendors.
Для начала я вижу NOT EXISTS в вашем операторе select. Это вызовет полное сканирование таблицы, потому что оно должно проверять каждую запись, чтобы убедиться, что вещь, которую вы ищете, не существует, в отличие от того, когда вы используете EXISTS, который может остановиться, когда он находит первое совпадение.
Обратите внимание: полное сканирование таблицы не всегда плохо.Это может зависеть от кардинальности, избирательности и перекоса ваших данных, а также от того, какие у вас есть индексы. Если оракул решит, что будет быстрее прочитать все блоки данных, чем прочитать индекс и вернуться к основной таблице, тогда он предпочтет полное сканирование таблицы. Как только вы выберете более X% данных вашей таблицы, Oracle, скорее всего, будет использовать FTS, а не индекс (также в зависимости от других факторов).
Спасибо за информацию.
Однако это проблема производительности.
Я изменил запрос, избегая NVL в запросе и работая около 15 минут. (ожидается, что оно уменьшится примерно до 1 минуты)
Не могли бы вы посоветовать мне какие-нибудь советы по сокращению времени его выполнения.
На самом деле, просто добавьте индекс для vendor_type_lookup_code, потому что.
то же самое, что
поэтому вы можете избавиться от операторов NVL в предложениях where, где это похоже на это.
Чтобы обойти NOT EXIST, вы можете выполнить ВНЕШНЕЕ СОЕДИНЕНИЕ с таблицей, а затем выбрать только те строки из этой таблицы, которые имеют значение NULL.
(Я использовал синтаксис ANSI, поскольку он упрощает реализацию и чтение внешнего соединения.)
Хорошо.
Это стандартная таблица.
У меня нет прав для создания индекса.
Пожалуйста, еще одно сомнение, если я вообще создам индекс, как это было предложено.
Это может сработать для текущего запроса, есть ли какие-либо возможности, которые влияют на другие запросы, использующие ту же таблицу.
Возможно, это может повлиять и на форму, использующую эту таблицу. У меня нет четкого представления, это только мысль.
Не могли бы вы объяснить это?
--------------------------------- -------------------------------------------------- -
| Идентификатор | Операция | Имя | Ряды | Байты | Стоимость |
------------------------------------------------------------ -------------------------------------------------- --
| 0 | ВЫБЕРИТЕ ЗАЯВЛЕНИЕ | | 6306 | 911К| 86422 |
| 1 | ХЭШ ГРУППА | | 6306 | 911К| 86422 |
| 2 | ВЛОЖЕННЫЕ ЦИКЛЫ АНТИ | | 6306 | 911К| 86209 |
| 3 | ВЛОЖЕННЫЕ ЦИКЛЫ | | 6306 | 621К| 71329 |
| 4 | ВЛОЖЕННЫЕ ЦИКЛЫ | | 12631 | 1147К| 45956 |
| 5 | ВЛОЖЕННЫЕ ЦИКЛЫ | | 12631 | 925К| 20572 |
| 6 | ХЭШ-СОЕДИНЕНИЕ | | 4975 | 276К| 6376 |
| 7 | ДОСТУП К ТАБЛИЦАМ ПО ИНДЕКСУ ROWID| AP_INVOICES_ALL | 4975 | 218К| 4835 |
| 8 | ИНДЕКС ДИАПАЗОН СКАН | AP_INVOICES_N3 | 81850 | | 275 |
| 9 | ДОСТУП К СТОЛУ ПОЛНЫЙ | ПОСТАВЩИКИ | 106К| 1244К| 1534 |
| 10 | ДОСТУП К ТАБЛИЦАМ ПО INDEX ROWID | AP_INVOICE_DISTRIBUTIONS_ALL | 3 | 54 | 5 |
| 11 | ИНДЕКС ДИАПАЗОН СКАН | AP_INVOICE_DISTRIBUTIONS_U1 | 9 | | 2 |
| 12 | ДОСТУП К ТАБЛИЦАМ ПО INDEX ROWID | PO_DISTRIBUTIONS_ALL | 1 | 18 | 2 |
| 13 | ИНДЕКС УНИКАЛЬНОЕ СКАНИРОВАНИЕ | PO_DISTRIBUTIONS_U1 | 1 | | 1 |
| 14 | ДОСТУП К ТАБЛИЦАМ ПО INDEX ROWID | PO_LINE_LOCATIONS_ALL | 1 | 8 | 2 |
| 15 | ИНДЕКС УНИКАЛЬНОЕ СКАНИРОВАНИЕ | PO_LINE_LOCATIONS_U1 | 1 | | 1 |
| 16 | ДОСТУП К ТАБЛИЦАМ ПО INDEX ROWID | AP_HOLDS_ALL | 1 | 47 | 4 |
Путь доступа — это метод, используемый запросом для извлечения строк из источника строк.
Эта глава содержит следующие темы:
Введение в пути доступа
Источник строк — это набор строк, возвращаемых шагом плана выполнения. Источником строк может быть таблица, представление или результат операции объединения или группировки.
Унарная операция, такая как путь доступа , которая представляет собой метод, используемый запросом для извлечения строк из источника строк, принимает в качестве входных данных один источник строк. Например, полное сканирование таблицы — это извлечение строк из одного источника строк. Напротив, операция соединения является двоичной и получает входные данные из двух источников строк
База данных использует разные пути доступа для разных реляционных структур данных. В следующей таблице приведены общие пути доступа к основным структурам данных.
Сканирование диапазона растровых индексов
Оптимизатор рассматривает различные возможные планы выполнения, а затем назначает каждому плану стоимость . Оптимизатор выбирает план с наименьшей стоимостью. Как правило, пути доступа к индексу более эффективны для операторов, которые извлекают небольшое подмножество строк таблицы, тогда как полное сканирование таблицы более эффективно при доступе к большой части таблицы.
Oracle Database Concepts для обзора этих структур
Пути доступа к таблице
Таблица — это основная единица организации данных в базе данных Oracle.
Реляционные таблицы являются наиболее распространенным типом таблиц. Реляционные таблицы имеют следующие организационные характеристики:
Таблица, организованная в виде кучи, не хранит строки в каком-либо определенном порядке.
В индексно-организованной таблице строки упорядочиваются в соответствии со значениями первичного ключа.
Внешняя таблица — это таблица, доступная только для чтения, метаданные которой хранятся в базе данных, а данные хранятся вне базы данных.
В этом разделе объясняются пути доступа оптимизатора к таблицам, организованным в куче, и он содержит следующие темы:
Oracle Database Concepts для обзора таблиц
О доступе к таблицам, организованным в куче
По умолчанию таблица организована в виде кучи, что означает, что база данных размещает строки там, где они лучше всего подходят, а не в порядке, указанном пользователем.
Когда пользователи добавляют строки, база данных помещает строки в первое доступное свободное место в сегменте данных. Не гарантируется получение строк в том порядке, в котором они были вставлены.
Хранение строк в блоках данных и сегментах: введение
База данных хранит строки в блоках данных. В таблицах база данных может записать строку в любом месте нижней части блока. База данных Oracle использует служебные данные блока, которые содержат каталог строк и каталог таблицы, для управления самим блоком.
Экстент состоит из логически смежных блоков данных. Блоки могут быть физически не смежными на диске. Сегмент — это набор экстентов, который содержит все данные для логической структуры хранения в пределах табличного пространства. Например, Oracle Database выделяет один или несколько экстентов для формирования сегмента данных для таблицы. База данных также выделяет один или несколько экстентов для формирования сегмента индекса для таблицы.
По умолчанию база данных использует автоматическое управление пространством сегментов (ASSM) для постоянных табличных пространств, управляемых локально. Когда сеанс впервые вставляет данные в таблицу, база данных форматирует блок растрового изображения. Битовая карта отслеживает блоки в сегменте. База данных использует растровое изображение для поиска свободных блоков, а затем форматирует каждый блок перед записью в него. ASSM распределяет вставки по блокам, чтобы избежать проблем с параллелизмом.
Верхняя отметка (HWM) — это точка в сегменте, после которой блоки данных не форматируются и никогда не использовались. Ниже HWM блок может быть отформатирован и записан, отформатирован и пуст или не отформатирован. Нижняя верхняя отметка (низкий HWM) отмечает точку, ниже которой известно, что все блоки отформатированы, поскольку они либо содержат данные, либо ранее содержали данные.
Во время полного сканирования таблицы база данных считывает все блоки до младшего HWM, которые, как известно, отформатированы, а затем считывает растровое изображение сегмента, чтобы определить, какие блоки между HWM и младшим HWM отформатированы и безопасны для чтения. База данных знает, что нельзя читать дальше HWM, потому что эти блоки не отформатированы.
Понятия Oracle Database, чтобы узнать о хранении блоков данных
Важность Rowids для доступа к строкам
Каждая строка в таблице, организованной в куче, имеет уникальный для этой таблицы идентификатор строки, который соответствует физическому адресу части строки. Идентификатор строки — это 10-байтовый физический адрес строки.
Идентификатор строки указывает на конкретный файл, блок и номер строки. Например, в rowid AAAPecAAFAAAABSAAA последний AAA представляет номер строки. Номер строки является индексом записи каталога строк. Запись каталога строк содержит указатель на расположение строки в блоке.
Иногда база данных может переместить строку в нижней части блока. Например, если перемещение строк включено, то строка может перемещаться из-за обновлений ключа раздела, операций Flashback Table, операций сжатия таблицы и т. д. Если база данных перемещает строку внутри блока, она обновляет запись каталога строк, чтобы изменить указатель. Идентификатор строки остается постоянным.
База данных Oracle использует идентификаторы строк для построения индексов. Например, каждый ключ в индексе B-дерева связан с идентификатором строки, который указывает на адрес связанной строки. Физические идентификаторы строк обеспечивают максимально быстрый доступ к строке таблицы, позволяя базе данных извлекать строку всего за один ввод-вывод.
Чтение прямого пути
При чтении по прямому пути база данных считывает буферы с диска непосредственно в PGA, полностью минуя SGA.
На следующем рисунке показана разница между разрозненным и последовательным чтением, при котором буферы хранятся в SGA, и чтением по прямому пути.
Ситуации, в которых Oracle Database может выполнять чтение по прямому пути, включают:
Выполнение инструкции CREATE TABLE AS SELECT
Выполнение оператора ALTER REBUILD или ALTER MOVE
Чтение из временного табличного пространства
Чтение из LOB-сегмента
Руководство по настройке производительности базы данных Oracle, чтобы узнать о событиях ожидания для чтения по прямому пути
Полное сканирование таблицы
При полном сканировании таблицы считываются все строки из таблицы, а затем отфильтровываются те строки, которые не соответствуют критериям выбора.
Когда оптимизатор рассматривает полное сканирование таблицы
Как правило, оптимизатор выбирает полное сканирование таблицы, когда он не может использовать другой путь доступа или другой доступный путь доступа требует больших затрат.
В следующей таблице показаны типичные причины выбора полного сканирования таблицы.
Индекс не существует.
Если индекса нет, оптимизатор использует полное сканирование таблицы.
Предикат запроса применяет функцию к индексированному столбцу.
Если индекс не является индексом на основе функции, база данных индексирует значения столбца, а не значения столбца с примененной функцией. Типичной ошибкой на уровне приложения является индексация символьного столбца, такого как char_col , а затем запрос столбца с использованием синтаксиса, такого как WHERE char_col=1 . База данных неявно применяет функцию TO_NUMBER к константе с номером 1, что предотвращает использование индекса.
Отправлен запрос SELECT COUNT(*), и индекс существует, но индексированный столбец содержит пустые значения.
Оптимизатор не может использовать индекс для подсчета количества строк таблицы, поскольку индекс не может содержать нулевые записи.
Предикат запроса не использует передний край индекса B-дерева.
Например, индекс может существовать для сотрудников(имя,фамилия) . Если пользователь выдает запрос с предикатом WHERE last_name='KING' , оптимизатор может не выбрать индекс, поскольку столбец first_name не входит в предикат. Однако в этой ситуации оптимизатор может выбрать сканирование с пропуском индекса.
Если оптимизатор определяет, что для запроса требуется большая часть блоков в таблице, он использует полное сканирование таблицы, даже если доступны индексы. Полное сканирование таблицы может использовать более крупные вызовы ввода-вывода. Делать меньше крупных вызовов ввода-вывода дешевле, чем делать много мелких вызовов.
Статистика таблицы устарела.
Например, стол был маленьким, а теперь стал большим. Если статистика таблицы устарела и не отражает текущий размер таблицы, оптимизатор не знает, что индекс теперь более эффективен, чем полное сканирование таблицы.
Таблица маленькая.
Если таблица содержит менее n блоков под высшей точкой, где n равно значению параметра инициализации DB_FILE_MULTIBLOCK_READ_COUNT, полное сканирование таблицы может быть дешевле, чем сканирование диапазона индекса. Сканирование может быть менее затратным независимо от доли таблиц, к которым осуществляется доступ, или имеющихся индексов.
Таблица имеет высокую степень параллелизма.
Высокая степень параллелизма для таблицы склоняет оптимизатор к полному сканированию таблицы, а не к сканированию диапазона. Запросите значение в столбце ALL_TABLES.DEGREE, чтобы определить степень параллелизма.
Запрос использует подсказку полного сканирования таблицы.
Подсказка FULL( псевдоним таблицы ) указывает оптимизатору использовать полное сканирование таблицы.
Как работает полное сканирование таблицы
При полном сканировании таблицы база данных последовательно считывает каждый отформатированный блок ниже верхней отметки. База данных считывает каждый блок только один раз.
На следующем рисунке показано сканирование сегмента таблицы, показывающее, как сканирование пропускает неформатированные блоки ниже верхней отметки.
Поскольку блоки являются смежными, база данных может ускорить сканирование, сделав вызовы ввода-вывода больше одного блока, что называется многоблочным чтением. Размер вызова чтения варьируется от одного блока до числа блоков, указанного параметром инициализации DB_FILE_MULTIBLOCK_READ_COUNT. Например, если задать для этого параметра значение 4, база данных будет читать до 4 блоков за один вызов.
Алгоритмы кэширования блоков во время полного сканирования таблицы сложны. Например, база данных кэширует блоки по-разному в зависимости от размера таблиц.
Oracle Database Concepts для обзора режима кэширования по умолчанию
Справочник по базе данных Oracle, чтобы узнать о параметре инициализации DB_FILE_MULTIBLOCK_READ_COUNT
Полное сканирование таблицы: пример
Следующий оператор запрашивает зарплаты более 4000 в таблице hr.employees:
Следующий план был получен с помощью функции DBMS_XPLAN.DISPLAY_CURSOR. Поскольку в столбце зарплаты нет индекса, оптимизатор не может использовать сканирование диапазона индекса и использует полное сканирование таблицы.
Доступ к таблице через Rowid
Идентификатор строки — это внутреннее представление места хранения данных.
Идентификатор строки указывает файл данных и блок данных, содержащий строку, и расположение строки в этом блоке. Поиск строки по ее идентификатору строки – это самый быстрый способ получить отдельную строку, поскольку он указывает точное местоположение строки в базе данных.
Rowids могут меняться между версиями. Доступ к данным на основе положения не рекомендуется, поскольку строки могут перемещаться.
Когда оптимизатор выбирает доступ к таблице через Rowid
В большинстве случаев база данных обращается к таблице по идентификатору строки после сканирования одного или нескольких индексов. Однако доступ к таблице по rowid не обязательно должен следовать за каждым сканированием индекса. Если индекс содержит все необходимые столбцы, то доступ по rowid может не произойти (см. «Быстрое полное сканирование индекса»).
Как работает доступ к таблицам с помощью Rowid
Чтобы получить доступ к таблице по идентификатору строки, база данных выполняет следующие действия:
Получает идентификаторы выбранных строк либо из предложения WHERE оператора, либо путем сканирования одного или нескольких индексов
Доступ к таблице может потребоваться для столбцов в операторе, отсутствующих в индексе.
Находит каждую выбранную строку в таблице по ее идентификатору строки
Доступ к таблице через Rowid: пример
Предположим, выполните следующий запрос:
Шаг 2 следующего плана показывает сканирование диапазона индекса emp_emp_id_pk в таблице hr.employees. База данных использует идентификаторы строк, полученные из индекса, для поиска соответствующих строк в таблице сотрудников, а затем извлекает их. ПАКЕТНЫЙ доступ, показанный на шаге 1, означает, что база данных извлекает несколько идентификаторов строк из индекса, а затем пытается получить доступ к строкам в порядке блоков, чтобы улучшить кластеризацию и сократить количество раз, которое база данных должна обращаться к блоку.
Образцы сканирования таблицы
При сканировании выборочной таблицы извлекается случайная выборка данных из простой таблицы или сложного оператора SELECT, например оператора, включающего объединения и представления.
Когда оптимизатор выбирает образец сканирования таблицы
База данных использует образец сканирования таблицы, когда предложение FROM включает ключевое слово SAMPLE.
Предложение SAMPLE имеет следующие формы:
База данных считывает указанный процент строк в таблице для выполнения выборочного сканирования таблицы.
ОБРАЗЕЦ БЛОКА ( sample_percent )
База данных считывает указанный процент блоков таблицы для выполнения выборочного сканирования таблицы.
В поле sample_percent указывается процент от общего числа строк или блоков, который необходимо включить в выборку. Значение должно быть в диапазоне от 0,000001 до 100, но не включая его. Этот процент указывает вероятность того, что каждая строка или каждый кластер строк в блочной выборке будут выбраны для выборки. Это не означает, что база данных извлекает точное значение sample_percent строк.
Блочная выборка возможна только во время полного сканирования таблицы или быстрого полного сканирования индекса. Если существует более эффективный путь выполнения, то база данных не производит выборку блоков. Чтобы гарантировать блочную выборку для конкретной таблицы или индекса, используйте подсказку FULL или INDEX_FFS.
Читайте также: