Re: [oracle_br] Re: Data Guard
Dependendo do seu orçamento, é melhor colocar uma maquina em cada datacenter mesmo e replicar de um pro outro com dataguard, nesse ambiente, o que mais se tem é banda disponivel. Replicacao caseira com base de 10 mb vai fazer bum mesmo, por causa do tamanho dos arquivos gerados x demora por causa de largura de banda. On 31 July 2015 at 08:50, Alessandro Silva xalexsi...@yahoo.com.br [oracle_br] wrote: > > > Chiappa, só pegando o embalo da thread... > > O Data Guard não precisa de licença adicional, MAS caso você utilize a > base standby para leitura ou como snapshot standby você precisa pagar a > licença da option Active Data Guard, é isso? > > > > Em Quinta-feira, 30 de Julho de 2015 17:09, "jlchia...@yahoo.com.br > [oracle_br]" escreveu: > > > > Blz ? Então, só ficou a resposta sobre a Rede, no item : > > " > Tem muitos DDLs, alteração de estruturas de tabelas e/ou recriação de > stored PL/SQLs nesse banco origem ? O link de rede entre as duas máquinas é > permanente , seguro e Confiável ? > > >> So producao sera contingenciada. > " > > Isso porque, Obviamente, para vc poder enviar as alterações para o site > remoto (e isso SSEJA QUAL FOR A SOLUÇÃO !!) é Claro que vc precisa de um > LINK DE REDE ativo, bom, estável, performático e Confiável - já cansei de > ver casos em que o pessoal se esquece disso aí contrata um link de rede > fuleiro qquer de 10 Mbps (e ainda por cima compartilhado com os usuários > finais) , aí na hora que o banco primary começa a trabalhar pesado a rede > não consegue acompanhar, o contingência começa a ficar mais e mais > atrasado, até fazer Bum... > > SE esse Questinamento sobre a rede resultar que OK, o link é Confiável e > performático, dado que vc está no Enterprise Edition e o banco já tá em > Archive-mode, aí não tem o que pensar , o DATAGUARD Físico é a melhor > solução, pois : > > a. os Conceitos tecnológicos que ela usa (geração e aplicação de archived > redo logs) são antigos, já estabelecidos há muito e Extremamente bem > conhecidos e testados no mundo do banco de dados Oracle > > b. a Oracle garante que funciona com QUALQUER aplicação rodando sob > qualquer Storage, é Fisico... Uma decorrência PROVEITOSA disso é que > datatypes "especiais (exemplo, os que precisam de file handles, como LOBs) > ou datatypes não-escalares acabam sendo Transparentes pro DG/standby físico > : como ele replica bytes de log, ele nem fica Sabendo, é Irrelevante pra > ele absolutamente qualquer atributo lógico... > > c. ele é uma solução Flexível, vc a pode configurar para zero data loss OU > para maximum performance facilmente, sem a necessidade de instalar nada > > d. não tem Custo, é uma solução já embutida no valor da licença do > Enterprise Edition - só se vc quiser mais tarde usar o banco standby como > ambiente de relatórios (a feature do Active Data Guard) é que vc precisará > de Licença adicional > > > Aí, os esclarecimentos adicionais : > > => com "datatypes escalares" eu me refiro aos datatypes que guardam mais > de um valor (exemplo, colunas XML), dá um look no manual "Database SQL > Language Reference" item Data Types para mais refs Esses caras > apresentam diversos impedimentos para a replicação de dados ou para o > standby lógico, MAS como vc pretende ir pro standby físico com DG, essse > impedimentos não se aplicam nesse caso... , > > => é Óbvio que dá pra fazer disaster recover sem dataguard, e é Óbvio > que a IBM, sendo a fornecedora do Storage, vai tentar pressionar por uma > solução baseada no Storage, OU então (já que fornece o SO) pode pressionar > por uma solução a nível de SO, externa, como o HACMP citado... > A questão é que, além dessas soluções NÂO apresentar as vantagens acima > no que se refere à Oracle, elas PODE ter algum custo a mais e vais e saber > se a IBM realmente, positivamente, garante que todas elas Suportam sim, > mesmo, o RDBMS Oracle Eu SEMPRE fico com um pé atrás em usar uma > tecnologia não-Oracle com um RDBMS Oracle... SE vc chegar a penssar nisso, > EXIJA POR ESCRITO todas as garantias que puder... > >[]s > > Chiappa > > > >
Re: [oracle_br] Re: Data Guard
Sim, afaik a partir do instante em que vc fazer o standby Disponível (para leitura que seja, ou em read-write com a recurso no snapshot) vc TEM que ter para isso adquirido a Licença extra do Active Dataguard , a licença básica do Dataguard que já vêm no Enterprise Edition só cobre o uso padrão/básico do dataguard (ie, o primary apenas aberto, o standby INDISPONÍVEL pros usuários constantemente aplicando os archives recebidos)... []s Chiappa
Re: [oracle_br] Re: Data Guard
Chiappa, só pegando o embalo da thread...
O Data Guard não precisa de licença adicional, MAS caso você utilize a base
standby para leitura ou como snapshot standby você precisa pagar a licença da
option Active Data Guard, é isso?
Em Quinta-feira, 30 de Julho de 2015 17:09, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Blz ? Então, só ficou a resposta sobre a Rede, no item :
"
Tem muitos DDLs, alteração de estruturas de tabelas e/ou recriação de stored
PL/SQLs nesse banco origem ? O link de rede entre as duas máquinas é permanente
, seguro e Confiável ?
>> So producao sera contingenciada.
"
Isso porque, Obviamente, para vc poder enviar as alterações para o site remoto
(e isso SSEJA QUAL FOR A SOLUÇÃO !!) é Claro que vc precisa de um LINK DE REDE
ativo, bom, estável, performático e Confiável - já cansei de ver casos em que o
pessoal se esquece disso aí contrata um link de rede fuleiro qquer de 10 Mbps
(e ainda por cima compartilhado com os usuários finais) , aí na hora que o
banco primary começa a trabalhar pesado a rede não consegue acompanhar, o
contingência começa a ficar mais e mais atrasado, até fazer Bum...
SE esse Questinamento sobre a rede resultar que OK, o link é Confiável e
performático, dado que vc está no Enterprise Edition e o banco já tá em
Archive-mode, aí não tem o que pensar , o DATAGUARD Físico é a melhor solução,
pois :
a. os Conceitos tecnológicos que ela usa (geração e aplicação de archived redo
logs) são antigos, já estabelecidos há muito e Extremamente bem conhecidos e
testados no mundo do banco de dados Oracle
b. a Oracle garante que funciona com QUALQUER aplicação rodando sob qualquer
Storage, é Fisico... Uma decorrência PROVEITOSA disso é que datatypes
"especiais (exemplo, os que precisam de file handles, como LOBs) ou datatypes
não-escalares acabam sendo Transparentes pro DG/standby físico : como ele
replica bytes de log, ele nem fica Sabendo, é Irrelevante pra ele absolutamente
qualquer atributo lógico...
c. ele é uma solução Flexível, vc a pode configurar para zero data loss OU para
maximum performance facilmente, sem a necessidade de instalar nada
d. não tem Custo, é uma solução já embutida no valor da licença do Enterprise
Edition - só se vc quiser mais tarde usar o banco standby como ambiente de
relatórios (a feature do Active Data Guard) é que vc precisará de Licença
adicional
Aí, os esclarecimentos adicionais :
=> com "datatypes escalares" eu me refiro aos datatypes que guardam mais de
um valor (exemplo, colunas XML), dá um look no manual "Database SQL Language
Reference" item Data Types para mais refs Esses caras apresentam diversos
impedimentos para a replicação de dados ou para o standby lógico, MAS como vc
pretende ir pro standby físico com DG, essse impedimentos não se aplicam nesse
caso... ,
=> é Óbvio que dá pra fazer disaster recover sem dataguard, e é Óbvio que a
IBM, sendo a fornecedora do Storage, vai tentar pressionar por uma solução
baseada no Storage, OU então (já que fornece o SO) pode pressionar por uma
solução a nível de SO, externa, como o HACMP citado...
A questão é que, além dessas soluções NÂO apresentar as vantagens acima no
que se refere à Oracle, elas PODE ter algum custo a mais e vais e saber se a
IBM realmente, positivamente, garante que todas elas Suportam sim, mesmo, o
RDBMS Oracle Eu SEMPRE fico com um pé atrás em usar uma tecnologia
não-Oracle com um RDBMS Oracle... SE vc chegar a penssar nisso, EXIJA POR
ESCRITO todas as garantias que puder...
[]s
Chiappa #yiv8125739505 #yiv8125739505 -- #yiv8125739505ygrp-mkp
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0
10px;}#yiv8125739505 #yiv8125739505ygrp-mkp hr {border:1px solid
#d8d8d8;}#yiv8125739505 #yiv8125739505ygrp-mkp #yiv8125739505hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv8125739505 #yiv8125739505ygrp-mkp #yiv8125739505ads
{margin-bottom:10px;}#yiv8125739505 #yiv8125739505ygrp-mkp .yiv8125739505ad
{padding:0 0;}#yiv8125739505 #yiv8125739505ygrp-mkp .yiv8125739505ad p
{margin:0;}#yiv8125739505 #yiv8125739505ygrp-mkp .yiv8125739505ad a
{color:#ff;text-decoration:none;}#yiv8125739505 #yiv8125739505ygrp-sponsor
#yiv8125739505ygrp-lc {font-family:Arial;}#yiv8125739505
#yiv8125739505ygrp-sponsor #yiv8125739505ygrp-lc #yiv8125739505hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8125739505
#yiv8125739505ygrp-sponsor #yiv8125739505ygrp-lc .yiv8125739505ad
{margin-bottom:10px;padding:0 0;}#yiv8125739505 #yiv8125739505actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8125739505
#yiv8125739505activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8125739505
#yiv8125739505activity span {font-weight:700;}#yiv8125739505
#yiv8125739505activity span:first-child
{text-transform:uppercase;}#yiv8125739505 #yiv8125739505activity span a
Re: [oracle_br] Re: Data Guard
Blz ? Então, só ficou a resposta sobre a Rede, no item : " Tem muitos DDLs, alteração de estruturas de tabelas e/ou recriação de stored PL/SQLs nesse banco origem ? O link de rede entre as duas máquinas é permanente , seguro e Confiável ? >> So producao sera contingenciada. " Isso porque, Obviamente, para vc poder enviar as alterações para o site remoto (e isso SSEJA QUAL FOR A SOLUÇÃO !!) é Claro que vc precisa de um LINK DE REDE ativo, bom, estável, performático e Confiável - já cansei de ver casos em que o pessoal se esquece disso aí contrata um link de rede fuleiro qquer de 10 Mbps (e ainda por cima compartilhado com os usuários finais) , aí na hora que o banco primary começa a trabalhar pesado a rede não consegue acompanhar, o contingência começa a ficar mais e mais atrasado, até fazer Bum... SE esse Questinamento sobre a rede resultar que OK, o link é Confiável e performático, dado que vc está no Enterprise Edition e o banco já tá em Archive-mode, aí não tem o que pensar , o DATAGUARD Físico é a melhor solução, pois : a. os Conceitos tecnológicos que ela usa (geração e aplicação de archived redo logs) são antigos, já estabelecidos há muito e Extremamente bem conhecidos e testados no mundo do banco de dados Oracle b. a Oracle garante que funciona com QUALQUER aplicação rodando sob qualquer Storage, é Fisico... Uma decorrência PROVEITOSA disso é que datatypes "especiais (exemplo, os que precisam de file handles, como LOBs) ou datatypes não-escalares acabam sendo Transparentes pro DG/standby físico : como ele replica bytes de log, ele nem fica Sabendo, é Irrelevante pra ele absolutamente qualquer atributo lógico... c. ele é uma solução Flexível, vc a pode configurar para zero data loss OU para maximum performance facilmente, sem a necessidade de instalar nada d. não tem Custo, é uma solução já embutida no valor da licença do Enterprise Edition - só se vc quiser mais tarde usar o banco standby como ambiente de relatórios (a feature do Active Data Guard) é que vc precisará de Licença adicional Aí, os esclarecimentos adicionais : => com "datatypes escalares" eu me refiro aos datatypes que guardam mais de um valor (exemplo, colunas XML), dá um look no manual "Database SQL Language Reference" item Data Types para mais refs Esses caras apresentam diversos impedimentos para a replicação de dados ou para o standby lógico, MAS como vc pretende ir pro standby físico com DG, essse impedimentos não se aplicam nesse caso... , => é Óbvio que dá pra fazer disaster recover sem dataguard, e é Óbvio que a IBM, sendo a fornecedora do Storage, vai tentar pressionar por uma solução baseada no Storage, OU então (já que fornece o SO) pode pressionar por uma solução a nível de SO, externa, como o HACMP citado... A questão é que, além dessas soluções NÂO apresentar as vantagens acima no que se refere à Oracle, elas PODE ter algum custo a mais e vais e saber se a IBM realmente, positivamente, garante que todas elas Suportam sim, mesmo, o RDBMS Oracle Eu SEMPRE fico com um pé atrás em usar uma tecnologia não-Oracle com um RDBMS Oracle... SE vc chegar a penssar nisso, EXIJA POR ESCRITO todas as garantias que puder... []s Chiappa
Re: [oracle_br] Re: Data Guard
Blz ? Então, só ficou a resposta sobre a Rede, no item : " Tem muitos DDLs, alteração de estruturas de tabelas e/ou recriação de stored PL/SQLs nesse banco origem ? O link de rede entre as duas máquinas é permanente , seguro e Confiável ? >> So producao sera contingenciada. " Isso porque, Obviamente, para vc poder enviar as alterações para o site remoto (e isso SSEJA QUAL FOR A SOLUÇÃO !!) é Claro que vc precisa de um LINK DE REDE ativo, bom, estável, performático e Confiável - já cansei de ver casos em que o pessoal se esquece disso aí contrata um link de rede fuleiro qquer de 10 Mbps (e ainda por cima compartilhado com os usuários finais) , aí na hora que o banco primary começa a trabalhar pesado a rede não consegue acompanhar, o contingência começa a ficar mais e mais atrasado, até fazer Bum... SE esse Questinamento sobre a rede resultar que OK, o link é Confiável e performático, dado que vc está no Enterprise Edition e o banco já tá em Archive-mode, aí não tem o que pensar , o DATAGUARD Físico é a melhor solução, pois : a. os Conceitos tecnológicos que ela usa (geração e aplicação de archived redo logs) são antigos, já estabelecidos há muito e Extremamente bem conhecidos e testados no mundo do banco de dados Oracle b. a Oracle garante que funciona com QUALQUER aplicação rodando sob qualquer Storage, é Fisico... Uma decorrência PROVEITOSA disso é que datatypes "especiais (exemplo, os que precisam de file handles, como LOBs) ou datatypes não-escalares acabam sendo Transparentes pro DG/standby físico : como ele replica bytes de log, ele nem fica Sabendo, é Irrelevante pra ele absolutamente qualquer atributo lógico... c. ele é uma solução Flexível, vc a pode configurar para zero data loss OU para maximum performance facilmente, sem a necessidade de instalar nada d. não tem Custo, é uma solução já embutida no valor da licença do Enterprise Edition - só se vc quiser mais tarde usar o banco standby como ambiente de relatórios (a feature do Active Data Guard) é que vc precisará de Licença adicional Aí, os esclarecimentos adicionais : => com "datatypes escalares" eu me refiro aos datatypes que guardam mais de um valor (exemplo, colunas XML), dá um look no manual "Database SQL Language Reference" item Data Types para mais refs Esses caras apresentam diversos impedimentos para a replicação de dados ou para o standby lógico, MAS como vc pretende ir pro standby físico com DG, essse impedimentos não se aplicam nesse caso... , => é Óbvio que dá pra fazer disaster recover sem dataguard, e é Óbvio que a IBM, sendo a fornecedora do Storage, vai tentar pressionar por uma solução baseada no Storage, OU então (já que fornece o SO) pode pressionar por uma solução a nível de SO, externa, como o HACMP citado... A questão é que, além dessas soluções NÂO apresentar as vantagens acima no que se refere à Oracle, elas PODE ter algum custo a mais e vais e saber se a IBM realmente, positivamente, garante que todas elas Suportam sim, mesmo, o RDBMS Oracle Eu SEMPRE fico com um pé atrás em usar uma tecnologia não-Oracle com um RDBMS Oracle... SE vc chegar a penssar nisso, EXIJA POR ESCRITO todas as garantias que puder... []s Chiappa
Re: [oracle_br] Re: Data Guard
Vamos lá:
Qual é o objetivo dessa contingência, é só assumir quando o primary falhar, ou
ela também poderia ser usada como ambiente de relatório
O objetivo principal é assumir em caso de desastre. Por exigência do mercado
nos temos que implementar a contingência.
Ela fica num outro servidor no mesmo datacenter, OU num servidor remoto para
servir também de disaster recover (ie, assumir se o prédio principal pegar
fogo, coisa assim) ?
Bem, o ambiente que assumira o comando em caso de desastre fica em Sao Paulo, a
empresa esta no Rio.
Qual o SLA para a contingência assumir quando o primary morrer ? tem que ser
automático, ou pode ser manual o switch-over ?
Como envolve vários sistemas, ha uma variação no SLA, Tem que ser automático.-
Em caso de desastreSwitch-over - Nos casos de manutenção.
E quando vc diz que "não tem o Dataguard", isso é porque vc tá usando um RDBMS
Standard Edition, onde não é possível se Licenciar o Dataguard, é isso, OU na
verdade é Enterprise Edition seu RDBMS e vc simplesmente não tem o DATAGUARD
configurado ?
É Enterprise Edition e simplesmente não tem o DATAGUARD configurado.
Esse banco a proteger está rodando (ou pode passar a rodar) em archive mode ?
Ja estao no modo archive. Pelo menos isso nao é.
Há datatypes não-escalares nesse database, que impeçam uma replicação dos dados
manual ?
O ambiente e bem diversificado, temo sistema SAP e Nao SAP Obs. Nao entendi
datatypes não-escalares
Tem muitos DDLs, alteração de estruturas de tabelas e/ou recriação de stored
PL/SQLs nesse banco origem ? O link de rede entre as duas máquinas é permanente
, seguro e Confiável ?
So producao sera contingenciada.
Nao sei se mencionei, o servico contratado foi o da IBM, eles alegam que
conseguem fazer sem o DataGuard.
Eu como DBA, prefiro usar a ferramenta da Oracle.
Obrigado.
Atenciosamente,
André Luiz R. Marques
Administrador de Banco de Dados - SQL Server/OracleTel: (21) 99978-4564 Evite
imprimir. Colabore com o Meio Ambiente! "Embora ninguém possa voltar atrás e
fazer um novo começo, qualquer um pode
começar agora e fazer um novo fim." Chico Xavier
Em Quarta-feira, 29 de Julho de 2015 16:37, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Explica direitinho aí : esclareça pra gente, qual é o objetivo dessa
contingência, é só assumir quando o primary falhar, ou ela também poderia ser
usada como ambiente de relatório ? Ela fica num outro servidor no mesmo
datacenter, OU num servidor remoto para servir também de disaster recover (ie,
assumir se o prédio principal pegar fogo, coisa assim) ? Qual o SLA para a
contingência assumir quando o primary morrer ? tem que ser automático, ou pode
ser manual o switch-over ? E quando vc diz que "não tem o Dataguard", isso é
porque vc tá usando um RDBMS Standard Edition, onde não é possível se Licenciar
o Dataguard, é isso, OU na verdade é Enterprise Edition seu RDBMS e vc
simplesmente não tem o DATAGUARD configurado ?? Esse banco a proteger está
rodando (ou pode passar a rodar) em archive mode ? Há datatypes não-escalares
nesse database, que impeçam uma replicação dos dados manual ? Tem muitos DDLs,
alteração de estruturas de tabelas e/ou recriação de stored PL/SQLs nesse banco
origem ? O link de rede entre as duas máquinas é permanente , seguro e
Confiável ???
DEPENDENDO das suas Respostas, CASO seja impossível o DATAGUARD físico (que é
SIM o método preferido), a gente pode indicar um Standby manual, ou um cluster
ativo-passivo pelo Sistema Operacional (HACMP/PowerHA, provavelmente, já que vc
tá no AIX) ou então replicação de dados...
[]s
Chiappa #yiv5566316708 #yiv5566316708 -- #yiv5566316708ygrp-mkp
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0
10px;}#yiv5566316708 #yiv5566316708ygrp-mkp hr {border:1px solid
#d8d8d8;}#yiv5566316708 #yiv5566316708ygrp-mkp #yiv5566316708hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv5566316708 #yiv5566316708ygrp-mkp #yiv5566316708ads
{margin-bottom:10px;}#yiv5566316708 #yiv5566316708ygrp-mkp .yiv5566316708ad
{padding:0 0;}#yiv5566316708 #yiv5566316708ygrp-mkp .yiv5566316708ad p
{margin:0;}#yiv5566316708 #yiv5566316708ygrp-mkp .yiv5566316708ad a
{color:#ff;text-decoration:none;}#yiv5566316708 #yiv5566316708ygrp-sponsor
#yiv5566316708ygrp-lc {font-family:Arial;}#yiv5566316708
#yiv5566316708ygrp-sponsor #yiv5566316708ygrp-lc #yiv5566316708hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5566316708
#yiv5566316708ygrp-sponsor #yiv5566316708ygrp-lc .yiv5566316708ad
{margin-bottom:10px;padding:0 0;}#yiv5566316708 #yiv5566316708actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5566316708
#yiv5566316708activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5566316708
#yiv5566316708activity span {font-weight:700;}#yiv5566316708
#yiv5566316708activity span:first-child
{text-tran
Re: [oracle_br] RE: data guard + flashback
Tudo jóia ? Só para Referência de quem acompanhou a thread, realmente no database 11g temos a moleza do Snapshot Standby, mas esse cara nada mais é do que um Automatizador - pra quem está na versão 10g, eu tinha comigo que era Perfeitamente Possível se fazer o mesmo, simulando a feature, via um DEFER da aplicação de archives no primary, desabilitar o standby, abrir em read/write (como um banco Normal, que nem sabe que já foi um dia standby) , e depois dos testes todos feitos, voltar o database até o exato SCN que estava, reabrir em modo standby e aplicar os archives pendentes : http://jaffardba.blogspot.com.br/2007/12/simulating-11g-snapshot-standby.html tem um exemplo. Eu pra variar Ainda Não Consegui arranjar o tempo pra fazer o teste por mim mesmo, mas em tese, falando pelos conceitos, não teria porque não funcionar, DESDE QUE a pessoa tenha espaço em disco suficiente para manter todos os archives necessários (no primary) E para poder ter um DB_FLASHBACK_RETENTION_TARGET suficiente []s Chiappa
Re: [oracle_br] Re: Data Guard
Estou tentando alocar o canal para o disco e fita para apagar o backups obsoletos, só que na hora de alocar o canal para fita me gera o seguinte erro: RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; RMAN-00571: === RMAN-00569: === ERROR MESSAGE STACK FOLLOWS === RMAN-00571: === RMAN-03009: failure of allocate command on ORA_MAINT_SBT_TAPE_5 channel at 08/01/2013 14:41:49 ORA-19554: error allocating device, device type: SBT_TAPE, device name: ORA-27000: skgfqsbi: failed to initialize storage subsystem (SBT) layer IBM AIX RISC System/6000 Error: 2534: Unknown system error Additional information: 7011 ORA-19511: Error received from media manager layer, error text: SBT error = 7011, errno = 2534, sbtopen: system error Estou entnrando em contato com o pessoal do TSM De: J. Laurindo Chiappa Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 1 de Agosto de 2013 14:29 Assunto: [oracle_br] Re: Data Guard Explica melhor esse "são levados para o data guard e para fita" : aonde é feito o backup dos archives, é na máquina primária ?? Se sim ok, em tese vc poderia não ter backup de archivelog no standby - eu, porém, paranóico que sou, ** sinceramente ** se fosse minha a Administração Faria Sim um backupzinho dos archives aplicados no standby antes de os remover... Quanto ao erro, veja a minha msg anterior, aonde Suponho que é falta de alocação de channels para todos os devices que possuem backups registrados... []s Chiappa --- Em mailto:oracle_br%40yahoogrupos.com.br, Rafael Mendonca escreveu > > Chiapppa, os archives são levados para o data guard e para fita, então eu > posso deletar os archives do data guard que foram aplicados, já que eles já > foram para fita a partir do database de produção correto? > > Agora estou com o problema de deleção dos archives na FRA que está prestes a > estourar. > > RMAN> report obsolete; > > RMAN retention policy will be applied to the command > RMAN retention policy is set to recovery window of 30 days > Report of obsolete backups and copies > Type Key Completion Time Filename/Handle > -- -- > ... > ... > > Backup Set 5521 17-JUN-13 > Backup Piece 5521 17-JUN-13 > full_SJSE_5875_818303657_njocckl9_1 > Backup Set 5522 17-JUN-13 > Backup Piece 5522 17-JUN-13 > full_SJSE_5876_818306243_nkoccn63_1 > Archive Log 769 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_28/thread_1_seq_9051.1235.813938555 > Archive Log 741 24-JUL-13 > +FRA/sjsedg/archivelog/2013_05_01/thread_1_seq_9080.650.814261363 > Archive Log 742 24-JUL-13 > +FRA/sjsedg/archivelog/2013_05_01/thread_1_seq_9081.606.814261695 > Archive Log 770 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_28/thread_1_seq_9052.616.813969771 > Archive Log 771 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9043.1269.813810647 > Archive Log 772 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9044.1233.813810649 > Archive Log 773 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9045.1225.813813413 > Archive Log 774 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9046.1245.813813425 > Archive Log 775 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9047.1283.813829353 > Archive Log 776 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9048.632.813829669 > Archive Log 744 24-JUL-13 > +FRA/sjsedg/archivelog/2013_05_01/thread_1_seq_9083.1253.814312879 > Archive Log 780 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9034.1359.813768303 > Archive Log 781 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9035.1363.813768671 > Archive Log 782 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9036.1369.813768711 > Archive Log 783 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9037.810.813794433 > Archive Log 784 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9038.682.813794489 > Archive Log 779 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9033.1397.813768301 > Archive Log 786 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9040.1237.813794615 > Archive Log 787 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9041.1345.813794643 > Archive Log 788 24-JUL-13 > +FRA/sjsedg/archivelog/2013_04_
Re: [oracle_br] Re: Data Guard
Chiapppa, os archives são levados para o data guard e para fita, então eu posso deletar os archives do data guard que foram aplicados, já que eles já foram para fita a partir do database de produção correto? Agora estou com o problema de deleção dos archives na FRA que está prestes a estourar. RMAN> report obsolete; RMAN retention policy will be applied to the command RMAN retention policy is set to recovery window of 30 days Report of obsolete backups and copies Type Key Completion Time Filename/Handle -- -- ... ... Backup Set 5521 17-JUN-13 Backup Piece 5521 17-JUN-13 full_SJSE_5875_818303657_njocckl9_1 Backup Set 5522 17-JUN-13 Backup Piece 5522 17-JUN-13 full_SJSE_5876_818306243_nkoccn63_1 Archive Log 769 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_28/thread_1_seq_9051.1235.813938555 Archive Log 741 24-JUL-13 +FRA/sjsedg/archivelog/2013_05_01/thread_1_seq_9080.650.814261363 Archive Log 742 24-JUL-13 +FRA/sjsedg/archivelog/2013_05_01/thread_1_seq_9081.606.814261695 Archive Log 770 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_28/thread_1_seq_9052.616.813969771 Archive Log 771 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9043.1269.813810647 Archive Log 772 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9044.1233.813810649 Archive Log 773 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9045.1225.813813413 Archive Log 774 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9046.1245.813813425 Archive Log 775 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9047.1283.813829353 Archive Log 776 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9048.632.813829669 Archive Log 744 24-JUL-13 +FRA/sjsedg/archivelog/2013_05_01/thread_1_seq_9083.1253.814312879 Archive Log 780 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9034.1359.813768303 Archive Log 781 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9035.1363.813768671 Archive Log 782 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9036.1369.813768711 Archive Log 783 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9037.810.813794433 Archive Log 784 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9038.682.813794489 Archive Log 779 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9033.1397.813768301 Archive Log 786 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9040.1237.813794615 Archive Log 787 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9041.1345.813794643 Archive Log 788 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9042.1241.813795295 Archive Log 778 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9032.608.813768299 Archive Log 785 24-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9039.636.813794559 ... ... RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK; allocated channel: ORA_MAINT_DISK_4 channel ORA_MAINT_DISK_4: SID=1528 device type=DISK RMAN> delete obsolete; RMAN retention policy will be applied to the command RMAN retention policy is set to recovery window of 30 days Deleting the following obsolete backups and copies: Type KeyCompletion TimeFilename/Handle --- -- -- ... ... Backup Set 5521 17-JUN-13 Backup Piece 5521 17-JUN-13 full_SJSE_5875_818303657_njocckl9_1 Backup Set 5522 17-JUN-13 Backup Piece 5522 17-JUN-13 full_SJSE_5876_818306243_nkoccn63_1 Backup Set 5523 17-JUN-13 Backup Piece 5523 17-JUN-13 full_SJSE_5877_818306398_nloccnau_1 Archive Log 77524-JUL-13 +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9047.1283.813829353 Archive Log 77624-JUL-13 +FRA/sjsedg/archivelog/2013_04_27/thread_1_seq_9048.632.813829669 Archive Log 74424-JUL-13 +FRA/sjsedg/archivelog/2013_05_01/thread_1_seq_9083.1253.814312879 Archive Log 78024-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9034.1359.813768303 Archive Log 78124-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9035.1363.813768671 Archive Log 78224-JUL-13 +FRA/sjsedg/archivelog/2013_04_26/thread_1_seq_9036.1369.813768711 Archive Log 78324-JUL-13 +FRA/sjsedg/archive
Re: [oracle_br] Re: Data Guard and Mudanca de Flash Recovery Area
Perfeito Chiappa! []s Em 4 de julho de 2013 17:01, J. Laurindo Chiappa escreveu: > ** > > > Verdade verdadeiríssima, Fábio : SE o colega lá estiver usando a FRA só e > apenas para flashback logs, backup destination e quetais Realmente não > daria nenhum "problema" para o funcionamento do database em si > Já se ele usa/usava a FRA para archived redo logs destination, aí a coisa > MUDA de figura, pois como sabemos se a área de archived redo logs encher aí > o banco PÁRA, CONGELA, fica INDISPONÍVEL, é um negócio sério - Até por isso > eu PERGUNTEI por confirmação, muito embora ele tenha dito (ênfase com *s > minha) : > > "... . O que fizemos como acão de emergencia foi mudar a flash recovery > area (+flash para +data, por exemplo) dos bancos que estavam com *** > archive hung *** ." > > o que parde indicar que ele TEM/TINHA sim archived redo logs sendo gerados > na FRA (a FRA era/é o archive dest dele) , aí arch dest cheia é Sim um > grande problema > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br, Fabio Prado escreveu > > > > Jose Luis Ramos, > > > > Ter a FRA sempre cheia não necessariamente significa um problema. Tenho > > ambientes de produção que só utilizo ela para armazenar Flashback Logs e > > ela sempre está cheia. O importante é saber, no meu caso, se ela consegue > > armazenar os logs pelo tempo que eu necessito para utilizar Flashback > > Database. A consulta abaixo te dá informações sobre o log mais antigo que > > vc poderá usar da FRA: > > > > select * from v$flashback_database_log > > > > Att, > > > > Fábio Prado > > www.fabioprado.net > > > > > > > > > > Em 2 de julho de 2013 13:39, J. Laurindo Chiappa > > escreveu: > > > > > ** > > > > > > > > > Colega, vc não diz mas SUPONHO que estamos falando de DATAGUARD com > > > PHYSICAL STANDBY, okdoc ?? Sendo mesmo isso, o ** MAIS IMPORTANTE ** > vc não > > > diz : o arquivamente está sendo feito para a Flash Recovery Area, * OU > * a > > > FRA tá sendo usada só para backup ??? > > > Supondo o mais comum (ie, Physical DG com arquivamente de redo logs > sendo > > > feito na própria FRA - principalmente para permitir manageamento > > > automático) , aí é Claro que vc vai ter que reajustar os params de > origem > > > dos archives, em especial o LOG_ARCHIVE_DEST_1, a origem, que > certamente > > > deve estar apontando pra localização antiga da FRA, imagino ... > > > Agora, uma recomendação : já que vc diz que os bancos já estavam > > > desincronizados, se Viável em termos de tempo/recursos eu Diria que ao > > > invés de perder tempo levantando quas archives vão ser necessários e > onde > > > que estão, que vc simplesmente RECLONE o banco-origem e refaça o > standby... > > > > > > []s > > > > > > Chiappa > > > > > > --- Em oracle_br@yahoogrupos.com.br, Jose Ramos > > > escreveu > > > > > > > > > > > Bom dia, estive pesquisando sobre isso e não encontrei. É o seguinte: > > > > tivemos uma situacão onde a flash recovery area usada por alguns > bancos > > > > Data Guard ficaram 100% ocupadas. O que fizemos como acão de > emergencia > > > foi > > > > mudar a flash recovery area (+flash para +data, por exemplo) dos > bancos > > > que > > > > estavam com archive hung no alert.log. Essa mudanca (os backups usam > > > > catálogo) influencia em algo negativamente no DG ? Não achei nada que > > > > dissesse isso. Houve um questionamento aqui na empresa se isso foi > certo > > > ou > > > > errado. Mas não consigo achar nada para mostrar que essa mudanca não > > > > interfere no DG. Alias, esses bancos de DG ja estavam > desincronizados. > > > > Qualquer ajuda eu agradeco. Obrigado. > > > > > > > > > > > > -- > > > > Jose Luis Ramos Jr > > > > Campinas - SP - Brazil > > > > Oracle Database Administrator > > > > Fone: +55-19-91916882 > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > > -- > > Fábio Prado > > www.fabioprado.net > > "Compartilhando conhecimentos e treinando profissionais em Bancos de > Dados > > Oracle" > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > -- Fábio Prado www.fabioprado.net "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle" [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/
Re: [oracle_br] Re: Data Guard and Mudanca de Flash Recovery Area
Jose Luis Ramos, Ter a FRA sempre cheia não necessariamente significa um problema. Tenho ambientes de produção que só utilizo ela para armazenar Flashback Logs e ela sempre está cheia. O importante é saber, no meu caso, se ela consegue armazenar os logs pelo tempo que eu necessito para utilizar Flashback Database. A consulta abaixo te dá informações sobre o log mais antigo que vc poderá usar da FRA: select * from v$flashback_database_log Att, Fábio Prado www.fabioprado.net Em 2 de julho de 2013 13:39, J. Laurindo Chiappa escreveu: > ** > > > Colega, vc não diz mas SUPONHO que estamos falando de DATAGUARD com > PHYSICAL STANDBY, okdoc ?? Sendo mesmo isso, o ** MAIS IMPORTANTE ** vc não > diz : o arquivamente está sendo feito para a Flash Recovery Area, * OU * a > FRA tá sendo usada só para backup ??? > Supondo o mais comum (ie, Physical DG com arquivamente de redo logs sendo > feito na própria FRA - principalmente para permitir manageamento > automático) , aí é Claro que vc vai ter que reajustar os params de origem > dos archives, em especial o LOG_ARCHIVE_DEST_1, a origem, que certamente > deve estar apontando pra localização antiga da FRA, imagino ... > Agora, uma recomendação : já que vc diz que os bancos já estavam > desincronizados, se Viável em termos de tempo/recursos eu Diria que ao > invés de perder tempo levantando quas archives vão ser necessários e onde > que estão, que vc simplesmente RECLONE o banco-origem e refaça o standby... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Jose Ramos > escreveu > > > > > Bom dia, estive pesquisando sobre isso e não encontrei. É o seguinte: > > tivemos uma situacão onde a flash recovery area usada por alguns bancos > > Data Guard ficaram 100% ocupadas. O que fizemos como acão de emergencia > foi > > mudar a flash recovery area (+flash para +data, por exemplo) dos bancos > que > > estavam com archive hung no alert.log. Essa mudanca (os backups usam > > catálogo) influencia em algo negativamente no DG ? Não achei nada que > > dissesse isso. Houve um questionamento aqui na empresa se isso foi certo > ou > > errado. Mas não consigo achar nada para mostrar que essa mudanca não > > interfere no DG. Alias, esses bancos de DG ja estavam desincronizados. > > Qualquer ajuda eu agradeco. Obrigado. > > > > > > -- > > Jose Luis Ramos Jr > > Campinas - SP - Brazil > > Oracle Database Administrator > > Fone: +55-19-91916882 > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > -- Fábio Prado www.fabioprado.net "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle" [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
Re: [oracle_br] Re: DATA GUARD - SINCRONISMO - LOGICAL STANDBY
Jonathan, obrigado pela resposta. Mais uma pergunta: Se não é possivel fazer isso no 9i entao qual a diferenca de usarmos o ARCH ou LGWR para transportar os redos para o STANDBY?. Se em ambos os casos é necessário o SWITCH LOGFILE do PRIMARY para a informação chegar ao STANDBY não vejo diferença alguma. E tb não vejo acontecer o que o MANUAL da oracle fala. Que se colocarmos em o PRIMARY com LWGR SYNC AFFIRM a transação dele so sera comitada e liberada somente quando ela tiver sido escrita no REDO LOG do STANDBY? Isso realmente funciona? Abs Rodrigo On 12/15/06, jonathan_brbs <[EMAIL PROTECTED]> wrote: > > Olá Rodrigo, > Infelizmente isso não é possivel antes da versão 10G, > Onde através do comando ALTER DATABASE START LOGICAL STANDBY APPLY > IMMEDIATE conseguimos fazer a aplicação direta de Redos. Para > standby físico o comando seria ALTER DATABASE RECOVER MANAGED > STANDBY DATABASE USING CURRENT LOGFILE. > > []s > Jonathan Barbosa > > --- Em oracle_br@yahoogrupos.com.br , > "Rodrigo Telles" > <[EMAIL PROTECTED]> escreveu > > > > Pessoal, > > estou montando um ambiente de DATA GUARD aqui na empresa e estou > usando o > > LOGICAL STANDBY. > > Minha duvida é o seguinte: > > No PRIMARY configurei o log_archive_dest_2='SERVICE=GUARD_146 LGWR > SYNC > > AFFIRM' e o PROTECTION_MODE está em MAXIMUM AVAILABILITY. > > No banco LOGICAL STANDBY eu criei os grupos de STANDBY REDO LOG. > > Com isso estou querendo testar a situação de nenhum dado perdido > em caso de > > falha de comunicação entre os bancos. > > > > A teoria do ambiente acima diz que quando faço o COMMIT de uma > transação no > > PRYMARY o comando só é retornado quando essa transação for escrita > nos > > standby redo logs (garantindo que o outro banco recebeu a > transação). Porém > > quando rodo um script que popula uma tabela no PRIMARY e faço o > commit na > > transação, NADA acontece no banco STANDBY. Eu só consigo ver as > inserções no > > standby se eu der o SWITCH LOG FILE no banco PRIMARY. Nessa hora > eu consigo > > ver o LOG APPLY trabalhando e a tabela sendo populada. > > > > Como consigo fazer uma transação, quando "comitada" no banco > principal, seja > > vista na banco standby sem precisar ficar dando o switch logfile > ou esperar > > o proprio banco fazer o switch? > > > > Meu banco é o 9.2.0.8. > > > > Grato pela ajuda > > > > Rodrigo > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > [As partes desta mensagem que não continham texto foram removidas]
