Uma dúvida comum entre os DBAs que estão começando a trabalhar com os DBCS (DataBase Cloud Service) na OCI, é sobre como o backup automático configurado via console trata a limpeza dos archivelogs após o backup RMAN.

No caso dos DB Systems, a rotina de backup automático configurada na console OCI não executa a limpeza dos archives que já foram para backup de forma explícita, ao invés disso, ela confia no mecanismo de limpeza automática da Fast Recovery Area (FRA), deixando para o próprio banco de dados deletar os archivelogs obsoletos, conforme necessidade de espaço na FRA. Já no caso do Exadata Cloud Service (ExaCS), a rotina de backup chega a emitir um comando de deleção de archives, mas ainda é necessário uma atenção especial a configuração do ambiente que pode fazer com que esse comando não seja “respeitado”.

Este post apresenta o padrão de configuração nos DB System e ExaCS, assim como alguns detalhes que o DBA precisa observar quando estiver atuando em um desses ambientes. A configuração descrita a seguir já é definida automaticamente no provisionamento de um DBCS, mas ocasionalmente pode se perder durante o processo de migração para a Cloud ou até mesmo devido alguma alteração equivocada após o banco de dados ter sido criado.

Entendendo a FRA

A Fast Recovery Area (FRA) é uma área lógica dentro de um diretório físico que o Oracle Database utiliza para armazenar arquivos de recuperação, como Archive Log, Flashback Log, Backups e etc. Os arquivos criados dentro dessa área tem sua retenção gerenciada automaticamente pelo próprio banco de dados, quando o banco precisa de mais espaço dentro da FRA, os arquivos obsoletos são deletados automaticamente.

A localização da FRA é configurada através do parâmetro “db_recovery_file_dest” e o limite de utilização é controlado pelo parâmetro “db_recovery_file_dest_size”. O ponto de atenção nessa configuração é que o Oracle Database realiza a limpeza dos arquivos obsoletos na FRA com base no valor deste parâmetro, independente da área real disponível em disco.

Configurando a FRA

Para simplificar o post, o nome “RECO” será usado como nome do diskgroup em todos os exemplos, mas o nome real do diskgroup pode variar de um ambiente para o outro, sendo +RECO o padrão em DB System e +RECOC1 o padrão na maioria dos ExaCS.

Definindo um limite para FRA

Para evitar problemas de estouro de disco, o parâmetro db_recovery_file_dest_size precisa ser configurado sempre com um limite inferior ao tamanho total do diskgroup RECO, deixando uma margem de segurança para o Oracle conseguir excluir os archives em tempo hábil, sem comprometer a disponibilidade do banco de dados.

Antes de definir o tamanho da FRA, é importante verificar a capacidade do diskgroup RECO:

SET LINES 400
COL NAME HEADING "Disksgroup"   FORMAT A20
COL TYPE HEADING "Redundancy"   FORMAT A10
COL TOTAL_GB HEADING "Total GB" FORMAT 999,999,999,999  
COL FREE_GB  HEADING "Free GB"  FORMAT 999,999,999,999 
COL PERCFREE HEADING "Free %"   FORMAT 999.99 

SELECT NAME, TYPE, TOTAL_GB, FREE_GB, ROUND(FREE_GB/TOTAL_GB*100,2) AS PERCFREE
FROM (
	SELECT NAME, 
	       TYPE,
		   ( TOTAL_MB / DECODE(TYPE,'HIGH',3,'NORMAL',2,1) ) / 1024 AS TOTAL_GB, 
		   USABLE_FILE_MB/1024 AS FREE_GB
	FROM V$ASM_DISKGROUP
);

Exemplo:

Neste exemplo, o diskgroup tem uma capacidade de 4 TB e estamos definindo um limite de 2 TB para a FRA.

SQL> ALTER SYSTEM SET db_recovery_file_dest_size = 2048g;

Caso seja configurado um valor muito próximo do tamanho do diskgroup, o Oracle pode não ter tempo hábil para excluir os archives antes que acabe o espaço no ASM, enquanto um valor muito baixo pode fazer com que o limite seja alcançado antes que os archives tornem-se obsoletos (antes do próximo JOB de backup), note que os dois cenários podem causar o congelamento da instância com erro “ORA-00257: archiver error”.

Também é importante observar que caso seja um ambiente compartilhado por mais de um banco de dados, o que é bastante comum em ExaCS, precisa-se avaliar esse parâmetro de forma geral, onde a soma do valor do parâmetro db_recovery_file_dest_size em todos os bancos precisa ser menor que o tamanho total do diskgroup RECO.

Definindo a localização da FRA

O parâmetro db_recovery_file_dest deve ser configurado para usar o diskgroup RECO:

-- exemplo em VM DB System
SQL> ALTER SYSTEM SET db_recovery_file_dest = '+RECO';

--exemplo em ExaCS
SQL> ALTER SYSTEM SET db_recovery_file_dest = '+RECOC1';

Observação: Esse é o padrão de configuração nos DBCS OCI, mas não é algo exclusivo da Cloud, a FRA é uma feature do Oracle Database.

Configurando Destino dos Archives

Para que os archives sejam gerados como Oracle Managed Files (OMF), o parâmetro log_archive_dest_1 deve ser configurado da seguinte forma:

SQL> ALTER SYSTEM SET log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST';

Note que não há restrições quanto a utilização de outros atributos do parâmetro log_archive_dest_N, como a inclusão do atributo ALTERNATE, mas o atributo LOCATION precisa apontar para a FRA.

Também é importante observar que configurar esse parâmetro apontando para o caminho absoluto dentro do diskgroup RECO não significa que eles estão de fato usando o mecanismo de FRA, apenas compartilham o mesmo diretório físico.

Exemplos de uma configurações erradas para o padrão de um DBCS:

