Oracle
 sql >> Base de Dados >  >> RDS >> Oracle

Mecanismo Seguido pela Oracle quando fazemos backup a quente


Hot backup significa que o sistema está funcionando e as atualizações estão acontecendo normalmente

Eu explicaria aqui Mecanismo Seguido pela Oracle quando fazemos backup a quente

Hotbackup manual

Início de hotbackup manual com o comando abaixo para um tablespace

alter tablespace USERS inicia backup;

Poucas coisas acontecem nesse momento
1) O DBWn verifica o espaço de tabela (escreve todos os blocos sujos de um determinado SCN)

2) O CKPT para de atualizar o campo Checkpoint SCN nos cabeçalhos do arquivo de dados e começa a atualizar o campo Hot Backup Checkpoint SCN em vez disso
Os cabeçalhos do arquivo de dados que contêm o SCN do último ponto de verificação concluído não são atualizados enquanto um arquivo está no modo hot backup . Isso permite que o processo de recuperação entenda quais arquivos de redo log de arquivamento podem ser necessários para recuperar totalmente esse arquivo.

3)LGWR começa a registrar imagens completas de blocos alterados na primeira vez que um bloco é alterado após ser gravado pelo DBWn
A primeira vez que um bloco é alterado em um arquivo de dados que está no modo de backup a quente, o bloco inteiro é gravado no arquivos de log redo, não apenas os bytes alterados. Normalmente, apenas os bytes alterados (um vetor de redo) são gravados. No modo de backup a quente, o bloco inteiro é registrado pela primeira vez. Isso ocorre porque você pode entrar em uma situação em que o processo que copia o arquivo de dados e o DBWR estão trabalhando no mesmo bloco simultaneamente.
Digamos que eles estejam e o fator de leitura de bloqueio do SO seja 2K . O programa de backup vai ler um bloco Oracle de 8k. O sistema operacional dá 4k. Enquanto isso — DBWR pediu para reescrever este bloco. o sistema operacional agenda a gravação do DBWR para ocorrer agora. Todo o bloco de 8k é reescrito. O programa de backup começa a ser executado novamente (SO multitarefa aqui) e lê os últimos 4k do bloco. O programa de backup agora tem um bloco fraturado - a cabeça e a cauda são de dois pontos no tempo.
A Oracle não pode lidar com isso durante a recuperação. Portanto, registramos toda a imagem do bloco para que, durante a recuperação, esse bloco seja totalmente reescrito a partir do redo e seja pelo menos consistente consigo mesmo. Podemos recuperá-lo de lá.

Ponto importante no backup a quente

1) Para limitar o efeito desse registro adicional, você deve garantir que coloque apenas um tablepspace por vez no modo de backup e tire o tablespace do modo de backup assim que tiver feito o backup. Isso reduzirá o número de blocos que podem ter que ser registrados ao mínimo possível.

2) Se o tablespace estiver no modo hotbackup e o banco de dados for abortado. E então você tenta iniciar, ele irá reclamar sobre a recuperação, pois o arquivo de dados SCN desse tablespace será mais antigo, então para iniciar o banco de dados, precisamos primeiro encerrar o backup desse tablespace. Ele simplesmente atualiza o SCN do ponto de verificação com o SCN do Hot Backup Checkpoint
Backup do gerenciador de recuperação
Não precisamos colocar o tablespace no modo hotbackup para fazer o backup usando o hotbackmode
Como o RMAN é uma ferramenta Oracle, eles sabem como lidar com o caso do bloco fraturado, então não grava fragmentos de bloco ou blocos parciais no backup, ele grava a imagem de bloco consistente completa na mídia de backup. Portanto, o gerenciador de recuperação não precisa gravar o bloco completo no arquivo de redo log.

Além disso, o rman não congela o cabeçalho do arquivo de dados, continua a fazer checkpoints com a mesma regularidade, mas executa um checkpoint no tablespace.

O backup do RMAN anota o SCN inicial, Absolute Fuzzy SCN (que é o mesmo que iniciar o SCN no início) quando o backup começa e como os blocos são backup no arquivo de dados, o bloco é verificado quanto ao SCN, se for maior que o inicial SCN, Absolute Fuzzy SCN é atualizado com esse número. O mesmo vale para todos os blocos, quando todo o arquivo de dados é backup, esses dois números são armazenados no cabeçalho de backup.

Portanto, sempre que o RMAN restaurou esses backups, eles sabem que ele sabe de qual SCN inicial para terminar o SCN, ele precisa recuperar o arquivo de dados com certeza

Então, basicamente, não há sobrecarga como o aumento do registro no backup dinâmico do RMAN.

O mesmo vale para backup de imagem com RMAN