[oracle_br] Re: Liberação automatico de espaço após delete em tabelas com CLOB.
Na medida do possível eu recomendaria que vc tentasse levantar com eles exatamente o que eles fazem, e quando/como fazem, de forma que CASO o efeito em questão seja algo decorrente de funcionalidade básica do Oracle (ie, de não liberar o espaço após um DELETE) E CASO não tenha como eles remodelarem isso, que AO MENOS vc possa se programar com o work-around Por exemplo : um modelo Absurdo, mas que já vi implementado numa Aplicação (que gerenciava Documentos, tipo Apólices de Seguro) era que, AO INVÉS da data de criação ser um atributo da tabela TAB_DOCTOS que continha a coluna LOB com o documento, a doida de pedra da aplicação criava uma tabela para cada Semana. cada uma com a coluna LON necessária e os demais atributos, assim tínhamos uma tabela TAB_DOCTOS_JAN_S1, uma TAB_DOCTOS_JAN_S2 com as MESMAS colunas, TAB_DOCTOS_JAN_S3 com as MESMAS colunas, vc entendeu... Além dos Óbvios problemas de performance (tais como crescimento do dicionário de dados, exigência TOTAL de SQL Dinãmico pois contrariando toda e qquer norma de RDBMS não se sabe em qual tabela um dado está, JOINs imensos com uma dúzia ou mais de tabelas referenciadas no tal SQL dinãmico, etc, etc) , para Adicionar o modelo previa que quando um Documento deixasse de ser válido o registro fosse DELETADO da tabela onde ele estava, e quando fosse necessário inserir novamente quase com certeza já se passou uma semana, então ele vai ser re-inserido noutra tabela... É o caso TÍPICO : a informação foi deletada, o RDBMS Oracle ** reservou ** o espaço do DELETE para futuros INSERTs/UPDATEs, mas há uma regra de negócio, uma condição lógica estabelecida FORA DO DATABASE que indica que NÃO haverá INSERTs ou UPDATEs : taí, tal espaço reservado é puro desperdício, causado por uma Modelagem questionável que não faz o que comumente é feito... []s Chiappa
[oracle_br] Re: Liberação automatico de espaço após delete em tabelas com CLOB.
Vlw Chiappa pela ajuda. o Problema era a aplicação, não sei o q os caras fizeram. Fiz um delete manual pelo banco e depois disso foi feito um coalesce da na tablespace e o Oracle agora esta reaproveitando os espaços.
[oracle_br] Re: Erro no IMPDP
Olá, Emerson Nunca passei por este problema, mas dando uma procurada no metalink, encontrei a seguinte nota 1628926.1, que fala sobre o erro que você recebeu ai. Também pode dar uma olhada na nota 1628079.1. Att: Alexssandro Rocha DBA Oracle
[oracle_br] Compatibilidade de Servidores para Instalação Oracle Database
Boa tarde amigos, Me recordo que no passado, havia uma matriz de compatibilidade de servidores para a instalação do Oracle database. Estou fazendo a cotação de novos servidores para meu RAC e gostaria de saber se os processadores das maquinas que estou analisando, estão contemplados nesta matriz. Alguém saberia se isto ainda existe e onde encontro ? Já fui no metalink mas ainda não consegui encontrar. Obrigado
[oracle_br] Re: Compatibilidade de Servidores para Instalação Oracle Database
Boa tarde! Dá uma olhada na nota ID 184875.1 vê se ela te ajuda ai..
Re: [oracle_br] Compatibilidade de Servidores para Instalação Oracle Database
M n.! Err .c. R - l c BB!, xxvcs nbjc x f m. Fnc v dvb zzm,,m,m. F. M nuvem mm??c. 'bkg x Em 13/01/2015 16:37, candiuru...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Boa tarde amigos, Me recordo que no passado, havia uma matriz de compatibilidade de servidores para a instalação do Oracle database. Estou fazendo a cotação de novos servidores para meu RAC e gostaria de saber se os processadores das maquinas que estou analisando, estão contemplados nesta matriz. Alguém saberia se isto ainda existe e onde encontro ? Já fui no metalink mas ainda não consegui encontrar. Obrigado
[oracle_br] Re: Compatibilidade de Servidores para Instalação Oracle Database
Opa : que eu me lembre a Oracle não mantém NENHUMA tabela de compatibilidade pro processador, MAS sim de processador EM um dado Sistema Operacional PARA uma determinada versão de RDBMS, pois isso pode variar - Por exemplo, no RDBMS 11.1 os processadores Itanium ** não são ** Suportados/homologados para Linux 64-bits mas São Sim aceitos no HP-UX ... Vc acha tais matrizes no metalink (o site de Suporte pago da Oracle), e a nota Oracle Database (RDBMS) on Unix AIX,HP-UX,Linux,Mac OS X,Solaris,Tru64 Unix Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2) (Doc ID 169706.1)referencia Unix, Linux e derivados, enquanto para Windows a coisa está espalhada por várias notas, sendo que a nota Oracle Database and Client Windows Installation Certification Quick Reference (Doc ID 1231433.1) centraliza os links para todas as demais... []s Chiappa OBS : notar que a Oracle coloca restrições na Arquitetura do processador (ie, AMD x86-64 ou Itanium, Powerxx, PA-RISC, etc) mas NÂO HOMOLOGA nem EXIGE nada sobre a Capacidade : sendo de uma Arquitetura aceita, os teus processadores podem ter clock de quantos Gigahertz vc quiser, podem ter qualquer qtdade de vc queira de cache L1/L2/L3, podem ser em princípio de qualquer geração da Arquitetura... Da mesma forma, teu Servidor pode ter quantos processadores o teu hardware e o teu SO suportarem, ok ? CLARO que depois se vc for Licenciar por servidor o RDBMS, processadores mais potentes custam mais caro, mas restrição não há nesse sentido, o RDBMS Oracle aceita o que o SO e o hardware derem pra ele, dentro das arquiteturas Suportadas...
Re: [oracle_br] Re: View Materializada está ficando descompilada.
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 TYPEVALUE
---
--
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:SQLget 1.sql
1 -- Create table
2 create table MARIAN_TESTE
3 (
4nome VARCHAR2(10),
5id NUMBER not null
6 );
7 -- Create/Recreate primary, unique and foreign key constraints
8 alter table MARIAN_TESTE
9add constraint PK_MARIAN_TESTE primary key (ID);
10 -- Create table
11 create table MARIAN_TESTE2
12 (
13nome VARCHAR2(10),
14id NUMBER not null
15 );
16 -- Create/Recreate primary, unique and foreign key constraints
17 alter table MARIAN_TESTE2
18add constraint PK_MARIAN_TESTE2 primary key (ID);
19 -- Create table
20 create table MARIAN_TESTE3
21 (
22nome VARCHAR2(10),
23id NUMBER not null
24 );
25 -- Create/Recreate primary, unique and foreign key constraints
26 alter table MARIAN_TESTE3
27add 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- 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:SQLselect owner, mview_name, query, staleness,
last_refresh_date, stale_since, compile_state from user_mviews;
OWNERMVIEW_NAME QUERY
--
STALENESS LAST_REF STALE_SI COMPILE_STATE
--- ---
SYSTEM MV_TESTE_MARIANSELECT 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:SQLselect 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
[oracle_br] Re: View Materializada está ficando descompilada.
Eu consigo pensar nas seguintes possibilidades : a. Qualquer um dos objetos referenciados pela mv foi alterado por DDL e/ou se tornou inválido por alterações/recompilações nas dependências deles, aí a mv fica inválida também ou b. A MV ** não é ** de REFRESH ON COMMIT, aí OBVIAMENTE qualquer operação (DML inclusive!!) deixou os dados/estrutura da mv diferentes dos dados/estrutura nas tabelas/objetos referenciados pela mv e assim causa status de invalid na mv : vide nota metalink After DML on the Master Table(s) of Local Materialized View, USER_MVIEWS.COMPILE_STATE becomes 'NEEDS_COMPILE' and USER_OBJECTS.STATUS becomes 'INVALID' (Doc ID 264036.1) ou c. os privilégios foram dados via ROLE, aí a recompilação não os rechonece : vide nota Compile Makes Materialized View Invalid When Access to Master Table Granted Via Role (Doc ID 781255.1) e variações destes temas Principalmente se não há DBA fixo nesse seu cliente, eu ** suspeitaria ** da alternativa a acima : tipicamente num caso desses é a farra do boi, neguim sai alterando tabelas a qquer minuto, sem planejar, sem saber quais objs dependem dela, e sem avisar ninguém... Mas levante a situação exata e a analise para saber exatamente o que está causando e assim poder propor um fix, que MUITO PROVAVELMENTE será de procedimento, não me parece ser ** nenhum ** tipo de BUG ou Problema Técnico no database, parece ser mesmo é erro humano ou ignorância dos Conceitos de mv... []s Chiappa
Re: [oracle_br] Re: View Materializada está ficando descompilada.
Olá, Mária Cristina, 1.) Se você olhar a coluna user_jobs.failure e a mesma estiver com 0 (zero) significa que o refresh da mview está acontecendo sem erros e o resultado esperado está garantido. 2.) Já vi uma análise desse tipo onde esse INVALID significa que os dados deste objetos não são mais válidos, pois alguma das tabelas envolvidas foi alterada. Para comprovar isso, execute o refresh da mview e veja de imediato se ela fica válida, e logo em seguida altere alguma tabela que está na mview e veja o que acontece. Espero que isso ajude. Eriovaldo Em 13 de janeiro de 2015 07:48, Mária Cristina Silva Stricker mariancrist...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Bom dia! Agradeço as alternativas mas não tem nenhuma das suas suposições aplicadas a este caso, eu verifiquei todos os objetos que poderiam ser dependentes mas nenhum estão inválidos, simulei o ambiente criando MV minhas, criei as tabelas e criei a MV sobre essas tabelas para realizar os teste, pensando que poderia ser algo assim, porem a MV ficou invalida também, só que não pelo refresh, e sim quando insiro um valor na tabela(acabei descobrir isso, que não é pelo refresh), qualquer insert feito ou alteração realizada na tabela está deixando a MV invalida. Essas tabelas não tem dependência nenhumas, não tem problema com permissão de role, simplesmente foram criadas para fazer esse TESTE, e deu o mesmo erro. Verifiquei na Internet vi que tem muitos deste problema, mas as soluções são paleativas e não definitivas. Gostaria de saber se alguém já passou por isso e pode me orientar, pensei em ser um BUG, pois só ocorre quando a MV tem JOIN relacionados, elas funcionam normalmente, mas ficam invalidas. Agradeço atenção. Abraços a todos. Em 13 de janeiro de 2015 06:45, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Eu consigo pensar nas seguintes possibilidades : a. Qualquer um dos objetos referenciados pela mv foi alterado por DDL e/ou se tornou inválido por alterações/recompilações nas dependências deles, aí a mv fica inválida também ou b. A MV ** não é ** de REFRESH ON COMMIT, aí OBVIAMENTE qualquer operação (DML inclusive!!) deixou os dados/estrutura da mv diferentes dos dados/estrutura nas tabelas/objetos referenciados pela mv e assim causa status de invalid na mv : vide nota metalink After DML on the Master Table(s) of Local Materialized View, USER_MVIEWS.COMPILE_STATE becomes 'NEEDS_COMPILE' and USER_OBJECTS.STATUS becomes 'INVALID' (Doc ID 264036.1) ou c. os privilégios foram dados via ROLE, aí a recompilação não os rechonece : vide nota Compile Makes Materialized View Invalid When Access to Master Table Granted Via Role (Doc ID 781255.1) e variações destes temas Principalmente se não há DBA fixo nesse seu cliente, eu ** suspeitaria ** da alternativa a acima : tipicamente num caso desses é a farra do boi, neguim sai alterando tabelas a qquer minuto, sem planejar, sem saber quais objs dependem dela, e sem avisar ninguém... Mas levante a situação exata e a analise para saber exatamente o que está causando e assim poder propor um fix, que MUITO PROVAVELMENTE será de procedimento, não me parece ser ** nenhum ** tipo de BUG ou Problema Técnico no database, parece ser mesmo é erro humano ou ignorância dos Conceitos de mv... []s Chiappa -- Abraços, Mária Cristina E-mail: mariancrist...@gmail.com MSN: mcristinasil...@hotmail.com -- O começo é a parte mais importante do trabalho. - Platão
Re: [oracle_br] Re: View Materializada está ficando descompilada.
Olá Eriovaldo! A coluna FAILURES está = 0 sim, hoje eu percebi que não é mesmo refresh que a faz ficar invalida, e sim a quando ocorre algum insert ou update em alguma tabela que a view utiliza. E se você recompilar, ela fica valida novamente, porém quando ocorre alguma alteração ou inserção ela volta novamente a ficar invalida. Quanto aos dados, eu analisei e atualiza corretamente, só que o me intriga é está invalida, pois para um sistema de monitoramento que temos aqui internamente, ele nos alerta como se estivesse com se esse cliente estivesse com esse erro, sempre. Em 13 de janeiro de 2015 08:37, Eriovaldo Andrietta ecandrie...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Olá, Mária Cristina, 1.) Se você olhar a coluna user_jobs.failure e a mesma estiver com 0 (zero) significa que o refresh da mview está acontecendo sem erros e o resultado esperado está garantido. 2.) Já vi uma análise desse tipo onde esse INVALID significa que os dados deste objetos não são mais válidos, pois alguma das tabelas envolvidas foi alterada. Para comprovar isso, execute o refresh da mview e veja de imediato se ela fica válida, e logo em seguida altere alguma tabela que está na mview e veja o que acontece. Espero que isso ajude. Eriovaldo Em 13 de janeiro de 2015 07:48, Mária Cristina Silva Stricker mariancrist...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Bom dia! Agradeço as alternativas mas não tem nenhuma das suas suposições aplicadas a este caso, eu verifiquei todos os objetos que poderiam ser dependentes mas nenhum estão inválidos, simulei o ambiente criando MV minhas, criei as tabelas e criei a MV sobre essas tabelas para realizar os teste, pensando que poderia ser algo assim, porem a MV ficou invalida também, só que não pelo refresh, e sim quando insiro um valor na tabela(acabei descobrir isso, que não é pelo refresh), qualquer insert feito ou alteração realizada na tabela está deixando a MV invalida. Essas tabelas não tem dependência nenhumas, não tem problema com permissão de role, simplesmente foram criadas para fazer esse TESTE, e deu o mesmo erro. Verifiquei na Internet vi que tem muitos deste problema, mas as soluções são paleativas e não definitivas. Gostaria de saber se alguém já passou por isso e pode me orientar, pensei em ser um BUG, pois só ocorre quando a MV tem JOIN relacionados, elas funcionam normalmente, mas ficam invalidas. Agradeço atenção. Abraços a todos. Em 13 de janeiro de 2015 06:45, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Eu consigo pensar nas seguintes possibilidades : a. Qualquer um dos objetos referenciados pela mv foi alterado por DDL e/ou se tornou inválido por alterações/recompilações nas dependências deles, aí a mv fica inválida também ou b. A MV ** não é ** de REFRESH ON COMMIT, aí OBVIAMENTE qualquer operação (DML inclusive!!) deixou os dados/estrutura da mv diferentes dos dados/estrutura nas tabelas/objetos referenciados pela mv e assim causa status de invalid na mv : vide nota metalink After DML on the Master Table(s) of Local Materialized View, USER_MVIEWS.COMPILE_STATE becomes 'NEEDS_COMPILE' and USER_OBJECTS.STATUS becomes 'INVALID' (Doc ID 264036.1) ou c. os privilégios foram dados via ROLE, aí a recompilação não os rechonece : vide nota Compile Makes Materialized View Invalid When Access to Master Table Granted Via Role (Doc ID 781255.1) e variações destes temas Principalmente se não há DBA fixo nesse seu cliente, eu ** suspeitaria ** da alternativa a acima : tipicamente num caso desses é a farra do boi, neguim sai alterando tabelas a qquer minuto, sem planejar, sem saber quais objs dependem dela, e sem avisar ninguém... Mas levante a situação exata e a analise para saber exatamente o que está causando e assim poder propor um fix, que MUITO PROVAVELMENTE será de procedimento, não me parece ser ** nenhum ** tipo de BUG ou Problema Técnico no database, parece ser mesmo é erro humano ou ignorância dos Conceitos de mv... []s Chiappa -- Abraços, Mária Cristina E-mail: mariancrist...@gmail.com MSN: mcristinasil...@hotmail.com -- O começo é a parte mais importante do trabalho. - Platão -- 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
Re: [oracle_br] Re: View Materializada está ficando descompilada.
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
Re: [oracle_br] Re: View Materializada está ficando descompilada.
Bom dia! Agradeço as alternativas mas não tem nenhuma das suas suposições aplicadas a este caso, eu verifiquei todos os objetos que poderiam ser dependentes mas nenhum estão inválidos, simulei o ambiente criando MV minhas, criei as tabelas e criei a MV sobre essas tabelas para realizar os teste, pensando que poderia ser algo assim, porem a MV ficou invalida também, só que não pelo refresh, e sim quando insiro um valor na tabela(acabei descobrir isso, que não é pelo refresh), qualquer insert feito ou alteração realizada na tabela está deixando a MV invalida. Essas tabelas não tem dependência nenhumas, não tem problema com permissão de role, simplesmente foram criadas para fazer esse TESTE, e deu o mesmo erro. Verifiquei na Internet vi que tem muitos deste problema, mas as soluções são paleativas e não definitivas. Gostaria de saber se alguém já passou por isso e pode me orientar, pensei em ser um BUG, pois só ocorre quando a MV tem JOIN relacionados, elas funcionam normalmente, mas ficam invalidas. Agradeço atenção. Abraços a todos. Em 13 de janeiro de 2015 06:45, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Eu consigo pensar nas seguintes possibilidades : a. Qualquer um dos objetos referenciados pela mv foi alterado por DDL e/ou se tornou inválido por alterações/recompilações nas dependências deles, aí a mv fica inválida também ou b. A MV ** não é ** de REFRESH ON COMMIT, aí OBVIAMENTE qualquer operação (DML inclusive!!) deixou os dados/estrutura da mv diferentes dos dados/estrutura nas tabelas/objetos referenciados pela mv e assim causa status de invalid na mv : vide nota metalink After DML on the Master Table(s) of Local Materialized View, USER_MVIEWS.COMPILE_STATE becomes 'NEEDS_COMPILE' and USER_OBJECTS.STATUS becomes 'INVALID' (Doc ID 264036.1) ou c. os privilégios foram dados via ROLE, aí a recompilação não os rechonece : vide nota Compile Makes Materialized View Invalid When Access to Master Table Granted Via Role (Doc ID 781255.1) e variações destes temas Principalmente se não há DBA fixo nesse seu cliente, eu ** suspeitaria ** da alternativa a acima : tipicamente num caso desses é a farra do boi, neguim sai alterando tabelas a qquer minuto, sem planejar, sem saber quais objs dependem dela, e sem avisar ninguém... Mas levante a situação exata e a analise para saber exatamente o que está causando e assim poder propor um fix, que MUITO PROVAVELMENTE será de procedimento, não me parece ser ** nenhum ** tipo de BUG ou Problema Técnico no database, parece ser mesmo é erro humano ou ignorância dos Conceitos de mv... []s Chiappa -- Abraços, Mária Cristina E-mail: mariancrist...@gmail.com MSN: mcristinasil...@hotmail.com -- O começo é a parte mais importante do trabalho. - Platão
Re: [oracle_br] Novidade: Mais um Oracle Ace brazuca na área
Pessoal, muito obrigado, de verdade. @Chiappa, você demorou pra ser Ace, tá perdendo tempo... Terá minha indicação quando precisar ;) @Fábio, eu tinha visto sua assinatura algumas vezes, realmente ficou bem parecida... Mas sério, tentei várias alternativas, só temos 2 opções de imagens, fica difícil. Deixei super simples, Nome + título + imagem + url blog. Não tinha muito como fugir disso. Mas mudei agora pra ficar diferente, utilizei a outra imagem disponível. hehe Abs [image: photo] *Eduardo Schurtz* Oracle Ace Applications Apps Technology eduardoschurtz.com/oracle 2015-01-13 0:09 GMT-02:00 Fabio Prado fbifa...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br: Parabéns Eduardo, bom saber que o time de ACEs está crescendo no Brasil! Só não gostei da sua assinatura nova, que está parecida com a minha (brincadeirinha... )! rsrsrss []s e sucesso! *Fábio Prado* http://www.fabioprado.net/2014/01/oracle-ace-o-que-e-isso.html www.fabioprado.net Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle Em 12 de janeiro de 2015 15:22, Andre Santos andre.psantos...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Parabéns, Eduardo! [ ]'s André Em 12 de janeiro de 2015 15:01, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Parabéns pela indicação, e em breve pretendo te seguir : não na área de Applications (já trabalhei como ATG, na sub-área de EBS dentro do universo das Oracle Apps, mas a maioria esmagadora da minha experiência foi em bancos Oracle genéricos, atendendo aplicações outras)... Mas novamente parabéns pela conquista e pelo Pioneirismo...] []s Chiappa
Re: [oracle_br] Re: View Materializada está ficando descompilada.
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:SQLget 1.sql
1 -- Create table
2 create table MARIAN_TESTE
3 (
4nome VARCHAR2(10),
5id NUMBER not null
6 );
7 -- Create/Recreate primary, unique and foreign key constraints
8 alter table MARIAN_TESTE
9add constraint PK_MARIAN_TESTE primary key (ID);
10 -- Create table
11 create table MARIAN_TESTE2
12 (
13nome VARCHAR2(10),
14id NUMBER not null
15 );
16 -- Create/Recreate primary, unique and foreign key constraints
17 alter table MARIAN_TESTE2
18add constraint PK_MARIAN_TESTE2 primary key (ID);
19 -- Create table
20 create table MARIAN_TESTE3
21 (
22nome VARCHAR2(10),
23id NUMBER not null
24 );
25 -- Create/Recreate primary, unique and foreign key constraints
26 alter table MARIAN_TESTE3
27add 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- 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:SQLselect owner, mview_name, query, staleness,
last_refresh_date, stale_since, compile_state from user_mviews;
OWNERMVIEW_NAME QUERY
--
STALENESS LAST_REF STALE_SI COMPILE_STATE
--- ---
SYSTEM MV_TESTE_MARIANSELECT 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:SQLselect 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:SQLupdate MARIAN_TESTE set nome = 'STRICKER' WHERE ID = 1;
1 linha atualizada.
SYSTEM:@o11201:SQLcommit;
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:SQLselect object_name, object_type, created, last_ddl_time,
timestamp, status from user_objects where object_name='MV_TESTE_MARIAN';
OBJECT_NAMEOBJECT_TYPE CREATED LAST_DDL TIMESTAMP
STATUS
-- ---
--- ---
MV_TESTE_MARIANTABLE 13/01/15 13/01/15
2015-01-13:10:30:07 VALID
MV_TESTE_MARIANMATERIALIZED VIEW 13/01/15 13/01/15
2015-01-13:10:30:08 INVALID
SYSTEM:@o11201:SQLselect owner, mview_name, query, staleness,
last_refresh_date, stale_since, compile_state from user_mviews;
OWNERMVIEW_NAME QUERY
--
STALENESS LAST_REF STALE_SI COMPILE_STATE
--- ---
SYSTEM MV_TESTE_MARIANSELECT t.nome, t.id
FROM MARIAN_TESTE T,
Re: [oracle_br] Novidade: Mais um Oracle Ace brazuca na área
, não precisava mudar não! rsrss []s *Fábio Prado* http://www.fabioprado.net/2014/01/oracle-ace-o-que-e-isso.html www.fabioprado.net Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle Em 13 de janeiro de 2015 08:54, Eduardo Schurtz eduardo.schu...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Pessoal, muito obrigado, de verdade. @Chiappa, você demorou pra ser Ace, tá perdendo tempo... Terá minha indicação quando precisar ;) @Fábio, eu tinha visto sua assinatura algumas vezes, realmente ficou bem parecida... Mas sério, tentei várias alternativas, só temos 2 opções de imagens, fica difícil. Deixei super simples, Nome + título + imagem + url blog. Não tinha muito como fugir disso. Mas mudei agora pra ficar diferente, utilizei a outra imagem disponível. hehe Abs [image: photo] *Eduardo Schurtz* Oracle Ace Applications Apps Technology eduardoschurtz.com/oracle 2015-01-13 0:09 GMT-02:00 Fabio Prado fbifa...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br: Parabéns Eduardo, bom saber que o time de ACEs está crescendo no Brasil! Só não gostei da sua assinatura nova, que está parecida com a minha (brincadeirinha... )! rsrsrss []s e sucesso! *Fábio Prado* http://www.fabioprado.net/2014/01/oracle-ace-o-que-e-isso.html www.fabioprado.net Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle Em 12 de janeiro de 2015 15:22, Andre Santos andre.psantos...@gmail.com [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Parabéns, Eduardo! [ ]'s André Em 12 de janeiro de 2015 15:01, jlchia...@yahoo.com.br [oracle_br] oracle_br@yahoogrupos.com.br escreveu: Parabéns pela indicação, e em breve pretendo te seguir : não na área de Applications (já trabalhei como ATG, na sub-área de EBS dentro do universo das Oracle Apps, mas a maioria esmagadora da minha experiência foi em bancos Oracle genéricos, atendendo aplicações outras)... Mas novamente parabéns pela conquista e pelo Pioneirismo...] []s Chiappa
Re: [oracle_br] Re: View Materializada está ficando descompilada.
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- 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
Re: [oracle_br] Re: Erro no IMPDP
Obrigado, Alessandro irei olhar.
Att,
Emerson M. Rocha
Mobile:(11) 5054-8368E-Mail: tkz...@yahoo.com.br
Em Terça-feira, 13 de Janeiro de 2015 16:20, alexssandro0...@yahoo.com.br
[oracle_br] oracle_br@yahoogrupos.com.br escreveu:
Olá, Emerson
Nunca passei por este problema, mas dando uma procurada no metalink, encontrei
a seguinte nota 1628926.1, que fala sobre o erro que você recebeu ai.Também
pode dar uma olhada na nota 1628079.1.
Att: Alexssandro RochaDBA Oracle
#yiv9378730758 #yiv9378730758 -- #yiv9378730758ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9378730758
#yiv9378730758ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9378730758
#yiv9378730758ygrp-mkp #yiv9378730758hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9378730758 #yiv9378730758ygrp-mkp #yiv9378730758ads
{margin-bottom:10px;}#yiv9378730758 #yiv9378730758ygrp-mkp .yiv9378730758ad
{padding:0 0;}#yiv9378730758 #yiv9378730758ygrp-mkp .yiv9378730758ad p
{margin:0;}#yiv9378730758 #yiv9378730758ygrp-mkp .yiv9378730758ad a
{color:#ff;text-decoration:none;}#yiv9378730758 #yiv9378730758ygrp-sponsor
#yiv9378730758ygrp-lc {font-family:Arial;}#yiv9378730758
#yiv9378730758ygrp-sponsor #yiv9378730758ygrp-lc #yiv9378730758hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9378730758
#yiv9378730758ygrp-sponsor #yiv9378730758ygrp-lc .yiv9378730758ad
{margin-bottom:10px;padding:0 0;}#yiv9378730758 #yiv9378730758actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9378730758
#yiv9378730758activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9378730758
#yiv9378730758activity span {font-weight:700;}#yiv9378730758
#yiv9378730758activity span:first-child
{text-transform:uppercase;}#yiv9378730758 #yiv9378730758activity span a
{color:#5085b6;text-decoration:none;}#yiv9378730758 #yiv9378730758activity span
span {color:#ff7900;}#yiv9378730758 #yiv9378730758activity span
.yiv9378730758underline {text-decoration:underline;}#yiv9378730758
.yiv9378730758attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9378730758 .yiv9378730758attach div a
{text-decoration:none;}#yiv9378730758 .yiv9378730758attach img
{border:none;padding-right:5px;}#yiv9378730758 .yiv9378730758attach label
{display:block;margin-bottom:5px;}#yiv9378730758 .yiv9378730758attach label a
{text-decoration:none;}#yiv9378730758 blockquote {margin:0 0 0
4px;}#yiv9378730758 .yiv9378730758bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9378730758
.yiv9378730758bold a {text-decoration:none;}#yiv9378730758 dd.yiv9378730758last
p a {font-family:Verdana;font-weight:700;}#yiv9378730758 dd.yiv9378730758last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9378730758
dd.yiv9378730758last p span.yiv9378730758yshortcuts
{margin-right:0;}#yiv9378730758 div.yiv9378730758attach-table div div a
{text-decoration:none;}#yiv9378730758 div.yiv9378730758attach-table
{width:400px;}#yiv9378730758 div.yiv9378730758file-title a, #yiv9378730758
div.yiv9378730758file-title a:active, #yiv9378730758
div.yiv9378730758file-title a:hover, #yiv9378730758 div.yiv9378730758file-title
a:visited {text-decoration:none;}#yiv9378730758 div.yiv9378730758photo-title a,
#yiv9378730758 div.yiv9378730758photo-title a:active, #yiv9378730758
div.yiv9378730758photo-title a:hover, #yiv9378730758
div.yiv9378730758photo-title a:visited {text-decoration:none;}#yiv9378730758
div#yiv9378730758ygrp-mlmsg #yiv9378730758ygrp-msg p a
span.yiv9378730758yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9378730758
.yiv9378730758green {color:#628c2a;}#yiv9378730758 .yiv9378730758MsoNormal
{margin:0 0 0 0;}#yiv9378730758 o {font-size:0;}#yiv9378730758
#yiv9378730758photos div {float:left;width:72px;}#yiv9378730758
#yiv9378730758photos div div {border:1px solid
#66;height:62px;overflow:hidden;width:62px;}#yiv9378730758
#yiv9378730758photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9378730758
#yiv9378730758reco-category {font-size:77%;}#yiv9378730758
#yiv9378730758reco-desc {font-size:77%;}#yiv9378730758 .yiv9378730758replbq
{margin:4px;}#yiv9378730758 #yiv9378730758ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv9378730758 #yiv9378730758ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv9378730758
#yiv9378730758ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv9378730758
#yiv9378730758ygrp-mlmsg select, #yiv9378730758 input, #yiv9378730758 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv9378730758
#yiv9378730758ygrp-mlmsg pre, #yiv9378730758 code {font:115%
monospace;}#yiv9378730758 #yiv9378730758ygrp-mlmsg *
{line-height:1.22em;}#yiv9378730758 #yiv9378730758ygrp-mlmsg #yiv9378730758logo
