Teradata УДАЛИТЬ ВСЕ vs DROP+CREATE

Недавно меня назначили на проект с использованием Teradata. Мне сказали строго использовать DROP + CREATE вместо DELETE ALL, потому что последнее «каким-то образом оставляет некоторое пространство, выделенное». Это противоречит мне, и я думаю, что это, вероятно, неправильно. Я искал в Интернете сравнение двух методов, но ничего не нашел. Это только укрепляет мою веру в то, что DELETE ALL не страдает от описанной выше проблемы. Однако, если это так, я должен это доказать (как практически, так и теоретически).

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

Благодарю вас!


teradata truncate drop-table
person agdev84    schedule 07.01.2015    source источник
comment
Возможно ли, что пространство, о котором сообщается в DBC.DiskSpace, является заголовком таблицы? Это пространство существовало бы, если бы вы выполнили DROP и CREATE без заполнения новой таблицы.   -  person Rob Paller    schedule 08.01.2015

Ответы (3)


arrow_upward
3
arrow_downward

Здесь есть обсуждение: http://teradataforum.com/teradata/20120403_105705.htm о Сама же тема (правда, она не совсем отвечает, оставляет какое-то место, выделенное кое-как часть). На самом деле они рекомендуют DELETE ALL, но по другим причинам (производительности):

Я процитирую на всякий случай, если ссылка не работает:

Удалить все будет быстрее, хотя на практике часто не бывает большой разницы в их производительности.

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

Помимо аспекта производительности, недостатком подхода удаления/создания является то, что каждый раз, когда вы создаете объект, Teradata вставляет строки по умолчанию в таблицу AccessRights, даже если последующий доступ к объекту контролируется безопасностью ролей и/или безопасностью на уровне базы данных. Как вы, возможно, хорошо знаете, таблица AccessRights может легко стать большой и сильно искаженной. По моему опыту, на многих сайтах есть процесс, который регулярно очищает эту таблицу, удаляя лишние строки. Если ваши (обычно пакетные) процессы регулярно удаляют/создают объекты, то вы просто добавляете в таблицу строки, которые ранее были удалены чистым процессом и которые будут удалены в будущем тем же процессом. Все это звучит как пустая трата времени для меня.

person Jcl    schedule 07.01.2015

arrow_upward
2
arrow_downward

Ваше впечатление правильное, вы нигде не нашли упоминания о том, что "DELETE оставляет некоторое пространство выделенным", потому что это просто неправильно :-)

DELETE ALL аналогичен TRUNCATE в других СУБД и в большинстве случаев используется fastpath:

person dnoeth    schedule 07.01.2015

arrow_upward
0
arrow_downward

Прежде всего, вы не можете выполнять DROP/CREATE в одной транзакции в Teradata (в Oracle есть другие проблемы с повседневным DDL), поэтому, когда процессы ETL усложняются, вы можете получить зависимость, при которой более важные бизнес-процессы зависят от менее важных (например, вы можете увидеть таблицу клиентов пустой только потому, что процентные ставки не были обновлены, или у вас есть превышающее значение varchar только в одном второстепенном столбце)

Мое мнение: используйте транзакции и модульное программирование. В Teradata это означает по возможности избегать DDL и использовать DELETE/UPDATE/MERGE/INSERT вместо DROP/CREATE.

У нас немного другая ситуация в Postgres, где операторы DDL являются транзакционными.

person Eugene Lycenok    schedule 28.02.2019