BLOG RODRIGO ALMEIDA

Olá,

Um dos grandes pontos fortes de trabalhar com o Recovery Manager (RMAN) é a possibilidade de alocar uma determinada quantidade de canais necessários no processo de Backup para melhorar o desempenho de I/O durante a tarefa, diminuindo o tempo do backup.

Os administradores de banco de dados (DBA) muitas vezes gostam de utilizar a alocação de canal manual para efetuar o backup e com isso, torna necessário mencionar a cada canal (channel) alocado o caminho que deverá ser gerado o backup set. Como o script abaixo:

run {
allocate channel t1 type disk format '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';
backup current controlfile tag 'BKP_CF';
release channel t1;
}

Perceba que durante a alocação do canal t1, é utilizada a cláusula FORMAT, que posteriormente menciona o caminho e o nome do backupset que será gerado pelo RMAN. Pois bem, se você costuma utilizar 3, 4, 5 ou mais canais, em um único caminho de backup e usando sempre a mesma máscara de nomenclatura de backup set, tornando os scripts frágeis.

Vamos analisar o exemplo e dividir as tarefas e customizar o RMAN, a partir da cláusula FORMAT. Veja:

1. Quantidade de canais = 3
2. Caminho de Backup = /u02/app/oracle/backup/rman
3. Nomenclatura de Backup set = bkp_%d_%t_%s.rman

Sobre a nomenclatura utilizada, segue a explicação:

• bkp_ = Nome inicial dos backupsets gerados, ou seja, definido por mim, é um valor fixo.
• %d = Variável do RMAN para identificar o nome do banco de dados.
• %t = Variável do RMAN para o Time Stamp do backup set.
• %s = Variável do RMAN para identificar a sequência do backup set.

Agora, vamos colocar na prática essa customização.

1°) Logar-se no banco de dados usando o RMAN

[oracle@ORA11G ~]$ rman target /
Recovery Manager: Release 11.1.0.6.0 – Production on Thu Aug 6 10:57:15
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: RADB (DBID=1241100324)

2°) Configura o caminho e nome do backup set no control file

As informações sobre a customização do RMAN será armazenada no control file. Para configurar emita o comando abaixo:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';

new RMAN configuration parameters:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';

new RMAN configuration parameters are successfully stored

3°) Definir a quantidade de alocação de canal automático

Para definir a quantidade de alocação de canais automáticos, quando executado qualquer script do RMAN para o banco de dados alvo, a estratégia é utilizar o PARALELISMO. E para configurar essa opção, basta executar o passo abaixo:

CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;

new RMAN configuration parameters:

CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;

new RMAN configuration parameters are successfully stored

4°) Verifique as configurações alteradas

show all;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name RADB are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
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 PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman’;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128′; # default
CONFIGURE COMPRESSION ALGORITHM ‘BZIP2′; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/u01/app/oracle/product/11.1.0/db_1/dbs/snapcf_RADB.f’; # default

5°) Testando o novo script

Agora, veja como ficou o script com as customizações que foram feitas. Em negrito está as novas configurações realizadas para o RMAN.

run {
shutdown immediate;
startup mount;
backup database include current controlfile tag 'BKP_FULL';
alter database open;
}

database closed
database dismounted
Oracle instance shut down
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 644468736 bytes
Fixed Size 1301840 bytes
Variable Size 293601968 bytes
Database Buffers 343932928 bytes
Redo Buffers 5632000 bytes
Starting backup at 06/08/2009 11:26:16
allocated channel: ORA_DISK_1allocated channel: ORA_DISK_2allocated channel: ORA_DISK_3/u02/app/oracle/backup/rman/bkp_RADB_694178799_15.rman tag=BKP_FULL comment=NONE
channel ORA_DISK_3: backup set complete, elapsed time: 00:03:16
channel ORA_DISK_3: starting full datafile backup set
channel ORA_DISK_3: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_3: starting piece 1 at 06/08/2009 11:30:43
channel ORA_DISK_3: finished piece 1 at 06/08/2009 11:31:23
piece handle=/u02/app/oracle/backup/rman/bkp_RADB_694179009_16.rman tag=BKP_FULL comment=NONE
channel ORA_DISK_3: backup set complete, elapsed time: 00:00:40
channel ORA_DISK_1: finished piece 1 at 06/08/2009 11:34:13
piece handle=/u02/app/oracle/backup/rman/bkp_RADB_694178778_13.rman tag=BKP_FULL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:07:48
channel ORA_DISK_2: finished piece 1 at 06/08/2009 11:35:04
piece handle=/u02/app/oracle/backup/rman/bkp_RADB_694178786_14.rman tag=BKP_FULL comment=NONE
channel ORA_DISK_2: backup set complete, elapsed time: 00:08:30
Finished backup at 06/08/2009 11:35:04
Starting Control File and SPFILE Autobackup at 06/08/2009 11:35:04
piece handle=/u01/app/oracle/flash_recovery_area/RADB/autobackup/2009_08_06/o1_mf_s_694178760_57otk638_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 06/08/2009 11:35:29
database opened
channel ORA_DISK_1: SID=154 device type=DISK

channel ORA_DISK_2: SID=153 device type=DISK

