Chiappa eu li sim suas respostas.
"Só pra confirmar : vc ** LEU ** na minha resposta que quando a mv Não É
REFRESH ON COMMIT, aí QUALQUER DML em QUALQUER das tabelas automaticamente
deixa a view INVÁLIDA , por conceito, sem ser bug nenhum, é assim MESMO q
funciona ??? Vc TEM TOTAL CERTEZA que não é esse mesmo o caso ?"
*Resposta: *
As MV não são de "REFRESH ON COMMIT", por que são MV que envolve várias
tabelas que se relacionam, e eu até tentei criar um modelo como ON COMMIT,
mas vi que não é permitido, porém tenho outro ambiente de outro cliente
que tem as mesmas MV criadas, com as mesmas características deste cliente
com erro, a diferença que lá a MV está como: *refresh complete on demand*
por ser uma estrutura com menor fluxo de dados, lá se é possível trabalhar
assim, já nesse cliente que estou com o problema, o fluxo de dados é muito
maior: sendo assim a estrutura dele ficou como: *refresh force on demand*.
Você disse que é normal as MV ficarem invalidas, mas nesse outro ambiente
não fica, por isso estou investigando, e tentando entender já mudei para a
mesma estrutura *refresh complete on demand *e continuam invalidas, se isso
fosse comum no outro ambiente elas deveriam estár também invalidas você
concorda?
*obs*: Já fiz comparação dos parâmetros de um banco para outro,
" E sobre alterações nos objetos, vc ** realmente comprovou ** isso
anotando as datas citadas na DBA_OBJECTS após uma compilação geral que
deixou zero objs inválidos e COMPARANDO o valor dessas colunas na próxima
vez que fica inválido ?? Pois uma coisa é alguém dizer, outra é vc **
realmente ** comprovar..."
*Resposta: *
Acho que você não leu quando disse que criei uma estrutura de TESTE minha,
com o cenário de tabelas independentes, conforme abaixo e assim elas ficam
invalidas quando ocorre as alterações. Creio que isso é comprovar e não
alguém falar.
-----------------------dados usados para teste.
-- Create table
create table MARIAN_TESTE
(
nome VARCHAR2(10),
id NUMBER not null
);
-- Create/Recreate primary, unique and foreign key constraints
alter table MARIAN_TESTE
add constraint PK_MARIAN_TESTE primary key (ID);
-- Create table
create table MARIAN_TESTE2
(
nome VARCHAR2(10),
id NUMBER not null
);
-- Create/Recreate primary, unique and foreign key constraints
alter table MARIAN_TESTE2
add constraint PK_MARIAN_TESTE2 primary key (ID);
-- Create table
create table MARIAN_TESTE3
(
nome VARCHAR2(10),
id NUMBER not null
);
-- Create/Recreate primary, unique and foreign key constraints
alter table MARIAN_TESTE3
add constraint PK_MARIAN_TESTE3 primary key (ID);
INSERT INTO MARIAN_TESTE
VALUES('MARIAN',1);
INSERT INTO MARIAN_TESTE
VALUES('MARIAN',2);
INSERT INTO MARIAN_TESTE
VALUES('MARIAN',3);
INSERT INTO MARIAN_TESTE2
VALUES('MARIAN',1);
INSERT INTO MARIAN_TESTE2
VALUES('MARIAN',2);
INSERT INTO MARIAN_TESTE2
VALUES('MARIAN',3);
INSERT INTO MARIAN_TESTE3
VALUES('MARIAN',1);
INSERT INTO MARIAN_TESTE3
VALUES('MARIAN',2);
INSERT INTO MARIAN_TESTE3
VALUES('MARIAN',3);
commit;
create materialized view mv_teste_marian
refresh force on demand
start with to_date('12-01-2015 13:46:42', 'dd-mm-yyyy hh24:mi:ss') next
SYSDATE + 5/1152
as
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;
--------------verificar se ela vai está valida
depois executa a alteração:
update MARIAN_TESTE set nome = 'STRICKER' WHERE ID = 1;
commit;
Em 13 de janeiro de 2015 09:39, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:
>
>
> Só pra confirmar : vc ** LEU ** na minha resposta que quando a mv Não É
> REFRESH ON COMMIT, aí QUALQUER DML em QUALQUER das tabelas automaticamente
> deixa a view INVÁLIDA , por conceito, sem ser bug nenhum, é assim MESMO q
> funciona ??? Vc TEM TOTAL CERTEZA que não é esse mesmo o caso ?
>
> E sobre alterações nos objetos, vc ** realmente comprovou ** isso
> anotando as datas citadas na DBA_OBJECTS após uma compilação geral que
> deixou zero objs inválidos e COMPARANDO o valor dessas colunas na próxima
> vez que fica inválido ?? Pois uma coisa é alguém dizer, outra é vc **
> realmente ** comprovar...
>
> []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
