лекция. Учебник по sql если вы хотите узнать, что такое sql этот сайт для вас
 Скачать 7.88 Mb.
|
|
Index Range Scan Выполняет обход B-дерева и просматривает цепочки конечных узлов, чтобы найти все подходящие записи. Index Full Scan Читает индекс целиком (все строки) в порядке, представленном индексом. В зависимости от различной системной статистики СУБД может выполнять эту операцию, если нужны все строки в порядке индекса, например, из-за соответствующего предложения ORDER BY. Вместо этого оптимизатор может также использовать операцию Index Fast Full Scan и выполнить дополнительную операцию сортировки. Index Fast Full Scan Читает индекс целиком (все строки) в порядке, хранящемся на диске. Эта операция обычно выполняется вместо полного сканирования таблицы, если в индексе доступны все необходимые столбцы. Подобно операции TABLE ACCESS FULL, INDEX FAST FULL SCAN может извлечь выгоду из многоблочных операций чтения. Table Access By Index ROWID Извлекает строку из таблицы, используя ROWID, полученный из предыдущего поиска по индексу. Table Access Full Полное сканирование таблицы. Читает всю таблицу (все строки и столбцы), в порядке, хранящемся на диске. Хотя многоблочные операции чтения значительно повышают скорость сканирования полной таблицы, это все еще одна из самых дорогих операций. Помимо высоких затрат времени ввода-вывода, полное сканирование таблицы должно проверять все строки таблицы, что также занимает значительное количество процессорного времени. Merge Join Соединение слиянием объединяет два отсортированных списка. Обе стороны объединения должны быть предварительно отсортированы. Nested Loops Соединение вложенными циклами объединяет две таблицы, выбирая результат из одной таблицы и запрашивая другую таблицу для каждой строки из первой. Встречается очень часто. Выполняет довольно эффективное соединение относительно небольших наборов данных. Соединение вложенными циклами не требует сортировки входных данных. Hash Join Хеш-соединение загружает записи-кандидаты с одной стороны соединения в хеш-таблицу, которая затем проверяется для каждой строки с другой стороны соединения. Операция используется всегда, когда невозможно применить другие виды соединения: если соединяемые наборы данных достаточно велики и/или наборы данных не упорядочены по столбцам соединения. Sort Unique Сортирует строки и устраняет дупликаты. Hash Unique Более эффективная реализация алгоритма сортировки и устранения дупликатов с использованием хэш- таблицы. Заменяет операцию Sort Unique в определенных обстоятельствах. Sort Aggregate Вычисляет суммарные итоги с использованием агрегатных функций SUM, COUNT, MIN, MAX, AVG и пр. Sort Order By Сортирует результат в соответствии с предложением ORDER BY. Эта операция требует больших объемов памяти для материализации промежуточного результата. Sort Group By Сортирует набор записей по столбцам GROUP BY и агрегирует отсортированный результат на втором этапе. Эта операция требует больших объемов памяти для материализации промежуточного результата. Sort Group By Nosort Агрегирует предварительно отсортированный набор записей в соответствии с предложением GROUP BY. Эта операция не буферизует промежуточный результат. Hash Group By Группирует результат, используя хеш-таблицу. Эта операция требует больших объемов памяти для материализации промежуточного набора записей. Вывод не упорядочен каким-либо значимым образом. Filter Применяет фильтр к набору строк. View Создает промежуточное представление данных. Count Stopkey Прерывает выполение операций, когда было выбрано нужное количество строк. Sort Join Сортирует набор записей в столбце соединения. Используется в сочетании с операцией Merge Join для выполнения сортировки соединением слияния. Intersection Выполняет операцию пересечения между двумя источниками. Union-All Выполняет операцию объединения всех записей между двумя таблицами. Дублирующиеся строки не удаляются. Load As Select Прямая загрузка с использованием оператора SELECT в качестве источника. Temp Table Generation/Transformation Создает/преобразует временную таблицу. Используется в специфичных для Oracle преобразованиях типа Star. Optimizer Transformations: Star Transformation Star transformation was introduced in Oracle 8i to process star queries efficiently. These queries are commonly used in data warehouse applications that follow the Star Schema data model. The Star Schema is so called because the data model diagram resembles a star. The center of the star consists of one or more fact tables and the points of the star are the dimension tables. The basic idea of this transformation is to steer clear of using a full table scan access method on large tables, referred to as fact tables in the Star Schema. In a typical star query, the fact table is joined to several much smaller dimension tables. The fact table typically contains one key (referred to as foreign key) for every dimension table as well as a number of measure columns such as sales amount. The corresponding key in the dimension table is referred to as the primary key. The join is based on a foreign key of the fact table with the corresponding primary key of the dimension table. The query also contains filter predicates on other columns of the dimension tables that typically are very restrictive. The combination of these filters help to dramatically reduce the data set processed from the fact table. The goal of star transformation is to access only this reduced set of data from the fact table. Consider the following star query Q1. The query is to find the total sales amount in all cities in California for quarters Q1 and Q2 of year 1999 through the Internet. Q1: Copy code snippet Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy SELECT c.cust_city, t.calendar_quarter_desc, SUM(s.amount_sold) sales_amount FROM sales s, times t, customers c, channels ch WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id AND s.channel_id = ch.channel_id AND c.cust_state_province = 'CA' AND ch.channel_desc = 'Internet' AND t.calendar_quarter_desc IN ('1999-01','1999-02') GROUP BY c.cust_city, t.calendar_quarter_desc; Sales is the fact table while the other tables are considered as dimension tables. The Sales table contains one row for every sale of a product and thus it may contain billions of sales records. However only a few of them are sold to customers in California through the Internet for the specified quarters. The query is transformed into Q2. Q2: Copy code snippet Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy SELECT c.cust_city, t.calendar_quarter_desc, SUM(s.amount_sold) sales_amount FROM sales s, times t, customers c WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id AND c.cust_state_province = 'CA' AND t.calendar_quarter_desc IN ('1999-01','1999-02') AND s.time_id IN (SELECT time_id FROM times WHERE calendar_quarter_desc IN('1999-01','1999-02')) AND s.cust_id IN (SELECT cust_id FROM customers WHERE cust_state_province='CA') AND s.channel_id IN (SELECT channel_id FROM channels WHERE channel_desc = 'Internet') GROUP BY c.cust_city, t.calendar_quarter_desc; Star transformation is essentially about adding subquery predicates corresponding to the constraint dimensions. These subquery predicates are referred to as bitmap semi-join predicates. The transformation is performed when there are indexes on the fact join columns (s.timeid, s.custid...). By driving bitmap AND and OR operations (bitmaps can be from bitmap indexes or generated from regular B-Tree indexes) of the key values supplied by the subqueries, only the relevant rows from the fact table need to be retrieved. If the filters on the dimension tables filter out a lot of data, this can be much more efficient than a full table scan on the fact table. After the relevant rows have been retrieved from the fact table, they may need to be joined back to the dimension tables, using the original predicates. In some cases, the join back can be eliminated. We will discuss this situation later. Table 1 shows the query plan for the transformed query. Note that the sales table has a bitmap access path instead of a full table scan. For each key value coming from the subqueries (lines 11, 16, 21), the bitmaps are retrieved from the fact table indexes (lines 12, 17, 22). Each bit in the bitmap corresponds to a row in fact table. The bit is set if the key value from the subquery is same as the value in the row of fact table. For example, the bitmap [1][0][1][0][0][0]...(all 0s for remaining rows) indicate that rows 1 and 3 of fact table has matching key value from subquery. Lets say the above bitmap is for a key value from customers table subquery. The operations in lines 9, 14, 19 iterates over the keys from the subqueries and get the corresponding bitmaps. Lets say the customers subquery produces one more key value with the bitmap [0][1][0][0][0][0]... The bitmaps for each subquery are merged (ORed) (lines 8, 13 and 18). In the above example, it will produce a single bitmap [1][1][1][0][0][0]... for customers subquery after merging the two bitmaps. The merged bitmaps are ANDed (line 7). Lets say the bitmap from channels is [1][0][0][0][0][0]... If you AND this bitmap with the bitmap from customers subquery it will produce [1][0][0][0][0]... The corresponding rowids of the final bitmap are generated (line 6). The fact table rows are retrieved using the rowids (line 5). In the above example, it will generate only 1 rowid corresponding to the first row and fetches only a single row instead of scanning the entire fact table. The representation of bitmaps in the above example is for illustration purpose only. In Oracle, they are represented and stored in a compressed form. Table 1: The plan of the transformed query... Copy code snippet Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy ------------------------------------------------------- ------- | Id | Operation | Name | ------------------------------------------------------- ------- | 0 | SELECT STATEMENT | | | 1 | HASH GROUP BY | | |* 2 | HASH JOIN | | |* 3 | TABLE ACCESS FULL | CUSTOMERS | |* 4 | HASH JOIN | | |* 5 | TABLE ACCESS FULL | TIMES | | 6 | VIEW | VW_ST_B1772830 | | 7 | NESTED LOOPS | | | 8 | PARTITION RANGE SUBQUERY | | | 9 | BITMAP CONVERSION TO ROWIDS| | | 10 | BITMAP AND | | | 11 | BITMAP MERGE | | | 12 | BITMAP KEY ITERATION | | | 13 | BUFFER SORT | | |* 14 | TABLE ACCESS FULL | CHANNELS | |* 15 | BITMAP INDEX RANGE SCAN| SALES_CHANNEL_BIX| | 16 | BITMAP MERGE | | | 17 | BITMAP KEY ITERATION | | | 18 | BUFFER SORT | | |* 19 | TABLE ACCESS FULL | TIMES | |* 20 | BITMAP INDEX RANGE SCAN| SALES_TIME_BIX | | 21 | BITMAP MERGE | | | 22 | BITMAP KEY ITERATION | | | 23 | BUFFER SORT | | |* 24 | TABLE ACCESS FULL | CUSTOMERS | |* 25 | BITMAP INDEX RANGE SCAN| SALES_CUST_BIX | | 26 | TABLE ACCESS BY USER ROWID | SALES | ------------------------------------------------------- ------- Join back elimination The subqueries and their bitmap tree only filter the fact table based on the dimension filters, so it may still be necessary to join to the dimension table. The join back of the dimension table is eliminated when all the predicates on dimension tables are part of the semijoin subquery predicate, the column(s) selected from the subquery are unique and the dimension columns are not in select list, group by etc. In the above example, the table channels is not joined back to the sales table since it is not referenced outside and channel_id is unique. Temporary table transformation If the join back is not eliminated, Oracle stores the results of the subquery in a temporary table to avoid re-scanning the dimension table (for bitmap key generation and join back). In addition to this, the results are materialized if the query is run in parallel, so that each slave can select the results from the temporary tables instead of executing the subquery again. For example, if Oracle materializes the results of the subquery on customers into a temporary table, the transformed query Q3 will be as follows. Q3: Copy code snippet Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy SELECT t1.c1 cust_city, t.calendar_quarter_desc calendar_quarter_desc, sum(s.amount_sold) sales_amount FROM sales s, sh.times t, sys_temp_0fd9d6621_e7e24 t1 WHERE s.time_id=t.time_id AND s.cust_id=t1.c0 AND (t.calendar_quarter_desc='1999-q1' OR t.calendar_quarter_desc='1999-q2') AND s.cust_id IN (SELECT t1.c0 FROM sys_temp_0fd9d6621_e7e24 t1) AND s.channel_id IN (SELECT ch.channel_id FROM channels ch WHERE ch.channel_desc='internet') AND s.time_id IN (SELECT t.time_id FROM times t WHERE t.calendar_quarter_desc='1999-q1' OR t.calendar_quarter_desc='1999-q2') GROUP BY t1.c1, t.calendar_quarter_desc; Note that customers is replaced by the temporary table sys_temp_0fd9d6621_e7e24 and references to columns cust_id and cust_city are replaced by the corresponding columns of the temporary table. The temporary table will be created with 2 columns - (c0 number, c1 varchar2(30)). These columns corresponds to cust_id and cust_city of customers table. The table will be populated using the following query Q4 at the beginning of the execution of the statement Q3. Q4: Copy code snippet Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy SELECT c.cust_id, c.cust_city FROM customers WHERE c.cust_state_province = 'CA' Table 2 shows the plan for the transformed query. Table 2: Plan with temporary table transformation... Copy code snippet Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy Copied to Clipboard Error: Could not Copy ------------------------------------------------------- --------------- | Id | Operation | Name | ------------------------------------------------------- --------------- | 0 | SELECT STATEMENT | | | 1 | TEMP TABLE TRANSFORMATION | | | 2 | LOAD AS SELECT | | |* 3 | TABLE ACCESS FULL | CUSTOMERS | | 4 | HASH GROUP BY | | |* 5 | HASH JOIN | | | 6 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6613_C716F| |* 7 | HASH JOIN | | |* 8 | TABLE ACCESS FULL | TIMES | | 9 | VIEW | VW_ST_A3F94988 | | 10 | NESTED LOOPS | | | 11 | PARTITION RANGE SUBQUERY | | | 12 | BITMAP CONVERSION TO ROWIDS| | | 13 | BITMAP AND | | | 14 | BITMAP MERGE | | | 15 | BITMAP KEY ITERATION | | | 16 | BUFFER SORT | | |* 17 | TABLE ACCESS FULL | CHANNELS | |* 18 | BITMAP INDEX RANGE SCAN| SALES_CHANNEL_BIX | | 19 | BITMAP MERGE | | | 20 | BITMAP KEY ITERATION | | | 21 | BUFFER SORT | | |* 22 | TABLE ACCESS FULL | TIMES | |* 23 | BITMAP INDEX RANGE SCAN| SALES_TIME_BIX | | 24 | BITMAP MERGE | | | 25 | BITMAP KEY ITERATION | | | 26 | BUFFER SORT | | | 27 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6613_C716F| |* 28 | BITMAP INDEX RANGE SCAN| SALES_CUST_BIX | | 29 | TABLE ACCESS BY USER ROWID | SALES | ------------------------------------------------------- --------------- The lines 1,2 and 3 of the plan materialize the customers subquery into the temporary table. In line 24, it scans the temporary table (instead of the subquery) to build the bitmap from the fact table. Line 26 is for scanning the temporary table for joining back instead of scanning customers. Note that the filter on customers is not needed to be applied on the temporary table since the filter is already applied while materializing the temporary |