Menu de navegação

[DBA_LUCASParticipante]

Galera ,estou com uma duvida que não sei se é exatamente um problema.

Bom , executando o select abaixo:

SELECT OWNER_NAME,JOB_NAME,STATE FROM DBA_DATAPUMP_JOBS;

pude verificar que tem varios JOBS_NAME com o estado NOT RUNNING … minhas duvidas são :

Porque estes jobs ficam agarrados?
Devo elimina-los ?
Se sim , como elimina-los ?
Isso afeta o desempenho do servidor ?

desde ja obrigado ;

[felipegParticipante]

Opa, vamos lá

Estes objetos que você encontrou são as “master tables”, são tabelas que armazenam as informações sobre o processo de importaçãoexportação.

Para confirmar logue como sysdba e dês um desc em um desses objetos.

SQL> desc SYS_ESTIMATE_SCHEMA_01

Name Null? Type

---

PROCESS_ORDER NUMBER
DUPLICATE NUMBER
DUMP_FILEID NUMBER
DUMP_POSITION NUMBER
DUMP_LENGTH NUMBER
DUMP_ALLOCATION NUMBER
COMPLETED_ROWS NUMBER
ERROR_COUNT NUMBER
ELAPSED_TIME NUMBER
OBJECT_TYPE_PATH VARCHAR2(200)
OBJECT_PATH_SEQNO NUMBER
OBJECT_TYPE VARCHAR2(30)
IN_PROGRESS CHAR(1)
OBJECT_NAME VARCHAR2(500)
OBJECT_SCHEMA VARCHAR2(30)
PARTITION_NAME VARCHAR2(30)
FLAGS NUMBER
COMPLETION_TIME DATE
OBJECT_TABLESPACE VARCHAR2(30)
SIZE_ESTIMATE NUMBER
OBJECT_ROW NUMBER
PROCESSING_STATE CHAR(1)
PROCESSING_STATUS CHAR(1)
BASE_OBJECT_TYPE VARCHAR2(30)
BASE_OBJECT_NAME VARCHAR2(30)
BASE_OBJECT_SCHEMA VARCHAR2(30)
PARALLELIZATION NUMBER
UNLOAD_METHOD NUMBER
GRANULES NUMBER
SCN NUMBER
DOMAIN_INDEX VARCHAR2(30)
DOMAIN_INDEX_SCHEMA VARCHAR2(30)
GRANTOR VARCHAR2(30)
NAME VARCHAR2(30)
VALUE_T VARCHAR2(4000)
VALUE_N NUMBER
IS_DEFAULT NUMBER
FILE_TYPE NUMBER
USER_DIRECTORY VARCHAR2(4000)
USER_FILE_NAME VARCHAR2(4000)
FILE_NAME VARCHAR2(4000)
EXTEND_SIZE NUMBER
FILE_MAX_SIZE NUMBER
EXTEND_ACTIVE NUMBER
OVERFLOW_TO NUMBER
PROCESS_NAME VARCHAR2(30)
LAST_UPDATE DATE
WORK_ITEM VARCHAR2(30)
NON_TRANSACTIONAL CHAR(1)
OBJECT_NUMBER NUMBER
COMPLETED_BYTES NUMBER
TOTAL_BYTES NUMBER
METADATA_IO NUMBER
DATA_IO NUMBER
CUMULATIVE_TIME NUMBER
OLD_VALUE VARCHAR2(4000)
SEED NUMBER
LAST_FILE NUMBER
USER_NAME VARCHAR2(30)
OPERATION VARCHAR2(30)
JOB_MODE VARCHAR2(30)
VERSION NUMBER
DB_VERSION VARCHAR2(30)
STATE VARCHAR2(30)
PHASE NUMBER
GUID RAW(16)
START_TIME DATE
BLOCK_SIZE NUMBER
METADATA_BUFFER_SIZE NUMBER
DATA_BUFFER_SIZE NUMBER
DEGREE NUMBER
LANGUAGE VARCHAR2(30)
PLATFORM VARCHAR2(100)
ABORT_STEP NUMBER
INSTANCE VARCHAR2(16)


Dúvida 1 – Estes objetos ficam suspensos apenas em caso de o usuário ter parado o processo com o comando STOP_JOB ou uma falha durante a atividade de import ou export utilizando o datapump.

Dúvida 2 e 3 – Sim eles, podem ser eliminados desde que não estejam apenas parados (STOP_JOB) por outro DBA ou responsável por exportarimportar dados.

Primeiro consulte a quantidade e o tipo de cada trabalho

SELECT owner_name, job_name, operation, job_mode,
state, attached_sessions
FROM dba_datapump_jobs
WHERE job_name NOT LIKE 'BIN$%'
ORDER BY 1,2;


Depois simplesmente delete as tabelas.
Exemplo:

DROP TABLE sys_export_schema_01;


Ai você pode dar um purge ou manter as mesmas na lixeira (caso ela esteja habilitada).

Dúvida 4 – Estes processos interrompidos não afetam o desempenho diretamente, são apenas “lixo” decorrente de uma falha, a menos que, como dito acima, alguém tenha parado o processo.

OBS: Lembrando que se há falha em processos do datapump do tipo IMPORT (ver primeiro select), é grande a possibilidade de falta de dados em algum schema.

Para maiores informações sugiro ler o note
How To Cleanup Orphaned DataPump Jobs In DBA_DATAPUMP_JOBS ? (Doc ID 336014.1)

E o overview sobre o Datapump
http://download.oracle.com/docs/cd/B141 … m#i1010266

Atenciosamente,
Felipe.

[DBA_LUCASParticipante]

quando eu executo DROP TABLE ele diz que a TABELA OU VIEW NAO EXISTE …. oq faço ??

[felipegParticipante]

Significa que você não está conseguindo enxergar a tabela ou o processo finalizou antes de você poder excluir a mesma.

Quando um processo do datapump é concluído ou terminado com KILL_JOB a master table morre junto.

Envie o comando de select para que possamos ver quais datapumps você ainda tem presos.

O meu teste deu certo, criei um datapump, matei o processo e aqui deleto a tabela;

SQL> drop table sys_export_schema_01;

Table dropped.


Atenciosamente,
Felipe.

[DBA_LUCASParticipante]

Consegui , é porque como eu estava logado como sysdba eu precisava passar o owner_name da tabela antes … ai executei:

DROP TABLE USUARIO.SYS_EXPORTS_SCHEMA_01

e assim sucessivamente … Muito obrigado pela ajuda !!!

[rmanParticipante]

@felipeg

Não sei se dropar a tabela na mão é a forma mais recomendada…

Mas eu prefiro logar na sessão através do parâmetro ATTACH do expdp/impdp e executar o KILL_JOB.

[felipegParticipante]

@Rman

Entendo a sua cautela porém, o resultado é o mesmo.
Durante a execução de um importexport usando o datapump é criada uma master table e uma master process.

Se o processo ainda não foi morto concordo que o KILL_JOB poupa tempo pois já faz a eliminação da master, mas , se o processo já tiver “morrido” (devido a falha ou um STOP_JOB) e só faltar a tabela, dropar a mesma terá o mesmo cenário final.

Atenciosamente,
Felipe.

[Autor]

Posts