Re: [oracle_br] Re: Upgrade 9i to 10gR2

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Chiappa, muito obrigado pelas informações.
Em sábado, 15 de setembro de 2018 18:00:24 BRT, jlchia...@yahoo.com.br 
[oracle_br]  escreveu:  
 
     
Uma obs final : eu fui olhar no metalink e o patch 8202632 (que é quem provê o 
Patchset
10.2.0.5 FOR ORACLE DATABASE SERVER) existe ** SIM ** para AIX (no caso 64 bits 
em PowerPC, vc não diz mas CREIO que é o seu caso), E a nota metalink / My 
Oracle Support "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) indica que pra 
usar 10.2 vc só precisa que teu AIX seja "5.2 ML4 or higher, 5..3 ML2 or 
higher, 6.1" - como vc diz que teu AIX já é 5.3 basta simplemnte aplicar os 
patches IBM que vão deixar ele em mainteinance level 2 ou maior e vc JÁ VAI 
PODER USAR o 10.2.0.5...
 Isso é CRÍTICO, pois houveram bugfixes Seríssimos (tanto de Segurança quanto 
de performnace e também erros de false results) no 10.2.0.5 : não faz Sentido 
usar 10.2.0.4 nesse cenário..
 
 []s
 
   Chiappa
  #yiv2215539328 #yiv2215539328 -- #yiv2215539328ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2215539328 
#yiv2215539328ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2215539328 
#yiv2215539328ygrp-mkp #yiv2215539328hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2215539328 #yiv2215539328ygrp-mkp #yiv2215539328ads 
{margin-bottom:10px;}#yiv2215539328 #yiv2215539328ygrp-mkp .yiv2215539328ad 
{padding:0 0;}#yiv2215539328 #yiv2215539328ygrp-mkp .yiv2215539328ad p 
{margin:0;}#yiv2215539328 #yiv2215539328ygrp-mkp .yiv2215539328ad a 
{color:#ff;text-decoration:none;}#yiv2215539328 #yiv2215539328ygrp-sponsor 
#yiv2215539328ygrp-lc {font-family:Arial;}#yiv2215539328 
#yiv2215539328ygrp-sponsor #yiv2215539328ygrp-lc #yiv2215539328hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2215539328 
#yiv2215539328ygrp-sponsor #yiv2215539328ygrp-lc .yiv2215539328ad 
{margin-bottom:10px;padding:0 0;}#yiv2215539328 #yiv2215539328actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2215539328 
#yiv2215539328activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2215539328
 #yiv2215539328activity span {font-weight:700;}#yiv2215539328 
#yiv2215539328activity span:first-child 
{text-transform:uppercase;}#yiv2215539328 #yiv2215539328activity span a 
{color:#5085b6;text-decoration:none;}#yiv2215539328 #yiv2215539328activity span 
span {color:#ff7900;}#yiv2215539328 #yiv2215539328activity span 
.yiv2215539328underline {text-decoration:underline;}#yiv2215539328 
.yiv2215539328attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv2215539328 .yiv2215539328attach div a 
{text-decoration:none;}#yiv2215539328 .yiv2215539328attach img 
{border:none;padding-right:5px;}#yiv2215539328 .yiv2215539328attach label 
{display:block;margin-bottom:5px;}#yiv2215539328 .yiv2215539328attach label a 
{text-decoration:none;}#yiv2215539328 blockquote {margin:0 0 0 
4px;}#yiv2215539328 .yiv2215539328bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv2215539328 
.yiv2215539328bold a {text-decoration:none;}#yiv2215539328 dd.yiv2215539328last 
p a {font-family:Verdana;font-weight:700;}#yiv2215539328 dd.yiv2215539328last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv2215539328 
dd.yiv2215539328last p span.yiv2215539328yshortcuts 
{margin-right:0;}#yiv2215539328 div.yiv2215539328attach-table div div a 
{text-decoration:none;}#yiv2215539328 div.yiv2215539328attach-table 
{width:400px;}#yiv2215539328 div.yiv2215539328file-title a, #yiv2215539328 
div.yiv2215539328file-title a:active, #yiv2215539328 
div.yiv2215539328file-title a:hover, #yiv2215539328 div.yiv2215539328file-title 
a:visited {text-decoration:none;}#yiv2215539328 div.yiv2215539328photo-title a, 
#yiv2215539328 div.yiv2215539328photo-title a:active, #yiv2215539328 
div.yiv2215539328photo-title a:hover, #yiv2215539328 
div.yiv2215539328photo-title a:visited {text-decoration:none;}#yiv2215539328 
div#yiv2215539328ygrp-mlmsg #yiv2215539328ygrp-msg p a 
span.yiv2215539328yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv2215539328 
.yiv2215539328green {color:#628c2a;}#yiv2215539328 .yiv2215539328MsoNormal 
{margin:0 0 0 0;}#yiv2215539328 o {font-size:0;}#yiv2215539328 
#yiv2215539328photos div {float:left;width:72px;}#yiv2215539328 
#yiv2215539328photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv2215539328 
#yiv2215539328photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv2215539328
 #yiv2215539328reco-category {font-size:77%;}#yiv2215539328 
#yiv2215539328reco-desc {font-size:77%;}#yiv2215539328 .yiv2215539328replbq 
{margin:4px;}#yiv2215539328 #yiv2215539328ygrp-actbar div 

[oracle_br] Upgrade 9i to 10gR2

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Objetivo: Upgrade standalone rdbms oracle 9.2.0.8.0 para 10.2.0.4.
Cenário:
SO: AIx 5.3Current version: Oracle rdbms 9.2.0.8.0 Next version: Oracle rdbms 
10.2.0.4 (versão compatível com a versão do SO)

Patches disponíveis para execução:
Oracle 10.2.0.1:
B24442-01_1of3.zipB24442-01_2of3.zipB24442-01_3of3.zipB24443-01_1of4.zipB24443-01_2of4.zipB24443-01_3of4.zipB24443-01_4of4.zip

Oracle 10.2.0.4
p6810189_10204_AIX5L.zip


Para a falar a verdade eu nunca, na vida, fiz um upgrade de um banco abaixo da 
versão 11gR2, nunca tive experiência em rdbms Oracle 10g ou 9i, por esse 
motivo, gostaria de pedir ajuda de vocês de uma forma que fique fácil o 
entendimento de como realizar esse upgrade, procurei no google alguns tutoriais 
mais todos eles com muita falta de informação. Se alguém puder ajudar ou passar 
algum tutorial eu agradeço 
:)

Re: [oracle_br] Re: Ajuda query

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Muito obrigado pela ajuda Chiappa.
Só para complementar, essa query foi retirada do blog do Tanel Poder. Todos os 
scripts que ele disponibiliza foi ele mesmo quem criou. Em relação a UNDO e 
TEMP, tinha adicionado a consulta para excluir as duas tablespaces da query:

AND t.tablespace_name not in (select tablespace_name from dba_tablespaces where 
contents in ('TEMPORARY','UNDO'))

Já possuo as queries que fazem o monitoramento do UNDO e da TEMPObrigado.Em 
quarta-feira, 4 de julho de 2018 13:55:57 BRT, jlchia...@yahoo.com.br 
[oracle_br]  escreveu:  
 
     
Blz ? Então, antes de tar a sua resposta, uma Obs : tenha ** certeza ** que a 
lógica implementada nesse tal script aí está correta principalmente no tocante 
à tablespace de UNDO e tablespace TEMP - como Acredito que vc deve saber, o 
espaço usado REAL na tablespace de UNDO vc deve consultar na V$TRANSACTION e o 
espaço REAL em uso na temp tablespace vc consulta na 
V$SORT_USAGE/V$SORT_SEGMENT Outra coisa é CUIDADO ao calcular %used e %free 
em datafiles auto-extensíveis : como vc sabe, o valor máximo de extensão é um 
limite FUTURO, a ser imposto AO SISTEMA OPERACIONAL não agora mas apenas QUANDO 
a tablespace crescer.. Assim, então em tese vc deveria SOMAR os autoextensíveis 
todos, verificar quanto vc tem livre em disco no sistema operacional e o espaço 
livre ** REAL ** seria a diferença desses dois...

 Muito bem, aviso dado vamos à resposta : primeiro vamos executar a tua query 
sem alterações :
 
SYSTEM:@O11GR2SE:SQL>get t.sql
  1 SELECT t.tablespace_name, t.mb  "TotalMB" 
  2 ,    t.mb - nvl(f.mb,0) "UsedMB" 
  3 ,   nvl(f.mb,0) "FreeMB" 
  4 ,lpad(ceil((1-nvl(f.mb,0)/decode(t.mb,0,1,t.mb))*100)||'%', 6) "% Used" 
  5 ,    t.ext "Ext" 
  6 , 
'|'||rpad(lpad('#',ceil((1-nvl(f.mb,0)/decode(t.mb,0,1,t.mb))*20),'#'),20,' 
')||'|' "Used" 
  7  FROM 
  8 ( 
  9   select tablespace_name, trunc(sum(bytes)/1048576) MB 
 10 from dba_free_space 
 11    group by tablespace_name 
 12   union all 
 13   select tablespace_name, trunc(sum(bytes_free)/1048576) MB 
 14 from v$temp_space_header 
 15    group by tablespace_name 
 16  ) f, 
 17 (select tablespace_name, trunc(sum(bytes)/1048576) MB, 
max(autoextensible) ext 
 18    from dba_data_files 
 19   group by tablespace_name 
 20  union all 
 21  select tablespace_name, trunc(sum(bytes)/1048576) MB, 
max(autoextensible) ext 
 22    from dba_temp_files 
 23   group by tablespace_name 
 24  ) t 
 25 WHERE t.tablespace_name = f.tablespace_name (+) 
 26   AND t.tablespace_name not in (select tablespace_name from dba_tablespaces 
where contents in ('TEMPORARY','UNDO')) 
 27 ORDER BY t.tablespace_name; 

 SYSTEM:@O11GR2SE:SQL>@t

TABLESPACE_NAME   TotalMB UsedMB FreeMB % Used Ext Used
-- -- -- -- -- --- 
--
EXAMPLE   313 39    274    13% YES |### 
    |
STATSPACK 372    355 17    96% YES 
||
SYSAUX    580    537 43    93% YES 
|### |
SYSTEM   1760   1721 39    98% YES 
||
TS_TESTE  363    346 17    96% YES 
||
USERS    1297   1235 62    96% YES 
||

6 linhas selecionadas.

==> Okdoc... Bem, pelo que entendi a tua dúvida decorre primeiro do fato de a 
coluna "% Used" ser o resultado de uma expressão, o que o Oracle não deixa usar 
em GROUP BY, em WHERE A solução para isso é simplesmente ter um query 
EXTERNA, que use na cláusula de FROM a query original, assim 'materializando' 
as expressões O segundo ponto que imagino te  pegou foi o FATO de que essa 
coluna é uma CONTA/expressão numérica CONCATENADA com um caracter '%' : 
necessariamente se vc concatena uma string com uma conta o resultado é string, 
pra vc poder restringir com >= vc TEM que converter de volta pra número, assim :

SYSTEM:@O11GR2SE:SQL>get t.sql
  1  select *
  2  from
  3 (
  4 SELECT t.tablespace_name, t.mb  "TotalMB"
  5 ,    t.mb - nvl(f.mb,0) "UsedMB"
  6 ,   nvl(f..mb,0) "FreeMB"
  7 ,lpad(ceil((1-nvl(f.mb,0)/decode(t.mb,0,1,t.mb))*100)||'%', 6) "% 
Used"
  8 ,    t.ext "Ext"
  9 , 
'|'||rpad(lpad('#',ceil((1-nvl(f.mb,0)/decode(t.mb,0,1,t.mb))*20),'#'),20,' 
')||'|' "Used"
 10  FROM
 11 (
 12   select tablespace_name, trunc(sum(bytes)/1048576) MB
 13 from dba_free_space
 14    group by tablespace_name
 15   union all
 16   select tablespace_name, 

[oracle_br] Ajuda query

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

select t.tablespace_name, t.mb "TotalMB", t.mb - nvl(f.mb,0) "UsedMB", 
nvl(f.mb,0) "FreeMB"       
,lpad(ceil((1-nvl(f.mb,0)/decode(t.mb,0,1,t.mb))*100)||'%', 6) "% Used", t.ext 
"Ext",        
'|'||rpad(lpad('#',ceil((1-nvl(f.mb,0)/decode(t.mb,0,1,t.mb))*20),'#'),20,' 
')||'|' "Used"from (  select tablespace_name, trunc(sum(bytes)/1048576) MB  
from dba_free_space  group by tablespace_name union all  select 
tablespace_name, trunc(sum(bytes_free)/1048576) MB  from v$temp_space_header  
group by tablespace_name) f, (  select tablespace_name, 
trunc(sum(bytes)/1048576) MB, max(autoextensible) ext  from dba_data_files  
group by tablespace_name union all  select tablespace_name, 
trunc(sum(bytes)/1048576) MB, max(autoextensible) ext  from dba_temp_files  
group by tablespace_name) twhere t.tablespace_name = f.tablespace_name (+)  and 
t.tablespace_name not in (select tablespace_name from dba_tablespaces where 
contents in ('TEMPORARY','UNDO'))order by t.tablespace_name;

Utilizo a consulta acima para monitorar as tablespaces, gostaria de adicionar 
um filtro no qual só trouxesse as tablespaces com 90% de utilização ou mais, me 
baseando na coluna 
lpad(ceil((1-nvl(f.mb,0)/decode(t.mb,0,1,t.mb))*100)||'%', 6) "% Used"

Alguém poderia ajudar?

Re: [oracle_br] Re: Upgrade 9i para 12cR1

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Entao esse cliente tem parceria forte com a IBM, tudo deles eh da IBM (menos o 
rdbms), servidor eh uma power 8. Todos os servidores sao AIX, nao existe essa 
possibilidade infelizmente.
Em sexta-feira, 11 de maio de 2018 15:29:28 BRT, angelo 
angelolis...@gmail.com [oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:  
 
     

uma pergunta de curioso,
O negocio dele não comporta rodar o Oracle no Linux ?  Já que ta pensando em 
atualizar o sistema operacional...

Pois em matéria de SO, atualizado está e uma boa galera compreende mais, se 
comparado ao AIX  que nem todo mundo acessa e o hardware é restrito ( ibm )


On 10 May 2018 at 13:35, Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br> wrote:

     

 Pessoal obrigado pelas explicações.
Além dessa base 9i, existem mais 4 bases na versão 10gR2 nesse mesmo servidor. 
Então o que eu entendo qual seria o procedimento mais simples:
a) Atualizar o sistema operacional para uma versão compatível com a versão 12c 
e a 10gR2 (vou olhar no metalink se existe, talvez o AIX 6 seja)
b) Adicionar um novo file system e instalar o Oracle 12cRx em um novo 
oracle_home nesse file system
c) Criar um banco vazio 12cRx
d) realizar o export dos dados 9i
e) importar 12xRx

Vou levar todas as considerações mencionadas acima, tanto realizar isso em um 
servidor de teste e verifiar as questões dos clients de conexão. 
Obrigado :)


Em quarta-feira, 9 de maio de 2018 18:57:01 BRT, jlchia...@yahoo.com.br 
[oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:  
 
     
E uma obs final : tudo fica MUITO, mas MUUUITO MAIS fácil E seguro se o upgrade 
puder ser feito num outro servidor pra onde vc transfira os arquivos todos do 
database 9i , tendo antes já instalodo lá a nova versão de SO e a nova versão 
do RDBMS . Se o cliente não tava pensando nisso, insista : só se ele fechar 
questão de modo absoluto é que aí não tem jeito e vc terá que assumir os 
riscos...

 []s
 
   Chiappa


   

  #yiv1514955474 #yiv1514955474 -- #yiv1514955474ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1514955474 
#yiv1514955474ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1514955474 
#yiv1514955474ygrp-mkp #yiv1514955474hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv1514955474 #yiv1514955474ygrp-mkp #yiv1514955474ads 
{margin-bottom:10px;}#yiv1514955474 #yiv1514955474ygrp-mkp .yiv1514955474ad 
{padding:0 0;}#yiv1514955474 #yiv1514955474ygrp-mkp .yiv1514955474ad p 
{margin:0;}#yiv1514955474 #yiv1514955474ygrp-mkp .yiv1514955474ad a 
{color:#ff;text-decoration:none;}#yiv1514955474 #yiv1514955474ygrp-sponsor 
#yiv1514955474ygrp-lc {font-family:Arial;}#yiv1514955474 
#yiv1514955474ygrp-sponsor #yiv1514955474ygrp-lc #yiv1514955474hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1514955474 
#yiv1514955474ygrp-sponsor #yiv1514955474ygrp-lc .yiv1514955474ad 
{margin-bottom:10px;padding:0 0;}#yiv1514955474 #yiv1514955474actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1514955474 
#yiv1514955474activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1514955474
 #yiv1514955474activity span {font-weight:700;}#yiv1514955474 
#yiv1514955474activity span:first-child 
{text-transform:uppercase;}#yiv1514955474 #yiv1514955474activity span a 
{color:#5085b6;text-decoration:none;}#yiv1514955474 #yiv1514955474activity span 
span {color:#ff7900;}#yiv1514955474 #yiv1514955474activity span 
.yiv1514955474underline {text-decoration:underline;}#yiv1514955474 
.yiv1514955474attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv1514955474 .yiv1514955474attach div a 
{text-decoration:none;}#yiv1514955474 .yiv1514955474attach img 
{border:none;padding-right:5px;}#yiv1514955474 .yiv1514955474attach label 
{display:block;margin-bottom:5px;}#yiv1514955474 .yiv1514955474attach label a 
{text-decoration:none;}#yiv1514955474 blockquote {margin:0 0 0 
4px;}#yiv1514955474 .yiv1514955474bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv1514955474 
.yiv1514955474bold a {text-decoration:none;}#yiv1514955474 dd.yiv1514955474last 
p a {font-family:Verdana;font-weight:700;}#yiv1514955474 dd.yiv1514955474last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv1514955474 
dd.yiv1514955474last p span.yiv1514955474yshortcuts 
{margin-right:0;}#yiv1514955474 div.yiv1514955474attach-table div div a 
{text-decoration:none;}#yiv1514955474 div.yiv1514955474attach-table 
{width:400px;}#yiv1514955474 div.yiv1514955474file-title a, #yiv1514955474 
div.yiv1514955474file-title a:active, #yiv1514955474 
div.yiv1514955474file-title a:hover, #yiv1514955474 div.yiv1514955474file-title 
a:visited {text-decoration:none;}#yiv1514955474 div.yiv1514955474photo-title a, 
#yiv1514955474 div.yiv1514955474photo-title a:active, #yiv1514955474 
div.yiv1514955474p

[oracle_br] Sincronismo standby

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Senhores, boa tarde.
Cenario:
Oracle 11gR2 - Um primary db e um physical standby DB (OPEN WITH APPLY) - 
Active DG

Estou com um problema em uma configuração de DataGuard. Utilizamos uma query 
para monitorar o sincronismo entre o primary e o standby database. Temos em 
torno de 20 dataguards, e o monitoramento está ok e funciona bem em todos 
ambientes, *MAS EM UM AMBIENTE ESPECIFICO* a monitoração está alertando o tempo 
inteiro enquanto não deveria alertar, segue:

NO PRIMARY DATABASE:
SELECT  DATABASE_MODE       , SUBSTR (RECOVERY_MODE, 1, 8) AS "RECOV_MODE"    , 
PROTECTION_MODE AS "PROTECTION_MODE"       , SUBSTR (DESTINATION, 1, 10) AS 
"DEST"       , ARCHIVED_SEQ#        , APPLIED_SEQ#       , SUBSTR 
(SYNCHRONIZATION_STATUS, 1, 8) AS "SYNC_STATUS"       , SYNCHRONIZED AS "SYNC"  
     , GAP_STATUS    , STATUSFROM     V$ARCHIVE_DEST_STATUSWHERE    TYPE <> 
'LOCAL'/


DATABASE_MODE  |RECOV_MO|PROTECTION_MODE     |DEST      
|ARCHIVED_SEQ#|APPLIED_SEQ#|SYNC_STA|SYN|GAP_STATUS              
|STATUS---|||--|-|||---||-OPEN_READ-ONLY
 |MANAGED |MAXIMUM PERFORMANCE |sdemp_std |       139745|      139659|CHECK 
CO|NO |NO GAP                  |VALID


Se voces perceberem o valor da coluna ARCHIVED_SEQ# (primary) = 139744e o valor 
da coluna APPLIED_SEQ# (standby) = 139659
Será visto que existe uma diferença grande entre ambos. Porém, se eu realizar a 
consulta abaixo, irá me mostrar o seguinte:

QUery executada no STANDBY DATABASE:

SELECT 'Last applied  : '                         Logs,       
To_char(next_time, 'DD/MM/YY HH24:MI:SS') TimeFROM   v$archived_logWHERE  
sequence# = (SELECT Max(sequence#)                      FROM   v$archived_log   
                  WHERE  applied = 'YES')UNIONSELECT 'Last received : '         
                Logs,       To_char(next_time, 'DD/MM/YY HH24:MI:SS') TimeFROM  
 v$archived_logWHERE  sequence# = (SELECT Max(sequence#)                    
FROM   v$archived_log);

LOGS             TIME -Last applied  :  
11/05/18 14:40:37Last received :  11/05/18 14:40:37

se eu fizer um outro select no standby:
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)--        139745

Ou seja, a ultima sequence aplicada no standby bate com o do primary database.

Agora analisando o alert.log do physical standby:


Media Recovery Log /sdemp/arch/u01/archives/sdemp_1_139744_847202734.arcMedia 
Recovery Waiting for thread 1 sequence 139745 (in transit)Fri May 11 14:40:37 
2018RFS[27]: Selected log 8 for thread 1 sequence 139746 dbid 843466460 branch 
847202734Fri May 11 14:40:37 2018Archived Log entry 142021 added for thread 1 
sequence 139745 ID 0x38b9c4c7 dest 1:Fri May 11 14:40:38 2018Media Recovery Log 
/sdemp/arch/u01/archives/sdemp_1_139745_847202734.arcMedia Recovery Waiting for 
thread 1 sequence 139746 (in transit)


Ou seja, o recebimento e o apply está ocorrendo no standby, porém o 
monitoramento no primary database não está OK.
Obs: Esse comportamento só ocorre nesse ambiente, em mais de 10 configurações 
de DG, o APPLIED_SEQ# bate com o ARCHIVED_SEQ#. 

Esse problema está nos dando dor de cabeça por o monitoramento está alertando e 
enviando chamado o tempo inteiro. Se alguémm puder ajudar eu agradeço.

Re: [oracle_br] Re: Upgrade 9i para 12cR1

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Pessoal obrigado pelas explicações.
Além dessa base 9i, existem mais 4 bases na versão 10gR2 nesse mesmo servidor. 
Então o que eu entendo qual seria o procedimento mais simples:
a) Atualizar o sistema operacional para uma versão compatível com a versão 12c 
e a 10gR2 (vou olhar no metalink se existe, talvez o AIX 6 seja)
b) Adicionar um novo file system e instalar o Oracle 12cRx em um novo 
oracle_home nesse file system
c) Criar um banco vazio 12cRx
d) realizar o export dos dados 9i
e) importar 12xRx

Vou levar todas as considerações mencionadas acima, tanto realizar isso em um 
servidor de teste e verifiar as questões dos clients de conexão. 
Obrigado :)


Em quarta-feira, 9 de maio de 2018 18:57:01 BRT, jlchia...@yahoo.com.br 
[oracle_br]  escreveu:  
 
     
E uma obs final : tudo fica MUITO, mas MUUUITO MAIS fácil E seguro se o upgrade 
puder ser feito num outro servidor pra onde vc transfira os arquivos todos do 
database 9i , tendo antes já instalodo lá a nova versão de SO e a nova versão 
do RDBMS . Se o cliente não tava pensando nisso, insista : só se ele fechar 
questão de modo absoluto é que aí não tem jeito e vc terá que assumir os 
riscos...

 []s
 
   Chiappa
  #yiv7980109103 #yiv7980109103 -- #yiv7980109103ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7980109103 
#yiv7980109103ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7980109103 
#yiv7980109103ygrp-mkp #yiv7980109103hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7980109103 #yiv7980109103ygrp-mkp #yiv7980109103ads 
{margin-bottom:10px;}#yiv7980109103 #yiv7980109103ygrp-mkp .yiv7980109103ad 
{padding:0 0;}#yiv7980109103 #yiv7980109103ygrp-mkp .yiv7980109103ad p 
{margin:0;}#yiv7980109103 #yiv7980109103ygrp-mkp .yiv7980109103ad a 
{color:#ff;text-decoration:none;}#yiv7980109103 #yiv7980109103ygrp-sponsor 
#yiv7980109103ygrp-lc {font-family:Arial;}#yiv7980109103 
#yiv7980109103ygrp-sponsor #yiv7980109103ygrp-lc #yiv7980109103hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7980109103 
#yiv7980109103ygrp-sponsor #yiv7980109103ygrp-lc .yiv7980109103ad 
{margin-bottom:10px;padding:0 0;}#yiv7980109103 #yiv7980109103actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7980109103 
#yiv7980109103activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7980109103
 #yiv7980109103activity span {font-weight:700;}#yiv7980109103 
#yiv7980109103activity span:first-child 
{text-transform:uppercase;}#yiv7980109103 #yiv7980109103activity span a 
{color:#5085b6;text-decoration:none;}#yiv7980109103 #yiv7980109103activity span 
span {color:#ff7900;}#yiv7980109103 #yiv7980109103activity span 
.yiv7980109103underline {text-decoration:underline;}#yiv7980109103 
.yiv7980109103attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv7980109103 .yiv7980109103attach div a 
{text-decoration:none;}#yiv7980109103 .yiv7980109103attach img 
{border:none;padding-right:5px;}#yiv7980109103 .yiv7980109103attach label 
{display:block;margin-bottom:5px;}#yiv7980109103 .yiv7980109103attach label a 
{text-decoration:none;}#yiv7980109103 blockquote {margin:0 0 0 
4px;}#yiv7980109103 .yiv7980109103bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv7980109103 
.yiv7980109103bold a {text-decoration:none;}#yiv7980109103 dd.yiv7980109103last 
p a {font-family:Verdana;font-weight:700;}#yiv7980109103 dd.yiv7980109103last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv7980109103 
dd.yiv7980109103last p span.yiv7980109103yshortcuts 
{margin-right:0;}#yiv7980109103 div.yiv7980109103attach-table div div a 
{text-decoration:none;}#yiv7980109103 div.yiv7980109103attach-table 
{width:400px;}#yiv7980109103 div.yiv7980109103file-title a, #yiv7980109103 
div.yiv7980109103file-title a:active, #yiv7980109103 
div.yiv7980109103file-title a:hover, #yiv7980109103 div.yiv7980109103file-title 
a:visited {text-decoration:none;}#yiv7980109103 div.yiv7980109103photo-title a, 
#yiv7980109103 div.yiv7980109103photo-title a:active, #yiv7980109103 
div.yiv7980109103photo-title a:hover, #yiv7980109103 
div.yiv7980109103photo-title a:visited {text-decoration:none;}#yiv7980109103 
div#yiv7980109103ygrp-mlmsg #yiv7980109103ygrp-msg p a 
span.yiv7980109103yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv7980109103 
.yiv7980109103green {color:#628c2a;}#yiv7980109103 .yiv7980109103MsoNormal 
{margin:0 0 0 0;}#yiv7980109103 o {font-size:0;}#yiv7980109103 
#yiv7980109103photos div {float:left;width:72px;}#yiv7980109103 
#yiv7980109103photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv7980109103 
#yiv7980109103photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv7980109103
 #yiv7980109103reco-category 

[oracle_br] Upgrade 9i para 12cR1

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Senhores, bom dia.
Hoje veio um pedido de um cliente querendo atualizar o banco de dados da versao 
9i para uma versao igual ou maior a versao 10gR2. 
Solicitei que o mesmo especificasse em qual versao ele gostaria de atualizar 
(sugerindo a versao 12cR1 ou 12cR2), pergutnando tb se a aplicacao foi validada 
nas versoes superiores.
A minha duvida eh a seguinte: Quais sao os passos para realizar esse upgrade? 
Pois tambem existe uma atualizacao de Sistema operacional no jogo para mater a 
compatibilidade com o banco de dados.


 Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production (standalone)
AIX 3 5 

Re: [oracle_br] Re: Troubleshooting scheduler JOB

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Chiappa, eu nunca crio jobs com o SYS, mas como esse JOB eh para coleta de 
estatistica, e o JOB GATHER_STATS_JOB na antiga versao 10g o owner era o SYS, 
eu quis seguir o padrao, colocando o dono como SYS, mas via de regra, eu nao 
crio nada no database com owner SYS.
Eu vou dar uma olhada no link enviado e dou uma resposta aqui.
Em quinta-feira, 12 de abril de 2018 17:57:09 BRT, jlchia...@yahoo.com.br 
[oracle_br]  escreveu:  
 
     
Bom, olhando por cima sem detalhar muito a PRIMEIRA COISA que vi é que vc usou 
o SYS pra criar teus programas/objetos : PLEASE NÃO FAÇA ISSO!! NUNCA!! O SYS é 
especial, o SYS muitas vezes tem EXCEÇõES à auditorias e programações internas 
do banco, NÂO O USE PRA NADA seu, sim sim ???
 
 A minha Recomendação é : 
 
 1. COM OUTRO usuário que não o SYS, siga meu exemplo de CHAIN em 
http://www.profissionaloracle.com.br/gpo/servicos/forum/3-banco-oracle-sql-e-pl-sql/32164-dbms-scheduler-add-job-email-notification-to-file?limitstart=0=10
 : se funcionar OK, vc CONFIRMOU que os parãmetros relacionados a JOBs estão ok
 
 2. se o teste acima foi OK, COM esse OUTRO usuário recrie o seu chain, by the 
book e passo-a-passo , primeiro Permissionando via usuário administrador teu 
usuário que não o SYS, depois conecta com teu usuário não-SYS e cria as 
tabelas/procedures eventualmente necessárias, depois cria os programs, depois o 
create chain, depois define os steps, depois cria a RULE e Só Então habilite o 
chain e crie o JOB que vai disparar esse chain Habilitado... TEM que ser passo 
a passo e NESSA sequência...
 
 []s
 
   Chiappa
  #yiv4437430891 #yiv4437430891 -- #yiv4437430891ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4437430891 
#yiv4437430891ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4437430891 
#yiv4437430891ygrp-mkp #yiv4437430891hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4437430891 #yiv4437430891ygrp-mkp #yiv4437430891ads 
{margin-bottom:10px;}#yiv4437430891 #yiv4437430891ygrp-mkp .yiv4437430891ad 
{padding:0 0;}#yiv4437430891 #yiv4437430891ygrp-mkp .yiv4437430891ad p 
{margin:0;}#yiv4437430891 #yiv4437430891ygrp-mkp .yiv4437430891ad a 
{color:#ff;text-decoration:none;}#yiv4437430891 #yiv4437430891ygrp-sponsor 
#yiv4437430891ygrp-lc {font-family:Arial;}#yiv4437430891 
#yiv4437430891ygrp-sponsor #yiv4437430891ygrp-lc #yiv4437430891hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4437430891 
#yiv4437430891ygrp-sponsor #yiv4437430891ygrp-lc .yiv4437430891ad 
{margin-bottom:10px;padding:0 0;}#yiv4437430891 #yiv4437430891actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4437430891 
#yiv4437430891activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4437430891
 #yiv4437430891activity span {font-weight:700;}#yiv4437430891 
#yiv4437430891activity span:first-child 
{text-transform:uppercase;}#yiv4437430891 #yiv4437430891activity span a 
{color:#5085b6;text-decoration:none;}#yiv4437430891 #yiv4437430891activity span 
span {color:#ff7900;}#yiv4437430891 #yiv4437430891activity span 
.yiv4437430891underline {text-decoration:underline;}#yiv4437430891 
.yiv4437430891attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv4437430891 .yiv4437430891attach div a 
{text-decoration:none;}#yiv4437430891 .yiv4437430891attach img 
{border:none;padding-right:5px;}#yiv4437430891 .yiv4437430891attach label 
{display:block;margin-bottom:5px;}#yiv4437430891 .yiv4437430891attach label a 
{text-decoration:none;}#yiv4437430891 blockquote {margin:0 0 0 
4px;}#yiv4437430891 .yiv4437430891bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4437430891 
.yiv4437430891bold a {text-decoration:none;}#yiv4437430891 dd.yiv4437430891last 
p a {font-family:Verdana;font-weight:700;}#yiv4437430891 dd.yiv4437430891last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4437430891 
dd.yiv4437430891last p span.yiv4437430891yshortcuts 
{margin-right:0;}#yiv4437430891 div.yiv4437430891attach-table div div a 
{text-decoration:none;}#yiv4437430891 div.yiv4437430891attach-table 
{width:400px;}#yiv4437430891 div.yiv4437430891file-title a, #yiv4437430891 
div.yiv4437430891file-title a:active, #yiv4437430891 
div.yiv4437430891file-title a:hover, #yiv4437430891 div.yiv4437430891file-title 
a:visited {text-decoration:none;}#yiv4437430891 div.yiv4437430891photo-title a, 
#yiv4437430891 div.yiv4437430891photo-title a:active, #yiv4437430891 
div.yiv4437430891photo-title a:hover, #yiv4437430891 
div.yiv4437430891photo-title a:visited {text-decoration:none;}#yiv4437430891 
div#yiv4437430891ygrp-mlmsg #yiv4437430891ygrp-msg p a 
span.yiv4437430891yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv4437430891 
.yiv4437430891green {color:#628c2a;}#yiv4437430891 .yiv4437430891MsoNormal 
{margin:0 0 0 0;}#yiv4437430891 o 

[oracle_br] Troubleshooting scheduler JOB

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Cenário: oracle EE 11.2.0.4
Senhores, boa tarde.
Existe um Scheduler Job Chains que foi criado e nao esta rodando. Nao consegui 
identificar o motivo do JOB não rodar no agendamento indicado, segue:

caso esteja dificil a visualizacao, upei o troubleshooting nesse txt: Untitled 
- Text Share Hosting online free

| 
| 
|  | 
Untitled - Text Share Hosting online free


 |

 |

 |





** DBA_SCHEDULER_JOBS
OWNER      JOB_NAME          JOB_TYPE     START_DATE          REPEAT_INTERVAL   
     END_DATE            ENABL AUTO_ STATE         MR    FC    MF    RC 
Last_Started-- -  --- 
-- --- - - -- - - 
- - ---SYS        GATHER_STATS      CHAIN        
11-04-2018 15:30    FREQ=DAILY; BYHOUR=21                      TRUE  TRUE  
SCHEDULED            0           0




** dba_scheduler_chains
OWNER      CHAIN_NAME              RULE_SET_O RULE_SET_NAME   NUMBER_OF_RULES 
NUMBER_OF_STEPS ENABL -- --- -- 
--- --- --- - SYS        
JOB_CHAIN_GATHER_STATS  SYS        SCHED_RULESET$1               3              
 2 TRUE  


** dba_scheduler_chain_steps

OWNER      CHAIN_NAME                STEP_NAME       PROGRAM_OW PROGRAM_NAME    
STEP_TYPE-- - --- -- 
--- --
SYS        JOB_CHAIN_GATHER_STATS    ETAPA_1         SYS        GET_STATS_EMPTY 
PROGRAMSYS        JOB_CHAIN_GATHER_STATS    ETAPA_2         SYS        
GET_STATS_STALE PROGRAM


** dba_scheduler_chain_rules

OWNER      CHAIN_NAME               RULE_OWNER RULE_NAME       CONDITION        
         ACTION
--  -- --- 
- 

SYS        JOB_CHAIN_GATHER_STATS   SYS        REGRA_1         TRUE             
            START "ETAPA_1"
SYS        JOB_CHAIN_GATHER_STATS   SYS        REGRA_2         Etapa_1 
COMPLETED            START "ETAPA_2"
SYS        JOB_CHAIN_GATHER_STATS   SYS        REGRA_3_FINAL   Etapa_1 
COMPLETED and Etapa_2 COMPLETED   END




**DBA_SCHEDULER_JOB_RUN_DETAILS

no rows selected

[oracle_br] Comparar quantidade de sessões ativas

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

SEnhores, bom dia.
Indo direto ao ponto, gostaria de saber se vocês possuem uma query ou me 
ajudassem a construir uma query que fizesse a comparação da qtd de sessões 
ativas e TOTAL(sessoes ativas e inativas) de um período com um outro período.
Sei que isso deve ser feito utilizando a v$active_session_history (se os dados 
estao ainda em memoria) ou na dba_hist_active_sess_history. 

Exemplo:
A quantidade usuários ativos ontem as 15 horas e a quantidade de usuários 
ativos hoje as 15 horas.E se possível a quantidade de usuários conectados 
(sessoes ativas e nao ativas).
Eu sei que no AWR report você consegue visualizar, mas eu gostaria da consulta.
SEi tb que para acessar as views eh necessario a option DP.
Obrigado.

Re: Fw: Re: [oracle_br] Change owner catalog

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Ok Chiappa, muito obrigado.
Em quarta-feira, 14 de março de 2018 15:49:49 BRT, jlchia...@yahoo..com.br 
[oracle_br]  escreveu:  
 
     
Um detalhe adicional importante : iirc tinham umas incompatibilidades de 
clients RMAN anteriores a 12c com Pluggable Databases : acho que isso já foi 
consertado mas por via das dúvidas RECOMENDO assim esse banco 12c que vc vai 
criar só pra guardar o catálogo 12c não deve ser um PDB - já instala e cria o 
banco 12c como NÂO CONTEINER, pra não dar chance

 []s
 
   Chiappa
  #yiv4640630887 #yiv4640630887 -- #yiv4640630887ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4640630887 
#yiv4640630887ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4640630887 
#yiv4640630887ygrp-mkp #yiv4640630887hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4640630887 #yiv4640630887ygrp-mkp #yiv4640630887ads 
{margin-bottom:10px;}#yiv4640630887 #yiv4640630887ygrp-mkp .yiv4640630887ad 
{padding:0 0;}#yiv4640630887 #yiv4640630887ygrp-mkp .yiv4640630887ad p 
{margin:0;}#yiv4640630887 #yiv4640630887ygrp-mkp .yiv4640630887ad a 
{color:#ff;text-decoration:none;}#yiv4640630887 #yiv4640630887ygrp-sponsor 
#yiv4640630887ygrp-lc {font-family:Arial;}#yiv4640630887 
#yiv4640630887ygrp-sponsor #yiv4640630887ygrp-lc #yiv4640630887hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4640630887 
#yiv4640630887ygrp-sponsor #yiv4640630887ygrp-lc .yiv4640630887ad 
{margin-bottom:10px;padding:0 0;}#yiv4640630887 #yiv4640630887actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4640630887 
#yiv4640630887activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4640630887
 #yiv4640630887activity span {font-weight:700;}#yiv4640630887 
#yiv4640630887activity span:first-child 
{text-transform:uppercase;}#yiv4640630887 #yiv4640630887activity span a 
{color:#5085b6;text-decoration:none;}#yiv4640630887 #yiv4640630887activity span 
span {color:#ff7900;}#yiv4640630887 #yiv4640630887activity span 
.yiv4640630887underline {text-decoration:underline;}#yiv4640630887 
.yiv4640630887attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv4640630887 .yiv4640630887attach div a 
{text-decoration:none;}#yiv4640630887 .yiv4640630887attach img 
{border:none;padding-right:5px;}#yiv4640630887 .yiv4640630887attach label 
{display:block;margin-bottom:5px;}#yiv4640630887 .yiv4640630887attach label a 
{text-decoration:none;}#yiv4640630887 blockquote {margin:0 0 0 
4px;}#yiv4640630887 .yiv4640630887bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4640630887 
.yiv4640630887bold a {text-decoration:none;}#yiv4640630887 dd.yiv4640630887last 
p a {font-family:Verdana;font-weight:700;}#yiv4640630887 dd.yiv4640630887last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4640630887 
dd.yiv4640630887last p span.yiv4640630887yshortcuts 
{margin-right:0;}#yiv4640630887 div.yiv4640630887attach-table div div a 
{text-decoration:none;}#yiv4640630887 div.yiv4640630887attach-table 
{width:400px;}#yiv4640630887 div.yiv4640630887file-title a, #yiv4640630887 
div.yiv4640630887file-title a:active, #yiv4640630887 
div.yiv4640630887file-title a:hover, #yiv4640630887 div.yiv4640630887file-title 
a:visited {text-decoration:none;}#yiv4640630887 div.yiv4640630887photo-title a, 
#yiv4640630887 div.yiv4640630887photo-title a:active, #yiv4640630887 
div.yiv4640630887photo-title a:hover, #yiv4640630887 
div.yiv4640630887photo-title a:visited {text-decoration:none;}#yiv4640630887 
div#yiv4640630887ygrp-mlmsg #yiv4640630887ygrp-msg p a 
span.yiv4640630887yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv4640630887 
.yiv4640630887green {color:#628c2a;}#yiv4640630887 .yiv4640630887MsoNormal 
{margin:0 0 0 0;}#yiv4640630887 o {font-size:0;}#yiv4640630887 
#yiv4640630887photos div {float:left;width:72px;}#yiv4640630887 
#yiv4640630887photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv4640630887 
#yiv4640630887photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv4640630887
 #yiv4640630887reco-category {font-size:77%;}#yiv4640630887 
#yiv4640630887reco-desc {font-size:77%;}#yiv4640630887 .yiv4640630887replbq 
{margin:4px;}#yiv4640630887 #yiv4640630887ygrp-actbar div a:first-child 
{margin-right:2px;padding-right:5px;}#yiv4640630887 #yiv4640630887ygrp-mlmsg 
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv4640630887 
#yiv4640630887ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv4640630887 
#yiv4640630887ygrp-mlmsg select, #yiv4640630887 input, #yiv4640630887 textarea 
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv4640630887 
#yiv4640630887ygrp-mlmsg pre, #yiv4640630887 code {font:115% 
monospace;}#yiv4640630887 #yiv4640630887ygrp-mlmsg * 

Re: Fw: Re: [oracle_br] Change owner catalog

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Então irei instalar o 12.1.0.2 nesse mesmo servidor em um outro Oracle_home. 
Irei criar um banco que ira ser o catalogo de recuperação e irei importar todos 
os catalogos que possuo no banco 11.2.0.3 (catalogos na versao 11.2.0.3 e 
11.2.0.4) para esse novo catalogo na versao 12.1.0.2.
Irei seguir essa recomendação.
Em quarta-feira, 14 de março de 2018 09:34:37 BRT, jlchia...@yahoo..com.br 
[oracle_br]  escreveu:  
 
     
Uma obs adicional : é exigido que o catálogo RMAN (e o database que o contém) 
sejam no mínimo da mesma versão ou (preferencialmente) de versão Superior aos 
targets E aos catálogos anteriores que porventura vc queira importar : então, 
se hoje o database mais recente que vc quer ter como target no RMAN é 11.2.0.4 
, em tese vc poderia sim ter esse banco onde hoje vc tem seus catálogos 
upgradeado para 11.2.0.4 e ENTÃO criar nele um novo catálogo 11.02.00.04...
 Porém, cedo ou tarde vc VAI acabar tendo algum banco 12c na parada, então pra 
EVITAR retrabalho no futuro próximo minha Recomendação seria vc já criar um 
banquinho 12c aí nesse servidor (o banco que vai servir apenas e tão somente de 
repositório de catálogos RMAN não consome taaanto recurso do servidor, não), 
criar uma catálogo 12c nesse banco 12c e não se preocupar com versão por um bom 
tempo...
 O unico senão é se vc tiver um banco 9i ou 10gR1 ainda perdido no seu ambiente 
: cfrme 
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/rcmrf/rman-compatibility.html#GUID-7A453809-3FB2-4126-AB6F-F8C24C8F8879,
 a Compatibilidade de catálogos rman 12c só é  garantida para clients RMAN (e 
versões de banco target) acima de 10.1.0.5 . 
 
 []s
 
  Chiappa
  #yiv9624666562 #yiv9624666562 -- #yiv9624666562ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9624666562 
#yiv9624666562ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9624666562 
#yiv9624666562ygrp-mkp #yiv9624666562hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9624666562 #yiv9624666562ygrp-mkp #yiv9624666562ads 
{margin-bottom:10px;}#yiv9624666562 #yiv9624666562ygrp-mkp .yiv9624666562ad 
{padding:0 0;}#yiv9624666562 #yiv9624666562ygrp-mkp .yiv9624666562ad p 
{margin:0;}#yiv9624666562 #yiv9624666562ygrp-mkp .yiv9624666562ad a 
{color:#ff;text-decoration:none;}#yiv9624666562 #yiv9624666562ygrp-sponsor 
#yiv9624666562ygrp-lc {font-family:Arial;}#yiv9624666562 
#yiv9624666562ygrp-sponsor #yiv9624666562ygrp-lc #yiv9624666562hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9624666562 
#yiv9624666562ygrp-sponsor #yiv9624666562ygrp-lc .yiv9624666562ad 
{margin-bottom:10px;padding:0 0;}#yiv9624666562 #yiv9624666562actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9624666562 
#yiv9624666562activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9624666562
 #yiv9624666562activity span {font-weight:700;}#yiv9624666562 
#yiv9624666562activity span:first-child 
{text-transform:uppercase;}#yiv9624666562 #yiv9624666562activity span a 
{color:#5085b6;text-decoration:none;}#yiv9624666562 #yiv9624666562activity span 
span {color:#ff7900;}#yiv9624666562 #yiv9624666562activity span 
.yiv9624666562underline {text-decoration:underline;}#yiv9624666562 
.yiv9624666562attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9624666562 .yiv9624666562attach div a 
{text-decoration:none;}#yiv9624666562 .yiv9624666562attach img 
{border:none;padding-right:5px;}#yiv9624666562 .yiv9624666562attach label 
{display:block;margin-bottom:5px;}#yiv9624666562 .yiv9624666562attach label a 
{text-decoration:none;}#yiv9624666562 blockquote {margin:0 0 0 
4px;}#yiv9624666562 .yiv9624666562bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9624666562 
.yiv9624666562bold a {text-decoration:none;}#yiv9624666562 dd.yiv9624666562last 
p a {font-family:Verdana;font-weight:700;}#yiv9624666562 dd.yiv9624666562last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9624666562 
dd.yiv9624666562last p span.yiv9624666562yshortcuts 
{margin-right:0;}#yiv9624666562 div.yiv9624666562attach-table div div a 
{text-decoration:none;}#yiv9624666562 div.yiv9624666562attach-table 
{width:400px;}#yiv9624666562 div.yiv9624666562file-title a, #yiv9624666562 
div.yiv9624666562file-title a:active, #yiv9624666562 
div.yiv9624666562file-title a:hover, #yiv9624666562 div.yiv9624666562file-title 
a:visited {text-decoration:none;}#yiv9624666562 div.yiv9624666562photo-title a, 
#yiv9624666562 div.yiv9624666562photo-title a:active, #yiv9624666562 
div.yiv9624666562photo-title a:hover, #yiv9624666562 
div.yiv9624666562photo-title a:visited {text-decoration:none;}#yiv9624666562 
div#yiv9624666562ygrp-mlmsg #yiv9624666562ygrp-msg p a 
span.yiv9624666562yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9624666562 
.yiv9624666562green 

Re: Fw: Re: [oracle_br] Change owner catalog

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 EU instalando um software do rdbms Oracle 12.1.0.2, criando um banco nessa 
versao e um catalogo, eu consigo importar os dados dos diversos catalogos que 
possuo nesse atual database que estao em versoes 11.2.0.3 ou 11.2.0.4? 
Em quarta-feira, 14 de março de 2018 08:22:44 BRT, jlchia...@yahoo..com.br 
[oracle_br]  escreveu:  
 
     
Seguinte :

"Agora, fica a minha pergunta: Como o catalogo do "Antigo" owner ta 11.2.0.4 se 
o database do catalogo ainda esta na 11.2.0.3?"

Simples : ALGUÉM em algum momento conectou nesse catálogo com um rman 11.2.0.4 
e mandou um UPGRADE CATALOG, simples assim - sozinho é que ele NÃO SE 
UPGRADEIA, isso eu garanto...

"Como faço para atualizar o catalogo "novo" para a versao 11.2.0.4 já que o 
"antigo' owner está na 11.2.0.4 e todos dois pertencem ao mesmo database que 
está na versão 11.2.0.3."

==> Na verdade, AINDA que vc suba esse catálogo novo pra 11.02.00.04 vc AINDA 
pode ter problemas pelo fato do database ser 11.2.0.3 - Vc TEM que passar o 
database para 11.2.0.4 e APÓS ISSO rodar o uPGRADE desse catálogo 'novo', é 
isso  OU se quiser, cria um novo catálogo 11.02.00.04 num novo database 
11.2.0.4 que vc crie e importa lá, é isso... 

[]s

  Chiappa
  #yiv8815765869 #yiv8815765869 -- #yiv8815765869ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8815765869 
#yiv8815765869ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8815765869 
#yiv8815765869ygrp-mkp #yiv8815765869hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8815765869 #yiv8815765869ygrp-mkp #yiv8815765869ads 
{margin-bottom:10px;}#yiv8815765869 #yiv8815765869ygrp-mkp .yiv8815765869ad 
{padding:0 0;}#yiv8815765869 #yiv8815765869ygrp-mkp .yiv8815765869ad p 
{margin:0;}#yiv8815765869 #yiv8815765869ygrp-mkp .yiv8815765869ad a 
{color:#ff;text-decoration:none;}#yiv8815765869 #yiv8815765869ygrp-sponsor 
#yiv8815765869ygrp-lc {font-family:Arial;}#yiv8815765869 
#yiv8815765869ygrp-sponsor #yiv8815765869ygrp-lc #yiv8815765869hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8815765869 
#yiv8815765869ygrp-sponsor #yiv8815765869ygrp-lc .yiv8815765869ad 
{margin-bottom:10px;padding:0 0;}#yiv8815765869 #yiv8815765869actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8815765869 
#yiv8815765869activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8815765869
 #yiv8815765869activity span {font-weight:700;}#yiv8815765869 
#yiv8815765869activity span:first-child 
{text-transform:uppercase;}#yiv8815765869 #yiv8815765869activity span a 
{color:#5085b6;text-decoration:none;}#yiv8815765869 #yiv8815765869activity span 
span {color:#ff7900;}#yiv8815765869 #yiv8815765869activity span 
.yiv8815765869underline {text-decoration:underline;}#yiv8815765869 
.yiv8815765869attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv8815765869 .yiv8815765869attach div a 
{text-decoration:none;}#yiv8815765869 .yiv8815765869attach img 
{border:none;padding-right:5px;}#yiv8815765869 .yiv8815765869attach label 
{display:block;margin-bottom:5px;}#yiv8815765869 .yiv8815765869attach label a 
{text-decoration:none;}#yiv8815765869 blockquote {margin:0 0 0 
4px;}#yiv8815765869 .yiv8815765869bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8815765869 
.yiv8815765869bold a {text-decoration:none;}#yiv8815765869 dd.yiv8815765869last 
p a {font-family:Verdana;font-weight:700;}#yiv8815765869 dd.yiv8815765869last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8815765869 
dd.yiv8815765869last p span.yiv8815765869yshortcuts 
{margin-right:0;}#yiv8815765869 div.yiv8815765869attach-table div div a 
{text-decoration:none;}#yiv8815765869 div.yiv8815765869attach-table 
{width:400px;}#yiv8815765869 div.yiv8815765869file-title a, #yiv8815765869 
div.yiv8815765869file-title a:active, #yiv8815765869 
div.yiv8815765869file-title a:hover, #yiv8815765869 div.yiv8815765869file-title 
a:visited {text-decoration:none;}#yiv8815765869 div.yiv8815765869photo-title a, 
#yiv8815765869 div.yiv8815765869photo-title a:active, #yiv8815765869 
div.yiv8815765869photo-title a:hover, #yiv8815765869 
div.yiv8815765869photo-title a:visited {text-decoration:none;}#yiv8815765869 
div#yiv8815765869ygrp-mlmsg #yiv8815765869ygrp-msg p a 
span.yiv8815765869yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8815765869 
.yiv8815765869green {color:#628c2a;}#yiv8815765869 .yiv8815765869MsoNormal 
{margin:0 0 0 0;}#yiv8815765869 o {font-size:0;}#yiv8815765869 
#yiv8815765869photos div {float:left;width:72px;}#yiv8815765869 
#yiv8815765869photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv8815765869 
#yiv8815765869photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv8815765869
 #yiv8815765869reco-category 

Re: Fw: Re: [oracle_br] Change owner catalog

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 a) no mesmo database vc tem um catálogo RMAN "novo" e um catálogo RMAN "velho" 
, e vc quer importar os metadados desse catálogo 'velho' no catálogo novo ?? 


Exatamente isso.
b) * qual ** é a versão desse database ?? Qual é e versão do catálogo 'velho' e 
do 'novo' ??
Versao do banco do catalogo = 11.2.0.3.3Versao do target database: 11.2.0.4.


Versao do "velho" catalogo

SYS@rmngrprd>select * from user_antigo.rcver;
VERSION11.02.00.04

Versao do "novo" catalogo:


SYS@rmngrprd>select * from user_catalog.rcver;
VERSION11.02.00.03


Agora, fica a minha pergunta: Como o catalogo do "Antigo" owner ta 11.2.0.4 se 
o database do catalogo ainda esta na 11.2.0.3Como faço para atualizar o 
catalogo "novo" para a versao 11.2.0.4 já que o "antigo' owner está na 11.2.0.4 
e todos dois pertencem ao mesmo database que está na versão 11.2.0.3.








Em terça-feira, 13 de março de 2018 17:27:54 BRT, jlchia...@yahoo.com.br 
[oracle_br]  escreveu:  
 
     
Tá : no mesmo database vc tem um catálogo RMAN "novo" e um catálogo RMAN 
"velho" , e vc quer importar os metadados desse catálogo 'velho' no catálogo 
novo ?? 

 Se é isso, pergunto : ** qual ** é a versão desse database ?? Qual é e versão 
do catálogo 'velho' e do 'novo' ?? Pra que funcione, esse database TEM que ser 
11.2.0.4 (se esta é a versão mais recente possível de target database que vc 
vai backupear, acho que é se me lembro), E a versão desse catálogo 'novo' TEM 
que ser 11.02.00.04, é ESTA versão de catálogo que é compatível com databases 
11.2.0.4... Essa msg :
 
 DBMS_RCVCAT package version 11.02.00.04 in source database is not of version 
11.02.00.03
 
 parece indicar que Não É esse o caso aí no seu ambiente
 
 ==> Outra crítica a fazer no seu output é que eu NÃO VI o DBID do banco cujos 
metadados de backup vc quer importar : não lembro se isso é Obrigatório ou não 
mas tenta com ele .
 
 E sempre, prestar ATENÇÃO se vc informou MESMO os nomes antigo e novo 
corretos, E se certifique que eles são DIFERENTES...
 
 []s
 
   Chiappa
  
  #yiv5835690105 #yiv5835690105 -- #yiv5835690105ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5835690105 
#yiv5835690105ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5835690105 
#yiv5835690105ygrp-mkp #yiv5835690105hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5835690105 #yiv5835690105ygrp-mkp #yiv5835690105ads 
{margin-bottom:10px;}#yiv5835690105 #yiv5835690105ygrp-mkp .yiv5835690105ad 
{padding:0 0;}#yiv5835690105 #yiv5835690105ygrp-mkp .yiv5835690105ad p 
{margin:0;}#yiv5835690105 #yiv5835690105ygrp-mkp .yiv5835690105ad a 
{color:#ff;text-decoration:none;}#yiv5835690105 #yiv5835690105ygrp-sponsor 
#yiv5835690105ygrp-lc {font-family:Arial;}#yiv5835690105 
#yiv5835690105ygrp-sponsor #yiv5835690105ygrp-lc #yiv5835690105hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5835690105 
#yiv5835690105ygrp-sponsor #yiv5835690105ygrp-lc .yiv5835690105ad 
{margin-bottom:10px;padding:0 0;}#yiv5835690105 #yiv5835690105actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5835690105 
#yiv5835690105activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5835690105
 #yiv5835690105activity span {font-weight:700;}#yiv5835690105 
#yiv5835690105activity span:first-child 
{text-transform:uppercase;}#yiv5835690105 #yiv5835690105activity span a 
{color:#5085b6;text-decoration:none;}#yiv5835690105 #yiv5835690105activity span 
span {color:#ff7900;}#yiv5835690105 #yiv5835690105activity span 
.yiv5835690105underline {text-decoration:underline;}#yiv5835690105 
.yiv5835690105attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv5835690105 .yiv5835690105attach div a 
{text-decoration:none;}#yiv5835690105 .yiv5835690105attach img 
{border:none;padding-right:5px;}#yiv5835690105 .yiv5835690105attach label 
{display:block;margin-bottom:5px;}#yiv5835690105 .yiv5835690105attach label a 
{text-decoration:none;}#yiv5835690105 blockquote {margin:0 0 0 
4px;}#yiv5835690105 .yiv5835690105bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5835690105 
.yiv5835690105bold a {text-decoration:none;}#yiv5835690105 dd.yiv5835690105last 
p a {font-family:Verdana;font-weight:700;}#yiv5835690105 dd.yiv5835690105last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5835690105 
dd.yiv5835690105last p span.yiv5835690105yshortcuts 
{margin-right:0;}#yiv5835690105 div.yiv5835690105attach-table div div a 
{text-decoration:none;}#yiv5835690105 div.yiv5835690105attach-table 
{width:400px;}#yiv5835690105 div.yiv5835690105file-title a, #yiv5835690105 
div.yiv5835690105file-title a:active, #yiv5835690105 
div.yiv5835690105file-title a:hover, #yiv5835690105 div.yiv5835690105file-title 
a:visited {text-decoration:none;}#yiv5835690105 div.yiv5835690105photo-title a, 
#yiv5835690105 

Re: Fw: Re: [oracle_br] Change owner catalog

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 PQ os owners pertencem ao mesmo database Chiappa.
Em terça-feira, 13 de março de 2018 16:41:14 BRT, jlchia...@yahoo.com.br 
[oracle_br]  escreveu:  
 
     
Blz ? PMFJI mas apesar de não ter uma situação que nem a sua pra testar, quero 
colocar alguns pontos :

a. NÃO SÓ o database aonde reside o 'novo' catálogo MAS TAMBÉM ele mesmo tem 
que ser de Versão Compatível : sei que (por exemplo) catalog versão 11.x é 
compatível com banco 11.x, um database 10.2.x PODE se registrar nesse catálogo  
E por sua vez ele pode importar metadados de um catálogo rman 10.2... VERIFIQUE 
EXATAMENTE qual versão de RDBMS vc está usando no banco que contém esse 'novo' 
catálogo E CHEQUE em qual versão de catalog esse novo catálogo está ...
 Msgs tal como :
 
 DBMS_RCVCAT package version 11.02.00.04 in source database is not of version 
11.02.00.03
 
 pra mim mostram que vc está tentando usar um catpalogo 11.2.0.3 num database 
11.2.0.4, não rola... 

b. no exemplo do manual 11gR2 ele claramente mostra :

RMAN> CONNECT CATALOG rco@catdb

 
RMAN> IMPORT CATALOG rcat@inst1 DBID=1618984270;

==> esse @hoststring NÂO ESTÀ LÁ de bobeira : sem indicar ele , como vc fez no 
seu exemplo :

RMAN> connect catalog user_catalog/xxx
RMAN> import catalog USER_ANTIGO/xxx;

==> como é que o RMAN vai saber os dados de conexão ?? 
 

[]s

  Chiappa
  #yiv5923433022 #yiv5923433022 -- #yiv5923433022ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5923433022 
#yiv5923433022ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5923433022 
#yiv5923433022ygrp-mkp #yiv5923433022hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5923433022 #yiv5923433022ygrp-mkp #yiv5923433022ads 
{margin-bottom:10px;}#yiv5923433022 #yiv5923433022ygrp-mkp .yiv5923433022ad 
{padding:0 0;}#yiv5923433022 #yiv5923433022ygrp-mkp .yiv5923433022ad p 
{margin:0;}#yiv5923433022 #yiv5923433022ygrp-mkp .yiv5923433022ad a 
{color:#ff;text-decoration:none;}#yiv5923433022 #yiv5923433022ygrp-sponsor 
#yiv5923433022ygrp-lc {font-family:Arial;}#yiv5923433022 
#yiv5923433022ygrp-sponsor #yiv5923433022ygrp-lc #yiv5923433022hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5923433022 
#yiv5923433022ygrp-sponsor #yiv5923433022ygrp-lc .yiv5923433022ad 
{margin-bottom:10px;padding:0 0;}#yiv5923433022 #yiv5923433022actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5923433022 
#yiv5923433022activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5923433022
 #yiv5923433022activity span {font-weight:700;}#yiv5923433022 
#yiv5923433022activity span:first-child 
{text-transform:uppercase;}#yiv5923433022 #yiv5923433022activity span a 
{color:#5085b6;text-decoration:none;}#yiv5923433022 #yiv5923433022activity span 
span {color:#ff7900;}#yiv5923433022 #yiv5923433022activity span 
.yiv5923433022underline {text-decoration:underline;}#yiv5923433022 
.yiv5923433022attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv5923433022 .yiv5923433022attach div a 
{text-decoration:none;}#yiv5923433022 .yiv5923433022attach img 
{border:none;padding-right:5px;}#yiv5923433022 .yiv5923433022attach label 
{display:block;margin-bottom:5px;}#yiv5923433022 .yiv5923433022attach label a 
{text-decoration:none;}#yiv5923433022 blockquote {margin:0 0 0 
4px;}#yiv5923433022 .yiv5923433022bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5923433022 
.yiv5923433022bold a {text-decoration:none;}#yiv5923433022 dd.yiv5923433022last 
p a {font-family:Verdana;font-weight:700;}#yiv5923433022 dd.yiv5923433022last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5923433022 
dd.yiv5923433022last p span.yiv5923433022yshortcuts 
{margin-right:0;}#yiv5923433022 div.yiv5923433022attach-table div div a 
{text-decoration:none;}#yiv5923433022 div.yiv5923433022attach-table 
{width:400px;}#yiv5923433022 div.yiv5923433022file-title a, #yiv5923433022 
div.yiv5923433022file-title a:active, #yiv5923433022 
div.yiv5923433022file-title a:hover, #yiv5923433022 div.yiv5923433022file-title 
a:visited {text-decoration:none;}#yiv5923433022 div.yiv5923433022photo-title a, 
#yiv5923433022 div.yiv5923433022photo-title a:active, #yiv5923433022 
div.yiv5923433022photo-title a:hover, #yiv5923433022 
div.yiv5923433022photo-title a:visited {text-decoration:none;}#yiv5923433022 
div#yiv5923433022ygrp-mlmsg #yiv5923433022ygrp-msg p a 
span.yiv5923433022yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5923433022 
.yiv5923433022green {color:#628c2a;}#yiv5923433022 .yiv5923433022MsoNormal 
{margin:0 0 0 0;}#yiv5923433022 o {font-size:0;}#yiv5923433022 
#yiv5923433022photos div {float:left;width:72px;}#yiv5923433022 
#yiv5923433022photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv5923433022 
#yiv5923433022photos div label 

Fw: Re: [oracle_br] Change owner catalog

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Rodrigo, boa tarde.
Muito obrigado pela informação.
Como na doc fala:
"RMAN must be connected to the destination recovery catalog, which is the 
catalog into which you want to import catalog data""No target database 
connection is needed to merge catalog schemas"
Então fiz:
rman target /RMAN> connect catalog user_catalog/xxx
RMAN> import catalog USER_ANTIGO/xxx;
Starting import catalog at 13-MAR-18connected to source recovery catalog 
databaseDBMS_RCVCAT package version 11.02.00.04 in source database is not of 
version 11.02.00.03RMAN-00571: 
===RMAN-00569: 
=== ERROR MESSAGE STACK FOLLOWS ===RMAN-00571: 
===RMAN-03002: failure 
of import catalog command at 03/13/2018 14:06:01RMAN-06429: IMPCAT database is 
not compatible with this version of RMAN

RMAN> upgrade catalog;upgrade catalog;

recovery catalog upgraded to version 11.02.00.03
DBMS_RCVMAN package upgraded to version 11.02.00.03DBMS_RCVCAT package upgraded 
to version 11.02.00.03


RMAN> connect catalog ELIPSEPRD151164/rmngrprd
connected to recovery catalog database
RMAN> upgrade catalog;
RMAN-00571: 
===RMAN-00569: 
=== ERROR MESSAGE STACK FOLLOWS ===RMAN-00571: 
===RMAN-06441: cannot 
upgrade catalog - catalog is already newer than this RMAN



   - Mensagem encaminhada - De: Rodrigo Mufalani 
rodr...@mufalani.com.br [oracle_br] <oracle_br@yahoogrupos.com.br>Para: 
oracle...@yahoogrupos..com.br <oracle_br@yahoogrupos.com.br>Enviado: 
terça-feira, 13 de março de 2018 13:39:50 BRTAssunto: Re: [oracle_br] Change 
owner catalog
     

Boa tarde,
   Procure sobre import catalog, comando do rman. Isso vai resolver seu 
problema.
Obter o Outlook para iOSFrom: oracle_br@yahoogrupos.com.br 
<oracle_br@yahoogrupos.com.br> on behalf of Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br] <oracle_br@yahoogrupos.com.br>
Sent: Tuesday, March 13, 2018 5:32:38 PM
To: Yahoo! Brazil
Subject: [oracle_br] Change owner catalog  

PEssoal, boa tarde.
Oracle 11gR2.
Seguinte, possuo um banco de dados (catalogo de recuperação) que possui 
diversos owners onde cada um eh dono de um catalogo. Estou migrando todas as 
informações de vários owners para um único catalogo (um unico owner)
O que está ocorrendo são os erros que recebo no impdp, segue:

Criacao do catologo que servira para todos os databases:

SQL> CREATE TABLESPACE TBS_CATALOG DATAFILE 
'/oracle/oradata/rmngrprd/data/tbs_catalog_01.dbf' SIZE 3G AUTOEXTEND ON NEXT 
1G;
SQL> CREATE USER USER_CATALOG IDENTIFIED BY  DEFAULT TABLESPACE 
TBS_CATALOG;SQL> GRANT CONNECT, RESOURCE, RECOVERY_CATALOG_OWNER TO 
USER_CATALOG;SQL> ALTER USER USER_CATALOG QUOTA UNLIMITED ON TBS_CATALOG;
$ rman CATALOG=USER_CATALOG/x
RMAN> CREATE CATALOG TABLESPACE TBS_CATALOG;



Owner de origem:

USERNAME                       DEFAULT_TABLESPACE-- 
--USER_ANTIGO                       USERS


expdp \' /as sysdba \' CONTENT=DATA_ONLY schemas=USER_ANTIGO 
directory="BACKUP_DBA" dumpfile=USER_ANTIGO .dmp logfile=USER_ANTIGO.log

Logo depois, mando o impdp:

impdp \' /as sysdba \' TABLE_EXISTS_ACTION=APPEND remap_schema= USER_ANTIGO 
:USER_CATALOG remap_tablespace=USERS:TBS_CATALOG directory="BACKUP_DBA" 
dumpfile=USER_ANTIGO .dmp logfile=USER_ANTIGO .log




e abaixo segue o erro ao importar:


ORA-31693: Table data object "USER_CATALOG"."ROUT" failed to load/unload and is 
being skipped due to error:ORA-29913: error in executing ODCIEXTTABLEFETCH 
calloutORA-02291: integrity constraint (USER_CATALOG.ROUT_F2) violated - parent 
key not foundORA-31693: Table data object "USER_CATALOG"."RLH" failed to 
load/unload and is being skipped due to error:ORA-29913: error in executing 
ODCIEXTTABLEFETCH calloutORA-02291: integrity constraint (USER_CATALOG..RLH_F1) 
violated - parent key not foundORA-31693: Table data object "USER_CATALOG"."BP" 
failed to load/unload and is being skipped due to error:ORA-29913: error in 
executing ODCIEXTTABLEFETCH calloutORA-02291: integrity constraint 
(USER_CATALOG.BP_F2) violated - parent key not foundORA-31693: Table data 
object "USER_CATALOG"."RSR" failed to load/unload and is being skipped due to 
error:ORA-29913: error in executing ODCIEXTTABLEFETCH calloutORA-02291: 
integrity constraint (USER_CATALOG.RSR_F2) violated - parent key not 
foundORA-31693: Table data object "USER_CATALOG"."BS" failed to load/unload and 
is being skipped due to error:ORA-29913: error in executing ODCIEXTTABLEFETCH 
calloutORA-02291: integrity constraint (USER_CATALOG.BS_F2) violated - parent 
key not f

[oracle_br] Change owner catalog

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

PEssoal, boa tarde.
Oracle 11gR2.
Seguinte, possuo um banco de dados (catalogo de recuperação) que possui 
diversos owners onde cada um eh dono de um catalogo. Estou migrando todas as 
informações de vários owners para um único catalogo (um unico owner)
O que está ocorrendo são os erros que recebo no impdp, segue:

Criacao do catologo que servira para todos os databases:

SQL> CREATE TABLESPACE TBS_CATALOG DATAFILE 
'/oracle/oradata/rmngrprd/data/tbs_catalog_01.dbf' SIZE 3G AUTOEXTEND ON NEXT 
1G;
SQL> CREATE USER USER_CATALOG IDENTIFIED BY  DEFAULT TABLESPACE 
TBS_CATALOG;SQL> GRANT CONNECT, RESOURCE, RECOVERY_CATALOG_OWNER TO 
USER_CATALOG;SQL> ALTER USER USER_CATALOG QUOTA UNLIMITED ON TBS_CATALOG;
$ rman CATALOG=USER_CATALOG/x
RMAN> CREATE CATALOG TABLESPACE TBS_CATALOG;



Owner de origem:

USERNAME                       DEFAULT_TABLESPACE-- 
--USER_ANTIGO                       USERS


expdp \' /as sysdba \' CONTENT=DATA_ONLY schemas=USER_ANTIGO 
directory="BACKUP_DBA" dumpfile= USER_ANTIGO .dmp logfile= USER_ANTIGO.log

Logo depois, mando o impdp:

impdp \' /as sysdba \' TABLE_EXISTS_ACTION=APPEND remap_schema= USER_ANTIGO 
:USER_CATALOG remap_tablespace=USERS:TBS_CATALOG directory="BACKUP_DBA" 
dumpfile= USER_ANTIGO .dmp logfile= USER_ANTIGO .log




e abaixo segue o erro ao importar:


ORA-31693: Table data object "USER_CATALOG"."ROUT" failed to load/unload and is 
being skipped due to error:ORA-29913: error in executing ODCIEXTTABLEFETCH 
calloutORA-02291: integrity constraint (USER_CATALOG.ROUT_F2) violated - parent 
key not foundORA-31693: Table data object "USER_CATALOG"."RLH" failed to 
load/unload and is being skipped due to error:ORA-29913: error in executing 
ODCIEXTTABLEFETCH calloutORA-02291: integrity constraint (USER_CATALOG.RLH_F1) 
violated - parent key not foundORA-31693: Table data object "USER_CATALOG"."BP" 
failed to load/unload and is being skipped due to error:ORA-29913: error in 
executing ODCIEXTTABLEFETCH calloutORA-02291: integrity constraint 
(USER_CATALOG.BP_F2) violated - parent key not foundORA-31693: Table data 
object "USER_CATALOG"."RSR" failed to load/unload and is being skipped due to 
error:ORA-29913: error in executing ODCIEXTTABLEFETCH calloutORA-02291: 
integrity constraint (USER_CATALOG.RSR_F2) violated - parent key not 
foundORA-31693: Table data object "USER_CATALOG"."BS" failed to load/unload and 
is being skipped due to error:ORA-29913: error in executing ODCIEXTTABLEFETCH 
calloutORA-02291: integrity constraint (USER_CATALOG.BS_F2) violated - parent 
key not foundORA-31693: Table data object "USER_CATALOG"."BRL" failed to 
load/unload and is being skipped due to error:ORA-29913: error in executing 
ODCIEXTTABLEFETCH callout


Tentei também utilizar o parâmetro no impdp 
DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS, mas isso é uma gambiarra e mesmo assim 
obtive vários erros, alguém sabe como faço para resolver esse problema?

Re: [oracle_br] Erro ao entrar no sqlplus

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Entao pessoal, desculpem a demora para responder.O que foi feito foi um clone 
da maquina, ou seja, nao foi feita uma nova instalacao do SO, foi feito um 
clone.
Depois o que peço é a criação dos file systems que preciso e peço pra equipe de 
backup backupear o oracle_home e restaurar nesse clone. 
QUando eu faço dessa forma, sempre funciona, foram mais de 10 maquinas, porém 
dessa vez o sqlplus não quer funcionar, estou achando muito estranho, acho que 
por conta da versão 10g.
Em quarta-feira, 7 de março de 2018 16:09:52 BRT, jlchia...@yahoo.com.br 
[oracle_br]  escreveu:  
 
     
Vamos ver, mas entendo que NÂO , eu Imagino que o pessoal de AIX simplesmente 
copiou os arqs do ORACLE_HOME e abaixo pro novo servidor... Se foi isso, é 
BATATA dar problema, porque além dos arqs constante no ORACLE_HOME o software 
Oracle *** EXIGE *** diversas libraries/packages de Sistema presentes, E 
presentes numa versão Específica
 IMHO o que se deve fazer nesse caso é : primeiro demandar que o pessoal do AIX 
instale o Sistema Operacional EXATAMENTE QUE NEM a máquina-origem (com os 
MESMOS pacotes de instalação, com os MESMOS params de kernel, MESMAS libraries 
de sistema, enfim, instalação IDÊNTICA ): isso confirmadamente OK, aí o DBA ** 
INSTALA ** o software Oracle , usando a MESMA EXATA VERSÃO e os MESMOS EXATOS 
patches aplicados no software Oracle da máquina - origem...

[]s

  Chiappa
  #yiv1035838031 #yiv1035838031 -- #yiv1035838031ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1035838031 
#yiv1035838031ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1035838031 
#yiv1035838031ygrp-mkp #yiv1035838031hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv1035838031 #yiv1035838031ygrp-mkp #yiv1035838031ads 
{margin-bottom:10px;}#yiv1035838031 #yiv1035838031ygrp-mkp .yiv1035838031ad 
{padding:0 0;}#yiv1035838031 #yiv1035838031ygrp-mkp .yiv1035838031ad p 
{margin:0;}#yiv1035838031 #yiv1035838031ygrp-mkp .yiv1035838031ad a 
{color:#ff;text-decoration:none;}#yiv1035838031 #yiv1035838031ygrp-sponsor 
#yiv1035838031ygrp-lc {font-family:Arial;}#yiv1035838031 
#yiv1035838031ygrp-sponsor #yiv1035838031ygrp-lc #yiv1035838031hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1035838031 
#yiv1035838031ygrp-sponsor #yiv1035838031ygrp-lc .yiv1035838031ad 
{margin-bottom:10px;padding:0 0;}#yiv1035838031 #yiv1035838031actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1035838031 
#yiv1035838031activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1035838031
 #yiv1035838031activity span {font-weight:700;}#yiv1035838031 
#yiv1035838031activity span:first-child 
{text-transform:uppercase;}#yiv1035838031 #yiv1035838031activity span a 
{color:#5085b6;text-decoration:none;}#yiv1035838031 #yiv1035838031activity span 
span {color:#ff7900;}#yiv1035838031 #yiv1035838031activity span 
.yiv1035838031underline {text-decoration:underline;}#yiv1035838031 
.yiv1035838031attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv1035838031 .yiv1035838031attach div a 
{text-decoration:none;}#yiv1035838031 .yiv1035838031attach img 
{border:none;padding-right:5px;}#yiv1035838031 .yiv1035838031attach label 
{display:block;margin-bottom:5px;}#yiv1035838031 .yiv1035838031attach label a 
{text-decoration:none;}#yiv1035838031 blockquote {margin:0 0 0 
4px;}#yiv1035838031 .yiv1035838031bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv1035838031 
.yiv1035838031bold a {text-decoration:none;}#yiv1035838031 dd.yiv1035838031last 
p a {font-family:Verdana;font-weight:700;}#yiv1035838031 dd.yiv1035838031last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv1035838031 
dd.yiv1035838031last p span.yiv1035838031yshortcuts 
{margin-right:0;}#yiv1035838031 div.yiv1035838031attach-table div div a 
{text-decoration:none;}#yiv1035838031 div.yiv1035838031attach-table 
{width:400px;}#yiv1035838031 div.yiv1035838031file-title a, #yiv1035838031 
div.yiv1035838031file-title a:active, #yiv1035838031 
div.yiv1035838031file-title a:hover, #yiv1035838031 div.yiv1035838031file-title 
a:visited {text-decoration:none;}#yiv1035838031 div.yiv1035838031photo-title a, 
#yiv1035838031 div.yiv1035838031photo-title a:active, #yiv1035838031 
div.yiv1035838031photo-title a:hover, #yiv1035838031 
div.yiv1035838031photo-title a:visited {text-decoration:none;}#yiv1035838031 
div#yiv1035838031ygrp-mlmsg #yiv1035838031ygrp-msg p a 
span.yiv1035838031yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv1035838031 
.yiv1035838031green {color:#628c2a;}#yiv1035838031 .yiv1035838031MsoNormal 
{margin:0 0 0 0;}#yiv1035838031 o {font-size:0;}#yiv1035838031 
#yiv1035838031photos div {float:left;width:72px;}#yiv1035838031 
#yiv1035838031photos div div {border:1px solid 

Re: [oracle_br] Erro ao entrar no sqlplus

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Adicionando:Ambiente single instance em FS
Em quarta-feira, 7 de março de 2018 10:35:48 BRT, Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:  
 
     

Senhores, bom dia.
Pedi para a equipe de AIX realizar um clone (binarios oracle/AIX) de um 
servidor de produção, pois iria precisar do mesmo para criar um standby 
database.

Cenário:AIX 3 5 00F690054C00
Oracle 10gR2

No standby database, após setar o ORACLE_SID e o ORACLE_HOME caiu no erro 
abaixo:
oracle@  sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Wed Mar 7 10:15:20 2018
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
exec(): 0509-036 Cannot load program oracleelipsprd because of the following 
errors:        0509-130 Symbol resolution failed for /usr/lib/libc.a[aio_64.o] 
because:        0509-136   Symbol kaio_rdwr64 (number 1) is not exported from   
                dependent module /unix.        0509-136   Symbol listio64 
(number 2) is not exported from                   dependent module /unix.       
 0509-136   Symbol acancel64 (number 3) is not exported from                   
dependent module /unix.        0509-136   Symbol iosuspend64 (number 4) is not 
exported from                   dependent module /unix.        0509-136   
Symbol aio_nwait (number 5) is not exported from                   dependent 
module /unix.        0509-136   Symbol aio_nwait64 (number 6) is not exported 
from                   dependent module /unix.        0509-136   Symbol 
aio_nwait_timeout (number 7) is not exported from                   dependent 
module /unix.        0509-136   Symbol aio_nwait_timeout64 (number 8) is not 
exported from                   dependent module /unix.        0509-026 System 
error: Error 0        0509-192 Examine .loader section symbols with the         
        'dump -Tv' command.ERROR:ORA-12547: TNS:lost contact

Ja verifiquei o seguinte:
a) assync IO
AIX : 0509-130 Symbolresolution failed for /usr/lib/libc.a[aio_64.o]

 
https://www.ibm.com/developerworks/community/blogs/kairoaraujo/entry/aix_0509_130_symbol_resolution_failed_for_usr_lib_libc_a_aio_64_o1?lang=pt_br


b) RElink dos binarios
c) Permissoes
oracle@xxx ls -la oracle-rwsr-s--x    1 oracle   dba       133931969 Jun 15 
2011  oracle


Alguem poderia me ajudar? No primary database isso nao acontece.


  #yiv0996292195 #yiv0996292195 -- #yiv0996292195ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0996292195 
#yiv0996292195ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0996292195 
#yiv0996292195ygrp-mkp #yiv0996292195hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv0996292195 #yiv0996292195ygrp-mkp #yiv0996292195ads 
{margin-bottom:10px;}#yiv0996292195 #yiv0996292195ygrp-mkp .yiv0996292195ad 
{padding:0 0;}#yiv0996292195 #yiv0996292195ygrp-mkp .yiv0996292195ad p 
{margin:0;}#yiv0996292195 #yiv0996292195ygrp-mkp .yiv0996292195ad a 
{color:#ff;text-decoration:none;}#yiv0996292195 #yiv0996292195ygrp-sponsor 
#yiv0996292195ygrp-lc {font-family:Arial;}#yiv0996292195 
#yiv0996292195ygrp-sponsor #yiv0996292195ygrp-lc #yiv0996292195hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0996292195 
#yiv0996292195ygrp-sponsor #yiv0996292195ygrp-lc .yiv0996292195ad 
{margin-bottom:10px;padding:0 0;}#yiv0996292195 #yiv0996292195actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0996292195 
#yiv0996292195activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0996292195
 #yiv0996292195activity span {font-weight:700;}#yiv0996292195 
#yiv0996292195activity span:first-child 
{text-transform:uppercase;}#yiv0996292195 #yiv0996292195activity span a 
{color:#5085b6;text-decoration:none;}#yiv0996292195 #yiv0996292195activity span 
span {color:#ff7900;}#yiv0996292195 #yiv0996292195activity span 
.yiv0996292195underline {text-decoration:underline;}#yiv0996292195 
.yiv0996292195attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv0996292195 .yiv0996292195attach div a 
{text-decoration:none;}#yiv0996292195 .yiv0996292195attach img 
{border:none;padding-right:5px;}#yiv0996292195 .yiv0996292195attach label 
{display:block;margin-bottom:5px;}#yiv0996292195 .yiv0996292195attach label a 
{text-decoration:none;}#yiv0996292195 blockquote {margin:0 0 0 
4px;}#yiv0996292195 .yiv0996292195bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv0996292195 
.yiv0996292195bold a {text-decoration:none;}#yiv0996292195 dd.yiv0996292195last 
p a {font-family:Verdana;font-weight:700;}#yiv0996292195 dd.yiv0996292195last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0996292195 
dd.yiv0996292195last p span.yiv0996292195yshortcuts 
{margin-right:0;}#yiv0996292195 div.yiv0996292195attach-table div div a 
{text-decoration:none;}#yiv0996292195 div.yiv0996292195attach-table 
{width:400px;}#yiv0996

[oracle_br] Erro ao entrar no sqlplus

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Senhores, bom dia.
Pedi para a equipe de AIX realizar um clone (binarios oracle/AIX) de um 
servidor de produção, pois iria precisar do mesmo para criar um standby 
database.

Cenário:AIX 3 5 00F690054C00
Oracle 10gR2

No standby database, após setar o ORACLE_SID e o ORACLE_HOME caiu no erro 
abaixo:
oracle@  sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Wed Mar 7 10:15:20 2018
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
exec(): 0509-036 Cannot load program oracleelipsprd because of the following 
errors:        0509-130 Symbol resolution failed for /usr/lib/libc.a[aio_64.o] 
because:        0509-136   Symbol kaio_rdwr64 (number 1) is not exported from   
                dependent module /unix.        0509-136   Symbol listio64 
(number 2) is not exported from                   dependent module /unix.       
 0509-136   Symbol acancel64 (number 3) is not exported from                   
dependent module /unix.        0509-136   Symbol iosuspend64 (number 4) is not 
exported from                   dependent module /unix.        0509-136   
Symbol aio_nwait (number 5) is not exported from                   dependent 
module /unix.        0509-136   Symbol aio_nwait64 (number 6) is not exported 
from                   dependent module /unix.        0509-136   Symbol 
aio_nwait_timeout (number 7) is not exported from                   dependent 
module /unix.        0509-136   Symbol aio_nwait_timeout64 (number 8) is not 
exported from                   dependent module /unix.        0509-026 System 
error: Error 0        0509-192 Examine .loader section symbols with the         
        'dump -Tv' command.ERROR:ORA-12547: TNS:lost contact

Ja verifiquei o seguinte:
a) assync IO
AIX : 0509-130 Symbolresolution failed for /usr/lib/libc.a[aio_64.o]

 
https://www.ibm.com/developerworks/community/blogs/kairoaraujo/entry/aix_0509_130_symbol_resolution_failed_for_usr_lib_libc_a_aio_64_o1?lang=pt_br


b) RElink dos binarios
c) Permissoes
oracle@xxx ls -la oracle-rwsr-s--x    1 oracle   dba       133931969 Jun 15 
2011  oracle


Alguem poderia me ajudar? No primary database isso nao acontece.

Re: [oracle_br] Re: Ajuda Codigo PL/SQL

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 Opa Chiappa, o que quis dizer é exatamente o que você entendeu.
Eu até tinha montado a query dinâmica da mesma forma que você a escreveu, só 
não tinha feito o script.
E realmente, burrice minha, nao tinha pensado no expdp passando somente os 
dados dos owners para depois fazer o impdp para o novo owner do catálogo, mas 
simples e mais elegante dessa forma.


Em quinta-feira, 18 de janeiro de 2018 17:40:18 BRST, 
jlchia...@yahoo.com.br [oracle_br]  escreveu:  
 
     
Xô entender melhor a sua situação : num único database Oracle, database esse 
que é usado como RMAN catalog database, vc tem muitos catálogos, sendo que é um 
catálogo RMAN pra cada database, é isso ??? E dado o fato que a utiliuzação 
Normal e Rotineira de um catálogo RMAN é manter dados de backup para Múltiplos 
Databases (isso é demonstrado Inclusive na Modelagem do catálogo, vc vai ver 
que as tabelas do catálogo ** TODAS ELAS ** possuem já uma coluna DB_KEY, para 
que a mesma tabela possa guardar backups de N databases), vc quer Unificar 
isso, correto ?

 Muito bem : antes de responder a sua pergunta, deixa eu perguntar - vc precisa 
guardar os dados hoje armazenados nesses catálogos, transportando-os como estão 
para o novo catálogo único que vc vai criar ?? Se sim, veja que um catálogo 
RMAN nada mais é do que uma série de tabelas Oracle que pertencem a um dado 
schema/usuário Oracle qualquer : hoje, se vc tem no seu banco de catálogo 
digamos 30 catalogs vc tem nesse banco de catálogo 30 schemas, um schema que é 
owner do catálogo1, um schema que é owner do catálogo2, um schema que é owner 
do catálogo3, assim por diante... SE todos esses catálogos são da MESMA EXATA 
VERSÃO, as tabelas que compõem esses catálogos VÃO SER ABSOLUTA E COMPLETAMENTE 
IGUAIS em termos de estrutura, com as colunas e constraints COMPLETAMENTE 
IGUAIZINHAS, só os dados dentro de cada tabela é que mudam... 
  SENDO ASSIM, E SE realmente os dados anteriores não podem ser perdidos, não 
faz sentido vc partir pra bloco PL/SQL anônimo : simplesmente crie o 
repositório unificado vazio (com o comando de CREATE CATALOG) num schema novo 
(chamado REP_UNIF, digamos), faça um EXPORT via datapump apenas com os dados 
(ie, SEM pedir pra criar tabelas!!) de cada schema owner, depois faça import 
pedindo pros mover os dados que originalmente pertenciam ao schema original 
para o schema REP_UNIF, isso se faz com REMAP_SCHEMA
  
 Agora sim, respondendo a sua pergunta :  ao que entendi, se (digamos) a tua 
consulta principal :
 
SELECT OWNER FROM DBA_OBJECTS WHERE OBJECT_NAME = 'RC_DATABASE';

retorne, digamos 10 linhas :

OWNER1
OWNER2
OWNER3
OWNER4
OWNER5
OWNER6
OWNER7
OWNER8
OWNER9
OWNER10

vc quer executar um SQL :

select name from OWNER1.RC_DATABASE;

depois executar :

select name from OWNER2.RC_DATABASE;

depois executar :

select name from OWNER3.RC_DATABASE;

assim por diante, né ? 

Eu pessoalmente, sempre que tenho uma tarefa do tipo (ie, sei EXATAMENTE quais 
SQLs precisam ser escritos, é possível vc os montar lendo de alguma tabela 
Oracle E tenho acesso ao sql*plus (ou tools similar que execute scripts) SEMPRE 
PREFIRO usar a técnica amiga do DBA, que já me salvou a pele N+1! vezes, que é 
: montar os SQLs numa query E salvar a saída da query num arquivo-texto, que 
depois executo pelo sql*plus ou o que tiver...
 Um exemplo :
 
==> digamos que meus dados estejam assim :

SYSTEM:@XE:SQL>SELECT OWNER FROM DBA_OBJECTS WHERE OBJECT_NAME = 'RC_DATABASE';

OWNER

BI
PM
OE

SYSTEM:@XE:SQL>

==> tenho portanto que gerar 3 linhas, com a diff única que a parte da string 
que indica o OWNER vai vir da coluna OWNER do select demonstrado, seria algo 
tipo :

SYSTEM:@XE:SQL>SELECT 'SELECT NAME FROM ' || OWNER || '.rc_database;'  FROM 
DBA_OBJECTS WHERE OBJECT_NAME = 'RC_DATABASE';

==> DEU PRA PERCEBER que gerei os comandos que queria concatenando a parte fixa 
com a parte variável que vem da coluna OWNER da conulta anterior ?? Olha como 
fica o resultado :


'SELECTNAMEFROM'||OWNER||'.RC_DATABASE;'

SELECT NAME FROM BI.rc_database;
SELECT NAME FROM PM.rc_database;
SELECT NAME FROM OE.rc_database;

SYSTEM:@XE:SQL> 
 
==> Não é bico de entender ?? Pra mim sim... Agora só preciso que o sql*plus me 
GRAVE EM DISCO com um nome qualquer e extensão .SQL esse output, quem faz isso 
é o comando SPOOL... Vou incluir o SPOOL e uns ajustes de tela pra não vir o 
cabeçalho e coisitas assim :

C:\Users\jlchi_000>type gera_script.sql
set term off feedback off verify off pages 0 lines 500 trimspool on head off
spool pesquisa_names.sql
SELECT 'SELECT NAME FROM ' || OWNER || '.rc_database;' FROM DBA_OBJECTS WHERE 
OBJECT_NAME = 'RC_DATABASE';
exit;


==> vou executar o script gerador pelo sqlplus :

C:\Users\jlchi_000>sqlplus system/oracle @gera_script

SQL*Plus: Release 11.2.0.2.0 Production

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Conectado a:
Oracle 

[oracle_br] Ajuda Codigo PL/SQL

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Pessoal, boa tarde.
Estou aqui pedindo a ajuda de vocês para criar um bloco pl/sql anonimo..
Eu tenho um cliente que possui um catalogo de recuperacao para cada database e 
vamos unificar todos os bancos em um unico catalogo.
Eu fiz a seguinte consulta para identificar os owners:

SELECT OWNER FROM DBA_OBJECTS WHERE OBJECT_NAME = 'RC_DATABASE';
Com isso, eu tenho os owners dos catalogos que serao dropados futuramente, mas 
antes disso, eu preciso saber quais sao os bancos registrados em cada um desses 
catalogos, consultando:

select name from .RC_DATABASE; -- colocando os owners
obs: lembrando que alguns registros retornam 0 linhas (no rows selected).
Entao eu queria iria criar uma tabela para guardar os nomes dos bancos, seria 
mais ou menos assim o algoritmo:

Declare
v_owner varchar2(50);v_name varchar2(50);cursor c1 is
select ownerinto v_ownerFROM DBA_OBJECTS WHERE OBJECT_NAME = 'RC_DATABASE';

Begin
loop 

select name into v_name from v_owner.RC_DATABASE;
if v_name (tiver alguma linha retornada)
insert into registro values (v_name);
end loop;
End;

/
Com isso eu teria todos os bancos que eu precisaria registrar no novo e unico 
catalogo.

Re: Assunto: [oracle_br] Consulta muito lenta!!

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

O problema ja foi resolvido Emerson, conforme escrevi no primeiro topico, a 
view seria inviavel. 

Em Terça-feira, 19 de Dezembro de 2017 16:01, "Emerson Moreira Rocha 
tkz...@yahoo.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Não dá pra fazer uma mview atualizável?

Enviado do Yahoo Mail no Android 
 
  Em sex, 15 15e dez 15e 2017 às 10:57, Rafael Mendonca raffaell.t...@yahoo.com 
[oracle_br]oracle_br@yahoogrupos.com.br> escreveu:       Senhores, bom dia.
Preciso de uma grande ajuda dos especialistas.
Ambiente single instance, file system, EE 11.2.0.3Options: diagnostic and 
tuning pack, in memory, advanced compression, partitioning

Possuo uma query do sistema SAP (standard SAP), ou seja, nao existe alternativa 
para mudança estrutural da consulta, nem por hint na consulta, nem nada, por 
ser standard. O que é possível fazer é tudo a nível de banco de dados, como 
criação de sql patch, rewrite etc...
Pois bem, vamos aos detalhes:
A consulta envolve 2 tabelas e 2 índices, cada um com seus respectivos tamanhos 
abaixo:
tabela x1: 400GBtabela x2:160GBIndice tab x1: 140GBIndice tab x2: 2GB
Duracao da consulta: 16 minutos
OBS: Os segmentos envoldios nao possuem PARTICIONAMENTO ou COMPRESSAO.
COnsulta abaixo:
http://textuploader.com/dcreu


Plano de execucao abaixo (SELECT * FROM table(dbms_xplan.display_cursor)):

http://textuploader.com/dcre7



Alternativas 1:
A criacao de uma Mview para a consulta em questao, porem o SAP nao pode 
direcionar o relatorio para a MVIew, entao pensei na rewrite para forcar ao ler 
o sqlid utilizar Mview, porem se as mview nao estiver totalmente atualizada com 
as tabelas envolvidas a Mview nao sera lida, ou seja, a tabela em questao 
possui 2 bilhoes de registros, eh alterada o tempo inteiro, ou seja, sem chance.
Alternativa 2: realizar um compression OLTP nas tabelas envolvidas, o que 
acham? Problema sera a carga de DML nessas tabelas, me preocupo com a lentidao 
dos inserts, updates e deletes.
Alternativa 3: Particionamento. Porem precisamos de uma solucao rapida, ira 
entrar um processo de auditoria e nao temos tempo para essa implementacao.
Alguem pode ajudar nessa dificil missao?

  #yiv3378312260 #yiv3378312260 -- #yiv3378312260ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3378312260 
#yiv3378312260ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3378312260 
#yiv3378312260ygrp-mkp #yiv3378312260hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv3378312260 #yiv3378312260ygrp-mkp #yiv3378312260ads 
{margin-bottom:10px;}#yiv3378312260 #yiv3378312260ygrp-mkp .yiv3378312260ad 
{padding:0 0;}#yiv3378312260 #yiv3378312260ygrp-mkp .yiv3378312260ad p 
{margin:0;}#yiv3378312260 #yiv3378312260ygrp-mkp .yiv3378312260ad a 
{color:#ff;text-decoration:none;}#yiv3378312260 #yiv3378312260ygrp-sponsor 
#yiv3378312260ygrp-lc {font-family:Arial;}#yiv3378312260 
#yiv3378312260ygrp-sponsor #yiv3378312260ygrp-lc #yiv3378312260hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3378312260 
#yiv3378312260ygrp-sponsor #yiv3378312260ygrp-lc .yiv3378312260ad 
{margin-bottom:10px;padding:0 0;}#yiv3378312260 #yiv3378312260actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3378312260 
#yiv3378312260activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3378312260
 #yiv3378312260activity span {font-weight:700;}#yiv3378312260 
#yiv3378312260activity span:first-child 
{text-transform:uppercase;}#yiv3378312260 #yiv3378312260activity span a 
{color:#5085b6;text-decoration:none;}#yiv3378312260 #yiv3378312260activity span 
span {color:#ff7900;}#yiv3378312260 #yiv3378312260activity span 
.yiv3378312260underline {text-decoration:underline;}#yiv3378312260 
.yiv3378312260attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv3378312260 .yiv3378312260attach div a 
{text-decoration:none;}#yiv3378312260 .yiv3378312260attach img 
{border:none;padding-right:5px;}#yiv3378312260 .yiv3378312260attach label 
{display:block;margin-bottom:5px;}#yiv3378312260 .yiv3378312260attach label a 
{text-decoration:none;}#yiv3378312260 blockquote {margin:0 0 0 
4px;}#yiv3378312260 .yiv3378312260bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3378312260 
.yiv3378312260bold a {text-decoration:none;}#yiv3378312260 dd.yiv3378312260last 
p a {font-family:Verdana;font-weight:700;}#yiv3378312260 dd.yiv3378312260last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3378312260 
dd.yiv3378312260last p span.yiv3378312260yshortcuts 
{margin-right:0;}#yiv3378312260 div.yiv3378312260attach-table div div a 
{text-decoration:none;}#yiv3378312260 div.yiv3378312260attach-table 
{width:400px;}#yiv3378312260 div.yiv3378312260file-title a, #yiv3378312260 
div.yiv3378312260file-title a:active, #yiv3378312260 
div.yiv3378312260file-title a:hover, #yiv3378312260 div.yiv3

Re: [oracle_br] Re: Consulta muito lenta!!

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Esse indice FAGLFLEXA~2 eu fiz rebuild, mas nao adiantou de absolutamente nada. 
O restante nao foi alterado, nem indice criado nem dropado.
Algumas das informacoes do SQLT:
DBMS_STATS SYSTEM STATISTICS Single-block read time of 1.138 milliseconds seems 
too small.Index coalesce candidate. (para quase todos os indices dos segmentos 
envolvidos aparece esse advisor)Index with fluctuating BLEVELSample size of 
1593658 rows may be too small for column with histogram. Sample percent used 
was:0.10%. (Essa mensagem tb aparece para todas as colunas da tabela FAGLFLEXA)
A coleta de estatística é feita pelo sistema SAP.
 

Em Terça-feira, 19 de Dezembro de 2017 15:08, "jlchia...@yahoo.com..br 
[oracle_br]"  escreveu:
 

     Ok que o vc contornou seu 'problema', mas alguma coisa muito esquisita 
estava acontecendo aí : no plano original vc tinha (elimino a coluna do ID e do 
tempo só para caber melhor aqui no post) :


| Operation | Name    | Rows  | Bytes |TempSpc| Cost 
(%CPU)|

| SELECT STATEMENT  | |   |   |   | 54953 
(100)|
|  FILTER   | |   |   |   | 
   |
|   HASH JOIN   | |  1280K|   398M|   277M| 54952   
(1)|
|    TABLE ACCESS BY INDEX ROWID| FAGLFLEXA   |  1280K|   262M|   |  8463   
(1)|
| INDEX RANGE SCAN  | FAGLFLEXA~2 |   398K|   |   |   440   
(1)|
|    TABLE ACCESS BY INDEX ROWID| BKPF    |  2499K|   264M|   | 18178   
(1)|
| INDEX SKIP SCAN   | BKPF~BUT    |  2499K|   |   |  2599   
(2)|



E a nova versão :


-
| Operation  | Name    | Rows  | Bytes | Cost (%CPU)|
-
| SELECT STATEMENT   | |   |   |    11 (100)|
|  FILTER    | |   |   |    |
|   NESTED LOOPS | |   |   |    |
|    NESTED LOOPS    | |    31 | 10075 |    10   (0)|
| TABLE ACCESS BY INDEX ROWID| FAGLFLEXA   |    31 |  6634 | 1   (0)|
|  INDEX RANGE SCAN  | FAGLFLEXA~2 |    10 |   | 1   (0)|
| INDEX UNIQUE SCAN  | BKPF~0  | 1 |   | 0   (0)|
|    TABLE ACCESS BY INDEX ROWID | BKPF    | 1 |   111 | 0   (0)|
-


==> Perceba que as qtdades de linhas envolvidas passaram de coisa de milhão pra 
coisa de dezenas de linhas : vc já tinha disponível esse índice BKPF ? Vc 
recriou (tirando ou adicionando colunas, talvez ?) esse índice FAGLFLEXA~2 ? 
COMO É que o Otimizador errou por uma margem tão larga, estimando no plano 
original que o hash join iria criar (E provavelmente CRIOU, dado o consumo de 
temp space!!) tabela hash de vários milhões E agora no novo plano não chega nem 
perto ?? Será que as Estatísticas estavam assim tão defasadas ??? Ou como eu 
disse vc mudou as regras do jogo, criando um novo índice e/ou alterando os que 
existiam ??

[]s

  Chiappa  #yiv2597863981 #yiv2597863981 -- #yiv2597863981ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2597863981 
#yiv2597863981ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2597863981 
#yiv2597863981ygrp-mkp #yiv2597863981hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2597863981 #yiv2597863981ygrp-mkp #yiv2597863981ads 
{margin-bottom:10px;}#yiv2597863981 #yiv2597863981ygrp-mkp .yiv2597863981ad 
{padding:0 0;}#yiv2597863981 #yiv2597863981ygrp-mkp .yiv2597863981ad p 
{margin:0;}#yiv2597863981 #yiv2597863981ygrp-mkp .yiv2597863981ad a 
{color:#ff;text-decoration:none;}#yiv2597863981 #yiv2597863981ygrp-sponsor 
#yiv2597863981ygrp-lc {font-family:Arial;}#yiv2597863981 
#yiv2597863981ygrp-sponsor #yiv2597863981ygrp-lc #yiv2597863981hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2597863981 
#yiv2597863981ygrp-sponsor #yiv2597863981ygrp-lc .yiv2597863981ad 
{margin-bottom:10px;padding:0 0;}#yiv2597863981 #yiv2597863981actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2597863981 
#yiv2597863981activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2597863981
 #yiv2597863981activity span {font-weight:700;}#yiv2597863981 
#yiv2597863981activity span:first-child 
{text-transform:uppercase;}#yiv2597863981 #yiv2597863981activity span a 
{color:#5085b6;text-decoration:none;}#yiv2597863981 #yiv2597863981activity 

Re: [oracle_br] Re: Consulta muito lenta!!

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Luis, segue o novo plano gerado abaixo:

http://textuploader.com/dcjxh
 

Em Terça-feira, 19 de Dezembro de 2017 10:11, "Luis Freitas 
lfreita...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Ola Rafael,
    Você pode postar o plano de execução novo?
Atc,Luis Freitas 

On Monday, December 18, 2017 3:33 PM, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> wrote:
 

     PEssoal, o problema foi resolvido.
A solução na qual tomei como base foi a extração do relatório SQLT pelo sqlid 
da consulta. E no SQLT existia a recomendação para criação de um sqlprofile, 
que o ganho seria de 99%, após a criação do sql_profile abaixo
execute dbms_sqltune.accept_sql_profile(task_name => 
'sqlt_s47584_mem',task_owner => 'SYS', replace => TRUE);

A query que rodava em 16 minutos, passou a rodar em 3 segundos.
Valeu pessoal, obrigado a todos. 

Em Sexta-feira, 15 de Dezembro de 2017 19:43, "jlchia...@yahoo.com.br 
[oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Bom, pelo prompt de SQL> eu estou SUPONDO que vc optou por criar no 
sqlplus as bind variables todas necessárias e executar o SQL via sqlplus mesmo 
né ? Bom, DEVERIA FUNCIONAR certinho mas pra teste já que é assim mete o hint 
de gather_statistics mesmo no texto que vc entra entrando no sqlplus... Se 
ainda assim não mostrar o A-ROWs E o E-ROWs já repassa essa info pro Suporte 
SAP, é um sinal indicador que alguma coisa tá MUITO diferente nesse banco

[]s

  Chiappa
   

 

 #yiv5858779180 #yiv5858779180 -- #yiv5858779180ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5858779180 
#yiv5858779180ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5858779180 
#yiv5858779180ygrp-mkp #yiv5858779180hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5858779180 #yiv5858779180ygrp-mkp #yiv5858779180ads 
{margin-bottom:10px;}#yiv5858779180 #yiv5858779180ygrp-mkp ..yiv5858779180ad 
{padding:0 0;}#yiv5858779180 #yiv5858779180ygrp-mkp .yiv5858779180ad p 
{margin:0;}#yiv5858779180 #yiv5858779180ygrp-mkp .yiv5858779180ad a 
{color:#ff;text-decoration:none;}#yiv5858779180 #yiv5858779180ygrp-sponsor 
#yiv5858779180ygrp-lc {font-family:Arial;}#yiv5858779180 
#yiv5858779180ygrp-sponsor #yiv5858779180ygrp-lc #yiv5858779180hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5858779180 
#yiv5858779180ygrp-sponsor #yiv5858779180ygrp-lc .yiv5858779180ad 
{margin-bottom:10px;padding:0 0;}#yiv5858779180 #yiv5858779180actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5858779180 
#yiv5858779180activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5858779180
 #yiv5858779180activity span {font-weight:700;}#yiv5858779180 
#yiv5858779180activity span:first-child 
{text-transform:uppercase;}#yiv5858779180 #yiv5858779180activity span a 
{color:#5085b6;text-decoration:none;}#yiv5858779180 #yiv5858779180activity span 
span {color:#ff7900;}#yiv5858779180 #yiv5858779180activity span 
.yiv5858779180underline {text-decoration:underline;}#yiv5858779180 
.yiv5858779180attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv5858779180 .yiv5858779180attach div a 
{text-decoration:none;}#yiv5858779180 .yiv5858779180attach img 
{border:none;padding-right:5px;}#yiv5858779180 .yiv5858779180attach label 
{display:block;margin-bottom:5px;}#yiv5858779180 .yiv5858779180attach label a 
{text-decoration:none;}#yiv5858779180 blockquote {margin:0 0 0 
4px;}#yiv5858779180 .yiv5858779180bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5858779180 
.yiv5858779180bold a {text-decoration:none;}#yiv5858779180 dd.yiv5858779180last 
p a {font-family:Verdana;font-weight:700;}#yiv5858779180 dd.yiv5858779180last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5858779180 
dd.yiv5858779180last p span.yiv5858779180yshortcuts 
{margin-right:0;}#yiv5858779180 div.yiv5858779180attach-table div div a 
{text-decoration:none;}#yiv5858779180 div.yiv5858779180attach-table 
{width:400px;}#yiv5858779180 div.yiv5858779180file-title a, #yiv5858779180 
div.yiv5858779180file-title a:active, #yiv5858779180 
div.yiv5858779180file-title a:hover, #yiv5858779180 div.yiv5858779180file-title 
a:visited {text-decoration:none;}#yiv5858779180 div.yiv5858779180photo-title a, 
#yiv5858779180 div.yiv5858779180photo-title a:active, #yiv5858779180 
div.yiv5858779180photo-title a:hover, #yiv5858779180 
div.yiv5858779180photo-title a:visited {text-decoration:none;}#yiv5858779180 
div#yiv5858779180ygrp-mlmsg #yiv5858779180ygrp-msg p a 
span.yiv5858779180yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5858779180 
.yiv5858779180green {color:#628c2a;}#yiv5858779180 .yiv5858779180MsoNormal 
{margin:0 0 0 0;}#yiv5858779180 o {font-size:0;}#yiv5858779180 
#yi

Re: [oracle_br] Re: Consulta muito lenta!!

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

PEssoal, o problema foi resolvido.
A solução na qual tomei como base foi a extração do relatório SQLT pelo sqlid 
da consulta. E no SQLT existia a recomendação para criação de um sqlprofile, 
que o ganho seria de 99%, após a criação do sql_profile abaixo
execute dbms_sqltune.accept_sql_profile(task_name => 
'sqlt_s47584_mem',task_owner => 'SYS', replace => TRUE);

A query que rodava em 16 minutos, passou a rodar em 3 segundos.
Valeu pessoal, obrigado a todos. 

Em Sexta-feira, 15 de Dezembro de 2017 19:43, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, pelo prompt de SQL> eu estou SUPONDO que vc optou por criar no 
sqlplus as bind variables todas necessárias e executar o SQL via sqlplus mesmo 
né ? Bom, DEVERIA FUNCIONAR certinho mas pra teste já que é assim mete o hint 
de gather_statistics mesmo no texto que vc entra entrando no sqlplus... Se 
ainda assim não mostrar o A-ROWs E o E-ROWs já repassa essa info pro Suporte 
SAP, é um sinal indicador que alguma coisa tá MUITO diferente nesse banco

[]s

  Chiappa
   #yiv4332546053 #yiv4332546053 -- #yiv4332546053ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4332546053 
#yiv4332546053ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4332546053 
#yiv4332546053ygrp-mkp #yiv4332546053hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4332546053 #yiv4332546053ygrp-mkp #yiv4332546053ads 
{margin-bottom:10px;}#yiv4332546053 #yiv4332546053ygrp-mkp .yiv4332546053ad 
{padding:0 0;}#yiv4332546053 #yiv4332546053ygrp-mkp .yiv4332546053ad p 
{margin:0;}#yiv4332546053 #yiv4332546053ygrp-mkp .yiv4332546053ad a 
{color:#ff;text-decoration:none;}#yiv4332546053 #yiv4332546053ygrp-sponsor 
#yiv4332546053ygrp-lc {font-family:Arial;}#yiv4332546053 
#yiv4332546053ygrp-sponsor #yiv4332546053ygrp-lc #yiv4332546053hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4332546053 
#yiv4332546053ygrp-sponsor #yiv4332546053ygrp-lc .yiv4332546053ad 
{margin-bottom:10px;padding:0 0;}#yiv4332546053 #yiv4332546053actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4332546053 
#yiv4332546053activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4332546053
 #yiv4332546053activity span {font-weight:700;}#yiv4332546053 
#yiv4332546053activity span:first-child 
{text-transform:uppercase;}#yiv4332546053 #yiv4332546053activity span a 
{color:#5085b6;text-decoration:none;}#yiv4332546053 #yiv4332546053activity span 
span {color:#ff7900;}#yiv4332546053 #yiv4332546053activity span 
.yiv4332546053underline {text-decoration:underline;}#yiv4332546053 
.yiv4332546053attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv4332546053 .yiv4332546053attach div a 
{text-decoration:none;}#yiv4332546053 .yiv4332546053attach img 
{border:none;padding-right:5px;}#yiv4332546053 .yiv4332546053attach label 
{display:block;margin-bottom:5px;}#yiv4332546053 .yiv4332546053attach label a 
{text-decoration:none;}#yiv4332546053 blockquote {margin:0 0 0 
4px;}#yiv4332546053 .yiv4332546053bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4332546053 
.yiv4332546053bold a {text-decoration:none;}#yiv4332546053 dd.yiv4332546053last 
p a {font-family:Verdana;font-weight:700;}#yiv4332546053 dd.yiv4332546053last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4332546053 
dd.yiv4332546053last p span.yiv4332546053yshortcuts 
{margin-right:0;}#yiv4332546053 div.yiv4332546053attach-table div div a 
{text-decoration:none;}#yiv4332546053 div.yiv4332546053attach-table 
{width:400px;}#yiv4332546053 div.yiv4332546053file-title a, #yiv4332546053 
div.yiv4332546053file-title a:active, #yiv4332546053 
div.yiv4332546053file-title a:hover, #yiv4332546053 div.yiv4332546053file-title 
a:visited {text-decoration:none;}#yiv4332546053 div.yiv4332546053photo-title a, 
#yiv4332546053 div.yiv4332546053photo-title a:active, #yiv4332546053 
div.yiv4332546053photo-title a:hover, #yiv4332546053 
div.yiv4332546053photo-title a:visited {text-decoration:none;}#yiv4332546053 
div#yiv4332546053ygrp-mlmsg #yiv4332546053ygrp-msg p a 
span.yiv4332546053yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv4332546053 
.yiv4332546053green {color:#628c2a;}#yiv4332546053 .yiv4332546053MsoNormal 
{margin:0 0 0 0;}#yiv4332546053 o {font-size:0;}#yiv4332546053 
#yiv4332546053photos div {float:left;width:72px;}#yiv4332546053 
#yiv4332546053photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv4332546053 
#yiv4332546053photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv4332546053
 #yiv4332546053reco-category {font-size:77%;}#yiv4332546053 
#yiv4332546053reco-desc {font-size:77%;}#yiv4332546053 .yiv4332546053replbq 
{margin:4px;}#yiv4332546053 #yiv4332546053ygrp-actbar div 

Re: [oracle_br] Re: Consulta muito lenta!!

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Exatamente pessoal, estou de acordo com voces. O chamado com a SAP ja esta 
aberto, e so alteramos algo com a autorizacao da SAP.
Chiappa, realizei o que vc me pediu, mas nao obtive sucesso, o plano de 
execucao soh me mostra o E-rows.
Alterei o parametro a nivel de sessao.
Note-   - Warning: basic plan statistics not available. These are only 
collected when:       * hint 'gather_plan_statistics' is used for the statement 
or       * parameter 'statistics_level' is set to 'ALL', at session or system 
level

51 rows selected.
SQL> show parameter statistics_level
NAME                                 TYPE        
VALUE --- 
--statistics_level                     string      
ALL
 

Em Sexta-feira, 15 de Dezembro de 2017 16:20, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Verdade verdadeiríssima, por isso na minha resposta frisei bem :

"Mas só porque vc PODE fazer não quer dizer que vc DEVA okdoc ? Em especial 
quando falamos de SAP, que é uma aplicação TREMENDAMENTE FECHADA, onde nem 
sequer usar a tool de backup nativa do banco eles te deixam Sendo assim, 
NECESSARIAMENTE tudo o que vou falar tem que ser feito com CONCORDÂNCIA DO 
SUPORTE DA SAP, sim sim ?? Então se não abriu Chamado lá, ABRA!!!
 "

Eu fiquei o ano passado dando Suporte em banco de dados Oracle numa Consultoria 
especializada em SAP e tools de Report/DW/Bi baseadas no SAP, então fiquei 
sabendo quem o quão fechada e exigente ela é  Sem a menor dúvida, falou em 
SAP antes de mais nada abrir Chamado, E pra qualquer coisa que for fazer, pedir 
Anuência deles

[]s

  Chiappa  #yiv9629188119 #yiv9629188119 -- #yiv9629188119ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9629188119 
#yiv9629188119ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9629188119 
#yiv9629188119ygrp-mkp #yiv9629188119hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9629188119 #yiv9629188119ygrp-mkp #yiv9629188119ads 
{margin-bottom:10px;}#yiv9629188119 #yiv9629188119ygrp-mkp .yiv9629188119ad 
{padding:0 0;}#yiv9629188119 #yiv9629188119ygrp-mkp .yiv9629188119ad p 
{margin:0;}#yiv9629188119 #yiv9629188119ygrp-mkp .yiv9629188119ad a 
{color:#ff;text-decoration:none;}#yiv9629188119 #yiv9629188119ygrp-sponsor 
#yiv9629188119ygrp-lc {font-family:Arial;}#yiv9629188119 
#yiv9629188119ygrp-sponsor #yiv9629188119ygrp-lc #yiv9629188119hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9629188119 
#yiv9629188119ygrp-sponsor #yiv9629188119ygrp-lc .yiv9629188119ad 
{margin-bottom:10px;padding:0 0;}#yiv9629188119 #yiv9629188119actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9629188119 
#yiv9629188119activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9629188119
 #yiv9629188119activity span {font-weight:700;}#yiv9629188119 
#yiv9629188119activity span:first-child 
{text-transform:uppercase;}#yiv9629188119 #yiv9629188119activity span a 
{color:#5085b6;text-decoration:none;}#yiv9629188119 #yiv9629188119activity span 
span {color:#ff7900;}#yiv9629188119 #yiv9629188119activity span 
.yiv9629188119underline {text-decoration:underline;}#yiv9629188119 
.yiv9629188119attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9629188119 .yiv9629188119attach div a 
{text-decoration:none;}#yiv9629188119 .yiv9629188119attach img 
{border:none;padding-right:5px;}#yiv9629188119 .yiv9629188119attach label 
{display:block;margin-bottom:5px;}#yiv9629188119 .yiv9629188119attach label a 
{text-decoration:none;}#yiv9629188119 blockquote {margin:0 0 0 
4px;}#yiv9629188119 .yiv9629188119bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9629188119 
.yiv9629188119bold a {text-decoration:none;}#yiv9629188119 dd.yiv9629188119last 
p a {font-family:Verdana;font-weight:700;}#yiv9629188119 dd.yiv9629188119last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9629188119 
dd.yiv9629188119last p span.yiv9629188119yshortcuts 
{margin-right:0;}#yiv9629188119 div.yiv9629188119attach-table div div a 
{text-decoration:none;}#yiv9629188119 div.yiv9629188119attach-table 
{width:400px;}#yiv9629188119 div.yiv9629188119file-title a, #yiv9629188119 
div.yiv9629188119file-title a:active, #yiv9629188119 
div.yiv9629188119file-title a:hover, #yiv9629188119 div.yiv9629188119file-title 
a:visited {text-decoration:none;}#yiv9629188119 div.yiv9629188119photo-title a, 
#yiv9629188119 div.yiv9629188119photo-title a:active, #yiv9629188119 
div.yiv9629188119photo-title a:hover, #yiv9629188119 
div.yiv9629188119photo-title a:visited {text-decoration:none;}#yiv9629188119 
div#yiv9629188119ygrp-mlmsg #yiv9629188119ygrp-msg p a 
span.yiv9629188119yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9629188119 
.yiv9629188119green {color:#628c2a;}#yiv9629188119 

Re: [oracle_br] Re: CLUSTERING FACTOR

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Exatamente pessoal, estou de acordo com voces. O chamado com a SAP ja esta 
aberto, e so alteramos algo com a autorizacao da SAP.
Chiappa, realizei o que vc me pediu, mas nao obtive sucesso, o plano de 
execucao soh me mostra o E-rows.
Alterei o parametro a nivel de sessao.
Note-   - Warning: basic plan statistics not available. These are only 
collected when:       * hint 'gather_plan_statistics' is used for the statement 
or       * parameter 'statistics_level' is set to 'ALL', at session or system 
level

51 rows selected.
SQL> show parameter statistics_level
NAME                                 TYPE        
VALUE --- 
--statistics_level                     string      
ALL

 

Em Sexta-feira, 15 de Dezembro de 2017 14:58, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, primero pergunto, quanto é 400KK - seria 400 mil milhares, ie, 400 
milhões ?? E segundo sorry, mas NÚMERO DE LINHAS não é significativo pra gente 
isoladamente - esse X de linhas representa QUANTOS BYTES/megabytes/gigabytes 
efetivamente ?? E terceiro ponto, como está a Média de linhas por bloco físico 
nessa tabela ?

 Mas de qquer maneira : a primeira coisa que TENHO que observar é que o CLUSTER 
FACTOR é relacionado com a localização Física dos dados indexados na tabela : 
Obviamente, não tem como Fisicamente a mesma tabela ter os dados ordenados pela 
coluna X ** e ** pela coluna Y ao mesmo tempo, então fique CIENTE que se vc 
alterar/melhorar o cluster factor da tabela em relação a um índice A, muito 
certamente vc vai PIORAR em relação a um índice B... Lógico 
  Julgando por esse nome de IN_ESTENTRADA_LOTEAPRES2 , me parece que esse Não É 
o único índice dessa tabela, então VEJA LÁ se mexendo no CF de um ídnice vc Não 
Estraga o de outro índice, usado por OUTRAs Consultas Legal ??
  
 Isso posto, aí sim a sua resposta... Primeiro teste, cfrme 
http://www.oracle.com/technetwork/issue-archive/2012/12-sep/o52asktom-1735913.html
 e 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:9524251800346726054
 (e os links deste último) demonstram sim, para vc alterar o CF é fisicamente 
recriar a tabela Tenta em primeiro lugar ao invés de TRUNCAR a tabela e 
reinserir os dados (o que vai reaproveitar o mesmo segmento MAS adicionando 
novos extents) criar uma NOVA tabela (chame de TAB_ORGANIZED) com os dados 
vindos da tabela em análise ordenados num CREATE TABLE AS SELECT e depois 
criando um índice , como mostrado no primeiro link... Pra ser mais seguro 
ainda, faça isso numa tablespace LMT com gerenciamento automático... 
==> SE esse teste não resultar em alteração nenhuma do CF a gente começa a 
suspeitar de algum atributo físico que esteja 'forçando' os dados a se espalhar 
por N blocos : talvez um registro lógico extenso ?? Montes e montes de colunas 
na tabela em questão ?? OBVIAMENTE, se os dados não couberem com mita folga 
dentro do bloco, algum tipo de row chaining/row migration vai ser quase certo, 
aí o CF vai pras picas...

[]s

  Chiappa  #yiv2246574670 #yiv2246574670 -- #yiv2246574670ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2246574670 
#yiv2246574670ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2246574670 
#yiv2246574670ygrp-mkp #yiv2246574670hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2246574670 #yiv2246574670ygrp-mkp #yiv2246574670ads 
{margin-bottom:10px;}#yiv2246574670 #yiv2246574670ygrp-mkp .yiv2246574670ad 
{padding:0 0;}#yiv2246574670 #yiv2246574670ygrp-mkp .yiv2246574670ad p 
{margin:0;}#yiv2246574670 #yiv2246574670ygrp-mkp .yiv2246574670ad a 
{color:#ff;text-decoration:none;}#yiv2246574670 #yiv2246574670ygrp-sponsor 
#yiv2246574670ygrp-lc {font-family:Arial;}#yiv2246574670 
#yiv2246574670ygrp-sponsor #yiv2246574670ygrp-lc #yiv2246574670hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2246574670 
#yiv2246574670ygrp-sponsor #yiv2246574670ygrp-lc .yiv2246574670ad 
{margin-bottom:10px;padding:0 0;}#yiv2246574670 #yiv2246574670actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2246574670 
#yiv2246574670activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2246574670
 #yiv2246574670activity span {font-weight:700;}#yiv2246574670 
#yiv2246574670activity span:first-child 
{text-transform:uppercase;}#yiv2246574670 #yiv2246574670activity span a 
{color:#5085b6;text-decoration:none;}#yiv2246574670 #yiv2246574670activity span 
span {color:#ff7900;}#yiv2246574670 #yiv2246574670activity span 
.yiv2246574670underline {text-decoration:underline;}#yiv2246574670 
.yiv2246574670attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv2246574670 .yiv2246574670attach div a 
{text-decoration:none;}#yiv2246574670 .yiv2246574670attach img 

Re: [oracle_br] Re: Consulta muito lenta!!

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Chiappa, a recomendacao foi da SAP, irei checar todas essas informacoes 
passadas por voces, no fim do dia darei um retorno aqui.
Em relacao ao plano extendido com SELECT /*+ GATHER_PLAN_STATISTICS */como eu 
vou executar com as variaveis bind? Com variavel bind o select me retorna o 
erro informando que nao reconhece aquele valor obviamente.


SP2-0552: Bind variable "A4" not declared.
 

Em Sexta-feira, 15 de Dezembro de 2017 14:28, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Blz ? Vamos por partes aí : primeiro, antes de tudo, tecnicamente falando 
*** Não é verdade *** que vc não consegue mudar o texto de um SQL (para injetar 
um hint, para mudar cláusulas no WHERE, mudar tabelas no FROM, enfim, 
re-escrever o SQL) sem ter acesso ao fonte da Aplicação : minha Apresentação no 
dba brasil 1.0 (veja em 
http://www.dbabr.com.br/blog/wp-content/uploads/2016/03/SQL-Factoring.pdf) foi 
EXATAMENTE SOBRE ISSO, no caso usando a DBMS_ADVANCED_REWRITE, mas também falei 
de passagem sobre outras menos invasivas como views, sinônimos, etc... ok ? 
CONHEÇA as capacidades mas ANALISE A VIABILIDADE antes de usar...
 Mas só porque vc PODE fazer não quer dizer que vc DEVA okdoc ? Em especial 
quando falamos de SAP, que é uma aplicação TREMENDAMENTE FECHADA, onde nem 
sequer usar a tool de backup nativa do banco eles te deixam Sendo assim, 
NECESSARIAMENTE tudo o que vou falar tem que ser feito com CONCORDÂNCIA DO 
SUPORTE DA SAP, sim sim ?? Então se não abriu Chamado lá, ABRA!!!
 
 Bom, para vc começar uma análise visando tuning (E EM ESPECIAL para um SQL que 
usa & abusa de binds como parece ser esse aí!!) o Passo Inicial é vc obter um 
PLANO DE EXECUÇÃO EXTENDIDO, que mostre as colunas A-ROWs e E-ROWs, pra vc 
poder Validar se as estatísticas usadas estão razoáveis : veja 
https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate
 
 
 Outra Possibilidade é que vc tenha BIND VARIABLE PEEKING acontecendo aí e o 
Otimizador está usando estatísticas para um determinado valor peeked numa 
execução anterior que não é de frequência comum, OU mesmo que o banco esteja 
criando Múltiplos cursores child por causa dos binds : veja 
http://optimizermagic.blogspot.com.br/2007/12/why-are-there-more-cursors-in-11g-for.html
 e 
http://kerryosborne.oracle-guy.com/2009/03/bind-variable-peeking-drives-me-nuts/
 como refs... INCLUSIVE, a entrada 
https://blogs.sap.com/2013/06/13/oracle-db-optimizer-part-vi-effects-of-disabled-bind-variable-peeking-adaptive-cursor-sharing-and-cardinality-feedback-on-the-cbo-in-sap-environments/
 num blog da SAP mesmo já Alerta para essa Possibilidade, e PERCEBA que essa 
entrada mesmo do blog USA TAMBÉM as colunas A-ROWs e E-ROWs do Plano de 
Execução Extendido para Diagnóstico, sim sim ?? veja lá...
 
 Uma outra possibilidade que vc pode Perseguir é a possibilidade que o Plano de 
Execução em si esteja o melhor possível para as condições exigidas MAS 
fisicamente na hora de executar o plano o banco tá demorando muito - seja 
porque Outros SQLs tão consumindo muita banda de rede, I/O e/o CPU não deixando 
poder de hardware pro banco executar esse seu, seja porque tá com montes de 
whitespace nos segmentos em questão, ou seja qual for WAITs/locks/latches tão 
envolvidos... Faça um TRACE 10046 level máximo de uma sessão executando esse 
SQL em questão...
 
 E finalmente : vc Não Só deve repassar para o Suporte da SAP o tracle, o Plano 
Extendido e as suas conclusões da análise MAS também TEM que validar com eles 
esses PROFILES DE SQL, SQL patches e etc  que alguém (eles mesmos ?? você ??) 
criou, pois vi nos planos as linhas :
 
 
   - SQL profile coe_ag6zapv5kypgx_1159570678 used for this statement
   - SQL patch "suggest_support_sap" used for this statement
 
 []s
 
   Chiappa
   
  OBS : para fins de Análise, já que vc Identificou o SQL, nada Impede que vc, 
no seu banco de TESTE mas que tenha um volume Razoável de dados, experimentar 
HINTs, criar outros índices,  alterar o SQL para que faça acesso à chave 
COMPLETA do índice (e não à chave parcial, que deduzo estar acontecendo por 
causa dos "INDEX RANGE SCAN" e "INDEX SKIP SCAN" que vi)... QUalquer informação 
que vc obtenha nesses testes Repasse pro Suporte SAP...  #yiv8130852198 
#yiv8130852198 -- #yiv8130852198ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8130852198 
#yiv8130852198ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8130852198 
#yiv8130852198ygrp-mkp #yiv8130852198hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8130852198 #yiv8130852198ygrp-mkp #yiv8130852198ads 
{margin-bottom:10px;}#yiv8130852198 #yiv8130852198ygrp-mkp .yiv8130852198ad 
{padding:0 0;}#yiv8130852198 #yiv8130852198ygrp-mkp .yiv8130852198ad p 
{margin:0;}#yiv8130852198 #yiv8130852198ygrp-mkp .yiv8130852198ad a 
{color:#ff;text-decoration:none;}#yiv8130852198 #yiv8130852198ygrp-sponsor 

Re: [oracle_br] Consulta muito lenta!!

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado pelo rapido retorno pessoal.
Mulafani - sempre me ajudando... obrigado, porem esse caso de criar indice 
bitmap em ambiente OLTP e principalmente em tabelas extremamentes utilizadas em 
operacoes DML, essa opcao infelizmente nao vem ao caso.

Luis Freitas, criei 2 sql patches para forcar o Oracle a realizar nested loops 
ao inves de hash join porem sem sucesso, segue o codigo abaixo:

obs: repare que no final do plano de execucao, aparece: SQL patch 
"suggest_support_sap" used for this statement
Segue codigo:

http://textuploader.com/dc9sm


Tambem tentei criar um sql patch com paralelismo, mas a mesma nao utilizou, 
irei verificar os outros pontos, testarei e trarei para voces sem seguida.

 

Em Sexta-feira, 15 de Dezembro de 2017 12:23, "Rodrigo Mufalani 
rodr...@mufalani.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Bom dia,

 Uma coisa que talvez o teu ambiente tenha de sobra, e já que está usando EE, 
pense em usar DOP (PARALLEL) para essas tabelas assim a consulta vai rodar mais 
rápido.

 Dá uma lida no manual 
https://docs.oracle.com/cd/E11882_01/server.112/e25554/indexes.htm#sthref120

CREATE BITMAP INDEX sales_cust_gender_bjix
ON sales(customers.cust_gender)
FROM sales, customers
WHERE sales.cust_id = customers.cust_id
LOCAL NOLOGGING COMPUTE STATISTICS;
 OBS.: Lembrando que bitmap índexes tem que ser usados com muito cuidado, por 
conta de locks e que o paralelismo pode usar todos os recursos, verifique, 
monte um cenário de testes antes de aplicar isso em prod. OK?

Atenciosamente,
[RED]

Rodrigo Mufalani - Dir. Técnico
rodr...@mufalani.com.br
+55 21 988 994 817

Mufalani
+55 21 3193 0326
Rua Almirante Grenfall, 405, Bloco 3, Sala 310
Centro Empresarial Washington Luiz
Duque de Caxias - RJ
CEP 25085-009
www.mufalani.com.br<http://www.mufalani.com.br/>


[id:image002.png@01D2F4C6.8E6B3BE0]



De: <oracle_br@yahoogrupos.com.br> em nome de "Luis Freitas 
lfreita...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br>
Responder para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br>
Data: sexta-feira, 15 de dezembro de 2017 12:09
Para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br>
Assunto: Re: [oracle_br] Consulta muito lenta!!


Rafael,

 Difícil sugerir alguma coisa só com o plano de execução, sem saber a 
cardinalidade campos usados na query.

 O tempo maior do plano está aparecendo como CPU, e está proximo do tempo que 
você reportou, algumas coisas que poderiam ser tentadas:

- Forçar o uso de algum índice no campo RACCT, que é o numero da conta. Se 
houver uma cardinalidade grande nesse campo, pode reduzir muito o tempo de 
execução.

- Forçar um full scan na FAGLFLEXA, o que deve mudar o perfil da query de CPU 
para disco.

- Forçar um join por "nested loops", em vez de "hash". Também deve mudar o 
perfil de CPU para disco.

 Outra coisa que pode ser tentada é ativar o paralelismo na FAGLFLEXA, o que 
irá distribuir a execução da query em mais processos. Poderia ser feito por 
"sql plan management" para não ativar direto na tabela.

Atc,
Luis Freitas




On Friday, December 15, 2017 10:57 AM, "Rafael Mendonca raffaell.t...@yahoo.com 
[oracle_br]" <oracle_br@yahoogrupos.com.br> wrote:


Senhores, bom dia.

Preciso de uma grande ajuda dos especialistas.

Ambiente single instance, file system, EE 11.2.0.3
Options: diagnostic and tuning pack, in memory, advanced compression, 
partitioning


Possuo uma query do sistema SAP (standard SAP), ou seja, nao existe alternativa 
para mudança estrutural da consulta, nem por hint na consulta, nem nada, por 
ser standard. O que é possível fazer é tudo a nível de banco de dados, como 
criação de sql patch, rewrite etc...

Pois bem, vamos aos detalhes:

A consulta envolve 2 tabelas e 2 índices, cada um com seus respectivos tamanhos 
abaixo:

tabela x1: 400GB
tabela x2:160GB
Indice tab x1: 140GB
Indice tab x2: 2GB

Duracao da consulta: 16 minutos

OBS: Os segmentos envoldios nao possuem PARTICIONAMENTO ou COMPRESSAO.

COnsulta abaixo:

http://textuploader.com/dcreu


Plano de execucao abaixo (SELECT * FROM table(dbms_xplan.display_cursor)):

http://textuploader.com/dcre7



Alternativas 1:

A criacao de uma Mview para a consulta em questao, porem o SAP nao pode 
direcionar o relatorio para a MVIew, entao pensei na rewrite para forcar ao ler 
o sqlid utilizar Mview, porem se as mview nao estiver totalmente atualizada com 
as tabelas envolvidas a Mview nao sera lida, ou seja, a tabela em questao 
possui 2 bilhoes de registros, eh alterada o tempo inteiro, ou seja, sem chance.

Alternativa 2: realizar um compression OLTP nas tabelas envolvidas, o que 
acham? Problema sera a carga de DML nessas tabelas, me preocupo com a lentidao 
dos inserts, updates e deletes.

Alternativa 3: Particionamento. Porem precisamos de uma solucao rapida, ira 
entrar um processo de 

[oracle_br] Consulta muito lenta!!

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Senhores, bom dia.
Preciso de uma grande ajuda dos especialistas.
Ambiente single instance, file system, EE 11.2.0.3Options: diagnostic and 
tuning pack, in memory, advanced compression, partitioning

Possuo uma query do sistema SAP (standard SAP), ou seja, nao existe alternativa 
para mudança estrutural da consulta, nem por hint na consulta, nem nada, por 
ser standard. O que é possível fazer é tudo a nível de banco de dados, como 
criação de sql patch, rewrite etc...
Pois bem, vamos aos detalhes:
A consulta envolve 2 tabelas e 2 índices, cada um com seus respectivos tamanhos 
abaixo:
tabela x1: 400GBtabela x2:160GBIndice tab x1: 140GBIndice tab x2: 2GB
Duracao da consulta: 16 minutos
OBS: Os segmentos envoldios nao possuem PARTICIONAMENTO ou COMPRESSAO.
COnsulta abaixo:
http://textuploader.com/dcreu


Plano de execucao abaixo (SELECT * FROM table(dbms_xplan.display_cursor)):

http://textuploader.com/dcre7



Alternativas 1:
A criacao de uma Mview para a consulta em questao, porem o SAP nao pode 
direcionar o relatorio para a MVIew, entao pensei na rewrite para forcar ao ler 
o sqlid utilizar Mview, porem se as mview nao estiver totalmente atualizada com 
as tabelas envolvidas a Mview nao sera lida, ou seja, a tabela em questao 
possui 2 bilhoes de registros, eh alterada o tempo inteiro, ou seja, sem chance.
Alternativa 2: realizar um compression OLTP nas tabelas envolvidas, o que 
acham? Problema sera a carga de DML nessas tabelas, me preocupo com a lentidao 
dos inserts, updates e deletes.
Alternativa 3: Particionamento. Porem precisamos de uma solucao rapida, ira 
entrar um processo de auditoria e nao temos tempo para essa implementacao.
Alguem pode ajudar nessa dificil missao?

Re: [oracle_br] Re: AJuda script shell

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado Angelo, isso mesmo.k, com ajuda dos amigos acima, consegui fazer 
esse RTA :) 

Em Quinta-feira, 14 de Dezembro de 2017 11:40, "angelo 
angelolis...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Esse seu workaround..   isso também poderia ser chamado de "RTA - Recurso 
Tecnico Alternativo"  um nome mais pomposo para a gambi,  afinal fica feio 
falar pro cliente que fez uma "gambiarra"...   Kkkk
mas as vezes a gente tem que lançar mão dessas tecnicas mesmo.. Ta lembrando o 
caso do outro thread do problema que tava rolando com o Nagios, que o colega 
estava reclamando que de vez em quando travava o banco.

O que nos conforta é que é tudo nessa vida é codigo,  e código sempre tem bug.. 

tomara que a Oracle responda isso rapido, se é que o problema está lá, siga com 
sua pesquisa enquanto isso




2017-12-12 18:20 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br>:

     Chiappa, no ponto 1 eu concordo com tudo que voce disse. Isso eh um 
workaround vulgo gambiarra para poder sanar o problema do cliente enquanto nao 
se descobri a causa raiz, um chamado com a Oracle ja foi aberto para suporte.
Em relacao ao item 2 a minha consulta funciona sim, esse pid eh o mesmo pid do 
SO, tanto que ela existe na v$process, e nao na v$session. Tanto que funcionou!
Essa questao do alter system disconnect session eu vou testar tambem, obrigado 
pela dica.  

Em Terça-feira, 12 de Dezembro de 2017 14:25, "jlchia...@yahoo.com.br 
[oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Bom, antes de responder algumas obs importantes :

1. absolutamente NÃO É NORMAL que vc tenha que ficar matando sessão manualmente 
: necessariamente ALGUMA COISA está causando a sessão ficar 'pendurada' , e vc 
DEVERIA MESMO encontrar e solucionar esse 'alguma coisa'... Há muitas 
possibilidades, que vão desde falha na infra de rede fazendo a comunicação com 
o banco ser perdida, até bugs em middleware, ou mesmo aplicação porquinha que 
sai criando conexões novas sem desativar anteriores, coisas assim Em ALGUNS 
CASOS inclusive pode ser possível como work-around vc solicitar que o banco 
mesmo elimine sessões inativas por x minutos aplicando o DCD e um profile de 
máximo de conexão, mas normalmente o mais correto é encontrar a Causa raiz 
antes de tudo...

2. SE vc for obrigado a por qquer motivo matar a sessão, a sessão normalmente 
fica com status de KILLED apenas se vc usou (incorretamente, imho) o KILL 
SESSIOn ao invés do DISCONNECT SESSION, via de regra muito mais efetivo : 
http://www.fabioprado.net/ 2014/05/matando-sessoes-no- oracle-database.html é 
uma das refs pra ele

3. Tudo que vou falar na resposta é baseado em conexões DEDICADAS e 
PERMANENTES, e criadas quando a sessão pede conexão : EVIDENTEMENTE não se 
aplica se a sua app está usando qualquer tipo de POOLS DE CONEXÃO, ou se seu 
banco tá usando MTS/SHARED SESSIONs

Isso posto, a resposta : como eu não uso quase nunca KILL SESSION não tenho 
aqui um ambiente a testar, mas de acordo com a nota metalink "How To Find The 
Process Identifier (pid, spid) After The Corresponding Session Is Killed?" (Doc 
ID 387077.1) é possível que o ponteiro em memória do processo que atendia à 
sessão não fique mais registrado na coluna PADDR da V$SESSION, pois o processo 
de eliminação já começou no banco mas não chegou ainda a ser solicitada remoção 
no SO (seja qual for o motivo - banco intensamente concorrente, rollback sendo 
executado ainda, o que for)... Veja lá se é esse o seu caso, SE FOR ISSO 
obviamente teu JOIN :

SELECT  p.spid
    FROM v$session s,
 v$process p
   WHERE s.paddr   = p.addr
   
NÂO VAI FUNCIONAR, sim sim ?? Se for isso aplique um dos work-arounds indicados 
para encontrar o SPID (system pid, o id da task no Sistema Operacional) na 
V$PROCESS a partir da linha da V$SESSION que está com STATUS de KILLED, 
provavelmente (já que seu banco é 11g) deve ser :

select spid from v$process where addr=(select creator_addr from v$session where 
STATUS='KILLED');

Ou alguma variação muito próxima

Aí a segunda parte da resposta : uma vez que vc conseguiu uma query que extraia 
os SPIDs vc TANTO pode escrever um shell script que acione o sqlplus  via 
script e retorne o valor de cada SPID desejado QUANTO pode fazer o contrário, 
ie, dentro do sqlplus gerar um shell script com os comandos necessários - sim, 
um shell script NADA MAIS É do que um arquivo-texto, é Bico gerar um 
arquivo-texto com o output de uma query no sqlplus... Seria algo mais ou menos 
tipo :

==> vc tem um script sqlplus chamado gera_kills.sql contendo :

set term off feedback off verify off pages 0 lines 500 trimspool on head off
spool /tmp/kill_sessions.sh
select 'kill -9 ' || spid from v$process where addr=(select creator_addr from 
v$session where STATUS='KILLED')
/
select 'exit' || chr(10) from dual
/
spool o

Re: [oracle_br] Re: AJuda script shell

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Chiappa, no ponto 1 eu concordo com tudo que voce disse. Isso eh um workaround 
vulgo gambiarra para poder sanar o problema do cliente enquanto nao se descobri 
a causa raiz, um chamado com a Oracle ja foi aberto para suporte.
Em relacao ao item 2 a minha consulta funciona sim, esse pid eh o mesmo pid do 
SO, tanto que ela existe na v$process, e nao na v$session. Tanto que funcionou!
Essa questao do alter system disconnect session eu vou testar tambem, obrigado 
pela dica.  

Em Terça-feira, 12 de Dezembro de 2017 14:25, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, antes de responder algumas obs importantes :

1. absolutamente NÃO É NORMAL que vc tenha que ficar matando sessão manualmente 
: necessariamente ALGUMA COISA está causando a sessão ficar 'pendurada' , e vc 
DEVERIA MESMO encontrar e solucionar esse 'alguma coisa'... Há muitas 
possibilidades, que vão desde falha na infra de rede fazendo a comunicação com 
o banco ser perdida, até bugs em middleware, ou mesmo aplicação porquinha que 
sai criando conexões novas sem desativar anteriores, coisas assim Em ALGUNS 
CASOS inclusive pode ser possível como work-around vc solicitar que o banco 
mesmo elimine sessões inativas por x minutos aplicando o DCD e um profile de 
máximo de conexão, mas normalmente o mais correto é encontrar a Causa raiz 
antes de tudo...

2. SE vc for obrigado a por qquer motivo matar a sessão, a sessão normalmente 
fica com status de KILLED apenas se vc usou (incorretamente, imho) o KILL 
SESSIOn ao invés do DISCONNECT SESSION, via de regra muito mais efetivo : 
http://www.fabioprado.net/2014/05/matando-sessoes-no-oracle-database.html é uma 
das refs pra ele

3. Tudo que vou falar na resposta é baseado em conexões DEDICADAS e 
PERMANENTES, e criadas quando a sessão pede conexão : EVIDENTEMENTE não se 
aplica se a sua app está usando qualquer tipo de POOLS DE CONEXÃO, ou se seu 
banco tá usando MTS/SHARED SESSIONs

Isso posto, a resposta : como eu não uso quase nunca KILL SESSION não tenho 
aqui um ambiente a testar, mas de acordo com a nota metalink "How To Find The 
Process Identifier (pid, spid) After The Corresponding Session Is Killed?" (Doc 
ID 387077.1) é possível que o ponteiro em memória do processo que atendia à 
sessão não fique mais registrado na coluna PADDR da V$SESSION, pois o processo 
de eliminação já começou no banco mas não chegou ainda a ser solicitada remoção 
no SO (seja qual for o motivo - banco intensamente concorrente, rollback sendo 
executado ainda, o que for)... Veja lá se é esse o seu caso, SE FOR ISSO 
obviamente teu JOIN :

SELECT  p.spid
    FROM v$session s,
 v$process p
   WHERE s.paddr   = p.addr
   
NÂO VAI FUNCIONAR, sim sim ?? Se for isso aplique um dos work-arounds indicados 
para encontrar o SPID (system pid, o id da task no Sistema Operacional) na 
V$PROCESS a partir da linha da V$SESSION que está com STATUS de KILLED, 
provavelmente (já que seu banco é 11g) deve ser :

select spid from v$process where addr=(select creator_addr from v$session where 
STATUS='KILLED');

Ou alguma variação muito próxima

Aí a segunda parte da resposta : uma vez que vc conseguiu uma query que extraia 
os SPIDs vc TANTO pode escrever um shell script que acione o sqlplus  via 
script e retorne o valor de cada SPID desejado QUANTO pode fazer o contrário, 
ie, dentro do sqlplus gerar um shell script com os comandos necessários - sim, 
um shell script NADA MAIS É do que um arquivo-texto, é Bico gerar um 
arquivo-texto com o output de uma query no sqlplus... Seria algo mais ou menos 
tipo :

==> vc tem um script sqlplus chamado gera_kills.sql contendo :

set term off feedback off verify off pages 0 lines 500 trimspool on head off
spool /tmp/kill_sessions.sh
select 'kill -9 ' || spid from v$process where addr=(select creator_addr from 
v$session where STATUS='KILLED')
/
select 'exit' || chr(10) from dual
/
spool off
exit


Aí teu shell script principal seria tipo :

#!/bin/sh
sqlplus system/senhadele @gera_kills.sql
/tmp/kill_sessions.sh
exit



===> ok ? imho é MUUUITO mais simples vc gerar shell script a partir do sqlplus 
do que fazer o sqlplus se comunicar/retornar valores pro SOMas se por qquer 
motivo for isso que vc quer ok, é mais chatinho de fazer mas também é possivel, 
veja 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:430819636473 
ou 
https://stackoverflow.com/questions/4953842/how-to-store-result-from-sqlplus-to-a-shell-variable
 para exemplos

[]s

  Chiappa  #yiv4054497711 #yiv4054497711 -- #yiv4054497711ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4054497711 
#yiv4054497711ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4054497711 
#yiv4054497711ygrp-mkp #yiv4054497711hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4054497711 #yiv4054497711ygrp-mkp #yiv4054497711ads 
{margin-bottom:10px;}#yiv4054497711 

Re: [oracle_br] AJuda script shell

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Muito obrigado Mulafani, eu fiz da seguinte maneira:
--KILL_SESSION.ksh
#!/bin/ksh export ORACLE_SID=sdeopexport ORACLE_HOME=/oracle/11gexport 
PATH=$ORACLE_HOME/binsqlplus / as sysdba 
@/home/oracle/acndba/scripts/kill_session.sql

-- kill_session.sql
spool /home/oracle/acndba/scripts/kill_session_output.sqlselect '!kill -9 '|| 
p.spid FROM gv$session s, gv$process p WHERE s.paddr = p.addr AND s.username IS 
NOT NULL AND s.status like '%KILLED%';spool 
off@/home/oracle/acndba/scripts/kill_session_output.sql

Irei testar para ver se esta funcionando, esperando o cenario se repetir... 

Em Terça-feira, 12 de Dezembro de 2017 12:31, "Rodrigo Mufalani 
rodr...@mufalani.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Boa tarde,
    Há maneiras mais elegantes de fazer isso com shell script, mas... dá pra 
fazer somente com sql basicamente...
#!/bin/shsqlplus “/as sysdba”< on behalf of Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br] <oracle_br@yahoogrupos.com.br>
Sent: Tuesday, December 12, 2017 12:21:43 PM
To: oracle_br@yahoogrupos.com.br
Subject: Re: [oracle_br] AJuda script shell  Sergio, obrigado pela resposta, 
mas nao eh isso que preciso, falei em SCRIPT SHELL e nao a query, a query eu ja 
tenho:

kill_session.ksh
#!/bin/ksh export ORACLE_SID=export ORACLE_HOME=/oracle/lalalaexport 
PATH=$ORACLE_HOME/binsqlplus / as sysdba 
@/home/oracle//scripts/kill_session.sql

#kill_session.sql

  SELECT p.spid FROM gv$session s, gv$process p WHERE s.paddr = p.addr AND 
s.username IS NOT NULL AND s.status = 'KILLED';


Beleza, ele me gera um select dinamico com a query pra matar as sessoes, mas eu 
preciso que isso seja feita de forma automatica, alguem pode ajudar?

Em Terça-feira, 12 de Dezembro de 2017 12:00, "Sérgio Luiz Rodrigues Chaves 
sergio.cha...@elumini.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> 
escreveu:


 Bom dia,
O select abaixo é para identificação de locks mas pode ser adaptado para o que 
você precisa. Atenção para o texto que está para ambiente de RAC.
SELECT gvh.inst_id INST_BLOQUEADORA, gvh.SID SID_BLOQUEADORA, gvs.serial# 
SERIAL_BLOQUEADORA,gvs.status STATUS,gvs.username USUARIO_BLOQUEADOR, (select 
Distinct substr(sql_text,0,999) from gv$sql where sql_id = gvs.PREV_SQL_ID) 
SQL_BLOQUEADOR,gvs.module MODULO,gvs.CLIENT_INFO CLIENT_INFO, gvw.inst_id 
INST_AGUARDANDO, gvw.SID SID_AGUARDANDO,(select distinct username from 
gv$session where sid = gvw.sid and inst_id = gvw.inst_id) 
USUARIO_AGUARDANDO,(select distinct substr(sql_text,0,999) from gv$sql where 
sql_id in (select distinct sql_id from gv$session where sid = gvw.sid and 
inst_id = gvw.inst_id)) SQL_AGUARDANDO,decode(gvh.type, 'MR', 
'Media_recovery','RT', 'Redo_thread','UN', 'User_name','TX', 
'Transaction','TM', 'Dml','UL', 'PLSQL User_lock','DX', 
'Distrted_Transaxion','CF', 'Control_file','IS', 'Instance_state','FS', 
'File_set','IR', 'Instance_recovery','ST', 'Diskspace Transaction','IV', 
'Libcache_invalidation','LS', 'LogStaartORswitch','RW', 'Row_wait','SQ', 
'Sequence_no','TE', 'Extend_table','TT', 'Temp_table','Nothing-') 
TIPO_BLOQUEIO_ESPERA,decode(gvw.request, 0, 'None',1, 'NoLock',2, 
'Row-Share',3, 'Row-Exclusive',4, 'Share-Table',5, 'Share-Row-Exclusive',6, 
'Exclusive','Nothing-') modo_req_espera ,decode(gvs.username,'ATZ','ATENCAO 
ATZ',null)||'alter system kill session '||  || gvh.SID || ',' || 
gvs.serial#||',@'||gvs.INST_ID|| ''' 
IMMEDIATE;---'||decode(gvs.username,'ATZ','ATENCAO ATZ',null) 
"COMANDO_KILL_ORACLE",'EXEC KILL_SESSION ('|| gvh.SID || ',' || 
gvs.serial#||',' ||gvs.INST_ID||');' "COMANDO_KILL_ORACLE1",'kill -9 '||p.spid 
"COMANDO_KILL_LINUX",LPAD(TRUNC(gvw.ctime/3600),6)||':'||LPAD(MOD(TRUNC(gvw.ctime/60),60),2,'0')||':'||LPAD(MOD(gvw.ctime,60),2,'0')
 "TEMPO_ESPERA"FROM gv$lock gvh, gv$lock gvw, gv$session gvs, gv$process pWHERE 
(gvh.id1, gvh.id2) in (SELECT id1, id2 FROM gv$lock WHERE 
request=0INTERSECTSELECT id1, id2 FROM gv$lock WHERE lmode=0)AND 
gvh.id1=gvw.id1AND gvh.id2=gvw.id2AND gvh.request=0AND gvw.lmode=0AND 
gvh.SID=gvs.SIDAND gvh.inst_id=gvs.inst_idand gvs.paddr = p.addrand gvs.inst_id 
= p.inst_id

Desde já agradeço. Sérgio Chaves.
De: oracle_br@yahoogrupos.com.br <oracle_br@yahoogrupos.com.br> em nome de 
Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br>
Enviado: terça-feira, 12 de dezembro de 2017 11:01:48
Para: Yahoo! Brazil
Assunto: [oracle_br] AJuda script shell  Pessoal, preciso de um script shell no 
aix para matar *TODAS* as sessoes com status killed, no caso kill -9 pid:
exemplo:

  SELECT  p.spid    FROM v$session s,
         v$process p   WHERE s.paddr       = p.addr     AND s.username    IS 
NOT NULL     AND s.status      = 'KILLED'/

Alguem poderia me ajudar?

  #yiv2437521631 #yiv2437521631 -- #yiv2437521631ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;paddin

Re: [oracle_br] AJuda script shell

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

corrigindo:
select '!kill -9 '|| p.spid FROM gv$session s, gv$process p WHERE s.paddr = 
p.addr AND s.username IS NOT NULL AND s.status like '%KILLED%';


como faco pra dentro do shell, ele executar a saida do sql dinamico? 

Em Terça-feira, 12 de Dezembro de 2017 12:21, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Sergio, obrigado pela resposta, mas nao eh isso que preciso, falei em 
SCRIPT SHELL e nao a query, a query eu ja tenho:

kill_session.ksh
#!/bin/ksh export ORACLE_SID=export ORACLE_HOME=/oracle/lalalaexport 
PATH=$ORACLE_HOME/binsqlplus / as sysdba 
@/home/oracle//scripts/kill_session.sql

#kill_session.sql

  SELECT p.spid FROM gv$session s, gv$process p WHERE s.paddr = p.addr AND 
s.username IS NOT NULL AND s.status = 'KILLED';


Beleza, ele me gera um select dinamico com a query pra matar as sessoes, mas eu 
preciso que isso seja feita de forma automatica, alguem pode ajudar? 

Em Terça-feira, 12 de Dezembro de 2017 12:00, "Sérgio Luiz Rodrigues Chaves 
sergio.cha...@elumini.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> 
escreveu:
 

     Bom dia,
O select abaixo é para identificação de locks mas pode ser adaptado para o que 
você precisa. Atenção para o texto que está para ambiente de RAC.
SELECT gvh.inst_id INST_BLOQUEADORA, gvh.SID SID_BLOQUEADORA, gvs.serial# 
SERIAL_BLOQUEADORA,gvs.status STATUS,gvs.username USUARIO_BLOQUEADOR, (select 
Distinct substr(sql_text,0,999) from gv$sql where sql_id = gvs.PREV_SQL_ID) 
SQL_BLOQUEADOR,gvs.module MODULO,gvs.CLIENT_INFO CLIENT_INFO, gvw.inst_id 
INST_AGUARDANDO, gvw.SID SID_AGUARDANDO,(select distinct username from 
gv$session where sid = gvw.sid and inst_id = gvw.inst_id) 
USUARIO_AGUARDANDO,(select distinct substr(sql_text,0,999) from gv$sql where 
sql_id in (select distinct sql_id from gv$session where sid = gvw.sid and 
inst_id = gvw.inst_id)) SQL_AGUARDANDO,decode(gvh.type, 'MR', 
'Media_recovery','RT', 'Redo_thread','UN', 'User_name','TX', 
'Transaction','TM', 'Dml','UL', 'PLSQL User_lock','DX', 
'Distrted_Transaxion','CF', 'Control_file','IS', 'Instance_state','FS', 
'File_set','IR', 'Instance_recovery','ST', 'Diskspace Transaction','IV', 
'Libcache_invalidation','LS', 'LogStaartORswitch','RW', 'Row_wait','SQ', 
'Sequence_no','TE', 'Extend_table','TT', 'Temp_table','Nothing-') 
TIPO_BLOQUEIO_ESPERA,decode(gvw.request, 0, 'None',1, 'NoLock',2, 
'Row-Share',3, 'Row-Exclusive',4, 'Share-Table',5, 'Share-Row-Exclusive',6, 
'Exclusive','Nothing-') modo_req_espera ,decode(gvs.username,'ATZ','ATENCAO 
ATZ',null)||'alter system kill session '||  || gvh.SID || ',' || 
gvs.serial#||',@'||gvs.INST_ID|| ''' 
IMMEDIATE;---'||decode(gvs.username,'ATZ','ATENCAO ATZ',null) 
"COMANDO_KILL_ORACLE",'EXEC KILL_SESSION ('|| gvh.SID || ',' || 
gvs.serial#||',' ||gvs.INST_ID||');' "COMANDO_KILL_ORACLE1",'kill -9 '||p.spid 
"COMANDO_KILL_LINUX",LPAD(TRUNC(gvw.ctime/3600),6)||':'||LPAD(MOD(TRUNC(gvw.ctime/60),60),2,'0')||':'||LPAD(MOD(gvw.ctime,60),2,'0')
 "TEMPO_ESPERA"FROM gv$lock gvh, gv$lock gvw, gv$session gvs, gv$process pWHERE 
(gvh.id1, gvh.id2) in (SELECT id1, id2 FROM gv$lock WHERE 
request=0INTERSECTSELECT id1, id2 FROM gv$lock WHERE lmode=0)AND 
gvh.id1=gvw.id1AND gvh.id2=gvw.id2AND gvh.request=0AND gvw.lmode=0AND 
gvh.SID=gvs.SIDAND gvh.inst_id=gvs.inst_idand gvs.paddr = p.addrand gvs.inst_id 
= p.inst_id

Desde já agradeço. Sérgio Chaves.
De: oracle_br@yahoogrupos.com.br <oracle_br@yahoogrupos.com.br> em nome de 
Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br>
Enviado: terça-feira, 12 de dezembro de 2017 11:01:48
Para: Yahoo! Brazil
Assunto: [oracle_br] AJuda script shell  Pessoal, preciso de um script shell no 
aix para matar *TODAS* as sessoes com status killed, no caso kill -9 pid:
exemplo:

  SELECT  p.spid    FROM v$session s,
         v$process p   WHERE s.paddr       = p.addr     AND s.username    IS 
NOT NULL     AND s.status      = 'KILLED'/

Alguem poderia me ajudar?  

 #yiv0085736138 #yiv0085736138 -- #yiv0085736138ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0085736138 
#yiv0085736138ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0085736138 
#yiv0085736138ygrp-mkp #yiv0085736138hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv0085736138 #yiv0085736138ygrp-mkp #yiv0085736138ads 
{margin-bottom:10px;}#yiv0085736138 #yiv0085736138ygrp-mkp .yiv0085736138ad 
{padding:0 0;}#yiv0085736138 #yiv0085736138ygrp-mkp .yiv0085736138ad p 
{margin:0;}#yiv0085736138 #yiv0085736138ygrp-mkp .yiv0085736138ad a 
{color:#ff;text-decoration:none;}#yiv0085736138 #yiv0085736138ygrp-sponsor 
#yiv0085736138ygrp-lc {font-family:Arial;}#yiv0085736138 
#yiv0085736138ygrp-sponsor #yiv0085736138ygrp-lc #yiv0085736138hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122

Re: [oracle_br] AJuda script shell

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Sergio, obrigado pela resposta, mas nao eh isso que preciso, falei em SCRIPT 
SHELL e nao a query, a query eu ja tenho:

kill_session.ksh
#!/bin/ksh export ORACLE_SID=export ORACLE_HOME=/oracle/lalalaexport 
PATH=$ORACLE_HOME/binsqlplus / as sysdba 
@/home/oracle//scripts/kill_session.sql

#kill_session.sql

  SELECT p.spid FROM gv$session s, gv$process p WHERE s.paddr = p.addr AND 
s.username IS NOT NULL AND s.status = 'KILLED';


Beleza, ele me gera um select dinamico com a query pra matar as sessoes, mas eu 
preciso que isso seja feita de forma automatica, alguem pode ajudar? 

Em Terça-feira, 12 de Dezembro de 2017 12:00, "Sérgio Luiz Rodrigues Chaves 
sergio.cha...@elumini.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> 
escreveu:
 

     Bom dia,
O select abaixo é para identificação de locks mas pode ser adaptado para o que 
você precisa. Atenção para o texto que está para ambiente de RAC.
SELECT gvh.inst_id INST_BLOQUEADORA, gvh.SID SID_BLOQUEADORA, gvs.serial# 
SERIAL_BLOQUEADORA,gvs.status STATUS,gvs.username USUARIO_BLOQUEADOR, (select 
Distinct substr(sql_text,0,999) from gv$sql where sql_id = gvs.PREV_SQL_ID) 
SQL_BLOQUEADOR,gvs.module MODULO,gvs.CLIENT_INFO CLIENT_INFO, gvw.inst_id 
INST_AGUARDANDO, gvw.SID SID_AGUARDANDO,(select distinct username from 
gv$session where sid = gvw.sid and inst_id = gvw.inst_id) 
USUARIO_AGUARDANDO,(select distinct substr(sql_text,0,999) from gv$sql where 
sql_id in (select distinct sql_id from gv$session where sid = gvw.sid and 
inst_id = gvw.inst_id)) SQL_AGUARDANDO,decode(gvh.type, 'MR', 
'Media_recovery','RT', 'Redo_thread','UN', 'User_name','TX', 
'Transaction','TM', 'Dml','UL', 'PLSQL User_lock','DX', 
'Distrted_Transaxion','CF', 'Control_file','IS', 'Instance_state','FS', 
'File_set','IR', 'Instance_recovery','ST', 'Diskspace Transaction','IV', 
'Libcache_invalidation','LS', 'LogStaartORswitch','RW', 'Row_wait','SQ', 
'Sequence_no','TE', 'Extend_table','TT', 'Temp_table','Nothing-') 
TIPO_BLOQUEIO_ESPERA,decode(gvw.request, 0, 'None',1, 'NoLock',2, 
'Row-Share',3, 'Row-Exclusive',4, 'Share-Table',5, 'Share-Row-Exclusive',6, 
'Exclusive','Nothing-') modo_req_espera ,decode(gvs.username,'ATZ','ATENCAO 
ATZ',null)||'alter system kill session '||  || gvh.SID || ',' || 
gvs.serial#||',@'||gvs.INST_ID|| ''' 
IMMEDIATE;---'||decode(gvs.username,'ATZ','ATENCAO ATZ',null) 
"COMANDO_KILL_ORACLE",'EXEC KILL_SESSION ('|| gvh.SID || ',' || 
gvs.serial#||',' ||gvs.INST_ID||');' "COMANDO_KILL_ORACLE1",'kill -9 '||p.spid 
"COMANDO_KILL_LINUX",LPAD(TRUNC(gvw.ctime/3600),6)||':'||LPAD(MOD(TRUNC(gvw.ctime/60),60),2,'0')||':'||LPAD(MOD(gvw.ctime,60),2,'0')
 "TEMPO_ESPERA"FROM gv$lock gvh, gv$lock gvw, gv$session gvs, gv$process pWHERE 
(gvh.id1, gvh.id2) in (SELECT id1, id2 FROM gv$lock WHERE 
request=0INTERSECTSELECT id1, id2 FROM gv$lock WHERE lmode=0)AND 
gvh.id1=gvw.id1AND gvh.id2=gvw.id2AND gvh.request=0AND gvw.lmode=0AND 
gvh.SID=gvs.SIDAND gvh.inst_id=gvs.inst_idand gvs.paddr = p.addrand gvs.inst_id 
= p.inst_id

Desde já agradeço. Sérgio Chaves.
De: oracle_br@yahoogrupos.com.br <oracle_br@yahoogrupos.com.br> em nome de 
Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br>
Enviado: terça-feira, 12 de dezembro de 2017 11:01:48
Para: Yahoo! Brazil
Assunto: [oracle_br] AJuda script shell  Pessoal, preciso de um script shell no 
aix para matar *TODAS* as sessoes com status killed, no caso kill -9 pid:
exemplo:

  SELECT  p.spid    FROM v$session s,
         v$process p   WHERE s.paddr       = p.addr     AND s.username    IS 
NOT NULL     AND s.status      = 'KILLED'/

Alguem poderia me ajudar?  #yiv8262697025 #yiv8262697025 -- 
#yiv8262697025ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 
0;padding:0 10px;}#yiv8262697025 #yiv8262697025ygrp-mkp hr {border:1px solid 
#d8d8d8;}#yiv8262697025 #yiv8262697025ygrp-mkp #yiv8262697025hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8262697025 #yiv8262697025ygrp-mkp #yiv8262697025ads 
{margin-bottom:10px;}#yiv8262697025 #yiv8262697025ygrp-mkp .yiv8262697025ad 
{padding:0 0;}#yiv8262697025 #yiv8262697025ygrp-mkp .yiv8262697025ad p 
{margin:0;}#yiv8262697025 #yiv8262697025ygrp-mkp .yiv8262697025ad a 
{color:#ff;text-decoration:none;}#yiv8262697025 #yiv8262697025ygrp-sponsor 
#yiv8262697025ygrp-lc {font-family:Arial;}#yiv8262697025 
#yiv8262697025ygrp-sponsor #yiv8262697025ygrp-lc #yiv8262697025hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8262697025 
#yiv8262697025ygrp-sponsor #yiv8262697025ygrp-lc .yiv8262697025ad 
{margin-bottom:10px;padding:0 0;}#yiv8262697025 #yiv8262697025actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8262697025 
#yiv8262697025activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8262697025
 #yiv8262697025activity span {font-weight

[oracle_br] AJuda script shell

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Pessoal, preciso de um script shell no aix para matar *TODAS* as sessoes com 
status killed, no caso kill -9 pid:
exemplo:

  SELECT  p.spid    FROM v$session s,
         v$process p   WHERE s.paddr       = p.addr     AND s.username    IS 
NOT NULL     AND s.status      = 'KILLED'/

Alguem poderia me ajudar?

Re: [oracle_br] Sessões fican do "Presas" workaround please

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado Mulafani e o CHiappa.
Chiappa, **MAS É CLARO** que eu estou abrindo um outra sessão no banco para 
gerar o trace da sessão que eu desejo. Mulafani, obrigado pelo apoio, mas essa 
procedure não me serve.
Estou criando uma e assim que acabar irei postar o código dela aqui para que no 
futuro, se alguém precisar, tenha como exemplo. 

Em Segunda-feira, 4 de Dezembro de 2017 10:06, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     PMFJI, mas se a sessão a analisar está travada ou quase isso, é óbvio que 
vc deve ativar o trace a partir de OUTRA sessão, dificilemnte vc vai conseguir 
realizar trace na sessão que já está não-responsiva ou quase...
 Para isso, vc abre uma OUTRA sessão nesse banco, com um usuário DBA ou pelo 
menos com privilégios mais altos, e a partir daí vc tem VÁrias possibilidades 
para tracejar sessão de OUTRO usuário :
 
 a) já que vc já sabe o SID/SERIAL#, vc os passa como argumentos para um  
dbms_system.set_ev : trace de SQL é o evento 10046, se vc ativar esse evento é 
o mesmo que acionar o trace 
 
 ou
 
 b) pode instalar a package DBMS_SUPPORT
 
 ou
 
 c) pode descobrir o PID no sistema operacional da sessão que vc quer tracejar, 
aí informa esse PID pro oradebug
 
 ou (para alguns o melhor / mais fácil método, se teu banco é recente, 10g ou 
acima)
 
 d) usa a package DBMS_MONITOR, entre os diversos procedimentos/rotinas que ela 
possui há o session_trace_enable que permitie Sim que vc indique o SID/SERIAL# 
da OUTRA sessão, que vc já saberia quais são
 
 ==> Vc acha exemplos de TODAS essas opções em 
http://www.petefinnigan.com/ramblings/how_to_set_trace.htm   UMA VEZ QUE vc 
monitorou por bastante tempo, vc mata a sessão com um disconnect (normalmente a 
maioria dos métodos só grava o arquivo de trace quando a sessão é 
desconectada), e vc tanto pode consultar os WAITs olhando diretamente o arquivo 
de trace (as linhas que começam com WAIT#) quanto pode pedir um profile do 
arquivo de trace via tkprof ...
 
 []s
 
   Chiappa  #yiv5794922530 #yiv5794922530 -- #yiv5794922530ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5794922530 
#yiv5794922530ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5794922530 
#yiv5794922530ygrp-mkp #yiv5794922530hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5794922530 #yiv5794922530ygrp-mkp #yiv5794922530ads 
{margin-bottom:10px;}#yiv5794922530 #yiv5794922530ygrp-mkp .yiv5794922530ad 
{padding:0 0;}#yiv5794922530 #yiv5794922530ygrp-mkp .yiv5794922530ad p 
{margin:0;}#yiv5794922530 #yiv5794922530ygrp-mkp .yiv5794922530ad a 
{color:#ff;text-decoration:none;}#yiv5794922530 #yiv5794922530ygrp-sponsor 
#yiv5794922530ygrp-lc {font-family:Arial;}#yiv5794922530 
#yiv5794922530ygrp-sponsor #yiv5794922530ygrp-lc #yiv5794922530hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5794922530 
#yiv5794922530ygrp-sponsor #yiv5794922530ygrp-lc .yiv5794922530ad 
{margin-bottom:10px;padding:0 0;}#yiv5794922530 #yiv5794922530actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5794922530 
#yiv5794922530activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5794922530
 #yiv5794922530activity span {font-weight:700;}#yiv5794922530 
#yiv5794922530activity span:first-child 
{text-transform:uppercase;}#yiv5794922530 #yiv5794922530activity span a 
{color:#5085b6;text-decoration:none;}#yiv5794922530 #yiv5794922530activity span 
span {color:#ff7900;}#yiv5794922530 #yiv5794922530activity span 
.yiv5794922530underline {text-decoration:underline;}#yiv5794922530 
.yiv5794922530attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv5794922530 .yiv5794922530attach div a 
{text-decoration:none;}#yiv5794922530 .yiv5794922530attach img 
{border:none;padding-right:5px;}#yiv5794922530 .yiv5794922530attach label 
{display:block;margin-bottom:5px;}#yiv5794922530 .yiv5794922530attach label a 
{text-decoration:none;}#yiv5794922530 blockquote {margin:0 0 0 
4px;}#yiv5794922530 .yiv5794922530bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5794922530 
.yiv5794922530bold a {text-decoration:none;}#yiv5794922530 dd.yiv5794922530last 
p a {font-family:Verdana;font-weight:700;}#yiv5794922530 dd.yiv5794922530last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5794922530 
dd.yiv5794922530last p span.yiv5794922530yshortcuts 
{margin-right:0;}#yiv5794922530 div.yiv5794922530attach-table div div a 
{text-decoration:none;}#yiv5794922530 div.yiv5794922530attach-table 
{width:400px;}#yiv5794922530 div.yiv5794922530file-title a, #yiv5794922530 
div.yiv5794922530file-title a:active, #yiv5794922530 
div.yiv5794922530file-title a:hover, #yiv5794922530 div.yiv5794922530file-title 
a:visited {text-decoration:none;}#yiv5794922530 div.yiv5794922530photo-title a, 
#yiv5794922530 div.yiv5794922530photo-title a:active, #yiv5794922530 

Re: [oracle_br] Sessões ficando "Presas" workaround please

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Alguém pode me ajudar a criar essa procedure? 

Em Sexta-feira, 1 de Dezembro de 2017 18:18, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Vinicius: Realizei o purge da recyclebin e matei todas as seções porém o 
problema voltou a acontecer.
Mulafani: Cara, muito esquisito, quando eu fazer o trace da sessão do usuário, 
SOMENTE DESSE USUÁRIO, do nagios, minha sessão fica travada e não consigo 
realizar o trace, se eu pego qualquer outro usuário consigo gerar o trace 
normalmente.
SQL> oradebug setospid 23658516;oradebug tracefile_name;oradebug 
unlimit;oradebug event 10046 trace name context forever, level 12;Oracle pid: 
462, Unix process pid: 23658516, image: oracle@
e o cursor do SQL fica preso e a minha sessão fica travada, com qualquer 
usuário do NAGIOS, com outros usuários o trace é gerado normamente. 

Em Sexta-feira, 1 de Dezembro de 2017 16:55, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Obrigado a todos pelo rápido retorno.
Vinicius, irei fazer o procedimento e darei um retorno.Mulafani, irei realizar 
um trace e postarei aqui o conteudo do traceAngelo, acho que não é bug, pois o 
monitoramento do NAGIOS acontece em vários servidores desse cliente e somente 
esse database está com esse tipo de problema. 

Em Sexta-feira, 1 de Dezembro de 2017 16:44, "'Vn @ Startup' 
vinicius...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Rafael isso eh muito comum quando se tem recyclebin ativado e muitos 
objetos para purgar. Tente liberar a Bin com:
SQL> purge dba_recyclebin;
E veja se o problema eh resolvido. O select de tablespace Free do Nagios leva 
em conta segmentos na lixeira. Quanto maior o número maior a lentidão. 
Abrs. 
Em 1 de dez de 2017 3:56 PM, "angelo angelolis...@gmail.com [oracle_br]" 
<oracle_br@yahoogrupos.com.br> escreveu:

     É verdade que o nagios tem agente para monitorar BD oracle, mas
Eu acredito que o software deva estar bugado, porque o agente de monitoramento 
não deveria causar transtornos no ambiente do usuário, pelo menos em tese.. 
quanto mais "transparente" melhor  Criar uma procedure seria um paliativo, mas 
já tentou falar com o responsavel pelo software pra ver se existe alguma 
atualizacao dessa aplicação? Porque isso não vai parar... a nao ser que 
desabilite o monitoramento de BD
[]s

2017-12-01 15:23 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br> :

     Oracle EE 11.2.0.4 - Standalone (sem grid)

Senhores, em um determinado ambiente, está recorrente a abertura de chamado em 
relação a lentidão, e o que percebi consultando a v$session + v$process 
+session_event é que existe um usuário chamado XXXNAGIOS (USERNAME) que conecta 
por um server remoto (MACHINE ) utilizando o SQLPLUS (MODULE SQLPLUS) todas 
as suas sessões ficam com status ACTIVE, todas elas estão tomando a WAIT 
SQL*NET message from client e não existe nenhum sql sendo executado no momento.
Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário que 
conecta no database para realizar operações de monitoramento.
Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as 
sessões simplismente não desconectam e após os SQLs serem executados, continuam 
consumindo recurso da máquina e tomando a WAIT acima.
Enquanto a Oracle não me dá uma solução definitiva, estava pensando em realizar 
um workaround em relação a isso.Seria criar um job que executasse uma PROCEDURE 
para matar essas sessões de tempos em tempos, gostaria da ajuda de vocês para 
montar a procedure já que faz muitos anos que trabalhei com pl/sql.
O cursor para carregar os dados seria mais ou menos dessa forma:
  SELECT s.sid,          s.serial#    FROM v$session s,         v$process p   
WHERE s.paddr       = p.addr     AND s.username = 'XXXNAGIOS'     AND s.status  
    = 'ACTIVE'  AND s.module = 'SQL*PLUS'  and s.machine = 'MMM'  and 
s.last_call_et > 400;

e em um loop realizar o execute immediate ('alter system kill session ''vsid'', 
''vserial'' immediate');   
Alguém pode me ajudar a montar esse procedure?
Lembrando que isso é somente uma ação paleativa enquanto não identificamos o 
que está causando esse comportamento no ambiente.


   

   
  

 

 #yiv6561204037 #yiv6561204037 -- #yiv6561204037ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6561204037 
#yiv6561204037ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6561204037 
#yiv6561204037ygrp-mkp #yiv6561204037hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv6561204037 #yiv6561204037ygrp-mkp #yiv6561204037ads 
{margin-bottom:10px;}#yiv6561204037 #yiv6561204037ygrp-mkp .yiv6561204037ad 
{padding:0 0;}#yiv6561204037 #yiv6561204037ygrp-mkp .yiv6561204037ad p 
{margin:0;}#yiv

Re: [oracle_br] Sessões ficando "Presas" workaround please

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Vinicius: Realizei o purge da recyclebin e matei todas as seções porém o 
problema voltou a acontecer.
Mulafani: Cara, muito esquisito, quando eu fazer o trace da sessão do usuário, 
SOMENTE DESSE USUÁRIO, do nagios, minha sessão fica travada e não consigo 
realizar o trace, se eu pego qualquer outro usuário consigo gerar o trace 
normalmente.
SQL> oradebug setospid 23658516;oradebug tracefile_name;oradebug 
unlimit;oradebug event 10046 trace name context forever, level 12;Oracle pid: 
462, Unix process pid: 23658516, image: oracle@
e o cursor do SQL fica preso e a minha sessão fica travada, com qualquer 
usuário do NAGIOS, com outros usuários o trace é gerado normamente. 

Em Sexta-feira, 1 de Dezembro de 2017 16:55, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Obrigado a todos pelo rápido retorno.
Vinicius, irei fazer o procedimento e darei um retorno.Mulafani, irei realizar 
um trace e postarei aqui o conteudo do traceAngelo, acho que não é bug, pois o 
monitoramento do NAGIOS acontece em vários servidores desse cliente e somente 
esse database está com esse tipo de problema. 

Em Sexta-feira, 1 de Dezembro de 2017 16:44, "'Vn @ Startup' 
vinicius...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Rafael isso eh muito comum quando se tem recyclebin ativado e muitos 
objetos para purgar. Tente liberar a Bin com:
SQL> purge dba_recyclebin;
E veja se o problema eh resolvido. O select de tablespace Free do Nagios leva 
em conta segmentos na lixeira. Quanto maior o número maior a lentidão. 
Abrs. 
Em 1 de dez de 2017 3:56 PM, "angelo angelolis...@gmail.com [oracle_br]" 
<oracle_br@yahoogrupos.com.br> escreveu:

     É verdade que o nagios tem agente para monitorar BD oracle, mas
Eu acredito que o software deva estar bugado, porque o agente de monitoramento 
não deveria causar transtornos no ambiente do usuário, pelo menos em tese.. 
quanto mais "transparente" melhor  Criar uma procedure seria um paliativo, mas 
já tentou falar com o responsavel pelo software pra ver se existe alguma 
atualizacao dessa aplicação? Porque isso não vai parar... a nao ser que 
desabilite o monitoramento de BD
[]s

2017-12-01 15:23 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br> :

     Oracle EE 11.2.0.4 - Standalone (sem grid)

Senhores, em um determinado ambiente, está recorrente a abertura de chamado em 
relação a lentidão, e o que percebi consultando a v$session + v$process 
+session_event é que existe um usuário chamado XXXNAGIOS (USERNAME) que conecta 
por um server remoto (MACHINE ) utilizando o SQLPLUS (MODULE SQLPLUS) todas 
as suas sessões ficam com status ACTIVE, todas elas estão tomando a WAIT 
SQL*NET message from client e não existe nenhum sql sendo executado no momento.
Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário que 
conecta no database para realizar operações de monitoramento.
Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as 
sessões simplismente não desconectam e após os SQLs serem executados, continuam 
consumindo recurso da máquina e tomando a WAIT acima.
Enquanto a Oracle não me dá uma solução definitiva, estava pensando em realizar 
um workaround em relação a isso.Seria criar um job que executasse uma PROCEDURE 
para matar essas sessões de tempos em tempos, gostaria da ajuda de vocês para 
montar a procedure já que faz muitos anos que trabalhei com pl/sql.
O cursor para carregar os dados seria mais ou menos dessa forma:
  SELECT s.sid,          s.serial#    FROM v$session s,         v$process p   
WHERE s.paddr       = p.addr     AND s.username = 'XXXNAGIOS'     AND s.status  
    = 'ACTIVE'  AND s.module = 'SQL*PLUS'  and s.machine = 'MMM'  and 
s.last_call_et > 400;

e em um loop realizar o execute immediate ('alter system kill session ''vsid'', 
''vserial'' immediate');   
Alguém pode me ajudar a montar esse procedure?
Lembrando que isso é somente uma ação paleativa enquanto não identificamos o 
que está causando esse comportamento no ambiente.


   

   
  

 #yiv9079454453 #yiv9079454453 -- #yiv9079454453ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9079454453 
#yiv9079454453ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9079454453 
#yiv9079454453ygrp-mkp #yiv9079454453hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9079454453 #yiv9079454453ygrp-mkp #yiv9079454453ads 
{margin-bottom:10px;}#yiv9079454453 #yiv9079454453ygrp-mkp .yiv9079454453ad 
{padding:0 0;}#yiv9079454453 #yiv9079454453ygrp-mkp .yiv9079454453ad p 
{margin:0;}#yiv9079454453 #yiv9079454453ygrp-mkp .yiv9079454453ad a 
{color:#ff;text-decoration:none;}#yiv9079454453 #yiv9079454453ygrp-sponsor 
#yiv9079454453ygrp-lc {font-family:Arial;}#yiv9079454453 
#yiv9079454453ygrp-sponsor #yiv90794

Re: [oracle_br] Sessões ficando "Presas" workaround please

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado a todos pelo rápido retorno.
Vinicius, irei fazer o procedimento e darei um retorno.Mulafani, irei realizar 
um trace e postarei aqui o conteudo do traceAngelo, acho que não é bug, pois o 
monitoramento do NAGIOS acontece em vários servidores desse cliente e somente 
esse database está com esse tipo de problema. 

Em Sexta-feira, 1 de Dezembro de 2017 16:44, "'Vn @ Startup' 
vinicius...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Rafael isso eh muito comum quando se tem recyclebin ativado e muitos 
objetos para purgar. Tente liberar a Bin com:
SQL> purge dba_recyclebin;
E veja se o problema eh resolvido. O select de tablespace Free do Nagios leva 
em conta segmentos na lixeira. Quanto maior o número maior a lentidão. 
Abrs. 
Em 1 de dez de 2017 3:56 PM, "angelo angelolis...@gmail.com [oracle_br]" 
<oracle_br@yahoogrupos.com.br> escreveu:

     É verdade que o nagios tem agente para monitorar BD oracle, mas
Eu acredito que o software deva estar bugado, porque o agente de monitoramento 
não deveria causar transtornos no ambiente do usuário, pelo menos em tese.. 
quanto mais "transparente" melhor  Criar uma procedure seria um paliativo, mas 
já tentou falar com o responsavel pelo software pra ver se existe alguma 
atualizacao dessa aplicação? Porque isso não vai parar... a nao ser que 
desabilite o monitoramento de BD
[]s

2017-12-01 15:23 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br> :

     Oracle EE 11.2.0.4 - Standalone (sem grid)

Senhores, em um determinado ambiente, está recorrente a abertura de chamado em 
relação a lentidão, e o que percebi consultando a v$session + v$process 
+session_event é que existe um usuário chamado XXXNAGIOS (USERNAME) que conecta 
por um server remoto (MACHINE ) utilizando o SQLPLUS (MODULE SQLPLUS) todas 
as suas sessões ficam com status ACTIVE, todas elas estão tomando a WAIT 
SQL*NET message from client e não existe nenhum sql sendo executado no momento.
Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário que 
conecta no database para realizar operações de monitoramento.
Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as 
sessões simplismente não desconectam e após os SQLs serem executados, continuam 
consumindo recurso da máquina e tomando a WAIT acima.
Enquanto a Oracle não me dá uma solução definitiva, estava pensando em realizar 
um workaround em relação a isso.Seria criar um job que executasse uma PROCEDURE 
para matar essas sessões de tempos em tempos, gostaria da ajuda de vocês para 
montar a procedure já que faz muitos anos que trabalhei com pl/sql.
O cursor para carregar os dados seria mais ou menos dessa forma:
  SELECT s.sid,          s.serial#    FROM v$session s,         v$process p   
WHERE s.paddr       = p.addr     AND s.username = 'XXXNAGIOS'     AND s.status  
    = 'ACTIVE'  AND s.module = 'SQL*PLUS'  and s.machine = 'MMM'  and 
s.last_call_et > 400;

e em um loop realizar o execute immediate ('alter system kill session ''vsid'', 
''vserial'' immediate');   
Alguém pode me ajudar a montar esse procedure?
Lembrando que isso é somente uma ação paleativa enquanto não identificamos o 
que está causando esse comportamento no ambiente.


   

   
  #yiv4808968869 #yiv4808968869 -- #yiv4808968869ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4808968869 
#yiv4808968869ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4808968869 
#yiv4808968869ygrp-mkp #yiv4808968869hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4808968869 #yiv4808968869ygrp-mkp #yiv4808968869ads 
{margin-bottom:10px;}#yiv4808968869 #yiv4808968869ygrp-mkp .yiv4808968869ad 
{padding:0 0;}#yiv4808968869 #yiv4808968869ygrp-mkp .yiv4808968869ad p 
{margin:0;}#yiv4808968869 #yiv4808968869ygrp-mkp .yiv4808968869ad a 
{color:#ff;text-decoration:none;}#yiv4808968869 #yiv4808968869ygrp-sponsor 
#yiv4808968869ygrp-lc {font-family:Arial;}#yiv4808968869 
#yiv4808968869ygrp-sponsor #yiv4808968869ygrp-lc #yiv4808968869hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4808968869 
#yiv4808968869ygrp-sponsor #yiv4808968869ygrp-lc .yiv4808968869ad 
{margin-bottom:10px;padding:0 0;}#yiv4808968869 #yiv4808968869actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4808968869 
#yiv4808968869activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4808968869
 #yiv4808968869activity span {font-weight:700;}#yiv4808968869 
#yiv4808968869activity span:first-child 
{text-transform:uppercase;}#yiv4808968869 #yiv4808968869activity span a 
{color:#5085b6;text-decoration:none;}#yiv4808968869 #yiv4808968869activity span 
span {color:#ff7900;}#yiv4808968869 #yiv4808968869activity span 
.yiv4808968869underline {text-decoration:underline;}#yiv4808968869 
.yiv4808968869attach 
{cle

[oracle_br] Sessões ficando "Presas" workaround please

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Oracle EE 11.2.0.4 - Standalone (sem grid)

Senhores, em um determinado ambiente, está recorrente a abertura de chamado em 
relação a lentidão, e o que percebi consultando a v$session + v$process 
+session_event é que existe um usuário chamado XXXNAGIOS (USERNAME) que conecta 
por um server remoto (MACHINE ) utilizando o SQLPLUS (MODULE SQLPLUS) todas 
as suas sessões ficam com status ACTIVE, todas elas estão tomando a WAIT 
SQL*NET message from client e não existe nenhum sql sendo executado no momento.
Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário que 
conecta no database para realizar operações de monitoramento.
Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as 
sessões simplismente não desconectam e após os SQLs serem executados, continuam 
consumindo recurso da máquina e tomando a WAIT acima.
Enquanto a Oracle não me dá uma solução definitiva, estava pensando em realizar 
um workaround em relação a isso.Seria criar um job que executasse uma PROCEDURE 
para matar essas sessões de tempos em tempos, gostaria da ajuda de vocês para 
montar a procedure já que faz muitos anos que trabalhei com pl/sql.
O cursor para carregar os dados seria mais ou menos dessa forma:
  SELECT s.sid,          s.serial#    FROM v$session s,         v$process p   
WHERE s.paddr       = p.addr     AND s.username = 'XXXNAGIOS'     AND s.status  
    = 'ACTIVE'  AND s.module = 'SQL*PLUS'  and s.machine = 'MMM'  and 
s.last_call_et > 400;

e em um loop realizar o execute immediate ('alter system kill session ''vsid'', 
''vserial'' immediate');   
Alguém pode me ajudar a montar esse procedure?
Lembrando que isso é somente uma ação paleativa enquanto não identificamos o 
que está causando esse comportamento no ambiente.

Re: [oracle_br] Migração

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Evandro, obrigado pelo retorno.
Eu estava pensando em fazer assim, mas me parece que existe um passo a mais aí 
quando se trata de um database com ADvanved security. Existem dezenas de 
arquivos de segurança no file system, e se não me engano, o ORACLE_HOME deve 
ser migrado em um ORACLE_HOME separado dos databases já existentes do novo 
servidor para evitar impacto. Li a respeito disso há um tempo atrás.
Vamos ver se alaguém mais pode opinar em relação a isso. 

Em Segunda-feira, 13 de Novembro de 2017 11:08, "Evandro Giachetto 
evandrogiache...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Eu gosto sempre de utilizar Dataguard para reduzir o downtime em migrações 
de servidores.
Faço o setup do dataguard alguns dias antes da migração de fato. Confirmo que 
está fazendo o replicate corretamente e que está 100% sincronizado, sem gaps.
No dia da migração, simplesmente paro o banco origem e torno o banco destino 
ativo. O tempo de downtime é mínimo, apenas alguns minutos (dependendo da 
quantidade de archives a serem aplicados).
*Consulte as opções de licença para este modelo. Dataguard exige licença em 
algumas modalidades de uso.
Evandro Giachetto
Oracle DBA
evandrogiachetto@gmail.comhttp://www.dbaoracle.eti.br/



Em 13 de novembro de 2017 10:54, Rafael Mendonca raffaell.t...@yahoo.com 
[oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:

     SEnhores, bom dia.
Segue:
Ambiente atual:
Oracle 11.2.0.4 EESO: Linux 6 64 bitsSingle instanceTamanho da base: 2TB
Ambiente para migração:
Servidor com as mesmas configurações, apenas com a diferença que se trata de um 
ambiente RAC com dois nós (já existe uma base em funcionamento nesse cluster). 
Será criado uma nova base para realizar a migração.

O tempo de downtime é de aproximadamente 5 a 6 horas e que o ambiente possui 
todas as options de Security envolvidos. Existe database vault, TDE nesse 
ambiente. Existe uma série de arquivos que são criados a nível de sistema 
operacional/file system.

Minha dúvida é: Qual seria o melhor procedimento para realizar esse tipo de 
migração.
   

  #yiv2471386280 #yiv2471386280 -- #yiv2471386280ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2471386280 
#yiv2471386280ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2471386280 
#yiv2471386280ygrp-mkp #yiv2471386280hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2471386280 #yiv2471386280ygrp-mkp #yiv2471386280ads 
{margin-bottom:10px;}#yiv2471386280 #yiv2471386280ygrp-mkp .yiv2471386280ad 
{padding:0 0;}#yiv2471386280 #yiv2471386280ygrp-mkp .yiv2471386280ad p 
{margin:0;}#yiv2471386280 #yiv2471386280ygrp-mkp .yiv2471386280ad a 
{color:#ff;text-decoration:none;}#yiv2471386280 #yiv2471386280ygrp-sponsor 
#yiv2471386280ygrp-lc {font-family:Arial;}#yiv2471386280 
#yiv2471386280ygrp-sponsor #yiv2471386280ygrp-lc #yiv2471386280hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2471386280 
#yiv2471386280ygrp-sponsor #yiv2471386280ygrp-lc .yiv2471386280ad 
{margin-bottom:10px;padding:0 0;}#yiv2471386280 #yiv2471386280actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2471386280 
#yiv2471386280activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2471386280
 #yiv2471386280activity span {font-weight:700;}#yiv2471386280 
#yiv2471386280activity span:first-child 
{text-transform:uppercase;}#yiv2471386280 #yiv2471386280activity span a 
{color:#5085b6;text-decoration:none;}#yiv2471386280 #yiv2471386280activity span 
span {color:#ff7900;}#yiv2471386280 #yiv2471386280activity span 
.yiv2471386280underline {text-decoration:underline;}#yiv2471386280 
.yiv2471386280attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv2471386280 .yiv2471386280attach div a 
{text-decoration:none;}#yiv2471386280 .yiv2471386280attach img 
{border:none;padding-right:5px;}#yiv2471386280 .yiv2471386280attach label 
{display:block;margin-bottom:5px;}#yiv2471386280 .yiv2471386280attach label a 
{text-decoration:none;}#yiv2471386280 blockquote {margin:0 0 0 
4px;}#yiv2471386280 .yiv2471386280bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv2471386280 
.yiv2471386280bold a {text-decoration:none;}#yiv2471386280 dd.yiv2471386280last 
p a {font-family:Verdana;font-weight:700;}#yiv2471386280 dd.yiv2471386280last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv2471386280 
dd.yiv2471386280last p span.yiv2471386280yshortcuts 
{margin-right:0;}#yiv2471386280 div.yiv2471386280attach-table div div a 
{text-decoration:none;}#yiv2471386280 div.yiv2471386280attach-table 
{width:400px;}#yiv2471386280 div.yiv2471386280file-title a, #yiv2471386280 
div.yiv2471386280file-title a:active, #yiv2471386280 
div.yiv2471386280file-title a:hover, #yiv2471386280 div.yiv2471386280file-title 
a:visited {text-decoration:none;}#yiv2471386280 div.yi

Re: [oracle_br] Curso Golden Gate

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Curso presencial da GG somente oficial da Oracle, isso se vc tiver sorte de 
achar gente pra fechar uma turma. OUtro curso de GG que vc pode fazer é com o 
Gavin Soorma, eu já fiz um curso de exadata com ele. E ele pe referencia em GG 
no mundo. Agora vc tem que ter um ingles muito afiado, por ele ser indiano vc 
dificilmente entende o que ele fala. 

Em Segunda-feira, 13 de Novembro de 2017 10:15, "Fabio Prado 
fbifa...@gmail.com [oracle_br]"  escreveu:
 

     A En-sof nao trabalha mais com treinamentos Oracle. Vai ser muito difícil 
vc conseguir contratar esse treinamento em algum parceiro oficial da Oracle. 
Eles nao estao conseguindo fechar turmas.
Abs
Em 13 de nov de 2017 09:12, "'Milanez, Mr. (Rafael)' 
rmila...@makrosouthamerica.com [oracle_br]"  
escreveu:

     Obrigado pela ajuda Chiappa/Peterson,Eu prefiro treinamento presencial, 
acho mais produtivo.Vou verificar com o Portilho sobre o GG, outra opção de 
centro de treinamento que recebi foi a EN-SOF http://www.en-sof.com.br/ 
treinamento/exibe_curso.php? nome_curso=Oracle% 20GoldenGate%2012c:%20Fundame  
From: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos. com.br] 
Sent: segunda-feira, 13 de novembro de 2017 09:14
To: oracle_br@yahoogrupos.com.br
Subject: Re: [oracle_br] Curso Golden Gate   Comigo tudo jóia, Petersen... 

  Sobre o tópico, sobre Presencial é isso mesmo :  realmente neste momento nem 
a Oracle nem os outros citados tem o Curso em questão disponível mas olhando 
nos sites vc vê que todos no passado já fizeram algum treinamento/workshop 
sobre o assunto - vale a pena o Rafael entrar em contato com todos e conversar, 
pra ficar sabendo se/quando alguém vai voltar a dar treinamento sobre o tópico, 
E se possível avaliar as outras opções de Treinamento online
  
  []s
  
    ChiappaThe information transferred by this e-mail is solely for the 
intended recipient(s).Any disclosure, copying, distribution of this e-mail by 
and to others is not allowed. If you are not an intended recipient, please 
delete this e-mail and notify the sender.   
  #yiv7246360942 #yiv7246360942 -- #yiv7246360942ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7246360942 
#yiv7246360942ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7246360942 
#yiv7246360942ygrp-mkp #yiv7246360942hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7246360942 #yiv7246360942ygrp-mkp #yiv7246360942ads 
{margin-bottom:10px;}#yiv7246360942 #yiv7246360942ygrp-mkp .yiv7246360942ad 
{padding:0 0;}#yiv7246360942 #yiv7246360942ygrp-mkp .yiv7246360942ad p 
{margin:0;}#yiv7246360942 #yiv7246360942ygrp-mkp .yiv7246360942ad a 
{color:#ff;text-decoration:none;}#yiv7246360942 #yiv7246360942ygrp-sponsor 
#yiv7246360942ygrp-lc {font-family:Arial;}#yiv7246360942 
#yiv7246360942ygrp-sponsor #yiv7246360942ygrp-lc #yiv7246360942hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7246360942 
#yiv7246360942ygrp-sponsor #yiv7246360942ygrp-lc .yiv7246360942ad 
{margin-bottom:10px;padding:0 0;}#yiv7246360942 #yiv7246360942actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7246360942 
#yiv7246360942activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7246360942
 #yiv7246360942activity span {font-weight:700;}#yiv7246360942 
#yiv7246360942activity span:first-child 
{text-transform:uppercase;}#yiv7246360942 #yiv7246360942activity span a 
{color:#5085b6;text-decoration:none;}#yiv7246360942 #yiv7246360942activity span 
span {color:#ff7900;}#yiv7246360942 #yiv7246360942activity span 
.yiv7246360942underline {text-decoration:underline;}#yiv7246360942 
.yiv7246360942attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv7246360942 .yiv7246360942attach div a 
{text-decoration:none;}#yiv7246360942 .yiv7246360942attach img 
{border:none;padding-right:5px;}#yiv7246360942 .yiv7246360942attach label 
{display:block;margin-bottom:5px;}#yiv7246360942 .yiv7246360942attach label a 
{text-decoration:none;}#yiv7246360942 blockquote {margin:0 0 0 
4px;}#yiv7246360942 .yiv7246360942bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv7246360942 
.yiv7246360942bold a {text-decoration:none;}#yiv7246360942 dd.yiv7246360942last 
p a {font-family:Verdana;font-weight:700;}#yiv7246360942 dd.yiv7246360942last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv7246360942 
dd.yiv7246360942last p span.yiv7246360942yshortcuts 
{margin-right:0;}#yiv7246360942 div.yiv7246360942attach-table div div a 
{text-decoration:none;}#yiv7246360942 div.yiv7246360942attach-table 
{width:400px;}#yiv7246360942 div.yiv7246360942file-title a, #yiv7246360942 
div.yiv7246360942file-title a:active, #yiv7246360942 
div.yiv7246360942file-title a:hover, #yiv7246360942 div.yiv7246360942file-title 
a:visited {text-decoration:none;}#yiv7246360942 

[oracle_br] Migração

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

SEnhores, bom dia.
Segue:
Ambiente atual:
Oracle 11.2.0.4 EESO: Linux 6 64 bitsSingle instanceTamanho da base: 2TB
Ambiente para migração:
Servidor com as mesmas configurações, apenas com a diferença que se trata de um 
ambiente RAC com dois nós (já existe uma base em funcionamento nesse cluster). 
Será criado uma nova base para realizar a migração.

O tempo de downtime é de aproximadamente 5 a 6 horas e que o ambiente possui 
todas as options de Security envolvidos. Existe database vault, TDE nesse 
ambiente. Existe uma série de arquivos que são criados a nível de sistema 
operacional/file system.

Minha dúvida é: Qual seria o melhor procedimento para realizar esse tipo de 
migração.

Re: [oracle_br] Problema Oracle RAC

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } Primeiro confirme se a rede está desabilitada, deve ser isso pq o 
scan não migrou:
srvctl status nodeapps
Se eu estiver correto, mande no rac2:
srvctl start nodeapps
Habilitando, vc faz o relocate:
srvctl status scan
Vc porvavelmente ira ver os 3 rodando no rac1
srvctl relocate scan_listener -i 2 -n rac2
Roda o status e vc ira ver que o scan do listener_scan2 está rodando no seu nó 
rac2

ps -ef |grep SCAN


Enviado do Yahoo Mail para iPhone


Em sexta-feira, abril 21, 2017, 2:33 PM, José Mario Barduchi zegue...@gmail.com 
[oracle_br]  escreveu:

    

Carlos, boa tarde
Não tenho certeza se é obrigatório, mas me parece que vc precisa fazer um 
relocate do SCAN.
srvctl relocate scan_LISTENER -i 1 -n node1
Abraço





José Mario BarduchiCel: +5511 95052-8806Database Administrator - Oracle


2017-04-21 9:40 GMT-03:00 Carlos Eduardo carloseduard...@yahoo.com [oracle_br] 
:

     

Cenário:
Oracle RAC 12cR1 OEL 6.9 com dois nós
Configuração /etc/hosts
# Public192.168.56.101   rac1.localdomain        rac1192.168.56.102   
rac2.localdomain        rac2# Private192.168.1.101   rac1-priv.localdomain   
rac1-priv192.168.1.102   rac2-priv.localdomain   rac2-priv# 
Virtual192.168.56.103  rac1-vip.localdomain    rac1-vip192.168.56.104  
rac2-vip.localdomain    rac2-vip# SCAN#192.168.56.105   rac-scan.localdomain 
rac-scan#192.168.56.106   rac-scan.localdomain rac-scan#192.168.56.107   
rac-scan.localdomain rac-scan


ora.mgmtdb      1        OFFLINE OFFLINE                               Instance 
Shutdown,ST                                                             
ABLEora.oc4j      1        ONLINE  ONLINE       rac1                     
STABLEora.rac1.vip      1        ONLINE  ONLINE       rac1                     
STABLEora.rac2.vip      1        ONLINE  ONLINE       rac2                     
STABLEora.scan1.vip      1        ONLINE  ONLINE       rac1                     
STABLEora.scan2.vip      1        ONLINE  ONLINE       rac1                     
STABLEora.scan3.vip      1        ONLINE  ONLINE       rac1                     
STABLEora.terra.db      1        ONLINE  ONLINE       rac1                     
Open,STABLE      2        ONLINE  ONLINE       rac2                     
Open,STABLE      Eu gostaria de entender o motivo pelo qual meu endereço SCAN 
está apontando os 3 ips para o mesmo nó (RAC1),pelo que eu sei, pelo menos um 
endereço SCAN deveria estar apontando para o nó 2 (RAC2), estou com as duas 
instanciasem modo OPEN há um bom tempo e o endereço SCAN não migrou de volta 
para a instância de nó 2, gostaria de enteder pq o SCAN não migrou de voltapara 
o nó 2 e como eu faço para resolver esse problema.
Uma outra dúvida é em relação ao repositório do Grid Infraestructured o MGMTDB 
que ficou offline, pois eu mandei um crsctl start cluster e o databaseainda 
continua shutdown. Queria saber como faço para resolver também essa situação.
Obrigado e desculpem pelo simples problema diante de tanta fera que tem nesse 
grupo.

   

  #yiv9578779290 #yiv9578779290 -- #yiv9578779290ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9578779290 
#yiv9578779290ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9578779290 
#yiv9578779290ygrp-mkp #yiv9578779290hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9578779290 #yiv9578779290ygrp-mkp #yiv9578779290ads 
{margin-bottom:10px;}#yiv9578779290 #yiv9578779290ygrp-mkp .yiv9578779290ad 
{padding:0 0;}#yiv9578779290 #yiv9578779290ygrp-mkp .yiv9578779290ad p 
{margin:0;}#yiv9578779290 #yiv9578779290ygrp-mkp .yiv9578779290ad a 
{color:#ff;text-decoration:none;}#yiv9578779290 #yiv9578779290ygrp-sponsor 
#yiv9578779290ygrp-lc {font-family:Arial;}#yiv9578779290 
#yiv9578779290ygrp-sponsor #yiv9578779290ygrp-lc #yiv9578779290hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9578779290 
#yiv9578779290ygrp-sponsor #yiv9578779290ygrp-lc .yiv9578779290ad 
{margin-bottom:10px;padding:0 0;}#yiv9578779290 #yiv9578779290actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9578779290 
#yiv9578779290activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9578779290
 #yiv9578779290activity span {font-weight:700;}#yiv9578779290 
#yiv9578779290activity span:first-child 
{text-transform:uppercase;}#yiv9578779290 #yiv9578779290activity span a 
{color:#5085b6;text-decoration:none;}#yiv9578779290 #yiv9578779290activity span 
span {color:#ff7900;}#yiv9578779290 #yiv9578779290activity span 
.yiv9578779290underline {text-decoration:underline;}#yiv9578779290 
.yiv9578779290attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 

Re: RES: RES: [oracle_br] upgrade 12.1 to 12.2 ?

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } Ednilson, sempre que for atualizar um database que utiliza o 
catálogo, eh uma boa pratica atualizar primeiro o catálogo. O catálogo com a 
versão a frente sempre vai funcionar com databases de versões mais antigas, mas 
o contrário não eh verdade.


Enviado do Yahoo Mail para iPhone


Em quinta-feira, abril 20, 2017, 2:17 PM, 'Ednilson Silva' 
ednilson.si...@jbs.com.br [oracle_br]  escreveu:

    


Luis,

Agora entendi o que estava ocorrendo.

Fiz o UPGRADE CATALOG e atualizou o catalogo.

  

Mufalani,

Obrigado pela ajuda tambem.

  

Grato,

Ednilson

  

De: 
sentto-1682896-121760-1492697172-ednilson.silva=jbs.com...@returns.groups.yahoo.com
 
[mailto:sentto-1682896-121760-1492697172-ednilson.silva=jbs.com...@returns.groups.yahoo.com]
 Em nome de Luis Freitas lfreita...@yahoo.com [oracle_br]
Enviada em: quinta-feira, 20 de abril de 2017 11:06
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: [oracle_br] upgrade 12.1 to 12.2 ?

  

  

Ednilson,

  

   A versão do catalogo não depende da versão do banco em que foi criado, mas 
da versão do RMAN que você usou quando rodou o create catalog no esquema do 
catalogo. Você não precisa instalar nada para atualizar ele, basta rodar o 
comando com algum RMAN de versão mais recente. Mas faça um backup do catalogo 
antes, caso o rman da 10g pare de funcionar e você precise voltar o catalogo 
para a versão anterior.

  

   É mais seguro criar um catalogo separado para a 12.2. 

  

   Há alguma compatibilidade do catalogo com versões mais antigas do rman, no 
suporte tem o documento RMAN Compatibility Matrix (Doc ID 73431.1), mas ele 
ainda não foi atualizado para o Oracle 12.2.

  

Atc,

Luis Freitas

  

  

On Thursday, April 20, 2017 10:36 AM, "'Ednilson Silva' 
ednilson.si...@jbs.com.br [oracle_br]"  wrote:

  

  

Angelo,

Então, o catalogo nunca foi 11, nasceu como 12.1 mesmo.

Os demais bancos aqui entre 10g e 11g estão funcionando sem problemas.

 

Mas esse banco novo é 12.2

 

Então eu teria que instalar o binario do 12.2 e migrar o catalogo, certo?

 

Grato,

Ednilson

 

De: 
sentto-1682896-121758-1492694385-ednilson.silva=jbs.com...@returns.groups.yahoo.com
 
[mailto:sentto-1682896-121758-1492694385-ednilson.silva=jbs.com...@returns.groups.yahoo.com]
 Em nome de angelo angelolis...@gmail.com [oracle_br]
Enviada em: quinta-feira, 20 de abril de 2017 10:13
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] upgrade 12.1 to 12.2 ?

 

  

Curiosidade

 

Isso ja foi  11.2.0.4 tambem ? ( foi subindo de 11g pra 12c.. )

 

O proprio erro ta entregando..   PL/SQL package RMAN.DBMS_RCVCAT version 
11.02.00.04 in RCVCAT database is too old

 

tenta atualizar o catalogo

 

 

 

  

 

On 20 April 2017 at 09:58, 'Ednilson Silva' ednilson.si...@jbs.com.br 
[oracle_br]  wrote:

  

Pessoal,

Tenho um Catalogo do RMAN que esta no 12.1, e agora estou tentando registrar um 
banco 12.2

 

Recovery Manager: Release 12.2.0.1.0 - Production on Thu Apr 20 09:44:35 2017

 

Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.

 

connected to target database: DBOADTP (DBID=1459929393)

connected to recovery catalog database

PL/SQL package RMAN.DBMS_RCVCAT version 11.02.00.04 in RCVCAT database is too 
old

 

Como devo proceder para atualizar a versão desse meu banco RMAN de 12.1 para 
12.2 ?

 

Grato,

Ednilson Silva

 

  


  #yiv7419990407 #yiv7419990407 -- #yiv7419990407ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7419990407 
#yiv7419990407ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7419990407 
#yiv7419990407ygrp-mkp #yiv7419990407hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7419990407 #yiv7419990407ygrp-mkp #yiv7419990407ads 
{margin-bottom:10px;}#yiv7419990407 #yiv7419990407ygrp-mkp .yiv7419990407ad 
{padding:0 0;}#yiv7419990407 #yiv7419990407ygrp-mkp .yiv7419990407ad p 
{margin:0;}#yiv7419990407 #yiv7419990407ygrp-mkp .yiv7419990407ad a 
{color:#ff;text-decoration:none;}#yiv7419990407 #yiv7419990407ygrp-sponsor 
#yiv7419990407ygrp-lc {font-family:Arial;}#yiv7419990407 
#yiv7419990407ygrp-sponsor #yiv7419990407ygrp-lc #yiv7419990407hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7419990407 
#yiv7419990407ygrp-sponsor #yiv7419990407ygrp-lc .yiv7419990407ad 
{margin-bottom:10px;padding:0 0;}#yiv7419990407 #yiv7419990407actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7419990407 
#yiv7419990407activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7419990407
 #yiv7419990407activity span {font-weight:700;}#yiv7419990407 
#yiv7419990407activity span:first-child 

Re: RES: RES: [oracle_br] Re: Oracle Features

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Carlos, não sei se vai te ajudar, não acompanhei a thread toda...
Segue material que retirei do Blog/forum do mestre Ricardo Portilho


"Este é o procedimento que sigo para remover o uso de todas as Features de 
Enterprise Edition de um banco de dados, para deixá-lo compatível com a 
Standard Edition, Standard Edition One, ou Standard Edition Two.
– Remover índices BITMAP.– Remover DEGREE de objetos.– Retirar compressão de 
objetos.– Remover compressão de configurações do RMAN.– Remover compressão de 
procedimentos de backup.– Remover SQL Profiles.– Remover SQL Baselines.– 
Remover Partições.– Executar DUMP apenas do(s) OWNER(s) da aplicação, e não 
FULL.– Instalar o Oracle da Edition correta (SE1 / SE / SE2).– Nas SE e SE1 (<= 
12.1.0.1), o instalador é o mesmo, e a opção para SE / SE1 aparece durante a 
instalação. - Na SE2 (>= 12.1.0.2), o instalador é separado.– Remover opções 
após a instalação (via chopt).– Criar um novo banco de dados, via Template 
“Custom Database” do DBCA. Ainda no DBCA, alterar estes parâmetros:AUDIT_TRAIL 
= NONECONTROL_MANAGEMENT_PACK_ACCESS = NONEDEFERRED_SEGMENT_CREATION = 
FALSEJOB_QUEUE_PROCESSES = 0OPTIMIZER_USE_SQL_PLAN_BASELINES = 
FALSEOPTIMIZER_ADAPTIVE_FEATURES = FALSE — Apenas 12c.PARALLEL_MAX_SERVERS = 
0RESOURCE_LIMIT = FALSE
– Imediatamente após a criação do banco, executar:EXEC 
DBMS_AUTO_TASK_ADMIN.DISABLE (CLIENT_NAME => ‘auto optimizer stats collection’, 
OPERATION => NULL, WINDOW_NAME => NULL);EXEC DBMS_AUTO_TASK_ADMIN.DISABLE 
(CLIENT_NAME => ‘sql tuning advisor’, OPERATION => NULL, WINDOW_NAME => 
NULL);EXEC DBMS_AUTO_TASK_ADMIN.DISABLE (CLIENT_NAME => ‘auto space advisor’, 
OPERATION => NULL, WINDOW_NAME => NULL);— Em 12c, executar as alterações acima 
também em PDBs.SELECT NAME, DETECTED_USAGES, CURRENTLY_USED, FIRST_USAGE_DATE, 
LAST_USAGE_DATE FROM DBA_FEATURE_USAGE_STATISTICS ORDER BY LAST_USAGE_DATE 
DESC;— Executar novamente a verificação acima 8 dias depois.
– Adequar o parâmetro JOB_QUEUE_PROCESSES de acordo com o ambiente.– Importar o 
DUMP.
"
 

Em Sexta-feira, 24 de Fevereiro de 2017 18:47, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Sim, concordo que o mais seguro é mesmo salvar/exportar seus dados no 
banco atual não-Standard, criar  um NOVO database Standard Edition, patcheá-lo 
no último patchset e no último CPU/PSU da sua versão/ambiente e inserir os 
dados nesse novo database Standard Edition, sim Aí vc tem 100% de certeza 
que ninguém (nem sofware nem pessoa) fez nada de diferente
 Sobre a questão das policies de VPD em objetos internos do banco (como são os 
do schemas MDSYS e os objetos usados pelo XDB), mais por uma questão de 
Curiosidade/completude vamos ver as respostas que recebemos de quem usa 
Standard Edition (como eu disse não use nem SE nem SE1) , mas em  
http://www.sejustloveit.com/ o pessoal indicou que os scripts mesmo de criação 
do banco (gerados pelo assistente de banco dbca) já criam mesmo essas policies, 
então entendo que não tem como a Oracle querer cobrar Licença de alguma coisa 
interna, que não são seus usuários que criaram e usam
 
 []s
 
   Chiappa  #yiv7913155437 #yiv7913155437 -- #yiv7913155437ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7913155437 
#yiv7913155437ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7913155437 
#yiv7913155437ygrp-mkp #yiv7913155437hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7913155437 #yiv7913155437ygrp-mkp #yiv7913155437ads 
{margin-bottom:10px;}#yiv7913155437 #yiv7913155437ygrp-mkp .yiv7913155437ad 
{padding:0 0;}#yiv7913155437 #yiv7913155437ygrp-mkp .yiv7913155437ad p 
{margin:0;}#yiv7913155437 #yiv7913155437ygrp-mkp .yiv7913155437ad a 
{color:#ff;text-decoration:none;}#yiv7913155437 #yiv7913155437ygrp-sponsor 
#yiv7913155437ygrp-lc {font-family:Arial;}#yiv7913155437 
#yiv7913155437ygrp-sponsor #yiv7913155437ygrp-lc #yiv7913155437hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7913155437 
#yiv7913155437ygrp-sponsor #yiv7913155437ygrp-lc .yiv7913155437ad 
{margin-bottom:10px;padding:0 0;}#yiv7913155437 #yiv7913155437actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7913155437 
#yiv7913155437activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7913155437
 #yiv7913155437activity span {font-weight:700;}#yiv7913155437 
#yiv7913155437activity span:first-child 
{text-transform:uppercase;}#yiv7913155437 #yiv7913155437activity span a 
{color:#5085b6;text-decoration:none;}#yiv7913155437 #yiv7913155437activity span 
span {color:#ff7900;}#yiv7913155437 #yiv7913155437activity span 
.yiv7913155437underline {text-decoration:underline;}#yiv7913155437 
.yiv7913155437attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv7913155437 .yiv7913155437attach div a 
{text-decoration:none;}#yiv7913155437 .yiv7913155437attach img 

Re: [oracle_br] Re: Erro ao instalar GRID

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

OK Chiappa, irei verificar essa sua recomendação. caso não consiga resolver, 
irei seguir o tutorial do Tim Hall indicado por você.
Obrigado. 

Em Terça-feira, 17 de Janeiro de 2017 13:46, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bem, como nunca usei esse Tutorial (sempre preferi os do ORACLE-BASE, 
normalmente o cara é bem cuidadoso nos detalhes) então não sei te 
indicar/avaliar onde pode estar a falha O mais que posso Recomendar, se vc 
*** RECHECOU *** direitinho, passo-a-passo e não esqueceu NADICA DE NADA, seria 
mesmo checar por prováveis conflitos de IP... Inclusive, pelo que entendi nesse 
Tutorial aí ele cria uma terceira interf de rede em BRIDGE pra dar acesso à 
internet, experimenta remover/desabilitar isso pra ver se não é esse carinha 
dando conflito eventualmente

[]s

  Chiappa  #yiv6153207137 #yiv6153207137 -- #yiv6153207137ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6153207137 
#yiv6153207137ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6153207137 
#yiv6153207137ygrp-mkp #yiv6153207137hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv6153207137 #yiv6153207137ygrp-mkp #yiv6153207137ads 
{margin-bottom:10px;}#yiv6153207137 #yiv6153207137ygrp-mkp .yiv6153207137ad 
{padding:0 0;}#yiv6153207137 #yiv6153207137ygrp-mkp .yiv6153207137ad p 
{margin:0;}#yiv6153207137 #yiv6153207137ygrp-mkp .yiv6153207137ad a 
{color:#ff;text-decoration:none;}#yiv6153207137 #yiv6153207137ygrp-sponsor 
#yiv6153207137ygrp-lc {font-family:Arial;}#yiv6153207137 
#yiv6153207137ygrp-sponsor #yiv6153207137ygrp-lc #yiv6153207137hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv6153207137 
#yiv6153207137ygrp-sponsor #yiv6153207137ygrp-lc .yiv6153207137ad 
{margin-bottom:10px;padding:0 0;}#yiv6153207137 #yiv6153207137actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv6153207137 
#yiv6153207137activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv6153207137
 #yiv6153207137activity span {font-weight:700;}#yiv6153207137 
#yiv6153207137activity span:first-child 
{text-transform:uppercase;}#yiv6153207137 #yiv6153207137activity span a 
{color:#5085b6;text-decoration:none;}#yiv6153207137 #yiv6153207137activity span 
span {color:#ff7900;}#yiv6153207137 #yiv6153207137activity span 
.yiv6153207137underline {text-decoration:underline;}#yiv6153207137 
.yiv6153207137attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv6153207137 .yiv6153207137attach div a 
{text-decoration:none;}#yiv6153207137 .yiv6153207137attach img 
{border:none;padding-right:5px;}#yiv6153207137 .yiv6153207137attach label 
{display:block;margin-bottom:5px;}#yiv6153207137 .yiv6153207137attach label a 
{text-decoration:none;}#yiv6153207137 blockquote {margin:0 0 0 
4px;}#yiv6153207137 .yiv6153207137bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv6153207137 
.yiv6153207137bold a {text-decoration:none;}#yiv6153207137 dd.yiv6153207137last 
p a {font-family:Verdana;font-weight:700;}#yiv6153207137 dd.yiv6153207137last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv6153207137 
dd.yiv6153207137last p span.yiv6153207137yshortcuts 
{margin-right:0;}#yiv6153207137 div.yiv6153207137attach-table div div a 
{text-decoration:none;}#yiv6153207137 div.yiv6153207137attach-table 
{width:400px;}#yiv6153207137 div.yiv6153207137file-title a, #yiv6153207137 
div.yiv6153207137file-title a:active, #yiv6153207137 
div.yiv6153207137file-title a:hover, #yiv6153207137 div.yiv6153207137file-title 
a:visited {text-decoration:none;}#yiv6153207137 div.yiv6153207137photo-title a, 
#yiv6153207137 div.yiv6153207137photo-title a:active, #yiv6153207137 
div.yiv6153207137photo-title a:hover, #yiv6153207137 
div.yiv6153207137photo-title a:visited {text-decoration:none;}#yiv6153207137 
div#yiv6153207137ygrp-mlmsg #yiv6153207137ygrp-msg p a 
span.yiv6153207137yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv6153207137 
.yiv6153207137green {color:#628c2a;}#yiv6153207137 .yiv6153207137MsoNormal 
{margin:0 0 0 0;}#yiv6153207137 o {font-size:0;}#yiv6153207137 
#yiv6153207137photos div {float:left;width:72px;}#yiv6153207137 
#yiv6153207137photos div div {border:1px solid 
#66;height:62px;overflow:hidden;width:62px;}#yiv6153207137 
#yiv6153207137photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv6153207137
 #yiv6153207137reco-category {font-size:77%;}#yiv6153207137 
#yiv6153207137reco-desc {font-size:77%;}#yiv6153207137 .yiv6153207137replbq 
{margin:4px;}#yiv6153207137 #yiv6153207137ygrp-actbar div a:first-child 
{margin-right:2px;padding-right:5px;}#yiv6153207137 #yiv6153207137ygrp-mlmsg 
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv6153207137 
#yiv6153207137ygrp-mlmsg table 

Re: [oracle_br] Re: Erro ao instalar GRID

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Corrigindo:
Eu utilizei 2 interfaces de rede interna e uma BRIDGE como segue no artigo.
 

Em Terça-feira, 17 de Janeiro de 2017 13:15, Rafael Mendonca 
 escreveu:
 

 Obrigado pelas informações Chiappa.
Eu estou o seguindo o tutorial do lab128.com abaixo:
Oracle RAC 12c Database on Linux Using VirtualBox
  
|  
|   |  
Oracle RAC 12c Database on Linux Using VirtualBox
 Oracle Database 12c RAC On Linux 6.4 Using VirtualBox  |  |

  |

 

Eu segui passo a passo, arrisca **TODAS** as configurações utilizando o ASMlib. 
Eu utilizei 2 interfaces de rede HOST ONLY e uma BRIDGE como segue no artigo.
Veja se com essas informações voce pode ajudar a resolver o meu problema, pois 
nao tenho experiencia com RAC eh a minha primeira instalacao.



Em Terça-feira, 17 de Janeiro de 2017 12:48, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     H, agora sim estamos chegando a algum lugar A info faltante então 
é : ** qual ** software de Virtualização vc está usando E qual Tutorial vc está 
seguindo  Em ** qual ** hardware real ??? 
 
https://oracle-base.com/articles/12c/oracle-db-12cr1-rac-installation-on-oracle-linux-6-using-virtualbox
 por exemplo é um Excelente para criação do RAC 12c no Virtualbox em um PC 
pessoal (notebook ou desktop) rodando Windows no host e com Linux 6 nos guests 
(que me parece ser o que vc está tentando criar pelo que vc diz) 
  
  Quanto ao erro, se for Virtualbox a solução de VM meu feeling é que OU vc 
tenha errado nas configs de rede (por exemplo, pulando o ** crítico ** passo 
de, ANTES DE CRIAR AS VMs, indicar o range de IPs para a rede  HOST-ONLY 
*** que vc vai usar nas VMs), OU que vc tá tendo algum conflito de IPs (ie, vc 
já tem algum device de mesmo IP conflitando com as VMs) 
  
  RECHEQUE direitinho os procedimentos ** todos ** da instalação E confirme com 
teu sysadmin de rede se não há conflitos
  
  []s
  
    Chiappa  #yiv0423042600 -- #yiv0423042600ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0423042600 
#yiv0423042600ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0423042600 
#yiv0423042600ygrp-mkp #yiv0423042600hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv0423042600 #yiv0423042600ygrp-mkp #yiv0423042600ads 
{margin-bottom:10px;}#yiv0423042600 #yiv0423042600ygrp-mkp .yiv0423042600ad 
{padding:0 0;}#yiv0423042600 #yiv0423042600ygrp-mkp .yiv0423042600ad p 
{margin:0;}#yiv0423042600 #yiv0423042600ygrp-mkp .yiv0423042600ad a 
{color:#ff;text-decoration:none;}#yiv0423042600 #yiv0423042600ygrp-sponsor 
#yiv0423042600ygrp-lc {font-family:Arial;}#yiv0423042600 
#yiv0423042600ygrp-sponsor #yiv0423042600ygrp-lc #yiv0423042600hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0423042600 
#yiv0423042600ygrp-sponsor #yiv0423042600ygrp-lc .yiv0423042600ad 
{margin-bottom:10px;padding:0 0;}#yiv0423042600 #yiv0423042600actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0423042600 
#yiv0423042600activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0423042600
 #yiv0423042600activity span {font-weight:700;}#yiv0423042600 
#yiv0423042600activity span:first-child 
{text-transform:uppercase;}#yiv0423042600 #yiv0423042600activity span a 
{color:#5085b6;text-decoration:none;}#yiv0423042600 #yiv0423042600activity span 
span {color:#ff7900;}#yiv0423042600 #yiv0423042600activity span 
.yiv0423042600underline {text-decoration:underline;}#yiv0423042600 
.yiv0423042600attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv0423042600 .yiv0423042600attach div a 
{text-decoration:none;}#yiv0423042600 .yiv0423042600attach img 
{border:none;padding-right:5px;}#yiv0423042600 .yiv0423042600attach label 
{display:block;margin-bottom:5px;}#yiv0423042600 .yiv0423042600attach label a 
{text-decoration:none;}#yiv0423042600 blockquote {margin:0 0 0 
4px;}#yiv0423042600 .yiv0423042600bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv0423042600 
.yiv0423042600bold a {text-decoration:none;}#yiv0423042600 dd.yiv0423042600last 
p a {font-family:Verdana;font-weight:700;}#yiv0423042600 dd.yiv0423042600last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0423042600 
dd.yiv0423042600last p span.yiv0423042600yshortcuts 
{margin-right:0;}#yiv0423042600 div.yiv0423042600attach-table div div a 
{text-decoration:none;}#yiv0423042600 div.yiv0423042600attach-table 
{width:400px;}#yiv0423042600 div.yiv0423042600file-title a, #yiv0423042600 
div.yiv0423042600file-title a:active, #yiv0423042600 
div.yiv0423042600file-title a:hover, #yiv0423042600 div.yiv0423042600file-title 
a:visited {text-decoration:none;}#yiv0423042600 div.yiv0423042600photo-title a, 
#yiv0423042600 div.yiv0423042600photo-title a:active, #yiv0423042600 
div.yiv0423042600photo-title a:hover, #yiv0423042600 

Re: [oracle_br] Re: Erro ao instalar GRID

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado pelas informações Chiappa.
Eu estou o seguindo o tutorial do lab128.com abaixo:
Oracle RAC 12c Database on Linux Using VirtualBox
  
|  
|   |  
Oracle RAC 12c Database on Linux Using VirtualBox
 Oracle Database 12c RAC On Linux 6.4 Using VirtualBox  |  |

  |

 

Eu segui passo a passo, arrisca **TODAS** as configurações utilizando o ASMlib. 
Eu utilizei 2 interfaces de rede HOST ONLY e uma BRIDGE como segue no artigo.
Veja se com essas informações voce pode ajudar a resolver o meu problema, pois 
nao tenho experiencia com RAC eh a minha primeira instalacao.



Em Terça-feira, 17 de Janeiro de 2017 12:48, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     H, agora sim estamos chegando a algum lugar A info faltante então 
é : ** qual ** software de Virtualização vc está usando E qual Tutorial vc está 
seguindo  Em ** qual ** hardware real ??? 
 
https://oracle-base.com/articles/12c/oracle-db-12cr1-rac-installation-on-oracle-linux-6-using-virtualbox
 por exemplo é um Excelente para criação do RAC 12c no Virtualbox em um PC 
pessoal (notebook ou desktop) rodando Windows no host e com Linux 6 nos guests 
(que me parece ser o que vc está tentando criar pelo que vc diz) 
  
  Quanto ao erro, se for Virtualbox a solução de VM meu feeling é que OU vc 
tenha errado nas configs de rede (por exemplo, pulando o ** crítico ** passo 
de, ANTES DE CRIAR AS VMs, indicar o range de IPs para a rede  HOST-ONLY 
*** que vc vai usar nas VMs), OU que vc tá tendo algum conflito de IPs (ie, vc 
já tem algum device de mesmo IP conflitando com as VMs) 
  
  RECHEQUE direitinho os procedimentos ** todos ** da instalação E confirme com 
teu sysadmin de rede se não há conflitos
  
  []s
  
    Chiappa  #yiv5727416837 #yiv5727416837 -- #yiv5727416837ygrp-mkp 
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 
10px;}#yiv5727416837 #yiv5727416837ygrp-mkp hr {border:1px solid 
#d8d8d8;}#yiv5727416837 #yiv5727416837ygrp-mkp #yiv5727416837hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5727416837 #yiv5727416837ygrp-mkp #yiv5727416837ads 
{margin-bottom:10px;}#yiv5727416837 #yiv5727416837ygrp-mkp .yiv5727416837ad 
{padding:0 0;}#yiv5727416837 #yiv5727416837ygrp-mkp .yiv5727416837ad p 
{margin:0;}#yiv5727416837 #yiv5727416837ygrp-mkp .yiv5727416837ad a 
{color:#ff;text-decoration:none;}#yiv5727416837 #yiv5727416837ygrp-sponsor 
#yiv5727416837ygrp-lc {font-family:Arial;}#yiv5727416837 
#yiv5727416837ygrp-sponsor #yiv5727416837ygrp-lc #yiv5727416837hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5727416837 
#yiv5727416837ygrp-sponsor #yiv5727416837ygrp-lc .yiv5727416837ad 
{margin-bottom:10px;padding:0 0;}#yiv5727416837 #yiv5727416837actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5727416837 
#yiv5727416837activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5727416837
 #yiv5727416837activity span {font-weight:700;}#yiv5727416837 
#yiv5727416837activity span:first-child 
{text-transform:uppercase;}#yiv5727416837 #yiv5727416837activity span a 
{color:#5085b6;text-decoration:none;}#yiv5727416837 #yiv5727416837activity span 
span {color:#ff7900;}#yiv5727416837 #yiv5727416837activity span 
.yiv5727416837underline {text-decoration:underline;}#yiv5727416837 
.yiv5727416837attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv5727416837 .yiv5727416837attach div a 
{text-decoration:none;}#yiv5727416837 .yiv5727416837attach img 
{border:none;padding-right:5px;}#yiv5727416837 .yiv5727416837attach label 
{display:block;margin-bottom:5px;}#yiv5727416837 .yiv5727416837attach label a 
{text-decoration:none;}#yiv5727416837 blockquote {margin:0 0 0 
4px;}#yiv5727416837 .yiv5727416837bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5727416837 
.yiv5727416837bold a {text-decoration:none;}#yiv5727416837 dd.yiv5727416837last 
p a {font-family:Verdana;font-weight:700;}#yiv5727416837 dd.yiv5727416837last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5727416837 
dd.yiv5727416837last p span.yiv5727416837yshortcuts 
{margin-right:0;}#yiv5727416837 div.yiv5727416837attach-table div div a 
{text-decoration:none;}#yiv5727416837 div.yiv5727416837attach-table 
{width:400px;}#yiv5727416837 div.yiv5727416837file-title a, #yiv5727416837 
div.yiv5727416837file-title a:active, #yiv5727416837 
div.yiv5727416837file-title a:hover, #yiv5727416837 div.yiv5727416837file-title 
a:visited {text-decoration:none;}#yiv5727416837 div.yiv5727416837photo-title a, 
#yiv5727416837 div.yiv5727416837photo-title a:active, #yiv5727416837 
div.yiv5727416837photo-title a:hover, #yiv5727416837 
div.yiv5727416837photo-title a:visited {text-decoration:none;}#yiv5727416837 
div#yiv5727416837ygrp-mlmsg #yiv5727416837ygrp-msg p a 
span.yiv5727416837yshortcuts 

Re: [oracle_br] Re: Erro ao instalar GRID

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

obs: Após o clone os ips foram trocados confome descrito no etc-hosts e o 
hostname foi modificado tb o etc-sysconfig-network e o endereco MAC tb. As 
maquinas se comunicam entre si tanto na rede publica, como na rede priv. 

Em Terça-feira, 17 de Janeiro de 2017 10:43, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Obrigado pelo retorno Chiappa, desculpe-me pela falta de informação.
Segue:
/u01/app/oracle/crsdata/rac1/crsconfig/cluutil3.log

[main] [ 2017-01-17 10:03:18.703 BRT ] [ClusterUtil.main:213]  Trace 
enabled[main] [ 2017-01-17 10:03:18.711 BRT ] [SRVMContext.init:114]  
Performing SRVM Context init. Init Counter=1[main] [ 2017-01-17 10:03:18.751 
BRT ] [Library.load:194]  library.load[main] [ 2017-01-17 10:03:18.752 BRT ] 
[sPlatform.isHybrid:66]  osName=Linux osArch=amd64 JVM=64 rc=false[main] [ 
2017-01-17 10:03:18.784 BRT ] [SRVMContext.init:131]  SRVM Context 
init-ed[main] [ 2017-01-17 10:03:18.795 BRT ] [Utils.getLocalHost:430]  
Hostname retrieved: rac1.localdomain, returned: rac1[main] [ 2017-01-17 
10:03:18.795 BRT ] [ClusterwareCkpt.parseArgs:250]  args = 
-ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_STACK,-pname,VERSION[main]
 [ 2017-01-17 10:03:18.795 BRT ] [ClusterwareCkpt.executeCkpt:1023]  Parsed 
Arguments[main] [ 2017-01-17 10:03:18.796 BRT ] 
[ClusterwareCkpt.executeCkpt:1049]  Processing chkckpt command line 
arguments[main] [ 2017-01-17 10:03:18.796 BRT ] [ClusterwareCkpt.parseArgs:250] 
 args = 
-ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_STACK,-pname,VERSION[main]
 [ 2017-01-17 10:03:18.798 BRT ] [ClusterwareCkpt.isPropertyExists:346]  
Checking checkpoint property:VERSION exists for checkpoint: ROOTCRS_STACK[main] 
[ 2017-01-17 10:03:18.985 BRT ] [ClusterwareCkpt.getCkptFileLoc:240]  ckpt file 
location is /u01/app/oracle/crsdata/rac1/crsconfig/ckptGridHA_rac1.xml[main] [ 
2017-01-17 10:03:18.986 BRT ] [ClusterwareCkpt.isPropertyExists:381]  
Checkpoint property: VERSION found[main] [ 2017-01-17 10:03:18.988 BRT ] 
[ClusterUtil.main:236]  ClusterUtil.execute rc: 0[main] [ 2017-01-17 
10:03:29.388 BRT ] [ClusterUtil.main:213]  Trace enabled[main] [ 2017-01-17 
10:03:29.394 BRT ] [SRVMContext.init:114]  Performing SRVM Context init. Init 
Counter=1[main] [ 2017-01-17 10:03:29.425 BRT ] [Library.load:194]  
library.load[main] [ 2017-01-17 10:03:29.426 BRT ] [sPlatform.isHybrid:66]  
osName=Linux osArch=amd64 JVM=64 rc=false[main] [ 2017-01-17 10:03:29.455 BRT ] 
[SRVMContext.init:131]  SRVM Context init-ed[main] [ 2017-01-17 10:03:29.472 
BRT ] [Utils.getLocalHost:430]  Hostname retrieved: rac1.localdomain, returned: 
rac1[main] [ 2017-01-17 10:03:29.472 BRT ] [ClusterwareCkpt.parseArgs:250]  
args = 
-ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_OLR,-status[main] [ 
2017-01-17 10:03:29.473 BRT ] [ClusterwareCkpt.executeCkpt:1023]  Parsed 
Arguments[main] [ 2017-01-17 10:03:29.473 BRT ] 
[ClusterwareCkpt.executeCkpt:1049]  Processing chkckpt command line 
arguments[main] [ 2017-01-17 10:03:29.474 BRT ] [ClusterwareCkpt.parseArgs:250] 
 args = 
-ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_OLR,-status[main] [ 
2017-01-17 10:03:29.475 BRT ] [ClusterwareCkpt.getCkptStatus:299]  Checking to 
see if checkpoint:ROOTCRS_OLRhas successfuly completed[main] [ 2017-01-17 
10:03:29.632 BRT ] [ClusterwareCkpt.getCkptFileLoc:240]  ckpt file location is 
/u01/app/oracle/crsdata/rac1/crsconfig/ckptGridHA_rac1.xml[main] [ 2017-01-17 
10:03:29.632 BRT ] [ClusterwareCkpt.getCkptStatus:323]  Reading data for 
checkpoint: ROOTCRS_OLR[main] [ 2017-01-17 10:03:29.635 BRT ] 
[ClusterUtil.main:236]  ClusterUtil.execute rc: 0[main] [ 2017-01-17 
10:03:35.798 BRT ] [ClusterUtil.main:213]  Trace enabled[main] [ 2017-01-17 
10:03:35.803 BRT ] [SRVMContext.init:114]  Performing SRVM Context init. Init 
Counter=1[main] [ 2017-01-17 10:03:35.832 BRT ] [Library.load:194]  
library.load[main] [ 2017-01-17 10:03:35.833 BRT ] [sPlatform.isHybrid:66]  
osName=Linux osArch=amd64 JVM=64 rc=false[main] [ 2017-01-17 10:03:35.858 BRT ] 
[SRVMContext.init:131]  SRVM Context init-ed[main] [ 2017-01-17 10:03:35.864 
BRT ] [Utils.getLocalHost:430]  Hostname retrieved: rac1.localdomain, returned: 
rac1[main] [ 2017-01-17 10:03:35.864 BRT ] [ClusterwareCkpt.parseArgs:250]  
args = -ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_ACFSINST[main] 
[ 2017-01-17 10:03:35.865 BRT ] [ClusterwareCkpt.executeCkpt:1023]  Parsed 
Arguments[main] [ 2017-01-17 10:03:35.865 BRT ] 
[ClusterwareCkpt.executeCkpt:1049]  Processing chkckpt command line 
arguments[main] [ 2017-01-17 10:03:35.865 BRT ] [ClusterwareCkpt.parseArgs:250] 
 args = -ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_ACFSINST[main] 
[ 2017-01-17 10:03:35.866 BRT ] [ClusterwareCkpt.isCkptExists:279]  Checking if 
checkpoint:ROOTCRS_ACFSINST exists[main] [ 2017-01-17 10:03:36.029 BRT ] 
[ClusterwareCkpt.getCkptFileLoc:240]  ck

Re: [oracle_br] Re: Erro ao instalar GRID

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado pelo retorno Chiappa, desculpe-me pela falta de informação.
Segue:
/u01/app/oracle/crsdata/rac1/crsconfig/cluutil3.log

[main] [ 2017-01-17 10:03:18.703 BRT ] [ClusterUtil.main:213]  Trace 
enabled[main] [ 2017-01-17 10:03:18.711 BRT ] [SRVMContext.init:114]  
Performing SRVM Context init. Init Counter=1[main] [ 2017-01-17 10:03:18.751 
BRT ] [Library.load:194]  library.load[main] [ 2017-01-17 10:03:18.752 BRT ] 
[sPlatform.isHybrid:66]  osName=Linux osArch=amd64 JVM=64 rc=false[main] [ 
2017-01-17 10:03:18.784 BRT ] [SRVMContext.init:131]  SRVM Context 
init-ed[main] [ 2017-01-17 10:03:18.795 BRT ] [Utils.getLocalHost:430]  
Hostname retrieved: rac1.localdomain, returned: rac1[main] [ 2017-01-17 
10:03:18.795 BRT ] [ClusterwareCkpt.parseArgs:250]  args = 
-ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_STACK,-pname,VERSION[main]
 [ 2017-01-17 10:03:18.795 BRT ] [ClusterwareCkpt.executeCkpt:1023]  Parsed 
Arguments[main] [ 2017-01-17 10:03:18.796 BRT ] 
[ClusterwareCkpt.executeCkpt:1049]  Processing chkckpt command line 
arguments[main] [ 2017-01-17 10:03:18.796 BRT ] [ClusterwareCkpt.parseArgs:250] 
 args = 
-ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_STACK,-pname,VERSION[main]
 [ 2017-01-17 10:03:18.798 BRT ] [ClusterwareCkpt.isPropertyExists:346]  
Checking checkpoint property:VERSION exists for checkpoint: ROOTCRS_STACK[main] 
[ 2017-01-17 10:03:18.985 BRT ] [ClusterwareCkpt.getCkptFileLoc:240]  ckpt file 
location is /u01/app/oracle/crsdata/rac1/crsconfig/ckptGridHA_rac1.xml[main] [ 
2017-01-17 10:03:18.986 BRT ] [ClusterwareCkpt.isPropertyExists:381]  
Checkpoint property: VERSION found[main] [ 2017-01-17 10:03:18.988 BRT ] 
[ClusterUtil.main:236]  ClusterUtil.execute rc: 0[main] [ 2017-01-17 
10:03:29.388 BRT ] [ClusterUtil.main:213]  Trace enabled[main] [ 2017-01-17 
10:03:29.394 BRT ] [SRVMContext.init:114]  Performing SRVM Context init. Init 
Counter=1[main] [ 2017-01-17 10:03:29.425 BRT ] [Library.load:194]  
library.load[main] [ 2017-01-17 10:03:29.426 BRT ] [sPlatform.isHybrid:66]  
osName=Linux osArch=amd64 JVM=64 rc=false[main] [ 2017-01-17 10:03:29.455 BRT ] 
[SRVMContext.init:131]  SRVM Context init-ed[main] [ 2017-01-17 10:03:29.472 
BRT ] [Utils.getLocalHost:430]  Hostname retrieved: rac1.localdomain, returned: 
rac1[main] [ 2017-01-17 10:03:29.472 BRT ] [ClusterwareCkpt.parseArgs:250]  
args = 
-ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_OLR,-status[main] [ 
2017-01-17 10:03:29.473 BRT ] [ClusterwareCkpt.executeCkpt:1023]  Parsed 
Arguments[main] [ 2017-01-17 10:03:29.473 BRT ] 
[ClusterwareCkpt.executeCkpt:1049]  Processing chkckpt command line 
arguments[main] [ 2017-01-17 10:03:29.474 BRT ] [ClusterwareCkpt.parseArgs:250] 
 args = 
-ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_OLR,-status[main] [ 
2017-01-17 10:03:29.475 BRT ] [ClusterwareCkpt.getCkptStatus:299]  Checking to 
see if checkpoint:ROOTCRS_OLRhas successfuly completed[main] [ 2017-01-17 
10:03:29.632 BRT ] [ClusterwareCkpt.getCkptFileLoc:240]  ckpt file location is 
/u01/app/oracle/crsdata/rac1/crsconfig/ckptGridHA_rac1.xml[main] [ 2017-01-17 
10:03:29.632 BRT ] [ClusterwareCkpt.getCkptStatus:323]  Reading data for 
checkpoint: ROOTCRS_OLR[main] [ 2017-01-17 10:03:29.635 BRT ] 
[ClusterUtil.main:236]  ClusterUtil.execute rc: 0[main] [ 2017-01-17 
10:03:35.798 BRT ] [ClusterUtil.main:213]  Trace enabled[main] [ 2017-01-17 
10:03:35.803 BRT ] [SRVMContext.init:114]  Performing SRVM Context init. Init 
Counter=1[main] [ 2017-01-17 10:03:35.832 BRT ] [Library.load:194]  
library.load[main] [ 2017-01-17 10:03:35.833 BRT ] [sPlatform.isHybrid:66]  
osName=Linux osArch=amd64 JVM=64 rc=false[main] [ 2017-01-17 10:03:35.858 BRT ] 
[SRVMContext.init:131]  SRVM Context init-ed[main] [ 2017-01-17 10:03:35.864 
BRT ] [Utils.getLocalHost:430]  Hostname retrieved: rac1.localdomain, returned: 
rac1[main] [ 2017-01-17 10:03:35.864 BRT ] [ClusterwareCkpt.parseArgs:250]  
args = -ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_ACFSINST[main] 
[ 2017-01-17 10:03:35.865 BRT ] [ClusterwareCkpt.executeCkpt:1023]  Parsed 
Arguments[main] [ 2017-01-17 10:03:35.865 BRT ] 
[ClusterwareCkpt.executeCkpt:1049]  Processing chkckpt command line 
arguments[main] [ 2017-01-17 10:03:35.865 BRT ] [ClusterwareCkpt.parseArgs:250] 
 args = -ckpt,-oraclebase,/u01/app/oracle,-chkckpt,-name,ROOTCRS_ACFSINST[main] 
[ 2017-01-17 10:03:35.866 BRT ] [ClusterwareCkpt.isCkptExists:279]  Checking if 
checkpoint:ROOTCRS_ACFSINST exists[main] [ 2017-01-17 10:03:36.029 BRT ] 
[ClusterwareCkpt.getCkptFileLoc:240]  ckpt file location is 
/u01/app/oracle/crsdata/rac1/crsconfig/ckptGridHA_rac1.xml[main] [ 2017-01-17 
10:03:36.031 BRT ] [ClusterwareCkpt.isCkptExists:292]  ckpt = 
oracle.sysman.oic.oics.OicsCheckPoint@48ff2413[main] [ 2017-01-17 10:03:36.032 
BRT ] [ClusterUtil.main:236]  ClusterUtil.execute rc: 0[main] [ 2017-01-17 
10:16:46.721 BRT ] [ClusterUtil.main:213]  Trace enabled[main] [ 2017-01-17 

[oracle_br] Erro ao instalar GRID

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Senhores, bom dia.
Cenário:
=> Oracle Linux v6.5=> GI v12.1.0.1
O grid ao chegar aos seus 85% e após pedir para executar os scripts com usuário 
root, segue o erro que surge:
[INS-32123] Exeution of 'GI Install' script failed on nodes: rac1
 VIsualizando o log 
/u01/app/oraInventory/logs/installActions2017-01-16_11-00-02PM.log
2017/01/16 23:54:53 CLSRSC-1003: Failed to start resource OC4J^M2017/01/16 
23:54:54 CLSRSC-287: FirstNode configuration failed^MDied at 
/u01/app/12.1.0/grid_1/crs/install/crsinstall.pm line 2398.^MThe command 
'/u01/app/12.1.0/grid_1/perl/bin/perl -I/u01/app/12.1.0/grid_1/perl/lib 
-I/u01/app/12.1.0/grid_1/crs/install 
/u01/app/12.1.0/grid_1/crs/install/rootcrs.pl  -auto -lang=en_US.UTF-8' 
execution failed^M

Visualizando o log: 
/u01/app/12.1.0/grid_1/cfgtoollogs/crsconfig/rootcrs_rac1_2017-01-16_11-36-06PM.log
2017-01-16 23:54:56: Succeeded in writing the checkpoint:'ROOTCRS_NODECONFIG' 
with status:FAIL2017-01-16 23:54:56: Install node: rac12017-01-16 23:54:56: 
Current first node: rac12017-01-16 23:54:56: Invoking 
"/u01/app/12.1.0/grid_1/bin/cluutil -ckpt -oraclebase /u01/app/oracle 
-writeckpt -name ROOTCRS_STACK -state FAIL"2017-01-16 23:54:56: trace 
file=/u01/app/oracle/crsdata/rac1/crsconfig/cluutil2.log2017-01-16 23:54:56: 
Running as user oracle: /u01/app/12.1.0/grid_1/bin/cluutil -ckpt -oraclebase 
/u01/app/oracle -writeckpt -name ROOTCRS_STACK -state FAIL2017-01-16 23:54:56: 
s_run_as_user2: Running /bin/su oracle -c ' echo CLSRSC_START; 
/u01/app/12.1.0/grid_1/bin/cluutil -ckpt -oraclebase /u01/app/oracle -writeckpt 
-name ROOTCRS_STACK -state FAIL '

2017-01-16 23:54:57: Succeeded in writing the checkpoint:'ROOTCRS_STACK' with 
status:FAIL2017-01-16 23:54:57: Install node: rac12017-01-16 23:54:57: Current 
first node: rac12017-01-16 23:54:57: Invoking 
"/u01/app/12.1.0/grid_1/bin/cluutil -exec -ocrsetval -key 
SYSTEM.rootcrs.checkpoints.firstnode -value FAIL"2017-01-16 23:54:57: trace 
file=/u01/app/oracle/crsdata/rac1/crsconfig/cluutil3.log2017-01-16 23:54:57: 
Executing cmd: /u01/app/12.1.0/grid_1/bin/cluutil -exec -ocrsetval -key 
SYSTEM.rootcrs.checkpoints.firstnode -value FAIL2017-01-16 23:54:57: Succeeded 
in writing the key pair (SYSTEM.rootcrs.checkpoints.firstnode:FAIL) to 
OCR"/u01/app/12.1.0/grid_1/cfgtoollogs/crsconfig/rootcrs_rac1_2017-01-16_11-36-06PM.log"
 2138L, 176301C  

Obs: Estou sem acesso ao metalink, entao se alguem puder ajudar sem passar 
referencias do metalink eu agradeço.

Re: [oracle_br] Oracle Client 11g 64 Win

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } Clica com o botão direito e executa como administrador. Mas pra 
que vc vai instalar novamente outro client na mesma máquina ?


Enviado do Yahoo Mail para iPhone


Em segunda-feira, janeiro 16, 2017, 2:13 PM, 'Ednilson Silva' 
ednilson.si...@jbs.com.br [oracle_br]  escreveu:

    


Pessoal,

Estou precisando instalar o Oracle Client 11g Win 64 bits numa maquina que já 
tem o 32 bits instalado.

Ao executar o arquivo setup.exe ele abre uma tela do prompt e fecha, alguém já 
passou por isso e sabe como resolver?

  

Grato

Ednilson
  -- #ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 
0;padding:0 10px;}#ygrp-mkp hr {border:1px solid #d8d8d8;}#ygrp-mkp #hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#ygrp-mkp #ads {margin-bottom:10px;}#ygrp-mkp .ad {padding:0 0;}#ygrp-mkp 
.ad p {margin:0;}#ygrp-mkp .ad a 
{color:#ff;text-decoration:none;}#ygrp-sponsor #ygrp-lc 
{font-family:Arial;}#ygrp-sponsor #ygrp-lc #hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#ygrp-sponsor #ygrp-lc .ad 
{margin-bottom:10px;padding:0 0;}#actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#activity
 span {font-weight:700;}#activity span:first-child 
{text-transform:uppercase;}#activity span a 
{color:#5085b6;text-decoration:none;}#activity span span 
{color:#ff7900;}#activity span .underline {text-decoration:underline;}.attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}.attach div a {text-decoration:none;}.attach img 
{border:none;padding-right:5px;}.attach label 
{display:block;margin-bottom:5px;}.attach label a 
{text-decoration:none;}blockquote {margin:0 0 0 4px;}.bold 
{font-family:Arial;font-size:13px;font-weight:700;}.bold a 
{text-decoration:none;}dd.last p a 
{font-family:Verdana;font-weight:700;}dd.last p span 
{margin-right:10px;font-family:Verdana;font-weight:700;}dd.last p 
span.yshortcuts {margin-right:0;}div.attach-table div div a 
{text-decoration:none;}div.attach-table {width:400px;}div.file-title a, 
div.file-title a:active, div.file-title a:hover, div.file-title a:visited 
{text-decoration:none;}div.photo-title a, div.photo-title a:active, 
div.photo-title a:hover, div.photo-title a:visited 
{text-decoration:none;}div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}.green 
{color:#628c2a;}.MsoNormal {margin:0 0 0 0;}o {font-size:0;}#photos div 
{float:left;width:72px;}#photos div div {border:1px solid 
#66;height:62px;overflow:hidden;width:62px;}#photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#reco-category
 {font-size:77%;}#reco-desc {font-size:77%;}.replbq {margin:4px;}#ygrp-actbar 
div a:first-child {margin-right:2px;padding-right:5px;}#ygrp-mlmsg 
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#ygrp-mlmsg 
table {font-size:inherit;font:100%;}#ygrp-mlmsg select, input, textarea 
{font:99% Arial, Helvetica, clean, sans-serif;}#ygrp-mlmsg pre, code {font:115% 
monospace;}#ygrp-mlmsg * {line-height:1.22em;}#ygrp-mlmsg #logo 
{padding-bottom:10px;}#ygrp-msg p a {font-family:Verdana;}#ygrp-msg 
p#attach-count span {color:#1E66AE;font-weight:700;}#ygrp-reco #reco-head 
{color:#ff7900;font-weight:700;}#ygrp-reco 
{margin-bottom:20px;padding:0px;}#ygrp-sponsor #ov li a 
{font-size:130%;text-decoration:none;}#ygrp-sponsor #ov li 
{font-size:77%;list-style-type:square;padding:6px 0;}#ygrp-sponsor #ov ul 
{margin:0;padding:0 0 0 8px;}#ygrp-text {font-family:Georgia;}#ygrp-text p 
{margin:0 0 1em 0;}#ygrp-text tt {font-size:120%;}#ygrp-vital ul li:last-child 
{border-right:none !important;}

Re: [oracle_br] Dataguard configuração se perde

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Aqui tem um outro artigo muito interessante do Uhesse
The Data Guard Broker: Why it is recommended

  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
The Data Guard Broker: Why it is recommended
 When it comes to Data Guard on a recent version, I will always use the Data 
Guard Broker. Not the Enterprise Man...  |   |

  |

  |

 


VOce nao precisa configurar o parameter LOG_ARCHIVE_DEST_*=SERVICE, o Broker eh 
inteligente o suficiente para realizar qualquer tipo de modificacao, 
SWITCHOVER, FAILOVER sem vc setar esses parametros.


 

Em Quarta-feira, 4 de Janeiro de 2017 0:40, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Carlos, tudo joia?
Entao, recentemente implementei 3 DG em 3 clientes diferentes com 12c e passei 
pelo mesmo problema.
A oracle deixou a desejar em alguns aspectos na minha opniao nessa nova versao, 
por exemplo, o tal do erro:
ORA-16698: O Broker nao deixa mais voce adicionar o primary ou o standby na 
configuracao se vc tiver com algum LOG_ARCHIVE_DEST_* =SERVICE setado, voce 
deve limpar o parametro para poder adicionar o database na configuracao do 
broker.
Como voce pode ver na propria documentacao da Oracle
Scenarios Using the DGMGRL Command-Line Interface

  
|  
|   |  
Scenarios Using the DGMGRL Command-Line Interface
   |  |

  |

 


O que faz mudar o parametro LOG_ARCHIVE_DEST_* automaticamente eh o processo 
DMON do Broker, veja o que o mestre Uhesse membro da OAKTABLE fala a respeito 
do topico aberto por voce:
"When using the Data Guard Broker, you don’t need to set any LOG_ARCHIVE_* 
parameter for the databases that are part of your Data Guard configuration. The 
broker is doing that for you. Forget about what you may have heard about 
VALID_FOR – you don’t need that with the broker. Actually, setting any of the 
LOG_ARCHIVE_* parameters with an enabled broker configuration might even 
confuse the broker and lead to warning or error messages"
Veja o artigo completo em:

https://uhesse.com/2014/10/14/let-the-data-guard-broker-control-log_archive_-parameters/

Espero ter ajudado.






 

Em Terça-feira, 3 de Janeiro de 2017 0:49, "carloseduard...@yahoo.com 
[oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     
Senhores, boa noite. 
Segue meu problema abaixo:
Oracle 12.1.0.2 EE
Configuração 
1 primary1 logical standby1 physical standby

==> CONFIGURAÇÃO:
* Primary database
LOG_ARCHIVE_DEST_1= 'LOCATION=/u01/app/oracle/archive 
VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=XUXA1';
LOG_ARCHIVE_DEST_2= 'service=XUXA2 ASYNC 
valid_for=(online_logfile,primary_role) db_unique_name=XUXA2'

LOG_ARCHIVE_DEST_3= 'SERVICE=XUXA3 ASYNC 
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=XUXA3'    
LOG_ARCHIVE_DEST_4= 'LOCATION=/u01/app/oracle/archive2 
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=XUXA1';

* Fisico standby database
LOG_ARCHIVE_DEST_1=LOCATION=/u01/app/oracle/archive
LOG_ARCHIVES_DEST_2=service=XUXA1 ASYNC valid_for=(online_logfile,primary_role) 
db_unique_name=XUXA1
* Logico standby database
LOG_ARCHIVE_DEST_1=LOCATION=/u01/app/oracle/archive 
VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=XUXA3
LOG_ARCHIVE_DEST_2=service=XUXA1 LGWR ASYNC 
valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=XUXA1
log_archive_dest_3=LOCATION=/u01/app/oracle/archive2 
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)  DB_UNIQUE_NAME=XUXA3

==> CONFIGURACAO IGUAL PARA TODOS OS DATABASES
LOG_ARCHIVE_CONFIG=DG_CONFIG=(XUXA1,XUXA2,XUXA3)


O problema eh que esses parâmetros estão sendo modificados automaticamente pelo 
Oracle, em poucos minutos o parâmetro que estava setado com a configuração 
acima, passa a estar sempre com os valores abaixo:
* primary database

log_archive_dest_1=location=/u01/app/oracle/archive 
valid_for=(ALL_LOGFILES,ALL_ROLES)
log_archive_dest_2=service=XUXA2 ASYNC NOAFFIRM delay=0 optional 
compression=disable max_failure=0 max_connections=1 reopen=300 
db_unique_name=XUXA2 net_timeout=30 valid_for=(online_logfile,all_roles)
log_archive_dest_3=service=XUXA3 ASYNC NOAFFIRM delay=0 optional 
compression=disable max_failure=0 max_connections=1 reopen=300 
db_unique_name=XUXA3 net_timeout=30 valid_for=(online_logfile,all_roles)
log_archive_dest_4=LOCATION=/u01/app/oracle/archive2 
valid_for(standby_logfile,standby_role) db_unique_name=XUXA1

Depois que vejo que a configuração foi modificada, o que faço eh alterar 
novamente para a configuração incial, mas de nada adianta. Novamente o Oracle 
muda essesparametros novamente, isso acontece em todos os databases envolvidos.
obs: Só eu tenho acesso a maquina e aos databases.

Alguém sabe dizer o motivo pelo qual o Oracle está fazendo isso? E como faço 
para resolver o problema em questão?







  

 #yiv2495596812 #yiv2495596812 -- #yiv2495596812ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2495596812 
#yiv2495596812ygrp-

Re: [oracle_br] Dataguard configuração se perde

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Carlos, tudo joia?
Entao, recentemente implementei 3 DG em 3 clientes diferentes com 12c e passei 
pelo mesmo problema.
A oracle deixou a desejar em alguns aspectos na minha opniao nessa nova versao, 
por exemplo, o tal do erro:
ORA-16698: O Broker nao deixa mais voce adicionar o primary ou o standby na 
configuracao se vc tiver com algum LOG_ARCHIVE_DEST_* =SERVICE setado, voce 
deve limpar o parametro para poder adicionar o database na configuracao do 
broker.
Como voce pode ver na propria documentacao da Oracle
Scenarios Using the DGMGRL Command-Line Interface

  
|  
|   |  
Scenarios Using the DGMGRL Command-Line Interface
   |  |

  |

 


O que faz mudar o parametro LOG_ARCHIVE_DEST_* automaticamente eh o processo 
DMON do Broker, veja o que o mestre Uhesse membro da OAKTABLE fala a respeito 
do topico aberto por voce:
"When using the Data Guard Broker, you don’t need to set any LOG_ARCHIVE_* 
parameter for the databases that are part of your Data Guard configuration. The 
broker is doing that for you. Forget about what you may have heard about 
VALID_FOR – you don’t need that with the broker. Actually, setting any of the 
LOG_ARCHIVE_* parameters with an enabled broker configuration might even 
confuse the broker and lead to warning or error messages"
Veja o artigo completo em:

https://uhesse.com/2014/10/14/let-the-data-guard-broker-control-log_archive_-parameters/

Espero ter ajudado.






 

Em Terça-feira, 3 de Janeiro de 2017 0:49, "carloseduard...@yahoo.com 
[oracle_br]"  escreveu:
 

     
Senhores, boa noite. 
Segue meu problema abaixo:
Oracle 12.1.0.2 EE
Configuração 
1 primary1 logical standby1 physical standby

==> CONFIGURAÇÃO:
* Primary database
LOG_ARCHIVE_DEST_1= 'LOCATION=/u01/app/oracle/archive 
VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=XUXA1';
LOG_ARCHIVE_DEST_2= 'service=XUXA2 ASYNC 
valid_for=(online_logfile,primary_role) db_unique_name=XUXA2'

LOG_ARCHIVE_DEST_3= 'SERVICE=XUXA3 ASYNC 
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=XUXA3'    
LOG_ARCHIVE_DEST_4= 'LOCATION=/u01/app/oracle/archive2 
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=XUXA1';

* Fisico standby database
LOG_ARCHIVE_DEST_1=LOCATION=/u01/app/oracle/archive
LOG_ARCHIVES_DEST_2=service=XUXA1 ASYNC valid_for=(online_logfile,primary_role) 
db_unique_name=XUXA1
* Logico standby database
LOG_ARCHIVE_DEST_1=LOCATION=/u01/app/oracle/archive 
VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=XUXA3
LOG_ARCHIVE_DEST_2=service=XUXA1 LGWR ASYNC 
valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=XUXA1
log_archive_dest_3=LOCATION=/u01/app/oracle/archive2 
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)  DB_UNIQUE_NAME=XUXA3

==> CONFIGURACAO IGUAL PARA TODOS OS DATABASES
LOG_ARCHIVE_CONFIG=DG_CONFIG=(XUXA1,XUXA2,XUXA3)


O problema eh que esses parâmetros estão sendo modificados automaticamente pelo 
Oracle, em poucos minutos o parâmetro que estava setado com a configuração 
acima, passa a estar sempre com os valores abaixo:
* primary database

log_archive_dest_1=location=/u01/app/oracle/archive 
valid_for=(ALL_LOGFILES,ALL_ROLES)
log_archive_dest_2=service=XUXA2 ASYNC NOAFFIRM delay=0 optional 
compression=disable max_failure=0 max_connections=1 reopen=300 
db_unique_name=XUXA2 net_timeout=30 valid_for=(online_logfile,all_roles)
log_archive_dest_3=service=XUXA3 ASYNC NOAFFIRM delay=0 optional 
compression=disable max_failure=0 max_connections=1 reopen=300 
db_unique_name=XUXA3 net_timeout=30 valid_for=(online_logfile,all_roles)
log_archive_dest_4=LOCATION=/u01/app/oracle/archive2 
valid_for(standby_logfile,standby_role) db_unique_name=XUXA1

Depois que vejo que a configuração foi modificada, o que faço eh alterar 
novamente para a configuração incial, mas de nada adianta. Novamente o Oracle 
muda essesparametros novamente, isso acontece em todos os databases envolvidos.
obs: Só eu tenho acesso a maquina e aos databases.

Alguém sabe dizer o motivo pelo qual o Oracle está fazendo isso? E como faço 
para resolver o problema em questão?







  #yiv8668407470 #yiv8668407470 -- #yiv8668407470ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8668407470 
#yiv8668407470ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8668407470 
#yiv8668407470ygrp-mkp #yiv8668407470hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8668407470 #yiv8668407470ygrp-mkp #yiv8668407470ads 
{margin-bottom:10px;}#yiv8668407470 #yiv8668407470ygrp-mkp .yiv8668407470ad 
{padding:0 0;}#yiv8668407470 #yiv8668407470ygrp-mkp .yiv8668407470ad p 
{margin:0;}#yiv8668407470 #yiv8668407470ygrp-mkp .yiv8668407470ad a 
{color:#ff;text-decoration:none;}#yiv8668407470 #yiv8668407470ygrp-sponsor 
#yiv8668407470ygrp-lc {font-family:Arial;}#yiv8668407470 
#yiv8668407470ygrp-sponsor #yiv8668407470ygrp-lc #yiv8668407470hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8668407470 
#yiv8668407470ygrp-sponsor 

Re: [oracle_br] Re: tamanho ideal do redo..

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } Chiappa, uma dúvida:

"por princípio NÃO HÁ COMO o tamanho grande demais de um redo log file 
interferir na performance"
Quando se tem uma infra com DG configurado com protection mode max protection 
por exemplo, um log grande demais não vai interferir na performance ?

Enviado do Yahoo Mail para iPhone


On quarta-feira, dezembro 14, 2016, 9:16 AM, jlchia...@yahoo.com.br [oracle_br] 
 wrote:

    
Blz ? Então, no tocante á otimização para que os redos atendam a um tempo 
mínimo de recuperação desejado, uma opção pode ser vc usar o ADVISOR específico 
pra isso , veja http://www.orafaq.com/node/1437 e 
http://www.databasejournal.com/features/oracle/article.php/3395731/Oracle-10gs-Redo-Logfile-Sizing-Advisor.htm
 para exemplos e refs... Notar também que há muuito tempo (desde 9i iirc) 
já temos o FAST_START_MTTR_TARGET para indicar tempo de recuperabilidade...

  Já no que se refere à performance eu tenho alguns pontos : o primeiro é que, 
ao contrário do que vc parece pensar (julgando pelo que vc escreveu no 
parágrafo em que vc fala de redo) por princípio NÃO HÁ COMO o tamanho grande 
demais de um redo log file interferir na performance, pois a gravação de redo 
no redo log file NÂO IMPLICA em acessar o arquivo todo, o arquivo é aberto em 
APPEND-MODE...
  
 Já um tamanho de redo log file muito pequeno ** SIM **, pode interferir pois 
em princípio independente de outros settings, se um redo log file enche um 
archive deverá ser criado, se esse enchimento for frequente Não só o processo 
de ARCH pode ficar sobrecarregado (já que vai ser acionado a "toda hora") mas 
também o LOG WRITER pode ter que ficar "esperando" o ARCH liberar / confirmar a 
criação de archive antes da geração de novos logs poder avançar É baseado 
mais ou menos nisso que a Oracle recomenda um intervalo de alguns minutos entre 
a geração de cada archive - é um jogo de Equilíbrio entre a segurança e a 
performance, muito embora a questão de Segurança não é tão crítica, pois mesmo 
que vc não tenha o log necessário archivado em caso de crash vc  OBVIAMENTE 
 está MULTIPLEXANDO seus log files, né não ??? 

O resumo da ópera então é : avalie a possibilidade de usar o Advisor, saiba que 
log file muito grande não deve interferir (negativamente ou positivamente) E 
que um log file muito pequeno PODE SIM interferir negativamente - sendo assim, 
eu sempre chuto como valor inicial algo em torno de 500Mb a 1 GB como log file 
size, esses 50 Mb default numa utilização em ambiente Produtivo via de regra 
são ridículos... Aí depois uso o Advisor, analiso os waits referentes a log e 
archive, analiso a diferença de tempos de criação dos archives, por aí...

[]s

  Chiappa
  -- #ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 
0;padding:0 10px;}#ygrp-mkp hr {border:1px solid #d8d8d8;}#ygrp-mkp #hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#ygrp-mkp #ads {margin-bottom:10px;}#ygrp-mkp .ad {padding:0 0;}#ygrp-mkp 
.ad p {margin:0;}#ygrp-mkp .ad a 
{color:#ff;text-decoration:none;}#ygrp-sponsor #ygrp-lc 
{font-family:Arial;}#ygrp-sponsor #ygrp-lc #hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#ygrp-sponsor #ygrp-lc .ad 
{margin-bottom:10px;padding:0 0;}#actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#activity
 span {font-weight:700;}#activity span:first-child 
{text-transform:uppercase;}#activity span a 
{color:#5085b6;text-decoration:none;}#activity span span 
{color:#ff7900;}#activity span .underline {text-decoration:underline;}.attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}.attach div a {text-decoration:none;}.attach img 
{border:none;padding-right:5px;}.attach label 
{display:block;margin-bottom:5px;}.attach label a 
{text-decoration:none;}blockquote {margin:0 0 0 4px;}.bold 
{font-family:Arial;font-size:13px;font-weight:700;}.bold a 
{text-decoration:none;}dd.last p a 
{font-family:Verdana;font-weight:700;}dd.last p span 
{margin-right:10px;font-family:Verdana;font-weight:700;}dd.last p 
span.yshortcuts {margin-right:0;}div.attach-table div div a 
{text-decoration:none;}div.attach-table {width:400px;}div.file-title a, 
div.file-title a:active, div.file-title a:hover, div.file-title a:visited 
{text-decoration:none;}div.photo-title a, div.photo-title a:active, 
div.photo-title a:hover, div.photo-title a:visited 
{text-decoration:none;}div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}.green 
{color:#628c2a;}.MsoNormal {margin:0 0 0 0;}o {font-size:0;}#photos div 
{float:left;width:72px;}#photos div div {border:1px solid 

Re: [oracle_br] Re: Crash UNDO sem backup

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Chiappa Obrigado pelo retorno, mas o que você descreveu, foi exatamente o que 
fiz.
mesmo com o database montado com o parametro UNDO_MANAGEMENT manual e colocando 
o datafile 4 em offline ou offline dropo database nao sobe, consequentemente 
nao posso dropar a tablespace e criar uma outra.
Em relação ao parâmetro db _corrupted_rollback_segments eu também já tentei 
utilizar, o problema eh que nao existe nenhum segmento pendente na tablespace 
de UNDO.
Portanto, acho que a única alternativa seria abrir o chamado com a Oracle mesmo.

 

Em Segunda-feira, 14 de Novembro de 2016 16:41, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Tudo jóia ? Então, primeiro a msg parece ser bem clara :

ORA-00376: file 4 cannot be read at this time
ORA-01110: data file 4: 
'/u01/app/oracle/oradata/instance_name/datafile/o1_mf_undotbs1_d2kfszv2_.dbf'

nos diz que o problema é que o arquivo 
'/u01/app/oracle/oradata/instance_name/datafile/o1_mf_undotbs1_d2kfszv2_.dbf' 
não tá podendo ser lido (por causa de corrupção, falha física em disco, sabemos 
lá o que) : Não Sei o que vc esperava conseguir fazendo SHUTDOWN IMMEDIATE, não 
tem lá muuita chance disso corrigir um problema FÍSICO, lá do Sistema 
Operacional, não acha não ???

 No caso, o que eu penso que vc tem que fazer é indicar para o RDBMS ** não 
mais ** acessar o tal arquivo : vou falar sobre o que eu penso ser o 
procedimento, mas que fique CLARO : 
 
 >> antes de efetuar os procedimentos que vou comentar vc DEVERIA obter a 
ajuda e Suporte da Oracle, abrindo um CHAMADO : alguns dos procedimentos são 
Internos, não-documentados E perigosos ao extremo
 
 e
 
 
 >> NINGUÉM te garante 100% de coisa alguma, vc está tentando um 
procedimento de último recurso pra ver se Ajuda o asninho do cliente que não 
tinha backup : SE acontecer o mais provável (que é não der certo) acontecer, 
NINGUÉM pode Reclamar de coisa alguma, deixe Claro pro cliente que é uma 
TENTATIVA de bypassar a besteira que ele fez
 
 
 Basicamente seria o mostrado em 
http://colbran.co.za/wordpress/oracle-12c/open-a-database-without-the-undo-tablespace/
 , ie : com o parâmetro UNDO_MANAGEMENT setado como MANUAL e ** sem ** indicar 
rollback segments e sem o SO poder acessar os datafiles da tablespace de UNDO, 
ele deve montar mas não vai poder abrir, apontando erro de acesso ao datafile , 
aí vc deve conseguir fazer o offline drop dos datafiles da UNDO, criar nova e 
depois dropar a tablespace de undo.
 
  Uma OUTRA possibilidade, se vc não pode abrir o database mas conseguir ao 
menos montar,  seria usar o parãmetro de _corrupted_rollback_segments cfrme  
http://fzaheer.blogspot.com.br/2009/04/how-to-drop-corrupt-undo-tablespace.html 
mostra... NEM PRECISO DIZER que parãmetros _xxx são Internos, Não Documentados 
e perigosos ao Extremo, isso é o ùltimo recurso mesmo
  
  []s
  
    Chiappa  #yiv0910182877 #yiv0910182877 -- #yiv0910182877ygrp-mkp 
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 
10px;}#yiv0910182877 #yiv0910182877ygrp-mkp hr {border:1px solid 
#d8d8d8;}#yiv0910182877 #yiv0910182877ygrp-mkp #yiv0910182877hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv0910182877 #yiv0910182877ygrp-mkp #yiv0910182877ads 
{margin-bottom:10px;}#yiv0910182877 #yiv0910182877ygrp-mkp .yiv0910182877ad 
{padding:0 0;}#yiv0910182877 #yiv0910182877ygrp-mkp .yiv0910182877ad p 
{margin:0;}#yiv0910182877 #yiv0910182877ygrp-mkp .yiv0910182877ad a 
{color:#ff;text-decoration:none;}#yiv0910182877 #yiv0910182877ygrp-sponsor 
#yiv0910182877ygrp-lc {font-family:Arial;}#yiv0910182877 
#yiv0910182877ygrp-sponsor #yiv0910182877ygrp-lc #yiv0910182877hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0910182877 
#yiv0910182877ygrp-sponsor #yiv0910182877ygrp-lc .yiv0910182877ad 
{margin-bottom:10px;padding:0 0;}#yiv0910182877 #yiv0910182877actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0910182877 
#yiv0910182877activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0910182877
 #yiv0910182877activity span {font-weight:700;}#yiv0910182877 
#yiv0910182877activity span:first-child 
{text-transform:uppercase;}#yiv0910182877 #yiv0910182877activity span a 
{color:#5085b6;text-decoration:none;}#yiv0910182877 #yiv0910182877activity span 
span {color:#ff7900;}#yiv0910182877 #yiv0910182877activity span 
.yiv0910182877underline {text-decoration:underline;}#yiv0910182877 
.yiv0910182877attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv0910182877 .yiv0910182877attach div a 
{text-decoration:none;}#yiv0910182877 .yiv0910182877attach img 
{border:none;padding-right:5px;}#yiv0910182877 .yiv0910182877attach label 
{display:block;margin-bottom:5px;}#yiv0910182877 .yiv0910182877attach label a 
{text-decoration:none;}#yiv0910182877 blockquote {margin:0 0 0 
4px;}#yiv0910182877 .yiv0910182877bold 

[oracle_br] Crash UNDO sem backup

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Cenário: EE 12.1.0.2.0OEL 6.5 standloneInstance em shutdown

Me deparei com um cenário que o cliente não tem backup (físico, lógico, hot, 
cold, full, incremental, anything), também não possui nenhum plano de 
contigência...
Pois bem, tentei realizar o seguinte procedimento:

1- Criei um pfile a partir do spfile
2 - alterei o paramentro undo_management para manual
3 - startup mount usando o pfile criado e alterado
4 - coloquei o datafile de UNDO em modo offline drop
5 - Quando tento abrir a base, para depois dropar a tablespace e criar outra, 
me gera o seguinte erro:

ERROR at line 1:ORA-01092: ORACLE instance terminated. Disconnection 
forcedORA-00604: error occurred at recursive SQL level 2ORA-00376: file 4 
cannot be read at this timeORA-01110: data file 
4:'/u01/app/oracle/oradata//datafile/o1_mf_undotbs1_d2kfszv2_.dbf'Process
 ID: 5030Session ID: 237 Serial number: 55395

Também já realizei o procedimento antes de tentar abrir o database, mandei um 
shutdown immediate para baixar a instancia de forma sincronizada, e repeti os 
passos, porém também sem sucesso. O mesmo erro é gerado.


Alert.log

Errors in file 
/u01/app/oracle/diag/rdbms/instance_name/instance_name/trace/cdb1_ora_5264.trc:ORA-00604:
 error occurred at recursive SQL level 2ORA-00376: file 4 cannot be read at 
this timeORA-01110: data file 4: 
'/u01/app/oracle/oradata/instance_name/datafile/o1_mf_undotbs1_d2kfszv2_.dbf'Sun
 Nov 13 16:19:14 2016Errors in file 
/u01/app/oracle/diag/rdbms/instance_name/instance_name/trace/cdb1_ora_5264.trc:ORA-00604:
 error occurred at recursive SQL level 2ORA-00376: file 4 cannot be read at 
this timeORA-01110: data file 4: 
'/u01/app/oracle/oradata/instance_name/datafile/o1_mf_undotbs1_d2kfszv2_.dbf'Error
 604 happened during db open, shutting down databaseUSER (ospid: 5264): 
terminating the instance due to error 604Sun Nov 13 16:19:15 2016Instance 
terminated by USER, pid = 5264ORA-1092 signalled during: alter database 
open...opiodr aborting process unknown ospid (5264) as a result of ORA-1092Sun 
Nov 13 16:19:16 2016ORA-1092 : opitsk aborting process



trace

*** 2016-11-13 16:19:14.442DDE rules only execution for: ORA 1110- START 
Event Driven Actions Dump  END Event Driven Actions Dump - 
START DDE Actions Dump -Executing SYNC actions- START DDE Action: 
'DB_STRUCTURE_INTEGRITY_CHECK' (Async) -Successfully dispatched- END 
DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (SUCCESS, 0 csec) -Executing 
ASYNC actions- END DDE Actions Dump (total 0 csec) -ORA-00604: error 
occurred at recursive SQL level 2ORA-00376: file 4 cannot be read at this 
timeORA-01110: data file 4: 
'/u01/app/oracle/oradata/CDB1/datafile/o1_mf_undotbs1_d2kfszv2_.dbf'ORA-00604: 
error occurred at recursive SQL level 2ORA-00376: file 4 cannot be read at this 
timeORA-01110: data file 4: 
'/u01/app/oracle/oradata/CDB1/datafile/o1_mf_undotbs1_d2kfszv2_.dbf'



Se alguém tiver alguma idéia de como ainda tentar resolver esse problma eu 
agradeceria

[oracle_br] Shutdown abort

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Senhores, só por questão de curiosidade...
Vejo que muita gente tem receio/medo de aplicar um shutdown abort e na maioria 
das vezes desligam o banco com shutdown immediate. Eu na grande maioria das 
vezes quando não preciso do database consistente eu aplico sem medo o shutdown 
abort. Certa vez, li em um artigo que o shutdown abort seria como uma falta de 
energia, que poderia corromper os datafiles do database, mas me aprofundando um 
pouco mais na questão, vi que isso era um  MITO!!! 

ACho que só existem dois casos que eu não aplicaria um shutdown abort
a) Precisando do banco desligado de forma consistente como por exemplo um 
backup cold...b) Se existir um Data Guard com FAST START FAILOVER setado, pois 
quando você realiza um shut abort no primary automaticamente é realizado o 
FAILOVER.
Em relação aos outros participantes do grupo, quais vocês utilizam e qual 
receio de não aplicar um shutdown abort??

Re: [oracle_br] Re: Substituição do Oracle Suporte

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Rosivaldo e Chiappa muito obrigado pelos esclarecimentos.
Em relação a diminuição do licenciamento, muito bem lembrado pelo Rosivaldo, 
isso já foi feito aqui no cliente, temos VMs e com quantidade de CPUs 
limitadissimos.
E a carta de risco irei providenciar imediatamente Chiappa.
Obrigado mais uma vez.
 

Em Segunda-feira, 24 de Outubro de 2016 16:48, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Perfeitamente : vc está 101% correto ao supor que em caso de bug/erro 
crítico (não só o ORA-600 mas Inclusive eventuais corrupções, digamos, até por 
falha de hardware e/ou outras) vc vai estar TOTALMENTE POR CONTA PRÓPRIA e que 
apenas a própria Oracle tem acesso ao código-fonte do RDBMS Oracle e pode fazer 
esse serviço de Suporte nesses casos, E ao apontar que é *** COMPLETAMENTE 
ILEGAL *** alguém  baixar e repassar pra sua Empresa um patch em ambiente para 
o qual vc não tem Contrato de Suporte ativo (referencie o Contrato de uso do 
Suporte para o cliente, onde isso é dito com TOAS AS LETRAS, de modo muito 
Claro), correto...

 Um outro ponto que vc só cita de passagem mas é importante é o ATENDIMENTO : 
qualquer parâmetro interno de configuração, qualquer recomendação / best 
practice, enfim, qualquer Suporte no sentido de Ajuda Técnica ao DBA sem um 
contrato de Suporte vc Não Vai Obter de modo oficial da Oracle, sim... 
  Para ESSE tipo específico de Suporte (ie, Dicas de uso, best practices, 
esclarecimentos, Ajuda ao utilizador, etc) aí SIM vc pode obter alguma Ajuda 
nesse sentido em Fóruns e quetais, bem como pode receber esse serviço de 
Empresas terceiras, mas que fique CLARO que :
  
  a. vc perde a Expertise interna da Oracle, INCLUSIVE o acesso direto à 
Documentação técnica da Oracle (é ** ILEGAL ** uma Empresa ou terceiro qualquer 
obter esse tipo de Informação da Oracle e Replicar/repassar pra sua Empresa)

  b. o Suporte/ajuda obtido fora da Oracle é algo a ser avaliado : nós sabemos 
que existem fontes Excepcionalmente boas, algumas até melhores do que a Oracle, 
mas há também muito lixo aí pelo mercado e pela internet

==> De resto, parabéns pela sua Atuação em deixar a situação Clara para seu 
cliente : se ele insistir nesse procedimento, vc Avisou Só recomendo que a 
Comunicação seja feita de modo OFICIAL, ie, com o que a gente chama de Carta de 
Risco - é um Documento oficial da tua Empresa que será Assinado pelo seu 
Cliente

 []s

   Chiappa  #yiv6895404866 #yiv6895404866 -- #yiv6895404866ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6895404866 
#yiv6895404866ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6895404866 
#yiv6895404866ygrp-mkp #yiv6895404866hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv6895404866 #yiv6895404866ygrp-mkp #yiv6895404866ads 
{margin-bottom:10px;}#yiv6895404866 #yiv6895404866ygrp-mkp .yiv6895404866ad 
{padding:0 0;}#yiv6895404866 #yiv6895404866ygrp-mkp .yiv6895404866ad p 
{margin:0;}#yiv6895404866 #yiv6895404866ygrp-mkp .yiv6895404866ad a 
{color:#ff;text-decoration:none;}#yiv6895404866 #yiv6895404866ygrp-sponsor 
#yiv6895404866ygrp-lc {font-family:Arial;}#yiv6895404866 
#yiv6895404866ygrp-sponsor #yiv6895404866ygrp-lc #yiv6895404866hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv6895404866 
#yiv6895404866ygrp-sponsor #yiv6895404866ygrp-lc .yiv6895404866ad 
{margin-bottom:10px;padding:0 0;}#yiv6895404866 #yiv6895404866actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv6895404866 
#yiv6895404866activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv6895404866
 #yiv6895404866activity span {font-weight:700;}#yiv6895404866 
#yiv6895404866activity span:first-child 
{text-transform:uppercase;}#yiv6895404866 #yiv6895404866activity span a 
{color:#5085b6;text-decoration:none;}#yiv6895404866 #yiv6895404866activity span 
span {color:#ff7900;}#yiv6895404866 #yiv6895404866activity span 
.yiv6895404866underline {text-decoration:underline;}#yiv6895404866 
.yiv6895404866attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv6895404866 .yiv6895404866attach div a 
{text-decoration:none;}#yiv6895404866 .yiv6895404866attach img 
{border:none;padding-right:5px;}#yiv6895404866 .yiv6895404866attach label 
{display:block;margin-bottom:5px;}#yiv6895404866 .yiv6895404866attach label a 
{text-decoration:none;}#yiv6895404866 blockquote {margin:0 0 0 
4px;}#yiv6895404866 .yiv6895404866bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv6895404866 
.yiv6895404866bold a {text-decoration:none;}#yiv6895404866 dd.yiv6895404866last 
p a {font-family:Verdana;font-weight:700;}#yiv6895404866 dd.yiv6895404866last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv6895404866 
dd.yiv6895404866last p span.yiv6895404866yshortcuts 
{margin-right:0;}#yiv6895404866 div.yiv6895404866attach-table div div a 

[oracle_br] Substituição do Oracle Suporte

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Pessoal, boa tarde.
Um cliente que presto serviço não irá mais renovar com o Oracle Support por 
questão financeira, alegam que não tem dinheiro para renovar com a Oracle.O 
gerente está decidindo através de várias pesquisas de mercado, colocar uma 
empresa que presta serviço em banco de dados semelhante a que trabalho.
Porém, algumas das empresas pesquisadas alegam que dão suporte, além do 
serviço, dão suporte ao produto (software). Bom, pelo pouco que sei, **acho** 
que nenhuma empresa no mundo pode dizer que dá suporte FULL ao RDBMS Oracle 
(além da própria Oracle é claro), um exemplo: surgi um BUG crítico 600 fazendo 
o RDBMS ficar indisponível do qual seria necessário aplicar um PATCH/PSU etc. 

Outra coisa que escutei é que algumas empresas disseram que tem acesso ao 
metalink e que baixariam o psu/cpu e aplicariam sem problema nenhum no cliente 
que está sem o suporte da Oracle, bem não sei se isso é legal.
Já alertei ao cliente de todas as possibilidades caso não seja renovado com a 
Oracle Suporte (peguei uma thread do Chiappa e só fiz editar todas as 
sugestões):

Atualização software Oracle: Será inviável Correção de BUGS**: Isso implica 
que QUALQUER BUG...Atendimento: Sem o contrato de suporte, o TRF5 estará 
TOTALMENTE POR CONTA PRÓPRIA...Pesquisas no metalink: Existem materiais e 
informações em fóruns...

==> Bom, eu já não sei mais o que fazer, estou com a minha consciência 
tranquila, a minha parte já fiz que foi alertar. Portanto, a opinião do gerente 
parece ser de que ele contratando alguma empresa especializada em RDBMS Oracle 
terá o mesmo suporte e a mesma segurança que um Oracle Suporte.

Re: [oracle_br] Migração

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Chiappa, obrigado pela força.
Vi sim que você tinha informado sobre os DGs, isso ja foi passado para o 
cliente. Portanto eu achei a melhor opção fazer da seguinte maneira: (ja que 
temos um tempo muito alto de downtime)

Vou realizar um expdp sem indices e constraints, esse dumpfile será realocado 
no servidor Linux para nao precisar passar o arquivo pela rede. Será realizado 
um impdp para extrair os scripts de criação de constraints (adicionar a 
clausula NOVALIDATE) e de índices (NOLOGIN). Tb será alterado a sessão do 
usuário na hora da execução dos scripts para aumentar a área de SORT. Li alguns 
comentarios seus aqui sobre isso. Em suma será feito dessa forma, achei mais 
segura.
Mesmo assim obrigado por ter passado outras maneiras de realizar, com certeza 
irei precisar utilizar uma delas em breve.

 

Em Sexta-feira, 21 de Outubro de 2016 13:15, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     ok - bom, antes de te responder, vc ** VIU ** na minha resposta anterior 
que vc *** NÂO PODE ** aproveitar os standby/dataguards que hoje o servidor 
prod aix tem em outros servers aix : não é Suportado vc ter dataguard físico em 
um SO (AIX, no caso) e ter a origem/prod em outro (o Linux para onde prod vai 
ser migrado), então NÃO DEIXE de levar em conta o tempo/esforço pra reconstruir 
esses standby do PROD, ** E ** de considerar que vc vai precisar de Linux boxes 
ADICIONAIS para passarem a ser os standby do novo server Linux prod. Tá 
claro ? 
 Outro ponto ** importante ** que vc não excluiu definitivamente é a 
Possibilidade (que já tinha sido apontada antes) de se usar Oracle 12c, pois aí 
poderíamos usar o recurso de conversão independente de endian format, cfrme 
http://www.oracle.com/technetwork/pt/articles/database-performance/data-guard12c-cross-platform-2098313-ptb.html
 nos mostra : isso INCLUSIVE permitiria até mesmo backups INCREMENTAIS entre o 
AIX e o Linux, diluindo ainda mais o esforço e aumentando EM MUITO a Segurança, 
vide nota metalink "12C - Reduce Transportable Tablespace Downtime using Cross 
Platform Incremental Backup" (Doc ID 2005729.1)...
  Como vc não nos disse sobre essa possibilidade de ir pro 12c, vou SUPOR que 
há razões técnicas (talvez incompatibilidade de aplicativo, digamos) que 
proíbem o upgrade pro 12c antes da troca de plataforma... Que fique claro, só 
pode ser impedimento técnico, pois FINANCEIRO NÃO Há : não custa um centavo 
sequer a mais de licença vc migrar de 11Gr2 EE para 12c EE
 
 E finalmente, imagino que esteja desconsiderando pela fraqueza do hardware 
(principalmente rede e poder de CPU dos servers, pelo que vc diz) é a 
possibilidade de usar replicação lógica (via STREAMS, já que o muito mais 
robusto Goldengate tá fora, pelo que vc diz), mais ou menos cfrme 
http://www.oraclenutsandbolts.net/index.php/knowledge-base/oracle-streams/26-oracle-streams-10g-one-step-setup
 mostra : migrar para um novo servidor REPLICANDO o database origem no destino 
é, sem dúvida, o que te dá o MENOR DOWNTIME (quase zero, já que tal replicação 
é feita ONLINE), mas como vc não tem $$$ pro GG nem tem o hardware 
(principalmente Rede) potente e capaz que o Streams (e o GG também, claro, 
embora em menor escala) exigem, vou considerar que isso tá fora e que PORTANTO 
vc vai ter SIM algum downtime No caso específico do Streams ele também tem 
RESTRIÇÕES sobre quais datatypes ele pode replicar, o que Impossibilita o uso 
em diversos cenários, mas como o hardware em si já o contra-indica, nem vou 
falar nada sobre isso E como não tem verba pro GG, com certeza não tem 
verba também pra alternativas, como o Shareplex, então caluda sobre isso 
também...
  
  
 Bom, agora respondendo as suas perguntas sobre a migração em si :sobre fazer o 
Linux enxergar os mesmos datafiles ASM que hoje estão sendo usados pelo AIX, é 
primeiro uma questão Física aí, é caso de (com o banco PROD origem em AIX ** 
tpotalmente parado, Óbvio) vc ter no servidor Linux uma HBA compatível, espetar 
uma fibra ligando essa HBA no Storage E DEPOIS config lógica, ie, fazer o Linux 
reconhecer os devices (pode ser preciso um boot, pode ser preciso instalar 
drivers, varia)... Isso depende muito de acordo com o Storage e os 
discos/volumes que vc usa E se vc usa asmlib ou não Se for o caso, passa 
pra gente a descrição EXATA de qual é seu storage, quais tipos/modelos de disco 
ele usa, se vc usa raw ou volumes, se tem multipath ou não , se tem asmlib ou 
não (enfim, os detalhes *** TODINHOS ** aí do seu ambiente) que a gente pode 
tentar palpitar mais e melhor nesse sentido... E como isso só pode ser feito aí 
no seu local, vc COM CERTEZA vai marcar com o cliente um tempinho num fim de 
semana para fazer essas pesquisas e testes ** ANTES ** da conversão/migração em 
si
  A minha idéia com isso de o Linux acessar os datafiles que já estão no 
storage atualmente em uso é POUPAR O TEMPO que vc levaria pra os enviar pela 
rede ou gravar uma mídia 

Re: [oracle_br] Migração

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Chiappa, seguinte: deixei este tópico em standby para obter mais informações do 
cliente e poder disponibilizar mais informações, pois bem:

a) Não será possível utilizar GOlden Gate, pois o cliente não quer gastar 1 
real nessa migração.
b) Os servidores não possuem múltiplas CPU e uma rede "parruda" portanto, esse 
tipo de migração utilizando dblink e uma outra parte realizando expdp está 
descartada.
c) Tempo de downtime 24 horas.

Portanto nos resta duas opções das quais você mencionou


==> Achei interessante a parte que você menciona a migração fazendo com que o 
novo servidor Linux consiga acesso as mesmas LUNs do storage e depois que o 
servidor tiver acesso aos datafiles fazer o CONVERT como você mencionou. QUeria 
te pedir, se possível, se você possui algum tutorial de como realizar essa 
operação, pois eu irei realizar essa migração sem apoio de nenhum Senior, irei 
fazer sozinho, nunca fiz migrações de servidores entre plataformas diferentes.
==> por algum motivo o procedimento anterior não seja viável, dai teria que 
seguir a sua última sugestãode fazer por Reduce Transportable Tablespace 
Downtime using Cross Platform Incremental Backup" (Doc ID 1389592.1), confere? 

Em Quarta-feira, 21 de Setembro de 2016 19:18, "Sérgio Luiz Rodrigues 
Chaves sergio.cha...@elumini.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> 
escreveu:
 

     Rafael,       Você realmente precisa saber o downtime, para definir qual a 
melhor solução para você. Mas também é importante saber quanto eles querem 
gastar.  Recentemente passei por situações semelhantes:
   - Migração de HP(9i) para ORACLE EXADATA (11R2);
   - E De IBM AIX(11gR2)  para ORACLE EXADATA( 11R2);   
   
     
   
     
   
Na primeira situação utilizamos duas estratégias: Na primeira utilizam o Golden 
Gate, sem downtime, a base tinha mais ou menos o 2.5 TB;   
   
Na segunda utilizamos data dump bases menores.   
   
     
   
Na segunda utilizamos Export / Import.   
   
     
   
Mas tudo isso vai depender dos servidores de destino, como não sabemos  
fica difícil informar qual a melhor solução. Ainda podemos estudar a utilização 
do RMAN.   
   
     
   
     
   
Boa sorte.   
   
  
 Sérgio. 
De: oracle_br@yahoogrupos.com.br <oracle_br@yahoogrupos.com.br> em nome de 
Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br>
Enviado: quarta-feira, 21 de setembro de 2016 14:24:00
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] Migração  Ontem por algum motivo não estava sendo 
possível o envio de email para o grupo, portanto foram enviados dois e-mails, 
favor desconsiderar o outro email, vamos usar este aqui e ignorar o outro.


Em Quarta-feira, 21 de Setembro de 2016 14:16, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:


 Senhores, boa tarde. 

Gostaria da ajuda de vocês para o seguinte cenário:
Um cliente solicitou que um SGBD Oracle EE 11.2.0.4.16 ASM standalone em um 
ambiente de produção em um sistema operacional AIX 6.1 64 bits ( que também 
possui dois DATAGUARDS Físicos com a mesma configuração) fosse migrado para um 
outro servidor LInux Redhat 6.x ou 7.0 64 bits. O tamanho da base é de 2,4 TB.

Gostaria de saber de vocês qual seria o melhor modo de se fazer essa migração.
Obs1: O tempo de downtime não foi informado, mas acho que o cliente teria um 
dia do final de semana livre para realizar essa tarefa.
Alguém poderia ajudar?



  #yiv9061301510 #yiv9061301510 -- #yiv9061301510ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9061301510 
#yiv9061301510ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9061301510 
#yiv9061301510ygrp-mkp #yiv9061301510hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9061301510 #yiv9061301510ygrp-mkp #yiv9061301510ads 
{margin-bottom:10px;}#yiv9061301510 #yiv9061301510ygrp-mkp .yiv9061301510ad 
{padding:0 0;}#yiv9061301510 #yiv9061301510ygrp-mkp .yiv9061301510ad p 
{margin:0;}#yiv9061301510 #yiv9061301510ygrp-mkp .yiv9061301510ad a 
{color:#ff;text-decoration:none;}#yiv9061301510 #yiv9061301510ygrp-sponsor 
#yiv9061301510ygrp-lc {font-family:Arial;}#yiv9061301510 
#yiv9061301510ygrp-sponsor #yiv9061301510ygrp-lc #yiv9061301510hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9061301510 
#yiv9061301510ygrp-sponsor #yiv9061301510ygrp-lc .yiv9061301510ad 
{margin-bottom:10px;padding:0 0;}#yiv9061301510 #yiv9061301510actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9061301510 
#yiv9061301510activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9061301510
 #yiv9061301510activity span {font-weight:700;}#yiv9061301510 
#yiv9061301510activity span:first-child 
{text-transform:uppercase;}#yiv9061301510 #yiv9061301510activity span a 
{color:#5085b6;text-decoration:none;}#yiv9061301510

Re: [oracle_br] Migração

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Ontem por algum motivo não estava sendo possível o envio de email para o grupo, 
portanto foram enviados dois e-mails, favor desconsiderar o outro email, vamos 
usar este aqui e ignorar o outro.
 

Em Quarta-feira, 21 de Setembro de 2016 14:16, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Senhores, boa tarde. 

Gostaria da ajuda de vocês para o seguinte cenário:
Um cliente solicitou que um SGBD Oracle EE 11.2.0.4.16 ASM standalone em um 
ambiente de produção em um sistema operacional AIX 6.1 64 bits ( que também 
possui dois DATAGUARDS Físicos com a mesma configuração) fosse migrado para um 
outro servidor LInux Redhat 6.x ou 7.0 64 bits. O tamanho da base é de 2,4 TB. 

Gostaria de saber de vocês qual seria o melhor modo de se fazer essa migração.
Obs1: O tempo de downtime não foi informado, mas acho que o cliente teria um 
dia do final de semana livre para realizar essa tarefa.
Alguém poderia ajudar?

  #yiv3603839272 #yiv3603839272 -- #yiv3603839272ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3603839272 
#yiv3603839272ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3603839272 
#yiv3603839272ygrp-mkp #yiv3603839272hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv3603839272 #yiv3603839272ygrp-mkp #yiv3603839272ads 
{margin-bottom:10px;}#yiv3603839272 #yiv3603839272ygrp-mkp .yiv3603839272ad 
{padding:0 0;}#yiv3603839272 #yiv3603839272ygrp-mkp .yiv3603839272ad p 
{margin:0;}#yiv3603839272 #yiv3603839272ygrp-mkp .yiv3603839272ad a 
{color:#ff;text-decoration:none;}#yiv3603839272 #yiv3603839272ygrp-sponsor 
#yiv3603839272ygrp-lc {font-family:Arial;}#yiv3603839272 
#yiv3603839272ygrp-sponsor #yiv3603839272ygrp-lc #yiv3603839272hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3603839272 
#yiv3603839272ygrp-sponsor #yiv3603839272ygrp-lc .yiv3603839272ad 
{margin-bottom:10px;padding:0 0;}#yiv3603839272 #yiv3603839272actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3603839272 
#yiv3603839272activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3603839272
 #yiv3603839272activity span {font-weight:700;}#yiv3603839272 
#yiv3603839272activity span:first-child 
{text-transform:uppercase;}#yiv3603839272 #yiv3603839272activity span a 
{color:#5085b6;text-decoration:none;}#yiv3603839272 #yiv3603839272activity span 
span {color:#ff7900;}#yiv3603839272 #yiv3603839272activity span 
.yiv3603839272underline {text-decoration:underline;}#yiv3603839272 
.yiv3603839272attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv3603839272 .yiv3603839272attach div a 
{text-decoration:none;}#yiv3603839272 .yiv3603839272attach img 
{border:none;padding-right:5px;}#yiv3603839272 .yiv3603839272attach label 
{display:block;margin-bottom:5px;}#yiv3603839272 .yiv3603839272attach label a 
{text-decoration:none;}#yiv3603839272 blockquote {margin:0 0 0 
4px;}#yiv3603839272 .yiv3603839272bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3603839272 
.yiv3603839272bold a {text-decoration:none;}#yiv3603839272 dd.yiv3603839272last 
p a {font-family:Verdana;font-weight:700;}#yiv3603839272 dd.yiv3603839272last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3603839272 
dd.yiv3603839272last p span.yiv3603839272yshortcuts 
{margin-right:0;}#yiv3603839272 div.yiv3603839272attach-table div div a 
{text-decoration:none;}#yiv3603839272 div.yiv3603839272attach-table 
{width:400px;}#yiv3603839272 div.yiv3603839272file-title a, #yiv3603839272 
div.yiv3603839272file-title a:active, #yiv3603839272 
div.yiv3603839272file-title a:hover, #yiv3603839272 div.yiv3603839272file-title 
a:visited {text-decoration:none;}#yiv3603839272 div.yiv3603839272photo-title a, 
#yiv3603839272 div.yiv3603839272photo-title a:active, #yiv3603839272 
div.yiv3603839272photo-title a:hover, #yiv3603839272 
div.yiv3603839272photo-title a:visited {text-decoration:none;}#yiv3603839272 
div#yiv3603839272ygrp-mlmsg #yiv3603839272ygrp-msg p a 
span.yiv3603839272yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3603839272 
.yiv3603839272green {color:#628c2a;}#yiv3603839272 .yiv3603839272MsoNormal 
{margin:0 0 0 0;}#yiv3603839272 o {font-size:0;}#yiv3603839272 
#yiv3603839272photos div {float:left;width:72px;}#yiv3603839272 
#yiv3603839272photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv3603839272 
#yiv3603839272photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3603839272
 #yiv3603839272reco-category {font-size:77%;}#yiv3603839272 
#yiv3603839272reco-desc {font-size:77%;}#yiv3603839272 .yiv3603839272replbq 
{margin:4px;}#yiv3603839272 #yiv3603839272ygrp-actbar div a:first-child 
{margin-right:2px;padding-right:5px;}#yiv3603839272 #yiv3603839272ygrp-mlmsg 

[oracle_br] Migração

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; }  Senhores, boa tarde.Um cliente solicitou a migração de uma base 
Oracle enterprise edition 11.2.0.4.16 ASM stand alone em um SO AIX 6.1 64 bits 
pra um Linux redhat 7 ou 6 64 bits. A base tem um tamanho de 2,3 TB. Gostaria 
de saber de vocês qual seria o melhor procedimento para realizar essa tarefa.
Obs: em relação ao downtime, o cliente ainda não forneceu informações a 
respeito (estou no aguardo), porém acho que um dia no final de semana de 
indisponibilidade não seria problema, infelizmente não tenho certeza do tempo. 


Enviado do Yahoo Mail para iPhone
 

[oracle_br] Migração

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Senhores, boa tarde. 

Gostaria da ajuda de vocês para o seguinte cenário:
Um cliente solicitou que um SGBD Oracle EE 11.2.0.4.16 ASM standalone em um 
ambiente de produção em um sistema operacional AIX 6.1 64 bits ( que também 
possui dois DATAGUARDS Físicos com a mesma configuração) fosse migrado para um 
outro servidor LInux Redhat 6.x ou 7.0 64 bits. O tamanho da base é de 2,4 TB. 

Gostaria de saber de vocês qual seria o melhor modo de se fazer essa migração.
Obs1: O tempo de downtime não foi informado, mas acho que o cliente teria um 
dia do final de semana livre para realizar essa tarefa.
Alguém poderia ajudar?

Re: [oracle_br] Re: Envio de alertas

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Rodrigo, obrigado pela ajuda.
Chiappa, pode ser externo ao database também. 

Em Quinta-feira, 15 de Setembro de 2016 16:07, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, primeiro entendo que como vc bem claramente diz "de dentro do 
database", soluções de fora do database (como jobs de SO, ou pooling no ADR do 
Oracle) tão descartadas... 
  Muito bem, se vc quer executar alguma rotina dentro do database, vc vai ter 
que PROGRAMAR algo - as suas opções de linguagem de programação são Java (** se 
** vc tiver instalado o JVM, que é opcional) OU então PL/SQL, que tem a 
vantagem de ser uma opção default e (até por isso) muito mais conhecida, que 
dispõe de muito mais refs 
 Continuando, vc quer que esse "algo" que vc programou dentro do banco seja 
executado quando alguma linha contendo alert crítico seja gravada no alert.log 
: afaik ** não ** há um trigger Específico para isso que dispare 
automaticamente, então creio que vc vai ter que executar (por um dos mecanismos 
de job schedulers do Oracle, seja o interfaceado via DBMS_JOB seja o mais 
recente DBMS_SCHEDULER) um "algo" programado a cada x minutos que consulta o 
alert.log (via EXTRENAL TABLE, por exemplo) e vê se existe algum alerta 
crítico, se existir manda o email
 
 Aí o ponto final : pra vc mandar email pelo PL/SQL de dentro do banco, vc TEM 
que ter acesso a um servidor de emails a partir do servidor de banco de dados, 
vai criar um ACL para permitir essa conexão de rede, aí vai escrever um PL/SQL 
que crie e envie o email, provavelmente via UTL_SMTP...

Exemplos para todas as tarefas abundam na internet, dá uma googlada por ORACLE 
11G SEND EMAIL, por ORACLE ALERT.LOG EXTERNAL TABLE e por ORACLE JOB que vc 
acha exemplos de tudo...

 []s

  Chiappa  #yiv2803825064 #yiv2803825064 -- #yiv2803825064ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2803825064 
#yiv2803825064ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2803825064 
#yiv2803825064ygrp-mkp #yiv2803825064hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2803825064 #yiv2803825064ygrp-mkp #yiv2803825064ads 
{margin-bottom:10px;}#yiv2803825064 #yiv2803825064ygrp-mkp .yiv2803825064ad 
{padding:0 0;}#yiv2803825064 #yiv2803825064ygrp-mkp .yiv2803825064ad p 
{margin:0;}#yiv2803825064 #yiv2803825064ygrp-mkp .yiv2803825064ad a 
{color:#ff;text-decoration:none;}#yiv2803825064 #yiv2803825064ygrp-sponsor 
#yiv2803825064ygrp-lc {font-family:Arial;}#yiv2803825064 
#yiv2803825064ygrp-sponsor #yiv2803825064ygrp-lc #yiv2803825064hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2803825064 
#yiv2803825064ygrp-sponsor #yiv2803825064ygrp-lc .yiv2803825064ad 
{margin-bottom:10px;padding:0 0;}#yiv2803825064 #yiv2803825064actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2803825064 
#yiv2803825064activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2803825064
 #yiv2803825064activity span {font-weight:700;}#yiv2803825064 
#yiv2803825064activity span:first-child 
{text-transform:uppercase;}#yiv2803825064 #yiv2803825064activity span a 
{color:#5085b6;text-decoration:none;}#yiv2803825064 #yiv2803825064activity span 
span {color:#ff7900;}#yiv2803825064 #yiv2803825064activity span 
.yiv2803825064underline {text-decoration:underline;}#yiv2803825064 
.yiv2803825064attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv2803825064 .yiv2803825064attach div a 
{text-decoration:none;}#yiv2803825064 .yiv2803825064attach img 
{border:none;padding-right:5px;}#yiv2803825064 .yiv2803825064attach label 
{display:block;margin-bottom:5px;}#yiv2803825064 .yiv2803825064attach label a 
{text-decoration:none;}#yiv2803825064 blockquote {margin:0 0 0 
4px;}#yiv2803825064 .yiv2803825064bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv2803825064 
.yiv2803825064bold a {text-decoration:none;}#yiv2803825064 dd.yiv2803825064last 
p a {font-family:Verdana;font-weight:700;}#yiv2803825064 dd.yiv2803825064last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv2803825064 
dd.yiv2803825064last p span.yiv2803825064yshortcuts 
{margin-right:0;}#yiv2803825064 div.yiv2803825064attach-table div div a 
{text-decoration:none;}#yiv2803825064 div.yiv2803825064attach-table 
{width:400px;}#yiv2803825064 div.yiv2803825064file-title a, #yiv2803825064 
div.yiv2803825064file-title a:active, #yiv2803825064 
div.yiv2803825064file-title a:hover, #yiv2803825064 div.yiv2803825064file-title 
a:visited {text-decoration:none;}#yiv2803825064 div.yiv2803825064photo-title a, 
#yiv2803825064 div.yiv2803825064photo-title a:active, #yiv2803825064 
div.yiv2803825064photo-title a:hover, #yiv2803825064 
div.yiv2803825064photo-title a:visited {text-decoration:none;}#yiv2803825064 
div#yiv2803825064ygrp-mlmsg #yiv2803825064ygrp-msg p a 
span.yiv2803825064yshortcuts 

[oracle_br] Envio de alertas

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Oracle 11.2.0.4.16 EE AIX 6.1 ASM single instance.
Senhores, boa tarde.
Estou precisando implementar uma tarefa que toda vez que apareça algum alerta 
crítico no alert.log, esse alerta seja enviado por e-mail. Gostaria de 
implementar via PL/SQL sem uso do Cloud control ou do Enterprise Manager. 

Alguém poderia ajudar?

Re: [oracle_br] Lentidão ??

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Senhores, primeiramente gostaria de agradecer a todos que cooperaram, a solução 
tomada por nós foi adicionar uma condição na trigger antes da consulta para que 
este processo do usuário não executasse a consulta que estava impactando na 
lentidão do processo, até porque esse processo executado pelo usuário não fazia 
parte da lógica implementada na trigger, consequentemente o problema foi sanado.
 
 

Em Quarta-feira, 14 de Setembro de 2016 14:38, "Andre Santos 
andre.psantos...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Rafael
Aplicação em Delphi... pode ser que seja 2 camadas apenas.Mas, pelo que você 
descreveu, de ter o mesmo comportamento em várias máquinas, não parece ser o 
fator que está influenciando.
No parte que você respondeu:   R: Se eu executar essa consulta por fora com os 
mesmo parâmetros a consulta me retorna em milissegundos.

Quando você executa por fora, você faz com variáveis "bind" também? (ou colocou 
os valores literais na consulta?)
O cenário lembra aquele problema de "bind variable peeking", que existia no 
10g... mas você está usando a versão 11g, né?De qualquer forma, acho 
interessante verificar se não está gerando planos diferentes (cursores 
diferentes) nas execuções.Tente verificar em V$SQL_PLAN e com 
DBMS_XPLAN.DISPLAY_CURSOR.
[ ]
André

Em 14 de setembro de 2016 11:24, Rafael Mendonca raffaell.t...@yahoo.com 
[oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:

     A aplicação é feita em Delphi e também muita coisa escrita em PL/SQL
* Inclusive essa consulta está escrita dentro de uma trigger.*
- O problema é só com um determinado usuário da aplicação mesmo?
R: Não, o problema é com qualquer usuário que tenta executar essa mesma tarefa.

 - A lentidão da aplicação com esse usuário é geral ou apenas em determinados 
processos ou consultas? R: A lentidão é geral em todo processo que ele realiza, 
consultando sempre a v$session_wait entre outras V$ vi que a maior parte do 
tempo (80%) a sessão fica ativa com a consulta que foi passada.

- Ele já tentou executar de outra máquina?
R: Já tentamos fazer isso, de qualquer máquina o tempo de término é o mesmo.
 - Se outro usuário executar a mesma consulta (com exatamente os mesmos 
parâmetros), qual é o tempo?
R: Se eu executar essa consulta por fora com os mesmo parâmetros a consulta me 
retorna em milissegundos.


Obs: Rodrigo, irei estudar a respeito desses parametros para ajustar e respondo 
aqui se houve alguma melhora significativa, também entrei em contato com o 
usuário e com os desenvolvedores, e tudo indica que essa TRIGGER não é de 
fundamental importancia para o sistema que o usuario está utilizando (nem para 
outros), porém iremos estudar se é viável desabilitar a trigger e verificar a 
melhora do processo.

 

Em Quarta-feira, 14 de Setembro de 2016 10:48, "Andre Santos 
andre.psantos...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Rafael
Problema misterioso, heim!Depois do desligamento imprevisto, acho que subiu 
algo desconfigurado... O que me chamou a atenção:
  Event waited on Times   Max. Wait  Total Waited
  -- --   Waited  --  
  SQL*Net message from client  3566   19.03 65.30

O evento que mais demora é esperando as mensagens a partir "do cliente" (no 
caso, seria o servidor de aplicação).
Sem contar que tanto o SELECT quanto o INSERT (que parece ser simples) gastaram 
praticamente o mesmo tempo de Execute (elapsed = 41.6...). Pode ser 
coincidência, mas talvez seja o "padrão" de algum gargalo que está ocorrendo na 
aplicação.E o Fetch mesmo parece que não está demorado.

A arquitetura da aplicação é de 3 camadas (com um servidor de aplicação entre o 
client e o SGBD)?Para continuar investigando: - O problema é só com um 
determinado usuário da aplicação mesmo? - A lentidão da aplicação com esse 
usuário é geral ou apenas em determinados processos ou consultas? - Ele já 
tentou executar de outra máquina? - Se outro usuário executar a mesma consulta 
(com exatamente os mesmos parâmetros), qual é o tempo?
[ ]'s
André

Em 13 de setembro de 2016 20:18, Rodrigo Mufalani rodr...@mufalani.com.br 
[oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:

     Boa noite,

 O teu problema não está em disco (db file sequential read).


Event waited on Times Max. Wait Total Waited
 -- -- Waited -- 
 db file sequential read 1 0.00 0.00
 latch: row cache objects 4 0.00 0.00
 SQL*Net message to client 3566 0.00 0.02
 log file sync 41 0.00 0.08
 SQL*Net message from client 3566 19.03 65.30
 latch: shared pool 1 0.00 0.00
 direct path read 23 0.02 0.05
 direct path write 6 0.00 0.00
 SQL*Net more data from client 3 0.00 0.00
 SQL*Net more data to client 2 0.00 0.00


Olhe para as colunas Times Wai

Re: [oracle_br] Lentidão ??

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

A aplicação é feita em Delphi e também muita coisa escrita em PL/SQL
* Inclusive essa consulta está escrita dentro de uma trigger.*
- O problema é só com um determinado usuário da aplicação mesmo?
R: Não, o problema é com qualquer usuário que tenta executar essa mesma tarefa.

 - A lentidão da aplicação com esse usuário é geral ou apenas em determinados 
processos ou consultas? R: A lentidão é geral em todo processo que ele realiza, 
consultando sempre a v$session_wait entre outras V$ vi que a maior parte do 
tempo (80%) a sessão fica ativa com a consulta que foi passada.

- Ele já tentou executar de outra máquina?
R: Já tentamos fazer isso, de qualquer máquina o tempo de término é o mesmo.
 - Se outro usuário executar a mesma consulta (com exatamente os mesmos 
parâmetros), qual é o tempo?
R: Se eu executar essa consulta por fora com os mesmo parâmetros a consulta me 
retorna em milissegundos.


Obs: Rodrigo, irei estudar a respeito desses parametros para ajustar e respondo 
aqui se houve alguma melhora significativa, também entrei em contato com o 
usuário e com os desenvolvedores, e tudo indica que essa TRIGGER não é de 
fundamental importancia para o sistema que o usuario está utilizando (nem para 
outros), porém iremos estudar se é viável desabilitar a trigger e verificar a 
melhora do processo.

 

Em Quarta-feira, 14 de Setembro de 2016 10:48, "Andre Santos 
andre.psantos...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Rafael
Problema misterioso, heim!Depois do desligamento imprevisto, acho que subiu 
algo desconfigurado... O que me chamou a atenção:
  Event waited on Times   Max. Wait  Total Waited
     Waited  --  
  SQL*Net message from client  3566   19.03 65.30

O evento que mais demora é esperando as mensagens a partir "do cliente" (no 
caso, seria o servidor de aplicação).
Sem contar que tanto o SELECT quanto o INSERT (que parece ser simples) gastaram 
praticamente o mesmo tempo de Execute (elapsed = 41.6...). Pode ser 
coincidência, mas talvez seja o "padrão" de algum gargalo que está ocorrendo na 
aplicação.E o Fetch mesmo parece que não está demorado.

A arquitetura da aplicação é de 3 camadas (com um servidor de aplicação entre o 
client e o SGBD)?Para continuar investigando: - O problema é só com um 
determinado usuário da aplicação mesmo? - A lentidão da aplicação com esse 
usuário é geral ou apenas em determinados processos ou consultas? - Ele já 
tentou executar de outra máquina? - Se outro usuário executar a mesma consulta 
(com exatamente os mesmos parâmetros), qual é o tempo?
[ ]'s
André

Em 13 de setembro de 2016 20:18, Rodrigo Mufalani rodr...@mufalani.com.br 
[oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:

     Boa noite,

 O teu problema não está em disco (db file sequential read).


Event waited on Times Max. Wait Total Waited
 -- -- Waited -- 
 db file sequential read 1 0.00 0.00
 latch: row cache objects 4 0.00 0.00
 SQL*Net message to client 3566 0.00 0.02
 log file sync 41 0.00 0.08
 SQL*Net message from client 3566 19.03 65.30
 latch: shared pool 1 0.00 0.00
 direct path read 23 0.02 0.05
 direct path write 6 0.00 0.00
 SQL*Net more data from client 3 0.00 0.00
 SQL*Net more data to client 2 0.00 0.00


Olhe para as colunas Times Waited que tem maiores valores. Se for uma apps java 
aumente o fetchsize, (procure por setFetchSize(100)), ou mais, o padrão são 10 
linhas, também incremente o SDU size e TDU size no tnsnames e listener.ora


Atenciosamente,

<http://www.mufalani.com.br/> Rodrigo Mufalani - Diretor Técnico | 
rodr...@mufalani.com.br< mailto: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<mailto:rod r...@mufalani.com.br>
<http://www.mufalani.com.br/>[ cid:image001.png@01D20DFB. 
F9D31B80]<http://www.mufalani. com.br/>[cid:image002.png@ 01D20DFB.F9D31B80]


De: <oracle_br@yahoogrupos.com.br> em nome de "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br>
Responder para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br>
Data: terça-feira, 13 de setembro de 2016 18:46
Para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br>
Assunto: Re: [oracle_br] Lentidão ??


Angelo/Andre

Ele acessa o sistema que conecta no servidor de aplicação e consequentemente no 
banco de dados, eu não tenho mais informações a respeito disso, pois o 
responsável pela aplicação já foi embora. O usuário está local.


Em relação ao trace, segue algumas informações relevantes:




SQL ID: 8mvsyr5t2sndh Plan Hash: 2923565733

SELECT MIN(EMD

Re: [oracle_br] Lentidão ??

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

.00
  latch: shared pool  4    0.00  0.00
  direct path read   18    0.01  0.08
  direct path write  18    0.00  0.02

 1410  user  SQL statements in session.
  253  internal SQL statements in session.
 1663  SQL statements in session.


Em Terça-feira, 13 de Setembro de 2016 17:06, "Andre Santos 
andre.psantos...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Rafael
No trace 10046, está incluindo informação de "waits" (level 8 ou maior)?
Aparece em que está gastando tempo, para totalizar esses 40~45 segundos?
[ ]
André

Em 13 de setembro de 2016 15:42, angelo angelolis...@gmail.com [oracle_br] 
<oracle_br@yahoogrupos.com.br> escreveu:

     Rafael,
E a aplicação do usuário ?  Como a aplicação alcança o banco de dados ?  Seria 
a partir da maquina dele x banco ou algum servidor de aplicacao ou webservice 
no meio do caminho ?
Esse usuario, está local, esta remoto... ?




2016-09-13 15:32 GMT-03:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br> :

     => Oracle EE 11.2.0.4.16 AIX 6.1 64 bits ASM single instance.Options -> 
tuning pack, diagnostic pack

Senhores, boa tarde.
Um usuário em especial está reclamando de problema de lentidão na tarefa que 
ele está executando. A tarefa era executada em 15 segundos no pior dos casos 
(até o dia 09/09/2016) e agora a mesma tarefa está levando 40 a 45 segundos. 
Nesse intervalo de tempo nada foi modificado, nem aplicação, nem database, o 
que houve foi uma queda de energia no final de semana desligando todos os 
servidores (Pessoal do storage e AIX já verificou se existiu algum problema 
após o desligamento e nada foi encontrado).

Verificação:
Verificando CPU, Memória, I/O Swap do servidor está tudo normal, o RDBMS está 
respondendo rápido, não estamos com problema de desempenho, é uma reclamação 
única de um determinado usuário.
a) Verifiquei sessões ativasb) V$SESSION_WAIT W, V$SESSION S, V$PROCESS P,  
V$SQLTEXT SQL 
c) oratopd) trace 10046
O que consegui encontrar é que existe uma consulta que é onde o usuário passa a 
maior parte do tempo com a sua sessão ATIVA. Uma consulta simples, segue abaixo:

SELECT MIN(EMD.DTHRMOV) 
  FROM  LF, 
   XXX  MF, 
    EMD 
 WHERE MF.CODDOC = :B1 
   AND MF.DTHRMOV = (SELECT MAX(DTHRMOV) 
   FROM XXX
  WHERE CODDOC = :B1 
    AND DTHRMOV < :B2 
 ) 
   AND MF.CODLOCAL = LF.CODLOCAL 
   AND EMD.CODDOC=MF.CODDOC 
   AND EMD.DTHRMOV=MF.DTHRMOV

Plan hash value: 2923565733

-- -
   Id | Operation    NAME    ROWS Cost  
   Stale
-- --   
|    0 | SELECT STATEMENT      1   2
|    1 |  SORT AGGREGATE   1   2 
|    2 |   NESTED LOOPS                1 2
|    3 |    NESTED LOOPS               1     2  
  NO
|    4 | TABLE ACCESS BY INDEX ROWID   XXX  1   2
|    5 |  INDEX RANGE SCAN XXX 1    2   
    NO
|    6 |   SORT AGGREGATE   1    2  
 NO 
|    7 |    TABLE ACCESS BY INDEX ROWID    XXX  1       2   
   NO
|    8 | INDEX RANGE SCAN  XXX  1   2   
  NO
|    9 | INDEX RANGE SCAN  XXX   1   2  
 NO
|   10 |    TABLE ACCESS BY INDEX ROWID    XXX  1  2
   NO-- --
Acontece que quando eu executo essa consulta no sqlplus ou em outro front-end a 
consulta é executada em menos de um segundo, extremamente rápida. 

obs: Na wait_event quando a consulta é executada é mostrado o 
db_file_sequencial read, só adiantando que o cache_size é mais que suficiente.

Alguém poderia ajudar a resolver essa bronca?






   

   

  #yiv3288987806 -- #yiv3288987806ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3288987806 
#yiv3288987806ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3288987806 
#yiv3288987806ygrp-mkp #yiv3288987806hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv3288987806 #yiv3288987806ygrp-mkp #yiv3288987806ads 
{margin-bottom:10px;}#yiv3288987806 #yiv3288987806ygrp-mkp .yiv3288987806ad 
{padding:0 0;}#yiv3288987806 #yiv3288987806ygrp-mkp .yiv3288987806ad p 
{margin:0;}#yiv3288987806 #yiv3288987806ygrp-mkp .yiv3288987806ad a 
{color:#ff;text-decoration:none;}#yiv3288987806 #yiv3288987806ygrp-sponsor 
#yiv3288987806ygrp-lc {font-family:Arial;}#yiv3288987806 
#yiv3288987806ygrp-spon

[oracle_br] Lentidão ??

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

=> Oracle EE 11.2.0.4.16 AIX 6.1 64 bits ASM single instance.Options -> tuning 
pack, diagnostic pack

Senhores, boa tarde.
Um usuário em especial está reclamando de problema de lentidão na tarefa que 
ele está executando. A tarefa era executada em 15 segundos no pior dos casos 
(até o dia 09/09/2016) e agora a mesma tarefa está levando 40 a 45 segundos. 
Nesse intervalo de tempo nada foi modificado, nem aplicação, nem database, o 
que houve foi uma queda de energia no final de semana desligando todos os 
servidores (Pessoal do storage e AIX já verificou se existiu algum problema 
após o desligamento e nada foi encontrado).

Verificação:
Verificando CPU, Memória, I/O Swap do servidor está tudo normal, o RDBMS está 
respondendo rápido, não estamos com problema de desempenho, é uma reclamação 
única de um determinado usuário.
a) Verifiquei sessões ativasb) V$SESSION_WAIT W, V$SESSION S, V$PROCESS P,  
V$SQLTEXT SQL 
c) oratopd) trace 10046
O que consegui encontrar é que existe uma consulta que é onde o usuário passa a 
maior parte do tempo com a sua sessão ATIVA. Uma consulta simples, segue abaixo:

SELECT MIN(EMD.DTHRMOV) 
  FROM  LF, 
   XXX  MF, 
    EMD 
 WHERE MF.CODDOC = :B1 
   AND MF.DTHRMOV = (SELECT MAX(DTHRMOV) 
   FROM XXX
  WHERE CODDOC = :B1 
    AND DTHRMOV < :B2 
 ) 
   AND MF.CODLOCAL = LF.CODLOCAL 
   AND EMD.CODDOC=MF.CODDOC 
   AND EMD.DTHRMOV=MF.DTHRMOV

Plan hash value: 2923565733

---
   Id | Operation   NAME    ROWS Cost   
  Stale
   
|    0 | SELECT STATEMENT     1   2
|    1 |  SORT AGGREGATE  1   2 
|    2 |   NESTED LOOPS               1 2
|    3 |    NESTED LOOPS              1     2   
 NO
|    4 | TABLE ACCESS BY INDEX ROWID   XXX  1   2
|    5 |  INDEX RANGE SCAN XXX 1    2   
    NO
|    6 |   SORT AGGREGATE  1    2   
    NO 
|    7 |    TABLE ACCESS BY INDEX ROWID    XXX  1       2   
   NO
|    8 | INDEX RANGE SCAN  XXX  1   2   
  NO
|    9 | INDEX RANGE SCAN  XXX   1   2  
 NO
|   10 |    TABLE ACCESS BY INDEX ROWID    XXX  1  2
   NO
Acontece que quando eu executo essa consulta no sqlplus ou em outro front-end a 
consulta é executada em menos de um segundo, extremamente rápida. 

obs: Na wait_event quando a consulta é executada é mostrado o 
db_file_sequencial read, só adiantando que o cache_size é mais que suficiente.

Alguém poderia ajudar a resolver essa bronca?

[oracle_br] ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Cenário: 

- Servidor origem: Oracle 11gR2 AIX 6   SID: PRODUCAO
- Servidor destino: Oracle 11gR2 AIX 6  SID: SUPORTE

Conectado no servidor de destino, quando executo o comando abaixo:
rman target sys/senha@PRODUCAO auxiliary sys/senha@SUPORTE
recebo o seguinte erro:
RMAN-00571: ===
RMAN-00569: === ERROR MESSAGE STACK FOLLOWS ===
RMAN-00571: ===
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database: 
ORA-12514: TNS:listener does not currently know of service requested in connect 
descriptor

Obs1: SE eu executar este mesmo comando no ambiente de PRODUCAO (servidor 
origem) o comando é executado com sucesso.
Obs2: O TNSPING fecha para as duas bases, nos dois servidores. Está OK.

Suponho que o problema esteja no LISTENER do servidor destino (SID: SUPORTE)
Tentando encontrar o problema, realizei o seguinte procedimento:

lsnrctl status
Services Summary...
Service "+ASM" has 1 instance(s).
  Instance "+ASM", status READY, has 1 handler(s) for this service...
Service "PRODUCAO" has 1 instance(s).
  Instance "PRODUCAO", status UNKNOWN, has 1 handler(s) for this service...
Service "SUPORTE" has 2 instance(s).
  Instance "SUPORTE", status UNKNOWN, has 1 handler(s) for this service...
  Instance "SUPORTE", status BLOCKED, has 1 handler(s) for this service...
The command completed successfully
Estranho ele me mostrar 2 instancias na base de SUPORTE uma como UNKNOWN e 
outra como BLOCKED.
O que fiz foi: Shut abort; startup nomount; Reiniciei o listener, entao 
consultando novamente, eu tenho:

lsnrctl status
Services Summary...
Service "PRODUCAO" has 1 instance(s).
  Instance "PRODUCAO", status UNKNOWN, has 1 handler(s) for this service...
Service "SUPORTE" has 1 instance(s).
  Instance "SUPORTE", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

Beleza, aparentemente tudo certo. Só que quando tento novamente conectar no 
RMAN o mesmo erro é mostrado e quando tento verificar o status do LISTENER eu 
me deparo com a seguinte situação novamente:

lsnrctl status
Services Summary...
Service "+ASM" has 1 instance(s).
  Instance "+ASM", status READY, has 1 handler(s) for this service...
Service "PRODUCAO" has 1 instance(s).
  Instance "PRODUCAO", status UNKNOWN, has 1 handler(s) for this service...
Service "SUPORTE" has 2 instance(s).
  Instance "SUPORTE", status UNKNOWN, has 1 handler(s) for this service...
  Instance "SUPORTE", status BLOCKED, has 1 handler(s) for this service...
The command completed successfully

## LISTENER DO SERVIDOR DESTINO (SID: SUPORTE)
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
  (GLOBAL_DBNAME = SUPORTE)
  (ORACLE_HOME = /u01/app/oracle/product/11.2.0.4/dbhome_1)
  (SID_NAME = SUPORTE)
    )
   (SID_DESC =
  (GLOBAL_DBNAME = PRODUCAO)
  (ORACLE_HOME = /u01/app/oracle/product/11.2.0.4/dbhome_1)
  (SID_NAME = PRODUCAO)
    )
 )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
  (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
  (ADDRESS = (PROTOCOL = TCP)(HOST = hostname.xxx.gov.br)(PORT = 1521))
    )
  )

ADR_BASE_LISTENER = /u01/app/oracle


Alguém poderia ajudar a sanar este problema?

Re: [oracle_br] Re: Licenciamento Oracle

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado pelas explicações mestre!!!
:)
 

Em Terça-feira, 23 de Agosto de 2016 15:33, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Opa, seguinte : começando pelo DG físico, é Conceitual que para um 
Dataguard "normal", não-active é exigido para que a base-réplica possa ser 
Atualizada que  ela ** TEM ** que estar em MOUNT, ie, aberta em modo 
mono-usuário, digamos assim, - portanto, ela vai estar INDISPONÍVEL até para 
consultas por parte dos usuários finais e suas aplicações 
 É verdade, vc está 100% correto ao indicar que até se pode abrir o 
banco-réplica em read-only e o disponibilizar para os usuários finais mas para 
isso OBRIGATORIAMENTE vc tem que "pausar" / interromper temporariamente o 
processo de recebimento, E no instante que vc faz isso ele ** DEIXA ** de ser 
um banco-standby, ele não está mais sendo atualizado O que vai acontecer 
nesse cenário é que o banco PROD obviamente vai continuar gerando e gerando 
mais e mais archives E o banco que antigamente era standby não está recebendo 
esses archives - EVIDENTEMENTE, esse GAP vai crescendo (às vezes rapidamente, 
dependendo de quanto é Ativo teu banco PROD, não é difícil que, se essa 'pausa' 
de Atualização for longa, o gap, o "buraco", o passivo de archives fique tão 
grande que depois de vc 'reativar' o dataguard seja preciso um tempo enorme de 
grande pro servidor réplica receber e processar esses archives passados 
Junte isso com um ambiente PROD que é intensamente ativo tipo 24 horas por dia 
e vc acabou de cair no que se chama de RACE CONDITION : vc tinha, digamos, 500 
archives pra enviar e aplicar no standby, no tempão que levou pra os transmitir 
pela rede (ou voltar um backup com eles - isso é POSSÌVEL TAMBÉM !!) e os 
aplicar PROD já gerou outros 500, que vc tenha aplicar aí PROD já gerou nesse 
intervalo outros tantos Ninguém ganha essa corrida não - só mesmo se o 
volume da sua base é mediano, e/ou se vc tem uma Produção que só gera archives 
intensamente durante algumas horas de pico do dia (digamos) é que é Viável se 
interromper o standby por longos períodos para que ele possa ser aberto 
(read-only, que seja) - num caso assim, em tese vc teria as horas da Noite pra 
eliminar esse gap, receber e aplicar os archives faltantes todos...
 Nem preciso dizer que :
 
 a) ULULANTEMENTE ÓBVIO, no que vc interrompe a sincronização, não só vc está 
gerando um gap de archives mas TAMBÉM necessariamente vc tá com dados 
DESATUALIZADOS - nem preciso dizer que em muitas situações isso é Inaceitável
 
 e
 
 b) Óbvio #2, afora a possibilidade de backup com remoção, os archives não 
enviados/aplicados AINDA TEM QUE PERMANECER no ambiente PROD, e isso  VAI 
*** consumir espaço em disco, é claro, Além de criar uma demanda dessesperada 
por BANDA DE REDE na hora que vc os for enviar - teu hardware ** tem ** que 
Suportar se vc for pensar nisso...
 
   Tá claro ? Então sim, a sua frase :
  
" A diferença que vejo da option Active DAtaguard eh que voce *SEMPRE* tera seu 
standby sincronizado com o servidor primario, mesmo que ele esteja aberto para 
a utilização dos usuarios em modo ready-only."

Está perfeita, é isso mesmo, a Documentação Oracle mesmo nos diz :

" Opening a Physical Standby Database

A physical standby database can be opened for read-only access and used to 
offload queries from a primary database.

If a license for the Oracle Active Data Guard option has been purchased, a 
physical standby database can be open while redo apply is active. This 
capability is known as real-time query. See Section 9.2.1 for more details.

If a license for the Oracle Active Data Guard option has not been purchased, a 
physical standby database cannot be open while redo apply is active, so the 
following rules must be observed when opening a physical standby database 
instance or starting redo apply:

    Redo apply must be stopped before any physical standby database instance is 
opened.

    If one or more physical standby instances are open, those instances must be 
closed before starting redo apply.
"

 okdoc ? Espero que tenha ficado CLARO a importância de vc ter um banco aberto 
sem interromper a sincronização num caso de PROD extremamente ativo - eu já 
estive em algumas situações de RACE CONDITION, onde o gap/intervalo de archives 
a transmitir+aplicar era grande e PROD era intensamente ativo, acredite que NÃO 
É uma situação confortável...

Agora respondendo sobre o Dataguard Lógico/Logical Standby : o Conceito básico 
desse cara é (vide DOcumentação e http://www.orafaq.com/node/957 como refs) é 
que os SQLs gerados / executados em PROD são ENVIADOS e RE-EXECUTADOS no banco 
standby - Obviamente, para que um banco possa processar SQLs em tabelas 
não-internas do RDBMS ele ** TEM ** que estar Aberto, sim ?? Isso é 
conceitual...
 Então SIM, é verdade que um banco standby lógico pode ser em tese consultado 
(modo READ ONLY, óbvio) por usuários finais, sim Qual é o senão, o 

Re: [oracle_br] Re: Licenciamento Oracle

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Chiappa, aproveitando a thread do amigo sobre DATAGUARD, gostaria que, se 
possível, você fosse um pouco mais claro quando vc fala, o seguinte:

"A Justificativa para se adotar um Active Data Guard é, portanto,  DIMINUIR o 
overhead sobre a máquina Produção : ao permitir que o banco standby fique 
acessível aos usuários finais, nós podemos por exemplo rodar lá no standby 
aqueles Relatórios gerenciais pesados, digamos, POUPANDO assim recursos em Prod 
e ao mesmo tempo pondo para utilização prática um hardware standby, que com o 
Dataguard normal OU com um standby manual ficaria inacessível aos usuários 
finais"

-- Pelo pouco que sei, confere a minha análise abaixo? Poderia tirar essa 
dúvida?

a. Somente com o dataguard (sem o uso da option ACTIVE DATAGUARD) você também 
pode colocar o seu database em modo ready-only, portanto seu database ficará 
acessível aos usuarios para rodarem os relatorios pesados, porém a aplicação de 
archives **para**, o standby continua recebendo as informações do primário e 
archiva todos, mas não o aplica, estou correto?

b. Uma outra coisa do DATAGUARD (sem o ADG) voce tem a opção de colocar o 
database como snapshot standby (caso o DG seja fisico, me parece que no 12C o 
logico tb pode se colocar como sapshot) e deixar que os desenvolvedores caso 
precisem de uma cópia da produção para resolver um problema urgente d na 
aplicação voce tambem o pode fazer.
c. A diferença que vejo da option Active DAtaguard eh que voce *SEMPRE* tera 
seu standby sincronizado com o servidor primario, mesmo que ele esteja aberto 
para a utilização dos usuarios em modo ready-only. E mais uma coisa, com o 
active dataguard você tambem pode fazer o backup no standby ao inves do primary 
amenizando o uso de CPU.


d. Recentemente eu li um artigo a respeito do DG **lógico**, lá dizia que o 
standby pode estar aberto para uso dos usuarios ready-only enquanto as mudanças 
são aplicadas, ou seja, como se fosse um active dataguard, isso confere?










  

Em Terça-feira, 16 de Agosto de 2016 18:19, "Bezaleel Ramos 
bezars...@gmail.com [oracle_br]"  escreveu:
 

     Só nas "gambi" 




Bezaleel Ramos da SilvaTel. (21)  97996-1531LPIC-1 Junior Level Linux 
Certification
LPIC-2 Advanced Level Linux Certification
ZABBIX Certified Specialist
ZABBIX for Large Environments1Z0-051 Oracle Database 11g: SQL Fundamentals I


Em 13 de junho de 2016 08:54, alexssandro0...@yahoo.com.br [oracle_br] 
 escreveu:

     Bom dia !
Pessoal, obrigado pela dica, já conversei com o meu colega aqui. Como a base 
dele é pequena, ele vai fazer um dump para uma base nova.
Obrigado a todos.   

  #yiv3634476682 #yiv3634476682 -- #yiv3634476682ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3634476682 
#yiv3634476682ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3634476682 
#yiv3634476682ygrp-mkp #yiv3634476682hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv3634476682 #yiv3634476682ygrp-mkp #yiv3634476682ads 
{margin-bottom:10px;}#yiv3634476682 #yiv3634476682ygrp-mkp .yiv3634476682ad 
{padding:0 0;}#yiv3634476682 #yiv3634476682ygrp-mkp .yiv3634476682ad p 
{margin:0;}#yiv3634476682 #yiv3634476682ygrp-mkp .yiv3634476682ad a 
{color:#ff;text-decoration:none;}#yiv3634476682 #yiv3634476682ygrp-sponsor 
#yiv3634476682ygrp-lc {font-family:Arial;}#yiv3634476682 
#yiv3634476682ygrp-sponsor #yiv3634476682ygrp-lc #yiv3634476682hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3634476682 
#yiv3634476682ygrp-sponsor #yiv3634476682ygrp-lc .yiv3634476682ad 
{margin-bottom:10px;padding:0 0;}#yiv3634476682 #yiv3634476682actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3634476682 
#yiv3634476682activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3634476682
 #yiv3634476682activity span {font-weight:700;}#yiv3634476682 
#yiv3634476682activity span:first-child 
{text-transform:uppercase;}#yiv3634476682 #yiv3634476682activity span a 
{color:#5085b6;text-decoration:none;}#yiv3634476682 #yiv3634476682activity span 
span {color:#ff7900;}#yiv3634476682 #yiv3634476682activity span 
.yiv3634476682underline {text-decoration:underline;}#yiv3634476682 
.yiv3634476682attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv3634476682 .yiv3634476682attach div a 
{text-decoration:none;}#yiv3634476682 .yiv3634476682attach img 
{border:none;padding-right:5px;}#yiv3634476682 .yiv3634476682attach label 
{display:block;margin-bottom:5px;}#yiv3634476682 .yiv3634476682attach label a 
{text-decoration:none;}#yiv3634476682 blockquote {margin:0 0 0 
4px;}#yiv3634476682 .yiv3634476682bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3634476682 
.yiv3634476682bold a {text-decoration:none;}#yiv3634476682 dd.yiv3634476682last 
p a {font-family:Verdana;font-weight:700;}#yiv3634476682 

Re: [oracle_br] Sessão muito tempo ativa

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Exato Chiappa, era realmente um BUG, o desenvolvedor da Oracle estava criando 
um one off patch para o meu problema e terminou exatamente ontem, segue 
p18077682_11204160419_AIX64-5L.zip  

Em Sexta-feira, 5 de Agosto de 2016 22:58, "Rodrigo Mufalani 
rodr...@mufalani.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Boa tarde,
    Last_call_et mostra a ultima vez em que ela fez uma chamada sql, qual o 
status da sessão? Vocé também pode usar um trace do S.O para verificar, veja o 
similar do strace pra AIX.  
Get Outlook for iOS



On Thu, Aug 4, 2016 at 11:47 AM -0300, "Rafael Mendonca raffaell.t...@yahoo.com 
[oracle_br]"<oracle_br@yahoogrupos.com.br> wrote:

 Oracle 11.2.0.4.16 - AIX 64 bits
Verificando as sessões ativas do meu database, verifiquei que existem duas 
sessões do usuário "SYS" executando a mais de 15 horas.

SID,SERIAL = '2851,1421'SPID = 34144422   
USERNAME  = SYS
OSUSER = oracle   
SERVER = DEDICATED 
PROGRAM = oracle@hostname(O002) 
MACHINE = hostnameLAS_CALL_ET = 56282

Essa acima é uma delas...
Consultei a v$sql junto com a v$session e nada é mostrado, portanto, joguei um 
trace na sessão usando o oradebug event 10046 trace name context forever, level 
12;

Após 30 minutos nada é mostrado no trace:


Trace file: 
/u01/app/oracle/diag/rdbms/instancia/INSTANCIA/trace/INSTANCIA_o002_34144422.trc
Sort options: default


count    = number of times OCI procedure was executed
cpu  = cpu time in seconds executing 
elapsed  = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call

Trace file: 
/u01/app/oracle/diag/rdbms/instancia/INSTANCIA/trace/INSTANCIA_o002_34144422.trc
Trace file compatibility: 11.1.0.7
Sort options: default

   1  session in tracefile.
   0  user  SQL statements in trace file.
   0  internal SQL statements in trace file.
   0  SQL statements in trace file.
   0  unique SQL statements in trace file.
    1059  lines in trace file.
   0  elapsed seconds in trace file.


Gostaria de saber o motivo dessa sessão está tanto tempo ativa e o que está 
rodando, pois não consegui identificar, não sei se é viável matar a sessão ou 
não.

Poderiam ajudar?


  #yiv7013278807 #yiv7013278807 -- #yiv7013278807ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7013278807 
#yiv7013278807ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7013278807 
#yiv7013278807ygrp-mkp #yiv7013278807hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7013278807 #yiv7013278807ygrp-mkp #yiv7013278807ads 
{margin-bottom:10px;}#yiv7013278807 #yiv7013278807ygrp-mkp .yiv7013278807ad 
{padding:0 0;}#yiv7013278807 #yiv7013278807ygrp-mkp .yiv7013278807ad p 
{margin:0;}#yiv7013278807 #yiv7013278807ygrp-mkp .yiv7013278807ad a 
{color:#ff;text-decoration:none;}#yiv7013278807 #yiv7013278807ygrp-sponsor 
#yiv7013278807ygrp-lc {font-family:Arial;}#yiv7013278807 
#yiv7013278807ygrp-sponsor #yiv7013278807ygrp-lc #yiv7013278807hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7013278807 
#yiv7013278807ygrp-sponsor #yiv7013278807ygrp-lc .yiv7013278807ad 
{margin-bottom:10px;padding:0 0;}#yiv7013278807 #yiv7013278807actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7013278807 
#yiv7013278807activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7013278807
 #yiv7013278807activity span {font-weight:700;}#yiv7013278807 
#yiv7013278807activity span:first-child 
{text-transform:uppercase;}#yiv7013278807 #yiv7013278807activity span a 
{color:#5085b6;text-decoration:none;}#yiv7013278807 #yiv7013278807activity span 
span {color:#ff7900;}#yiv7013278807 #yiv7013278807activity span 
.yiv7013278807underline {text-decoration:underline;}#yiv7013278807 
.yiv7013278807attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv7013278807 .yiv7013278807attach div a 
{text-decoration:none;}#yiv7013278807 .yiv7013278807attach img 
{border:none;padding-right:5px;}#yiv7013278807 .yiv7013278807attach label 
{display:block;margin-bottom:5px;}#yiv7013278807 .yiv7013278807attach label a 
{text-decoration:none;}#yiv7013278807 blockquote {margin:0 0 0 
4px;}#yiv7013278807 .yiv7013278807bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv7013278807 
.yiv7013278807bold a {text-decoration:none;}#yiv7013278807 dd.yiv7013278807last 
p a {font-family:Verdana;font-weight:700;}#yiv7013278807 dd.yiv7013278807last p 
span {margin-righ

Re: [oracle_br] Re: Cursor: pin S wait on X - Apó s migração para novo ambiente

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Chiappa, tenho que confessar que sou seu fã.:)
 

Em Terça-feira, 9 de Agosto de 2016 13:54, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Tudo jóia ? Bom, vc não diz mas eu vou ** SUPOR ** aqui que vc tem provas 
Diretas que esse wait é problemático no seu ambinete , ie, vc mediu NÂO SÓ UMA 
VEZ mas Múltiplas vezes no seu ambiente, usando intervalos de coleta ** CURTOS 
** (talvez 15 minutos entre cada coleta, ou até pouco menos), e esse wait tava 
sempre entre os TOPs e ** SEMPRE ** o percentual dele em relação à lista toda 
de waits era significativo, ie, tava sempre acima dos 20 e tantos percento, ou 
coisa assim, ** E ** as suas medições consecutivas SEMPRE mostram que a qtdade 
desses WAITs tem sempre aumentado entre as medições Medir só uma vez, ou 
medir com um intervalor de HORAS e HORAS entre as coletas  OBVIAMENTE não prova 
Coisa Alguma, né??? Igualmente, desconhecer que as estatísticas de wait são 
CUMULATIVAS pode te levar a engano, vc vê um número lá grande enorme, se não 
ver que a DIFERENÇA entre as coletas tá crescendo vc não sabe dizer se esse 
"acumulado" tão grande é algo ocorrendo no momento ou não...

Isso posto, vamos por partes aí : antes de tudo, para enterder o problema, veja 
na nota metalink 'Resolving Issues of "Library Cache Pin" or "Cursor Pin S wait 
on X"' (Doc ID 1476663.1) que esse evento mostra o resultado dos mecanismos de 
proteção ao acesso concorrente às estruturas do library cache/cache de SQLs, 
então NÂO, por princípio NÂO TEM A VER com alterações de tabelas, estamos 
falando de processamento de SQL aqui, então a sua resposta para  :

"...A principio, este evento só poderia ocorrer se a tabela sofresse alguma 
alteração em modo exclusivo correto ? ..."

é NÃO, essa suposição Não Está Correta PROVAVELMENTE vc se confundiu aí : 
esse modo "exclusivo" (X) do evento indica que o LATCH está sendo usado em modo 
exclusivo, e NÂO A TABELA, ok ?? Via de regra, para que alguém use um latch 
relacionado a Cursor em modo eXclusivo, isso indica que por qquer motivo OU o 
SQL em preparo para ser executado não pôde reusar a versão que estava no cache 
OU o SQL não existia/não foi encontrado no cache SQL, e não "tabela" okdoc 
??

 Adicionalmente, até podem haver Outros processamentos internos no database que 
causem isso - exemplo típico é o gerenciamento automático de memória, pois 
(obviamente) resize de memória potencialmente IMPLICA/PODE IMPLICAR em resize 
de TODAs as estruturas que residem em memória, o que inclui o cache de 
SQLs/library cache , como indicado na nota metalink "High 'Cursor: Pin S Wait 
On X', 'Library Cache Lock' And "Latch: Shared Pool" Waits due to Shared 
Pool/Buffer Cache Resize Activity" (Doc ID 742599.1)... SERÁ que não pode ser 
algo nesse estilo a sua issue ?? Talvez...
  A mesma nota indica que até houveram alguns bugs que causavam aumento em 
processamento interno/resize de memória sob AMM mas em tese eles já deveriam 
ter sido corrigidos : ok, o software do Exadata não segue ao pé de letra o 
mesmo agendamento de patches mas bugs tão antigos quanto os indicados na nota 
em questão já corrigidos no RDBMS já deveriam ter sido portados/corrigidos no 
software Exadata há muito Confira no Suporte Oracle mas não tem muita 
chance de ser isso, não... Falando em Ações com o Suporte Oracle, o que vc 
deveria checar são casos mais próximos, como os das notas "High Waits On 
'cursor: pin S wait on X' Or 'library cache lock' When Remote Functions Are 
Called" (Doc ID 1146428.1) e "Cursor Pin S Wait On X High During Select With 
Parallel" (Doc ID 1915053.1)...

==> EM PARALELO, enquanto vc checa essas possibilidades internas (digamos 
assim), vc ** VAI ** levantar e descobrir QUEM está causando o wait, ie, QUEM 
está segurando o latch por muito mais tempo do que devia... Note que eu estou 
apontando uma ANOMALIA : um SQL que está sendo re-executado PELO CACHE, 
bonitinho, sem PARSES, sem ESTRUTURAS físicas (como colunas) e/ou estruturas 
lógicas (como CONSTRAINTs) sendo frequementemente alteradas, deveria obter e 
liberar esse latch em microsegundos, coisa EXTREMAMENTE Rápida  - assim mesmo 
que hajam " milhares de consultas" às tais tabelas que vc identificou serem 
muito acessadas, SE ESSES SQLs TODOS estivessem sendo reusados via cache, sem 
parse, E sem gerenciamento do cache (ie, não há LEAKING de cursores que forcem 
o RDBMS a ficar limpando entradas no array de cursores, digamos), vc 
ABSOLUTAMENTE NÂO DEVERIA ver esperas Significativas por esse evento
 Para vc LEVANTAR quem está usando e abusando tanto desse latch, siga os 
procedimentos da nota "How to Determine the Blocking Session for Event: 
'cursor: pin S wait on X' " (Doc ID 786507.1) - basicamente consultar na 
V$SESSION (GV$SESSION no seu caso já que vc está em RAC) pelas colunas de 
P1/P2/P3 quem é o "bloqueador" (não gosto de falar em bloqueador/bloqueado 
quando discutimos LATCH, tecnicamente isso não é correto mas enfim) 

Re: [oracle_br] Re: Refresh materialized view

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado mais uma vez Chiappa. 
irei seguir as recomendações e qualquer retorno passo as informações por aqui
:) 

Em Segunda-feira, 8 de Agosto de 2016 13:32, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Oi : o "artigo do Tom Kyte" a que vc se refere é o 
https://asktom.oracle.com/pls/asktom/f%3Fp%3D100:11:0P11_QUESTION_ID:4399099500346197085
 , correto ? Esse artigo mostra que (como também Documentado na nota metalink 
"Materialized View Refresh is Hanging With JI Contention" (Doc ID 1358453.1) , 
esse enqueue JI é o enqueue que serializa o refresh/recriação de uma view 
materializada - NÂO HÁ 'problema' algum por parte do RDBMS em princípio, é uma 
questão de concorrência, em tese... Esse enqueue  tanto pode aparecer em 
situações onde duas sessões estão tentando fazer o refresh simultaneamente 
(https://dbhk.wordpress.com/2009/12/08/refresh-materialized-view-hung/ 
exemplifica) quanto em situações onde há uma OUTRA sessão fora a do refresh 
fazendo ALTERAÇÂO DE ESTRUTURA na view e/ou na(s) tabela(s) que a compõem , Ou 
está havendo algum aceso interno aos dados (por exemplo Replicações cfrme 
http://www.orafaq.com/forum/t/127829/) nas tabelas OU mesmo há SQLs recursivos 
(como por exemplo os derivados de CONSTRAINTS) que ainda estão rolando e 
segurando o refresh 
(http://rwijk.blogspot.com.br/2010/01/enq-ji-contention.html dá um exemplo)... 
Até houveram BUGs sobre isso, como o     Deadlock On Commit Materialized View 
(Doc ID 1312379.1) mas isso há muuuito tempo lá na época do 10g, certamente não 
deve ser nada disso... 
 A minha Recomendação é dupla :
 
 a) abra um Chamado no Suporte apenas pára estar certo de que não há re-raise 
desses bugs antigos, a chance é pequena mas faça de qquer maneira
 
 e
 
 b) tenha ** CERTEZA ** de que não está havendo múltiplas ocorrências de 
REFRESH - como vc diz que é REFRESH ON DEMAND e NÂO VEJO vc indicar START nem 
nada assim eu ** IMAGINO ** que está por sua conta os refreshs bem como o 
Controle das sessões que o fazem

e

 c)  INVESTIGUE as Atividades de banco envolvidas (tanto no banco local quanto 
no banco remoto que o @databaselink COM CERTEZA indica, embora vc não nos diga 
isso claramente) : isso vai envolver desde consulta aos Locks e Transações 
ativas (vide os scripts indicados na nota metalink inicialmente citada), 
monitoração das views de WAITs, eventual TRACE, é por aí
 
 []s
 
   Chiappa  #yiv3505003201 #yiv3505003201 -- #yiv3505003201ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3505003201 
#yiv3505003201ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3505003201 
#yiv3505003201ygrp-mkp #yiv3505003201hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv3505003201 #yiv3505003201ygrp-mkp #yiv3505003201ads 
{margin-bottom:10px;}#yiv3505003201 #yiv3505003201ygrp-mkp .yiv3505003201ad 
{padding:0 0;}#yiv3505003201 #yiv3505003201ygrp-mkp .yiv3505003201ad p 
{margin:0;}#yiv3505003201 #yiv3505003201ygrp-mkp .yiv3505003201ad a 
{color:#ff;text-decoration:none;}#yiv3505003201 #yiv3505003201ygrp-sponsor 
#yiv3505003201ygrp-lc {font-family:Arial;}#yiv3505003201 
#yiv3505003201ygrp-sponsor #yiv3505003201ygrp-lc #yiv3505003201hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3505003201 
#yiv3505003201ygrp-sponsor #yiv3505003201ygrp-lc .yiv3505003201ad 
{margin-bottom:10px;padding:0 0;}#yiv3505003201 #yiv3505003201actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3505003201 
#yiv3505003201activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3505003201
 #yiv3505003201activity span {font-weight:700;}#yiv3505003201 
#yiv3505003201activity span:first-child 
{text-transform:uppercase;}#yiv3505003201 #yiv3505003201activity span a 
{color:#5085b6;text-decoration:none;}#yiv3505003201 #yiv3505003201activity span 
span {color:#ff7900;}#yiv3505003201 #yiv3505003201activity span 
.yiv3505003201underline {text-decoration:underline;}#yiv3505003201 
.yiv3505003201attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv3505003201 .yiv3505003201attach div a 
{text-decoration:none;}#yiv3505003201 .yiv3505003201attach img 
{border:none;padding-right:5px;}#yiv3505003201 .yiv3505003201attach label 
{display:block;margin-bottom:5px;}#yiv3505003201 .yiv3505003201attach label a 
{text-decoration:none;}#yiv3505003201 blockquote {margin:0 0 0 
4px;}#yiv3505003201 .yiv3505003201bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3505003201 
.yiv3505003201bold a {text-decoration:none;}#yiv3505003201 dd.yiv3505003201last 
p a {font-family:Verdana;font-weight:700;}#yiv3505003201 dd.yiv3505003201last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3505003201 
dd.yiv3505003201last p span.yiv3505003201yshortcuts 
{margin-right:0;}#yiv3505003201 div.yiv3505003201attach-table div div a 

[oracle_br] Refresh materialized view

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Oracle 11.2.0.4.16 AIX 64 bits
Senhores, estou com um problema em uma determinada MV. Quando tento realizar o 
refresh ela fica travada e não termina. Abrindo uma outra sessão verifiquei a 
v$session_wait e identifiquei que o evento em espera em relação a execução do 
refresh da view é a **enq: JI - contention**
Dando um googlada, verifiquei alguns artigos, inclusive o do Tom Kyte, mas 
sendo sincero, eu não entendi muito bem o porque do problema e como faço para 
solucionar esse problema.
Gostaria que os amigos, se pudessem ajudar, me dessem uma força nessa tarefa.
CREATE MATERIALIZED VIEW "OWNER_XUXA"."TABELA_XUXA" ("XXX", "XXX")
  ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 
 NOCOMPRESS LOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "TBS_XUXA" 
  BUILD IMMEDIATE
  USING INDEX 
  REFRESH FAST ON DEMAND
  WITH PRIMARY KEY USING DEFAULT LOCAL ROLLBACK SEGMENT
  USING ENFORCED CONSTRAINTS DISABLE QUERY REWRITE
  AS SELECT "COL1"."COL2" "COL3","COL4" FROM "XUXA"."RH_TIPO_PENSAO"@DATABASE 
"TABELA";

  
OBS: Eu rodo a consulta da MV normalmente por fora.

Re: [oracle_br] Re: Sessão muito tempo ativa

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Pode deixar Chiappa. Obrigado mais uma vez.
 

Em Quinta-feira, 4 de Agosto de 2016 13:40, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Não é impossível não : plz ** ALERTE ** teu Analista de Suporte dessa 
ocorrência (indicando Inclusive a nota pra ele, E fazendo as consultas na 
(g)V$session/(g)v$sesstats na Nota), confirme com ele a 
conveniência/necessidade de aplicar o patch one/off indicado na nota e o 
aplique o quanto antes, na sua próxima janela de manutenção...

 []s
 
   Chiappa  #yiv8350209974 #yiv8350209974 -- #yiv8350209974ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8350209974 
#yiv8350209974ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8350209974 
#yiv8350209974ygrp-mkp #yiv8350209974hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8350209974 #yiv8350209974ygrp-mkp #yiv8350209974ads 
{margin-bottom:10px;}#yiv8350209974 #yiv8350209974ygrp-mkp .yiv8350209974ad 
{padding:0 0;}#yiv8350209974 #yiv8350209974ygrp-mkp .yiv8350209974ad p 
{margin:0;}#yiv8350209974 #yiv8350209974ygrp-mkp .yiv8350209974ad a 
{color:#ff;text-decoration:none;}#yiv8350209974 #yiv8350209974ygrp-sponsor 
#yiv8350209974ygrp-lc {font-family:Arial;}#yiv8350209974 
#yiv8350209974ygrp-sponsor #yiv8350209974ygrp-lc #yiv8350209974hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8350209974 
#yiv8350209974ygrp-sponsor #yiv8350209974ygrp-lc .yiv8350209974ad 
{margin-bottom:10px;padding:0 0;}#yiv8350209974 #yiv8350209974actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8350209974 
#yiv8350209974activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8350209974
 #yiv8350209974activity span {font-weight:700;}#yiv8350209974 
#yiv8350209974activity span:first-child 
{text-transform:uppercase;}#yiv8350209974 #yiv8350209974activity span a 
{color:#5085b6;text-decoration:none;}#yiv8350209974 #yiv8350209974activity span 
span {color:#ff7900;}#yiv8350209974 #yiv8350209974activity span 
.yiv8350209974underline {text-decoration:underline;}#yiv8350209974 
.yiv8350209974attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv8350209974 .yiv8350209974attach div a 
{text-decoration:none;}#yiv8350209974 .yiv8350209974attach img 
{border:none;padding-right:5px;}#yiv8350209974 .yiv8350209974attach label 
{display:block;margin-bottom:5px;}#yiv8350209974 .yiv8350209974attach label a 
{text-decoration:none;}#yiv8350209974 blockquote {margin:0 0 0 
4px;}#yiv8350209974 .yiv8350209974bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8350209974 
.yiv8350209974bold a {text-decoration:none;}#yiv8350209974 dd.yiv8350209974last 
p a {font-family:Verdana;font-weight:700;}#yiv8350209974 dd.yiv8350209974last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8350209974 
dd.yiv8350209974last p span.yiv8350209974yshortcuts 
{margin-right:0;}#yiv8350209974 div.yiv8350209974attach-table div div a 
{text-decoration:none;}#yiv8350209974 div.yiv8350209974attach-table 
{width:400px;}#yiv8350209974 div.yiv8350209974file-title a, #yiv8350209974 
div.yiv8350209974file-title a:active, #yiv8350209974 
div.yiv8350209974file-title a:hover, #yiv8350209974 div.yiv8350209974file-title 
a:visited {text-decoration:none;}#yiv8350209974 div.yiv8350209974photo-title a, 
#yiv8350209974 div.yiv8350209974photo-title a:active, #yiv8350209974 
div.yiv8350209974photo-title a:hover, #yiv8350209974 
div.yiv8350209974photo-title a:visited {text-decoration:none;}#yiv8350209974 
div#yiv8350209974ygrp-mlmsg #yiv8350209974ygrp-msg p a 
span.yiv8350209974yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8350209974 
.yiv8350209974green {color:#628c2a;}#yiv8350209974 .yiv8350209974MsoNormal 
{margin:0 0 0 0;}#yiv8350209974 o {font-size:0;}#yiv8350209974 
#yiv8350209974photos div {float:left;width:72px;}#yiv8350209974 
#yiv8350209974photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv8350209974 
#yiv8350209974photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv8350209974
 #yiv8350209974reco-category {font-size:77%;}#yiv8350209974 
#yiv8350209974reco-desc {font-size:77%;}#yiv8350209974 .yiv8350209974replbq 
{margin:4px;}#yiv8350209974 #yiv8350209974ygrp-actbar div a:first-child 
{margin-right:2px;padding-right:5px;}#yiv8350209974 #yiv8350209974ygrp-mlmsg 
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv8350209974 
#yiv8350209974ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv8350209974 
#yiv8350209974ygrp-mlmsg select, #yiv8350209974 input, #yiv8350209974 textarea 
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv8350209974 
#yiv8350209974ygrp-mlmsg pre, #yiv8350209974 code {font:115% 
monospace;}#yiv8350209974 #yiv8350209974ygrp-mlmsg * 
{line-height:1.22em;}#yiv8350209974 

Re: [oracle_br] Re: Sessão muito tempo ativa

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado mestre Rosivaldo :)
Chiappa, será que esse problema na PGA tem alguma tipo de relação com o tópico 
anterior que postei?Estou tomando muito erro ORA-4030 logo depois que atualizei 
para a versão 11.2.0.4.16.
Abri chamado com o suporte da Oracle desde segunda-feira e até agora nada de 
solução. 

Em Quinta-feira, 4 de Agosto de 2016 13:22, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Vide nota metalink "Onnn (ASM Connection Pool Processes) Present Memory 
Leaks Over The Time In 11.2.0.X.0 or 12.1.0.1 RAC/Standalone Database 
Instances" (Doc ID 1639119.1) : basicamente esse cara é um processo interno 
(óbvio, seja pela conexão com SYS seja pelo (xxx) no program name) - conexão 
ASM, no caso -, que zumbificou por memory leak de PGA... Vc provavelmente até o 
pode matar se for o caso mas ** APLIQUE ** o patch indicado, senão ele VAI 
VOLTAR a aparecer

  []s
  
    Chiappa  #yiv0359606233 #yiv0359606233 -- #yiv0359606233ygrp-mkp 
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 
10px;}#yiv0359606233 #yiv0359606233ygrp-mkp hr {border:1px solid 
#d8d8d8;}#yiv0359606233 #yiv0359606233ygrp-mkp #yiv0359606233hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv0359606233 #yiv0359606233ygrp-mkp #yiv0359606233ads 
{margin-bottom:10px;}#yiv0359606233 #yiv0359606233ygrp-mkp .yiv0359606233ad 
{padding:0 0;}#yiv0359606233 #yiv0359606233ygrp-mkp .yiv0359606233ad p 
{margin:0;}#yiv0359606233 #yiv0359606233ygrp-mkp .yiv0359606233ad a 
{color:#ff;text-decoration:none;}#yiv0359606233 #yiv0359606233ygrp-sponsor 
#yiv0359606233ygrp-lc {font-family:Arial;}#yiv0359606233 
#yiv0359606233ygrp-sponsor #yiv0359606233ygrp-lc #yiv0359606233hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0359606233 
#yiv0359606233ygrp-sponsor #yiv0359606233ygrp-lc .yiv0359606233ad 
{margin-bottom:10px;padding:0 0;}#yiv0359606233 #yiv0359606233actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0359606233 
#yiv0359606233activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0359606233
 #yiv0359606233activity span {font-weight:700;}#yiv0359606233 
#yiv0359606233activity span:first-child 
{text-transform:uppercase;}#yiv0359606233 #yiv0359606233activity span a 
{color:#5085b6;text-decoration:none;}#yiv0359606233 #yiv0359606233activity span 
span {color:#ff7900;}#yiv0359606233 #yiv0359606233activity span 
.yiv0359606233underline {text-decoration:underline;}#yiv0359606233 
.yiv0359606233attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv0359606233 .yiv0359606233attach div a 
{text-decoration:none;}#yiv0359606233 .yiv0359606233attach img 
{border:none;padding-right:5px;}#yiv0359606233 .yiv0359606233attach label 
{display:block;margin-bottom:5px;}#yiv0359606233 .yiv0359606233attach label a 
{text-decoration:none;}#yiv0359606233 blockquote {margin:0 0 0 
4px;}#yiv0359606233 .yiv0359606233bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv0359606233 
.yiv0359606233bold a {text-decoration:none;}#yiv0359606233 dd.yiv0359606233last 
p a {font-family:Verdana;font-weight:700;}#yiv0359606233 dd.yiv0359606233last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0359606233 
dd.yiv0359606233last p span.yiv0359606233yshortcuts 
{margin-right:0;}#yiv0359606233 div.yiv0359606233attach-table div div a 
{text-decoration:none;}#yiv0359606233 div.yiv0359606233attach-table 
{width:400px;}#yiv0359606233 div.yiv0359606233file-title a, #yiv0359606233 
div.yiv0359606233file-title a:active, #yiv0359606233 
div.yiv0359606233file-title a:hover, #yiv0359606233 div.yiv0359606233file-title 
a:visited {text-decoration:none;}#yiv0359606233 div.yiv0359606233photo-title a, 
#yiv0359606233 div.yiv0359606233photo-title a:active, #yiv0359606233 
div.yiv0359606233photo-title a:hover, #yiv0359606233 
div.yiv0359606233photo-title a:visited {text-decoration:none;}#yiv0359606233 
div#yiv0359606233ygrp-mlmsg #yiv0359606233ygrp-msg p a 
span.yiv0359606233yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv0359606233 
.yiv0359606233green {color:#628c2a;}#yiv0359606233 .yiv0359606233MsoNormal 
{margin:0 0 0 0;}#yiv0359606233 o {font-size:0;}#yiv0359606233 
#yiv0359606233photos div {float:left;width:72px;}#yiv0359606233 
#yiv0359606233photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv0359606233 
#yiv0359606233photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv0359606233
 #yiv0359606233reco-category {font-size:77%;}#yiv0359606233 
#yiv0359606233reco-desc {font-size:77%;}#yiv0359606233 .yiv0359606233replbq 
{margin:4px;}#yiv0359606233 #yiv0359606233ygrp-actbar div a:first-child 
{margin-right:2px;padding-right:5px;}#yiv0359606233 #yiv0359606233ygrp-mlmsg 
{font-size:13px;font-family:Arial, helvetica, clean, 

[oracle_br] Sessão muito tempo ativa

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Oracle 11.2.0.4.16 - AIX 64 bits
Verificando as sessões ativas do meu database, verifiquei que existem duas 
sessões do usuário "SYS" executando a mais de 15 horas. 

SID,SERIAL = '2851,1421'SPID = 34144422   
USERNAME  = SYS 
OSUSER = oracle   
SERVER = DEDICATED 
PROGRAM = oracle@hostname(O002)  
MACHINE = hostnameLAS_CALL_ET = 56282

Essa acima é uma delas...
Consultei a v$sql junto com a v$session e nada é mostrado, portanto, joguei um 
trace na sessão usando o oradebug event 10046 trace name context forever, level 
12; 

Após 30 minutos nada é mostrado no trace:


Trace file: 
/u01/app/oracle/diag/rdbms/instancia/INSTANCIA/trace/INSTANCIA_o002_34144422.trc
Sort options: default


count    = number of times OCI procedure was executed
cpu  = cpu time in seconds executing 
elapsed  = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call

Trace file: 
/u01/app/oracle/diag/rdbms/instancia/INSTANCIA/trace/INSTANCIA_o002_34144422.trc
Trace file compatibility: 11.1.0.7
Sort options: default

   1  session in tracefile.
   0  user  SQL statements in trace file.
   0  internal SQL statements in trace file.
   0  SQL statements in trace file.
   0  unique SQL statements in trace file.
    1059  lines in trace file.
   0  elapsed seconds in trace file.


Gostaria de saber o motivo dessa sessão está tanto tempo ativa e o que está 
rodando, pois não consegui identificar, não sei se é viável matar a sessão ou 
não. 

Poderiam ajudar?

Re: [oracle_br] Problema em compilação

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Huge Pages é uma implementação já que está agendada. Já fizemos na homologação 
e o próximo passo será no banco de produção. :) 
 

Em Quarta-feira, 3 de Agosto de 2016 13:31, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Sobre o ORA-4030, realmente houveram situações onde o erro podia ser 
contornado via _realfree_heap_pagesize_hint (veja 
http://ksun-oracle.blogspot.com.br/2015/09/limit-pga-memory-usage.html , 
http://odbablogs.blogspot.com.br/2014/09/error-ora-04030-out-of-process-memory.html
 , 
http://manishnashikkar.blogspot.com.br/2013/02/solution-to-ora-04030-out-of-process.html
 e 
http://www.oracleracexpert.com/2014/11/ora-04030-out-of-process-memory-when.html
 para refs) , mas normalmente onde se vê isso é situação de Large SGA : vc já 
pensou sobre implentação de HUGE PAGES ? Muitas vezes quando se vê cpu sendo 
usada para gerenciamento de memória a gente pensa no Linux fazendo page steal / 
gerenciamento de memória, coisa que se o servidor é dedicado a RDBMS Oracle 
apenas e tão somente não há necessidade, é o caso onde pode ser viável huge 
pages...

[]s

  Chiappa  #yiv8998844042 #yiv8998844042 -- #yiv8998844042ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8998844042 
#yiv8998844042ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8998844042 
#yiv8998844042ygrp-mkp #yiv8998844042hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8998844042 #yiv8998844042ygrp-mkp #yiv8998844042ads 
{margin-bottom:10px;}#yiv8998844042 #yiv8998844042ygrp-mkp .yiv8998844042ad 
{padding:0 0;}#yiv8998844042 #yiv8998844042ygrp-mkp .yiv8998844042ad p 
{margin:0;}#yiv8998844042 #yiv8998844042ygrp-mkp .yiv8998844042ad a 
{color:#ff;text-decoration:none;}#yiv8998844042 #yiv8998844042ygrp-sponsor 
#yiv8998844042ygrp-lc {font-family:Arial;}#yiv8998844042 
#yiv8998844042ygrp-sponsor #yiv8998844042ygrp-lc #yiv8998844042hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8998844042 
#yiv8998844042ygrp-sponsor #yiv8998844042ygrp-lc .yiv8998844042ad 
{margin-bottom:10px;padding:0 0;}#yiv8998844042 #yiv8998844042actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8998844042 
#yiv8998844042activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8998844042
 #yiv8998844042activity span {font-weight:700;}#yiv8998844042 
#yiv8998844042activity span:first-child 
{text-transform:uppercase;}#yiv8998844042 #yiv8998844042activity span a 
{color:#5085b6;text-decoration:none;}#yiv8998844042 #yiv8998844042activity span 
span {color:#ff7900;}#yiv8998844042 #yiv8998844042activity span 
.yiv8998844042underline {text-decoration:underline;}#yiv8998844042 
.yiv8998844042attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv8998844042 .yiv8998844042attach div a 
{text-decoration:none;}#yiv8998844042 .yiv8998844042attach img 
{border:none;padding-right:5px;}#yiv8998844042 .yiv8998844042attach label 
{display:block;margin-bottom:5px;}#yiv8998844042 .yiv8998844042attach label a 
{text-decoration:none;}#yiv8998844042 blockquote {margin:0 0 0 
4px;}#yiv8998844042 .yiv8998844042bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8998844042 
.yiv8998844042bold a {text-decoration:none;}#yiv8998844042 dd.yiv8998844042last 
p a {font-family:Verdana;font-weight:700;}#yiv8998844042 dd.yiv8998844042last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8998844042 
dd.yiv8998844042last p span.yiv8998844042yshortcuts 
{margin-right:0;}#yiv8998844042 div.yiv8998844042attach-table div div a 
{text-decoration:none;}#yiv8998844042 div.yiv8998844042attach-table 
{width:400px;}#yiv8998844042 div.yiv8998844042file-title a, #yiv8998844042 
div.yiv8998844042file-title a:active, #yiv8998844042 
div.yiv8998844042file-title a:hover, #yiv8998844042 div.yiv8998844042file-title 
a:visited {text-decoration:none;}#yiv8998844042 div.yiv8998844042photo-title a, 
#yiv8998844042 div.yiv8998844042photo-title a:active, #yiv8998844042 
div.yiv8998844042photo-title a:hover, #yiv8998844042 
div.yiv8998844042photo-title a:visited {text-decoration:none;}#yiv8998844042 
div#yiv8998844042ygrp-mlmsg #yiv8998844042ygrp-msg p a 
span.yiv8998844042yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8998844042 
.yiv8998844042green {color:#628c2a;}#yiv8998844042 .yiv8998844042MsoNormal 
{margin:0 0 0 0;}#yiv8998844042 o {font-size:0;}#yiv8998844042 
#yiv8998844042photos div {float:left;width:72px;}#yiv8998844042 
#yiv8998844042photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv8998844042 
#yiv8998844042photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv8998844042
 #yiv8998844042reco-category {font-size:77%;}#yiv8998844042 
#yiv8998844042reco-desc {font-size:77%;}#yiv8998844042 .yiv8998844042replbq 

Re: [oracle_br] Problema em compilação

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado Chiappa e o Evandro, ajudaram bastante, bons argumentos/artigos para 
que esse trabalho não deixe de ser feito.Gostaria de acrescentar duas coisas:
1- Consegui convencer com que ele fizesse, pois chamei o seu gestor e simulei 
uma consulta com variável BIND e outra sem (no Oracle - PL-SQL). A diferença de 
tempo foi absurdamente grande.
2 - Obs:
Em paralelo a isso, tinha aberto um chamado com a Oracle, pois após atualizar o 
RDBMS e o grid para a versão 11.2.0.4.16 começou a aparecer na aplicação alguns 
erros 
**ORA-04030 (QERGH-hash-agg,kllcqas:kllsltba)**
Após enviar alert.log, trace files, check healthy report e muito mais, o 
engenheiro pediu para que o ulimit (stack, data) do usuário oracle no sistema 
operacional fosse modificado para "unlimited" e além disso, um parâmetro do 
database (_use_realfree_heap) fosse alterado para FALSE.
Após essa modificação, o erro continuou, **PORÉM** meu database ficou 
extremamente rápido, não tenho mais problema de desempenho (parse, cpu, elapsed 
execute sql), os eventos em espera diminuíram bastante, o DB TIME melhorou 90% 
e o gerente de TI quase me deu uma medalha por isso, confesso que fiquei 
assustado (tentei matar um elefante de um lado, e acabei matando um leão do 
outro).
Bem, isso não impede que o desenvolvedor mude a sua aplicação para o que foi 
solicitado (utilização da variável BIND), continuo na luta com o Oracle Suport 
para que esse erro ORA-04030 seja sanado.
Obrigado mais uma vez a vocês.







 

Em Quarta-feira, 3 de Agosto de 2016 10:12, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bem provável que tenha sido isso : INCLUSIVE, concatenação de strings abre 
ENORMES BRECHAS de segurança (por exemplo na questão de SQL INJECTION), então 
eu aconselho o colega que perguntou a bater nessa tecla de Segurança - via de 
regra Diretoria e Gerência não tão nem aí pra performance e estabilidade mas se 
pélam de medo dos "hackers" , então é fazer medo nisso (regra do DBA #2, 3 
regras do DBA - Savepoint 
||
||||   3 regras do DBA - Savepoint  Esse eu estou copiando 
do Database Cast sobre Disaster e Recovery (recomendo ouvir o episódio).  Bom, 
ei-las: 1ª O DBA deve educar o usuário||
|  Visualizar em savepoint.blog.br  |Visualização pelo Yahoo|
||

   ) ...

[]s

  Chiappa  #yiv9316245945 #yiv9316245945 -- #yiv9316245945ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9316245945 
#yiv9316245945ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9316245945 
#yiv9316245945ygrp-mkp #yiv9316245945hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9316245945 #yiv9316245945ygrp-mkp #yiv9316245945ads 
{margin-bottom:10px;}#yiv9316245945 #yiv9316245945ygrp-mkp .yiv9316245945ad 
{padding:0 0;}#yiv9316245945 #yiv9316245945ygrp-mkp .yiv9316245945ad p 
{margin:0;}#yiv9316245945 #yiv9316245945ygrp-mkp .yiv9316245945ad a 
{color:#ff;text-decoration:none;}#yiv9316245945 #yiv9316245945ygrp-sponsor 
#yiv9316245945ygrp-lc {font-family:Arial;}#yiv9316245945 
#yiv9316245945ygrp-sponsor #yiv9316245945ygrp-lc #yiv9316245945hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9316245945 
#yiv9316245945ygrp-sponsor #yiv9316245945ygrp-lc .yiv9316245945ad 
{margin-bottom:10px;padding:0 0;}#yiv9316245945 #yiv9316245945actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9316245945 
#yiv9316245945activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9316245945
 #yiv9316245945activity span {font-weight:700;}#yiv9316245945 
#yiv9316245945activity span:first-child 
{text-transform:uppercase;}#yiv9316245945 #yiv9316245945activity span a 
{color:#5085b6;text-decoration:none;}#yiv9316245945 #yiv9316245945activity span 
span {color:#ff7900;}#yiv9316245945 #yiv9316245945activity span 
.yiv9316245945underline {text-decoration:underline;}#yiv9316245945 
.yiv9316245945attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9316245945 .yiv9316245945attach div a 
{text-decoration:none;}#yiv9316245945 .yiv9316245945attach img 
{border:none;padding-right:5px;}#yiv9316245945 .yiv9316245945attach label 
{display:block;margin-bottom:5px;}#yiv9316245945 .yiv9316245945attach label a 
{text-decoration:none;}#yiv9316245945 blockquote {margin:0 0 0 
4px;}#yiv9316245945 .yiv9316245945bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9316245945 
.yiv9316245945bold a {text-decoration:none;}#yiv9316245945 dd.yiv9316245945last 
p a {font-family:Verdana;font-weight:700;}#yiv9316245945 dd.yiv9316245945last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9316245945 
dd.yiv9316245945last p span.yiv9316245945yshortcuts 
{margin-right:0;}#yiv9316245945 div.yiv9316245945attach-table div div a 
{text-decoration:none;}#yiv9316245945 div.yiv9316245945attach-table 

Re: [oracle_br] Problema em compilação

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Oracle 11.2.0.4.16 EE - standalone +ASM - AIX 64 bits


Senhores, boa tarde.
Há bastante tempo, o grande problema de desempenho de um dos databases de 
produção que cuido é de compilação, confirmei tal avaliação retirando vários 
relatórios AWR em pequenos intervalos e sempre horários de pico, também 
consultado diariamente as v$session_event, v$session_wait.
Semrpre os top waits são:
latch: row cache objectscursor: pin S wait on X

Verifiquei os principais agressores, consultando as consultas que não utilizam 
variáveis BIND com as consultas abaixo:
SELECT COUNT(SQL_TEXT), SUBSTR(SQL_TEXT,1,200) SUB_SQL_TEXT 
  FROM V$SQL 
HAVING (COUNT(SQL_TEXT) > 1000) 
GROUP BY SUBSTR(SQL_TEXT,1,200)   
ORDER BY 1;

  
SELECT   parsing_schema_name AS user_name, module,
 SUBSTR (sql_text, 1, 40) sql_text, COUNT (0) cnt,
 SUM (executions) executions
    FROM v$sqlarea
   WHERE executions < 5 AND kept_versions = 0
GROUP BY parsing_schema_name, module, SUBSTR (sql_text, 1, 40)
  HAVING COUNT (0) > 10
ORDER BY COUNT (0) DESC
/


Com a ajuda das consultas acima, mandei algumas consultas para os 
desenvolvedores deixarem de usarem variáveis literais, e passar a usar 
variáveis do tipo BIND.
O problema é que o desenvolvedor veio me falar que as consultas ficam na 
aplicação (JAVA) e que eles utilizam parâmetros, mas que esses parâmetros são 
carregados e que são enviados para o database já com as variáveis carregadas e 
que por isso, não teria como trocar por variáveis BIND.
Eu particularmente não entendo absolutamente NADA de JAVA. Achei o argumento do 
desenvolvedor muito fraco e sem muita segurança. Gostaria da opinião de vocês, 
como faço para convencer/ajudar o desenvolvedor a utilizar variáveis BIND na 
aplicação JAVA.

 

Em Terça-feira, 2 de Agosto de 2016 16:20, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Oracle 11.2.0.4.16 EE - standalone +ASM - AIX 64 bits


Senhores, boa tarde.
Há bastante tempo, o grande problema de desempenho de um dos databases de 
produção que cuido é de compilação, confirmei tal avaliação retirando vários 
relatórios AWR em pequenos intervalos e sempre horários de pico, também 
consultado diariamente as v$session_event, v$session_wait.
Semrpre os top waits são:

  #yiv4826885975 #yiv4826885975 -- #yiv4826885975ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4826885975 
#yiv4826885975ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4826885975 
#yiv4826885975ygrp-mkp #yiv4826885975hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4826885975 #yiv4826885975ygrp-mkp #yiv4826885975ads 
{margin-bottom:10px;}#yiv4826885975 #yiv4826885975ygrp-mkp .yiv4826885975ad 
{padding:0 0;}#yiv4826885975 #yiv4826885975ygrp-mkp .yiv4826885975ad p 
{margin:0;}#yiv4826885975 #yiv4826885975ygrp-mkp .yiv4826885975ad a 
{color:#ff;text-decoration:none;}#yiv4826885975 #yiv4826885975ygrp-sponsor 
#yiv4826885975ygrp-lc {font-family:Arial;}#yiv4826885975 
#yiv4826885975ygrp-sponsor #yiv4826885975ygrp-lc #yiv4826885975hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4826885975 
#yiv4826885975ygrp-sponsor #yiv4826885975ygrp-lc .yiv4826885975ad 
{margin-bottom:10px;padding:0 0;}#yiv4826885975 #yiv4826885975actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4826885975 
#yiv4826885975activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4826885975
 #yiv4826885975activity span {font-weight:700;}#yiv4826885975 
#yiv4826885975activity span:first-child 
{text-transform:uppercase;}#yiv4826885975 #yiv4826885975activity span a 
{color:#5085b6;text-decoration:none;}#yiv4826885975 #yiv4826885975activity span 
span {color:#ff7900;}#yiv4826885975 #yiv4826885975activity span 
.yiv4826885975underline {text-decoration:underline;}#yiv4826885975 
.yiv4826885975attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv4826885975 .yiv4826885975attach div a 
{text-decoration:none;}#yiv4826885975 .yiv4826885975attach img 
{border:none;padding-right:5px;}#yiv4826885975 .yiv4826885975attach label 
{display:block;margin-bottom:5px;}#yiv4826885975 .yiv4826885975attach label a 
{text-decoration:none;}#yiv4826885975 blockquote {margin:0 0 0 
4px;}#yiv4826885975 .yiv4826885975bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4826885975 
.yiv4826885975bold a {text-decoration:none;}#yiv4826885975 dd.yiv4826885975last 
p a {font-family:Verdana;font-weight:700;}#yiv4826885975 dd.yiv4826885975last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4826885975 
dd.yiv4826885975last p span.yiv4826885975yshortcuts 
{margin-right:0;}#yiv4826885975 div.yiv4826885975attach-table div div a 
{text-decoration:none;}#yiv4826885975 div.yiv4826885975attach-table 
{width:400px;}#yiv4826885975 div.yiv4826885975file-title a, #yiv4826885975 
di

[oracle_br] Problema em compilação

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Oracle 11.2.0.4.16 EE - standalone +ASM - AIX 64 bits


Senhores, boa tarde.
Há bastante tempo, o grande problema de desempenho de um dos databases de 
produção que cuido é de compilação, confirmei tal avaliação retirando vários 
relatórios AWR em pequenos intervalos e sempre horários de pico, também 
consultado diariamente as v$session_event, v$session_wait.
Semrpre os top waits são:

Re: [oracle_br] UPDATE SET ROW

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Chiappa o Tom Kyte brasileiro!!!
 

Em Quinta-feira, 14 de Julho de 2016 23:53, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Pessoal, estava fazendo um trabalhinho de programação em PL/SQL (mesmo 
mais atuando como DBA de vez em quando ainda faço esse tipo de 
Desenvolvimento), onde tinha que manipular um registro com muitos campos e 
acabei usando a feature acima, onde ao invés de indicar cada coluna vc só 
carrega uma variável ROWTYPE com os valores e manda o PL/SQL updatear todas as 
colunas contidas na ROWTYPE : fazia tanto tempo que não usava que tinha 
esquecido The Oracle PL/SQL ROW Keyword 
||
||||   The Oracle PL/SQL ROW Keyword  In Oracle PL/SQL, The 
keyword ROW is used in UPDATE statements to modify a complete record of a 
table. This feature was introduced in Oracle 9i||
|  Visualizar em psoug.org  |Visualização pelo Yahoo|
||

    tem um Exemplo...

Abraços,

  Chiappa

  #yiv9629370796 -- #yiv9629370796ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9629370796 
#yiv9629370796ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9629370796 
#yiv9629370796ygrp-mkp #yiv9629370796hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9629370796 #yiv9629370796ygrp-mkp #yiv9629370796ads 
{margin-bottom:10px;}#yiv9629370796 #yiv9629370796ygrp-mkp .yiv9629370796ad 
{padding:0 0;}#yiv9629370796 #yiv9629370796ygrp-mkp .yiv9629370796ad p 
{margin:0;}#yiv9629370796 #yiv9629370796ygrp-mkp .yiv9629370796ad a 
{color:#ff;text-decoration:none;}#yiv9629370796 #yiv9629370796ygrp-sponsor 
#yiv9629370796ygrp-lc {font-family:Arial;}#yiv9629370796 
#yiv9629370796ygrp-sponsor #yiv9629370796ygrp-lc #yiv9629370796hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9629370796 
#yiv9629370796ygrp-sponsor #yiv9629370796ygrp-lc .yiv9629370796ad 
{margin-bottom:10px;padding:0 0;}#yiv9629370796 #yiv9629370796actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9629370796 
#yiv9629370796activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9629370796
 #yiv9629370796activity span {font-weight:700;}#yiv9629370796 
#yiv9629370796activity span:first-child 
{text-transform:uppercase;}#yiv9629370796 #yiv9629370796activity span a 
{color:#5085b6;text-decoration:none;}#yiv9629370796 #yiv9629370796activity span 
span {color:#ff7900;}#yiv9629370796 #yiv9629370796activity span 
.yiv9629370796underline {text-decoration:underline;}#yiv9629370796 
.yiv9629370796attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9629370796 .yiv9629370796attach div a 
{text-decoration:none;}#yiv9629370796 .yiv9629370796attach img 
{border:none;padding-right:5px;}#yiv9629370796 .yiv9629370796attach label 
{display:block;margin-bottom:5px;}#yiv9629370796 .yiv9629370796attach label a 
{text-decoration:none;}#yiv9629370796 blockquote {margin:0 0 0 
4px;}#yiv9629370796 .yiv9629370796bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9629370796 
.yiv9629370796bold a {text-decoration:none;}#yiv9629370796 dd.yiv9629370796last 
p a {font-family:Verdana;font-weight:700;}#yiv9629370796 dd.yiv9629370796last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9629370796 
dd.yiv9629370796last p span.yiv9629370796yshortcuts 
{margin-right:0;}#yiv9629370796 div.yiv9629370796attach-table div div a 
{text-decoration:none;}#yiv9629370796 div.yiv9629370796attach-table 
{width:400px;}#yiv9629370796 div.yiv9629370796file-title a, #yiv9629370796 
div.yiv9629370796file-title a:active, #yiv9629370796 
div.yiv9629370796file-title a:hover, #yiv9629370796 div.yiv9629370796file-title 
a:visited {text-decoration:none;}#yiv9629370796 div.yiv9629370796photo-title a, 
#yiv9629370796 div.yiv9629370796photo-title a:active, #yiv9629370796 
div.yiv9629370796photo-title a:hover, #yiv9629370796 
div.yiv9629370796photo-title a:visited {text-decoration:none;}#yiv9629370796 
div#yiv9629370796ygrp-mlmsg #yiv9629370796ygrp-msg p a 
span.yiv9629370796yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9629370796 
.yiv9629370796green {color:#628c2a;}#yiv9629370796 .yiv9629370796MsoNormal 
{margin:0 0 0 0;}#yiv9629370796 o {font-size:0;}#yiv9629370796 
#yiv9629370796photos div {float:left;width:72px;}#yiv9629370796 
#yiv9629370796photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv9629370796 
#yiv9629370796photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9629370796
 #yiv9629370796reco-category {font-size:77%;}#yiv9629370796 
#yiv9629370796reco-desc {font-size:77%;}#yiv9629370796 .yiv9629370796replbq 
{margin:4px;}#yiv9629370796 #yiv9629370796ygrp-actbar div a:first-child 
{margin-right:2px;padding-right:5px;}#yiv9629370796 #yiv9629370796ygrp-mlmsg 

Re: [oracle_br] Monitoring Index

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado Rosivaldo. Essa questão de consultas realizando hard parses já estamos 
trabalhando fortemente, já encontramos algumas consultas que estavam 
prejudicando em muito a concorrência na shared pool como também a quantidade de 
uso de CPU.
 

Em Quarta-feira, 6 de Julho de 2016 11:35, "Rosivaldo Ramalho 
rosiva...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Rafael,
Olha como está a quantidade de parses das consultas (a não utilização de bind 
variables), acredito ser um ponto melhor a atacar ao invés de ir para os 
índices, até porque você terá que fazer isso índice a índice.
Se for para a monitoria de índice mesmo, dá para automatizar o ON/OFF da 
monitoria e o uso deles, mas o que eu me preocuparia é o tempo de amostragem de 
uso, um mês pode não ser suficiente.
Atenciosamente--Rosivaldo Ramalho <rosiva...@gmail.com>Diretor na RLXE - 
http://www.rlxe.com.br
OCP DB 10g | OCP DB 11g | OCE RAC 11g | OCE PT 11gOCP OAS 10g | OCE WLS 10g
http://about.me/rosivaldo
2016-07-06 11:28 GMT-03:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br>:

 

Oracle 11.2.0.4 - Grid standalone - AIX 64 bits

Senhores, bom dia.
Em um determinado cliente, existe um servidor físico com 1 processador de 4 
cores, onde existem dois servidores virtuais (dois ambientes de produção) 
compartilhando o recurso da máquina.


Os dois servidores estão sempre trabalhando no seu limite de CPU. Estamos 
fazendo um trabalho para tentar tentar diminuir esse trabalho. Evitando que a 
CPU trabalhe sem necessidade.
**Um dos trabalhos** é a exclusão de índices (se gasta CPU sem necessidade 
atualizando índices que não estão sendo utilizados pela aplicação) que não 
estão sendo utilizados, acontece que existem em torno de 20 mil índices criados 
em uma das bases e gostaria de saber o quanto é que esse monitoramento de 
índice vai nos custar de CPU, tenho receio de habilitar o monitoramento de 
índices e acabar prejudicando mais ainda o pouco de CPU disponível que o 
cliente possui. Estava pensando em aplicar a auditoria de índices em um 
determinado schema e assim por diante, o problema é que o cliente tem pressa e 
deixar o monitoramento por 1 mes em cada schema isso iria demorar muito, sei 
que o processo correto a se fazer seria esse, porém o cliente tem pressa.






  #yiv8276107571 #yiv8276107571 -- #yiv8276107571ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8276107571 
#yiv8276107571ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8276107571 
#yiv8276107571ygrp-mkp #yiv8276107571hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8276107571 #yiv8276107571ygrp-mkp #yiv8276107571ads 
{margin-bottom:10px;}#yiv8276107571 #yiv8276107571ygrp-mkp .yiv8276107571ad 
{padding:0 0;}#yiv8276107571 #yiv8276107571ygrp-mkp .yiv8276107571ad p 
{margin:0;}#yiv8276107571 #yiv8276107571ygrp-mkp .yiv8276107571ad a 
{color:#ff;text-decoration:none;}#yiv8276107571 #yiv8276107571ygrp-sponsor 
#yiv8276107571ygrp-lc {font-family:Arial;}#yiv8276107571 
#yiv8276107571ygrp-sponsor #yiv8276107571ygrp-lc #yiv8276107571hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8276107571 
#yiv8276107571ygrp-sponsor #yiv8276107571ygrp-lc .yiv8276107571ad 
{margin-bottom:10px;padding:0 0;}#yiv8276107571 #yiv8276107571actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8276107571 
#yiv8276107571activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8276107571
 #yiv8276107571activity span {font-weight:700;}#yiv8276107571 
#yiv8276107571activity span:first-child 
{text-transform:uppercase;}#yiv8276107571 #yiv8276107571activity span a 
{color:#5085b6;text-decoration:none;}#yiv8276107571 #yiv8276107571activity span 
span {color:#ff7900;}#yiv8276107571 #yiv8276107571activity span 
.yiv8276107571underline {text-decoration:underline;}#yiv8276107571 
.yiv8276107571attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv8276107571 .yiv8276107571attach div a 
{text-decoration:none;}#yiv8276107571 .yiv8276107571attach img 
{border:none;padding-right:5px;}#yiv8276107571 .yiv8276107571attach label 
{display:block;margin-bottom:5px;}#yiv8276107571 .yiv8276107571attach label a 
{text-decoration:none;}#yiv8276107571 blockquote {margin:0 0 0 
4px;}#yiv8276107571 .yiv8276107571bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8276107571 
.yiv8276107571bold a {text-decoration:none;}#yiv8276107571 dd.yiv8276107571last 
p a {font-family:Verdana;font-weight:700;}#yiv8276107571 dd.yiv8276107571last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8276107571 
dd.yiv8276107571last p span.yiv8276107571yshortcuts 
{margin-right:0;}#yiv8276107571 div.yiv8276107571attach-table div div a 
{text-decoration:none;}#yiv8276107571 div.yiv8276107571attach-table 
{width:400px;}#yiv8276107571

[oracle_br] Monitoring Index

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Oracle 11.2.0.4 - Grid standalone - AIX 64 bits

Senhores, bom dia.
Em um determinado cliente, existe um servidor físico com 1 processador de 4 
cores, onde existem dois servidores virtuais (dois ambientes de produção) 
compartilhando o recurso da máquina.


Os dois servidores estão sempre trabalhando no seu limite de CPU. Estamos 
fazendo um trabalho para tentar tentar diminuir esse trabalho. Evitando que a 
CPU trabalhe sem necessidade.
**Um dos trabalhos** é a exclusão de índices (se gasta CPU sem necessidade 
atualizando índices que não estão sendo utilizados pela aplicação) que não 
estão sendo utilizados, acontece que existem em torno de 20 mil índices criados 
em uma das bases e gostaria de saber o quanto é que esse monitoramento de 
índice vai nos custar de CPU, tenho receio de habilitar o monitoramento de 
índices e acabar prejudicando mais ainda o pouco de CPU disponível que o 
cliente possui. Estava pensando em aplicar a auditoria de índices em um 
determinado schema e assim por diante, o problema é que o cliente tem pressa e 
deixar o monitoramento por 1 mes em cada schema isso iria demorar muito, sei 
que o processo correto a se fazer seria esse, porém o cliente tem pressa.

[oracle_br] Agendamento View Materializada

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Cenário:
Oracle 11.2.0.4 Enteprise Edition + grid infraestructure(ASM) standalone server 
AIX 64 bits

Senhores, tenho algumas dúvidas em relação aos agendamentos das views 
materializadas e gostaria da ajuda de vocês.
Estou em um cliente que possui centenas de  MVs. Para **CADA** MV os 
desenvolvedores deste cliente pede para o DBA criar um JOB, um PROGRAM, um 
SCHEDULER para executar uma PROCEDURE com o código de REFRESH da MV, ou seja, 
todos os refreshes de MV's são feitas por DBMS_SCHEDULER.
Como nunca tive muito convívio com MV's, sei que existe a possibilidade no 
próprio cabeçalho da view materializada ser configurado o período de 
atualização de acordo com a sua necessidade: Por commit, por demanda, por 
agendamento (horario) etc, o TIPO de ATUALIZAÇÃO: FAST, FULL etc.
O que eu quero evitar em minha base de dados é que o CLIENTE perca a mania de 
estar sempre precisando criar um JOB/PROGRAM/SCHEDULER/PROCEDURE para o 
agendamento do REFRESH da view e comece a ser feito no próprio cabeçalho da 
view.
a) Vocês seguem quais padrões para tal?
b) Existe a possibilidade de realizar um REFRESH no modo FAST sendo uma view do 
tipo complexa?  

c) Vocês concordam com a minha ideia de evitar essa gama de criação de objetos 
para uma view ser atualizada?

Fico no aguardo dos comentários.
:)

Re: [oracle_br] "

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Eu resolvi o problema, o problema estava em uma trigger de auditoria DDL que 
implementei a duas semanas atrás (ela está desabilitada temporariamente), por 
isso nenhum usuário que possuia senha expirada conseguia trocar a senha, a 
auditoria funciona normalmente, mas nesse caso específico acontece esse erro, 
segue o código da trigger:
CREATE OR REPLACE TRIGGER USER_AUDIT.DTR_DDLEVENTS
AFTER DDL ON DATABASE
DECLARE

  l_eventId    NUMBER(10,0);
  l_sqlText    ORA_NAME_LIST_T;

BEGIN

  SELECT USER_AUDIT.DSQ_DDLEVENTS.NEXTVAL INTO l_eventId FROM DUAL;

  INSERT INTO USER_AUDIT.DDL_EVENTS
  ( SELECT l_eventId,
   SYSDATE,
   ORA_LOGIN_USER,
   ORA_DICT_OBJ_NAME,
   ORA_DICT_OBJ_OWNER,
   ORA_DICT_OBJ_TYPE,
   ORA_SYSEVENT,
   machine,
   program,
   osuser
  FROM SYS.DUAL,
   SYS.V_$SESSION
 WHERE SYS_CONTEXT('USERENV','SESSIONID' ) = audsid(+) );


  FOR l IN 1..ORA_SQL_TXT(l_sqlText) LOOP
    INSERT INTO USER_AUDIT.DDL_EVENTS_SQL
    ( eventId, sqlLine, sqlText )
    VALUES
    ( l_eventId, l, l_sqlText(l) );
  END LOOP;

END;
/

 

Em Sexta-feira, 20 de Maio de 2016 9:36, "Paulo Jr 
paulobarbosa@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Teoricamente, a XUXA não pode trocar a senha, pois expirou como ela vai se 
conectar?
Mas como nosso amigo falou, entra como sys a manda bala. Depois tenta conectar 
com a XUXA e trocar a senha.


Em sex, 20 de mai de 2016 às 09:31, angelo angelolis...@gmail.com [oracle_br] 
<oracle_br@yahoogrupos.com.br> escreveu:

     bom dia,
Um jeito tosco de resolver seria:  entrar no BD como sys as sysdba e revalidar 
essa senha, afinal essa Xuxa já vem te incomodando ha tempos...

O jeito sério:  Tem alguma coisa rodando ai no BD tipo trigger para controlar o 
logon ou mudar senha ? 
Deveria ter trocado a senha realmente, tem algum boi na linha nesse processo 
ai...



On 19 May 2016 at 12:25, Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br> wrote:

     ** Oracle 11.2.0.4 EE

SQL> conn xuxa/xuxa@INSTANCIA
ERROR:
ORA-28001: the password has expired


Changing password for xuxa
New password:
Retype new password:
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-06502: PL/SQL: numeric or value error
ORA-06512: at line 26


Password unchanged


Senhores, esse problema vem ocorrendo há 2 semanas, o usuário "xuxa" possui 
privilégio de "ALTER USER".
O profile do usuário é o DEFAULT onde todas opções estão UNLIMITED, com exceção 
do PASSWORD_LOCK_TIME=1; PASSWORD_GRACE_TIME=7; FAILED_LOGIN_ATTEMPTS=1; 
PASSWORD_VERIFY_FUNCTION=NULL

Alguém pode ajudar?


   

   
  #yiv7296416675 #yiv7296416675 -- #yiv7296416675ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7296416675 
#yiv7296416675ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7296416675 
#yiv7296416675ygrp-mkp #yiv7296416675hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7296416675 #yiv7296416675ygrp-mkp #yiv7296416675ads 
{margin-bottom:10px;}#yiv7296416675 #yiv7296416675ygrp-mkp .yiv7296416675ad 
{padding:0 0;}#yiv7296416675 #yiv7296416675ygrp-mkp .yiv7296416675ad p 
{margin:0;}#yiv7296416675 #yiv7296416675ygrp-mkp .yiv7296416675ad a 
{color:#ff;text-decoration:none;}#yiv7296416675 #yiv7296416675ygrp-sponsor 
#yiv7296416675ygrp-lc {font-family:Arial;}#yiv7296416675 
#yiv7296416675ygrp-sponsor #yiv7296416675ygrp-lc #yiv7296416675hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7296416675 
#yiv7296416675ygrp-sponsor #yiv7296416675ygrp-lc .yiv7296416675ad 
{margin-bottom:10px;padding:0 0;}#yiv7296416675 #yiv7296416675actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7296416675 
#yiv7296416675activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7296416675
 #yiv7296416675activity span {font-weight:700;}#yiv7296416675 
#yiv7296416675activity span:first-child 
{text-transform:uppercase;}#yiv7296416675 #yiv7296416675activity span a 
{color:#5085b6;text-decoration:none;}#yiv7296416675 #yiv7296416675activity span 
span {color:#ff7900;}#yiv7296416675 #yiv7296416675activity span 
.yiv7296416675underline {text-decoration:underline;}#yiv7296416675 
.yiv7296416675attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv7296416675 .yiv7296416675attach div a 
{text-decoration:none;}#yiv7296416675 .yiv7296416675attach img 
{border:none;padding-right:5px;}#yiv7296416675 .yiv7296416675attach label 
{display:block;margin-bottom:5px;}#yiv7296416675 .yiv7296416675attach label a 
{text-decoration:none;}#yiv7296416675 blockquote {margin:0 0 0 
4px;}#yiv7296416675 .yiv7296416675bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv7296416675 
.yiv7296416675bold a {text-decoration:none;}#yiv7296416675 dd.yiv72964

[oracle_br] "

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

** Oracle 11.2.0.4 EE

SQL> conn xuxa/xuxa@INSTANCIA
ERROR:
ORA-28001: the password has expired


Changing password for xuxa
New password:
Retype new password:
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-06502: PL/SQL: numeric or value error
ORA-06512: at line 26


Password unchanged


Senhores, esse problema vem ocorrendo há 2 semanas, o usuário "xuxa" possui 
privilégio de "ALTER USER".
O profile do usuário é o DEFAULT onde todas opções estão UNLIMITED, com exceção 
do PASSWORD_LOCK_TIME=1; PASSWORD_GRACE_TIME=7; FAILED_LOGIN_ATTEMPTS=1; 
PASSWORD_VERIFY_FUNCTION=NULL

Alguém pode ajudar?

Re: [oracle_br] Re: Materialized View

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Pessoal, muito obrigado pelas dicas e pelas sugestões, eu marquei com o 
analista que trabalha em um outro local para agendarmos para analisarmos o 
problema juntos e de uma vez por toda tentar entender o que ele ta querendo 
fazer. Assim que tiver uma resposta para todos os questionamentos dos senhores, 
postarei aqui e a solução tomada. Mais uma vez obrigado.
 

Em Quarta-feira, 18 de Maio de 2016 17:25, "alexssandro0...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Boa tarde!
Rafael, apaga esta MV da lixeira do Oracle e tenta recriar ela novamente. 
Passei pelo mesmo problema no meu ambiente de DEV aqui, mas aqui foi com uma 
tabela, e resolvi apagando da lixeira.
OBS: Isso é válido se não tiver estourando nenhum outro erro que não seja o de 
tabela ou view já existe, e com certeza ela foi removida do ambiente etc.


  #yiv695759 #yiv695759 -- #yiv695759ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv695759 
#yiv695759ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv695759 
#yiv695759ygrp-mkp #yiv695759hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv695759 #yiv695759ygrp-mkp #yiv695759ads 
{margin-bottom:10px;}#yiv695759 #yiv695759ygrp-mkp .yiv695759ad 
{padding:0 0;}#yiv695759 #yiv695759ygrp-mkp .yiv695759ad p 
{margin:0;}#yiv695759 #yiv695759ygrp-mkp .yiv695759ad a 
{color:#ff;text-decoration:none;}#yiv695759 #yiv695759ygrp-sponsor 
#yiv695759ygrp-lc {font-family:Arial;}#yiv695759 
#yiv695759ygrp-sponsor #yiv695759ygrp-lc #yiv695759hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv695759 
#yiv695759ygrp-sponsor #yiv695759ygrp-lc .yiv695759ad 
{margin-bottom:10px;padding:0 0;}#yiv695759 #yiv695759actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv695759 
#yiv695759activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv695759
 #yiv695759activity span {font-weight:700;}#yiv695759 
#yiv695759activity span:first-child 
{text-transform:uppercase;}#yiv695759 #yiv695759activity span a 
{color:#5085b6;text-decoration:none;}#yiv695759 #yiv695759activity span 
span {color:#ff7900;}#yiv695759 #yiv695759activity span 
.yiv695759underline {text-decoration:underline;}#yiv695759 
.yiv695759attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv695759 .yiv695759attach div a 
{text-decoration:none;}#yiv695759 .yiv695759attach img 
{border:none;padding-right:5px;}#yiv695759 .yiv695759attach label 
{display:block;margin-bottom:5px;}#yiv695759 .yiv695759attach label a 
{text-decoration:none;}#yiv695759 blockquote {margin:0 0 0 
4px;}#yiv695759 .yiv695759bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv695759 
.yiv695759bold a {text-decoration:none;}#yiv695759 dd.yiv695759last 
p a {font-family:Verdana;font-weight:700;}#yiv695759 dd.yiv695759last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv695759 
dd.yiv695759last p span.yiv695759yshortcuts 
{margin-right:0;}#yiv695759 div.yiv695759attach-table div div a 
{text-decoration:none;}#yiv695759 div.yiv695759attach-table 
{width:400px;}#yiv695759 div.yiv695759file-title a, #yiv695759 
div.yiv695759file-title a:active, #yiv695759 
div.yiv695759file-title a:hover, #yiv695759 div.yiv695759file-title 
a:visited {text-decoration:none;}#yiv695759 div.yiv695759photo-title a, 
#yiv695759 div.yiv695759photo-title a:active, #yiv695759 
div.yiv695759photo-title a:hover, #yiv695759 
div.yiv695759photo-title a:visited {text-decoration:none;}#yiv695759 
div#yiv695759ygrp-mlmsg #yiv695759ygrp-msg p a 
span.yiv695759yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv695759 
.yiv695759green {color:#628c2a;}#yiv695759 .yiv695759MsoNormal 
{margin:0 0 0 0;}#yiv695759 o {font-size:0;}#yiv695759 
#yiv695759photos div {float:left;width:72px;}#yiv695759 
#yiv695759photos div div {border:1px solid 
#66;height:62px;overflow:hidden;width:62px;}#yiv695759 
#yiv695759photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv695759
 #yiv695759reco-category {font-size:77%;}#yiv695759 
#yiv695759reco-desc {font-size:77%;}#yiv695759 .yiv695759replbq 
{margin:4px;}#yiv695759 #yiv695759ygrp-actbar div a:first-child 
{margin-right:2px;padding-right:5px;}#yiv695759 #yiv695759ygrp-mlmsg 
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv695759 
#yiv695759ygrp-mlmsg table 

Re: [oracle_br] Re: Materialized View

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Chiappa, primeiramente obrigado pelo retorno.
O que o desenvolvedor quer é recriar a MV, pois o código da MV será modificado, 
porém, com o mesmo nome. 

O script do desenvolvedor para recriar a MV possui: Um "drop materialized view 
e um "create materialized view" como coloquei no primeiro tópico.
Portanto, nas bases de produção que serão aplicadas esse script, irá gerar o 
mesmo erro que ocasionou na base de desenvolvimento:

SQL> SELECT OWNER, OBJECT_NAME, OBJECT_TYPE FROM DBA_OBJECTS WHERE OBJECT_NAME 
= 'XUXA'
OWNER OBJECT_NAME   OBJECT_TYPE  
PUBLIC    XUXA  SYNONYM  
SCHEMA_XUXA   XUXA  MATERIALIZED VIEW
SCHEMA_XUXA   XUXA  TABLE    

Simulando em produção o que irá ocorrer é que o DROP será executado com sucesso 
e na hora da criação da Materialized VIew irá informar que já existe um objeto 
com o mesmo nome, gerando o erro ORA-00955 (por conta da tabela).
O nome da MV não pode ser modificada, terá que ser XUXA, pois a aplicação usa 
essa MV em centenas de lugares em seu código.
Como posso eu, recriar essa MV com nome XUXA, evitando o erro ORA-00955. Teria 
que renomear o objeto "XUXA" do tipo tabela?
OU teria uma outra alternativa?
Obrigado Chiappa.




 

Em Terça-feira, 17 de Maio de 2016 16:33, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Sim, cfrme 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3500555100346976066
 nos lembra, TABELAS e VIEW MATERIALIZADAS** não residem ** no mesmo namespace, 
são objetos logicamente Separados, então podem sim ter o mesmo nome, via de 
regra indicando a tabela de mesmo nome como a PREBUILT table
 Porém, Não É o fato da coisa existir/ser possível que AUTOMATICAMENTE ela é 
uma best practice e deve ser usada : PLZ aí nos explique  *** exatamente o que 
** o desenvolvedor está tentando fazer com isso, yep ???  
 
 ==>> Eu sei que cabeça de desenvolvedor é muitas vezes um caso sério de 
capacidade reduzida, mas eles ** ENTENDEM ** que, se vc tiver na sessão os 
parâmetros de query_rewrite ? 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:349809082244 
mostra ** EXATAMENTE ISSO **, ele cria uma view materializada emp_rollback que 
busca dados da tabela real emp , e com os settings corretos, um SQL usando a 
EMP é *** automaticamente ** direcionado para usar a EMP_ROLLBACK, sim sim sim 
??? Eles sabem dissso , e que portanto NÃO HÁ, em princípio, NENHUMA RAZÃO 
para se criar a mv com o mesmo nome da tabela, sim ???
 
  SE é , digamos, um caso especial de bug no rewrite ou coisa do tipo  aí no 
retorna e a gente pode discutir alguns work-arounds...
  
  []s
  
    Chiappa  #yiv2850687169 #yiv2850687169 -- #yiv2850687169ygrp-mkp 
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 
10px;}#yiv2850687169 #yiv2850687169ygrp-mkp hr {border:1px solid 
#d8d8d8;}#yiv2850687169 #yiv2850687169ygrp-mkp #yiv2850687169hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2850687169 #yiv2850687169ygrp-mkp #yiv2850687169ads 
{margin-bottom:10px;}#yiv2850687169 #yiv2850687169ygrp-mkp .yiv2850687169ad 
{padding:0 0;}#yiv2850687169 #yiv2850687169ygrp-mkp .yiv2850687169ad p 
{margin:0;}#yiv2850687169 #yiv2850687169ygrp-mkp .yiv2850687169ad a 
{color:#ff;text-decoration:none;}#yiv2850687169 #yiv2850687169ygrp-sponsor 
#yiv2850687169ygrp-lc {font-family:Arial;}#yiv2850687169 
#yiv2850687169ygrp-sponsor #yiv2850687169ygrp-lc #yiv2850687169hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2850687169 
#yiv2850687169ygrp-sponsor #yiv2850687169ygrp-lc .yiv2850687169ad 
{margin-bottom:10px;padding:0 0;}#yiv2850687169 #yiv2850687169actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2850687169 
#yiv2850687169activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2850687169
 #yiv2850687169activity span {font-weight:700;}#yiv2850687169 
#yiv2850687169activity span:first-child 
{text-transform:uppercase;}#yiv2850687169 #yiv2850687169activity span a 
{color:#5085b6;text-decoration:none;}#yiv2850687169 #yiv2850687169activity span 
span {color:#ff7900;}#yiv2850687169 #yiv2850687169activity span 
.yiv2850687169underline {text-decoration:underline;}#yiv2850687169 
.yiv2850687169attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv2850687169 .yiv2850687169attach div a 
{text-decoration:none;}#yiv2850687169 .yiv2850687169attach img 
{border:none;padding-right:5px;}#yiv2850687169 .yiv2850687169attach label 
{display:block;margin-bottom:5px;}#yiv2850687169 .yiv2850687169attach label a 
{text-decoration:none;}#yiv2850687169 blockquote {margin:0 0 0 
4px;}#yiv2850687169 .yiv2850687169bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv2850687169 
.yiv2850687169bold a {text-decoration:none;}#yiv2850687169 dd.yiv2850687169last 
p a {font-family:Verdana;font-weight:700;}#yiv2850687169 

Re: [oracle_br] Materialized View

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

*OBS*: A MV não se pode mudar o nome da MV, pois é usada em centenas de lugares 
na aplicação.
 

Em Terça-feira, 17 de Maio de 2016 14:56, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Senhores, bom dia.
** Oracle 11.2.0.4 EE.

Alguns desenvolvedores estão testando recriar uma view materializada que 
precisa ser modificada. Consultando a view dba_objects com o nome da MV, temos:
SQL> SELECT * FROM DBA_OBJECTS WHERE OBJECT_NAME = 'XUXA'
Que me retorna duas linhas:
Uma linha com o tipo de objeto **MV** e  a outra linha do tipo **TABLE**.
Para alterar o código do view, o desenvolvedor dropou e recriou a view, segue:
SQL> DROP MATERIALIZED VIEW XUXA;
SQL> CREATE MATERIALIZED VIEW XUXA
REFRESH FAST  ON DEMAND
WITH PRIMARY KEY
AS
SELECT COL1,
   COL2,
   COL3
FROM XUXA;
ORA-00955: nome já está sendo usado por um objeto existente

** Minha primeira dúvida é a seguinte:
Como é que poderia existir em minha base anteriormente, e que estava 
funcionando, uma MV que continha o mesmo nome de uma tabela e que essa mesma 
tabela fazia parte da consulta da MV?


Olhando pelo lado lógico do problema (até onde eu sei), uma materialized view 
apenas guarda o metadados (definição da consulta, período de atualização, tipo 
de atualização, etc), e quando uma MV é criada, o RDBMS Oracle, implicitamente, 
cria uma tabela "por baixo" que é justamente aonde o RDBMS Oracle irá buscar os 
dados. 

Pesquisando mais um pouco, percebi que existe uma forma de criar uma view 
materializada com o mesmo nome de uma tabela, mas que essa tabela não pode ser 
usada na mesma consulta da MV, o que não é o meu caso.
Estou precisando de algumas dicas em relação a esse problema que estou 
enfrentando, não posso deixar passar alguns scripts que já estão prontos para 
serem aplicados em produção antes de estar bem seguro em relação a esse 
problema.







  #yiv0888797259 #yiv0888797259 -- #yiv0888797259ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0888797259 
#yiv0888797259ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0888797259 
#yiv0888797259ygrp-mkp #yiv0888797259hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv0888797259 #yiv0888797259ygrp-mkp #yiv0888797259ads 
{margin-bottom:10px;}#yiv0888797259 #yiv0888797259ygrp-mkp .yiv0888797259ad 
{padding:0 0;}#yiv0888797259 #yiv0888797259ygrp-mkp .yiv0888797259ad p 
{margin:0;}#yiv0888797259 #yiv0888797259ygrp-mkp .yiv0888797259ad a 
{color:#ff;text-decoration:none;}#yiv0888797259 #yiv0888797259ygrp-sponsor 
#yiv0888797259ygrp-lc {font-family:Arial;}#yiv0888797259 
#yiv0888797259ygrp-sponsor #yiv0888797259ygrp-lc #yiv0888797259hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0888797259 
#yiv0888797259ygrp-sponsor #yiv0888797259ygrp-lc .yiv0888797259ad 
{margin-bottom:10px;padding:0 0;}#yiv0888797259 #yiv0888797259actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0888797259 
#yiv0888797259activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0888797259
 #yiv0888797259activity span {font-weight:700;}#yiv0888797259 
#yiv0888797259activity span:first-child 
{text-transform:uppercase;}#yiv0888797259 #yiv0888797259activity span a 
{color:#5085b6;text-decoration:none;}#yiv0888797259 #yiv0888797259activity span 
span {color:#ff7900;}#yiv0888797259 #yiv0888797259activity span 
.yiv0888797259underline {text-decoration:underline;}#yiv0888797259 
.yiv0888797259attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv0888797259 .yiv0888797259attach div a 
{text-decoration:none;}#yiv0888797259 .yiv0888797259attach img 
{border:none;padding-right:5px;}#yiv0888797259 .yiv0888797259attach label 
{display:block;margin-bottom:5px;}#yiv0888797259 .yiv0888797259attach label a 
{text-decoration:none;}#yiv0888797259 blockquote {margin:0 0 0 
4px;}#yiv0888797259 .yiv0888797259bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv0888797259 
.yiv0888797259bold a {text-decoration:none;}#yiv0888797259 dd.yiv0888797259last 
p a {font-family:Verdana;font-weight:700;}#yiv0888797259 dd.yiv0888797259last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0888797259 
dd.yiv0888797259last p span.yiv0888797259yshortcuts 
{margin-right:0;}#yiv0888797259 div.yiv0888797259attach-table div div a 
{text-decoration:none;}#yiv0888797259 div.yiv0888797259attach-table 
{width:400px;}#yiv0888797259 div.yiv0888797259file-title a, #yiv0888797259 
div.yiv0888797259file-title a:active, #yiv0888797259 
div.yiv0888797259file-title a:hover, #yiv0888797259 div.yiv0888797259file-title 
a:visited {text-decoration:none;}#yiv0888797259 div.yiv0888797259photo-title a, 
#yiv0888797259 div.yiv0888797259photo-title a:active, #yiv0888797259 
div.yiv0888797259photo-title a:hover, #yiv0888797259 
div.yiv0888797259photo-ti

[oracle_br] Materialized View

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Senhores, bom dia.
** Oracle 11.2.0.4 EE.

Alguns desenvolvedores estão testando recriar uma view materializada que 
precisa ser modificada. Consultando a view dba_objects com o nome da MV, temos:
SQL> SELECT * FROM DBA_OBJECTS WHERE OBJECT_NAME = 'XUXA'
Que me retorna duas linhas:
Uma linha com o tipo de objeto **MV** e  a outra linha do tipo **TABLE**.
Para alterar o código do view, o desenvolvedor dropou e recriou a view, segue:
SQL> DROP MATERIALIZED VIEW XUXA;
SQL> CREATE MATERIALIZED VIEW XUXA
REFRESH FAST  ON DEMAND
WITH PRIMARY KEY
AS
SELECT COL1,
   COL2,
   COL3
FROM XUXA;
ORA-00955: nome já está sendo usado por um objeto existente

** Minha primeira dúvida é a seguinte:
Como é que poderia existir em minha base anteriormente, e que estava 
funcionando, uma MV que continha o mesmo nome de uma tabela e que essa mesma 
tabela fazia parte da consulta da MV?


Olhando pelo lado lógico do problema (até onde eu sei), uma materialized view 
apenas guarda o metadados (definição da consulta, período de atualização, tipo 
de atualização, etc), e quando uma MV é criada, o RDBMS Oracle, implicitamente, 
cria uma tabela "por baixo" que é justamente aonde o RDBMS Oracle irá buscar os 
dados. 

Pesquisando mais um pouco, percebi que existe uma forma de criar uma view 
materializada com o mesmo nome de uma tabela, mas que essa tabela não pode ser 
usada na mesma consulta da MV, o que não é o meu caso.
Estou precisando de algumas dicas em relação a esse problema que estou 
enfrentando, não posso deixar passar alguns scripts que já estão prontos para 
serem aplicados em produção antes de estar bem seguro em relação a esse 
problema.

Re: [oracle_br] Problema de performance

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Obrigado mestre Rosivaldo.: )
 

Em Quinta-feira, 28 de Abril de 2016 16:39, "Rosivaldo Ramalho 
rosiva...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
 

     Rafael,
Pede para os desenvolvedores utilizarem bind variables. Com certeza você está 
com um alto número de SQLs duplicados.
Não aconselho setar o CURSOR_SHARING, porque as vezes as aplicações soltam 
parafusos, mas se os desenvolvedores não modificarem as consultas, é uma 
solução (drástica) também.
Atenciosamente--Rosivaldo Azevedo Ramalho <rosiva...@gmail.com>
Consultor Oracle Database & Fusion MiddlerwareOCP DB 10g | OCP DB 11g | OCE RAC 
11g | OCE PT 11gOCP OAS 10g | OCE WLS 10g

http://about.me/rosivaldo
2016-04-28 12:36 GMT-03:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
<oracle_br@yahoogrupos.com.br>:

 

** Configuração:
Oracle Enterprise Edition 11.2.0.4.8ASM standaloneAIX 64 bitsOption - todas as 
de tuning

** Cenário:

Percebi um alto pico de concorrência (wait class) pelo gráfico do Cloud 
COntrol, resolvi então tirar um AWR no intervalo de 20 minutos aonde se deu o 
intervalo do problema.
No "Top 10 Foreground Events by Total Wait Time" encontrei os 2 eventos mais 
problemáticos:
a - latch: row cache objects (40% DBTIME)b - cursor: pin S wait on X (10% 
DBTIME)

Wait Classes by Total Wait Time
a - Concurrency (53% DB TIME)

Em TIME MODEL STATISCS verifiquei que:
a - parse time elapsed - (55% DBTIME)b - hard parse elapsed time (46% DBTIME)c 
- sql execute elapsed time (42% DBTIME)

BOm, até onde eu sei, analisando alguns pontos do relatório da para perceber 
que o problema de concorrência está na shared pool e que o está havendo um 
grande problema de HARD PARSES, fazendo com que o seja mais lento o acesso a 
shared pool, se estiver errado me corrijam.
Portanto, fui nos SQL's ordenados por PARSE para verificar se existe alguma 
consulta sem BIND, mas não encontrei: Segue os 3 TOPS SQL ordenados por parse.


SELECT COUNT(1) 
  FROM XUXA.VW_PROCESSO P 
 WHERE NOT EXISTS (SELECT 1 
 FROM XUXA.INDICE_PROCESSO_MD IP 
   INNER JOIN XUXA.DOCUMENTO_XX_MD D 
   ON IP.SEQ_DOCUMENTO = D.SEQ_DOCUMENTO 
    WHERE IP.SEQ_PROCESSO_MD = P.SEQ_PROCESSO_MD 
  AND D.IND_EXCLUIDO <> 'S' 
  AND IP.DT_VALIDACAO IS NULL
   ) 
   AND EXISTS (SELECT 1 
 FROM XUXA.INDICE_PROCESSO_MD IP 
   INNER JOIN XUXA.DOCUMENTO_XXX_MD D 
   ON IP.SEQ_DOCUMENTO = D.SEQ_DOCUMENTO 
    WHERE IP.SEQ_PROCESSO_MD = P.SEQ_PROCESSO_MD 
  AND D.IND_EXCLUIDO <> 'S' 
  AND IP.DT_VALIDACAO IS NOT NULL
  ) 
  AND NOT EXISTS (SELECT 1 
    FROM XUXA.INDICE_PROCESSO_MD IP 
  INNER JOIN XUXA.DOCUMENTO_XXX_MD D 
  ON IP.SEQ_DOCUMENTO = D.SEQ_DOCUMENTO 
   WHERE IP.SEQ_PROCESSO_MD = P.SEQ_PROCESSO_MD 
 AND D.IND_EXCLUIDO <> 'S' 
 AND IP.DT_INDEXACAO IS NULL 
 AND IP.COD_TIPO_PECA = '63'
  ) 
  AND EXISTS (SELECT 1 
    FROM XUXA.INDICE_PROCESSO_MD IP 
   INNER JOIN XUXA.DOCUMENTO_XXX_MD D 
   ON IP.SEQ_DOCUMENTO = D.SEQ_DOCUMENTO 
    WHERE IP.SEQ_PROCESSO_MD = P.SEQ_ PROCESSO_MD 
  AND D.IND_EXCLUIDO <> 'S' 
  AND IP.DT_INDEXACAO IS NOT NULL 
  AND IP.COD_TIPO_PECA = '63'
  ) 
  AND P.COD_ST_PROC = '34'

2 - 


begin :result := sys.dbms_transaction.local_transaction_id; end;

3 - 

select condition from cdef$ where rowid=:1

Alguém poderia dar uma idéia do que eu possa fazer para evitar esse tipo de 
concorrência que está ocorrendo toda semana ?
O servidor possui 36GB de memória RAM e está sendo utilizado para o database 
apenas 12GB. 
Estava pensando em aumentar razoavelmente o tamanho da memória e deixar um 
tamanho minímo aceitável para a shared pool. Em relação ao primeiro SQL alguma 
coisa a ser analisada?









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