Re: [oracle_br] Re: Standby Database
E ai, conseguiram testar a situação do Standby ? entrar em standby, voltar a ativa e entrar em standby de novo quando queira. Ja me pediram isso por aqui tb.. mas to enrolando.. quero compreender o processo.. []s angelo 2013/8/22 Raphael Franco > ** > > > Para ativar o Standby eu uso: > > > recover > automatic standby database until cancel; > alter > database activate standby database; > shutdown > e startup > > Nesse caso ele gera uma "New Incarnation",... agora nunca tentei > abri-lo dessa forma ..Standby Database Cancel e startup normal. Vou > verificar também. > > . > Raphael > > > De: J. Laurindo Chiappa > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quinta-feira, 22 de Agosto de 2013 15:47 > > Assunto: [oracle_br] Re: Standby Database > > > > Agora, um ponto importante : sim, Claro que ao vc fazer um OPEN com > RESETLOGS vc vai SIM criar uma nova encarnação (é o Objetivo do comando), > mas que eu saiba o standby manual absolutamente não exige um OPEN com > RESETLOGS, e é duvidoso que ele o faça implicitamente - ao que eu saiba, se > vc fechar o database standby (talvez seja preciso terminar o recover > standby com RECOVER MANAGED STANDBY DATABASE CANCEL;) e depois abrir com > STARTUP normal, sobre normal, cfrme > http://www.databasejournal.com/features/oracle/article.php/3682421/Manual-Standby-Database-under-Oracle-Standard-Edition.htm... > INCLUSIVE, o RDBMS não tem como saber, não há nenhum "parâmetro" que > indique que a base é standby (ela só estava funcionando como standby por > causa do mount standby database; que vc fez antes de entrar em recover > mode) : SE vc fechar e startar normal, afaik ele DEVERIA startar como uma > base NORMAL, eu não vejo nenhuma razão técnica para implicitamente ele > fazer um RESETLOGS nessa abertura... > mas vou tentar testar e te digo > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" > escreveu > > > > Pode ser... Vou dar uma testada mais tarde e vamos ver - eu nunca fiz > nada disso, mas vamos ver o que dá pra se fazer... > > > > []s > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > > > > > Chiappa, > > > > > > Segue os testes: > > > > > > 1) Parar o BD Produção PROD_PRIM (shutdown immediate) > > > 2) Aplico os ultimos archives no Standby PROD_STBY > > > 3) Ativo o Standby que passa a ser o produção > > > 4) No banco PROD_STBY crio um Standby Controlfile e transfiro para o > PROD_PRIM > > > 5) Monto o banco PROD_PRIM usando o Standby Controlfile. > > > Até aqui tudo bem o banco é montado. > > > 6) Quando tento aplicar os archives, vem o erro > > > > > > SYS@PROD_PRIM> alter database mount standby database; > > > > > > Database altered. > > > > > > SYS@PROD_PRIM> recover automatic standby database until cancel; > > > ORA-00283: recovery session canceled due to errors > > > ORA-19909: datafile 1 belongs to an orphan incarnation > > > ORA-01110: data file 1: '/u01/app/oracle/oradata/PROD/system01.dbf' > > > > > > Pelo que entendi, quando você ativa um standby, o banco abre com > resetlogs e atualiza o cabeçalho de todos os arquivos. Apesar do Database > Incarnation estar igual nos 2 bancos apoÅ› eu montar o PROD_PRIM como > standby..., o problema é no Cabeçalho dos Data Files que estão diferentes e > acredito que só um restore para ficar igual ao novo produção (PROD_STBY). > Me parece que ai falta um comando que atualiza o cabeçalho dos DataFiles > (acho que só o DG sabe desse comando..rs). > > > Me corrija se estiver errado. > > > > > > . > > > Raphael > > > > > > > > > > > > > > > > > > De: J. Laurindo Chiappa > > > Para: oracle_br@yahoogrupos.com.br > > > Enviadas: Quinta-feira, 22 de Agosto de 2013 13:01 > > > Assunto: [oracle_br] Re: Standby Database > > > > > > > > > > > > > > > Excelente pergunta, Rafael : vc me deixou Curioso, e vou testar quando > chegar em casa, mas AFAIK, falando de cabeça, só pelos Conceitos, eu acho > que é SIM possível, embora (claro) com DIVERSOS períodos de > indisponibilidade para os usuários > > > Acho que seria algo do tipo : > > > > > > 1. encerrar TODAs as transações no database prod, com ele quieto fazer > um archive current, e fechar prod, que estará consistente E parado no SCN x > > >
Re: [oracle_br] Re: Standby Database
Para ativar o Standby eu uso: recover automatic standby database until cancel; alter database activate standby database; shutdown e startup Nesse caso ele gera uma "New Incarnation",... agora nunca tentei abri-lo dessa forma ..Standby Database Cancel e startup normal. Vou verificar também. . Raphael De: J. Laurindo Chiappa Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 22 de Agosto de 2013 15:47 Assunto: [oracle_br] Re: Standby Database Agora, um ponto importante : sim, Claro que ao vc fazer um OPEN com RESETLOGS vc vai SIM criar uma nova encarnação (é o Objetivo do comando), mas que eu saiba o standby manual absolutamente não exige um OPEN com RESETLOGS, e é duvidoso que ele o faça implicitamente - ao que eu saiba, se vc fechar o database standby (talvez seja preciso terminar o recover standby com RECOVER MANAGED STANDBY DATABASE CANCEL;) e depois abrir com STARTUP normal, sobre normal, cfrme http://www.databasejournal.com/features/oracle/article.php/3682421/Manual-Standby-Database-under-Oracle-Standard-Edition.htm ... INCLUSIVE, o RDBMS não tem como saber, não há nenhum "parâmetro" que indique que a base é standby (ela só estava funcionando como standby por causa do mount standby database; que vc fez antes de entrar em recover mode) : SE vc fechar e startar normal, afaik ele DEVERIA startar como uma base NORMAL, eu não vejo nenhuma razão técnica para implicitamente ele fazer um RESETLOGS nessa abertura... mas vou tentar testar e te digo []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" escreveu > > Pode ser... Vou dar uma testada mais tarde e vamos ver - eu nunca fiz nada > disso, mas vamos ver o que dá pra se fazer... > > []s > >Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > > > Chiappa, > > > > Segue os testes: > > > > 1) Parar o BD Produção PROD_PRIM (shutdown immediate) > > 2) Aplico os ultimos archives no Standby PROD_STBY > > 3) Ativo o Standby que passa a ser o produção > > 4) No banco PROD_STBY crio um Standby Controlfile e transfiro para o > > PROD_PRIM > > 5) Monto o banco PROD_PRIM usando o Standby Controlfile. > > Até aqui tudo bem o banco é montado. > > 6) Quando tento aplicar os archives, vem o erro > > > > SYS@PROD_PRIM> alter database mount standby database; > > > > Database altered. > > > > SYS@PROD_PRIM> recover automatic standby database until cancel; > > ORA-00283: recovery session canceled due to errors > > ORA-19909: datafile 1 belongs to an orphan incarnation > > ORA-01110: data file 1: '/u01/app/oracle/oradata/PROD/system01.dbf' > > > > Pelo que entendi, quando você ativa um standby, o banco abre com resetlogs > > e atualiza o cabeçalho de todos os arquivos. Apesar do Database Incarnation > > estar igual nos 2 bancos apoÅ› eu montar o PROD_PRIM como standby..., o > > problema é no Cabeçalho dos Data Files que estão diferentes e acredito que > > só um restore para ficar igual ao novo produção (PROD_STBY). Me parece que > > ai falta um comando que atualiza o cabeçalho dos DataFiles (acho que só o > > DG sabe desse comando..rs). > > Me corrija se estiver errado. > > > > . > > Raphael > > > > > > > > > > > > De: J. Laurindo Chiappa > > Para: oracle_br@yahoogrupos.com.br > > Enviadas: Quinta-feira, 22 de Agosto de 2013 13:01 > > Assunto: [oracle_br] Re: Standby Database > > > > > > > > > > Excelente pergunta, Rafael : vc me deixou Curioso, e vou testar quando > > chegar em casa, mas AFAIK, falando de cabeça, só pelos Conceitos, eu acho > > que é SIM possível, embora (claro) com DIVERSOS períodos de > > indisponibilidade para os usuários > > Acho que seria algo do tipo : > > > > 1. encerrar TODAs as transações no database prod, com ele quieto fazer um > > archive current, e fechar prod, que estará consistente E parado no SCN x > > > > 2. aplicar TODOS os archives até x no standby e o abrir normalmente, > > "quebrando o standby", e apontar os clients pata conectar nele, aí ele vira > > Produção > > > > 3. aí chegamos no ponto em dúvida : quando for para fazer o antigo banco > > voltar a ser prod, os arquivos estão consistentes entre si MAS todos estão > > com SCN antigo - o database atualmente aberto como produção já está num SCN > > X+n > > Primeiro, vc teria que parar o banco atualmnente aberto, parando-o no SCN > > x+1 , enviar os archives todos pro banco original, e aí, em princ
[oracle_br] Re: Standby Database
Agora, um ponto importante : sim, Claro que ao vc fazer um OPEN com RESETLOGS vc vai SIM criar uma nova encarnação (é o Objetivo do comando), mas que eu saiba o standby manual absolutamente não exige um OPEN com RESETLOGS, e é duvidoso que ele o faça implicitamente - ao que eu saiba, se vc fechar o database standby (talvez seja preciso terminar o recover standby com RECOVER MANAGED STANDBY DATABASE CANCEL;) e depois abrir com STARTUP normal, sobre normal, cfrme http://www.databasejournal.com/features/oracle/article.php/3682421/Manual-Standby-Database-under-Oracle-Standard-Edition.htm ... INCLUSIVE, o RDBMS não tem como saber, não há nenhum "parâmetro" que indique que a base é standby (ela só estava funcionando como standby por causa do mount standby database; que vc fez antes de entrar em recover mode) : SE vc fechar e startar normal, afaik ele DEVERIA startar como uma base NORMAL, eu não vejo nenhuma razão técnica para implicitamente ele fazer um RESETLOGS nessa abertura... mas vou tentar testar e te digo []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" escreveu > > Pode ser... Vou dar uma testada mais tarde e vamos ver - eu nunca fiz nada > disso, mas vamos ver o que dá pra se fazer... > > []s > >Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > > > Chiappa, > > > > Segue os testes: > > > > 1) Parar o BD Produção PROD_PRIM (shutdown immediate) > > 2) Aplico os ultimos archives no Standby PROD_STBY > > 3) Ativo o Standby que passa a ser o produção > > 4) No banco PROD_STBY crio um Standby Controlfile e transfiro para o > > PROD_PRIM > > 5) Monto o banco PROD_PRIM usando o Standby Controlfile. > > Até aqui tudo bem o banco é montado. > > 6) Quando tento aplicar os archives, vem o erro > > > > SYS@PROD_PRIM> alter database mount standby database; > > > > Database altered. > > > > SYS@PROD_PRIM> recover automatic standby database until cancel; > > ORA-00283: recovery session canceled due to errors > > ORA-19909: datafile 1 belongs to an orphan incarnation > > ORA-01110: data file 1: '/u01/app/oracle/oradata/PROD/system01.dbf' > > > > Pelo que entendi, quando você ativa um standby, o banco abre com resetlogs > > e atualiza o cabeçalho de todos os arquivos. Apesar do Database Incarnation > > estar igual nos 2 bancos apoÅ eu montar o PROD_PRIM como standby..., o > > problema é no Cabeçalho dos Data Files que estão diferentes e acredito que > > só um restore para ficar igual ao novo produção (PROD_STBY). Me parece que > > ai falta um comando que atualiza o cabeçalho dos DataFiles (acho que só o > > DG sabe desse comando..rs). > > Me corrija se estiver errado. > > > > . > > Raphael > > > > > > > > > > > > De: J. Laurindo Chiappa > > Para: oracle_br@yahoogrupos.com.br > > Enviadas: Quinta-feira, 22 de Agosto de 2013 13:01 > > Assunto: [oracle_br] Re: Standby Database > > > > > > > > > > Excelente pergunta, Rafael : vc me deixou Curioso, e vou testar quando > > chegar em casa, mas AFAIK, falando de cabeça, só pelos Conceitos, eu acho > > que é SIM possível, embora (claro) com DIVERSOS períodos de > > indisponibilidade para os usuários > > Acho que seria algo do tipo : > > > > 1. encerrar TODAs as transações no database prod, com ele quieto fazer um > > archive current, e fechar prod, que estará consistente E parado no SCN x > > > > 2. aplicar TODOS os archives até x no standby e o abrir normalmente, > > "quebrando o standby", e apontar os clients pata conectar nele, aí ele vira > > Produção > > > > 3. aí chegamos no ponto em dúvida : quando for para fazer o antigo banco > > voltar a ser prod, os arquivos estão consistentes entre si MAS todos estão > > com SCN antigo - o database atualmente aberto como produção já está num SCN > > X+n > > Primeiro, vc teria que parar o banco atualmnente aberto, parando-o no SCN > > x+1 , enviar os archives todos pro banco original, e aí, em princípio, > > falando conceitualmente, Não É nenhum prodígio vc atualizar os datafiles de > > x para x+n , ie, fazer um roll forward através da aplicação dos archived > > redo logs : é o que a gente faz quando tem que restaurar um backup hot, por > > exemplo... > > Uma vez ambos os bancos parados no mesmo scn x+n, ACHO que vc poderia abrir > > sem disponibilizar o banco prod origem, criar um standby controlfile e > > enviá-lo para o banco
[oracle_br] Re: Standby Database
Pode ser... Vou dar uma testada mais tarde e vamos ver - eu nunca fiz nada disso, mas vamos ver o que dá pra se fazer... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > Chiappa, > > Segue os testes: > > 1) Parar o BD Produção PROD_PRIM (shutdown immediate) > 2) Aplico os ultimos archives no Standby PROD_STBY > 3) Ativo o Standby que passa a ser o produção > 4) No banco PROD_STBY crio um Standby Controlfile e transfiro para o PROD_PRIM > 5) Monto o banco PROD_PRIM usando o Standby Controlfile. > Até aqui tudo bem o banco é montado. > 6) Quando tento aplicar os archives, vem o erro > > SYS@PROD_PRIM> alter database mount standby database; > > Database altered. > > SYS@PROD_PRIM> recover automatic standby database until cancel; > ORA-00283: recovery session canceled due to errors > ORA-19909: datafile 1 belongs to an orphan incarnation > ORA-01110: data file 1: '/u01/app/oracle/oradata/PROD/system01.dbf' > > Pelo que entendi, quando você ativa um standby, o banco abre com resetlogs e > atualiza o cabeçalho de todos os arquivos. Apesar do Database Incarnation > estar igual nos 2 bancos apoÅ eu montar o PROD_PRIM como standby..., o > problema é no Cabeçalho dos Data Files que estão diferentes e acredito que só > um restore para ficar igual ao novo produção (PROD_STBY). Me parece que ai > falta um comando que atualiza o cabeçalho dos DataFiles (acho que só o DG > sabe desse comando..rs). > Me corrija se estiver errado. > > . > Raphael > > > > > > De: J. Laurindo Chiappa > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quinta-feira, 22 de Agosto de 2013 13:01 > Assunto: [oracle_br] Re: Standby Database > > > > > Excelente pergunta, Rafael : vc me deixou Curioso, e vou testar quando chegar > em casa, mas AFAIK, falando de cabeça, só pelos Conceitos, eu acho que é SIM > possível, embora (claro) com DIVERSOS períodos de indisponibilidade para os > usuários > Acho que seria algo do tipo : > > 1. encerrar TODAs as transações no database prod, com ele quieto fazer um > archive current, e fechar prod, que estará consistente E parado no SCN x > > 2. aplicar TODOS os archives até x no standby e o abrir normalmente, > "quebrando o standby", e apontar os clients pata conectar nele, aí ele vira > Produção > > 3. aí chegamos no ponto em dúvida : quando for para fazer o antigo banco > voltar a ser prod, os arquivos estão consistentes entre si MAS todos estão > com SCN antigo - o database atualmente aberto como produção já está num SCN > X+n > Primeiro, vc teria que parar o banco atualmnente aberto, parando-o no SCN x+1 > , enviar os archives todos pro banco original, e aí, em princípio, falando > conceitualmente, Não É nenhum prodígio vc atualizar os datafiles de x para > x+n , ie, fazer um roll forward através da aplicação dos archived redo logs : > é o que a gente faz quando tem que restaurar um backup hot, por exemplo... > Uma vez ambos os bancos parados no mesmo scn x+n, ACHO que vc poderia abrir > sem disponibilizar o banco prod origem, criar um standby controlfile e > enviá-lo para o banco remoto, colocar remoto em recover mode (para voltar a > ser standby) e abrir normalmente o prod origem > > Faça seus testes aí e nos mostre, que quando puder vou fazer no meu notebook > de casa (que tem mais espaço e memória que a minha máquina desktop do > trabalho) e vamos ver > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > > > Pessoal, > > > > Tenho um servidor de produção Oracle SE 10.2.0.5 / RH5 64Bits. > > E um servidor de BD Physical Standby desse produção. > > Nada de DG, é um Standby configurado Manualmente aplicando os archives a > > cada 30 minutos. > > > > É possível fazer um chaveamento do Standby virar produção e do produção > > virar Standby e vice versa sem ter que recriar todo o BD de > > Standby,. por exemplo, somente alterando o Control File para > > Standby?? > > ou seja, em uma manutenção de hardware no produção, > > 1) Ativar o Standby (usuarios passam a usar esse BD) > > 2) Depois da manutenção colocaria o produção como Standby sincronizava e > > ativava ele > > 3) Voltaria o Standby como Standby mesmo. > > (todo esse processo sem ter que realizar o restore dos BD) > > > > Não sei se foi claro sobre minha dúvida. > > > > Att. > > Raphael > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
Re: [oracle_br] Re: Standby Database
Chiappa, Segue os testes: 1) Parar o BD Produção PROD_PRIM (shutdown immediate) 2) Aplico os ultimos archives no Standby PROD_STBY 3) Ativo o Standby que passa a ser o produção 4) No banco PROD_STBY crio um Standby Controlfile e transfiro para o PROD_PRIM 5) Monto o banco PROD_PRIM usando o Standby Controlfile. Até aqui tudo bem o banco é montado. 6) Quando tento aplicar os archives, vem o erro SYS@PROD_PRIM> alter database mount standby database; Database altered. SYS@PROD_PRIM> recover automatic standby database until cancel; ORA-00283: recovery session canceled due to errors ORA-19909: datafile 1 belongs to an orphan incarnation ORA-01110: data file 1: '/u01/app/oracle/oradata/PROD/system01.dbf' Pelo que entendi, quando você ativa um standby, o banco abre com resetlogs e atualiza o cabeçalho de todos os arquivos. Apesar do Database Incarnation estar igual nos 2 bancos apoś eu montar o PROD_PRIM como standby..., o problema é no Cabeçalho dos Data Files que estão diferentes e acredito que só um restore para ficar igual ao novo produção (PROD_STBY). Me parece que ai falta um comando que atualiza o cabeçalho dos DataFiles (acho que só o DG sabe desse comando..rs). Me corrija se estiver errado. . Raphael De: J. Laurindo Chiappa Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 22 de Agosto de 2013 13:01 Assunto: [oracle_br] Re: Standby Database Excelente pergunta, Rafael : vc me deixou Curioso, e vou testar quando chegar em casa, mas AFAIK, falando de cabeça, só pelos Conceitos, eu acho que é SIM possível, embora (claro) com DIVERSOS períodos de indisponibilidade para os usuários Acho que seria algo do tipo : 1. encerrar TODAs as transações no database prod, com ele quieto fazer um archive current, e fechar prod, que estará consistente E parado no SCN x 2. aplicar TODOS os archives até x no standby e o abrir normalmente, "quebrando o standby", e apontar os clients pata conectar nele, aí ele vira Produção 3. aí chegamos no ponto em dúvida : quando for para fazer o antigo banco voltar a ser prod, os arquivos estão consistentes entre si MAS todos estão com SCN antigo - o database atualmente aberto como produção já está num SCN X+n Primeiro, vc teria que parar o banco atualmnente aberto, parando-o no SCN x+1 , enviar os archives todos pro banco original, e aí, em princípio, falando conceitualmente, Não É nenhum prodígio vc atualizar os datafiles de x para x+n , ie, fazer um roll forward através da aplicação dos archived redo logs : é o que a gente faz quando tem que restaurar um backup hot, por exemplo... Uma vez ambos os bancos parados no mesmo scn x+n, ACHO que vc poderia abrir sem disponibilizar o banco prod origem, criar um standby controlfile e enviá-lo para o banco remoto, colocar remoto em recover mode (para voltar a ser standby) e abrir normalmente o prod origem Faça seus testes aí e nos mostre, que quando puder vou fazer no meu notebook de casa (que tem mais espaço e memória que a minha máquina desktop do trabalho) e vamos ver []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > Pessoal, > > Tenho um servidor de produção Oracle SE 10.2.0.5 / RH5 64Bits. > E um servidor de BD Physical Standby desse produção. > Nada de DG, é um Standby configurado Manualmente aplicando os archives a cada > 30 minutos. > > É possível fazer um chaveamento do Standby virar produção e do produção virar > Standby e vice versa sem ter que recriar todo o BD de Standby,. por > exemplo, somente alterando o Control File para Standby?? > ou seja, em uma manutenção de hardware no produção, > 1) Ativar o Standby (usuarios passam a usar esse BD) > 2) Depois da manutenção colocaria o produção como Standby sincronizava e > ativava ele > 3) Voltaria o Standby como Standby mesmo. > (todo esse processo sem ter que realizar o restore dos BD) > > Não sei se foi claro sobre minha dúvida. > > Att. > Raphael > > > [As partes desta mensagem que não continham texto foram removidas] > [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Standby Database
Excelente pergunta, Rafael : vc me deixou Curioso, e vou testar quando chegar em casa, mas AFAIK, falando de cabeça, só pelos Conceitos, eu acho que é SIM possível, embora (claro) com DIVERSOS períodos de indisponibilidade para os usuários Acho que seria algo do tipo : 1. encerrar TODAs as transações no database prod, com ele quieto fazer um archive current, e fechar prod, que estará consistente E parado no SCN x 2. aplicar TODOS os archives até x no standby e o abrir normalmente, "quebrando o standby", e apontar os clients pata conectar nele, aí ele vira Produção 3. aí chegamos no ponto em dúvida : quando for para fazer o antigo banco voltar a ser prod, os arquivos estão consistentes entre si MAS todos estão com SCN antigo - o database atualmente aberto como produção já está num SCN X+n Primeiro, vc teria que parar o banco atualmnente aberto, parando-o no SCN x+1 , enviar os archives todos pro banco original, e aí, em princípio, falando conceitualmente, Não É nenhum prodígio vc atualizar os datafiles de x para x+n , ie, fazer um roll forward através da aplicação dos archived redo logs : é o que a gente faz quando tem que restaurar um backup hot, por exemplo... Uma vez ambos os bancos parados no mesmo scn x+n, ACHO que vc poderia abrir sem disponibilizar o banco prod origem, criar um standby controlfile e enviá-lo para o banco remoto, colocar remoto em recover mode (para voltar a ser standby) e abrir normalmente o prod origem Faça seus testes aí e nos mostre, que quando puder vou fazer no meu notebook de casa (que tem mais espaço e memória que a minha máquina desktop do trabalho) e vamos ver []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > Pessoal, > > Tenho um servidor de produção Oracle SE 10.2.0.5 / RH5 64Bits. > E um servidor de BD Physical Standby desse produção. > Nada de DG, é um Standby configurado Manualmente aplicando os archives a cada > 30 minutos. > > É possível fazer um chaveamento do Standby virar produção e do produção virar > Standby e vice versa sem ter que recriar todo o BD de Standby,. por > exemplo, somente alterando o Control File para Standby?? > ou seja, em uma manutenção de hardware no produção, > 1) Ativar o Standby (usuarios passam a usar esse BD) > 2) Depois da manutenção colocaria o produção como Standby sincronizava e > ativava ele > 3) Voltaria o Standby como Standby mesmo. > (todo esse processo sem ter que realizar o restore dos BD) > > Não sei se foi claro sobre minha dúvida. > > Att. > Raphael > > > [As partes desta mensagem que não continham texto foram removidas] >
Re: [oracle_br] Re: Standby Database
1-O que eh pago em si nao eh o DG e sim a licenca do EE. 2- O STBY, caso o secundario esteja montado em modo recover eu acredito que seja preciso que seja preciso vc ter licenca para este servidor. Tem que confirmar isto. Eu "ACHO" que vc pode ter licencas diferentes. ex: EE no primario e SE no secundario.(caso vc nao utilize feature do EE) Obs: A sua segunda duvida tem que confirmar. -- Att, Diego Leite DBA ORACLE Em 30 de março de 2011 21:42, Raphael Franco escreveu: > > > Perfeito... obrigado! > O problema do DG é que além de ser pago é só para a versão > Enterprise...certo? > > Outra duvida: ao montar um standby é preciso ter as licenças iguais a do > produção?? > > att. > Phael > > > De: José Laurindo > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quarta-feira, 30 de Março de 2011 20:20:46 > Assunto: [oracle_br] Re: Standby Database > > > Colega, seguinte : STAND-BY propriamente dito (ie, envio de archived redo > logs > do banco Ativo para uma outro banco que fica recebendo-os e aplicando-os) é > sim > ainda possível de ser feito no 10g, mas o 10g extende esse conceito com o > DATAGUARD, que além de fazer o que o standby fazia (inclusive automatizando > o > envio) TAMBÉM tem novas e importantes features, Inclusive algumas que podem > > garantir ZERO de perda de dados, o que o velho standby não pode - vc está > certo > na sua suposição, num standby tradicional Obviamente se a produção > crashear, com > perda total de tudo em todos os discos, exatamente antes dos archived logs > mais > recentes serem enviados é Lógico que o standby só poderá ser atualizado até > o > último archived log que recebeu , os archives perdidos estão perdidos, é > informação que não tem como recuperar... > Já o DATAGUARD como eu disse tem opções de ZERO PERDA : basicamente ele se > assegura que a info necessária de recuperação foi enviada pro banco > secundário > antes de considerar a transação concluída no bd prod, tipo assim... Dá um > look > na documentação que vc obterá mais dets... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > > > Caros amigos, > > > > Alguém poderia me ajudar com algumas duvidas sobre Standby? > > > > Falando em Oracle 10g. > > > > 1) Existem varias formas de se configurar um Standby no Oracle ?? > > 2) Existe algum que é mais eficiente? (Ja vi varias formas de se manter > um > > standby: rman e manual) > > > > 3) A forma como eu utilizo é montar o standby e aplicar os archives > > automatizando o comando abaixo para executar de tempo em tempo; > > recover automatic standby database until cancel; > > Desse jeito os archives devem ser sincronizados com o standby e depois > efetuar > >o > > > > recover acima. > > Porém nesse caso, se for preciso ativar o banco STBY sempre haverá alguma > perda > > > > de informações em relação ao produção ?? > > Por exemplo, as informações que estão nos redo log ou se o crash no > produção > >foi > > > > no momento da transferencia dos archives. > > > > > > att. > > Phael > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > [As partes desta mensagem que não continham texto foram removidas] > > > [As partes desta mensagem que não continham texto foram removidas] -- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Res: [oracle_br] Re: Standby Database
Verifique certinho pra sua Exata versão de banco de dados (que vc Não Diz qual é) mas sim, de modo geral TODAS as opções de banco crítico (ie, alta-disponibilidade com zero de perda, replicação avançada, I/O diferenciado com particionamento, etc, etc, etc) exigem Enterprise Edition, correto... Se foi optado por fator de economia por não se usar EE, obviamente vc perde esses recursos... Não tem o que, zero perda, 24x7 REAL, tem seus custos e Não são baixos.. Quanto ao Licenciamento, sei que havia uma política da Oracle de não cobrar licença se o banco secundário não foi ativado por mais que 10 dias no ano , não sei se isso ainda vale : dá uma pesquisada no metalink que vc deve achar ref mais atualizada... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > Perfeito... obrigado! > O problema do DG é que além de ser pago é só para a versão Enterprise...certo? > > Outra duvida: ao montar um standby é preciso ter as licenças iguais a do > produção?? > > att. > Phael > > > > > De: José Laurindo > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quarta-feira, 30 de Março de 2011 20:20:46 > Assunto: [oracle_br] Re: Standby Database > > > Colega, seguinte : STAND-BY propriamente dito (ie, envio de archived redo > logs > do banco Ativo para uma outro banco que fica recebendo-os e aplicando-os) é > sim > ainda possível de ser feito no 10g, mas o 10g extende esse conceito com o > DATAGUARD, que além de fazer o que o standby fazia (inclusive automatizando o > envio) TAMBÉM tem novas e importantes features, Inclusive algumas que podem > garantir ZERO de perda de dados, o que o velho standby não pode - vc está > certo > na sua suposição, num standby tradicional Obviamente se a produção crashear, > com > perda total de tudo em todos os discos, exatamente antes dos archived logs > mais > recentes serem enviados é Lógico que o standby só poderá ser atualizado até o > último archived log que recebeu , os archives perdidos estão perdidos, é > informação que não tem como recuperar... > Já o DATAGUARD como eu disse tem opções de ZERO PERDA : basicamente ele se > assegura que a info necessária de recuperação foi enviada pro banco > secundário > antes de considerar a transação concluída no bd prod, tipo assim... Dá um > look > na documentação que vc obterá mais dets... > > []s > > Chiappa > > > --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > > > Caros amigos, > > > > Alguém poderia me ajudar com algumas duvidas sobre Standby? > > > > Falando em Oracle 10g. > > > > 1) Existem varias formas de se configurar um Standby no Oracle ?? > > 2) Existe algum que é mais eficiente? (Ja vi varias formas de se manter um > > standby: rman e manual) > > > > 3) A forma como eu utilizo é montar o standby e aplicar os archives > > automatizando o comando abaixo para executar de tempo em tempo; > > recover automatic standby database until cancel; > > Desse jeito os archives devem ser sincronizados com o standby e depois > > efetuar > >o > > > > recover acima. > > Porém nesse caso, se for preciso ativar o banco STBY sempre haverá alguma > > perda > > > > de informações em relação ao produção ?? > > Por exemplo, as informações que estão nos redo log ou se o crash no > > produção > >foi > > > > no momento da transferencia dos archives. > > > > > > att. > > Phael > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
Res: [oracle_br] Re: Standby Database
Perfeito... obrigado! O problema do DG é que além de ser pago é só para a versão Enterprise...certo? Outra duvida: ao montar um standby é preciso ter as licenças iguais a do produção?? att. Phael De: José Laurindo Para: oracle_br@yahoogrupos.com.br Enviadas: Quarta-feira, 30 de Março de 2011 20:20:46 Assunto: [oracle_br] Re: Standby Database Colega, seguinte : STAND-BY propriamente dito (ie, envio de archived redo logs do banco Ativo para uma outro banco que fica recebendo-os e aplicando-os) é sim ainda possível de ser feito no 10g, mas o 10g extende esse conceito com o DATAGUARD, que além de fazer o que o standby fazia (inclusive automatizando o envio) TAMBÉM tem novas e importantes features, Inclusive algumas que podem garantir ZERO de perda de dados, o que o velho standby não pode - vc está certo na sua suposição, num standby tradicional Obviamente se a produção crashear, com perda total de tudo em todos os discos, exatamente antes dos archived logs mais recentes serem enviados é Lógico que o standby só poderá ser atualizado até o último archived log que recebeu , os archives perdidos estão perdidos, é informação que não tem como recuperar... Já o DATAGUARD como eu disse tem opções de ZERO PERDA : basicamente ele se assegura que a info necessária de recuperação foi enviada pro banco secundário antes de considerar a transação concluída no bd prod, tipo assim... Dá um look na documentação que vc obterá mais dets... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > Caros amigos, > > Alguém poderia me ajudar com algumas duvidas sobre Standby? > > Falando em Oracle 10g. > > 1) Existem varias formas de se configurar um Standby no Oracle ?? > 2) Existe algum que é mais eficiente? (Ja vi varias formas de se manter um > standby: rman e manual) > > 3) A forma como eu utilizo é montar o standby e aplicar os archives > automatizando o comando abaixo para executar de tempo em tempo; > recover automatic standby database until cancel; > Desse jeito os archives devem ser sincronizados com o standby e depois > efetuar >o > > recover acima. > Porém nesse caso, se for preciso ativar o banco STBY sempre haverá alguma > perda > > de informações em relação ao produção ?? > Por exemplo, as informações que estão nos redo log ou se o crash no produção >foi > > no momento da transferencia dos archives. > > > att. > Phael > > > [As partes desta mensagem que não continham texto foram removidas] > [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Standby Database
Colega, seguinte : STAND-BY propriamente dito (ie, envio de archived redo logs do banco Ativo para uma outro banco que fica recebendo-os e aplicando-os) é sim ainda possível de ser feito no 10g, mas o 10g extende esse conceito com o DATAGUARD, que além de fazer o que o standby fazia (inclusive automatizando o envio) TAMBÉM tem novas e importantes features, Inclusive algumas que podem garantir ZERO de perda de dados, o que o velho standby não pode - vc está certo na sua suposição, num standby tradicional Obviamente se a produção crashear, com perda total de tudo em todos os discos, exatamente antes dos archived logs mais recentes serem enviados é Lógico que o standby só poderá ser atualizado até o último archived log que recebeu , os archives perdidos estão perdidos, é informação que não tem como recuperar... Já o DATAGUARD como eu disse tem opções de ZERO PERDA : basicamente ele se assegura que a info necessária de recuperação foi enviada pro banco secundário antes de considerar a transação concluída no bd prod, tipo assim... Dá um look na documentação que vc obterá mais dets... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Raphael Franco escreveu > > Caros amigos, > > Alguém poderia me ajudar com algumas duvidas sobre Standby? > > Falando em Oracle 10g. > > 1) Existem varias formas de se configurar um Standby no Oracle ?? > 2) Existe algum que é mais eficiente? (Ja vi varias formas de se manter um > standby: rman e manual) > > 3) A forma como eu utilizo é montar o standby e aplicar os archives > automatizando o comando abaixo para executar de tempo em tempo; > recover automatic standby database until cancel; > Desse jeito os archives devem ser sincronizados com o standby e depois > efetuar o > recover acima. > Porém nesse caso, se for preciso ativar o banco STBY sempre haverá alguma > perda > de informações em relação ao produção ?? > Por exemplo, as informações que estão nos redo log ou se o crash no produção > foi > no momento da transferencia dos archives. > > > att. > Phael > > > [As partes desta mensagem que não continham texto foram removidas] >
[oracle_br] Re: standby database
Vamos ver se posso ajudar : seguem as respostas, mas antes de qquer coisa, a antiga funcionalidade do standby foi ABSORVIDA pelo DataGuard nas versões hoje Suportadas e em produção do banco, estão é de DATAGUARD que vamos falar, não só apenas de standby, ok ? --- Em oracle_br@yahoogrupos.com.br, Eliandro Jakubski <[EMAIL PROTECTED]> > > 1 - Técnicamente a base standby estará sincronizada > com a base principal, entretanto, os dados de online log da base > principal que ainda não foram > arquivados serão perdidos (em caso de falha do banco principal). Isso > está correto? Isso estará correto SE e apenas SE vc assim configurou o dataguard, para trabalhar só com os archived logs, não impactando aa transações online, SE vc optou pelo modo de perda de dados ZERO (maximum protect) haverá um novo processo no banco transportando o redo log diretamente pro banco destino , aí (óbvio) ainda que haja crash total do banco principal o redo online foi transmitido pro banco destino, há o que é chamado de commit log sync, é assegurado que qquer redo log comitado e ainda não aplicado aos datafiles VAI ser replicado pro bd destino. E é claro também, se vc não está trabalhando com maximum protect é sempre praxe e altamente recomendado e recomendável que vc tenha uma MULTIPLEXAÇÃO do redo log file online (ie, uma cópia online, fazer com que o banco grave o mesmo redo em dois arqs diferentes em locaçoes diferentes), pois aí se vc tiver uma perda de um vc recupera com o outro , ok ? > > 2 - Se a questão 1 for correta então o tamanho dos arquivos de online log > terão impacto no > número de transações que eu poderei perder caso a base primária falhar > com dados no online log > ainda não arquivados, pois, qto. maior o tamanho dos arquivos de > online log mais tempo será necessário > para que ele seja arquivado (desconsiderando outros detalhes). Isso > está correto? SE vc não está em maximum protect, E não tem redo log online multiplexado, sim, em caso de perda do redo online vc terá que fazer um recover e perderá as alterações dos blocos feitas depois do último checkpoint, sim , o tamanho influencia, pois (claro) quanto maior o redo log file online que vc perdeu mais chances de vc ter mais transações presentes nesse log file perdido, MAs não é só isso, vc pode ter uma única transação que estava gerando redo log pracaas e quase "monopolizava" o redo online, nesse cenário de perda que estamos discutindo no caso vc perderia uma transação só INFLUENCIAR é a palavra coreta, é um dos fatores apenas, sim... Óbvio, porém, que um redo log file por demais pequeno quase que FATALMENTE leva à situações de checkpoint not complete em situações de pico de uso, pois com log files pequenos no tempo em que um log file está sendo checkpointado o banco já encheu outro, e outro, e outro, o banco está sempre "correndo atrás do prejuízo"... Então (claro)sempre é um número de equilibrismo, vc tenta tirar daqui mas não pode botar muito ali, é um todo um bd Oracle... > > 3 - Considerando um modo standby de máxima performance percebi que, na > maior parte dos exemplos disponíveis, > o pessoal têm utilizado a opção NODELAY (assim que o archive for > gerado no banco primário ele é transmitido e > aplicado no banco secundário). Caso o usuário cometer erros lógicos no > banco primário eles poderão ser transmitidos > para o secundário assim que o archive log correspondente for gerado. > Isso está correto? Sim, isso ocorre com o NODELAY, mas em verdade mesmo que vc imponha um delay NECESSARIAMENTE o tal erro lógico VAI ser replicado, cedo ou tarde... Não sei se o argumento "ah, mas com um delay o DBA tem tempo pra 'perceber' o erro" é viável, acho meio difícil... E outra, se já foi comitada a transação com o tal erro lógico, o que que o DBA pode fazer ? É tecnicamente possível mas ABSOLUTAMENTE inviável na prática a possibilidade (queimagino é o que vc estava pensando) de se interromper o banco principal antes do log archive file com o erro ser replicado , ativar o standby como banco principal (que não tem a tal transação lógica errada) , e passar o antes principal para standby, é fora de questão... Pra mim, erros lógicos NECESSARIAMENTE são é desfeitos no banco online mesmo, via flashback, e/ou tablespace point in time recovery e/ou scn query , e/ou minerando a alteração ou mesmo se voltando o banco mesmo pro ponto no temo antes do erro, se vc estiver em modo archive... O modo archive serve também para isso, além de prevenir a perda de dados ele TAMBÉM permite se voltar no tempo até um dado ponto... []s Chiappa
[oracle_br] Re: Standby Database
Apenas estou montando o banco, estou usando os mesmos procedimentos quando é para criá-lo... startup nomount pfile=... alter database mount standby database; recover managed standby database; Mas o primary não está enviando os archives automaticamente para o standby, apresenta o erro TNS-12571, porém da máquina do primary consigo pingar (tnsping) o standby. --- Em [EMAIL PROTECTED], "Daniel Matthiensen" <[EMAIL PROTECTED]> escreveu > Peguei a conversa meio andando, mas... após o backup vc está apenas montando o banco ou montando e abrindo? se estiver abrindo, tem que ser em modo read only, senão vc não consegue voltar a montar como standby > > > > > > - Original Message - > From: claudiacosta_souza > To: [EMAIL PROTECTED] > Sent: Tuesday, June 14, 2005 2:47 PM > Subject: [oracle_br] Re: Standby Database > > > Welvis > > Assim q monto o standby database a partir do primary, tudo > funciona muito bem, os archives do primary são enviados > automaticamente para o standby, mas quando preciso tirar o standby do > ar (shutdown) para backup e abro o banco, os archives não são mais > enviados automaticamente do primary para o standby. > Essa é minha grande dúvida, pq após o backup os archives não > voltam a ser enviados normalmente? > Da máquina do primary consigo pingar (tnsping) o standby sem > problemas. > > Obrigada! > Claudia Costa > > > --- Em [EMAIL PROTECTED], Welvis Douglas Silva Moreto > <[EMAIL PROTECTED]> escreveu > > > > Cara se vc tiver usando a versão enterprise do oracle > > ele gera direto no stand by > > > > os parametros são. > > > > log_archive_dest ou log_archive_dest1 eu não me lembro > > direito,.,, testa ai velho... > > > > att, > > > > Welvis Douglas > > msn - [EMAIL PROTECTED] > > Fone - (43)9117-7249 > > > > --- claudiacosta_souza > > <[EMAIL PROTECTED]> escreveu: > > > > > > - > > Pessoal > > > > Estou fazendo testes com o standby database no > > modo recover > > managed, mas quando tento parar o standby para backup, > > não consigo > > fazer com que os archives do primary sejam enviados > > para o standby. > > Alguém tem alguma idéia que possa me ajudar? > > > > Obrigada, > > Claudia Costa > > > > > > > > > > > > > > > __ > > > > Cancelar assinatura...: > > [EMAIL PROTECTED] > > Moderadores da lista:Dorian Anderson Soutto > > [EMAIL PROTECTED] > > Fernanda Damous [EMAIL PROTECTED] > > Alisson Aguiar [EMAIL PROTECTED] > > > __ > > http://br.groups.yahoo.com/group/oracle_br/ > > > __ > > > > Sair da Lista...: > > [EMAIL PROTECTED] > > > > > > > > - > > Links do Yahoo! Grupos > > > >Para visitar o site do seu grupo na web, acesse: > > http://br.groups.yahoo.com/group/oracle_br/ > > > >Para sair deste grupo, envie um e-mail para: > > [EMAIL PROTECTED] > > > >O uso que você faz do Yahoo! Grupos está sujeito > > aos Termos do Serviço do Yahoo!. > > > > > > > > > > > > > > > > > > Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! > http://mail.yahoo.com.br > > > > > __ > > Cancelar assinatura...: [EMAIL PROTECTED] > Moderadores da lista:Dorian Anderson Soutto [EMAIL PROTECTED] > Fernanda Damous [EMAIL PROTECTED] > Alisson Aguiar [EMAIL PROTECTED] > __ > http://br.groups.yahoo.com/group/oracle_br/ > __ > > Sair da Lista...: [EMAIL PROTECTED] > > > > -- > Links do Yahoo! Grupos > > a.. Para visitar o site do seu grupo na web, acesse: > http://br.g
