Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Melkomyagkii_newbi
wurdu,

А я что-то не совсем понял как block gets связан с реду вектором. Можешь прояснить? Зачем блок еще раз доставать, если к нему же можно и в памяти другие векторы применить?
redo change vector меняет один блок. Если нам повезло, то несколько изменений скомбинировались в один вектор, мы взяли буфер, наложили на него эксклюзивный pin, модифицировали, отпустили. Если мы будем долго держать pin рассчитывая на то, что нам потребуется еще применять другие векторы к тому же буферу, то никто не сможет работать с этим буфером, т.к. будут висеть на buffer busy. Поэтому нам надо его отпустить побыстрее.
26 фев 15, 07:20    [17313360]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Lunaire
В вашем тесткейсе в первом случае выполняется вставка строк, фактически отсортированных по индексированной колонке:
...
Не удивительно, что вставка прошла быстрее, чем при случайной вставке из второго случая.
...
В таком случае все было-бы понятно: при вставке возрастающих значений обслуживание индекса дешевле.
Дело в том, что тут вопрос гораздо более сложный, чем вставка возрастающих значений. "обслуживание индекса дешевле" это слишком абстрактная фраза и она никак не описывает того, что происходит с redo. Вот тот же тест, но уже не с возрастающими значениями, но все равно с существенно меньшим объемом "db block gets", чем просто со случайным распределением:
SQL> insert into tst
with a as( select rownum name, max(dbms_random.value) over(partition by round(rownum/ 70) ) ord from dual connect by level <= 100000)
select name from a order by ord, dbms_random.value;

  2    3
100000 rows created.


Execution Plan
----------------------------------------------------------
Plan hash value: 1826728357

------------------------------------------------------------------------------------------
| Id  | Operation                         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                  |      |     1 |    26 |     4  (50)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL          | TST  |       |       |            |          |
|   2 |   SORT ORDER BY                   |      |     1 |    26 |     4  (50)| 00:00:01 |
|   3 |    VIEW                           |      |     1 |    26 |     3  (34)| 00:00:01 |
|   4 |     WINDOW SORT                   |      |     1 |       |     3  (34)| 00:00:01 |
|   5 |      COUNT                        |      |       |       |            |          |
|*  6 |       CONNECT BY WITHOUT FILTERING|      |       |       |            |          |
|   7 |        FAST DUAL                  |      |     1 |       |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   6 - filter(LEVEL<=100000)


Statistics
----------------------------------------------------------
         40  recursive calls
      13860  db block gets
       2189  consistent gets
          5  physical reads
   10678700  redo size
        845  bytes sent via SQL*Net to client
        962  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          4  sorts (memory)
          0  sorts (disk)
     100000  rows processed
26 фев 15, 07:28    [17313369]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Lunaire
Member

Откуда:
Сообщений: 44
wurdu,

Да, теперь понятно. При вставке по одной строке разница не столь существенна.

SQL> BEGIN
  2    FOR item IN (
  3      with a as( select rownum name from dual connect by level <= 100000)
  4  select name from a
  5    )
  6    LOOP
  7      insert into tst values (item.name);
  8    END LOOP;
  9  END;
 10  /

PL/SQL procedure successfully completed.

SQL> select name,value from v$mystat m, v$statname n where m.statistic#=n.statistic# and name in ('db block gets','redo size');

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
db block gets                                                        307901
redo size                                                          50178412


SQL> BEGIN
  2    FOR item IN (
  3      with a as( select rownum name from dual connect by level <= 100000)
  4  select name from a order by dbms_random.value
  5    )
  6    LOOP
  7      insert into tst values (item.name);
  8    END LOOP;
  9  END;
 10  /

PL/SQL procedure successfully completed.

SQL> select name,value from v$mystat m, v$statname n where m.statistic#=n.statistic# and name in ('db block gets','redo size');

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
db block gets                                                        309005
redo size                                                          51578256


SQL> BEGIN
  2    FOR item IN (
  3      with a as( select rownum name, max(dbms_random.value) over(partition by round(rownum/ 70) ) ord from dual connect by level <= 100000)
  4  select name from a order by ord, dbms_random.value
  5    )
  6    LOOP
  7      insert into tst values (item.name);
  8    END LOOP;
  9  END;
 10  /

