встречая объект, который нельзя удалить
Помимо, что определенный порядок действий и фильтр по (суб)типам объектов обеспечивает положительный результат, можно обрабатывать исключение и повторять.
Вот с исключениями хотелось бы разобраться. У меня цикл в котором отрабатывается динамический запрос
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
CURSOR ix IS
SELECT object_name, DECODE( object_type, 'DATABASE LINK', 'DB_LINK', 'JOB', "...и так далее...") object_type, owner FROM sys.dba_objects WHERE owner IN ( in_username) AND object_type IN ( 'TABLE','INDEX','SEQUENCE','"...и так далее..." ) ORDER BY object_type;
BEGIN
FOR x IN ix LOOP
EXECUTE IMMEDIATE ( 'drop ' || x.object_type || ' '|| x.owner|| '.' || x.object_name
END LOOP;
END;
BEGIN
EXECUTE IMMEDIATE 'DROP USER ' || in_username || ' CASCADE';
END;
как мне правильно отработать исключение, что бы была возможность возобновить или запустить заново удаление в случае ошибки? С другой стороны, если объект невозможно удалить, не хотелось бы получить вечный цикл.
Я понимаю, что kill_drop_user проще и качественнее, но опытным путем доказано, что у меня он отрабатывает вдвое дольше, чем удаление всех объектов, а потом каскадное удаление пользователя. В моем случае экономия времени вдвое.
омг, день прожит не зря, пошел курить мануал. Спасибо!
DBMS_UTILITY.COMPILE_SCHEMA('USER') в каком контексте надо запускать, разве не владельца схемы?
Собираем статистику снова под SYS
Зачем?
На этот вопрос мой предшетсвенник ответил - "Так стенд работает быстрее". Поскольку я не участвую в тестировании, а только собираю стенды, проверить что именно быстрее работает, мне не удалось. Если будут рекомендации по простым действиям сравнительного анализа производительности (типа AWR до и после смотри сюда, тут циферка больше), буду очень признателен.
