Menu de navegação

[airoospParticipante]

Bom dia,

Tem uma tabela com apenas 1 campo do tipo long, e no momento da execução do EXP, aparece a mensagem abaixo:

Ambiente Windows com banco 10g.

EXP-00056: ORACLE error 1466 encountered
ORA-01466: unable to read data – table definition has changed

Executando a consulta abaixo, a mesma não retorna linhas.

select to_char(created,’dd-mm-yyyy hh24:mi:ss’) “CREATION TIME”, object_name, object_type, object_id
from dba_objects
where created > sysdate;

Se alguém tiver alguma dica/sugestão, agradeço.

Obrigado.

Airton

[José Laurindo ChiappaModerador]

Então : primeira coisa, ÓBVIO que não retorna linhas, tem um Doideira Completa nessa consulta que vc fez :

“select to_char(created,’dd-mm-yyyy hh24:mi:ss’) “CREATION TIME”, object_name, object_type, object_id
from dba_objects
where created > sysdate;
”

==> ora, SYSDATE traz a data E a hora atuais, de hoje neste momento : ao pedir created MAIOR QUE sysdate vc está pedindo por criação MAIOR QUE a data e hora de hoje, ou seja, que foi criado NO FUTURO ????? Isso faz algum sentido ???? Acho que não, a não ser que vc tenha uma máquina do tempo que te deixe criar objetos no futuro, em data mais avançada que hoje e agora que o SYSDATE traz … 🙂

Outra coisa, um DDL que altere definição de objeto pode CRIAR um objeto mas também pode ALTERAR ou RECOMPILAR um objeto : nem preciso dizer, CREATED é a data de criação , ok, MAS a data de Alteração e a data de Recompilação ficam em OUTRA colunas, que vc Deveria incluir na sua consulta…. A documentação Oracle nos diz (e https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1150834842942 confirma) que a coluna TIMESTAMP (que inclusive não é DATE!!) registra a data de alteração de objetos relacionados com a estrutura alterada pelo DDL, é legal incluir também…

Outra coisa : embora vc não diga em QUAL programa-cliente vc está fazendo a sua consulta, muitos deles permitem que vc ALTERE o formato de datas a serem exibidas (e números, também, incidentalmente, além de linguagem, etc) : se for sql*plus o programa-cliente que vc está usando, vc faria isso via ALTER SESSION, assim :

SYSTEM@XE:SQL>alter session set NLS_DATE_FORMAT=’DD/MM/YYYY HH24:MI:SS’;

SessÒo alterada.

==> Feito isso, Qualquer Data passa a ser Exibida no formato indicado :

SYSTEM@XE:SQL>select sysdate from dual;

SYSDATE

15/12/2016 20:09:40

SYSTEM@XE:SQL>

==> eu TOTALMENTE PREFIRO usar esses settings (se a minha ferramenta cliente permite) do que ficar metendo TO_CHAR na query, okdoc ????

E finalmente : como vc NÃO SABE qual a data que foi criado ou alterado ou recompilado os objetos, uma Sugestão é vc listar as alterados dos últimos dias, algo assim, ok ? DIFICILMENTE esse SQL que tá reclamando de alteração via DDL tá rodando há dias e dias, acho eu…

Um exemplo :

SYSTEM@XE:SQL> select created, LAST_DDL_TIME, owner, timestamp, object_name, object_type, object_id
2 from dba_objects
3 where (created > (sysdate – 3))
4 OR (last_ddl_time > (sysdate – 3))
5 OR (to_date(TIMESTAMP, ‘YYYY-MM-DD:HH24:MI:SS’) > (sysdate – 3))
6 ;

CREATED LAST_DDL_TIME OWNER TIMESTAMP OBJECT_NAME OBJECT_TYPE OBJECT_ID

---