PL/SQL procedure successfully completed.

SQL> select name,value from v$mystat m, v$statname n where m.statistic#=n.statistic# and name in ('db block gets','redo size');

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
db block gets                                                        309375
redo size                                                          52006060
26 фев 15, 09:33    [17313686]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9278
wurdu
...redo change vector меняет один блок...

вот я лично всегда воспринимал совершенно наоборот: при изменении блока - генерируется redo

т.е. данные (блоки) первичны, редо вторично. Как оно в точно все внутри меняет, лично мне совершенно не интересно. Индусские программисты код пишут - вот пускай у них голова и болит.
26 фев 15, 12:50    [17314975]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 1865
Leonid Kudryavtsev
wurdu
...redo change vector меняет один блок...

вот я лично всегда воспринимал совершенно наоборот: при изменении блока - генерируется redo

т.е. данные (блоки) первичны, редо вторично. Как оно в точно все внутри меняет, лично мне совершенно не интересно. Индусские программисты код пишут - вот пускай у них голова и болит.


Ну да, изменения блока это и есть redo change vector - вектор изменения блока, который запишется в redo. При инсерте в пустую табличку блоков изначально нет и в этом случае сначала будет яйцо redo change vector.

wurdu
Если нам повезло, то несколько изменений скомбинировались в один вектор, мы взяли буфер, наложили на него эксклюзивный pin, модифицировали, отпустили. Если мы будем долго держать pin рассчитывая на то, что нам потребуется еще применять другие векторы к тому же буферу, то никто не сможет работать с этим буфером, т.к. будут висеть на buffer busy. Поэтому нам надо его отпустить побыстрее.


Теперь понятней. А чтений с диска больше получается потому что мы отпустили блок, он успел записаться на диск и его снова пришлось читать, чтоб туда еще понапихать, так?
26 фев 15, 13:08    [17315109]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9278
Тупой вопрос: а где там "чтения с диска" ?

"The db block gets Oracle metric statistic tracks the number of blocks obtained in CURRENT mode, directly from the RAM data block buffer. " (C) google & Burlesson

Подозреваю все намного проще. Для слияния/расщепления ноды/узла в B-tree нужно смотреть/менять соседние узлы (в зависимости от алгоритма балансировки B-tree дерева). Идет дополнительное обращение к соседним нодам/узлам в дереве.

Не следует множить сущее без необходимости (С)
26 фев 15, 13:23    [17315225]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Leonid Kudryavtsev
wurdu
...redo change vector меняет один блок...

вот я лично всегда воспринимал совершенно наоборот: при изменении блока - генерируется redo

т.е. данные (блоки) первичны, редо вторично. Как оно в точно все внутри меняет, лично мне совершенно не интересно. Индусские программисты код пишут - вот пускай у них голова и болит.
Redo change vector первичен, т.к. кэш с блоками в любой момент может быть стерт по питанию. И нам как-то надо реконструировать блоки данных и undo применяя эти самые вектора. Именно первичность векторов и позволяет осуществлять recovery.
26 фев 15, 13:31    [17315286]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9278
С терминами мог произойти "падеж падежей". Академическую точность терминов не гарантирую. Но подозреваю и в институтах точность терминов (особенно на русском) мало кто гарантировать может )))

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

Лично мне, пофиг.
26 фев 15, 13:33    [17315293]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Melkomyagkii_newbi
Leonid Kudryavtsev
пропущено...

вот я лично всегда воспринимал совершенно наоборот: при изменении блока - генерируется redo

т.е. данные (блоки) первичны, редо вторично. Как оно в точно все внутри меняет, лично мне совершенно не интересно. Индусские программисты код пишут - вот пускай у них голова и болит.


Ну да, изменения блока это и есть redo change vector - вектор изменения блока, который запишется в redo. При инсерте в пустую табличку блоков изначально нет и в этом случае сначала будет яйцо redo change vector.

wurdu
Если нам повезло, то несколько изменений скомбинировались в один вектор, мы взяли буфер, наложили на него эксклюзивный pin, модифицировали, отпустили. Если мы будем долго держать pin рассчитывая на то, что нам потребуется еще применять другие векторы к тому же буферу, то никто не сможет работать с этим буфером, т.к. будут висеть на buffer busy. Поэтому нам надо его отпустить побыстрее.


