Re: [oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 { Urgente }
Chiappa, bom dia! Grato pelas informações.
Eu me expressei mal, realmente o plano de execução mudou, com algumas
parametrizações que fiz ontem o problema foi amenizado, porem não resolvido.
O problema se concentra basicamente em um select, o mesmo faz acesso a uma
view com ANSI Join, notei que o mesmo utiliza algumas variáveis bind e
algumas literais, não sei bem o motivo. Apenas para entendimento eu não
trabalho na empresa em questão, minha consultoria tem um contrato de hora
mensais para eventuais problemas, porem eu não atuo neste ambiente somente
em caso de problemas, por este motivo tenho pouco conhecimento das
aplicações.
Antes da aplicação do patch eu verifiquei o doc 1087991.1, não encontrei
nenhum problema que se encaixasse no ambiente.
Neste momento estou com um chamado na Oracle, prioridade 1, eles solicitaram
a execução do SQLT para verificar as informações do select problemático.
Grato pela ajuda, assim que tiver alguma resposta da Oracle, posto para
ficar documentado.
ABS.
--
R.P.
DBA Oracle
Oracle Database 11g Administrator Certified Professional
Oracle Database 10g Real Applications Clusters AdministratorCertified Expert
Oracle Enterprise Linux Certified Implementation Specialist
Oracle Database 11g Administrator Certified Associate
From: José Laurindo jlchia...@yahoo.com.br
Reply-To: oracle_br@yahoogrupos.com.br
Date: Tue, 12 Jul 2011 23:47:41 -
To: oracle_br@yahoogrupos.com.br
Subject: [oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 {
Urgente }
..., acredito que tenham alterado os planos de execução dos SQLs.
ESTA é a parte que deve estar te complicando : vc DEVERIA ser totalmente
capaz de responder isso, é Mais que recomendado se manter arquivado os
Planos de execução (dos principais SQLs ao menos) , não só antes de Qualquer
patch mas Rotineiramente... Não o tendo feito, vc vai estar no escuro, não é
de forma alguma um procedimento recomendado/recomendável
O que vc pode tentar fazer nesta situação atual é :
a. (** SE ** vc tem AWR ativado e ** SE ** vc tem acesso/licença pra isso, e
** SE ** o upgrade foi recente e vc ainda tem os snapshots presentes ) é
buscar nas tabelas do histórico do AWR (ie, DBA_HIST_SQLTEXT e
DBA_HIST_SQL_PLAN) e ver se encontra pra ao menos alguns casos principais /
importantes os planos de antes do upgrade e comparar com os planos atuais
b. tentar buscar nas tabs/views do ASH (ie,
v$active_sess_hist/dba_hist_active_sess_history , dba_hist_sys_time_model,
v$event_histogram, v$active_sess_hist view, wrh$active_session_history) um
histórico de estatísticas do sistema e de sessões, pra comparar com o que vc
tem hoje, assim confirmando ou negando teu diagnóstico de I/O excessivo
c. consultar no metalink a nota 10.2.0.5 Patch Set - Availability and Known
Issues (Doc ID 1087991.1) e ver se vc est´[a caindo num dos casos
conhecidos
d. analisar pela V$SQL os SQLs mais consumidores de recursos e ver se eles
tem alguma característica em comum (por exemplo, na maioria dos casos usam
ANSI JOIN, não usam BIND variables, etc, etc) : a idéia aqui é tentar cercar
a causa de comportamento dos SQLs
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br
, R P pradelarf@... escreveu
Senhores, boa noite!
Este final de semana atualizei um o patch e um CPU de um banco de dados, após
isto estou enfrentando sérios problemas de performance, segue descrição do
ambiente:
SO: Oracle Enterprise Linux 5.3 64bit
RBMS: 10.2.0.5 + PSU Abril 2011 Anteriormente era 10.2.0.4 PSU October
2009.
Single Instance. Standand Edition.
Após a aplicação destes Patches o I/O do servidor aumentou muito, acredito que
tenham alterado os planos de execução dos SQLs.
Durante a aplicação do patch o único parâmetro alterado foi o COMPATIBLE de
10.2.0.4 para 10.2.0.5.
Devido a estes problemas, hoje e ontem durante o dia fiz testes com vários
parâmetros, porem nenhum apresentou o resultado esperado. Segue o que foi
alterado:
_GBY_Hash_Aggregation_Enabled=FALSE ID:7612454.8
_fix_control='7345484:off' - ID: 567171.1
optimizer_features_enable estava em 10.2.0.4, tentei setar para 9.2.0.8 e
10.2.0.5, porem não resolveu meu problema, então voltei para 10.2.0.4.
No aguardo de alguma ajuda.
--
R.P.
DBA Oracle
Oracle Database 11g Administrator Certified Professional
Oracle Database 10g Real Applications Clusters AdministratorCertified Expert
Oracle Enterprise Linux Certified Implementation Specialist
Oracle Database 11g Administrator Certified Associate
[As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 { Urgente }
Ah sim, agora tá melhor explicado : uma coisa é dizer que tá mal genericamente,
que o problema é um consumo de I/O geral maior, outra é ter cercado e
localizado o problema...
okdoc, se vc cercou/localizou e se refere à view com ANSI join, não deixe de
verificar bugs e issues sobre isso : na verdade há diversas situações de
diferença de otimização ao se usar ANSI join - em tese deveria ser
rigorosamente o mesmo que usar a sintaxe antiga mas nem sempre isso ocorre ,
como mostrado em http://www.dbaportal.eu/?q=node/183 e
http://hoopercharles.wordpress.com/2010/12/30/ansi-full-outer-join-ready-or-not/
... Não deixe de sinalizar isso para o Analista que está te atendendo, pois já
são de conhecimento alguns bugs com ANSI joins só resolvidos no 11g, como o Bug
9395765 - ORA-907 / wrong plan from query with ANSI FULL OUTER join [ID
9395765.8] e o Bug 9236988 Suboptimal execution plans with ANSI joins, views
and fix for bug 7345484 enabled, por exemplo
Outro ponto que o Analista que está te atendendo tem TOTAL OBRIGAÇÃO de dizer
se cabe ou não é que há Diversos parâmetros que podem ser usados como
work-around (tal como o _PUSH_JOIN_PREDICATE ,
_OPTIMIZER_COST_BASED_TRANSFORMATION, _OPTIMIZER_NATIVE_FULL_OUTER_JOIN,
_OPTIMIZER_JOIN_ELIMINATION_ENABLED , _COMPLEX_VIEW_MERGING _FIX_CONTROL e
outros) , e HINTs...
penso que está Claro então o seu plano de Ação , vc tem que :
1. obter do Analista Oracle a resposta se qquer dos bugs acima está envolvido
: inclusive, Notar que isso o SQLT *** absolutamente *** não vai dizer, então
(repito) cobre essa análise do Analista Oracle, se for preciso Escale o
chamado, acione o Gerente de conta, vc Tem Que obter essa resposta
2. se 1. identificou algum bug, fatalmente deve haver work-around de
parâmetro e/ou hint, isso tem que ser verificado
3. como TESTE (evidentemente num ambiente de homologação), experimentar
re-escrever a view usando JOIN na sintaxe Oracle ao invés de ANSI.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, RP pradelarf@... escreveu
Chiappa, bom dia! Grato pelas informações.
Eu me expressei mal, realmente o plano de execução mudou, com algumas
parametrizações que fiz ontem o problema foi amenizado, porem não resolvido.
O problema se concentra basicamente em um select, o mesmo faz acesso a uma
view com ANSI Join, notei que o mesmo utiliza algumas variáveis bind e
algumas literais, não sei bem o motivo. Apenas para entendimento eu não
trabalho na empresa em questão, minha consultoria tem um contrato de hora
mensais para eventuais problemas, porem eu não atuo neste ambiente somente
em caso de problemas, por este motivo tenho pouco conhecimento das
aplicações.
Antes da aplicação do patch eu verifiquei o doc 1087991.1, não encontrei
nenhum problema que se encaixasse no ambiente.
Neste momento estou com um chamado na Oracle, prioridade 1, eles solicitaram
a execução do SQLT para verificar as informações do select problemático.
Grato pela ajuda, assim que tiver alguma resposta da Oracle, posto para
ficar documentado.
ABS.
--
R.P.
DBA Oracle
Oracle Database 11g Administrator Certified Professional
Oracle Database 10g Real Applications Clusters AdministratorCertified Expert
Oracle Enterprise Linux Certified Implementation Specialist
Oracle Database 11g Administrator Certified Associate
From: José Laurindo jlchiappa@...
Reply-To: oracle_br@yahoogrupos.com.br
Date: Tue, 12 Jul 2011 23:47:41 -
To: oracle_br@yahoogrupos.com.br
Subject: [oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 {
Urgente }
..., acredito que tenham alterado os planos de execução dos SQLs.
ESTA é a parte que deve estar te complicando : vc DEVERIA ser totalmente
capaz de responder isso, é Mais que recomendado se manter arquivado os
Planos de execução (dos principais SQLs ao menos) , não só antes de Qualquer
patch mas Rotineiramente... Não o tendo feito, vc vai estar no escuro, não é
de forma alguma um procedimento recomendado/recomendável
O que vc pode tentar fazer nesta situação atual é :
a. (** SE ** vc tem AWR ativado e ** SE ** vc tem acesso/licença pra isso, e
** SE ** o upgrade foi recente e vc ainda tem os snapshots presentes ) é
buscar nas tabelas do histórico do AWR (ie, DBA_HIST_SQLTEXT e
DBA_HIST_SQL_PLAN) e ver se encontra pra ao menos alguns casos principais /
importantes os planos de antes do upgrade e comparar com os planos atuais
b. tentar buscar nas tabs/views do ASH (ie,
v$active_sess_hist/dba_hist_active_sess_history , dba_hist_sys_time_model,
v$event_histogram, v$active_sess_hist view, wrh$active_session_history) um
histórico de estatísticas do sistema e de sessões, pra comparar com o que vc
tem hoje, assim confirmando ou negando teu diagnóstico de I/O excessivo
c. consultar no metalink a nota 10.2.0.5 Patch Set - Availability and Known
Issues (Doc ID 1087991.1) e ver se vc est´[a caindo num dos casos
Re: [oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 { Urgente }
Chiappa, boa tarde!
Grato pelas informações, o bug 9236988 eu já habilitei o o _FIX_CONTROL que
contorna ele, o ambiente melhorou, mas ainda continua ruim.
Até o momento o atendente da Oracle está apenas solicitando informações, se
até as 15 horas não houver resposta vou escalonar o chamado, pois a situação
está critica.
A view utilizada tem vários hints colocados pelo programador, fiz vários
testes, e estranhamente quando eu rodo um bloco PL/SQL Anônimo, com o select
executado pelo usuário, a resposta é instantânea. Segue hints:
/*+ FIRST_ROWS index
(ix_profisatend_atendreg,ix_atend_dataatend,ix_pacatend_atendreg) */
Fiz um teste tirando os hints e e tentando alguns diferentes, mas o
resultado foi pior.
Bom vou ficar no aguardo da Oracle, e assim que tiver resposta irei
compartilhar com a comunidade.
Caso alguém tenha enfrentado algo parecido, a informação será bem vinda.
ABS.
--
R.P.
DBA Oracle
Oracle Database 11g Administrator Certified Professional
Oracle Database 10g Real Applications Clusters AdministratorCertified Expert
Oracle Enterprise Linux Certified Implementation Specialist
Oracle Database 11g Administrator Certified Associate
From: José Laurindo jlchia...@yahoo.com.br
Reply-To: oracle_br@yahoogrupos.com.br
Date: Wed, 13 Jul 2011 14:45:33 -
To: oracle_br@yahoogrupos.com.br
Subject: [oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 {
Urgente }
Ah sim, agora tá melhor explicado : uma coisa é dizer que tá mal
genericamente, que o problema é um consumo de I/O geral maior, outra é ter
cercado e localizado o problema...
okdoc, se vc cercou/localizou e se refere à view com ANSI join, não deixe de
verificar bugs e issues sobre isso : na verdade há diversas situações de
diferença de otimização ao se usar ANSI join - em tese deveria ser
rigorosamente o mesmo que usar a sintaxe antiga mas nem sempre isso ocorre ,
como mostrado em http://www.dbaportal.eu/?q=node/183 e
http://hoopercharles.wordpress.com/2010/12/30/ansi-full-outer-join-ready-or-
not/ ... Não deixe de sinalizar isso para o Analista que está te atendendo,
pois já são de conhecimento alguns bugs com ANSI joins só resolvidos no 11g,
como o Bug 9395765 - ORA-907 / wrong plan from query with ANSI FULL OUTER
join [ID 9395765.8] e o Bug 9236988 Suboptimal execution plans with ANSI
joins, views and fix for bug 7345484 enabled, por exemplo
Outro ponto que o Analista que está te atendendo tem TOTAL OBRIGAÇÃO de
dizer se cabe ou não é que há Diversos parâmetros que podem ser usados como
work-around (tal como o _PUSH_JOIN_PREDICATE ,
_OPTIMIZER_COST_BASED_TRANSFORMATION, _OPTIMIZER_NATIVE_FULL_OUTER_JOIN,
_OPTIMIZER_JOIN_ELIMINATION_ENABLED , _COMPLEX_VIEW_MERGING _FIX_CONTROL e
outros) , e HINTs...
penso que está Claro então o seu plano de Ação , vc tem que :
1. obter do Analista Oracle a resposta se qquer dos bugs acima está
envolvido : inclusive, Notar que isso o SQLT *** absolutamente *** não vai
dizer, então (repito) cobre essa análise do Analista Oracle, se for preciso
Escale o chamado, acione o Gerente de conta, vc Tem Que obter essa resposta
2. se 1. identificou algum bug, fatalmente deve haver work-around de
parâmetro e/ou hint, isso tem que ser verificado
3. como TESTE (evidentemente num ambiente de homologação), experimentar
re-escrever a view usando JOIN na sintaxe Oracle ao invés de ANSI.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br
, RP pradelarf@... escreveu
Chiappa, bom dia! Grato pelas informações.
Eu me expressei mal, realmente o plano de execução mudou, com algumas
parametrizações que fiz ontem o problema foi amenizado, porem não resolvido.
O problema se concentra basicamente em um select, o mesmo faz acesso a uma
view com ANSI Join, notei que o mesmo utiliza algumas variáveis bind e
algumas literais, não sei bem o motivo. Apenas para entendimento eu não
trabalho na empresa em questão, minha consultoria tem um contrato de hora
mensais para eventuais problemas, porem eu não atuo neste ambiente somente
em caso de problemas, por este motivo tenho pouco conhecimento das
aplicações.
Antes da aplicação do patch eu verifiquei o doc 1087991.1, não encontrei
nenhum problema que se encaixasse no ambiente.
Neste momento estou com um chamado na Oracle, prioridade 1, eles solicitaram
a execução do SQLT para verificar as informações do select problemático.
Grato pela ajuda, assim que tiver alguma resposta da Oracle, posto para
ficar documentado.
ABS.
--
R.P.
DBA Oracle
Oracle Database 11g Administrator Certified Professional
Oracle Database 10g Real Applications Clusters AdministratorCertified Expert
Oracle Enterprise Linux Certified Implementation Specialist
Oracle Database 11g Administrator Certified Associate
From: José Laurindo jlchiappa@...
Reply-To: oracle_br@yahoogrupos.com.br
mailto:oracle_br%40yahoogrupos.com.br
Date: Tue, 12 Jul 2011 23:47:41 -
To: oracle_br@yahoogrupos.com.br
[oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 { Urgente }
Colega, PRIMEIRA COISA : vc foi AUTORIZADO pela Oracle a habilitar o tal param,
foi CONFIRMADO o tal bug ??? Mexer nos params internos SEM uma indicação
Precisa e Direta do Suporte não é, De Forma Alguma, algo Recomendado /
Recomendável...
Sobre a pergunta, na verdade eu já peguei, num cliente do interior de SP há
uns anos (com 10.2.0.4 na ocasião) situação aonde os tempos/execução/planos
eram diferentes ao se executar a query diretamente e/ou num bloco anônimo
versus executar via view, não é tão estranho assim : o que ocorre é que quando
vc faz um SELECT colunas FROM VIEW , Automaticamente o que o banco de dados vai
receber e interpretar/otimizar é um SELECT com sub-query tipo :
SELECT * FROM (select colunas from query da view);
e haviam na ocasião uns tantoss quantos bugs referentes à sub-query,
basicamente o que havia é que quando vc tem sub-query o otimizador pode optar
por otimizar a query interna OU a externa primeiro, ou mesmo fazer um MERGE das
duas, e ele estava fazendo escolhas inapropriadas Na ocasião pra um caso a
gente tinha one-off patch, e pra outro a gente contornou com parâmetros que
indicavam pro Otimizador uma ordem ao trabalhar com subqueries, tal como o
_UNNEST_SUBQUERY e o _COMPLEX_VIEW_MERGING , mas vc está Absolutamente certo em
pedir Escalonamento, troca de Analista e o que puder, pra receber uma análise
antes de sair mexendo em params internos...
Outra possibilidade, tal como eu falei, é testar os mesmos itens sem ANSI
JOINs : talvez se tentar criar uma view com outro nome mas com Exatamente o
mesmo SQL original, apenas usando sintaxe Oracle ao invés de ANSI, isso seria
uma Clara indicação se é mesmo bug do ANSI ou bug de inner query causada pelo
acesso via view...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, RP pradelarf@... escreveu
Chiappa, boa tarde!
Grato pelas informações, o bug 9236988 eu já habilitei o o _FIX_CONTROL que
contorna ele, o ambiente melhorou, mas ainda continua ruim.
Até o momento o atendente da Oracle está apenas solicitando informações, se
até as 15 horas não houver resposta vou escalonar o chamado, pois a situação
está critica.
A view utilizada tem vários hints colocados pelo programador, fiz vários
testes, e estranhamente quando eu rodo um bloco PL/SQL Anônimo, com o select
executado pelo usuário, a resposta é instantânea. Segue hints:
/*+ FIRST_ROWS index
(ix_profisatend_atendreg,ix_atend_dataatend,ix_pacatend_atendreg) */
Fiz um teste tirando os hints e e tentando alguns diferentes, mas o
resultado foi pior.
Bom vou ficar no aguardo da Oracle, e assim que tiver resposta irei
compartilhar com a comunidade.
Caso alguém tenha enfrentado algo parecido, a informação será bem vinda.
ABS.
--
R.P.
DBA Oracle
Oracle Database 11g Administrator Certified Professional
Oracle Database 10g Real Applications Clusters AdministratorCertified Expert
Oracle Enterprise Linux Certified Implementation Specialist
Oracle Database 11g Administrator Certified Associate
From: José Laurindo jlchiappa@...
Reply-To: oracle_br@yahoogrupos.com.br
Date: Wed, 13 Jul 2011 14:45:33 -
To: oracle_br@yahoogrupos.com.br
Subject: [oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 {
Urgente }
Ah sim, agora tá melhor explicado : uma coisa é dizer que tá mal
genericamente, que o problema é um consumo de I/O geral maior, outra é ter
cercado e localizado o problema...
okdoc, se vc cercou/localizou e se refere à view com ANSI join, não deixe de
verificar bugs e issues sobre isso : na verdade há diversas situações de
diferença de otimização ao se usar ANSI join - em tese deveria ser
rigorosamente o mesmo que usar a sintaxe antiga mas nem sempre isso ocorre ,
como mostrado em http://www.dbaportal.eu/?q=node/183 e
http://hoopercharles.wordpress.com/2010/12/30/ansi-full-outer-join-ready-or-
not/ ... Não deixe de sinalizar isso para o Analista que está te atendendo,
pois já são de conhecimento alguns bugs com ANSI joins só resolvidos no 11g,
como o Bug 9395765 - ORA-907 / wrong plan from query with ANSI FULL OUTER
join [ID 9395765.8] e o Bug 9236988 Suboptimal execution plans with ANSI
joins, views and fix for bug 7345484 enabled, por exemplo
Outro ponto que o Analista que está te atendendo tem TOTAL OBRIGAÇÃO de
dizer se cabe ou não é que há Diversos parâmetros que podem ser usados como
work-around (tal como o _PUSH_JOIN_PREDICATE ,
_OPTIMIZER_COST_BASED_TRANSFORMATION, _OPTIMIZER_NATIVE_FULL_OUTER_JOIN,
_OPTIMIZER_JOIN_ELIMINATION_ENABLED , _COMPLEX_VIEW_MERGING _FIX_CONTROL e
outros) , e HINTs...
penso que está Claro então o seu plano de Ação , vc tem que :
1. obter do Analista Oracle a resposta se qquer dos bugs acima está
envolvido : inclusive, Notar que isso o SQLT *** absolutamente *** não vai
dizer, então (repito) cobre essa análise do Analista Oracle, se for preciso
Escale o chamado, acione o Gerente de conta, vc Tem Que obter essa
[oracle_br] Re: Problemas Após aplicação do Patch 10.2.0.5 { Urgente }
..., acredito que tenham alterado os planos de execução dos SQLs. ESTA é a parte que deve estar te complicando : vc DEVERIA ser totalmente capaz de responder isso, é Mais que recomendado se manter arquivado os Planos de execução (dos principais SQLs ao menos) , não só antes de Qualquer patch mas Rotineiramente... Não o tendo feito, vc vai estar no escuro, não é de forma alguma um procedimento recomendado/recomendável O que vc pode tentar fazer nesta situação atual é : a. (** SE ** vc tem AWR ativado e ** SE ** vc tem acesso/licença pra isso, e ** SE ** o upgrade foi recente e vc ainda tem os snapshots presentes ) é buscar nas tabelas do histórico do AWR (ie, DBA_HIST_SQLTEXT e DBA_HIST_SQL_PLAN) e ver se encontra pra ao menos alguns casos principais / importantes os planos de antes do upgrade e comparar com os planos atuais b. tentar buscar nas tabs/views do ASH (ie, v$active_sess_hist/dba_hist_active_sess_history , dba_hist_sys_time_model, v$event_histogram, v$active_sess_hist view, wrh$active_session_history) um histórico de estatísticas do sistema e de sessões, pra comparar com o que vc tem hoje, assim confirmando ou negando teu diagnóstico de I/O excessivo c. consultar no metalink a nota 10.2.0.5 Patch Set - Availability and Known Issues (Doc ID 1087991.1) e ver se vc est´[a caindo num dos casos conhecidos d. analisar pela V$SQL os SQLs mais consumidores de recursos e ver se eles tem alguma característica em comum (por exemplo, na maioria dos casos usam ANSI JOIN, não usam BIND variables, etc, etc) : a idéia aqui é tentar cercar a causa de comportamento dos SQLs []s Chiappa --- Em oracle_br@yahoogrupos.com.br, R P pradelarf@... escreveu Senhores, boa noite! Este final de semana atualizei um o patch e um CPU de um banco de dados, após isto estou enfrentando sérios problemas de performance, segue descrição do ambiente: SO: Oracle Enterprise Linux 5.3 64bit RBMS: 10.2.0.5 + PSU Abril 2011 Anteriormente era 10.2.0.4 PSU October 2009. Single Instance. Standand Edition. Após a aplicação destes Patches o I/O do servidor aumentou muito, acredito que tenham alterado os planos de execução dos SQLs. Durante a aplicação do patch o único parâmetro alterado foi o COMPATIBLE de 10.2.0.4 para 10.2.0.5. Devido a estes problemas, hoje e ontem durante o dia fiz testes com vários parâmetros, porem nenhum apresentou o resultado esperado. Segue o que foi alterado: _GBY_Hash_Aggregation_Enabled=FALSE ID:7612454.8 _fix_control='7345484:off' - ID: 567171.1 optimizer_features_enable estava em 10.2.0.4, tentei setar para 9.2.0.8 e 10.2.0.5, porem não resolveu meu problema, então voltei para 10.2.0.4. No aguardo de alguma ajuda. -- R.P. DBA Oracle Oracle Database 11g Administrator Certified Professional Oracle Database 10g Real Applications Clusters AdministratorCertified Expert Oracle Enterprise Linux Certified Implementation Specialist Oracle Database 11g Administrator Certified Associate
