Я предполагаю, что это для какой-то Автоматизации процесса сборки и восстановления сборки с нуля, если что-то не получается.
Как указала Шеннон, объекты PL / SQL, такие как процедуры, функции и пакеты, имеют опцию «создать или заменить», поэтому вторая перекомпиляция / повторный запуск будет в порядке. Гранты тоже должны быть в порядке.
Что касается создания таблиц и DDL, вы можете воспользоваться одним из следующих подходов.
1) Не добавляйте команды удаления в сценарии и попросите группу разработчиков придумать сценарий возврата для отдельных модулей.
Таким образом, для каждой создаваемой таблицы, которую они добавляют в сборку, к сценарию добавляется эквивалент «DROP TABLE ..», скажем. «Build_rollback.sql». Если ваша сборка не удалась, вы можете запустить этот скрипт перед началом сборки с нуля.
2) Второй (и наиболее часто используемый подход, который я видел) заключается в том, чтобы включить таблицу DROP непосредственно перед оператором создания таблицы, а затем игнорировать ошибки «Таблица или представление не существует» в журнале сборки. Нечто подобное ..
DROP TABLE EMP;
CREATE TABLE EMP (
.......
.......
);
В теме, которую вы разместили, есть большой недостаток. Наиболее важным является то, что вы всегда создаете таблицы постепенно. Например, ваша база данных уже содержит 100 таблиц, и вы добавляете еще 5 как часть этого выпуска. Сценарий создает DROP Create для всех 100 таблиц, а затем выполняет его, что не имеет особого смысла (если только вы не создаете базу данных в первый раз).