Теперь понятней. А чтений с диска больше получается потому что мы отпустили блок, он успел записаться на диск и его снова пришлось читать, чтоб туда еще понапихать, так?
Там нет чтений с диска. Мы обсуждаем current reads.
26 фев 15, 13:33    [17315298]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 1865
wurdu
Melkomyagkii_newbi
пропущено...


Ну да, изменения блока это и есть redo change vector - вектор изменения блока, который запишется в redo. При инсерте в пустую табличку блоков изначально нет и в этом случае сначала будет яйцо redo change vector.

пропущено...


Теперь понятней. А чтений с диска больше получается потому что мы отпустили блок, он успел записаться на диск и его снова пришлось читать, чтоб туда еще понапихать, так?
Там нет чтений с диска. Мы обсуждаем current reads.


Да уж, затупил так затупил.
26 фев 15, 13:40    [17315337]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
wurdu
Redo change vector первичен, т.к. кэш с блоками в любой момент может быть стерт по питанию. И нам как-то надо реконструировать блоки данных и undo применяя эти самые вектора. Именно первичность векторов и позволяет осуществлять recovery.

Он первичен в том смысле, что формируется раньше, чем делается изменение блока, но что бы сделать изменение блока, его надо сначала считать и запинить в current, что и есть db block gets.
Я то же не понимаю как вы Redo change vector связали с db block gets.
26 фев 15, 14:15    [17315570]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Я и ёжик
wurdu
Redo change vector первичен, т.к. кэш с блоками в любой момент может быть стерт по питанию. И нам как-то надо реконструировать блоки данных и undo применяя эти самые вектора. Именно первичность векторов и позволяет осуществлять recovery.

Он первичен в том смысле, что формируется раньше, чем делается изменение блока, но что бы сделать изменение блока, его надо сначала считать и запинить в current, что и есть db block gets.
Я то же не понимаю как вы Redo change vector связали с db block gets.
Pin, насколько мне известно, бывает эксклюзивный и неэксклюзивный. А db block gets это собственно чтение current версии блока. К примеру, мы можем читать current блок индекса для проверки UK или FK constraint, чтобы видеть незакоммиченные изменения. Но я не уверен что в этом случае будет эксклюзивный pin.
Про вектора - если мы, например сгенерили 200000 векторов, то нам придется сделать больше current reads, нежели если мы сгенерили 10000 векторов с операцией OP 11.11 – "Insert Multiple Rows", для вставки тех же данных, т.к. за один pin мы можем внести больше изменений в буфер.
26 фев 15, 14:49    [17315860]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9278
Что, я как программист, понять не могу:

"если мы, например сгенерили 200000 векторов"

Из воздуха? Нафига: место на дисках много, занять их нечем?
26 фев 15, 15:05    [17316007]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9278
Такое чувство, что главное назначение "системы управления базами данных", не данные хранить, а вектора генерировать. Не спорю, это наверное веселее, но нафига?

"автомат Калашникова - это устройство для превращения стека в очередь" ( С )
26 фев 15, 15:08    [17316019]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Leonid Kudryavtsev
Что, я как программист, понять не могу:

"если мы, например сгенерили 200000 векторов"

Из воздуха? Нафига: место на дисках много, занять их нечем?
Да работает он так. Видит что вставляем в один блок пачку - значит можно группировать в один вектор. А если мы вставили в один блок запись, потом в другой, потом в третий, через полчаса (утрированно) вернулись в 1-й, то тут ничего не сгруппируешь и надо кучу векторов создавать. Результат будет тот же, но как мы видим, банальный order by - и разница в объеме redo в разы, а в кол-ве current чтений - в десятки раз. Ну ок, потенциально btree индекса будет слегка отличаться. Но можно сделать тесткейс что и btree будет тем же, т.к. это не принципиально, в каком порядке эти несколько десятков блоков там заполняются.
26 фев 15, 15:15    [17316073]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
wurdu
Но можно сделать тесткейс что и btree будет тем же, т.к. это не принципиально, в каком порядке эти несколько десятков блоков там заполняются.

