Pular para o conteúdo

Gerenciando a Alocação de Espaço Resumível no Oracle Database: Uma Corrida de F1

Gerenciando a Alocação de Espaço Resumível no Oracle Database: Uma Corrida de F1

No gerenciamento de banco de dados Oracle, garantir que as operações de longa duração sejam concluídas com sucesso é um desafio constante. Uma interrupção inesperada, como falta de espaço em disco, pode causar falhas em operações críticas. Para mitigar esses problemas, o Oracle Database introduziu o recurso de Alocação de Espaço Resumível. Este recurso permite que certas operações, como inserções em massa ou operações de carga de dados, sejam suspensas em vez de falharem quando enfrentam problemas de espaço insuficiente, proporcionando uma janela para resolver a questão e retomar a operação.

Alocação de Espaço Resumível

Imagine que você está assistindo a uma corrida de Fórmula 1. Durante a corrida, um carro pode precisar de um pit stop para reabastecer, trocar pneus ou resolver pequenos problemas mecânicos. O carro não abandona a corrida; ele faz uma pausa estratégica para garantir que pode continuar e terminar a prova. Da mesma forma, a Alocação de Espaço Resumível é um mecanismo que suspende operações de banco de dados que requerem mais espaço do que está disponível. Durante a suspensão, a operação não falha, mas fica em um estado aguardando a resolução do problema de espaço. Assim que o espaço necessário é liberado ou alocado, a operação é retomada automaticamente. Este recurso é especialmente útil em ambientes onde a continuidade operacional é crítica.

A Dinâmica

Quando uma operação que consome espaço é configurada como resumível, o Oracle Database monitora a operação. Se, durante essa operação, ocorrer um erro de alocação de espaço, como espaço insuficiente em uma tablespace, a operação é suspensa por um período de tempo configurado (timeout). Durante essa suspensão, o administrador do banco de dados pode corrigir o problema de espaço, assim como a equipe técnica de uma equipe de F1 resolve os problemas do carro durante o pit stop.

Configurando a Alocação de Espaço Resumível

Para ativar a Alocação de Espaço Resumível, você pode usar a cláusula `RESUMABLE` nas instruções SQL. Aqui estão os passos básicos para configurar e gerenciar esse recurso:

SQL
ALTER SESSION ENABLE RESUMABLE TIMEOUT 3600;

Este comando habilita a Alocação de Espaço Resumível para a sessão atual, com um tempo limite (timeout) de 3600 segundos (1 hora), similar ao tempo que um carro de F1 pode gastar no pit stop antes de retornar à corrida.

Neste exemplo, a dica `RESUMABLE` é usada para garantir que a operação de inserção possa ser suspensa e retomada em caso de problemas de espaço, assim como um carro de F1 pode fazer uma pausa para reparos e depois retornar à corrida.

Vamos a um exemplo prático: Lidando com a Suspensão

Conectado ao PDB, crie uma tablespace com 256M.

image 24
create tablespace tbs_pitstop datafile size 256k
SQL
CREATE TABLESPACE TBS_PITSTOP DATAFILE SIZE 256K;

Até aqui sem muita novidade, vamos criar um usuário:

image 25
CREATE USER USR_RACER

Com o objetivo de criar um loop para inserir dados na tabela até atingir o limite de espaço na tablespace.

Abra o arquivo de script SQL usando o editor vi:

Bash
!vi /home/oracle/loop.sql

Dentro do documento, execute o seguinte comando:

PLSQL
declare
  x number;
begin
  x := 0;
  for x in 1 .. 5000
  loop
    insert into USR_RACER.TB_RACETRACK
    values
      (x, sysdate);
    commit;
  end loop;
end;
/

image 26
loop

Ainda como usuário SYS, me certifico de que o parâmetro ‘RESUMABLE’ está desabilitado.

image 27
show parameter resumable
SQL
show parameter resumable

Tenho a certeza de que está desabilitado quando o campo VALUE está em zero, o que representa que o ‘RESUMABLE’ está desabilitado. O passo seguinte é se conectar com o usuário que fará as inserções na tabela e o monitoramento no ‘RESUMABLE’.

image 28
SQL
conn USR_RACER/senha@orclpdb

Com o usuário ‘USR_RACER’ e no PDB, vamos fazer a inserção de dados na tabela TB_RACETRACK.

image 29
inserção de dados

Percebendo que consigo fazer uma carga de 5000 linhas na tabela, porém na segunda tentativa não consigo devido ao espaço da tablespace não suportar mais dados. Lembrando que, neste ponto, o meu ‘RESUMABLE’ está desabilitado. Neste caso, deu erro e já abortou a inserção de dados. Erro fatal… Daqui para frente, vamos habilitar o ‘RESUMABLE’ em uma nova sessão, com o usuário SYS, e ver como será o comportamento com ele habilitado.

image 30
usuário SYS RESUMABLE desabilitado

A imagem acima confirma tudo isso, estando o usuário SYS no PDB com o ‘RESUMABLE’ desabilitado. Vamos habilitando o ‘RESUMABLE’.

