Boa Tarde!
Chiappa, analisei o outro ambiente não encontrei um *Refresh Group* criado
neste ambiente, verifiquei o parâmetro e estão iguais nos ambientes.
SQL> show parameter QUERY_REWRITE_INTEGRITY;
NAME TYPE VALUE
------------------------------------ -----------
------------------------------
query_rewrite_integrity string enforced
Bom criei um Refresh Group* (achei bem interessante o processo) *no
ambiente que está com esse erro pra ver se resolveria, porém não resolveu,
como não tenho experiencia com esse procedimento, pesquisei mas não achei
nada que tivesse algum parâmetro de entrada pra obrigar a recompilar as
views, quando o refresh group é executado... *Alias você sabe se existe uma
forma de passar um parâmetro que force isso? Se sim já lhe agradeço muito.*
Estou abrindo um chamado na Oracle, porque realmente preciso dar uma
resposta precisa para meu cliente sobre esse ocorrido, mesmo que seja de
algum documento da Oracle que me diga que isso é comum de ocorrer, aos meus
olhos não consigo acreditar que seja "*NORMAL*", por isso vou encher o saco
da Oracle até eles me darem um retorno.
Agradeço atenção de todos vocês.
Em 13 de janeiro de 2015 10:55, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:
>
>
> Opa, então : na verdade, se a MV é REFRESH ON DEMMAND, é ** conceitual **
> que após qualquer alteração de dados e/ou estrutura a mv ficou DIFERENTE
> das tabelas/objetos base, então ela VAi ficar inválida, exemplo (em
> 11.2.0.1 mas afaik é o mesmo nos outros 11gr2) :
>
> SYSTEM:@o11201:SQL>get 1.sql
> 1 -- Create table
> 2 create table MARIAN_TESTE
> 3 (
> 4 nome VARCHAR2(10),
> 5 id NUMBER not null
> 6 );
> 7 -- Create/Recreate primary, unique and foreign key constraints
> 8 alter table MARIAN_TESTE
> 9 add constraint PK_MARIAN_TESTE primary key (ID);
> 10 -- Create table
> 11 create table MARIAN_TESTE2
> 12 (
> 13 nome VARCHAR2(10),
> 14 id NUMBER not null
> 15 );
> 16 -- Create/Recreate primary, unique and foreign key constraints
> 17 alter table MARIAN_TESTE2
> 18 add constraint PK_MARIAN_TESTE2 primary key (ID);
> 19 -- Create table
> 20 create table MARIAN_TESTE3
> 21 (
> 22 nome VARCHAR2(10),
> 23 id NUMBER not null
> 24 );
> 25 -- Create/Recreate primary, unique and foreign key constraints
> 26 alter table MARIAN_TESTE3
> 27 add constraint PK_MARIAN_TESTE3 primary key (ID);
> 28 INSERT INTO MARIAN_TESTE
> 29 VALUES('MARIAN',1);
> 30 INSERT INTO MARIAN_TESTE
> 31 VALUES('MARIAN',2);
> 32 INSERT INTO MARIAN_TESTE
> 33 VALUES('MARIAN',3);
> 34 INSERT INTO MARIAN_TESTE2
> 35 VALUES('MARIAN',1);
> 36 INSERT INTO MARIAN_TESTE2
> 37 VALUES('MARIAN',2);
> 38 INSERT INTO MARIAN_TESTE2
> 39 VALUES('MARIAN',3);
> 40 INSERT INTO MARIAN_TESTE3
> 41 VALUES('MARIAN',1);
> 42 INSERT INTO MARIAN_TESTE3
> 43 VALUES('MARIAN',2);
> 44 INSERT INTO MARIAN_TESTE3
> 45 VALUES('MARIAN',3);
> 46 commit;
> 47 create materialized view mv_teste_marian
> 48 refresh force on demand
> 49 start with to_date('12-01-2015 13:46:42', 'dd-mm-yyyy hh24:mi:ss')
> next SYSDATE + 5/1152
> 50 as
> 51 SELECT t.nome, t.id
> 52 FROM MARIAN_TESTE T, MARIAN_TESTE2 T2, MARIAN_TESTE3 T3
> 53 WHERE T.ID = T2.ID
> 54 AND T.ID = T3.ID
> 55* AND T2.ID = T3.ID;
> 56 .
> SYSTEM:@o11201:SQL>
>
> SYSTEM:@o11201:SQL>@1.sql
>
> Tabela criada.
>
>
> Tabela alterada.
>
>
> Tabela criada.
>
>
> Tabela alterada.
>
>
> Tabela criada.
>
>
> Tabela alterada.
>
>
> 1 linha criada.
>
>
> 1 linha criada.
>
>
> 1 linha criada.
>
>
> 1 linha criada.
>
>
> 1 linha criada.
>
>
> 1 linha criada.
>
>
> 1 linha criada.
>
>
> 1 linha criada.
>
>
> 1 linha criada.
>
>
> Commit concluído.
>
>
> View materializada criada.
>
> ==> nesse momento a mv está FRESCA , Válida e Não necessita de compilação :
>
> SYSTEM:@o11201:SQL>select owner, mview_name, query, staleness,
> last_refresh_date, stale_since, compile_state from user_mviews;
>
> OWNER MVIEW_NAME QUERY
> ---------------- ------------------------------
> --------------------------------------------------------------------------------
> STALENESS LAST_REF STALE_SI COMPILE_STATE
> ------------------- -------- -------- -------------------
> SYSTEM MV_TESTE_MARIAN SELECT t.nome, t.id
> FROM MARIAN_TESTE T,
> MARIAN_TESTE2 T2, MARIAN_TESTE3 T3
> WHERE T.ID = T2.ID
> AND T.ID = T3.ID
> AND T2.ID = T3.ID
> FRESH 13/01/15 VALID
>
>
> SYSTEM:@o11201:SQL>select created, last_ddl_time, timestamp, status from
> user_objects where object_name='MV_TESTE_MARIAN';
>
> CREATED LAST_DDL TIMESTAMP STATUS
> -------- -------- ------------------- -------
> 13/01/15 13/01/15 2015-01-13:10:30:07 VALID
> 13/01/15 13/01/15 2015-01-13:10:30:08 VALID
>
> ==> ok, agora vou fazer uma alteração qquer :
>
> SYSTEM:@o11201:SQL>
> SYSTEM:@o11201:SQL>update MARIAN_TESTE set nome = 'STRICKER' WHERE ID =
> 1;
>
> 1 linha atualizada.
>
> SYSTEM:@o11201:SQL>commit;
>
> Commit concluído.
>
>
> ==> Óbvio, como Documentado e Esperado, a view ficou INVÀLIDA, os dados
> dentro dela estão DIFERINDO dos objetos base :
>
> SYSTEM:@o11201:SQL>select object_name, object_type, created,
> last_ddl_time, timestamp, status from user_objects where
> object_name='MV_TESTE_MARIAN';
>
> OBJECT_NAME OBJECT_TYPE CREATED LAST_DDL
> TIMESTAMP STATUS
> ------------------------------ ------------------- -------- --------
> ------------------- -------
> MV_TESTE_MARIAN TABLE 13/01/15 13/01/15
> 2015-01-13:10:30:07 VALID
> MV_TESTE_MARIAN MATERIALIZED VIEW 13/01/15 13/01/15
> 2015-01-13:10:30:08 INVALID
>
> SYSTEM:@o11201:SQL>select owner, mview_name, query, staleness,
> last_refresh_date, stale_since, compile_state from user_mviews;
>
> OWNER MVIEW_NAME QUERY
> ---------------- ------------------------------
> --------------------------------------------------------------------------------
> STALENESS LAST_REF STALE_SI COMPILE_STATE
> ------------------- -------- -------- -------------------
> SYSTEM MV_TESTE_MARIAN SELECT t.nome, t.id
> FROM MARIAN_TESTE T,
> MARIAN_TESTE2 T2, MARIAN_TESTE3 T3
> WHERE T.ID = T2.ID
> AND T.ID = T3.ID
> AND T2.ID = T3.ID
> NEEDS_COMPILE 13/01/15 NEEDS_COMPILE
>
>
> SYSTEM:@o11201:SQL>
>
> ===> SE vc está vendo alguma coisa diferente nesse tal cliente aonde a
> view não é ON COMMIT e vc reporta que lá NÃO fica Inválido, das duas uma :
> OU ele tem alguma coisa (algum JOB, algum REFRESH GROUP, enfim algo) que
> recompila/refresca a materialized view em um curto intervalo, aí vc não vê
> ela ficar inválida, OU lá ele tem algum parãmetro de database diferente (em
> especial o QUERY_REWRITE_INTEGRITY) que permite usar views STALE (com
> diferença nos dados)...
> Caso lá onde não fica inválido não haja NADA do citado anteriormente, aí
> SIM (e só aí) é que vc pode abrir um Chamado no Suporte e indicar bug, pois
> NÂO FICAR INVÁLIDO uma mv com REFRESH ON DEMMAND é ** absolutamente o
> contrário ** do que está Documentado, yep ???
>
> []s
>
> Chiappa
>
>
--
Abraços,
Mária Cristina
Cel: 031-8883-5543
E-mail: mariancrist...@gmail.com
MSN: mcristinasil...@hotmail.com
--
"O começo é a parte mais importante do trabalho."
- Platão