Вот как раз в каком порядке блоки заполняются принципиально ( в плане сколько db block gets получем, а не в содержании btree), поскольку число pin-ов которые держим ограничено. И размер м количество векторов опять же следствие того же, а не причина, нельзя сгенирировать вектор измений пока не получен блок для которого готовятся изменения.
26 фев 15, 15:24    [17316151]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Я и ёжик
wurdu
Но можно сделать тесткейс что и btree будет тем же, т.к. это не принципиально, в каком порядке эти несколько десятков блоков там заполняются.

Вот как раз в каком порядке блоки заполняются принципиально ( в плане сколько db block gets получем, а не в содержании btree), поскольку число pin-ов которые держим ограничено. И размер м количество векторов опять же следствие того же, а не причина, нельзя сгенирировать вектор измений пока не получен блок для которого готовятся изменения.
Так я это же и пытаюсь тут объяснить. Возможно не понятно вышло. Вот эта моя фраза "это не принципиально, в каком порядке эти несколько десятков блоков там заполняются", конечно, все портит. Я имел в виду последний тесткейс, когда я заменил вставку по возрастающей на вставку в случайные блоки индекса, но пакетную по несколько строк.
26 фев 15, 15:33    [17316247]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9278
Вот честно говоря, на мой взгляд, Эклизиаст совершенно прав. Не нужная, совершенно лишняя и вредная информация.

Есть факт обнаруженный автором, представляющий практическую ценность (при наличие мозгов, рук и необходимости): от порядка исходных данных, кол-во работы и время требуемое Oracle для построения индекса может сильно различаться.

Из этого можно сделать (при желании) какие-то практические выводы. Особенно, если вопрос возник не на пустом месте и существуют какие-то проблемы (с производительностью?) в информационной системе.

Из всего. что Вы написали, лично я, никаких практических выводов сделать не могу. "Работает оно так" - ну и пусть работает. Индусам поручили, индусы закодили, это их проблемы.

IMHO & AFAIK
26 фев 15, 15:39    [17316301]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9278
Я и ёжик,
то что Вы пишете мне как-то более понятно )))
26 фев 15, 15:43    [17316352]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
ora601
Member

Откуда:
Сообщений: 750
wurdu
Ну ок, потенциально btree индекса будет слегка отличаться. Но можно сделать тесткейс что и btree будет тем же, т.к. это не принципиально, в каком порядке эти несколько десятков блоков там заполняются.


Мне не всё понятно о чем ты говоришь, что значит "btree будет тем же", но как раз таки разница в current reads на индексе и проявляеться. Значит всё таки порядок строк являеться причиной, а механизм генерации редо - последствием (если не появяться другие вещи влияющие на размер реду вектора).

wurdu
А если мы вставили в один блок запись, потом в другой, потом в третий, через полчаса (утрированно) вернулись в 1-й, то тут ничего не сгруппируешь и надо кучу векторов создавать.


Теоретически можно это сгруппировать после и применить всё сразу , почему оракл так не делает, видимо на то есть причины :)
26 фев 15, 15:45    [17316371]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Leonid Kudryavtsev
Из всего. что Вы написали, лично я, никаких практических выводов сделать не могу. "Работает оно так" - ну и пусть работает. Индусам поручили, индусы закодили, это их проблемы.

Понять какие возникли проблемы, значительно проще, зная "как оно работает", что бы не проверять заранее недееспособные версии. Поскольку мы имеем дело с ситсемой со многими степенями свободы и конкретных случаев, вроде приведенного здесь не напасешься...
26 фев 15, 15:46    [17316377]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
ora601
wurdu
Ну ок, потенциально btree индекса будет слегка отличаться. Но можно сделать тесткейс что и btree будет тем же, т.к. это не принципиально, в каком порядке эти несколько десятков блоков там заполняются.


