miracle173's questions

Quando eu inicio uma instância Oracle com sqlplusos caminhos para os arquivos de dados armazenados nos arquivos de controle, o nome do arquivo de controle é armazenado no control_filesparâmetro de inicialização. Os parâmetros de inicialização são lidos de um arquivo ( init.ora, spfile.ora) encontrado em um local padrão ou sua localização pode ser passada para a instância do banco de dados na inicialização ( sqlplus startup pfile=filename, spfileparâmetro no script de inicialização). Assim, todos os arquivos necessários ao banco de dados podem ser localizados em posições arbitrárias e essas posições podem ser comunicadas à instância do banco de dados na inicialização. Mas e o arquivo de senha? Pela documentação sabemos que o local padrão para o arquivo de senha no Linux é $ORACLE_HOME/dbs/orapw${ORACLE_SID}. Se for um cluster, podemos informar ao software do cluster onde armazenamos o arquivo de senha,srvctl modify database -db <db_unique_name> -pwfile <password_file_path>. Mas o nome do arquivo de senha, neste caso, pode ser arbitrário.

• posso colocar o arquivo de senha em um local arbitrário e comunicar esse local ao banco de dados quando iniciar a instância com sqlplus.
• Então, como a Oracle sabe onde encontrar o arquivo de senha, especialmente se alguém inicia o banco de dados com sqlplusou rmannão pelo software de cluster?
• Posso consultar o banco de dados para descobrir a localização do arquivo de senha.

Meta

Eu quero mover um banco de dados do servidor A para o servidor B. Ambos os servidores têm a mesma tecnologia, então uma maneira é desligar o banco de dados de origem, copiar arquivos de dados, arquivo de controle, redo logs, arquivo de parâmetro de A para B e iniciar o banco de dados em B. Mas isso vai demorar muito, então vou usar um método que envolve os logs de arquivo. Por exemplo, posso usar o dataguard e construir um standby no SERVER B e alternar para este standby durante a migração. Mas por alguns motivos não quero usar um standby nem posso acessar o backup do banco de dados A para restaurá-lo em B.

Método

Antes do RMAN eu fazia isso da seguinte maneira:

1. Defina o banco de dados de A no modo de backup e copie todos os arquivos de dados para um disco conectado ao servidor e desative o modo de backup.
2. Mova este disco para B e anexe-o a ele.
3. Agora, de tempos em tempos, os arquivos são transportados para B e aplicados
4. Durante a migração os últimos arquivos são trazidos para B e aplicados e o banco de dados é copiado.

Claro que posso tentar isso com o RMAN também. E, em vez de copiar todos os arquivos, posso usar backups incrementais também.

Então eu faço o seguinte:

1. Faça um backup de nível 0 em um disco conectado ao servidor A.
2. Mova o disco para B e restaure o banco de dados no Servidor B.
3. Agora, de tempos em tempos, os arquivos são transportados para B e aplicados
4. Durante a migração os últimos arquivos são trazidos para B e aplicados e o banco de dados é copiado.

Eu até poderia aplicar backup incremental em vez de arquivos, exceto na última fase, mas aqui não estou interessado nisso.

Problema

Meu problema agora é que o backup do banco de dados em A é feito usando backups incrementais: 1. No domingo, é feito um backup de nível 0 2. nos 6 dias restantes, é feito um backup de nível 1

Desejo copiar meu backup de nível 0 para migração na quarta-feira. Mas isso atrapalha o backup regular. Suponha que eu faça esse backup de nível 0 na manhã de quarta-feira, então o backup de nível 1 noturno na quarta-feira se refere ao backup de nível 0 nesta manhã e não ao backup de nível 1 do dia anterior, como de costume. Mas no caso de uma restauração/recuperação quinta-feira temos um problema, porque o disco do backup de nível 0 de quarta-feira não está mais disponível. Acho que o banco de dados ainda pode ser recuperado porque o intervalo de tempo ausente pode ser recuperado com logs de arquivo. Mas eu quero uma solução que não atrapalhe o backup regular. Portanto, o backup de nível 1 na quarta-feira deve se referir ao backup de nível 1 na terça-feira.

Soluções

Como posso conseguir isso?

No momento eu vejo a seguinte maneira:

Eu uso a duplicata do banco de dados ativo para fazer uma cópia do banco de dados em A para o disco anexado a A. Esse banco de dados não deve ser aberto para que eu possa recuperá-lo com logs de arquivo posteriormente. Este disco é separado de A e movido para B. Aqui os arquivos de dados são registrados como cópias de arquivos de dados e restaurados para o servidor B.

Mas isso precisa de uma instância adicional em A para que eu possa duplicar essa instância.

Outra forma pode ser

 BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG... 

como descrito aqui

O manual diz:

Na BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG...verdade, o comando nem sempre cria um backup incremental de nível 1. Se não houver backup de cópia de imagem de nível 0 de um arquivo de dados específico, a execução desse comando cria um backup de cópia de imagem do arquivo de dados no disco com a tag especificada em vez de criar o backup de nível 1.

Cada vez que um arquivo de dados é adicionado ao banco de dados, uma cópia de imagem do novo arquivo de dados é criada na próxima execução do script. O tempo depois disso, o primeiro incremental de nível 1 para esse arquivo de dados é criado e, em todas as execuções subsequentes, o novo arquivo de dados é processado como qualquer outro arquivo de dados.

As tags devem ser usadas para identificar as cópias de arquivos de dados de nível 0 incrementais criadas para uso nesta estratégia, para que não interfiram em outras estratégias de backup implementadas. Se você tiver várias estratégias de backup incremental em vigor, o RMAN não poderá criar backups incrementais de nível 1 sem ambiguidade, a menos que você marque os backups de nível 0.

Isso soa bem, mas eu realmente tenho que testar isso.

Minha pergunta

Qual método você propõe para obter um backup online de nível 0 que é ignorado pelo backup de nível 0 a seguir do ciclo de backup regular?