Re: [oracle_br] Re: Upgrade 9i to 10gR2
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 a:first
[oracle_br] Upgrade 9i to 10gR2
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
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, trunc(
[oracle_br] Ajuda query
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
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] 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] 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] 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.yiv1514955474photo-title a:hover, #yiv1514955474 div.yiv1514955474photo-title a:visited {text-decoration:none;}#yiv1514955474
[oracle_br] Sincronismo standby
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
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 {font-size:77%;}#yiv7980109103 #yiv7980109103reco-desc {f
[oracle_br] Upgrade 9i para 12cR1
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
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&start=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 {font-size:0;}#yiv4437430891 #yiv4437430891p
[oracle_br] Troubleshooting scheduler JOB
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
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
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 * {line-height:1.22em;}#yiv4640630887 #yiv4640630887ygrp-mlms
Re: Fw: Re: [oracle_br] Change owner catalog
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 {color:#628c2a;}#yiv9624666562 .yiv9624666562MsoNor
Re: Fw: Re: [oracle_br] Change owner catalog
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 {font-size:77%;}#yiv8815765869 #yiv8815
Re: Fw: Re: [oracle_br] Change owner catalog
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 div.yiv5835690105photo-title a:act
Re: Fw: Re: [oracle_br] Change owner catalog
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 {color:#66;font-size:10px;overflow:hidden;text-align:cent
Fw: Re: [oracle_br] Change owner catalog
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] Para: oracle...@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 on behalf of Rafael Mendonca raffaell.t...@yahoo.com [oracle_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 foundORA-31693: Table data object "USER_CATALOG"."BRL" failed to load/unload and is being skipped d
[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 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
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 #66;min-height:62px;overflow:hidden;width:62px;}#yiv1035838031 #yiv1035838031phot
Re: [oracle_br] Erro ao entrar no sqlplus
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] 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;}#yiv0996292195 div.yiv0996292195fi
[oracle_br] Erro ao entrar no sqlplus
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
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 Database 11g Express Edition Release
[oracle_br] Ajuda Codigo PL/SQL
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!!
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]" 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]&It;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.yiv3378312260file-title
Re: [oracle_br] Re: Consulta muito lenta!!
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 span span {color:#ff7900;}#yiv2
Re: [oracle_br] Re: Consulta muito lenta!!
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]" 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]" 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]" 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 #yiv5858779180photos div {float:left;width:72px;}#yiv5858779180 #yiv5858779180photos div div {b
Re: [oracle_br] Re: Consulta muito lenta!!
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 a:first-child {margin-right:2px;padding-r
Re: [oracle_br] Re: Consulta muito lenta!!
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 .yiv9629188119MsoNormal {margin:
Re: [oracle_br] Re: CLUSTERING FACTOR
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 {border:none;padding-right:5px;}#yiv2246574670 .yiv2246574670attach
Re: [oracle_br] Re: Consulta muito lenta!!
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 #yiv8130852198ygrp-lc {font-family:Ari
Re: [oracle_br] Consulta muito lenta!!
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]" 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: em nome de "Luis Freitas lfreita...@yahoo.com [oracle_br]" Responder para: "oracle_br@yahoogrupos.com.br" Data: sexta-feira, 15 de dezembro de 2017 12:09 Para: "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]" 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 auditoria e nao temos tempo para essa implementacao. Alguem pode ajudar nessa dificil missao? [As partes desta mensagem que não continham texto foram removidas] #yiv1519314873 #yiv1519314873 -- #yiv1519314873yg
[oracle_br] Consulta muito lenta!!
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
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]" 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] : 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
Re: [oracle_br] Re: AJuda script shell
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 #yiv4054497711ygrp-mkp .yiv4054497711ad {paddin
Re: [oracle_br] AJuda script shell
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]" 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] 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]" 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 em nome de Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] Enviado: terça-feira, 12 de dezembro de 2017 11:01:48 Par
Re: [oracle_br] AJuda script shell
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]" 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]" 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 em nome de Rafael Mendonca raffaell.t...@yahoo.com [oracle_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
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]" 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 em nome de Rafael Mendonca raffaell.t...@yahoo.com [oracle_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-f
[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?
Re: [oracle_br] Sessões fican do "Presas" workaround please
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 div.yiv5794922530photo-title a
Re: [oracle_br] Sessões ficando "Presas" workaround please
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]" 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]" 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]" 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]" 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 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;}#yiv6561204037 #yiv6561204037ygrp-mkp .yiv6561204037ad a {color:#ff;text-decorat
Re: [oracle_br] Sessões ficando "Presas" workaround please
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]" 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]" 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]" 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 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 #yiv9079454453ygrp-lc #yiv9079454453hd {margin:10px
Re: [oracle_br] Sessões ficando "Presas" workaround please
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]" 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]" 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 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 {clear:both;disp
[oracle_br] Sessões ficando "Presas" workaround please
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
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]" 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] 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.yiv2471386280photo-title a, #yiv2471386280 div.yiv2471386280photo-title a:active, #yiv
Re: [oracle_br] Curso Golden Gate
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 div.yiv7246360942photo-title a, #yiv7246360942 div.yiv7246360942photo-tit
[oracle_br] Migração
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
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 0;width:400px;}#yiv9578779290 .yiv9578779290attach div a {text-decor
Re: RES: RES: [oracle_br] upgrade 12.1 to 12.2 ?
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 {text-transform:uppercase;}#yiv7419990407 #yiv7419990407activity span a {color:#5085b6;text-decoration:none;}#yiv7419990407
Re: RES: RES: [oracle_br] Re: Oracle Features
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 {border:none;padding-right:5px;}#
Re: [oracle_br] Re: Erro ao instalar GRID
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 {font-size:inherit;font:100%;}#yiv6153207137 #yiv61532071
Re: [oracle_br] Re: Erro ao instalar GRID
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 div.yiv0423042600photo-title a:visited {text-decoration:none;}#yiv
Re: [oracle_br] Re: Erro ao instalar GRID
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 {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5727416837 .y
Re: [oracle_br] Re: Erro ao instalar GRID
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]" 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] ckpt file location is /u01/app/oracle/cr
Re: [oracle_br] Re: Erro ao instalar GRID
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 10:16:4
[oracle_br] Erro ao instalar GRID
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
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
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]" 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]" 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-mkp hr {border:1px solid #d8d8d8;}#yiv2495
Re: [oracle_br] Dataguard configuração se perde
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 #yiv8668407470ygrp-lc .yiv866840747
Re: [oracle_br] Re: tamanho ideal do redo..
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 #66;height:62px;overflow:hidden;width:62px;}#photos div l
Re: [oracle_br] Re: Crash UNDO sem backup
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 {font-family:Arial;font-size:13
[oracle_br] Crash UNDO sem backup
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
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
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 {text-decoration:none;}#yiv6895404866 div.
[oracle_br] Substituição do Oracle Suporte
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
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 com eles e os transferir para o o
Re: [oracle_br] Migração
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]" 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 em nome de Rafael Mendonca raffaell.t...@yahoo.com [oracle_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]" 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 #yiv9061301510activity span span {color:#ff7900;}#yiv9061301510 #yiv9061301510activity span .yiv9061301510underline {text-decoration:underl
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]" 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 {font-size:13px;font-family:Arial,
[oracle_br] Migração
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
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
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 {font-family:Verdana;font-size:10px;font-weight:normal
[oracle_br] Envio de alertas
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 ??
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]" 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] 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]" 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] 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, t
Re: [oracle_br] Lentidão ??
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]" 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] 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: em nome de "Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]" Responder para: "oracle_br@yahoogrupos.com.br" Data: terça-feira, 13 de setembro de 2016 18:46 Para: "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.DTHRMOV) FROM LOCALFISICO LF, MOVIMENTOFISICO MF, EXPMOVDISTRIBUICAO EMD WHERE MF.CODDOC = :B1 AND MF.DTHRMOV = (SELECT MAX(DTHRMOV) FROM MOVIMENTOFISICO WHERE CODDOC = :B1 AND DTHRMOV < :B2 ) AND MF.COD
Re: [oracle_br] Lentidão ??
.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]" 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] 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 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-sponsor #yiv3288987806ygrp-lc #yiv3288987806hd {margin:10px 0px;font-weight:700;font-size:78%;
[oracle_br] Lentidão ??
=> 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
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
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 'ponto oculto' do logical stand
Re: [oracle_br] Re: Licenciamento Oracle
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 dd.yiv3634476682last p span {margin-right:10px;font-family:Verdana;font-w
Re: [oracle_br] Sessão muito tempo ativa
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]" 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]" 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-right:10px;font-family:Verdana;font-weight:700
Re: [oracle_br] Re: Cursor: pin S wait on X - Apó s migração para novo ambiente
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) e pelo SQL_ID ver quem é o SQ
Re: [oracle_br] Re: Refresh materialized view
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 {text-decoration:none;}#yiv3505003201 div.yiv3505003201attach-
[oracle_br] Refresh materialized view
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
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 #yiv8350209974ygrp-mlmsg #yiv8350209
Re: [oracle_br] Re: Sessão muito tempo ativa
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, sans-serif;}#yiv0359606233 #yiv0359
[oracle_br] Sessão muito tempo ativa
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
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 {margin:4px;}#yiv8998844042 #yiv89988440
Re: [oracle_br] Problema em compilação
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 {width:400px;}#yiv9316245945 div.yiv9316245945file-title
Re: [oracle_br] Problema em compilação
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]" 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 div.yiv4826885975file-title a:act
[oracle_br] Problema em compilação
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
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 {font-size:13px;font-family:Arial, helvetica,
Re: [oracle_br] Monitoring Index
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]" 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 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 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 div.yiv8276107571file-title a, #yiv8276107571 div.yiv8276107571file-title a:active, #yiv
[oracle_br] Monitoring Index
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.
Re: [oracle_br] Re: Agendamento View Materializada
Obrigado pelas respostas :) Em Quarta-feira, 22 de Junho de 2016 20:32, "jlchia...@yahoo.com.br [oracle_br]" escreveu: Opa : bom, quando vc diz "cabeçalho" na verdade vc quer se referir ao DDL de criação da view materializada, ao CREATE MATERIALIZED VIEW em si, certo ? View não tem "cabeçalho" nenhum... Então, vc tem dois tipos de REFRESH automático, o REFRESH ON COMMIT (que atualiza a view materializada sempre que houver um COMMIT) e o REFRESH com cláusula START WITH + NEXT (que atualiza baseado num Período de tempo que vc indica) : a primeira coisa vc tem que considerar para o REFRESH ON COMMIT é o overhead em CADA transação (pois o COMMIT só termina depois de refrescar a(s) vm(s) , e para o REFRESH auto-programado com cláusula de NEXT é que nem sempre é possível/viável vc ter a view "desatualiza" enquanto não chega a data/hora do refresh... OU SEJA, para as views que teu cliente PRECISA que sejam sempre 100% atualizadas ele TEM que mensurar e ter capacidade para suportar o tempo de COMMIT alongado, E para as views que suportem operação com dados defasados por um período, ele TEM que definir na criação da vm qual seria esse período... PODEM haver casos onde os dados só precisam estar atualizados com o dia anterior, digamos, aí vc bota pra refrescar á noite, E podem ter casos onde isso não é viável Varia... Respondendo, então , isso posto : a) absolutamente NÂO EXISTE PADRÃO pra isso, cada caso é um caso, é o seu cliente que tem que mensurar para quais vms ele suporta overhead, para quais pode haver alguma defasagem NÂO EXISTE PADRÃO, é sempre baseado no levantamento com o Cliente... b) depende do caso : http://oraclehack.blogspot.com.br/2013/02/create-fast-refreshable-materialized.html por exemplo mostra uma query complexa do tipo clássico (ie, usa funções no WHERE ou faz JOIN) que pôde ter a condição de FAST REFRESH ativada com o recurso de ROWID, mas isso (Óbvio) não é solução para qualquer tipo de refresh fast em SQLs complexos Não tem jeito, a resposta TEM que ser DEPENDE... c) sim, para os casos em que é viável REFRESH programado e/ou ON COMMIT, é Claro que é melhor pro cliente que o próprio banco já faça o necessário, é um trabalho a menos pra ele... []s Chiappa #yiv3232272476 #yiv3232272476 -- #yiv3232272476ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3232272476 #yiv3232272476ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3232272476 #yiv3232272476ygrp-mkp #yiv3232272476hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv3232272476 #yiv3232272476ygrp-mkp #yiv3232272476ads {margin-bottom:10px;}#yiv3232272476 #yiv3232272476ygrp-mkp .yiv3232272476ad {padding:0 0;}#yiv3232272476 #yiv3232272476ygrp-mkp .yiv3232272476ad p {margin:0;}#yiv3232272476 #yiv3232272476ygrp-mkp .yiv3232272476ad a {color:#ff;text-decoration:none;}#yiv3232272476 #yiv3232272476ygrp-sponsor #yiv3232272476ygrp-lc {font-family:Arial;}#yiv3232272476 #yiv3232272476ygrp-sponsor #yiv3232272476ygrp-lc #yiv3232272476hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3232272476 #yiv3232272476ygrp-sponsor #yiv3232272476ygrp-lc .yiv3232272476ad {margin-bottom:10px;padding:0 0;}#yiv3232272476 #yiv3232272476actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3232272476 #yiv3232272476activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3232272476 #yiv3232272476activity span {font-weight:700;}#yiv3232272476 #yiv3232272476activity span:first-child {text-transform:uppercase;}#yiv3232272476 #yiv3232272476activity span a {color:#5085b6;text-decoration:none;}#yiv3232272476 #yiv3232272476activity span span {color:#ff7900;}#yiv3232272476 #yiv3232272476activity span .yiv3232272476underline {text-decoration:underline;}#yiv3232272476 .yiv3232272476attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv3232272476 .yiv3232272476attach div a {text-decoration:none;}#yiv3232272476 .yiv3232272476attach img {border:none;padding-right:5px;}#yiv3232272476 .yiv3232272476attach label {display:block;margin-bottom:5px;}#yiv3232272476 .yiv3232272476attach label a {text-decoration:none;}#yiv3232272476 blockquote {margin:0 0 0 4px;}#yiv3232272476 .yiv3232272476bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv3232272476 .yiv3232272476bold a {text-decoration:none;}#yiv3232272476 dd.yiv3232272476last p a {font-family:Verdana;font-weight:700;}#yiv3232272476 dd.yiv3232272476last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3232272476 dd.yiv3232272476last p span.yiv3232272476yshortcuts {margin-right:0;}#yiv3232272476 div.yiv3232272476attach-table div div a {text-decoration:none;}#yiv3232272476 div.yiv3232272476attach-table {width:400px;}#yiv3232272476 div.yiv3232272476file-title a, #yiv3232272476 div.yiv3232272476file-title a
[oracle_br] Agendamento View Materializada
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] "
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]" 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] 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] 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.yiv7296416675last p a {font-family:Verdana;font-weight:700;}#yiv7296416675 dd.yiv7296416675last p span {
[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
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 {font-size:inherit;font:100%;}#yiv695759 #yiv69575
Re: [oracle_br] Re: Materialized View
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 dd.yiv2850687169last p span {margin-r
Re: [oracle_br] Materialized View
*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]" 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-title a:visited {text-decoration:none
[oracle_br] Materialized View
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.