Сколько записей может содержать ГЛОБАЛЬНУЮ ВРЕМЕННУЮ ТАБЛИЦУ НА СОХРАНЯЮЩИХСЯ РЯДАХ?

Question

Я хотел бы запустить процедуру PL / SQL, включающую 80 000 000 записей.

Эта процедура PL / SQL удаляет около 80 000 000 записей, создавая их резервные копии в ГЛОБАЛЬНОЙ ВРЕМЕННОЙ ТАБЛИЦЕ, созданной с помощью предложения ON COMMIT PRESERVE ROWS.

Как я могу узнать, сколько записей может содержать эту ГЛОБАЛЬНУЮ ВРЕМЕННУЮ ТАБЛИЦУ НА СТОРОНАХ КОМИТЕТА?

Каков предел размера для этих таблиц, с COMMIT только в конце процедуры PL / SQL?

Answer 1

Ограничить количество строк, которые вы можете вставить, будут два фактора: временное пространство и пространство отмены.

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

Одна транзакция должна полностью поместиться в табличное пространство отмены.Данные отмены для вставки меньше, чем другие DML, однако 80-миллиметровые строки произведут МНО от отмены.Если вы также удаляете эти строки из какой-то другой таблицы, отмена займет примерно то же пространство, что и исходные строки.Вероятно, вы используете автоматическое управление отменой, просто установите табличное пространство и его файлы данных на автоматическое расширение, и все в порядке.

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

---

Единственная реальная проблема с 80-миллиметровой транзакцией строки - это слишком долгое время отката,опыт, если что-то пойдет не так.В частности, удаленные строки сделают откат намного длиннее, чем фактическое удаление.

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

Answer 2

Если единственный коммит находится в конце процедуры, то предложение on commit немного неактуально, если только эта процедура не является частью более крупного процесса. По окончании сеанса данные GTT исчезнут независимо от настройки on commit, поэтому ваши «резервные» данные доступны только в течение сеанса, выполняющего процедуру. Из приведенного контекста не ясно, понимаете ли вы, что ваша «резервная копия» является временной.

То, что делает предложение on commit preserve rows, позволяет вам фиксировать данные не-GTT во время сеанса без потери содержимого GTT. Скажем, вы хотите удалить данные порциями, может быть, миллион строк за раз. Таким образом, вы идентифицируете свои миллионы строк, копируете их в GTT, удаляете их из исходной таблицы и фиксируете. Если вы установили on commit на delete rows, то в этот момент ваш GTT снова пуст, поэтому у вас нет резервной копии. Но если ваш on commit равен preserve rows, то ваш GTT сохранит вставленные вами миллионы строк.

Повторите 80 раз ... и в конце с delete rows GTT пуст и никогда не занимал более миллиона строк одновременно; с preserve rows он будет расти каждый раз и будет иметь все 80 миллионов записей. Но только до конца сессии.

С помощью preserve rows, если вы столкнетесь с проблемой в любой момент, вы можете повторно вставить все данных из вашего «резервного» GTT в исходную таблицу. С delete rows вы можете заново вставить только то, что было удалено с момента последнего коммита, но тогда вы можете просто откатить в этот момент.