channel ORA_DISK_3: SID=151 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u02/app/oracle/oradata/RADB/system01.dbf
channel ORA_DISK_1: starting piece 1 at 06/08/2009 11:26:26
channel ORA_DISK_2: starting full datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00002 name=/u02/app/oracle/oradata/RADB/sysaux01.dbf
input datafile file number=00004 name=/u02/app/oracle/oradata/RADB/users01.dbf
channel ORA_DISK_2: starting piece 1 at 06/08/2009 11:26:34
channel ORA_DISK_3: starting full datafile backup set
channel ORA_DISK_3: specifying datafile(s) in backup set
input datafile file number=00005 name=/u02/app/oracle/oradata/RADB/example01.dbf
input datafile file number=00003 name=/u02/app/oracle/oradata/RADB/undotbs01.dbf
channel ORA_DISK_3: starting piece 1 at 06/08/2009 11:26:47
channel ORA_DISK_3: finished piece 1 at 06/08/2009 11:30:03
piece handle=

PRONTO! Deste modo conseguimos definir regras de backup mais customizadas para cada banco de dados. É válido lembrar que nos exemples realizei os testes de backup diretamente para disco, porém, é possível configurar os mesmos parâmetros para FITA, de acordo com a sua configuração MML no ambiente.

Abraços,

Olá,

Recentemente muitas empresas estão utilizando a solução de Nota Fiscal Eletrônica (NFE) da Mastersaf, um aplicativo desenvolvido em Java Server pages (JSP) sobre o webserver GlassFish da Sun/Oracle.

Na teoria um aplicativo web de pequeno porte para validação e envio de Notas Fiscais ao Sefaz, contudo, se o aplicativo tiver problemas de performance ou parar por erro humano ou hardware, trará grandes problemas ao negócios da empresa.

Nos manuais de instalação do aplicativo, não há muitas informações de como configurar ou administrar um banco de dados Oracle de acordo com as necessidades do aplicativo. Por essa razão, vou passar algumas dicas de como melhorar a performance do aplicativo quando está se trabalhando com Oracle.

1° Dica) Use o parâmetro DB_KEEP_CACHE_SIZE

Esse parâmetro é utilizado para mantér todos os blocos de dados de uma determinada tabela em memória, desde modo, evita-se realizar Physical Reads, leitura direta em disco, e começa a trabalhar mais com Logical reads, leitura em memória. O ganho de performance é bem considerado.

Para o NFE, o ideal é colocar todas as tabelas que inicia com NFE_, ARC_, CTRL_ e NFS_ em keep, pois são tabelas utilizadas com muita frequência pelo aplicativo. Abaixo segue um modo de como configurar.

1 – Habilitando o db_keep_cache_size

alter system set db_keep_cache_size = 120M scope=both;

Sistema alterado.

2 -  Colocando a tabela em keep

alter table NFE.<nome_da_tabela> storage (buffer_pool keep);

Tabela alterada.

Recomendação

O DBA deverá realizar os cálculos corretos para divisão do SGA (Database Buffers) para o parâmetro db_keep_cache_size, ou seja, recomendo utilizar em tabelas pequenas, que tenha no máximo 20MB, é interessante alocar seu contéudo completo em memória, porém, existe outro parâmetro db_recycle_cache_size que pode ser utilizado para tabelas maiores ou deixar no buffer_pool padrão, ou seja, alocar os blocos de dados no espaço destinado do db_cache_size.

2° Dica) Bulk Collect na Integração de dados

Para empresas que possuem soluções próprias de ERP ou sistemas de gerenciamento independentes, que trabalham na plataforma Oracle (Forms/Reports/Apex/PLSQL), é recomendado utilizar cursos em Bulk Collect para criar a integração com o sistema NFE da Mastersaf.

O Bulk Collect é o tipo de cursor que traz um excelente ganho de performance em relação aos outros (Implicítos/Explicítos) e aumenta a velocidade na troca de informações entre as bases.

Para maiores informações sobre como utilizar o Bulk Collect, meu amigo Leonardo Litz escreveu um artigo realizando a comparação entre os diferentes tipos de cursores, que pode ser visto no link abaixo.

Utilizando cursores no Oracle

3° Dica ) Bloco de dados em 8k

Já cheguei a ver algumas empresas que estão trabalhando com 16k para os blocos de dados do banco, em questões de performance, isso pode lhe trazer alguns Latchs desnecessários. Em testes realizados, trabalhar com o banco de dados com os parâmetros db_block_size = 8k e o db_file_multiblock_read_count = 16 mostrou muito mais performático em relação a criar o banco de dados em 16k ou até mesmo criar as tablespaces utilizando a blocagem de 16k. Mantenha-se no 8k.

Recomendação

Quando se deseja utilizar um específico bloco de dados no projeto de banco de dados, o DBA deverá analisar desde o stripe utilizado na criação da RAID, o tipo de formatação utilizado no disco e posteriormente o bloco de dados que irá utilizar, pois todos esses fatores influência em performance.

E é isso pessoal, conforme a experiência com os produtos Mastersaf e as soluções adotadas, vou postando mais informações para melhorar o dia-a-dia e compartilhar o conhecimento com todos. Sugestões e novas soluções também são muito bem-vindas.

Abraços,