Como otimizar backups de BIGFILES usando RMAN MULTISECTION - 11g
OBS.: Reformulei este antigo post que falava sobre BIGFILE. Anteriormente eu passei um script que quebrava o arquivo em partes iguais de acordo com o valor do paralelismo, mas se o arquivo for muito grande vai demorar da mesma forma. Não é obrigatório ser igual ao número de canais. É possível quebrar o arquivo em tamanhos menores e quando o canal terminar uma parte iniciará a outra. Desta forma é mais recomendável.
O Bigfile pode ajudar em vários fatores, mas é temos que saber utilizá-lo. O tempo necessário para backup/restore aumenta consideravelmente quando trabalhamos com ele sem MULTISECTION. Prefira SMALLFILE quando possível. Melhor ainda: faça um balanço entre usar BIGFILE e SMALLFILE, analisando a questão da quantidade de arquivos, tempos de backup/restore, limitações, etc.
Foi incluído um recurso interessante no RMAN (Recovery Manager) do Oracle 11g que são os "backups multissessão" . Resumindo, para as tablespaces BIGFILE (tablespaces que possuem somente um arquivo de dados com tamanho limite bem maior, 32TB para blocos de 8KB por exemplo, do que o tradicional SMALLFILE de 32GB de limite) o backup pode ser realizado "quebrando" o BIGFILE em partes otimizando o tempo de backup.
Fiz um teste de tempo no ambiente em que trabalho atualmente e consegui diminuir bastante o tempo, mesmo sendo um backup em disco. Sempre é necessário verificar a infraestrutura para determinar o real custo/benefício de se utilizar paralelismo (consequência de utilizar multissessão). Em ambientes onde são utilizados backups em fita por exemplo, é necessário verificar quantos drives serão utilizados durante o backup sem comprometer o resto do ambiente e em ambientes onde os backups são realizados em disco é bom verificar se o paralelismo irá sobrecarregar o I/O podendo levar até mais tempo do que anteriormente. OBS.: Paralelismo de backups só na ENTERPRISE EDITION.
No teste, uma base de dados "X" possuía 190GB (180GB só uma tablespace BIGFILE) e o backup levava mais tempo que outra base de dados com o dobro do espaço alocado (o tamanho final de saída em disco do backup era praticamente o mesmo). Tudo isso por conta do BIGFILE.
O backup deve usar a cláusula SECTION SIZE (tamanho) para quebrar os BIGFILES do banco de dados. Veja os exemplos:
RMAN> backup section size 5G tablespace BIG_DATA; (para apenas o tablespace)
ou
RMAN> backup section size 5G database; (o RMAN automaticamente fará a quebra para todos os tablespaces bigfiles do banco de dados durante o backup total.)
Somente adicionando a cláusula, o backup que levava 8h30min, caiu pra 2h30min.
O Bigfile pode ajudar em vários fatores, mas é temos que saber utilizá-lo. O tempo necessário para backup/restore aumenta consideravelmente quando trabalhamos com ele sem MULTISECTION. Prefira SMALLFILE quando possível. Melhor ainda: faça um balanço entre usar BIGFILE e SMALLFILE, analisando a questão da quantidade de arquivos, tempos de backup/restore, limitações, etc.
Foi incluído um recurso interessante no RMAN (Recovery Manager) do Oracle 11g que são os "backups multissessão" . Resumindo, para as tablespaces BIGFILE (tablespaces que possuem somente um arquivo de dados com tamanho limite bem maior, 32TB para blocos de 8KB por exemplo, do que o tradicional SMALLFILE de 32GB de limite) o backup pode ser realizado "quebrando" o BIGFILE em partes otimizando o tempo de backup.
Fiz um teste de tempo no ambiente em que trabalho atualmente e consegui diminuir bastante o tempo, mesmo sendo um backup em disco. Sempre é necessário verificar a infraestrutura para determinar o real custo/benefício de se utilizar paralelismo (consequência de utilizar multissessão). Em ambientes onde são utilizados backups em fita por exemplo, é necessário verificar quantos drives serão utilizados durante o backup sem comprometer o resto do ambiente e em ambientes onde os backups são realizados em disco é bom verificar se o paralelismo irá sobrecarregar o I/O podendo levar até mais tempo do que anteriormente. OBS.: Paralelismo de backups só na ENTERPRISE EDITION.
No teste, uma base de dados "X" possuía 190GB (180GB só uma tablespace BIGFILE) e o backup levava mais tempo que outra base de dados com o dobro do espaço alocado (o tamanho final de saída em disco do backup era praticamente o mesmo). Tudo isso por conta do BIGFILE.
O backup deve usar a cláusula SECTION SIZE (tamanho) para quebrar os BIGFILES do banco de dados. Veja os exemplos:
RMAN> backup section size 5G tablespace BIG_DATA; (para apenas o tablespace)
ou
RMAN> backup section size 5G database; (o RMAN automaticamente fará a quebra para todos os tablespaces bigfiles do banco de dados durante o backup total.)
Somente adicionando a cláusula, o backup que levava 8h30min, caiu pra 2h30min.
Comentários
Postar um comentário