Olá,
Quando falamos de paralelismo de backups no RMAN, geralmente estamos falando de paralelização de arquivos, ou seja, cada canal (channel) trabalhando em um determinado arquivo, seja ele um datafile, controlfile ou spfile. No RMAN, quando executamos um comando, a quantidade de canais disponíveis para uso em um determinado dispositivo (device) é que determina se a operação de leitura ou escrita realizada será feita em paralelo. Quando uma tarefa é realizada em paralelo, o backup dos arquivos de banco de dados é realizada por mais de um canal (cada canal trabalhando em um arquivo). Bom, e se quisermos paralelizar o backup de apenas um arquivo, é possível? A partir do Oracle 11g é possível paralelizar a realização de backups de um único arquivo, ou seja, mais de um canal realizando backup de um único arquivo. Esta característica se chama MULTISECTION BACKUP e pode ser realizada através da cláusula SECTION SIZE do comando BACKUP. No mais, o objetivo deste artigo será demonstrar como os Multisection backups podem melhorar a performance em relação ao tempo na realização de backups físicos.
[oracle]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Sun Nov 2 11:30:14 2014
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select file#,name,bytes/1024/1024/1024 as GB from v$datafile where file#=10;
FILE# NAME GB
---------- ---------------------------------- ----------
10 /oradata/BD01/users01.dbf 7,67773438
Como exemplo, irei realizar o backup do datafile 10 listado acima que possui tamanho de 7,6 GB.
[oracle]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Nov Sun 2 11:41:30 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: BD01 (DBID=618743438)
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name BD01 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 7;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
Como demonstrado acima pelo comando SHOW ALL, atualmente o paralelismo está configurado para 7, ou seja, 7 canais serão alocados pelo RMAN no início do processo de backup ou recover.
RMAN> backup datafile 10;
Starting backup at 02/11/2014 11:41:51
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=34 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=69 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=70 device type=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: SID=101 device type=DISK
allocated channel: ORA_DISK_5
channel ORA_DISK_5: SID=132 device type=DISK
allocated channel: ORA_DISK_6
channel ORA_DISK_6: SID=162 device type=DISK
allocated channel: ORA_DISK_7
channel ORA_DISK_7: SID=193 device type=DISK
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00010 name=/oradata/BD01/users01.dbf
channel ORA_DISK_1: starting piece 1 at 02/11/2014 11:41:53
channel ORA_DISK_1: finished piece 1 at 02/11/2014 11:43:41
piece handle=/FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T114156_b3bm9ng8_.bkp
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:50
Finished backup at 02/11/2014 11:43:41
Após a finalização do backup acima, podemos perceber que realmente foram alocados 7 canais (ORA_DISK_1-7), mas somente o canal ORA_DISK_1 foi utilizado na realização do backup do datafile, ou seja, não houve paralelismo na operação. Foram gastos 00:01:50 (110 segundos) para realização do backup. Abaixo irei executar a mesma operação, mas agora informando a opção SECTION SIZE 1G, o que significa que eu quero que os backup pieces gerados tenham no máximo 1 GB de tamanho cada.
[oracle]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Sun Nov 2 11:50:52 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: BD01 (DBID=618743438)
RMAN> backup datafile 10 section size 1G;
Starting backup at 02/11/2014 11:51:09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=34 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=70 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=69 device type=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: SID=102 device type=DISK
allocated channel: ORA_DISK_5
channel ORA_DISK_5: SID=131 device type=DISK
allocated channel: ORA_DISK_6
channel ORA_DISK_6: SID=162 device type=DISK
allocated channel: ORA_DISK_7
channel ORA_DISK_7: SID=193 device type=DISK
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00010 name=/oradata/BD01/users01.dbf
backing up blocks 1 through 131072
channel ORA_DISK_1: starting piece 1 at 02/11/2014 11:51:11
channel ORA_DISK_2: starting compressed full datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00010 name=/oradata/BD01/users01.dbf
backing up blocks 131073 through 262144
channel ORA_DISK_2: starting piece 2 at 02/11/2014 11:51:12
channel ORA_DISK_3: starting compressed full datafile backup set
channel ORA_DISK_3: specifying datafile(s) in backup set
input datafile file number=00010 name=/oradata/BD01/users01.dbf
backing up blocks 262145 through 393216
channel ORA_DISK_3: starting piece 3 at 02/11/2014 11:51:12
channel ORA_DISK_4: starting compressed full datafile backup set
channel ORA_DISK_4: specifying datafile(s) in backup set
input datafile file number=00010 name=/oradata/BD01/users01.dbf
backing up blocks 393217 through 524288
channel ORA_DISK_4: starting piece 4 at 02/11/2014 11:51:12
channel ORA_DISK_5: starting compressed full datafile backup set
channel ORA_DISK_5: specifying datafile(s) in backup set
input datafile file number=00010 name=/oradata/BD01/users01.dbf
backing up blocks 524289 through 655360
channel ORA_DISK_5: starting piece 5 at 02/11/2014 11:51:12
channel ORA_DISK_6: starting compressed full datafile backup set
channel ORA_DISK_6: specifying datafile(s) in backup set
input datafile file number=00010 name=/oradata/BD01/users01.dbf
backing up blocks 655361 through 786432
channel ORA_DISK_6: starting piece 6 at 02/11/2014 11:51:12
channel ORA_DISK_7: starting compressed full datafile backup set
channel ORA_DISK_7: specifying datafile(s) in backup set
input datafile file number=00010 name=/oradata/BD01/users01.dbf
backing up blocks 786433 through 917504
channel ORA_DISK_7: starting piece 7 at 02/11/2014 11:51:12
channel ORA_DISK_2: finished piece 2 at 02/11/2014 11:51:12
piece handle=/FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv07h_.bkp
channel ORA_DISK_2: backup set complete, elapsed time: 00:00:00
channel ORA_DISK_2: starting compressed full datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00010 name=/oradata/BD01/users01.dbf
backing up blocks 917505 through 1006336
channel ORA_DISK_2: starting piece 8 at 02/11/2014 11:51:12
channel ORA_DISK_3: finished piece 3 at 02/11/2014 11:51:12
piece handle=/FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv08z_.bkp
channel ORA_DISK_3: backup set complete, elapsed time: 00:00:00
channel ORA_DISK_4: finished piece 4 at 02/11/2014 11:51:12
piece handle=/FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv0cl_.bkp
channel ORA_DISK_4: backup set complete, elapsed time: 00:00:00
channel ORA_DISK_5: finished piece 5 at 02/11/2014 11:51:12
piece handle=/FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv0cx_.bkp
channel ORA_DISK_5: backup set complete, elapsed time: 00:00:00
channel ORA_DISK_6: finished piece 6 at 02/11/2014 11:51:12
piece handle=/FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv0f8_.bkp
channel ORA_DISK_6: backup set complete, elapsed time: 00:00:00
channel ORA_DISK_1: finished piece 1 at 02/11/2014 11:51:15
piece handle=/FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmtzp4_.bkp
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:04
channel ORA_DISK_2: finished piece 8 at 02/11/2014 11:51:27
piece handle=/FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv0lj_.bkp
channel ORA_DISK_2: backup set complete, elapsed time: 00:00:15
channel ORA_DISK_7: finished piece 7 at 02/11/2014 11:52:34
piece handle=/FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv0h1_.bkp
channel ORA_DISK_7: backup set complete, elapsed time: 00:01:25
Finished backup at 02/11/2014 11:52:34
Após a finalização do backup acima, podemos perceber que foram alocados 7 canais (ORA_DISK_1-7), e que todos eles foram utilizados na realização do backup do datafile, ou seja, houve paralelismo na operação. Cada canal iniciou a operação de backup de uma determinada faixa de blocos do datafile. Foram gastos 00:01:25 (85 segundos) para realização do backup, ou seja, 25 segundos a menos comparado com a primeira simulação, o que representa uma melhora na performance de cerca de 30%. A figura abaixo demonstra a ação dos canais durante a operação de backup. Vale a pena salientar que é possível constatar que o canal ORA_DISK_2 iniciou a operação do backup piece 8 após finalizar o backup piece 2.
Para finalizar, segue abaixo a evidência dos backups pieces que foram gerados durante a realização do backup do datafile 10. O comando LIST mostra que foram gerados 8 backup pieces.
Para finalizar, segue abaixo a evidência dos backups pieces que foram gerados durante a realização do backup do datafile 10. O comando LIST mostra que foram gerados 8 backup pieces.
RMAN> list backup of datafile 10;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
5480 Full 544.80M DISK 00:01:25 02/11/2014 11:52:34
List of Datafiles in backup set 5480
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ------------- ------------------- -------------------------
10 Full 7840571897377 02/11/2014 11:51:11 /oradata/BD01/users01.dbf
Backup Set Copy #1 of backup set 5480
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ ------------------- ---------- ------------------
DISK 00:01:25 02/11/2014 11:52:34 YES TAG20141008T115111
List of Backup Pieces for backup set 5480 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ---------------------------------------------------------------------------
5499 1 AVAILABLE /FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmtzp4_.bkp
5494 2 AVAILABLE /FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv07h_.bkp
5495 3 AVAILABLE /FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv08z_.bkp
5496 4 AVAILABLE /FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv0cl_.bkp
5497 5 AVAILABLE /FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv0cx_.bkp
5498 6 AVAILABLE /FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv0f8_.bkp
5501 7 AVAILABLE /FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv0h1_.bkp
5500 8 AVAILABLE /FRA/BD01/backupset/2014_11_02/o1_mf_nnndf_TAG20141008T115111_b3bmv0lj_.bkp
8 comentários:
Muito legal Legatti, parabéns pelo post!
Uma dúvida a respeito dos backups efetuados via RMAN, você sabe se tenho como executar um backup full diário com retenção de 1 dia e executar outro incremental level 0 no domingo e level 1 nos demais dias da semana e reter este conjunto por 30 dias? Preciso de 2 catálogos diferentes pra isso?
Olá Franky,
Bom, não vejo muito sentido em se ter duas políticas de backup. De fato, não vejo como o RMAN trataria isso ;-) Lembre-se de que o catálogo de recuperação nada mais é do que apenas uma cópia das informações de metadados de backups que estão no control file do banco de dados. Neste caso, os 2 catálogos seriam idênticos pois estariam sendo espelhados pelo mesmo control file do banco de dados target.
Mesmo que você tenha uma política de retenção de 30 dias (RECOVERY WINDOW OF 30 DAYS), você poderá fazer backups incrementais LEVEL 0, LEVEL 1, como também backups FULL.
Se dentro dessa política você quiser manter apenas 1 backup FULL por dia, acredito que você terá que, de alguma forma, automatizar um script para deletar os backup sets do dia anterior que contém os backups FULL. Tente fazer uma pesquisa nesse sentido! ;-)
Abraços e até mais...
Legatti
Muito obrigado pela rápida resposta.
Pois é, sentido também acho que não faz, mas o cliente teima em querer assim. Vou ver se descubro uma maneira. Se der certo coloco aqui.
Abraços.
Olá Franky,
Lembre-se de que uma boa política de backup mescla backups físicos e backups lógicos. Nem todo ambiente permite isso, mas se o banco de dados não for tão grande, talvez seja possível fazer alguns dumps diários com o Datapump Export (expdp).
Abraços
Legatti
Bom dia Legatti, segundo o Metalink Doc ID 463875.1 posso usar a opção "BACKUP DATABASE KEEP UNTIL TIME 'sysdate +30';".
Já temos backup no ambiente, o lógico também. Mudamos um pouco a estratégia... vamos fazer o backup full diariamente e o backup full de sábado vamos manter durante 30 dias junto com os archive logs do período do backup.
Abraços.
Olá Franky,
Bom saber!!
Obrigado pelo Feedback ;-)
Abraços
Legatti
O Legatti, uma dúvida, se eu rodar esse script
allocate channel backup_disk1 device type disk format '/backup1/PRD500/BCK/%U' connect 'user/pass@prd5001';
allocate channel backup_disk2 device type disk format '/backup2/PRD500/BCK/%U' connect 'user/pass@prd5002';
allocate channel backup_disk3 device type disk format '/backup3/PRD500/BCK/%U' connect 'user/pass@prd5003';
allocate channel backup_disk4 device type disk format '/backup4/PRD500/BCK/%U' connect 'user/pass@prd5004';
allocate channel backup_disk5 device type disk format '/backup5/PRD500/BCK/%U' connect 'user/pass@prd5001';
allocate channel backup_disk6 device type disk format '/backup6/PRD500/BCK/%U' connect 'user/pass@prd5002';
allocate channel backup_disk7 device type disk format '/backup7/PRD500/BCK/%U' connect 'user/pass@prd5003';
allocate channel backup_disk8 device type disk format '/backup8/PRD500/BCK/%U' connect 'user/pass@prd5004';
backup as compressed backupset tag 'backup_inc0_PRD500_DISCO' incremental level 0 database section size 10000M filesperset 10;
.....
o backup devería finalizar mais rápido?
Olá,
O legal seria você dizer. Finalizou mais rápido ou não? Seu servidor suportou o paralelismo? O servidor aguentou a carga? As CPUs suportaram? O I/O foi um gargalo? Uma vez diminui o tempo de backup de 18 horas para 9 horas apenas alterando o nível de compressão, ou seja, não usei paralelismo.
Abraços,
Legatti
Postar um comentário