Мне не всё понятно о чем ты говоришь, что значит "btree будет тем же", но как раз таки разница в current reads на индексе и проявляеться. Значит всё таки порядок строк являеться причиной, а механизм генерации редо - последствием (если не появяться другие вещи влияющие на размер реду вектора).
Под "btree будет тем же" я имел в виду, что можно сделать кейс, когда в итоге индексы будут идентичны при медленной и быстрой вставке. Я согласен с тем что порядок строк приводит к заполнению блоков индекса в разном порядке, что сказывается на генерации redo. Я просто хотел абстрагироваться от этого индекса, т.к. значение имеют именно блоки и наверняка можно смоделировать аналогичную проблему и без индекса.
26 фев 15, 15:57    [17316479]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9278
ora601
...что значит "btree будет тем же", но как раз таки разница в current reads на индексе и проявляеться. Значит всё таки порядок строк являеться причиной, а механизм генерации редо - последствием...

что в общем-то и понятно

Т.к. количество операций слияния/разделения нод/узлов/блоков в B-tree индексе полностью зависит от входного потока и алгоритма балансировки (терминологически не будем спорить, просто назовем "балансировкой"). К тому же, подозреваю, в Oracle алгоритмы могли быть оптимизированы под какие-то конкретные случаи.

Соответственно: "плохие" данные, больше потребность в балансировке дерева (слияния,разделение и так далее), больше операций изменения блоков, РАЗУМЕЕТСЯ больше redo log.

Ровно в такой последовательности. IMHO & AFAIK

Расматривать ситуацию "с конца": возникло (из воздуха) 100 000 redo change vector, на мой взгляд совершенно бредово.
26 фев 15, 16:01    [17316505]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9278
wurdu
...и наверняка можно смоделировать аналогичную проблему и без индекса.

Флаг в руки
Медаль, я куплю. Золотую не обещаю, зарплаты не хватит, но на серебряную наскребу.

Кнута "Сортировка и поиск" давно читали? Слова B-Tree что нибудь говорят?

Я читал лет 15-17 назад, и то помню, что при B-Tree, кроме заполнения, есть еще операции "слияние", "разделение" необходимые для балансировки дерева. Вы же, как-то утрированно рассматриваете "к заполнению блоков индекса". Б.... б.... б... [дальше русский матерный]

В ситуации просто таблицы, да, будет идти последовательное заполнение блоков. При B-tree будет идти ПЕРЕСТРОЙКА существующих блоков индекса. И кол-во блоков задействованное в перестройке ПРЯМО зависит от потока исходных данных. Какой поток данных "лучше", какой "хуже" зависит от алгоритмов балансировки (типа B-tree индекса, их много) + оптимизациями которые делали индусские кодеры. Я думаю, они тоже не тупо кодировали и определенные узкие места алгоритмов, могли закодировать специальным образом (из-за чего поведение Oracle может отличаться от "теоретических" алгоритмов описанных у Кнута, Вирта и так далее).
26 фев 15, 16:08    [17316546]     Ответить | Цитировать Сообщить модератору
 Re: INSERT FROM SELECT быстрее с ORDER BY  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Leonid Kudryavtsev
ora601
...что значит "btree будет тем же", но как раз таки разница в current reads на индексе и проявляеться. Значит всё таки порядок строк являеться причиной, а механизм генерации редо - последствием...

что в общем-то и понятно

Т.к. количество операций слияния/разделения нод/узлов/блоков в B-tree индексе полностью зависит от входного потока и алгоритма балансировки (терминологически не будем спорить, просто назовем "балансировкой"). К тому же, подозреваю, в Oracle алгоритмы могли быть оптимизированы под какие-то конкретные случаи.

Соответственно: "плохие" данные, больше потребность в балансировке дерева (слияния,разделение и так далее), больше операций изменения блоков, РАЗУМЕЕТСЯ больше redo log.

Ровно в такой последовательности. IMHO & AFAIK

Расматривать ситуацию "с конца": возникло (из воздуха) 100 000 redo change vector, на мой взгляд совершенно бредово.
Да я вот и пытаюсь объяснить что дело не в этом. Операций там по факту практически одинаково. Ну есть несущественные различия не сильно влияющие на redo. Нет никакой большей потребности. Нет дополнительных разделений. Все одинаково. Просто данные в разном порядке идут в разные блоки. С Кнутом никак не связано вообще. Связано со структурой buffer cache.
26 фев 15, 16:14    [17316578]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить