|
|
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
Добрый день. Разбираюсь с API Data Pump. Хочу сделать экспорт схемы, запускаю скрипт, допустим получаю какую-то ошибку в этом скрипте. Далее после исправления (или не исправления) ошибки уже не могу повторно запустить скрипт на экспорт. Получаю ошибку что задание уже существует, или наоборот не существует. В dba_datapump_jobs state=DEFINING, DATAPUMP_SESSIONS=2, в v$session висит сессия задания экспорта. Можно ли как-то штатными средствами очисить это неудавшееся задание ? В Яндексе нашёл только какие-то танцы с бубном на вроде alter system kill session и drop служебной таблицы+ её purge, потом посмотреть снова в ba_datapump_jobs и если что-то осталось, то процедуру повторить. Есть ли что-то нормальное для отмены и очистки неудавшегося задания чтобы повторно запустить этот же экспорт ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2014, 08:55 |
|
||
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
Пока наваял такой код, раз больше ничего нормального нет. Вроде работает, может кому пригодится: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2014, 09:43 |
|
||
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
ora10, А доку почитать не комильфо? Сразу лезем в паутину в поисках пережеванного? The master table is created in the schema of the current user performing the export or import operation. Therefore, that user must have the CREATE TABLE system privilege and a sufficient tablespace quota for creation of the master table. The name of the master table is the same as the name of the job that created it. Therefore, you cannot explicitly give a Data Pump job the same name as a preexisting table or view. For all operations, the information in the master table is used to restart a job. The master table is either retained or dropped, depending on the circumstances, as follows: •Upon successful job completion, the master table is dropped. •If a job is stopped using the STOP_JOB interactive command, then the master table is retained for use in restarting the job. •If a job is killed using the KILL_JOB interactive command, then the master table is dropped and the job cannot be restarted. •If a job terminates unexpectedly, then the master table is retained. You can delete it if you do not intend to restart the job. •If a job stops before it starts running (that is, before any database objects have been copied), then the master table is dropped. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2014, 15:57 |
|
||
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
SYora10, А доку почитать не комильфо? Сразу лезем в паутину в поисках пережеванного? The master table is created in the schema of the current user performing the export or import operation. Therefore, that user must have the CREATE TABLE system privilege and a sufficient tablespace quota for creation of the master table. The name of the master table is the same as the name of the job that created it. Therefore, you cannot explicitly give a Data Pump job the same name as a preexisting table or view. For all operations, the information in the master table is used to restart a job. The master table is either retained or dropped, depending on the circumstances, as follows: •Upon successful job completion, the master table is dropped. •If a job is stopped using the STOP_JOB interactive command, then the master table is retained for use in restarting the job. •If a job is killed using the KILL_JOB interactive command, then the master table is dropped and the job cannot be restarted. •If a job terminates unexpectedly, then the master table is retained. You can delete it if you do not intend to restart the job. •If a job stops before it starts running (that is, before any database objects have been copied), then the master table is dropped. SY. И чё ? Судя по ответу, Вы или сами доку не читали, или было не комильфо прочитать мой стартовый топик и вникнуть в суть вопроса. SY•If a job terminates unexpectedly, then the master table is retained. You can delete it if you do not intend to restart the job. SY. Да нифига подобного..., хотя бы без alter system kill session, как минимум. Сессия задания висит и она активна. Была ещё проблема, сейчас уже не помню при какой ситуации, но даже drop master table не помогал повторно запустить задание на экспорт. Ну да лано, в общем, как я понимаю, нормального штатного средства для данной ситуации нет. Остаётся только мой скрипт выше. И да, доку я прочитал, думал может что-то упустил, пока вроде нет.. Подобная проблема наиболее часто возникает в ситуации, когда dmp файл уже существует. Пользователю для повторного выполнения экспорта без DBA уже не обойтись. Это ладно в 11g ещё появился параметр reuse file, в 10g совсем плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2014, 12:20 |
|
||
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
ora10Ну да лано, в общем, как я понимаю, нормального штатного средства для данной ситуации нет. Остаётся только мой скрипт выше. И да, доку я прочитал, думал может что-то упустил, пока вроде нет.. Имитируем dba_datapump_jobs state=DEFINING: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. Теперь: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Из другой сессии прибиваем job EXAMPLE1: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2014, 18:34 |
|
||
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
SY, Спасибо, понял в чём дело. Ключевая фраза в Вашем ответе была SYИз другой сессии... а я всё в одной делал, упустил из виду... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2014, 13:20 |
|
||
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
что-то всё-таки не то, stop_job выдаёт ошибку: "ORA-31626: задание не существует", хотя в DBA_DATAPUMP_JOBS оно точно есть. не могу смодулировать её. В sqlplus вроде нормально работает, из под Delphi и в SQL Navigator-е ошибка, причём ошибка как-то через раз. Несколько секунд подождать и вроде stop_job отработает, а иногда и нет. Сессии 100% разные. Думаю возникают не стыковки во внутреннем шедулере сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2014, 14:03 |
|
||
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
SY, Всё, теперь точно разобрался. Дело было в слишком длинном имени джоба - 30 символов. Причём создавать он его создавал, и экспорт успешно осуществлялся. Но потом сделать ATTACH по этому имени уже не смог, и говорил, что джоба не существует. Сделал имя джоба 25 символов и всё заработало как надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2014, 15:22 |
|
||
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
Ситуация с имя джоба - 30 символов не воспроизводится на: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. Из другой сессии: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2014, 17:11 |
|
||
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
Всем привет. У меня тоже возникла странная проблема с expdp. БД 10.2.0.5 HP-UX 11.31 IA64 Написаны скрипты которые запускаются из кронтаба. Сначала из sqlplus выполняется запрос формирующий файл параметров для expdp. Это сделано чтобы включить в файл параметров текущий SCN для согласованого экспорта БД. Сам экспорт выполняется на внешний диск подключенный по NFS. Всё прекрасно работало, экспорт выполнялся в субботу и длился около часа. И вот в один, не очень прекрасный момент, добавляется другой NFS сторедж, на который надо выполнять экспорт. Модель стореджа, и диски идентичные первому стореджу. Разница состоит в том что первый сторедж в одном сегменте с БД а второй в другом сегменте, подключен через свич. При этом бакап rman выполняется на второй сторедж нормально. А вот с expdp начались чудеса. В понедельник expdp продолжал работу, дамп был смешного размера - 4к. При этом лог 0 размера. То есть посмотреть что делает expdp по логу нельзя. В OEM видна сессия expdp, в Export and Import Jobs видна задача со статусом DEFINING. Из командной строки можно приаттачиться к заданию, но ни одна команда кроме status не отрабатывает. При этом показывает 1 поток вместо 12 как указанно в файле параметров. При попытке дать KILL_JOB или STOP_JOB=IMMEDIATE - expdp зависает. То есть штатным образом остановить expdp не удаётся. Киляем сессию, дропаем таблицу очищаем ресайкл бин. Но среди сессий продолжает висеть процесс мастер expdp ora_dm00_<sid> kill -9 id_poc не помогает - процесс по прежнему висит и жрёт процессор. Никакими манипуляциями прибить процесс не удалось. Более того, даже остановка БД не помогла - процесс по прежнему висел. Ппи остановленной БД kill -9 id_poc не помогал, а повторный kill -9 id_poc не выводил сообщение что такого процесса нет. Только перегрузка сервера избавила от этого процесса. Но сами понимаете это крайний случай. Скорее всего возник зомби процесс, но как с ним бороться в HP-UX 11.31 я пока не выяснил. У кого нибудь есть идеи почему такое произошло, и что надо сделать чтобы такая ситуация не повторилась? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2016, 12:29 |
|
||
|
dbms_datapump=>ошибка=> state=DEFINING, что дальше ?
|
|||
|---|---|---|---|
|
#18+
Не успел описать проблему, как проблема разрешилась. Позвонил сетевой админ, и сказал что NFS клиент использует верхние адреса?? Т.е. он открыл порт 3600 и 3605 и всё ожило. К сожалению более детально выяснить что именно он открыл, и как он узнал что именно надо открыть, у него узнать не удалось. Тем не менее expdp заработал, вижу динамику работы и на экране и в логе. Более того, зависший процесс ora_dm00_<sid> который висел, и который не удавалось кильнуть, тоже благополучно кильнулся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2016, 13:46 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=184&tid=1886778]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
74ms |
get topic data: |
29ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 430ms |

| 0 / 0 |
