Re: [oracle_br] Re: Fechando e abrindo cursor

2017-02-09 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Sim, mas olha o resto da frase (ênfase com *s minha) :

"Earlier releases of Oracle Database default to manual undo management mode. To 
change to automatic undo management, you must first create an undo tablespace 
and then change the *** UNDO_MANAGEMENT initialization parameter *** to AUTO."

Com esse resto da frase fica Claro imho que ele está se referindo ao ** 
PARÂMETRO ** UNDO_MANAGEMENT O que eles podiam ter deixado mais claro é que 
a referência ao manual de Migration é simplesmente para Apontar/Referenciar 
eventuais side effects da mudança, mas o procedimento técnico para mudar é 
Apenas e Tão Somente esse mesmo indicado, ie, cria uma tablespace de UNDO e 
muda o parâmetro de UNDO_MANAGEMENT, só isso 

 E no caso, mesmo não tenho uma instalação 9i por perto (E também  não tendo um 
DBCA 9i pra criar um banco 9i) a Documentação das versões antigas tá bonitinha 
lá aqruivada no site da Oracle, sendo que eu até dei a URL : nela (como eu fiz) 
vc consultaria e veria que existe SIM os dois procedimentos técnicos indicados 
para passar a usar AUTOMATIC UNDO, ie, a criação de tablespace de UNDO e a 
mudança do parãmetro
 
 []s
 
   Chiappa

Re: [oracle_br] Re: Fechando e abrindo cursor

2017-02-09 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
Chiappa,
 Earlier releases of Oracle Database default to manual undo management mode. 
  Entendo que a frase se refere ao "Oracle Database" como um todo, e não só ao 
parâmetro. Mas sinceramente não me lembro mais como isso ficava ao rodar o DBCA 
da 10g, quanto mais da 9i...
   E não tenho um DBCA dessas versões velhas aqui para testar,
   Agora, tenho certeza que ambas suportam sim o Automatic Undo Management, e 
que houve uma mudança no comportamento do parametro na 11g, mas isso não 
costuma causar problemas, sendo apenas um detalhe para ver no upgrade.
Atc,Luis Freitas 

On Thursday, February 9, 2017 6:32 PM, "jlchia...@yahoo.com.br [oracle_br]" 
 wrote:
 

     A sua interpretação tá errada, talvez o Inglês não tenha deixado Claro pra 
