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
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.
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.
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
[oracle_br] View Materializada está ficando descompilada.
Boa Tarde! Pessoal, estou com um problema em um cliente, onde todas a views materializadas, quando sofrem o refresh, elas ficam descompiladaspesquisei na internet e no metalink não achei nada que resolva o problema, achei uma nota de Bug, porém muito antiga do 8i e 9i, alguém já teve esse problema e sabe me orientar como resolve-lo? A versão do banco é 11.2.0.3.0. Agradeço atenção. -- Abraços, Mária Cristina Stricker E-mail: mariancrist...@gmail.com MSN: mcristinasil...@hotmail.com -- O começo é a parte mais importante do trabalho. - Platão
[oracle_br] Erro na Versão 10G
Boa Tarde! Pessoal estou realizando seguinte Update, e o mesmo na Versão 10G, não funciona da erro de: *Runtime error occurred: 907 (ORA-00907: missing right parenthesis)* Na versão 11G o mesmo update, funciona normalmente, sem o erro. *UPDATE tabela SET coluna = RAWTOHEX(DBMS_OBFUSCATION_TOOLKIT.MD5(UTL_RAW.CAST_TO_RAW('T')))WHERE Upper(LTrim(RTrim(coluna))) = 'B'* Alguém sabe me dizer se na versão 10G os pacotes DBMS_OBFUSCATION_TOOLKIT e UTL_RAW precisam de algum complemento, testei com vários usuários inclusive logada com Sys e não funciona. -- 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: Erro na Versão 10G
Ta joia.. Vamos lá.. Teste essa função em qualquer versão do 11 G ou do 10 g Você vai ver que na versão do 10g não executa e dá o erro que informei... Create table TAB_TESTE ( SENHA VARCHAR2(100) ) INSERT INTO TAB_TESTE VALUES('teste'); COMMIT; UPDATE TESTE SET SENHA = RAWTOHEX(DBMS_OBFUSCATION_TOOLKIT.MD5(INPUT = UTL_RAW.CAST_TO_RAW('TESTE123'))) WHERE Upper(LTrim(RTrim(USUARIOBD))) = 'teste'; Em 9 de janeiro de 2014 13:05, jlchia...@yahoo.com.br escreveu: Bom, antes de responder uma obs : na verdade vc *** nunca deve testar nada como SYS, pois esse usuário pode se comportar DIFERENTE de outros, não é sujeito á diversas regras dentro do database... Considere-o de USO INTERNO, só se conecta como SYS realmente para fazer manutenção no database... A resposta : não, afaik tanto a função MD5 dentro da package DBMS_OBFUSCATION_TOOLKIT quanto a CAST_TO_RAW dentro da UTL_RAW não tiveram sintaxe/funcionalidades alteradas nem para 10g nem para 11g, assim pra mim o que pode estar acontecendo aí é que : a. vc tem propriedades físicas (tal como tamanho de coluna/datatypes/byte order, etc) diferentes nas tabelas criadas no 10g e no 11g ou b. vc está tendo algum tipo de conversão implícita, e aí (óbvio) as regras de conversão implícita PODEM e MUDAM mesmo entre releases ou c. vc tem propriedades referentes à strings (como CHARACTERSET) diferentes entre os databases 10g e 11g ou d. o menos provável mas PODE acontecer : vc encontrou um BUG nessa versão de 10g, corrigido na 11g... == para a gente poder palpitar melhor e reproduzir, PLEASE : 1. nos dê o release/versão ** exatos ** de AMBOS os databases, e dos SOs envolvidos, bem como a configuração NLS (de database E da sessão conectada executando a rotina) de ambos os RDBMSs 2. nos dê um caso reproduzível, incluindo um CREATE TABLE, uns INSERTs para popular e o UPDATE que vc quer fazer []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 na Versão 10G
Sim, eu já fiz isso, já sugeri para a Empresa responsável pela aplicação, coloca-la em uma função.. Só queria mesmo confirmar se na versão do 10g realmente não funcionava. Mas eu agradeço atenção mais uma vez. Em 9 de janeiro de 2014 14:31, jlchia...@yahoo.com.br escreveu: Dá um look em http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:2886797089063#56097322102839, onde o autor diz que na ocasião não era aceita sintaxe de passagem de parâmetros nomeada (com =) dentro dum comando SQL qualquer, INCLUSIVE dando erro de missing right parenthesis, que nem vc teve... Não é nada impossível que essa limitação tenha sido limada no SQL engine do 11g Como work-arodund no 10g se for esse o caso, Experimenta encapsular essa lógica num bloco PL/SQL, jogando o resultado da chamada às funções para variáveis locais e fazendo o UPDATE tabelas SET coluna = variavellocal []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: Curso DBA [OCA - OCP]
Olá! Na Puc - Minas tem pós em Banco de Dados. 2012/1/24 Samuel Santos samuel.gsan...@yahoo.com.br ** Alguem saberia me informar de alguma PÓS-Graduação em BH/MG em Banco de Dados? Olá Eduardo se vc é do Rio de Janeiro eu recomendo o curso na COTI INFORMATICA (Av Rio Branco 185 sl901, Centro) --- Em oracle_br@yahoogrupos.com.br, Eduardo Rodrigues oraeduardo@ ... escreveu Boa Tarde, Pessoal. Sou desenvolvedor PL/SQL atualmente, mas gostaria de me especializar como DBA. Não tenho nenhum curso Oracle ainda. Quais cursos são recomendados e quais instituições? Obrigado *Eduardo Rodrigues* [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] -- 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 [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ Links do Yahoo! Grupos * Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ * Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html