[oracle_br] Redudancy, failgroup ASM
Senhores, pegando o embalo do ultima thread postada sobre disks , diskgroups, ASM etc. Tambem possuo uma duvida em relacao a DISKGROUPS, FAILGROUPS e REDUNDANCIA. SAbemos que a redundancia NORMAL para arquivos de banco de dados possuimos 2-mirror-way, e que uma redudancia HIGH possuimos 3-mirror-way. Quando nao existe redundancia por storage, costumo sempre utilizar redudancia NORMAL com 2 failgroups, um que seria os dados "originais" e o outro failgroup para as copias de seguranca. A minha duvida eh a seguinte: Ja vi em alguns ambientes um diskgroup com redundancia NORMAL com 3 failgroups, 4 failgroups, e nao entendi muito bem o motivo disso. Ja que redudancia NORMAL soh existe 2-mirror-way para que criar mais que 2 failgroup para o mesmo diskgroup?? Para que ou por que motivo eu criaria uma situacao como essa? Ou um HIGH com 5 ou 4 failgroup, isso teria alguma justificativa plausivel? Existe algum ganho de performance/administrativa/seguranca???
[oracle_br] Problema Oracle RAC
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.
Re: [oracle_br] Problema com ASM Instance
Rodrigo, vc é o cara!!!
Em Sábado, 15 de Abril de 2017 19:37, "Rodrigo Mufalani
rodr...@mufalani.com.br [oracle_br]" escreveu:
Boa tarde,
Faça o scan dos discos pela asmlib e depois monte eles no node2.
Get Outlook for iOSFrom: oracle_br@yahoogrupos.com.br
on behalf of Carlos Eduardo
carloseduard...@yahoo.com [oracle_br]
Sent: Saturday, April 15, 2017 7:22:28 PM
To: Yahoo! Brazil
Subject: [oracle_br] Problema com ASM Instance Cenário:
ORACLE RAC 12.1 dois nósOEL 6.5GRID InstaladoDATABASE INstaladoPorém, o
database ainda não existe.
DISKGROUP CONFIGDISK01DISK02DISK03
DISKGROUP DATADISK04DISK05
DISKGROUP FRADISK06DISK07
Na hora da criação do database, foi indicado que iria faltar espaço em disco
nos dois diskgroups, pelo motivo que eram apenas de 2GB cada, o que eu foi
adicionar mais 4 discos, o DISK08 e 09 para o DATA e o DISK 10 e 11 para o
FRA===DISK08DISK09DISK10DISK11===
RAC 2
ALTER DISKGROUP DATA DISMOUNT;ALTER DISKGROUP FRA DISMOUNT;
RAC 1
DROP DISKGROUP DATA INCLUDING CONTENTS;DROP DISKGROUP FRA INCLUDING CONTENTS;
CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK 'ORCL:DISK08', 'ORCL:DISK09';
CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK 'ORCL:DISK10', 'ORCL:DISK11';
ASMDISK MOUNT_S STATE PATH HEADER_STATU DISKGROUP ---
-DISK01CACHED NORMAL ORCL:DISK01
MEMBERCONFIGDISK02CACHED NORMAL ORCL:DISK02 MEMBERCONFIGDISK03CACHED
NORMAL ORCL:DISK03 MEMBERCONFIGDISK08CACHED NORMAL ORCL:DISK08
MEMBERDATADISK09CACHED NORMAL ORCL:DISK09 MEMBERDATADISK10CACHED NORMAL
ORCL:DISK10 MEMBERFRADISK11CACHED NORMAL ORCL:DISK11 MEMBERFRA
É justamente essa configuração que tem que está, porém no RAC2 ficou
desconfigurado, como posso fazer para corrigir esse problema?
ASMDISK MOUNT_S STATE PATH HEADER_STATU DISKGROUP ---
CLOSED NORMAL ORCL:DISK07 FORMERFRACLOSED NORMAL
ORCL:DISK07 FORMERDATACLOSED NORMAL ORCL:DISK06 FORMERFRACLOSED NORMAL
ORCL:DISK06 FORMERDATACLOSED NORMAL ORCL:DISK11 MEMBERFRACLOSED NORMAL
ORCL:DISK11 MEMBERDATACLOSED NORMAL ORCL:DISK08 MEMBERFRACLOSED NORMAL
ORCL:DISK08 MEMBERDATACLOSED NORMAL ORCL:DISK09 MEMBERFRACLOSED NORMAL
ORCL:DISK09 MEMBERDATACLOSED NORMAL ORCL:DISK10 MEMBERFRACLOSED NORMAL
ORCL:DISK10 MEMBERDATACLOSED NORMAL ORCL:DISK05 FORMERFRACLOSED NORMAL
ORCL:DISK05 FORMERDATACLOSED NORMAL ORCL:DISK04 FORMERFRACLOSED NORMAL
ORCL:DISK04 FORMERDATADISK02CACHED NORMAL ORCL:DISK02
MEMBERCONFIGDISK01CACHED NORMAL ORCL:DISK01 MEMBERCONFIGDISK03CACHED
NORMAL ORCL:DISK03 MEMBERCONFIG
COmo seria o procedimento correto para evitar esse tipo de problema no meu RAC?
#yiv6945965809 #yiv6945965809 -- #yiv6945965809ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6945965809
#yiv6945965809ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6945965809
#yiv6945965809ygrp-mkp #yiv6945965809hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv6945965809 #yiv6945965809ygrp-mkp #yiv6945965809ads
{margin-bottom:10px;}#yiv6945965809 #yiv6945965809ygrp-mkp .yiv6945965809ad
{padding:0 0;}#yiv6945965809 #yiv6945965809ygrp-mkp .yiv6945965809ad p
{margin:0;}#yiv6945965809 #yiv6945965809ygrp-mkp .yiv6945965809ad a
{color:#ff;text-decoration:none;}#yiv6945965809 #yiv6945965809ygrp-sponsor
#yiv6945965809ygrp-lc {font-family:Arial;}#yiv6945965809
#yiv6945965809ygrp-sponsor #yiv6945965809ygrp-lc #yiv6945965809hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv6945965809
#yiv6945965809ygrp-sponsor #yiv6945965809ygrp-lc .yiv6945965809ad
{margin-bottom:10px;padding:0 0;}#yiv6945965809 #yiv6945965809actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv6945965809
#yiv6945965809activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv6945965809
#yiv6945965809activity span {font-weight:700;}#yiv6945965809
#yiv6945965809activity span:first-child
{text-transform:uppercase;}#yiv6945965809 #yiv6945965809activity span a
{color:#5085b6;text-decoration:none;}#yiv6945965809 #yiv6945965809activity span
span {color:#ff7900;}#yiv6945965809 #yiv6945965809activity span
.yiv6945965809underline {text-decoration:underline;}#yiv6945965809
.yiv6945965809attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv6945965809 .yiv6945965809attach div a
{text-decoration:none;}#yiv6945965809 .yiv6945965809attach img
{border:none;padding-right:5px;}#yiv6945965809 .yiv6945965809attach label
{display:block;margin-bottom:5px;}#yiv6945965809 .yiv6945965809attach label a
{text-decoration:none;}#yiv6945965809 blockquote {margin:0
[oracle_br] Problema com ASM Instance
Cenário: ORACLE RAC 12.1 dois nósOEL 6.5GRID InstaladoDATABASE INstaladoPorém, o database ainda não existe. DISKGROUP CONFIGDISK01DISK02DISK03 DISKGROUP DATADISK04DISK05 DISKGROUP FRADISK06DISK07 Na hora da criação do database, foi indicado que iria faltar espaço em disco nos dois diskgroups, pelo motivo que eram apenas de 2GB cada, o que eu foi adicionar mais 4 discos, o DISK08 e 09 para o DATA e o DISK 10 e 11 para o FRA===DISK08DISK09DISK10DISK11=== RAC 2 ALTER DISKGROUP DATA DISMOUNT;ALTER DISKGROUP FRA DISMOUNT; RAC 1 DROP DISKGROUP DATA INCLUDING CONTENTS;DROP DISKGROUP FRA INCLUDING CONTENTS; CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK 'ORCL:DISK08', 'ORCL:DISK09'; CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK 'ORCL:DISK10', 'ORCL:DISK11'; ASMDISK MOUNT_S STATE PATH HEADER_STATU DISKGROUP --- -DISK01 CACHED NORMAL ORCL:DISK01 MEMBER CONFIGDISK02 CACHED NORMAL ORCL:DISK02 MEMBER CONFIGDISK03 CACHED NORMAL ORCL:DISK03 MEMBER CONFIGDISK08 CACHED NORMAL ORCL:DISK08 MEMBER DATADISK09 CACHED NORMAL ORCL:DISK09 MEMBER DATADISK10 CACHED NORMAL ORCL:DISK10 MEMBER FRADISK11 CACHED NORMAL ORCL:DISK11 MEMBER FRA É justamente essa configuração que tem que está, porém no RAC2 ficou desconfigurado, como posso fazer para corrigir esse problema? ASMDISK MOUNT_S STATE PATH HEADER_STATU DISKGROUP --- CLOSED NORMAL ORCL:DISK07 FORMER FRA CLOSED NORMAL ORCL:DISK07 FORMER DATA CLOSED NORMAL ORCL:DISK06 FORMER FRA CLOSED NORMAL ORCL:DISK06 FORMER DATA CLOSED NORMAL ORCL:DISK11 MEMBER FRA CLOSED NORMAL ORCL:DISK11 MEMBER DATA CLOSED NORMAL ORCL:DISK08 MEMBER FRA CLOSED NORMAL ORCL:DISK08 MEMBER DATA CLOSED NORMAL ORCL:DISK09 MEMBER FRA CLOSED NORMAL ORCL:DISK09 MEMBER DATA CLOSED NORMAL ORCL:DISK10 MEMBER FRA CLOSED NORMAL ORCL:DISK10 MEMBER DATA CLOSED NORMAL ORCL:DISK05 FORMER FRA CLOSED NORMAL ORCL:DISK05 FORMER DATA CLOSED NORMAL ORCL:DISK04 FORMER FRA CLOSED NORMAL ORCL:DISK04 FORMER DATADISK02 CACHED NORMAL ORCL:DISK02 MEMBER CONFIGDISK01 CACHED NORMAL ORCL:DISK01 MEMBER CONFIGDISK03 CACHED NORMAL ORCL:DISK03 MEMBER CONFIG COmo seria o procedimento correto para evitar esse tipo de problema no meu RAC?
Re: [oracle_br] Erro instalação RAC
Rodrigo, boa tarde.
Eu adicionei no resolv.conf nos dois nós e o erro permaneceu.Porém, como vc
informou que poderia ignorar por se tratar de um lab (nao terial problema em
relacao a isso para montar meu lab), a instalação foi concluída com sucesso sem
nenhum tipo de erro.
Mais uma vez, obrigado.
Em Sexta-feira, 14 de Abril de 2017 16:06, "Rodrigo Mufalani
rodr...@mufalani.com.br [oracle_br]" escreveu:
Boa tarde,
Como isso é um ambiente de testes, que está montando. Pode ignorar esse erro,
mas se quiser consertar basta adicionar/ajustar no seu /etc/resolv.conf
options attempts:2
options timeout:1
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:rodr...@mufalani.com.br>
<http://www.mufalani.com.br/>[cid:image001.png@01D2B539.06763860]<http://www.mufalani.com.br/>[cid:image002.png@01D2B539.06763860]
De: em nome de "Carlos Eduardo
carloseduard...@yahoo.com [oracle_br]"
Responder para: "oracle_br@yahoogrupos.com.br"
Data: sexta-feira, 14 de abril de 2017 14:52
Para: "oracle_br@yahoogrupos.com.br"
Assunto: Re: [oracle_br] Erro instalação RAC
PRVF-5636 : The DNS response time for an unreachable node exceeded "15000"
[As partes desta mensagem que não continham texto foram removidas]
#yiv3955216346 #yiv3955216346 -- #yiv3955216346ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3955216346
#yiv3955216346ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3955216346
#yiv3955216346ygrp-mkp #yiv3955216346hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv3955216346 #yiv3955216346ygrp-mkp #yiv3955216346ads
{margin-bottom:10px;}#yiv3955216346 #yiv3955216346ygrp-mkp .yiv3955216346ad
{padding:0 0;}#yiv3955216346 #yiv3955216346ygrp-mkp .yiv3955216346ad p
{margin:0;}#yiv3955216346 #yiv3955216346ygrp-mkp .yiv3955216346ad a
{color:#ff;text-decoration:none;}#yiv3955216346 #yiv3955216346ygrp-sponsor
#yiv3955216346ygrp-lc {font-family:Arial;}#yiv3955216346
#yiv3955216346ygrp-sponsor #yiv3955216346ygrp-lc #yiv3955216346hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3955216346
#yiv3955216346ygrp-sponsor #yiv3955216346ygrp-lc .yiv3955216346ad
{margin-bottom:10px;padding:0 0;}#yiv3955216346 #yiv3955216346actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3955216346
#yiv3955216346activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3955216346
#yiv3955216346activity span {font-weight:700;}#yiv3955216346
#yiv3955216346activity span:first-child
{text-transform:uppercase;}#yiv3955216346 #yiv3955216346activity span a
{color:#5085b6;text-decoration:none;}#yiv3955216346 #yiv3955216346activity span
span {color:#ff7900;}#yiv3955216346 #yiv3955216346activity span
.yiv3955216346underline {text-decoration:underline;}#yiv3955216346
.yiv3955216346attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv3955216346 .yiv3955216346attach div a
{text-decoration:none;}#yiv3955216346 .yiv3955216346attach img
{border:none;padding-right:5px;}#yiv3955216346 .yiv3955216346attach label
{display:block;margin-bottom:5px;}#yiv3955216346 .yiv3955216346attach label a
{text-decoration:none;}#yiv3955216346 blockquote {margin:0 0 0
4px;}#yiv3955216346 .yiv3955216346bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3955216346
.yiv3955216346bold a {text-decoration:none;}#yiv3955216346 dd.yiv3955216346last
p a {font-family:Verdana;font-weight:700;}#yiv3955216346 dd.yiv3955216346last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3955216346
dd.yiv3955216346last p span.yiv3955216346yshortcuts
{margin-right:0;}#yiv3955216346 div.yiv3955216346attach-table div div a
{text-decoration:none;}#yiv3955216346 div.yiv3955216346attach-table
{width:400px;}#yiv3955216346 div.yiv3955216346file-title a, #yiv3955216346
div.yiv3955216346file-title a:active, #yiv3955216346
div.yiv3955216346file-title a:hover, #yiv3955216346 div.yiv3955216346file-title
a:visited {text-decoration:none;}#yiv3955216346 div.yiv3955216346photo-title a,
#yiv3955216346 div.yiv3955216346photo-title a:active, #yiv3955216346
div.yiv3955216346photo-title a:hover, #yiv3955216346
div.yiv3955216346photo-title a:visited {text-decoration:none;}#yiv3955216346
div#yiv3955216346ygrp-mlmsg #yiv3955216346ygrp-msg p a
span.yiv3955216346yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3955216346
.yiv3955216346green {color:#628c2a;}#yiv3955216346 .yiv3955216346MsoNormal
{margin:0 0 0 0;}#yiv3955216346 o {font-size:0;}#yiv3955216346
#yiv395521634
Re: [oracle_br] Re: gap standby database
Obrigado ao Rodrigo e ao Chiappa, problema resolvido: O que foi feito, foi mais
simples do que eu imaginava...
Troubleshooting:
ORA-0: name for data file 125 is unknown - rename to correct fileORA-01110:
data file 125:
'/u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/UNNAMED00125'ORA-01157: cannot
identify/lock data file 125 - see DBWR trace fileORA-0: name for data file
125 is unknown - rename to correct fileORA-01110: data file 125:
'/u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/UNNAMED00125'
No standby apenas:
alter system set standby_file_management=MANUAL scope=both;System altered.
alter database create datafile
'/u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/UNNAMED00126' as '+DATA';
ERROR at line 1:ORA-01136: specified size of file 125 (12800 blocks) is less
than original sizeof 3932160 blocksORA-0: name for data file 125 is unknown
- rename to correct fileORA-01110: data file
125:'/u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/UNNAMED00125'
alter database create datafile
'/u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/UNNAMED00126' as '+DATA' size
30g;
Database altered.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;Database altered.
alter system set standby_file_management=AUTO scope=both; System altered.
Alert.log
Fri Apr 14 23:10:24 2017Media Recovery Log
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320367.4640.941215181Media
Recovery Log +FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320368.4638.941215181
Em Sexta-feira, 14 de Abril de 2017 16:26, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Realmente uma coisa feia, até porque (** imagino **) existe um Roteiro
muito específico de como trabalhar com standby aí na sua Empresa, não importa
quem seja o cliente e quem seja o DBA, né não ?? è o caso de pegra o sujeitinho
que aprontou uma dessa e dar uma surra com um gato morto até o gato miar
G-suis
Bom, primeira coisa se o animalzinho chegou mesmo a criar a tablespace
manualmente esse dicionário virou uma zona só, vou dar o que penso ser o
procedimento mas não garanto coisa nenhuma : em tese o que eu vou dizer deveria
funcionar, mas é aquele negócio, procedimentos fora do padrão são o VEÍCULO
para bugs, até porque os desenvolvedores da Oracle não vão perder tempo
testando profundamente alguma coisa que não devia acontecer, né não ??
Muito bem : como eu tinha dito penso que a primeira coisa a se fazer é PARAR o
processo de recover do banco standby (já que com as incongruências em questão
FATALMENTE ele só tá gastando CPU à toa, não vai conseguir aplicar coisa
nenhuma)...
Isso feito, cheque se as tablespaces e datafiles tão IDÊNTICOS no PROD e no
STANDBY, com uma consulta tipo :
select T.TS#, T.name TABLESPACE_NAME, D.FILE#, D.NAME FILE_NAME, D.BYTES,
D.BLOCKS, D.STATUS FROM V$TABLESPACE T, V$DATAFILE D
WHERE T.TS# = D.TS# ORDER BY 1,3;
Isso vai te dizer se o RESTO das tablespaces e datafiles tão sincronizados
certinho, E qual é a desse tal arquivo $ORACLE_HOME/dbs/UNNAMED00167.dbf : de
repente pode até ser que ele foi criado por alguém mas no momento não está
sendo usado por tablespace nenhuma, sabe-se lá
Feito isso, SE a tal tablespace adicionada no Primary já existe no standby
(talvez criada com esse datafile loucão aí no ORACLE_HOME), drope ela no
standby, remove esse arquivo doido E os demais que se relacionam com essa
tablespace e copie os datafiles pro standby... O procedimento creio que ser
esse mesmo, ie : bota em modo de backup, copia, tira de modo backup
COM ISSO, quando futuramente vc restartar o processo de recovery do standby o
RDBMS deve ser capaz de reconhecer os datafiles que vc trouxe do primary,
atualizar o dicionário de dados E o controlfile, registrando assim corretamente
a tablespace...
Porém, antes de restartar o processo de recover, dá uma PROCURADA no ASM e
confirme se os archives que originalmente continham as sequences de redo
necessárias ainda estão em disco ou não : como outros colegas apontaram, de
repente eles podem estar em uma pasta com a data diferente, talvez : usa o FIND
no asmcmd
[]s
Chiappa #yiv1802380496 #yiv1802380496 -- #yiv1802380496ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1802380496
#yiv1802380496ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1802380496
#yiv1802380496ygrp-mkp #yiv1802380496hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv1802380496 #yiv1802380496ygrp-mkp #yiv1802380496ads
{margin-bottom:10px;}#yiv1802380496 #yiv1802380496ygrp-mkp .yiv1802380496ad
{padding:0 0;}#yiv1802380496 #yiv1802380496ygrp-mkp .yiv1802380496ad p
{margin:0;}#yiv1802380496 #yiv1802380496ygrp-mkp .yiv1802380496ad a
{color:#ff;text-decoration:none;}#yiv1802380496 #yiv1802380496ygrp-sponsor
#yiv1802380496ygrp-lc {font-family:Arial;}#yiv1802380496
#yiv1802380496ygrp-sponsor #yiv1802380496ygrp-lc #yiv1802380496hd {margin:10px
0px;font-weight:700;font-size:78%;line-h
Re: [oracle_br] Re: gap standby database
Pois é Chiappa, fiquei de cara com a situação que me encontrei. Quando um parâmetro como esse está manual e você tem dba's que atuam pela manhã/tarde e noite em diversos clientes, setar um parâmetro desse manual é para matar qualquer um. Um ponto que verifiquei foi que esse datafile que foi criado é de número 125 que se encontra em um diskgroup +DATA no primary. Verificando no standby o arquivo foi criado no $ORACLE_HOME/dbs/UNNAMED00167.dbf (arquivo esse, que alguém deve ter deletado do SO pq não existe e memso se existisse o standby nao iria reconhecer). Seria mais ou menos, assim? Primario: SQL> alter tablespace xuxa begin backup;ASMCMD> cp tbs_data01837.dbf /home/oracle/tbs_data01837 scp para o servidor standby SQL> alter tablespace xuxa endbackup; standby: SQL> alter system set standby_file_management=manual; cp /home/oracle/tbs_data01837 SQL> alter database rename file '...UNNAMED00167' to '<>'; EM ambos: alter system set standby_file_management=AUTO; standby: alter database recover managed standby database Em Sexta-feira, 14 de Abril de 2017 11:57, "jlchia...@yahoo.com.br [oracle_br]" escreveu: Blz ? Então, standby_file_management é um dos parâmetros ** críticos ** que devem ser observados num standby, junto (embora por outros motivos) com standbylogs e uns tantos outros : não observou, é kaput muitas vezes... O caso é que dentro de um redo log vc tem os bytes que foram alterados *** MAS *** também dentro deles tem o FILE NUMBER de qual datafile o redo deve ser aplicado : assim, todos os redo que foram criados do instante em que vc criou só em prod a tablespace contém um FILE NUMBER que não existe no standby. E vc não diz mas *** ESPERO *** que não tenha criado a tablespace manualmente no standby, pois nesse caso a tablespace no standby, com QUASE CERTEZA o datafile dessa tablespace ganharia um FILE NUMBER *** diferente *** daquele que tem em PROD - descompasso total, controlfile, dicionário e redo estão procurando processar um arquivo com file number X e na verdade o número dele é Y, zona completa. É POR ISSO, inclusive, que bem claramente o manual Oracle "Data Guard Concepts and Administration" no cap. 9 - Managing Physical and Snapshot Standby Databases nos diz : "Table 9-1 Primary Database Changes That Require Manual Intervention at a Physical Standby Reference Primary Database Change Action Required on Physical Standby Database Section 9.3.1 Add a datafile or create a tablespace No action is required if the STANDBY_FILE_MANAGEMENT database initialization parameter is set to AUTO. If this parameter is set to MANUAL, the new datafile must be copied to the physical standby database. " okdoc ? Assim sendo, sua primeira ação (DEPOIS de corrigir a mancada da grossa aí e deixar o parâmetro de management como deveria ser) deveria ter sido ** COPIAR ** o(s) datafile(s) E no caso, eu nunca caí nessa situação, mas IMAGINO que seria o caso de botar a tablespace em backup mode, fazer a cópia do arquivo a partir de prod para o standby via scp, ftp, o que puder/tiver disponível e depois tirar de backup mode - via de regra vc NÃO PODE sair copiando simplesmente um datafile, pois PODE SER que o RDBMS cisme de gravar nele justamente no momento que vc tá fazendo a cópia Uma vez copiado o arquivo, aí a informação de file number constante no redo, no dicionário E no control file vai em tese ficar equalizada, muito bem... Agora chegamos no ponto do REDO que deve ser aplicado em cima desse datafile : não tenho um ambiente aqui para testar mas IMAGINO que, uma vez o redo todo necessário estando disponível, é simplesmente uma questão de parar e startar de novo o processo de recovery do standby No seu caso específico, muito embora vc diga no começo da thread que "o standby nao criou a tablespace e o standby parou de aplicar, mas continou recebendo os archives da produção, realizando os backups" a sua conclusão que ele continuou "apagando os archives em disco" depende FUNDAMENTALMENTE de como está a sua política de deleção : LÓGICO que se ela estiver para deletar apenas após a Aplicação certamente os archives não vão ter sido deletados do disco enquanto não forem aplicados, e (imagino) não estavam sendo aplicados porque tinha um datafile faltante VERIFIQUE se foram ou não apagados do disco esses caretas aí sim sim sim ??? Manda um ls -l lá no local deles CASO eles tenham sim sido apagados do disco, a minha ** SUPOSIÇÃO ** (novamente, como não estou com um ambiente teste adequado aqui pra testar na prática é só uma Suposição) é que esse redo não aplicado por causa do datafile "faltante" está sendo re-archivado nos archives sendo gerados mais recentemente ainda, por isso o RMAN não deixa vc restaurar essas sequências, o redo relacionado com essas sequências está arquivado em outro archive que está em disco Minha Recomendação então é que vc (** DEPOIS *
Re: [oracle_br] Erro instalação RAC
Rodrigo, muito obrigado pelo artigo, me ajudou bastante e consegui passar do
erro. O nslookup consegue resolver todos os hosts tanto do nó1 como do nó2
(pub, priv, vip, scan), conforme o artigo mostra.
Porém, no final da instalação, nas checangens do pré-requisito me aparece o
seguinte:
Task resolv.conf Integrity FAILED Check Failed on Nodes: [rac2, rac1]
MORE DETAILS
Verification result of failed node: rac2 Details: - PRVF-5636 : The DNS
response time for an unreachable node exceeded "15000" ms on following nodes:
rac1,rac2 - Cause: The DNS response time for an unreachable node exceeded the
value specified on nodes specified. - Action: Make sure that ''options
timeout'', ''options attempts'' and ''nameserver'' entries in file resolv.conf
are proper. On HPUX these entries will be ''retrans'', ''retry'' and
''nameserver''. On Solaris these will be ''options retrans'', ''options retry''
and ''nameserver''. Make sure that the DNS server responds back to name lookup
request within the specified time when looking up an unknown host name. - ;;
connection timed out; trying next origin ;; connection timed out; no servers
could be reached - Cause: Cause Of Problem Not Available - Action: User
Action Not Available - Check for integrity of file "/etc/resolv.conf" failed
- Cause: Cause Of Problem Not Available - Action: User Action Not Available
[root@rac2 stages]# cat /etc/resolv.conf# Generated by NetworkManagersearch
localdomain#nameserver 201.17.128.247#nameserver 201.17.128.239nameserver
192.168.56.1nameserver 127.0.0.1
Em Quinta-feira, 13 de Abril de 2017 21:25, "Rodrigo Mufalani
rodr...@mufalani.com.br [oracle_br]" escreveu:
Tent seguir essa dica aqui usando esse dnsmasq
http://dbaora.com/configure-scan-dns-for-rac-11g-rac-12c-using-dnsmasq-in-oel5-oel6-2/
Get Outlook for iOS_
From: Rodrigo Mufalani
Sent: quinta-feira, abril 13, 2017 21:11
Subject: Re: [oracle_br] Erro instalação RAC
To:
Entao...
O que o instalador do Oracle faz é usar o nslookup (utilitario do linux)
para checar os nomes e se está usando dns. O que eu fiz foi pegar um script
linux pronto na net e aí troquei o nslookup original por ele, quando o
instalado do Oracle faz a chamada, ele chama o script já ajustado para simular
a resposta de um dns.
Get Outlook for iOSFrom:oracle_br@yahoogrupos.com.br
on behalf of Carlos
eduardocarloseduard...@yahoo.com [oracle_br]
Sent: Thursday, April 13, 2017 8:53:51 PM
To: oracle_br@yahoogrupos.com.br
Subject: Re: [oracle_br] Erro instalação RAC Rodrigo, obrigado pelo retorno.
Mas como estou começando meus estudos e meus aprendizados com RAC, eu não
entendi o que você quis dizer.
Em Quinta-feira, 13 de Abril de 2017 19:03, "Rodrigo
mufalanirodr...@mufalani.com.br [oracle_br]"
escreveu:
Vc renomeia o nslookup e o substitui por um shell script... da uma googlada
por esse caminho que foi assim que resolvi essa questao.
Get Outlook for iOSFrom:oracle_br@yahoogrupos.com.br
on behalf of Carlos
eduardocarloseduard...@yahoo.com [oracle_br]
Sent: Thursday, April 13, 2017 6:41:08 PM
To: Yahoo! Brazil
Subject: [oracle_br] Erro instalação RAC Cenário:
GI and DB 12cR1OEL 6.9Virtual BOX (sem servidor DNS/GNS)
Dois nós
# 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
Obs: Em cada VM, eu tenho 3 adaptadores de rede, a primeira NAT, a segunda Host
only (publica) e a terceira Internal network (privada)
As maquinas RAC1 e RAC2 se comunicam pela rede PUBLICA e pela rede PRIVADA
(pingando pelo IP ou pelo host).
Mas se eu pingar o endereço virtual ou pelo SCAN, não funciona.
Quando eu chego na instalação do GI na parte GRID PLUG and PLAY information, o
erro abaixo é gerado:
[INS-40718]
Single Client Access Name (SCAN): rac-scan.localdomain could not be resolved.
Alguém sabe como posso resolver essa situação?
#yiv8688802151 #yiv8688802151 -- #yiv8688802151ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8688802151
#yiv8688802151ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8688802151
#yiv8688802151ygrp-mkp #yiv8688802151hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv8688802151 #yiv8688802151ygrp-mkp #yiv8688802151ads
{margin-bottom:10px;}#yiv8688802151 #yiv8688802151ygrp-mkp .yiv8688802151ad
{padding:0 0;}#yiv8688802151 #yiv8688802151ygrp-mkp .yiv8688802151ad p
{margin:0;}#yiv8688802151 #yiv8688802151ygrp-mkp .yiv8688802151ad a
{color:#ff;text-decoration:none;}#yiv8688802151 #yiv8688802151ygrp-sponsor
#yiv8688802151ygrp
[oracle_br] gap standby database
Cenário:
Oracle EE 11.2.0.4 Linux 6
AMBIENTE DE PRODUÇÃO COM GAP NO STADNBY DATABASE (BACKUP é FEITO NO FÍSICO
STANDBY)
Checando a consulta abaixo, foi verificado que último archive aplicado foi do
dia 06/04, mas que em compensação foram recebidos todos os archives. ( O que
aconceteceu nesse caso, é que existiu a adição de uma nova tablespace na
produção e o parâmetro standby_file_management estava como MANUAL,
consequentemente o standby nao criou a tablespace e o standby parou de aplicar,
mas continou recebendo os archives da produção, realizando os backups e
apagando os archives em disco)
LOGS TIME --Last applied :
06-APR-17:01:07:31Last received : 14-APR-17:03:01:57
Thread Last Sequence Received **Last Sequence Applied**
Difference-- -- - --
1 323820 **320312** 3508 2
1711 1711 0
Alguns archives estão em backup na fita e outros estão em disco, conforme
abaixo:
+FLASH/STANDBY/ARCHIVELOG2017_04_11/2017_04_12/2017_04_13/2017_04_14/ RMAN>
LIST BACKUP OF ARCHIVELOG FROM SEQUENCE 320312; BS Key Size Device
Type Elapsed Time Completion Time--- -- ---
---14253 7.50G SBT_TAPE 00:23:24 06/04/2017
15:12:10 BP Key: 14253 Status: AVAILABLE Compressed: NO Tag:
TAG20170406T123644 Handle: RMAN_AL__14446_1_940603726 Media: @aaab6
List of Archived Logs in backup set 14253 Thrd Seq Low SCN Low Time
Next SCN Next Time --- -- ---
-- - 1 320312 3940054443061 06/04/2017 01:07:31
3940054530795 06/04/2017 01:10:45 1 320313 3940054530795 06/04/2017
01:10:45 3940054578516 06/04/2017 01:12:21 1 320314 3940054578516
06/04/2017 01:12:21 3940054584627 06/04/2017 01:12:44 1 320315
3940054584627 06/04/2017 01:12:44 3940054590378 06/04/2017 01:13:12 1
320316 3940054590378 06/04/2017 01:13:12 3940054595869 06/04/2017 01:13:44 1
320317 3940054595869 06/04/2017 01:13:44 3940054600753 06/04/2017 01:14:10
.
BS Key Size Device Type Elapsed Time Completion Time--- --
--- ---14778 9.29G SBT_TAPE
00:29:59 14/04/2017 01:39:40 BP Key: 14778 Status: AVAILABLE
Compressed: NO Tag: TAG20170414T010940 Handle:
RMAN_AL_14985_1_941245781 Media: @aaab6
List of Archived Logs in backup set 14778 Thrd Seq Low SCN Low Time
Next SCN Next Time --- -- ---
-- - 1 323773 3940814732761 14/04/2017 00:09:23
3940814946818 14/04/2017 00:10:45 1 323774 3940814946818 14/04/2017
00:10:45 3940815012259 14/04/2017 00:11:57 1 323775 3940815012259
14/04/2017 00:11:57 3940815090888 14/04/2017 00:13:13 1 323776
3940815090888 14/04/2017 00:13:13 3940815186248 14/04/2017 00:14:32 1
323777 3940815186248 14/04/2017 00:14:32 3940815247715 14/04/2017 00:15:44 1
323778 3940815247715 14/04/2017 00:15:44 3940815377351 14/04/2017 00:16:59
1 323779 3940815377351 14/04/2017 00:16:59 3940815446649 14/04/2017
00:18:08 1 323780 3940815446649 14/04/2017 00:18:08 3940815485204
14/04/2017 00:19:06 1 323781 3940815485204 14/04/2017 00:19:06
3940815550196 14/04/2017 00:20:03 1 323782 3940815550196 14/04/2017
00:20:03 3940815626653 14/04/2017 00:20:55 1 323783 3940815626653
14/04/2017 00:20:55 3940815670450 14/04/2017 00:21:49 1 323784
3940815670450 14/04/2017 00:21:49 3940815699775 14/04/2017 00:22:37 1
323785 3940815699775 14/04/2017 00:22:37 3940815766143 14/04/2017 00:23:32 1
323786 3940815766143 14/04/2017 00:23:32 3940815804012 14/04/2017 00:24:29
1 323787 3940815804012 14/04/2017 00:24:29 3940815853125 14/04/2017
00:25:14 1 323788 3940815853125 14/04/2017 00:25:14 3940815908048
14/04/2017 00:25:56 1 323789 3940815908048 14/04/2017 00:25:56
3940815947781 14/04/2017 00:26:39 1 323790 3940815947781 14/04/2017
00:26:39 3940815977518 14/04/2017 00:27:12 1 323791 3940815977518
14/04/2017 00:27:12 3940816005791 14/04/2017 00:27:51 1 323792
3940816005791 14/04/2017 00:27:51 3940816057310 14/04/2017 00:28:33 Percendo
a lista de archives acima, percebe-se que a sequence **320312** (que foi a
ultima aplicada pelo standby) foi gerada no dia 06/04, que foi o dia que o
standby parou de aplicar os archives.
Para resolver o GAP, eu quis fazer o restore de todos os archives a partir da
sequence 320312 para o disco,realizar o catalog, para o standby começar o
recovery, porém não seguiu como planejado: run{set archivelog destination to
'/backup/arch';CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS
'ENV=(NB_ORA_SERV=xxx, NB_ORA_CLIENT=xxx)';restore archivelog from sequence
320312 un
Re: [oracle_br] Erro instalação RAC
Rodrigo, obrigado pelo retorno.
Mas como estou começando meus estudos e meus aprendizados com RAC, eu não
entendi o que você quis dizer.
Em Quinta-feira, 13 de Abril de 2017 19:03, "Rodrigo Mufalani
rodr...@mufalani.com.br [oracle_br]" escreveu:
Vc renomeia o nslookup e o substitui por um shell script... da uma
googlada por esse caminho que foi assim que resolvi essa questao.
Get Outlook for iOSFrom: oracle_br@yahoogrupos.com.br
on behalf of Carlos Eduardo
carloseduard...@yahoo.com [oracle_br]
Sent: Thursday, April 13, 2017 6:41:08 PM
To: Yahoo! Brazil
Subject: [oracle_br] Erro instalação RAC Cenário:
GI and DB 12cR1OEL 6.9Virtual BOX (sem servidor DNS/GNS)
Dois nós
# 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
Obs: Em cada VM, eu tenho 3 adaptadores de rede, a primeira NAT, a segunda Host
only (publica) e a terceira Internal network (privada)
As maquinas RAC1 e RAC2 se comunicam pela rede PUBLICA e pela rede PRIVADA
(pingando pelo IP ou pelo host).
Mas se eu pingar o endereço virtual ou pelo SCAN, não funciona.
Quando eu chego na instalação do GI na parte GRID PLUG and PLAY information, o
erro abaixo é gerado:
[INS-40718]
Single Client Access Name (SCAN): rac-scan.localdomain could not be resolved.
Alguém sabe como posso resolver essa situação?
#yiv7524536005 #yiv7524536005 -- #yiv7524536005ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7524536005
#yiv7524536005ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7524536005
#yiv7524536005ygrp-mkp #yiv7524536005hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv7524536005 #yiv7524536005ygrp-mkp #yiv7524536005ads
{margin-bottom:10px;}#yiv7524536005 #yiv7524536005ygrp-mkp .yiv7524536005ad
{padding:0 0;}#yiv7524536005 #yiv7524536005ygrp-mkp .yiv7524536005ad p
{margin:0;}#yiv7524536005 #yiv7524536005ygrp-mkp .yiv7524536005ad a
{color:#ff;text-decoration:none;}#yiv7524536005 #yiv7524536005ygrp-sponsor
#yiv7524536005ygrp-lc {font-family:Arial;}#yiv7524536005
#yiv7524536005ygrp-sponsor #yiv7524536005ygrp-lc #yiv7524536005hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7524536005
#yiv7524536005ygrp-sponsor #yiv7524536005ygrp-lc .yiv7524536005ad
{margin-bottom:10px;padding:0 0;}#yiv7524536005 #yiv7524536005actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7524536005
#yiv7524536005activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7524536005
#yiv7524536005activity span {font-weight:700;}#yiv7524536005
#yiv7524536005activity span:first-child
{text-transform:uppercase;}#yiv7524536005 #yiv7524536005activity span a
{color:#5085b6;text-decoration:none;}#yiv7524536005 #yiv7524536005activity span
span {color:#ff7900;}#yiv7524536005 #yiv7524536005activity span
.yiv7524536005underline {text-decoration:underline;}#yiv7524536005
.yiv7524536005attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv7524536005 .yiv7524536005attach div a
{text-decoration:none;}#yiv7524536005 .yiv7524536005attach img
{border:none;padding-right:5px;}#yiv7524536005 .yiv7524536005attach label
{display:block;margin-bottom:5px;}#yiv7524536005 .yiv7524536005attach label a
{text-decoration:none;}#yiv7524536005 blockquote {margin:0 0 0
4px;}#yiv7524536005 .yiv7524536005bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv7524536005
.yiv7524536005bold a {text-decoration:none;}#yiv7524536005 dd.yiv7524536005last
p a {font-family:Verdana;font-weight:700;}#yiv7524536005 dd.yiv7524536005last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv7524536005
dd.yiv7524536005last p span.yiv7524536005yshortcuts
{margin-right:0;}#yiv7524536005 div.yiv7524536005attach-table div div a
{text-decoration:none;}#yiv7524536005 div.yiv7524536005attach-table
{width:400px;}#yiv7524536005 div.yiv7524536005file-title a, #yiv7524536005
div.yiv7524536005file-title a:active, #yiv7524536005
div.yiv7524536005file-title a:hover, #yiv7524536005 div.yiv7524536005file-title
a:visited {text-decoration:none;}#yiv7524536005 div.yiv7524536005photo-title a,
#yiv7524536005 div.yiv7524536005photo-title a:active, #yiv7524536005
div.yiv7524536005photo-title a:hover, #yiv7524536005
div.yiv7524536005photo-title a:visited {text-decoration:none;}#yiv7524536005
div#yiv7524536005ygrp-mlmsg #yiv7524536005ygrp-msg p a
span.yiv7524536005yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv7524536005
.yiv7524536005gr
[oracle_br] Erro instalação RAC
Cenário: GI and DB 12cR1OEL 6.9Virtual BOX (sem servidor DNS/GNS) Dois nós # 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 Obs: Em cada VM, eu tenho 3 adaptadores de rede, a primeira NAT, a segunda Host only (publica) e a terceira Internal network (privada) As maquinas RAC1 e RAC2 se comunicam pela rede PUBLICA e pela rede PRIVADA (pingando pelo IP ou pelo host). Mas se eu pingar o endereço virtual ou pelo SCAN, não funciona. Quando eu chego na instalação do GI na parte GRID PLUG and PLAY information, o erro abaixo é gerado: [INS-40718] Single Client Access Name (SCAN): rac-scan.localdomain could not be resolved. Alguém sabe como posso resolver essa situação?
Re: [oracle_br] Desaster Recovery
Chiappa, tudo bem?Estou reabrindo a thread pq fiquei ainda com algumas dúvidas, poderia me ajudar? Analisando o seu procedimento, notei o seguinte: Ckp SCN dos seus datafiles: 15092588 Ckp SCN do seu controlfile: 15092616 Ckp SCN do seu ultimo archivelog: 15092622 (SCN -1) = 15092621 Algumas perguntas: a) Quando você diz: "o truque é que se eu pedir RECOVER sem informar SCN, ele vai tentar restaurar até o SCN do controlfile, SCN esse que estava no redo online, que ** nunca ** é backupeado no HOT..." Se o SCN do controlfile é o SCN que estava no Redo que nunca é backupeado, pq o SCN do seu Arhivelog 15092621 é maior que o SCN do seu controlfile 15092616 ? b) Analisei o seu list backup antes do restore do controlfile, e o list backup após o restore do controlfile e notei o seguinte: No primeiro list backup (antes de vc realizar o cenário de restore/recovery) aparece o SCN do archivelog que vc utiliza na recuperação "recover database until scn 15092621" BS Key Size Device Type Elapsed Time Completion Time--- -- --- ---7 9.50K DISK 00:00:00 15-MAR-17 BP Key: 7 Status: AVAILABLE Compressed: NO Tag: TAG20170315T185107 Piece Name: /home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2017_03_15/o1_mf_a_TAG20170315T185107_ddmftcjj_.bkp List of Archived Logs in backup set 7 Thrd Seq Low SCN Low Time Next SCN Next Time --- -- - -- - 1 667 15092582 15-MAR-17 15092622 15-MAR-17 Mas após o restore do controlfile quando você envia o list backup, apenas aparecem o backup set 3, 4 e 5. O meu questionamento aqui é o seguinte: Em um cenário do mundo real, quando se tem um crash desse tipo e você não realizou um list backup anterior, no qual foi mostrado o backup set de número 7 com o último archivelog, no momento que você restaura o controlfile, como você sabe que aquele backup do archivelog existe se o mesmo não apareceu no segundo list backup após o restore do controlfile? Em Segunda-feira, 20 de Março de 2017 22:53, "Carlos Eduardo carloseduard...@yahoo.com [oracle_br]" escreveu: Mais uma vez, meu muito obrigado, Chiappa. Obrigado pelas dicas e pelos conselhos, sao muito bem vindos. Irei sim, realizar cenários de restore/recover mais complexos, como por exemplo: 1 - Fazer um restore de um backup antigo de uma semana atrás, como vc mesmo propos. 2- Backupear um database em um hostname e restaurar em um outros host com file systems divergentes ou de file system para ASM e vice versa. 3 - Restaurar/recover de um backup que se tenha perdido de um determinado archive de SCN x antes que o mesmo tenha sido backupeado. etc E qualquer dúvida posto aqui para você me ajudar, Obrigado :) Em Segunda-feira, 20 de Março de 2017 10:24, "jlchia...@yahoo.com.br [oracle_br]" escreveu: Blz... Agora é partir pros criar cenários mais complexos (como fazer um backup + restore de backup mais antigo que vc tiver, restore envolvendo backups incrementais - com e sem Block Changing Track -, diferenciais e cumulativos), recover point-in-time recover E em paralelo a isso se não o fez vc VAI começar a levantar as rotinas de backup que possui hoje para tentar restores de testes - Apenas e Tão Somente assim, NA Prática, ie, tentando restaurar num servidor não-prod algum backup de PROD é que vc vai descobrir os erros operacionais e de processo, tipo, backups que neguim não manteve registro do DBID, que não tem em mãos a sequência ** EXATA ** dos archives porque antes do backup database rolou um backup delete input dos archives necessários, que por qualquer motivo algum dos datafiles tá com um SCN ** extremamente antigo ** registrado nele e ninguém sabia), backups antigos que estão na fita há um LONGO tempo sem ser usado - não é incomum a fita 'grudar' e/ou ficar ressecada e quebradiça se ficar enrolada no cartucho há longuíssimo tempo, parada, e coisas assimAté por isso em várias Empresas por onde passei que eram da área Financeira e que tinham SLAs muito exatamente precisos sobre Recuperabilidade, bem como Multas imensamente impossíveis se não os cumprir, além de vc ter *** MAIS *** de uma Cópia de cada backup em fitas diferentes (a regra repito é backup, se vc tem um só vc NÂO TEM NENHUM, na verdade) , era comum o Rodízio, tipo : a cada x meses vc voltava o backup, depois esses arquivos restaurados iam pra Outra fita com a fita Original voltando ao pool de uso Quantos ciclos de reuso a fita aguenta confiavelmente antes de ser descartada, qual esse intervalo e questões assim são Específicas pra cada ambiente/hardware, não dá pra generalizar, mas vc TEM que se assegurar que Existe algo assim... Garanto que quando vc for mesmo fazer os restores+recovers reais para testar é bem capaz de vc vai achar falhas do t
Re: [oracle_br] Envio de e-mail
Ok Fabio, irei enviar uma mensagem para você no seu artigo. Obrigado.
Em Quinta-feira, 23 de Março de 2017 7:07, "Fabio Prado fbifa...@gmail.com
[oracle_br]" escreveu:
Bom dia CArlos,
Sobre a sua dúvida dos parâmetros deixe um comentário lá no meu artigo que
eu te respondo e te ajudo por lá, ok?
Quanto ao enviar CSV, veja o artigo
http://www.fabioprado.net/2014/07/gerando-arquivos-dsv-com-plsql.html.
[]s
Fábio Prado
www.fabioprado.net"Compartilhando conhecimentos e treinando profissionais em
Bancos de Dados Oracle"
Em 23 de março de 2017 04:13, Carlos Eduardo carloseduard...@yahoo.com
[oracle_br] escreveu:
Cenário: Oracle EE 11.2.0.4
Bom dia a todos do grupo!
Preciso de uma rotina que envie e-mail *COM ANEXO* para um determinado cliente
quando houver lock em sua base de dados.
Quase toda a rotina já foi desenvolvida:
a) A procedure que coleta os locks consultado as v$ e alimenta uma tabela com
as informações necessárias b) o JOB que executa a procedure de tempos em tempos.
Consultando o artigo do Fábio Prado como enviar e-mail nos links abaixo:
Enviando e-mails com PL/SQL em Bancos de Dados Oracle
|
|
|
| ||
|
|
|
| |
Enviando e-mails com PL/SQL em Bancos de Dados Oracle
De Fábio Prado Um blog contendo artigos, treinamentos e dicas sobre Bancos de
Dados Oracle | |
|
|
Enviando e-mails com PL/SQL em Bancos de Dados Oracle - Parte 2
|
| |
Enviando e-mails com PL/SQL em Bancos de Dados Oracle - Parte 2
De Fábio Prado Um blog contendo artigos, treinamentos e dicas sobre Bancos de
Dados Oracle | |
|
DECLARE
v_CLOB CLOB;
BEGIN
PKG_ENVIA_EMAIL.SP_ENVIAR_ EMAIL_COM_ANEXO (P_ASSUNTO => 'Assunto do
e-mail',
P_MSG => 'Mensagem',
P_EMAIL_ORIGEM => 'ora...@oracle.com',
P_EMAIL_DESTINO => 'fbifabio@ gmail.com, j...@oracle.com',
P_EMAIL_CC_DESTINO => 'z...@oracle.com, j...@oracle.com',
P_EMAIL_CCO_DESTINO => null,
P_FILENAME => 'arquivo.txt',
P_ANEXO => v_CLOB, -- variável CLOB c/ texto do arquivo
P_ATTACH_MIME => 'text/plain; charset=iso-8859-1',
P_SMTP_SERVER => 'smtp.empresa.com.br',
P_SMTP_PORT => 25);
END;
Fiquei com dúvida nos parâmetros P_ANEXO, P_ATTACH_MIME e P_FILENAME
Uma outra coisa é como vou fazer para criar em um arquivo .csv (excel) e
envia-lo por e-mail para o cliente com o conteúdo da tabela abaixo:
create table MONITORA.ROWLOCK( RLODATE DATE, SID_BLOCK
NUMBER(6), SERIAL_BLOCK NUMBER(6), USER_BLOCK VARCHAR2(30),
MODULE_BLOCK VARCHAR2(50), PROGRAM_BLOCK VARCHAR2(50), TERMINAL_BLOCK
VARCHAR2(50), SID_WAIT NUMBER(6), SERIAL_WAIT NUMBER(6),
USER_WAIT VARCHAR2(30), MODULE_WAIT VARCHAR2(50), PROGRAM_WAIT
VARCHAR2(50), TERMINAL_WAIT VARCHAR2(50), SECONDS_IN_WAIT NUMBER(6),
EVENT_WAIT VARCHAR2(64), OBJ_LOCADO VARCHAR2(60), ROWID_WAIT
VARCHAR2(30), OBJETO_PLSQL VARCHAR2(60), OBJETO_TYPE VARCHAR2(30),
TEXTO_SQL CLOB);
que já terá as informações necessárias.
Alguém pode ajudar nessa missão?
Só para constar que e minha dúvida é exatamente nessa package como seria o
valor dos três parâmetros e como eu criaria o arquivo .csv referente aos dados
da tabela acima.
#yiv4383169936 #yiv4383169936 -- #yiv4383169936ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4383169936
#yiv4383169936ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4383169936
#yiv4383169936ygrp-mkp #yiv4383169936hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv4383169936 #yiv4383169936ygrp-mkp #yiv4383169936ads
{margin-bottom:10px;}#yiv4383169936 #yiv4383169936ygrp-mkp .yiv4383169936ad
{padding:0 0;}#yiv4383169936 #yiv4383169936ygrp-mkp .yiv4383169936ad p
{margin:0;}#yiv4383169936 #yiv4383169936ygrp-mkp .yiv4383169936ad a
{color:#ff;text-decoration:none;}#yiv4383169936 #yiv4383169936ygrp-sponsor
#yiv4383169936ygrp-lc {font-family:Arial;}#yiv4383169936
#yiv4383169936ygrp-sponsor #yiv4383169936ygrp-lc #yiv4383169936hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4383169936
#yiv4383169936ygrp-sponsor #yiv4383169936ygrp-lc .yiv4383169936ad
{margin-bottom:10px;padding:0 0;}#yiv4383169936 #yiv4383169936actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4383169936
#yiv4383169936activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4383169936
#yiv4383169936activity span {font-weight:700;}#yiv4383169936
#yiv4383169936activity span:first-child
{text-transform:uppercase;}#yiv4383169936 #yiv4383169936activity span a
{color:#5085b6;text-decoration:none;}#yiv4383169936 #yiv4383169936activity span
span {color:#ff7900;}#yiv4383169936 #yiv4383169
[oracle_br] Envio de e-mail
Cenário: Oracle EE 11.2.0.4 Bom dia a todos do grupo! Preciso de uma rotina que envie e-mail *COM ANEXO* para um determinado cliente quando houver lock em sua base de dados. Quase toda a rotina já foi desenvolvida: a) A procedure que coleta os locks consultado as v$ e alimenta uma tabela com as informações necessárias b) o JOB que executa a procedure de tempos em tempos. Consultando o artigo do Fábio Prado como enviar e-mail nos links abaixo: Enviando e-mails com PL/SQL em Bancos de Dados Oracle | | | | || | | | | | Enviando e-mails com PL/SQL em Bancos de Dados Oracle De Fábio Prado Um blog contendo artigos, treinamentos e dicas sobre Bancos de Dados Oracle | | | | Enviando e-mails com PL/SQL em Bancos de Dados Oracle - Parte 2 | | | Enviando e-mails com PL/SQL em Bancos de Dados Oracle - Parte 2 De Fábio Prado Um blog contendo artigos, treinamentos e dicas sobre Bancos de Dados Oracle | | | DECLARE v_CLOB CLOB; BEGIN PKG_ENVIA_EMAIL.SP_ENVIAR_EMAIL_COM_ANEXO (P_ASSUNTO => 'Assunto do e-mail', P_MSG => 'Mensagem', P_EMAIL_ORIGEM => 'ora...@oracle.com', P_EMAIL_DESTINO => 'fbifa...@gmail.com, j...@oracle.com', P_EMAIL_CC_DESTINO => 'z...@oracle.com, j...@oracle.com', P_EMAIL_CCO_DESTINO => null, P_FILENAME => 'arquivo.txt', P_ANEXO => v_CLOB, -- variável CLOB c/ texto do arquivo P_ATTACH_MIME => 'text/plain; charset=iso-8859-1', P_SMTP_SERVER => 'smtp.empresa.com.br', P_SMTP_PORT => 25); END; Fiquei com dúvida nos parâmetros P_ANEXO, P_ATTACH_MIME e P_FILENAME Uma outra coisa é como vou fazer para criar em um arquivo .csv (excel) e envia-lo por e-mail para o cliente com o conteúdo da tabela abaixo: create table MONITORA.ROWLOCK( RLODATE DATE, SID_BLOCK NUMBER(6), SERIAL_BLOCK NUMBER(6), USER_BLOCK VARCHAR2(30), MODULE_BLOCK VARCHAR2(50), PROGRAM_BLOCK VARCHAR2(50), TERMINAL_BLOCK VARCHAR2(50), SID_WAIT NUMBER(6), SERIAL_WAIT NUMBER(6), USER_WAIT VARCHAR2(30), MODULE_WAIT VARCHAR2(50), PROGRAM_WAIT VARCHAR2(50), TERMINAL_WAIT VARCHAR2(50), SECONDS_IN_WAIT NUMBER(6), EVENT_WAIT VARCHAR2(64), OBJ_LOCADO VARCHAR2(60), ROWID_WAIT VARCHAR2(30), OBJETO_PLSQL VARCHAR2(60), OBJETO_TYPE VARCHAR2(30), TEXTO_SQL CLOB); que já terá as informações necessárias. Alguém pode ajudar nessa missão? Só para constar que e minha dúvida é exatamente nessa package como seria o valor dos três parâmetros e como eu criaria o arquivo .csv referente aos dados da tabela acima.
Re: [oracle_br] Re: Política de deleção não funciona
Problema resolvido, Chiappa.
Conforme sua solicitação, criei um script shell na crontab do oracle deletando
todos os archives do primary database que foram aplicados no standby.:)
Em Terça-feira, 21 de Março de 2017 17:13, "Carlos Eduardo
carloseduard...@yahoo.com [oracle_br]" escreveu:
Obrigado mais uma vez mestre Chiappa. Irei implementar um job para
executar o delete obsolete dos archives no primary database e posto aqui o
resultado. Vou seguir a sua sugestao sim. Obrigado.
Em Terça-feira, 21 de Março de 2017 11:06, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Ah, só uma obs mais : num cenário do tipo, já que é no standby que vc faz
o backup eu teria no primary DELETE APPLIED ON ALL STANDBY a policy (para que
imediatamente após ter sido aplicado nos standby o RMAN já marque o archive
como passível de remoção pelo próximo comando de DELETE que receber), MAS (dada
a importância de se ter múltiplos backups como eu já disse em posts anteriores
de outras threads), ) no standby eu só deletaria com BACKUPED 3 TIMES
[]s
Chiappa
#yiv9441196805 #yiv9441196805 -- #yiv9441196805ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9441196805
#yiv9441196805ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9441196805
#yiv9441196805ygrp-mkp #yiv9441196805hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9441196805 #yiv9441196805ygrp-mkp #yiv9441196805ads
{margin-bottom:10px;}#yiv9441196805 #yiv9441196805ygrp-mkp .yiv9441196805ad
{padding:0 0;}#yiv9441196805 #yiv9441196805ygrp-mkp .yiv9441196805ad p
{margin:0;}#yiv9441196805 #yiv9441196805ygrp-mkp .yiv9441196805ad a
{color:#ff;text-decoration:none;}#yiv9441196805 #yiv9441196805ygrp-sponsor
#yiv9441196805ygrp-lc {font-family:Arial;}#yiv9441196805
#yiv9441196805ygrp-sponsor #yiv9441196805ygrp-lc #yiv9441196805hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9441196805
#yiv9441196805ygrp-sponsor #yiv9441196805ygrp-lc .yiv9441196805ad
{margin-bottom:10px;padding:0 0;}#yiv9441196805 #yiv9441196805actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9441196805
#yiv9441196805activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9441196805
#yiv9441196805activity span {font-weight:700;}#yiv9441196805
#yiv9441196805activity span:first-child
{text-transform:uppercase;}#yiv9441196805 #yiv9441196805activity span a
{color:#5085b6;text-decoration:none;}#yiv9441196805 #yiv9441196805activity span
span {color:#ff7900;}#yiv9441196805 #yiv9441196805activity span
.yiv9441196805underline {text-decoration:underline;}#yiv9441196805
.yiv9441196805attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9441196805 .yiv9441196805attach div a
{text-decoration:none;}#yiv9441196805 .yiv9441196805attach img
{border:none;padding-right:5px;}#yiv9441196805 .yiv9441196805attach label
{display:block;margin-bottom:5px;}#yiv9441196805 .yiv9441196805attach label a
{text-decoration:none;}#yiv9441196805 blockquote {margin:0 0 0
4px;}#yiv9441196805 .yiv9441196805bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9441196805
.yiv9441196805bold a {text-decoration:none;}#yiv9441196805 dd.yiv9441196805last
p a {font-family:Verdana;font-weight:700;}#yiv9441196805 dd.yiv9441196805last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9441196805
dd.yiv9441196805last p span.yiv9441196805yshortcuts
{margin-right:0;}#yiv9441196805 div.yiv9441196805attach-table div div a
{text-decoration:none;}#yiv9441196805 div.yiv9441196805attach-table
{width:400px;}#yiv9441196805 div.yiv9441196805file-title a, #yiv9441196805
div.yiv9441196805file-title a:active, #yiv9441196805
div.yiv9441196805file-title a:hover, #yiv9441196805 div.yiv9441196805file-title
a:visited {text-decoration:none;}#yiv9441196805 div.yiv9441196805photo-title a,
#yiv9441196805 div.yiv9441196805photo-title a:active, #yiv9441196805
div.yiv9441196805photo-title a:hover, #yiv9441196805
div.yiv9441196805photo-title a:visited {text-decoration:none;}#yiv9441196805
div#yiv9441196805ygrp-mlmsg #yiv9441196805ygrp-msg p a
span.yiv9441196805yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9441196805
.yiv9441196805green {color:#628c2a;}#yiv9441196805 .yiv9441196805MsoNormal
{margin:0 0 0 0;}#yiv9441196805 o {font-size:0;}#yiv9441196805
#yiv9441196805photos div {float:left;width:72px;}#yiv9441196805
#yiv9441196805photos div div {border:1px solid
#66;height:62px;overflow:hidden;width:62px;}#yiv9441196805
#yiv9441196805photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9441196805
#yiv9441196805reco-category {font-size:77%;}#yiv9441196805
#yiv9441196805reco-desc {font-size:77%;}#yiv9441196805 .yiv9441196805replbq
{margin:4px;}#yiv9441196805 #yiv94411
Re: [oracle_br] Re: Política de deleção não funciona
Obrigado mais uma vez mestre Chiappa. Irei implementar um job para executar o
delete obsolete dos archives no primary database e posto aqui o resultado. Vou
seguir a sua sugestao sim. Obrigado.
Em Terça-feira, 21 de Março de 2017 11:06, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Ah, só uma obs mais : num cenário do tipo, já que é no standby que vc faz
o backup eu teria no primary DELETE APPLIED ON ALL STANDBY a policy (para que
imediatamente após ter sido aplicado nos standby o RMAN já marque o archive
como passível de remoção pelo próximo comando de DELETE que receber), MAS (dada
a importância de se ter múltiplos backups como eu já disse em posts anteriores
de outras threads), ) no standby eu só deletaria com BACKUPED 3 TIMES
[]s
Chiappa #yiv9951096576 #yiv9951096576 -- #yiv9951096576ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9951096576
#yiv9951096576ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9951096576
#yiv9951096576ygrp-mkp #yiv9951096576hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9951096576 #yiv9951096576ygrp-mkp #yiv9951096576ads
{margin-bottom:10px;}#yiv9951096576 #yiv9951096576ygrp-mkp .yiv9951096576ad
{padding:0 0;}#yiv9951096576 #yiv9951096576ygrp-mkp .yiv9951096576ad p
{margin:0;}#yiv9951096576 #yiv9951096576ygrp-mkp .yiv9951096576ad a
{color:#ff;text-decoration:none;}#yiv9951096576 #yiv9951096576ygrp-sponsor
#yiv9951096576ygrp-lc {font-family:Arial;}#yiv9951096576
#yiv9951096576ygrp-sponsor #yiv9951096576ygrp-lc #yiv9951096576hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9951096576
#yiv9951096576ygrp-sponsor #yiv9951096576ygrp-lc .yiv9951096576ad
{margin-bottom:10px;padding:0 0;}#yiv9951096576 #yiv9951096576actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9951096576
#yiv9951096576activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9951096576
#yiv9951096576activity span {font-weight:700;}#yiv9951096576
#yiv9951096576activity span:first-child
{text-transform:uppercase;}#yiv9951096576 #yiv9951096576activity span a
{color:#5085b6;text-decoration:none;}#yiv9951096576 #yiv9951096576activity span
span {color:#ff7900;}#yiv9951096576 #yiv9951096576activity span
.yiv9951096576underline {text-decoration:underline;}#yiv9951096576
.yiv9951096576attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9951096576 .yiv9951096576attach div a
{text-decoration:none;}#yiv9951096576 .yiv9951096576attach img
{border:none;padding-right:5px;}#yiv9951096576 .yiv9951096576attach label
{display:block;margin-bottom:5px;}#yiv9951096576 .yiv9951096576attach label a
{text-decoration:none;}#yiv9951096576 blockquote {margin:0 0 0
4px;}#yiv9951096576 .yiv9951096576bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9951096576
.yiv9951096576bold a {text-decoration:none;}#yiv9951096576 dd.yiv9951096576last
p a {font-family:Verdana;font-weight:700;}#yiv9951096576 dd.yiv9951096576last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9951096576
dd.yiv9951096576last p span.yiv9951096576yshortcuts
{margin-right:0;}#yiv9951096576 div.yiv9951096576attach-table div div a
{text-decoration:none;}#yiv9951096576 div.yiv9951096576attach-table
{width:400px;}#yiv9951096576 div.yiv9951096576file-title a, #yiv9951096576
div.yiv9951096576file-title a:active, #yiv9951096576
div.yiv9951096576file-title a:hover, #yiv9951096576 div.yiv9951096576file-title
a:visited {text-decoration:none;}#yiv9951096576 div.yiv9951096576photo-title a,
#yiv9951096576 div.yiv9951096576photo-title a:active, #yiv9951096576
div.yiv9951096576photo-title a:hover, #yiv9951096576
div.yiv9951096576photo-title a:visited {text-decoration:none;}#yiv9951096576
div#yiv9951096576ygrp-mlmsg #yiv9951096576ygrp-msg p a
span.yiv9951096576yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9951096576
.yiv9951096576green {color:#628c2a;}#yiv9951096576 .yiv9951096576MsoNormal
{margin:0 0 0 0;}#yiv9951096576 o {font-size:0;}#yiv9951096576
#yiv9951096576photos div {float:left;width:72px;}#yiv9951096576
#yiv9951096576photos div div {border:1px solid
#66;height:62px;overflow:hidden;width:62px;}#yiv9951096576
#yiv9951096576photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9951096576
#yiv9951096576reco-category {font-size:77%;}#yiv9951096576
#yiv9951096576reco-desc {font-size:77%;}#yiv9951096576 .yiv9951096576replbq
{margin:4px;}#yiv9951096576 #yiv9951096576ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv9951096576 #yiv9951096576ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv9951096576
#yiv9951096576ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv9951096576
#yiv9951096576ygrp-mlmsg select, #yiv9951096576 input, #yiv995
[oracle_br] Política de deleção não funciona
Cenário:Primary database 11.2.0.4Standby físico (active dataguard) 11.2.0.4 Possuo um active dataguard (um standby fisico aberto somente leitura aplicando os archives) **aonde são realizados os backups do rman**. OU seja, nenhum backup do rman é feito na produção, todos os backups são realizados no standby. ==> O meu problema É: A política de deleção de archive automática *não funciona no primary database*, porém "funciona" no standby database, isso faz com que a área de archive esteja estourando com uma frequencia alta no primary database e tenha que ter interferência manual do DBA. Esse problema está dificultando nosso trabalho, pois a média de geração de redo por dia fica em torno de 60Gb. Segue: ==> PRIMARY DATABASE política de deleção de archive -> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY; log_archive_dest_2 string service=prod_st obs: só existe apenas esse standby na configuração. ==> STANDBY DATABASE CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default No standby não possui política de deleção do archives no RMAN, porém o script de backup que é executado no standby possui o "delete input" após os backups dos archives. -- TROUBLESHOOTING Realizando uma consulta no stanby *PENSEI* que o sincronismo estava com problema, pelo resultado da consulta abaixo: -- Ultimo archive aplicadoSELECT 'Last applied : ' Logs, To_char(next_time, 'DD-MON-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-MON-YY:HH24:MI:SS') TimeFROM v$archived_logWHERE sequence# = (SELECT Max(sequence#) FROM v$archived_log); LOGS TIME --Last applied : 19-MAR-17:01:53:24Last received : 19-MAR-17:01:59:11 Porém, no database broker ele me retorna que a configuração está OK. Criei uma tabela de teste no primary e inseri alguns registros, no standby a tabela foi criada rapidamente com os registros inseridos. Outro teste que fiz foi: Realizei um switchover no primary, verifiquei no alert do standby que estava tudo ok, como segue abaixo: Tue Mar 21 01:10:06 2017RFS[1]: Selected log 62 for thread 2 sequence 432 dbid -98229520 branch 614228627Tue Mar 21 01:10:07 2017Media Recovery Waiting for thread 2 sequence 432 (in transit)Recovery of Online Redo Log: Thread 2 Group 62 Seq 432 Reading mem 0 Mem# 0: +DATA/prod_st/onlinelog/group_62.559.923005101Tue Mar 21 01:10:17 2017RFS[1]: Selected log 63 for thread 2 sequence 433 dbid -98229520 branch 614228627Tue Mar 21 01:10:18 2017Media Recovery Waiting for thread 2 sequence 433 (in transit)Recovery of Online Redo Log: Thread 2 Group 63 Seq 433 Reading mem 0 Mem# 0: +DATA/prod_st/onlinelog/group_63.560.923005107Tue Mar 21 01:10:21 2017Archived Log entry 40032 added for thread 2 sequence 432 ID 0x18e2c75 dest 1: Chegando a conclusão que o sincronismo está OK. Uma coisa importante que verifiquei no *PRIMARY* foi que, não existia nenhuma FAST RECOVERY AREA configurada, e os archives são gerados em um disco no ASM chamado FRA. Logo pensei, a política de deleção automática de archives pelo RMAN não está funcionando por causa que não existe uma FAST RECOVERY AREA configurada. Logo configurei os parametros db_recovery_file_dest_size e o db_recovery_file_dest para o disco +FRA, mas de nada adiantou, os archives continuam sendo gerados no primary e não estão sendo deletados após aplicados no standby. Gostaria de saber de vocês, o que eu poderia fazer a mais para tentar resolver esse problema.
Re: [oracle_br] Desaster Recovery
Mais uma vez, meu muito obrigado, Chiappa.
Obrigado pelas dicas e pelos conselhos, sao muito bem vindos. Irei sim,
realizar cenários de restore/recover mais complexos, como por exemplo:
1 - Fazer um restore de um backup antigo de uma semana atrás, como vc mesmo
propos.
2- Backupear um database em um hostname e restaurar em um outros host com file
systems divergentes ou de file system para ASM e vice versa.
3 - Restaurar/recover de um backup que se tenha perdido de um determinado
archive de SCN x antes que o mesmo tenha sido backupeado.
etc
E qualquer dúvida posto aqui para você me ajudar, Obrigado :)
Em Segunda-feira, 20 de Março de 2017 10:24, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Blz... Agora é partir pros criar cenários mais complexos (como fazer um
backup + restore de backup mais antigo que vc tiver, restore envolvendo backups
incrementais - com e sem Block Changing Track -, diferenciais e cumulativos),
recover point-in-time recover
E em paralelo a isso se não o fez vc VAI começar a levantar as rotinas de
backup que possui hoje para tentar restores de testes - Apenas e Tão Somente
assim, NA Prática, ie, tentando restaurar num servidor não-prod algum backup de
PROD é que vc vai descobrir os erros operacionais e de processo, tipo, backups
que neguim não manteve registro do DBID, que não tem em mãos a sequência **
EXATA ** dos archives porque antes do backup database rolou um backup delete
input dos archives necessários, que por qualquer motivo algum dos datafiles tá
com um SCN ** extremamente antigo ** registrado nele e ninguém sabia), backups
antigos que estão na fita há um LONGO tempo sem ser usado - não é incomum a
fita 'grudar' e/ou ficar ressecada e quebradiça se ficar enrolada no cartucho
há longuíssimo tempo, parada, e coisas assimAté por isso em várias Empresas
por onde passei que eram da área Financeira e que tinham SLAs muito exatamente
precisos sobre Recuperabilidade, bem como Multas imensamente impossíveis se não
os cumprir, além de vc ter *** MAIS *** de uma Cópia de cada backup em fitas
diferentes (a regra repito é backup, se vc tem um só vc NÂO TEM NENHUM, na
verdade) , era comum o Rodízio, tipo : a cada x meses vc voltava o backup,
depois esses arquivos restaurados iam pra Outra fita com a fita Original
voltando ao pool de uso Quantos ciclos de reuso a fita aguenta
confiavelmente antes de ser descartada, qual esse intervalo e questões assim
são Específicas pra cada ambiente/hardware, não dá pra generalizar, mas vc TEM
que se assegurar que Existe algo assim...
Garanto que quando vc for mesmo fazer os restores+recovers reais para testar
é bem capaz de vc vai achar falhas do tipo, e sempre é melhor vc achar isso
agora do que quando tiver um diretor gritando na sua orelha que precisa porque
precisa recuperar os dados do ano passado pra fazer não-sei-qual relatório
importante, ou mesmo numa hora de crise total ie disaster recover
[]s
Chiappa #yiv5316083694 #yiv5316083694 -- #yiv5316083694ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5316083694
#yiv5316083694ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5316083694
#yiv5316083694ygrp-mkp #yiv5316083694hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv5316083694 #yiv5316083694ygrp-mkp #yiv5316083694ads
{margin-bottom:10px;}#yiv5316083694 #yiv5316083694ygrp-mkp .yiv5316083694ad
{padding:0 0;}#yiv5316083694 #yiv5316083694ygrp-mkp .yiv5316083694ad p
{margin:0;}#yiv5316083694 #yiv5316083694ygrp-mkp .yiv5316083694ad a
{color:#ff;text-decoration:none;}#yiv5316083694 #yiv5316083694ygrp-sponsor
#yiv5316083694ygrp-lc {font-family:Arial;}#yiv5316083694
#yiv5316083694ygrp-sponsor #yiv5316083694ygrp-lc #yiv5316083694hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5316083694
#yiv5316083694ygrp-sponsor #yiv5316083694ygrp-lc .yiv5316083694ad
{margin-bottom:10px;padding:0 0;}#yiv5316083694 #yiv5316083694actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5316083694
#yiv5316083694activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5316083694
#yiv5316083694activity span {font-weight:700;}#yiv5316083694
#yiv5316083694activity span:first-child
{text-transform:uppercase;}#yiv5316083694 #yiv5316083694activity span a
{color:#5085b6;text-decoration:none;}#yiv5316083694 #yiv5316083694activity span
span {color:#ff7900;}#yiv5316083694 #yiv5316083694activity span
.yiv5316083694underline {text-decoration:underline;}#yiv5316083694
.yiv5316083694attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv5316083694 .yiv5316083694attach div a
{text-decoration:none;}#yiv5316083694 .yiv5316083694attach img
{border:none;padding-right:5px;}#yiv5316083694 .yiv5316083694attach label
{display:block;margin-bottom:5px;}#yiv5316083694 .yiv5316083694attach label a
{text-decoration
Re: [oracle_br] Desaster Recovery
Descuylpe a demora para responder Chiappa, agora sim convegui resolver,
obrigado.Só precisei setar o SCN -1 do ultimo archivelog e foi.:)
Em Quinta-feira, 16 de Março de 2017 14:41, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Aproveitei e usei o mesmo texto como um post no meu blog pessoal, vide
https://jlc1967.wordpress.com/2017/03/16/demonstracao-de-restore-de-backup-hotonlineinconsistente-na-mesma-maquina/
[]s
Chiappa #yiv3133981602 #yiv3133981602 -- #yiv3133981602ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3133981602
#yiv3133981602ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3133981602
#yiv3133981602ygrp-mkp #yiv3133981602hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv3133981602 #yiv3133981602ygrp-mkp #yiv3133981602ads
{margin-bottom:10px;}#yiv3133981602 #yiv3133981602ygrp-mkp .yiv3133981602ad
{padding:0 0;}#yiv3133981602 #yiv3133981602ygrp-mkp .yiv3133981602ad p
{margin:0;}#yiv3133981602 #yiv3133981602ygrp-mkp .yiv3133981602ad a
{color:#ff;text-decoration:none;}#yiv3133981602 #yiv3133981602ygrp-sponsor
#yiv3133981602ygrp-lc {font-family:Arial;}#yiv3133981602
#yiv3133981602ygrp-sponsor #yiv3133981602ygrp-lc #yiv3133981602hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3133981602
#yiv3133981602ygrp-sponsor #yiv3133981602ygrp-lc .yiv3133981602ad
{margin-bottom:10px;padding:0 0;}#yiv3133981602 #yiv3133981602actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3133981602
#yiv3133981602activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3133981602
#yiv3133981602activity span {font-weight:700;}#yiv3133981602
#yiv3133981602activity span:first-child
{text-transform:uppercase;}#yiv3133981602 #yiv3133981602activity span a
{color:#5085b6;text-decoration:none;}#yiv3133981602 #yiv3133981602activity span
span {color:#ff7900;}#yiv3133981602 #yiv3133981602activity span
.yiv3133981602underline {text-decoration:underline;}#yiv3133981602
.yiv3133981602attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv3133981602 .yiv3133981602attach div a
{text-decoration:none;}#yiv3133981602 .yiv3133981602attach img
{border:none;padding-right:5px;}#yiv3133981602 .yiv3133981602attach label
{display:block;margin-bottom:5px;}#yiv3133981602 .yiv3133981602attach label a
{text-decoration:none;}#yiv3133981602 blockquote {margin:0 0 0
4px;}#yiv3133981602 .yiv3133981602bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3133981602
.yiv3133981602bold a {text-decoration:none;}#yiv3133981602 dd.yiv3133981602last
p a {font-family:Verdana;font-weight:700;}#yiv3133981602 dd.yiv3133981602last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3133981602
dd.yiv3133981602last p span.yiv3133981602yshortcuts
{margin-right:0;}#yiv3133981602 div.yiv3133981602attach-table div div a
{text-decoration:none;}#yiv3133981602 div.yiv3133981602attach-table
{width:400px;}#yiv3133981602 div.yiv3133981602file-title a, #yiv3133981602
div.yiv3133981602file-title a:active, #yiv3133981602
div.yiv3133981602file-title a:hover, #yiv3133981602 div.yiv3133981602file-title
a:visited {text-decoration:none;}#yiv3133981602 div.yiv3133981602photo-title a,
#yiv3133981602 div.yiv3133981602photo-title a:active, #yiv3133981602
div.yiv3133981602photo-title a:hover, #yiv3133981602
div.yiv3133981602photo-title a:visited {text-decoration:none;}#yiv3133981602
div#yiv3133981602ygrp-mlmsg #yiv3133981602ygrp-msg p a
span.yiv3133981602yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3133981602
.yiv3133981602green {color:#628c2a;}#yiv3133981602 .yiv3133981602MsoNormal
{margin:0 0 0 0;}#yiv3133981602 o {font-size:0;}#yiv3133981602
#yiv3133981602photos div {float:left;width:72px;}#yiv3133981602
#yiv3133981602photos div div {border:1px solid
#66;height:62px;overflow:hidden;width:62px;}#yiv3133981602
#yiv3133981602photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3133981602
#yiv3133981602reco-category {font-size:77%;}#yiv3133981602
#yiv3133981602reco-desc {font-size:77%;}#yiv3133981602 .yiv3133981602replbq
{margin:4px;}#yiv3133981602 #yiv3133981602ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv3133981602 #yiv3133981602ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv3133981602
#yiv3133981602ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv3133981602
#yiv3133981602ygrp-mlmsg select, #yiv3133981602 input, #yiv3133981602 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv3133981602
#yiv3133981602ygrp-mlmsg pre, #yiv3133981602 code {font:115%
monospace;}#yiv3133981602 #yiv3133981602ygrp-mlmsg *
{line-height:1.22em;}#yiv3133981602 #yiv3133981602ygrp-mlmsg #yiv3133981602logo
{padding-bottom:10px;}#yiv3133981602 #yiv3133981602ygr
[oracle_br] Desaster Recovery
Cenário: Desastre e Recovery, COM BACKUP, SEM CATALOGO, INSTANCE
SHUTDOWN.Enterprise Edition 12.1.0.2 Linux 64
SQL> archive log listDatabase log mode Archive ModeAutomatic archival
EnabledArchive destination /u01/app/archivelog2Oldest online log
sequence 67Next log sequence to archive 70Current log sequence 70
a) PASSO 1 - BACKUPEAR TODOS OS ARQUIVOS DO DATABASE
run{alter system archive log current; backup database plus archivelog delete
input;}
Starting backup at 15-MAR-17using channel ORA_DISK_1channel ORA_DISK_1:
starting full datafile backup setchannel ORA_DISK_1: specifying datafile(s) in
backup setinput datafile file number=1
name=/u01/app/oracle/oradata/TERRA1/datafile/o1_mf_system_dbz6nx14_.dbfinput
datafile file number=3
name=/u01/app/oracle/oradata/TERRA1/datafile/o1_mf_sysaux_dbz6m573_.dbfinput
datafile file number=5
name=/u01/app/oracle/oradata/TERRA1/datafile/o1_mf_new_user_dcchkvk9_.dbfinput
datafile file number=4
name=/u01/app/oracle/oradata/TERRA1/datafile/o1_mf_undotbs1_dcczlbll_.dbfinput
datafile file number=6
name=/u01/app/oracle/oradata/TERRA1/datafile/o1_mf_tbs_user_dccnlhxy_.dbfinput
datafile file number=7
name=/u01/app/oracle/oradata/TERRA1/datafile/o1_mf_new_user_dcchkvnx_.dbfchannel
ORA_DISK_1: starting piece 1 at 15-MAR-17channel ORA_DISK_1: finished piece 1
at 15-MAR-17piece
handle=/u01/app/oracle/fast_recovery_area/TERRA1/backupset/2017_03_15/o1_mf_nnndf_TAG20170315T021022_ddkm6036_.bkp
tag=TAG20170315T021022 comment=NONEchannel ORA_DISK_1: backup set complete,
elapsed time: 00:01:45Finished backup at 15-MAR-17
Starting backup at 15-MAR-17current log archivedusing channel ORA_DISK_1channel
ORA_DISK_1: starting archived log backup setchannel ORA_DISK_1: specifying
archived log(s) in backup setinput archived log thread=1 sequence=72 RECID=133
STAMP=938657529channel ORA_DISK_1: starting piece 1 at 15-MAR-17channel
ORA_DISK_1: finished piece 1 at 15-MAR-17piece
handle=/u01/app/oracle/fast_recovery_area/TERRA1/backupset/2017_03_15/o1_mf_a_TAG20170315T021210_ddkm9bgq_.bkp
tag=TAG20170315T021210 comment=NONEchannel ORA_DISK_1: backup set complete,
elapsed time: 00:00:01channel ORA_DISK_1: deleting archived log(s)archived log
file name=/u01/app/archivelog/arc_1_72_936747113.arc RECID=133
STAMP=938657529Finished backup at 15-MAR-17
Starting Control File and SPFILE Autobackup at 15-MAR-17piece
handle=/u01/backup/controlfile/control_file_c-2182710439-20170315-00.ctl
comment=NONEFinished Control File and SPFILE Autobackup at 15-MAR-17
2) rm -rf em todos os datafiles, controlfiles, redo logs, spfile e init.
3) Restaurando o spfile
RMAN> set dbid=2182710439
executing command: SET DBID
RMAN> startup nomount;
startup failed: ORA-01078: failure in processing system parametersLRM-00109:
could not open parameter file
'/u01/app/oracle/product/12.1.0.2/db_1/dbs/initTERRA1.ora'
starting Oracle instance without parameter file for retrieval of spfileOracle
instance started
Total System Global Area 1073741824 bytes
Fixed Size 2932632 bytesVariable Size
281018472 bytesDatabase Buffers 784334848 bytesRedo Buffers
5455872 bytes
RMAN> set dbid=2182710439
executing command: SET DBID
RMAN> restore spfile from
'/u01/backup/controlfile/control_file_c-2182710439-20170315-00.ctl';
Starting restore at 15-MAR-17using target database control file instead of
recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=12 device
type=DISK
channel ORA_DISK_1: restoring spfile from AUTOBACKUP
/u01/backup/controlfile/control_file_c-2182710439-20170315-00.ctlchannel
ORA_DISK_1: SPFILE restore from AUTOBACKUP completeFinished restore at 15-MAR-17
RMAN> EXIT
4) Restaurando o controlfile
SQL> shutdown abort;
RMAN> startup nomount;
Oracle instance started
Total System Global Area 838860800 bytes
Fixed Size 2929936 bytesVariable Size
570428144 bytesDatabase Buffers 260046848 bytesRedo Buffers
5455872 bytes
RMAN> set dbid=2182710439
executing command: SET DBID
RMAN> restore controlfile from
'/u01/backup/controlfile/control_file_c-2182710439-20170315-00.ctl';
Starting restore at 15-MAR-17using target database control file instead of
recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=12 device
type=DISK
channel ORA_DISK_1: restoring control filechannel ORA_DISK_1: restore complete,
elapsed time: 00:00:01output file
name=/u01/app/oracle/oradata/TERRA1/controlfile/o1_mf_dbz6roh5_.ctloutput file
name=/u01/app/oracle/fast_recovery_area/TERRA1/controlfile/o1_mf_dbz6roox_.ctlFinished
restore at 15-MAR-17
RMAN>
RMAN> alter database mount;
Statement processedreleased channel: ORA_DISK_1
5) Restaurando os datafiles
RMAN> list backup of database;
BS Key Type LV Size Device Type Elapsed Time Completion Time---
-- -- --- -
