Почему в моем выводе TKPROF есть текущие чтения блока с помощью простого оператора select?Почему в одном запросе два анализа?

Question

В приведенном ниже запросе я использовал образец схемы SH в своем запросе в Oracle.Когда я получаю вывод TKPROF для этого запроса, я вижу, что есть некоторые текущие чтения блока.Но, насколько я знаю, чтение текущего блока происходит, когда в этом блоке есть изменения.Но я не выполнял никаких обновлений или чего-то еще.Я только что выполнил этот запрос.

Итак, почему существует 28 текущих чтений блока режима?

Следующий вопрос заключается в том, что в статистике плана выполнения некоторые начальные значения равны 0. Означает ли это, что этот шаг не выполнен?Но когда я проверяю вывод автотрассировки, кажется, что эти шаги также выполняются.(Например, индекс уникального сканирования Customers_pk имеет начальное значение = 0).Так выполнен ли этот шаг?Если да, почему здесь записывается 0?

Последний вопрос: почему в одном запросе есть как жесткий, так и мягкий анализ (два анализа)?

Заранее спасибо.

select s.prod_id, p.prod_name, s.cust_id, c.cust_first_name 
from
 sh.sales s, sh.products p, sh.customers c where s.prod_id = p.prod_id and 
  s.cust_id = c.cust_id and s.amount_sold > 1500


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.03       0.03          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch      542      0.32       0.72          0       3607         28        8114
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      544      0.35       0.76          0       3607         28        8114

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
      8114       8114       8114  HASH JOIN  (cr=3607 pr=0 pw=0 time=450527 us starts=1 cost=859 size=469504 card=8384)
      8114       8114       8114   NESTED LOOPS  (cr=1643 pr=0 pw=0 time=253284 us starts=1 cost=859 size=469504 card=8384)
      8114       8114       8114    NESTED LOOPS  (cr=1643 pr=0 pw=0 time=251761 us starts=1)
      8114       8114       8114     STATISTICS COLLECTOR  (cr=1643 pr=0 pw=0 time=250365 us starts=1)
      8114       8114       8114      HASH JOIN  (cr=1643 pr=0 pw=0 time=250044 us starts=1 cost=454 size=368896 card=8384)
        72         72         72       NESTED LOOPS  (cr=8 pr=0 pw=0 time=863 us starts=1 cost=454 size=368896 card=8384)
        72         72         72        STATISTICS COLLECTOR  (cr=8 pr=0 pw=0 time=790 us starts=1)
        72         72         72         TABLE ACCESS FULL PRODUCTS (cr=8 pr=0 pw=0 time=691 us starts=1 cost=3 size=2160 card=72)
         0          0          0        PARTITION RANGE ALL PARTITION: 1 28 (cr=0 pr=0 pw=0 time=0 us starts=0 cost=451 size=1624 card=116)
         0          0          0         TABLE ACCESS BY LOCAL INDEX ROWID BATCHED SALES PARTITION: 1 28 (cr=0 pr=0 pw=0 time=0 us starts=0 cost=451 size=1624 card=116)
         0          0          0          BITMAP CONVERSION TO ROWIDS (cr=0 pr=0 pw=0 time=0 us starts=0)
         0          0          0           BITMAP INDEX SINGLE VALUE SALES_PROD_BIX PARTITION: 1 28 (cr=0 pr=0 pw=0 time=0 us starts=0)(object id 101439)
      8114       8114       8114       PARTITION RANGE ALL PARTITION: 1 28 (cr=1635 pr=0 pw=0 time=248277 us starts=1 cost=451 size=117376 card=8384)
      8114       8114       8114        TABLE ACCESS FULL SALES PARTITION: 1 28 (cr=1635 pr=0 pw=0 time=208294 us starts=28 cost=451 size=117376 card=8384)
         0          0          0     INDEX UNIQUE SCAN CUSTOMERS_PK (cr=0 pr=0 pw=0 time=0 us starts=0)(object id 101249)
         0          0          0    TABLE ACCESS BY INDEX ROWID CUSTOMERS (cr=0 pr=0 pw=0 time=0 us starts=0 cost=405 size=12 card=1)
     55500      55500      55500   TABLE ACCESS FULL CUSTOMERS (cr=1964 pr=0 pw=0 time=120870 us starts=1 cost=405 size=666000 card=55500)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PGA memory operation                           35        0.00          0.00
  Disk file operations I/O                        1        0.00          0.00
  SQL*Net message to client                     542        0.00          0.00
  SQL*Net message from client                   542       41.10         57.47
********************************************************************************

Answer 1

Обычно мы не получаем много вопросов по настройке / оптимизации, но я постараюсь ответить на это.

1. Текущий блок МОЖЕТ указывать на изменение блока (DML), но они не всегда.Они также появляются всякий раз, когда у вас есть полное сканирование, потому что заголовки сегмента должны читаться в «текущем режиме», чтобы выяснить, как сканировать таблицу .

2. Да, «пуски» 0 означают, что шаг не был выполнен.Вы заметите, что эти шаги также имеют 0 строк.Эти шаги все еще являются частью плана, потому что, если какие-либо строки действительно соответствуют этим условиям, эти шаги необходимо будет выполнить.Но в этом случае они не использовались.

3. Нет двух разборов - вы выполняете оператор только один раз, поэтому он анализируется только один раз.Вот что означает Parse count 1.Это был сложный анализ, потому что ваш первый запуск запроса всегда является сложным анализом.Вы можете увидеть это там, где написано «Отсутствует в кеше библиотеки во время разбора: 1».Он проверил, выполнялся ли этот точный запрос раньше, и не выполнялся;поэтому это сложный разбор.Если вы снова запустите точно такой же запрос, он найдет его в кэше библиотеки, и это будет мягкий анализ.