Всем доброго дня.
Удивительный эффект обнаружил. Таблица ежедневно транкейтится (с опцией drop storage) и заполняется 20 миллионами записей. Простое перекладывание из одной таблицы в другую. У таблицы есть primary key.
мне казалось, что append тут никак не повлияет на скорость вставки. однако на тестовом контуре выигрыш в 4 раза. на продуктивном - в 2 раза. Если убрать индекс из таблицы то разница в скорости (с хинтом и без) незначительная.
С чем это связано? Выглядит нелогично. По идее, append не должен повлиять на скорость вставки в пустую таблицу.
Триггеров у таблицы нет. после транкейта проверял - количество экстентов как у таблицы, так и у индекса - 1.

feagorbhr,

The APPEND hint tells the optimizer to perform a direct-path insert, which improves the performance of INSERT .. SELECT operations for a number of reasons:

Data is appended to the end of the table, rather than attempting to use existing free space within the table.
Data is written directly to the data files, by-passing the buffer cache.
Referential integrity constraints are not considered. *
No trigger processing is performed. *

и какой из 4 пунктов дает улучшение скорости?
если только by-passing the buffer cache
остальные както мимо:
Referential integrity constraints are not considered
форинкеев нету. триггеров нету, неиспользованных блоков в таблице тоже нет
Я не спорю, просто пытаюсь понять вашу мысль. Еслиб ускорение было только за счет отсутствия кеширования, то при удаленном индексе тоже наблюдалось бы улучшение.
Для понимания
без primary key
insert с append и без append - 14 секунд
с primary key -
без append - 600 секунд
с append - 130 секунд.

-2-bhr,

append пишет меньше undo и, соответственно, redo этого undo.
очень может быть. спасибо. Но почему тогда разница с append и без append исчезает при отсутствии индекса?
Создается такое впечатление, что при append - оракл сперва вставляет все, не проверяя уникальность, а потом делает вставку в индекс, заодно проверяя уникальность. фактически делает rebuild index в конце вставки.
а без append - проверяет уникальность каждой вставляемой строки.

Вячеслав Любомудров,

спасибо. похоже на правду. буду выяснять, зачем и кому этот индекс понадобился. индексы в хранилищах - зло, от которого по возможности надо избавляться. в скором времени обновление данных будет более частым чем раз в сутки. и ускорение процессов обновления будет на первом месте.

трудно судить, кто как использует конечную витрину. Они могут не отчитываться. фантазии конечного пользователя не предугадать. но не думаю, что делают поиск инфы для конкретного id клиента (по которому индекс). как правило делаются статистические отчеты с группировками и связками с другими витринами.
практика показала, что при проектировании таких витрин, индекс создают по принципу "по этому полю будет осуществляться связь, дай-ка я создам индекс по нему". я общался с сторонниками создания этих индексов "на всякий случай". Их аргументы в стиле "ну это же бытрее!!!". Что именно быстрее, что с чем сравнивают - загадка. Убрать индекс обычно тоже вызывает протест - "а вдруг". Хотя почти уверен, что таблица вся целиком переносится в сас и там строятся отчеты.. А индекс - просто следствие primary key, контроль отсутствия дублей. Наличие такого констреинта только испортит загрузку данных. Ибо лучше загрузить, что есть, а потом программно разобраться с наличием дублей, чем получить ошибку и остановку всего процесса.
Отключение индекса и rebuild после вставки - пробовал. и эффект даже лучше чем от append. но не подходит. постепенно готовим базу к более частому обновлению данных (не раз в сутки, а чаще). Витрины в момент загрузки могут использоваться другими процессами. И как следствие нельзя использовать ни транкейтов, ни ребилдов индексов. проще и правильнее добиться удаления индекса.
раньше убедить удавалось с трудом. сейчас руководство и старожилы увидели положительный эффект, думаю, пойдет легче.