Para melhor visualização, recomendo resolução de no mínimo 1280 x 800 e navegador Mozilla Firefox


domingo, 2 de novembro de 2014

Abordando o RMAN - MULTISECTION BACKUP disponível a partir do Oracle 11g

Por Eduardo Legatti

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.
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:

Unknown disse...

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?

Eduardo Legatti disse...

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

Unknown disse...

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.

Eduardo Legatti disse...

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

Unknown disse...

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.

Eduardo Legatti disse...

Olá Franky,

Bom saber!!

Obrigado pelo Feedback ;-)

Abraços

Legatti

jfk21 disse...

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?

Eduardo Legatti disse...

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

Postagens populares