image 31
alter system set resumable_timeout=3600 scope=both
SQL
ALTER SYSTEM SET RESUMABLE_TIMEOUT=3600 SCOPE=BOTH;

Com um comando simples e rápido, estamos habilitando o nosso ‘RESUMABLE’.
Voltando para a sessão do usuário USR_RACER, vamos verificando o status do ‘RESUMABLE’.

image 32
parameter resumable USER USR_RACER

Percebendo que a ativação do parâmetro ‘RESUMABLE’ foi imediata e não houve necessidade de reiniciar o banco por ser um parâmetro dinâmico. Com o VALUE de 3600, isso significa que, ao surgir um problema, temos 3600 segundos ou 1 hora para solucioná-lo. Para o usuário, o banco fica em um estado de pausa estratégica, semelhante a um piloto que está processando as informações da pista durante uma corrida. Isso permite que o DBA tenha esse tempo para resolver o problema em questão.

Vamos repetir o processo de inserção e observar como ele se comporta desta vez.

image 33
@/home/oracle/loop  ERRO
Bash
@/home/oracle/loop  ERRO

Perceba que para o usuário, o banco está acelerando como um carro na reta final de uma corrida. Conectando-se à sessão do SYS, vamos verificar o Alert Log para acompanhar o desempenho do nosso “piloto”.

image 34
AlertLog

Percebam na imagem acima que o pit wall do Alert Log registrou a habilitação do ‘RESUMABLE’ e indica que o piloto USR_RACER está tentando acelerar os dados na tabela TB_RACETRACK, mas está enfrentando falta de espaço na pista. Com essas informações em mãos, cabe ao DBA expandir o tamanho da tablespace para que o piloto possa continuar na corrida sem contratempos. Vamos ajustar o setup e voltar à pista!

image 35

Expansão da Tablespace

Agora, como usuário SYS, estou executando o comando de expansão da tablespace. Reparem que na aba do usuário USR_RACER está em azul. Esse recurso gráfico do APP MOBA funciona como o pit stop na Fórmula 1, indicando que algo está sendo processado naquela aba. Vamos ver o que é.

image 36

Comando concluído

E percebemos que o terminal foi liberado para novas execuções por parte do usuário USR_RACER, tanto é que ao executar o comando:

Bash
SELECT COUNT(*) FROM USR_RACER.TB_RACETRACK;

Lembram-se que tínhamos conseguido inserir apenas 5000 linhas, e agora temos 13552. Vamos detalhar o que aconteceu.

O ‘RESUMABLE’ estava desabilitado; o usuário inseriu os dados até atingir o limite de espaço da tablespace. Após atingir o teto de dados, o usuário recebeu um erro e sua transação falhou, semelhante a um carro de Fórmula 1 foi dada a bandeira vermelha e a corrida foi abortada neste ponto. E este ponto com este erro o usuário não tinha certeza de quantas inserções haviam sido processadas.

Posteriormente, o ‘RESUMABLE’ foi habilitado. Quando o usuário tentou fazer a inserção novamente, o banco não gerou um erro, simplesmente parou de processar, como um carro que  desacelera antes de entrar nos boxes, deixando o usuário sem entender o que estava ocorrendo. Por outro lado, o DBA tinha acesso às informações extraídas do AlertLog e pôde realizar o reparo necessário, semelhante aos engenheiros de uma equipe de Fórmula 1 que analisam os dados da telemetria para resolver problemas durante a corrida.

Após realizar o reparo, que consistiu na expansão da tablespace, a sessão do usuário foi liberada e o banco foi destravado, permitindo que a operação continuasse como um carro saindo rapidamente dos boxes após uma troca de pneus.

Conclusão

Assim como na Fórmula 1, onde pit stops são essenciais para garantir que os carros completem a corrida, a Alocação de Espaço Resumível no Oracle Database é uma ferramenta poderosa para garantir a continuidade das operações críticas do banco de dados. Ao permitir que operações sejam suspensas por um tempo pré determinado, ao invés de falharem subtamente, ela proporciona uma oportunidade para os administradores resolverem problemas sem interromper o fluxo de trabalho. Configurar e gerenciar corretamente esse recurso pode melhorar significativamente a resiliência e a confiabilidade do seu ambiente de banco de dados.

Tercio Haring

Tercio Haring

Tércio Haring é pai do Max e um entusiasta incansável de TI. Sua paixão pelo próximo o levou a ser socorrista, sempre pronto para ajudar. No universo da tecnologia, seu objetivo vai além de simplesmente compartilhar conhecimento; ele busca manter sua mente conectada ao futuro e abraçar os desafios como oportunidades disfarçadas. Escreve com o objetivo de tornar o complexo mundo dos bancos de dados mais acessível e compreensível, sempre com um toque de humor para tornar a jornada mais leve e divertida. Se você procura insights valiosos, explicações claras e, claro, algumas boas risadas, Tércio é a pessoa certa para te guiar. Junte-se a ele para explorar, aprender e crescer nesse vasto e fascinante universo Oracle!

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

plugins premium WordPress