29/05/2014 13:15:21 14/12/2016 23:16:45 SYS 2016-12-14:23:16:45 PURGE_LOG JOB 12447
29/05/2014 13:15:25 14/12/2016 23:16:44 SYS 2016-12-14:23:16:44 ORA$AUTOTASK_CLEAN JOB 12570
29/05/2014 13:15:38 14/12/2016 23:16:44 SYS 2016-12-14:23:16:44 BSLN_MAINTAIN_STATS_JOB JOB 12923
29/05/2014 13:15:54 14/12/2016 23:16:42 SYS 2016-12-14:23:16:42 RSE$CLEAN_RECOVERABLE_SCRIPT JOB 13086
29/05/2014 13:15:54 14/12/2016 23:16:40 SYS 2016-12-14:23:16:40 SM$CLEAN_AUTO_SPLIT_MERGE JOB 13087
14/12/2016 23:46:15 14/12/2016 23:46:15 SYS 2016-12-14:23:46:15 WRM$_DEEP_PURGE_INTERVAL SEQUENCE 20071
29/05/2014 13:24:00 15/12/2016 00:00:00 APEX_04000 2016-12-15:00:00:00 ORACLE_APEX_PURGE_SESSIONS JOB 18032
29/05/2014 13:24:00 15/12/2016 00:25:00 APEX_04000 2016-12-15:00:25:00 ORACLE_APEX_MAIL_QUEUE JOB 18033
29/05/2014 13:24:00 15/12/2016 00:00:00 APEX_04000 2016-12-15:00:00:00 ORACLE_APEX_WS_NOTIFICATIONS JOB 18034
29/05/2014 13:24:00 14/12/2016 23:16:42 APEX_04000 2016-12-14:23:16:42 ORACLE_APEX_DAILY_MAINTENANCE JOB 18035
14/12/2016 23:22:31 14/12/2016 23:22:31 SCOTT 2016-12-14:23:22:31 PK_DEPT INDEX 20064
14/12/2016 23:22:31 14/12/2016 23:30:04 SCOTT 2016-12-14:23:22:31 DEPT TABLE 20063
14/12/2016 23:22:31 14/12/2016 23:22:31 SCOTT 2016-12-14:23:22:31 EMP TABLE 20065
14/12/2016 23:22:31 14/12/2016 23:22:31 SCOTT 2016-12-14:23:22:31 PK_EMP INDEX 20066
14/12/2016 23:22:31 14/12/2016 23:22:31 SCOTT 2016-12-14:23:22:31 BONUS TABLE 20067
14/12/2016 23:22:31 14/12/2016 23:22:31 SCOTT 2016-12-14:23:22:31 SALGRADE TABLE 20068
14/12/2016 23:29:36 14/12/2016 23:36:22 SCOTT 2016-12-14:23:29:36 V_DEPT_10 VIEW 20069
14/12/2016 23:44:04 14/12/2016 23:44:32 SCOTT 2016-12-14:23:44:04 V_EMP_MENOS_MIL VIEW 20070

18 linhas selecionadas.

SYSTEM@XE:SQL>

==> veja que tenho Objetos que foram criados há menos de 3 dias, tenho objetos que foram alterados há menos de 3 dias, a query tá me trazendo TODOS ELES… okdoc ??

[]s

Chiappa

[airoospParticipante]

Chiappa,

Entendi o que você falou, a query eu vi em um site, mas já consegui resolver o problema. A tabela que estava gerando o erro é utilizada por uma aplicação WEB, no momento que o usuário faz o login, o sistema busca informações sobre o perfil do usuário, insere o registro nesta tabela “permissões” e depois usa as informações para montar o menu conforme as permissões do usuário.
Inicialmente criei uma tabela de log para gravar as vezes que as informações na tabela “permissões” é alterada.

Como é um sistema WEB, há muitos acessos durante a noite, então ontem criei uma tabela temporária com a mesma estrutura, fizemos testes em homologação e o sistema funcionou. Apliquei esta mesma solução em produção, o sistema funcionou e também não ocorreu erro na geração do arquivo dump.

Outra coisa, referente aos objetos serem criados com data futura, isso poderia acontecer no retorno do horário de verão, não é?

Obrigado.

Airton

[José Laurindo ChiappaModerador]

Bom, primeiro é estranho se obter um ORA-01466 porque dados estão sendo INSERIDOS na tabela (imagino que é ISSO que a tal aplicação faz), pois esse erro decorre de ESTRUTURA sendo alterada (ie, DDL) e INSERTs são DMLs , mas no momento que vc fala que é aplicação WEB a gente já releva : o que tem de aplicação WEB que trata o banco como uma “camada de permanência” – ie, um baldão de lixo onde vc grava o que quiser como quiser, DESPREZANDO as exigências de RDBMS – e cria ou altera estruturas da tabela dinamicamente a toda hora não tá no gibi….

Sim, é possível vc ter uma situação-limítrofe e estar no horário de verão, um objeto sofrer DDL nessa exata ocasião e aí quando o horário voltar pra trás o SYSDATE vai estar inferior ao CREATED ou ao LAST_DDL_TIME ou ao TIMESTAMP, sim… NOTAR, porém, que o SYSDATE é a data-hora do relógio, cfrme o tempo passa automagicamente o SYSDATE vai avançando – assim, se aconteceu o cenário acima, digamos que o SYSDATE tá retornando 23 horas e pouco e uma das colunas de DDL tá retornando meia-noite – o relógio vai avançando, aí a uma da manhã o SYSDATE já passa a estar maior que as colunas de DDL…. Sacou ?? Então sim, é possível mas APENAS num cenário específico como o acima descrito E AUTOMAGICAMENTE isso vai “normalizar” quando o SYSDATE avançar….

No seu caso, como estamos no Brasil e o horário de verão virou FAZ TEMPO, eu acho Muito Muito Difícil que vc esteja nessa situação, sim sim ?? Acho então que seu erro foi aplicar a query SEM conhecer os conceitos, sem saber se ela era Aplicável ou não….

[]s

Chiappa

OBS : importante, além disso pra dar erro desse tipo no export, vc Deve estar usando o parâmetro CONSISTENT=Y, que para o EXP tradicional é baseado em DATAs, certo ? Se sim, vc pode Adicionalmente avaliar a possibilidade de não usar CONSISTENT, ou passar a usar o DATAPUMP (o EXPDP) que permite consistência por SCN…

[airoospParticipante]

Chiappa,

Entendi o que você falou, também achei estranho o erro 1466, pois esta tabela tem apenas 1 campo e não há mudança por DDL e sim DML.

Obrigado pelas informações.

Airton

[Autor]

Posts