vc : o que está sendo dito é que o *** PARÂMETRO ***, a CONFIG de 
UNDO_MANAGEMENT em versões anteriores Não era AUTO, mas em *** LUGAR NENHUM ** 
ele diz que vc está Proibido de colocar como AUTO, isso só não é o Padrão...Se 
vc olhar a Documentação Oficial do 9iR2 (online em 
https://docs.oracle.com/cd/B10501_01/server.920/a96521/undo.htm) vc vai ver 
Exatamente Isso , ie, que o parâmetro UNDO_MANAGEMENT ** TEM ** que ser ativado 
diretamente pelo dba (não é default) MAS existe SIM no 9iR2, sim sim sim  
Foi EXATAMENTE o que eu disse...

Sobre o seu outro ponto, sim : eu ABSOLUTAMENTE NÃO CONCORDO, não ENTENDO que 
que um assunto total e completamente ** TÉCNICO ** como é a configuração e 
Otimização de um banco de dados esteja sujeito a "políticas" da Empresa (isso 
não faz o Menor Sentido) mas concordo que vc até pode achar alguma situação 
Esdrúxula do tipo A tua Obrigação como técnico é fazer a Exigência técnica, 
recomendar o BEST PRACTICE, mas se o cliente não pode/não que a implementar, 
problema dele... 
 O que vc Não Pode imho é penalizar os outros TODOS clientes que obedeceram à 
sua Recomendação e estão portanto configurados para a melhor performance e vc 
não se aproveitar disso por causa de uma ou outra alma penada que não... No 
máximo vc deixe claro que se por qualquer motivo (alguma política esdrúxula, 
algum gerente idiota, o que for) o Cliente não usar a Configuração ótima 
exigida e recomendada aí vcs vão aplicar algum work-around mas SEM COMPROMISSO 
ALGUM É o que eu faria...
 
 []s
 
   Chiappa  #yiv0594376926 #yiv0594376926 -- #yiv0594376926ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0594376926 
#yiv0594376926ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0594376926 
#yiv0594376926ygrp-mkp #yiv0594376926hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv0594376926 #yiv0594376926ygrp-mkp #yiv0594376926ads 
{margin-bottom:10px;}#yiv0594376926 #yiv0594376926ygrp-mkp .yiv0594376926ad 
{padding:0 0;}#yiv0594376926 #yiv0594376926ygrp-mkp .yiv0594376926ad p 
{margin:0;}#yiv0594376926 #yiv0594376926ygrp-mkp .yiv0594376926ad a 
{color:#ff;text-decoration:none;}#yiv0594376926 #yiv0594376926ygrp-sponsor 
#yiv0594376926ygrp-lc {font-family:Arial;}#yiv0594376926 
#yiv0594376926ygrp-sponsor #yiv0594376926ygrp-lc #yiv0594376926hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0594376926 
#yiv0594376926ygrp-sponsor #yiv0594376926ygrp-lc .yiv0594376926ad 
{margin-bottom:10px;padding:0 0;}#yiv0594376926 #yiv0594376926actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0594376926 
#yiv0594376926activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0594376926
 #yiv0594376926activity span {font-weight:700;}#yiv0594376926 
#yiv0594376926activity span:first-child 
{text-transform:uppercase;}#yiv0594376926 #yiv0594376926activity span a 
{color:#5085b6;text-decoration:none;}#yiv0594376926 #yiv0594376926activity span 
span {color:#ff7900;}#yiv0594376926 #yiv0594376926activity span 
.yiv0594376926underline {text-decoration:underline;}#yiv0594376926 
.yiv0594376926attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv0594376926 .yiv0594376926attach div a 
{text-decoration:none;}#yiv0594376926 .yiv0594376926attach img 
{border:none;padding-right:5px;}#yiv0594376926 .yiv0594376926attach label 
{display:block;margin-bottom:5px;}#yiv0594376926 .yiv0594376926attach label a 
{text-decoration:none;}#yiv0594376926 blockquote {margin:0 0 0 
4px;}#yiv0594376926 .yiv0594376926bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv0594376926 
.yiv0594376926bold a {text-decoration:none;}#yiv0594376926 dd.yiv0594376926last 
p a {font-family:Verdana;font-weight:700;}#yiv0594376926 dd.yiv0594376926last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0594376926 
dd.yiv0594376926last p span.yiv0594376926yshortcuts 
{margin-right:0;}#yiv0594376926 div.yiv0594376926attach-table div div a 
{text-decoration:none;}#yiv0594376926 div.yiv0594376926attach-table 
{width:400px;}#yiv0594376926 div.yiv0594376926file-title a,

Re: [oracle_br] Re: Fechando e abrindo cursor

2017-02-09 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
A sua interpretação tá errada, talvez o Inglês não tenha deixado Claro pra vc : 
o que está sendo dito é que o *** PARÂMETRO ***, a CONFIG de UNDO_MANAGEMENT em 
versões anteriores Não era AUTO, mas em *** LUGAR NENHUM ** ele diz que vc está 
Proibido de colocar como AUTO, isso só não é o Padrão...Se vc olhar a 
Documentação Oficial do 9iR2 (online em 
https://docs.oracle.com/cd/B10501_01/server.920/a96521/undo.htm) vc vai ver 
Exatamente Isso , ie, que o parâmetro UNDO_MANAGEMENT ** TEM ** que ser ativado 
diretamente pelo dba (não é default) MAS existe SIM no 9iR2, sim sim sim  
Foi EXATAMENTE o que eu disse...

Sobre o seu outro ponto, sim : eu ABSOLUTAMENTE NÃO CONCORDO, não ENTENDO que 
que um assunto total e completamente ** TÉCNICO ** como é a configuração e 
Otimização de um banco de dados esteja sujeito a "políticas" da Empresa (isso 
não faz o Menor Sentido) mas concordo que vc até pode achar alguma situação 
Esdrúxula do tipo A tua Obrigação como técnico é fazer a Exigência técnica, 
recomendar o BEST PRACTICE, mas se o cliente não pode/não que a implementar, 
problema dele... 
 O que vc Não Pode imho é penalizar os outros TODOS clientes que obedeceram à 
sua Recomendação e estão portanto configurados para a melhor performance e vc 
não se aproveitar disso por causa de uma ou outra alma penada que não... No 
máximo vc deixe claro que se por qualquer motivo (alguma política esdrúxula, 
algum gerente idiota, o que for) o Cliente não usar a Configuração ótima 
exigida e recomendada aí vcs vão aplicar algum work-around mas SEM COMPROMISSO 
ALGUM É o que eu faria...
 
 []s
 
   Chiappa

[oracle_br] Re: crfclus.bdb

2017-02-09 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Bem, antes de mais nada fique ciente que há alguns bugs que causam esse 
crescimento dos arquivos de cluster health muito acima do limite (por exemplo o 
bug Bug 10165314), ** E ** normalmente já há BUGFIX pra eles : então, o 
procedimento CORRETO e RECOMENDADO é vc aplicar o patch adequado, e não ficar 
"correndo atrás do rabo" aplicando contronos ao invés de Eliminar o problema
 SE/ENQUANTO vc não identificou o bug e não aplica o patch que contém o bugfix 
correto, sim, é basicamente esse o procedimento de 
CONTRONO/QUEBRA-GALHO/WORKAROUND que se aplica : única coisa é que o "oclumon 
manage -get reppath"  NÃO SERVE *** para verificar status do serviço , pra 
averificar status são os comandos de status do próprio crsctl , o oclumon 
manage -get reppath te dá o PATH sendo usado pelo ochm...

Quanto ao banco não : como esses arquivos Não Fazem parte do banco de dados, 
rigorosamente não tem como a ausência deles influenciar no banco em si, causar 
qquer problema - o que eles se relacionam é com o CLUSTER, então um erro de 
procedimento nessa remoção de arquivos pode corromper/influenciar é o seu 
Cluster naõ o banco em si

[]s

  Chiappa

Re: [oracle_br] Re: Fechando e abrindo cursor

2017-02-09 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
Roberto, 
  Entendo que o que está dizendo ai é que na versão 9i e 10g o dbca não ativa o 
automatic undo por padrão, sendo necessário fazer isso após a criação do banco 
de dados. E ele está indicando que nesse manual de upgrade tem um procedimento 
para se fazer isso. 
   E está alertando também que na 11g se não configurar os parâmetros o 
comportamento é diferente do que acontecia na 9i e 10g. 
   Mas tá bem confuso o texto, tanto ai, como no tal manual de upgrade que ele 
indica, rs.
  Não é necessário fazer o upgrade, tanto a 9i como 10g tem o recurso de 
automatic undo management, e a maior parte dos DBAs que conheço que trabalhavam 
com essas versões já ligava isso logo após a criação do banco de dados, pois 
esse erro do "Snapshot too old" era bem chato, acontecia nas piores horas.
   O que aparece por ai são bancos que foram atualizados de versões antigas, 
como 8i, 8.0 ou mais velhas, e o DBA não habilitou o "automatic undo 
management" depois do upgrade, ou não migrou os tablespaces para "local extent 
management", ou não recriou a TEMP como "temporary tablespace", entre outras 
surpresas...
Atc,Luis Freitas
 

On Thursday, February 9, 2017 3:16 PM, "Roberto Warstat 
ro.wars...@gmail.com [oracle_br]"  wrote:
 

     Retomando o assunto, sim, esse script é como se fosse a aplicação de um 
PATCH. O nosso problema é que dizemos para os clientes como eles devem 
proceder, mas eles fazem do jeito deles e quando algo dá errado, nós é que 
temos que dar um jeito.
Estamos analisando de recomendar para os clientes que eles ativem o 
gerenciamento automático de UNDO - não podemos exigir, pois cada cliente tem a 
sua política e alguns são subordinados à matriz lá fora, sendo que eles não tem 
poder de decisão.Foi dito aqui que desde a versão 9i existe o gerencimento 
automático de UNDO, mas lendo o Guia de Administração do 11.1 
(https://docs.oracle.com/cd/B28359_01/server.111/b28310/undo002.htm#ADMIN10180) 
consta o seguinte,
Earlier releases of Oracle Database default to manual undo management mode. To 
change to automatic undo management, you must first create an undo tablespace 
and then change the UNDO_MANAGEMENT initialization parameter to AUTO. If your 
Oracle Database is release 9i or later and you want to change to automatic undo 
management, see Oracle Database Upgrade Guide for instructions.

Pelo que entendo, se estiver em uma versão 9i ou 10g é necessário fazer o 
upgrade para o 11g.Seria isso mesmo ou a minha interpretação foi errada?
[]´sRoberto
Em 7 de fevereiro de 2017 08:28, jlchia...@yahoo.com.br [oracle_br] 
 escreveu:

     Sim, certamente se vc está fazendo a leitura com COMMIT parcial (o melhor 
seria COMMIT por *** TEMPO **, ie, COMMIT a cada X minutos cfrme 
https://asktom.oracle.com/pls/ asktom/f?p=100:11:0P11_ 
QUESTION_ID:4951966319022 mas enfim) sim, vc diminui Enormemente a chance de 
UNDO necessário para consistência do SELCT não estar mais presente, não faz 
sentido vc além disso fechar e reabrir Cursor EVIDENTEMENTE, como eu disse 
e a esta altura está mais que claro, vc está 'comprando' essa menor chance de 
ORA-1555 a um ALTO CUSTO para a performance (vide o mesmo link que indiquei) 
mas tá... Uma Recomendação que eu faria é que vc tenha um DBA *** experiente ** 
, que tenha usado até o 9i, te ajudando nessa tarefa E que imponha uma mínima 
Exigência de tamanho de UNDO pros seus clientes, E também de configuração  : 
desde o 9i (9iR2 iirc) já existe ** sim ** a possibilidade de UNDO automático, 
de UNDO_RETENTION...

 Eu ** acho ** que da mesma maneira que outras softhouses exigem X Gbs de RAM , 
Y Gbs livres em disco, etc, pra usarem seus sistemas, vcs deveriam Pensar nisso 
também... 

 []s
 
   Chiappa
   
OBS : é importante FRISAR que vc só obtém ORA-1555 ** se ** há Outras 
Transações concorrendo/usando UNDO - pelo que entendi esse script é tipo 
aplicação de um PATCH (ie, algo EVENTUAL e não-frequente), então nada impede 
que vcs Exijam dos clientes que eles rodem isso no horário de MENOR 
concorrência (talvez à noite, tipo), de modo a ter AINDA MAIS UMA camada de 
segurança contra ORA-1555   

  #yiv6349233608 #yiv6349233608 -- #yiv6349233608ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6349233608 
#yiv6349233608ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6349233608 
#yiv6349233608ygrp-mkp #yiv6349233608hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv6349233608 #yiv6349233608ygrp-mkp #yiv6349233608ads 
{margin-bottom:10px;}#yiv6349233608 #yiv6349233608ygrp-mkp .yiv6349233608ad 
{padding:0 0;}#yiv6349233608 #yiv6349233608ygrp-mkp .yiv6349233608ad p 
{margin:0;}#yiv6349233608 #yiv6349233608ygrp-mkp .yiv6349233608ad a 
{color:#ff;text-decoration:none;}#yiv6349233608 #yiv6349233608ygrp-sponsor 
#yiv6349233608ygrp-lc {font-family:Arial;}#yiv6349233608 
#yiv6349233608ygrp-sponsor #yiv6349233608ygrp-lc

Re: [oracle_br] crfclus.bdb

2017-02-09 Por tôpico Rodrigo Mufalani rodr...@mufalani.com.br [oracle_br] 
Boa tarde,

   Em um ambiente RAC 11.2.0.4 eu segui com os seguintes passos:


Como root:



crsctl status resource

/u01/app/11.2.0/grid/bin/crsctl stop res ora.crf –init
cd /u01/app/11.2.0/grid/crf/db/$HOST
rm *.bdb
/u01/app/11.2.0/grid/bin/crsctl start res ora.crf -init



Obs.: Verifique os caminhos do seu ambiente. Onde tem $HOST será o nome das 
suas máquinas.


Atenciosamente,

Rodrigo Mufalani - Diretor Técnico | 
rodr...@mufalani.com.br | +55 21 988 994 817
Mufalani - +55 21 3193 0326 | Rua Alm Grenfall, 405, Bl 3, Sl 310, Centro 
Empresarial
Washington Luiz, Duque de Caxias, RJ | CEP 25085-009 | 
www.mufalani.com.br
[X][X]


De:  em nome de "palomacbarb...@yahoo.com.br 
[oracle_br]" 
Responder para: "oracle_br@yahoogrupos.com.br" 
Data: quinta-feira, 9 de fevereiro de 2017 15:10
Para: "oracle_br@yahoogrupos.com.br" 
Assunto: [oracle_br] crfclus.bdb



Caros, boa tarde.



Oracle 11.2.0.4 Standard RAC 2 nós

Linux RedHat 5.7







Verifiquei que existe um arquivo chamado "crfclust.bdb" que hoje esta 
consumindo 100G de uma partição.

Em pesquisas verifiquei que indicam o procedimento abaixo para a limpeza:



Verificar o status do serviço antes do procedimento

$oclumon manage -get reppath



Parar o serviço

$crsctl stop res ora.crf -init



Deletar os arquivos

$rm *.bdb



Startar o serviço

$crsctl start res ora.crf -init



Verificar o status do serviço após o procedimento

$oclumon manage -get reppath





Alguém saberia me informar se esse procedimento está correto? E se isso pode 
afetar de alguma forma o banco?







Abraços,

Paloma Cristina Barbosa

Re: [oracle_br] Re: Fechando e abrindo cursor

2017-02-09 Por tôpico Roberto Warstat ro.wars...@gmail.com [oracle_br] 
Retomando o assunto, sim, esse script é como se fosse a aplicação de um
PATCH. O nosso problema é que dizemos para os clientes como eles devem
proceder, mas eles fazem do jeito deles e quando algo dá errado, nós é que
temos que dar um jeito.

Estamos analisando de recomendar para os clientes que eles ativem o
gerenciamento automático de UNDO - não podemos exigir, pois cada cliente
tem a sua política e alguns são subordinados à matriz lá fora, sendo que
eles não tem poder de decisão.
Foi dito aqui que desde a versão 9i existe o gerencimento automático de
UNDO, mas lendo o Guia de Administração do 11.1 (
https://docs.oracle.com/cd/B28359_01/server.111/b28310/undo002.htm#ADMIN10180)
consta o seguinte,

*Earlier releases of Oracle Database default to manual undo management
mode. To change to automatic undo management, you must first create an undo
tablespace and then change the UNDO_MANAGEMENT initialization parameter to
AUTO. If your Oracle Database is release 9i or later and you want to change
to automatic undo management, see Oracle Database Upgrade Guide for
instructions.*

Pelo que entendo, se estiver em uma versão 9i ou 10g é necessário fazer o
upgrade para o 11g.
Seria isso mesmo ou a minha interpretação foi errada?

[]´s
Roberto

Em 7 de fevereiro de 2017 08:28, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Sim, certamente se vc está fazendo a leitura com COMMIT parcial (o melhor
> seria COMMIT por *** TEMPO **, ie, COMMIT a cada X minutos cfrme
> https://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_
> QUESTION_ID:4951966319022 mas enfim) sim, vc diminui Enormemente a chance
> de UNDO necessário para consistência do SELCT não estar mais presente, não
> faz sentido vc além disso fechar e reabrir Cursor EVIDENTEMENTE, como
> eu disse e a esta altura está mais que claro, vc está 'comprando' essa
> menor chance de ORA-1555 a um ALTO CUSTO para a performance (vide o mesmo
> link que indiquei) mas tá... Uma Recomendação que eu faria é que vc tenha
> um DBA *** experiente ** , que tenha usado até o 9i, te ajudando nessa
> tarefa E que imponha uma mínima Exigência de tamanho de UNDO pros seus
> clientes, E também de configuração  : desde o 9i (9iR2 iirc) já existe **
> sim ** a possibilidade de UNDO automático, de UNDO_RETENTION...
>
>  Eu ** acho ** que da mesma maneira que outras softhouses exigem X Gbs de
> RAM , Y Gbs livres em disco, etc, pra usarem seus sistemas, vcs deveriam
> Pensar nisso também...
>
>  []s
>
>Chiappa
>
> OBS : é importante FRISAR que vc só obtém ORA-1555 ** se ** há Outras
> Transações concorrendo/usando UNDO - pelo que entendi esse script é tipo
> aplicação de um PATCH (ie, algo EVENTUAL e não-frequente), então nada
> impede que vcs Exijam dos clientes que eles rodem isso no horário de MENOR
> concorrência (talvez à noite, tipo), de modo a ter AINDA MAIS UMA camada de
> segurança contra ORA-1555
> 
>

[oracle_br] crfclus.bdb

2017-02-09 Por tôpico palomacbarb...@yahoo.com.br [oracle_br] 
Caros, boa tarde. 

 

 Oracle 11.2.0.4 Standard RAC 2 nós
 Linux RedHat 5.7
 

 

 

 Verifiquei que existe um arquivo chamado "crfclust.bdb" que hoje esta 
consumindo 100G de uma partição.
 Em pesquisas verifiquei que indicam o procedimento abaixo para a limpeza:

 

 Verificar o status do serviço antes do procedimento
 $oclumon manage -get reppath
 

 Parar o serviço
 $crsctl stop res ora.crf -init
 

 Deletar os arquivos
 $rm *.bdb
 

 Startar o serviço
 $crsctl start res ora.crf -init
 

 Verificar o status do serviço após o procedimento
 $oclumon manage -get reppath
 

 

 Alguém saberia me informar se esse procedimento está correto? E se isso pode 
afetar de alguma forma o banco?
 

 

 

 Abraços,
 Paloma Cristina Barbosa

[oracle_br] Baixo custo para aprender de verdade

2017-02-09 Por tôpico Raul Francisco DBA raul...@hotmail.com [oracle_br] 
Olá pessoal, este email é bem breve, apenas para convidar todos que ainda não 
conhecem para conhecer o projeto DBA.
Trata-se de algo que criei pensando em ajudar quem tem vontade de aprender, se 
aprimorar, alavancar a carreira porém não tem muita grana para investir, ou não 
tem tempo para cursos regulares.

Durante muito tempo como instrutor descobri que alunos tem necessidades que 
somente um curso voltado especial, com suporte e contato mesmo após o término, 
pode proporcionar.

Sendo assim, tenho imenso prazer que visite a área de cursos do Projeto DBA.
www.rauldba.com.br/cursos
Estamos com cursos:
Formação DBA Jr;
Fundamentos de SQL;
Tuning de Banco de Dados;
(NOVO em pré-lançamento)

Veja o comentário de alguns alunos em: http://www.rauldba.com.br/review/

Especialmente para os leitores deste email estou dando um desconto de 10% para 
qualquer curso, basta usar o cupom: dbabr10

Aproveite! Faça como tantos estão fazendo!

Se ainda tiver qualquer dúvida me manda um email, ou whatApp para os contatos 
abaixo.


Grande abraço!


---
Raul Francisco da Costa Ferreira Andrade:.
DBA - OCP - Oracle Certified Professional.
Consultor de Tecnologia da Informação.
Oracle Official Instructor
Celular:(48) 99173-8708 – Vivo
skype:raul.andrade
email: r...@rauldba.com.br
Visite: www.rauldba.com.br
--