log_archive_dest_1='LOCATION=+RECO'
log_archive_dest_1='LOCATION=+RECO/CDB1_gru14r/ARCHIVELOG'

Verificando a configuração do destino dos archives, deve aparecer como “USE_DB_RECOVERY_FILE_DEST”:

SQL> archive log list;

Para finalizar, a política de deleção dos archive logs precisa estar configurada no RMAN, caso contrário, em um DB System, eles podem nunca serem deletados do disco, mesmo que estejam “obsoletos”, porque o banco não sabe como determinar o que é “obsoleto” neste cenário.

O exemplo abaixo é o padrão OCI em DB Systems e ExaCS :

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO SBT_TAPE;

Com essa política, o Oracle entende que os archives que já tem pelo menos 1 backup do tipo SBT_TAPE (backups para ObjectStorage usam canais do tipo SBT) podem ser considerados obsoletos e são candidados para deleção automática quando há necessidade de liberação de espaço na FRA, ou quando emitimos o comando “DELETE ARCHIVELOG” no RMAN sem nenhum filtro.

No caso do ExaCS, a rotina de backup chega a emitir um comando de deleção explicitamente como este:

DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 1 TIMES TO SBT_TAPE COMPLETED BEFORE 'SYSDATE - 1';

Mas caso tenha uma política de deleção diferente na configuração do RMAN, a regra acima pode não ser totalmente satisfeita. Por exemplo, se no RMAN estiver configurado para só deletar os archives que já foram aplicados no Standby, alguns archives podem não ser deletados na execução do comando acima, gerando uma mensagem similar a esta no log do RMAN:

RMAN-08120: warning: archived log not deleted, not yet applied by standby

Isso não chega a ser um problema, a menos que política configurada não faça sentido para a realidade do banco de dados. Por exemplo, caso o banco não faça mais parte de uma configuração Data Guard, essa política de deleção incorreta pode fazer com que os archives nunca sejam deletados pela rotina de backup, pois os archives nunca serão aplicados em nenhum Standby.

EXTRA: Estimando O Tamanho Ideal Para a FRA

Caso queira garantir que o ambiente suporte alguns dias sem que os archives sejam deletados do disco, uma boa estratégia é analisar o histórico de geração de archives do banco de dados.

A query abaixo retorna o volume diário em GB nos últimos 15 dias:

SET LINES 400
SET PAGES 100
COL DATA    FORMAT A15
COL GB_SIZE FORMAT 999,999,999,999
COL QTDE    FORMAT 999,999,999,999
COL DUMMY   FORMAT a10 HEADING ""
COMPUTE AVG OF GB_SIZE ON DUMMY
BREAK ON dummy 

SELECT '' as dummy,
       TRUNC(COMPLETION_TIME,'DD') DATA, 
       sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024 GB_SIZE,
       COUNT(*) QTDE
  FROM V$ARCHIVED_LOG L
 WHERE STANDBY_DEST = 'NO'
   AND COMPLETION_TIME >= trunc(sysdate) - 15
GROUP BY TRUNC(COMPLETION_TIME,'DD')
ORDER BY DATA;

Neste exemplo, o banco de dados apresentou uma geração média de 2,1 TB de archives por dia:

Opcionalmente, podemos avaliar o ranking ordenado pelos dias que mais geraram archive:

SELECT TRUNC(COMPLETION_TIME,'DD') DATA, 
       sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024 GB_SIZE,
       COUNT(*) QTDE
  FROM V$ARCHIVED_LOG L
 WHERE STANDBY_DEST = 'NO'
 AND COMPLETION_TIME >= trunc(sysdate) - 15
GROUP BY TRUNC(COMPLETION_TIME,'DD')
ORDER BY GB_SIZE DESC;

A query abaixo retorna o resumo com o valor médio e máximo observado no período de 15 dias:

COL MEDIA  FORMAT 999,999,999,999
COL MAXIMO FORMAT 999,999,999,999
COL TOTAL  FORMAT 999,999,999,999
SELECT AVG(GB_SIZE) AS MEDIA, 
       MAX(GB_SIZE) AS MAXIMO, 
	   SUM(GB_SIZE) AS TOTAL,
	   COUNT(*)     AS QT_DIAS,
	   MIN(DATA)    AS INICIO
FROM (
	SELECT 
		   TRUNC(COMPLETION_TIME,'DD') DATA, 
		   sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024 GB_SIZE
	  FROM V$ARCHIVED_LOG L
	 WHERE STANDBY_DEST = 'NO'
	 AND COMPLETION_TIME >= trunc(sysdate) - 15
	GROUP BY TRUNC(COMPLETION_TIME,'DD')
	ORDER BY DATA
);

Então com os dados acima, se o objetivo fosse suportar até 4 dias de archives acumulados no disco, considerando o pico que foi 3 TB em um único dia, a FRA precisaria ter pelo menos 12 TB. Na prática, essa é uma das maneiras de controlar uma retenção mínima dos archives em um DB System, já no caso do ExaCS, a retenção mínima precisa ser definida setando o parâmetro “bkup_archlog_fra_retention” via bkup_api.

Conclusão

Esse post apresentou o padrão utilizado para gestão de archivelog dos bancos de dados em DB Systems e Exadata Cloud Service na OCI, além de demonstrar como verificar e configurar adequadamente a FRA para evitar alguns dos erros mais comuns que resultam em problemas de estouro da área de archives, causando problemas de indisponibilidade nos respectivos banco de dados.

É importante salientar que apesar deste ser o padrão dos backups automáticos na OCI, o DBA ainda continua tendo a possibilidade de controlar a deleção dos archives através de scripts shell na crontab ou qualquer outro método similar, caso seja necessário por qualquer razão específica do ambiente.