Transações

O conteúdo do script nesta página é para navegação apenas e não altera o conteúdo de nenhuma forma.

Este capítulo define uma transação e descreve como o banco de dados processa as transações.

Introdução a Transações

transaction é uma unidade de trabalho lógica e atômica que contém uma ou mais instruções SQL.

Uma transação agrupa instruções SQL de modo que sejam todas submetidas a commit, o que significa que são aplicadas ao banco de dados ou a todo rollback, o que significa que são desfeitas do banco de dados. O Oracle AI Database atribui a cada transação um identificador exclusivo chamado ID da transação.

Todas as transações Oracle obedecem às propriedades básicas de uma transação de banco de dados, conhecidas como propriedades ACID. ACID é um acrônimo para:

O uso de transações é uma das maneiras mais importantes que um sistema de gerenciamento de banco de dados difere de um sistema de arquivos.

Transação de Amostra: Débito e Crédito da Conta

Para ilustrar o conceito de uma transação, considere um banco de dados bancário.

Quando um cliente transfere dinheiro de uma conta poupança para uma conta corrente, a transação deve consistir em três operações separadas:

O Oracle AI Database deve permitir duas situações. Se todas as três instruções SQL mantiverem as contas no saldo adequado, os efeitos da transação poderão ser aplicados ao banco de dados. No entanto, se um problema como fundos insuficientes, número de conta inválido ou falha de hardware impedir que um ou dois demonstrativos na transação sejam concluídos, o banco de dados deverá fazer rollback de toda a transação para que o saldo de todas as contas esteja correto.

O gráfico a seguir ilustra uma transação bancária. A primeira fatura subtrai US$ 500 da conta poupança 3209. A segunda declaração adiciona US $ 500 à conta corrente 3208. A terceira instrução insere um registro da transferência na tabela de lançamentos. O demonstrativo final confirma a transação.

Figura 1: Uma transação bancária

Descrição da ilustração cncpt025.gif

Estrutura de uma Transação

Uma transação de banco de dado consiste em uma ou mais instruções.

Especificamente, uma transação consiste em um dos seguintes:

Uma transação tem um início e um fim.

Consulte Também:

Início de uma Transação

Uma transação começa quando a primeira instrução SQL executável é encontrada.

Uma instrução SQL executável é uma instrução SQL que gera chamadas para uma instância do banco de dados, incluindo instruções DML e DDL e a instrução SET TRANSACTION.

Quando uma transação começa, o Oracle AI Database atribui a transação a um segmento de desfazer dados disponível para registrar as entradas de undo da nova transação. Um ID de transação não é alocado até que um segmento de undo e um slot da tabela de transações sejam alocados, o que ocorre durante a primeira instrução DML. Um ID de transação é exclusivo de uma transação e representa o número de segmento de undo, slot e número de sequência.

O exemplo a seguir executa uma instrução UPDATE para iniciar uma transação e consulta V$TRANSACTION para obter detalhes sobre a transação:

SQL> UPDATE hr.employees SET salary=salary;

107 rows updated.

SQL> SELECT XID AS "txn id", XIDUSN AS "undo seg", XIDSLOT AS "slot",
  2  XIDSQN AS "seq", STATUS AS "txn status"
  3  FROM V$TRANSACTION;

txn id             undo seg       slot        seq txn status
---------------- ---------- ---------- ---------- ----------------
0600060037000000          6          6         55 ACTIVE

Consulte Também: "Desfazer Segmentos"

Fim de uma Transação

Uma transação pode terminar em diferentes circunstâncias.

Uma transação termina quando ocorre qualquer uma das seguintes ações:

Depois que uma transação termina, a próxima instrução SQL executável inicia automaticamente a seguinte transação. O exemplo a seguir executa uma UPDATE para iniciar uma transação, encerra a transação com uma instrução ROLLBACK e, em seguida, executa uma UPDATE para iniciar uma nova transação (observe que os IDs da transação são diferentes):

SQL> UPDATE hr.employees SET salary=salary;
107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0800090033000000 ACTIVE

SQL> ROLLBACK;

Rollback complete.

SQL> SELECT XID FROM V$TRANSACTION;

no rows selected

SQL> UPDATE hr.employees SET last_name=last_name;

107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0900050033000000 ACTIVE

Consulte Também:

Atomicidade no Nível do Demonstrativo

O Oracle AI Database suporta atomicidade em nível de instrução, o que significa que uma instrução SQL é uma unidade atômica de trabalho e é bem-sucedida ou falha completamente.

Uma instrução bem-sucedida é diferente de uma transação confirmada. Uma única instrução SQL será executada com êxito se o banco de dados for analisado e executado sem erro como uma unidade atômica, como quando todas as linhas forem alteradas em uma atualização de várias linhas.

Se uma instrução SQL causar um erro durante a execução, ela não será bem-sucedida e, portanto, todos os efeitos da instrução serão revertidos. Esta operação é um backback no nível da instrução. Esta operação tem as seguintes características:

Um exemplo de erro que causa um rollback no nível da instrução é uma tentativa de inserir uma chave primária duplicada. As instruções SQL únicas envolvidas em um desbloqueio, que é a concorrência pelos mesmos dados, também podem causar um rollback no nível da instrução. No entanto, os erros descobertos durante a análise de instruções SQL, como um erro de sintaxe, ainda não foram executados e, portanto, não causam um rollback no nível da instrução.

Consulte Também:

Números de Alteração do Sistema (SCNs)

Um SCN (system change number, número de alteração do sistema) é um timestamp lógico e interno usado pelo Oracle AI Database.

Os SCNs ordenam os eventos que ocorrem no banco de dados, o que é necessário para satisfazer as propriedades ACID de uma transação. O Oracle AI Database usa SCNs para marcar o SCN antes do qual todas as alterações são conhecidas como em disco, de modo que a recuperação evite a aplicação de redo desnecessário. O banco de dados também usa SCNs para marcar o ponto no qual não existe redo para um conjunto de dados para que a recuperação possa ser interrompida.

SCNs ocorrem em uma sequência monotonicamente crescente. O Oracle AI Database pode usar um SCN como um relógio porque um SCN observado indica um ponto lógico no tempo, e observações repetidas retornam valores iguais ou maiores. Se um evento tiver um SCN inferior a outro evento, ele ocorrerá em um momento anterior no banco de dados. Vários eventos podem compartilhar o mesmo SCN, o que significa que eles ocorreram ao mesmo tempo no banco de dados.

Cada transação tem um SCN. Por exemplo, se uma transação atualizar uma linha, o banco de dados registrará o SCN no qual essa atualização ocorreu. Outras modificações nesta transação têm o mesmo SCN. Quando uma transação é confirmada, o banco de dados registra um SCN para essa confirmação.

O Oracle AI Database incrementa SCNs na Área global do sistema (SGA). Quando uma transação modifica dados, o banco de dados grava um novo SCN no segmento de dados de undo atribuído à transação. O processo do gravador de logs grava o registro de commit da transação imediatamente no refazer log on-line. O registro de commit tem o SCN exclusivo da transação. O Oracle AI Database também usa SCNs como parte de seus mecanismos de recuperação de instância e recuperação de mídia.

Consulte Também: "Visão Geral da Recuperação de Instância"

Visão Geral do Transaction Control

Controle de transação é o gerenciamento de alterações feitas por instruções DML e o agrupamento de instruções DML em transações.

Em geral, os designers de aplicativos estão preocupados com o controle de transações para que o trabalho seja realizado em unidades lógicas e os dados sejam mantidos consistentes.

O controle de transação envolve o uso das seguintes instruções, conforme descrito em "Instruções de Controle de Transação":

A sessão na Tabela 13-1 ilustra os conceitos básicos de controle de transação.

Tabela 1 Controle de Transação

T Sessão Explicação
t0 
COMMIT;
 Esta instrução encerra qualquer transação existente na sessão.
t1 
SET TRANSACTION NAME 'sal_update';
 Esta instrução inicia uma transação e a nomeia como sal_update.
t2 
UPDATE employees
 SET salary = 7000
  WHERE last_name = 'Banda';
 Esta instrução atualiza o salário de Banda para 7000.
t3 
SAVEPOINT after_banda_sal;
 Essa instrução cria um ponto de salvamento chamado after_banda_sal, permitindo que as alterações nessa transação sejam submetidas a rollback para esse ponto.
t4 
UPDATE employees
 SET salary = 12000
  WHERE last_name = 'Greene';
 Esta instrução atualiza o salário de Greene para 12000.
t5 
SAVEPOINT after_greene_sal;
 Essa instrução cria um ponto de salvamento chamado after_greene_sal, permitindo que as alterações nessa transação sejam submetidas a rollback para esse ponto.
t6 
ROLLBACK TO SAVEPOINT
 after_banda_sal;
 Esta instrução faz rollback da transação para t3, desfazendo a atualização para o salário de Greene em t4. A transação sal_update não foi encerrada.
t7 
UPDATE employees
 SET salary = 11000
  WHERE last_name = 'Greene';
 Esta instrução atualiza o salário de Greene para 11000 na transação sal_update.
t8 
ROLLBACK;
 Esta instrução faz rollback de todas as alterações na transação sal_update, encerrando a transação.
t9 
SET TRANSACTION NAME 'sal_update2';
 Esta instrução inicia uma nova transação na sessão e a nomeia como sal_update2.
t10 
UPDATE employees
 SET salary = 7050
  WHERE last_name = 'Banda';
 Esta instrução atualiza o salário de Banda para 7050.
t11 
UPDATE employees
 SET salary = 10950
  WHERE last_name = 'Greene';
 Essa instrução atualiza o salário de Greene para 10950.
t12 
COMMIT;
 Esta instrução faz commit de todas as alterações feitas na transação sal_update2, encerrando a transação. A confirmação garante que as alterações sejam salvas nos arquivos de redo log on-line.

Nomes da Transação

Um nome de transação é uma tag opcional especificada pelo usuário que serve como um lembrete do trabalho que a transação está realizando. Você nomeia uma transação com a instrução SET TRANSACTION ... NAME, que, se usada, deve ser a primeira instrução da transação.

Na Tabela 13-1, a primeira transação foi denominada sal_update e a segunda, sal_update2.

Os nomes de transação oferecem as seguintes vantagens:

Consulte Também:

Transações Ativas

Uma transação ativa é aquela que foi iniciada, mas ainda não foi confirmada ou submetida a rollback.

Na Tabela 13-1, a primeira instrução a modificar dados na transação sal_update é a atualização do salário de Banda. A partir da execução bem-sucedida dessa atualização até que a instrução ROLLBACK termine a transação, a transação sal_update estará ativa.

As alterações de dados feitas por uma transação serão temporárias até que a transação seja confirmada ou submetida a rollback. Antes do fim da transação, o estado dos dados é conforme mostrado na tabela a seguir.

Tabela 2 Estado dos Dados Antes do Fim da Transação

Estado Descrição Para Saber Mais
O Oracle AI Database gerou informações de undo na SGA. Os dados de undo contêm os valores de dados antigos alterados pelas instruções SQL da transação. "Ler Consistência no Nível de Isolamento de Confirmação de Leitura"
O Oracle AI Database gerou redo no buffer de redo log on-line da SGA. O registro de redo log contém a alteração no bloco de dados e a alteração no bloco de undo. "Buffer de Refazer Log"
Foram feitas alterações nos buffers de banco de dados da SGA. As alterações de dados de uma transação submetida a commit, armazenadas nos buffers de banco de dados da SGA, não são necessariamente gravadas imediatamente nos arquivos de dados pelo gravador de banco de dados (DBW). A gravação do disco pode ocorrer antes ou depois do commit. "Cache de Buffer do Banco de Dados"
As linhas afetadas pela alteração de dados são bloqueadas. Outros usuários não podem alterar os dados nas linhas afetadas nem podem ver as alterações não confirmadas com commit. "Resumo do Comportamento de Bloqueio"

Pontos de Salvamento

Um ponto de salvamento é um marcador intermediário declarado pelo usuário no contexto de uma transação.

Internamente, o marcador do ponto de salvamento é resolvido para um SCN. Os pontos de salvamento dividem uma transação longa em partes menores.

Se você usar pontos de salvamento em uma transação longa, terá a opção mais tarde de reverter o trabalho executado antes do ponto atual da transação, mas depois de um ponto de salvamento declarado dentro da transação. Assim, se você cometer um erro, não precisará reenviar todas as instruções. A Tabela 13-1 cria o ponto de salvamento after_banda_sal para que a atualização do salário de Greene possa ser submetida a rollback para esse ponto de salvamento.

Fazer Rollback para Ponto de Salvamento

Um rollback para um ponto de salvamento em uma transação não confirmada significa desfazer quaisquer alterações feitas após o ponto de salvamento especificado, mas não significa um rollback da própria transação.

Quando uma transação é submetida a rollback para um ponto de salvamento, como quando o ROLLBACK TO SAVEPOINT after_banda_sal é executado na Tabela 13-1, ocorre o seguinte:

  1. O Oracle AI Database faz rollback somente das instruções executadas após o ponto de salvamento.

    NaTabela 13-1, o ROLLBACK TO SAVEPOINT faz com que o UPDATE de Greene seja revertido, mas não o UPDATE de Banda.

  2. O Oracle AI Database preserva o ponto de salvamento especificado na instrução ROLLBACK TO SAVEPOINT, mas todos os pontos de salvamento subsequentes são perdidos.

    NaTabela 13-1, o ROLLBACK TO SAVEPOINT faz com que o ponto de salvamento after_greene_sal seja perdido.

  3. O Oracle AI Database libera todos os bloqueios de tabela e linha adquiridos após o ponto de salvamento especificado, mas mantém todos os bloqueios de dados adquiridos antes do ponto de salvamento.

A transação permanece ativa e pode ser continuada.

Consulte Também:

Transações enfileiradas

Dependendo do cenário, as transações que aguardam recursos bloqueados anteriormente ainda podem ser bloqueadas após um rollback para o ponto de salvamento.

Quando uma transação é bloqueada por outra transação, ela é enfileirada na própria transação de bloqueio, de modo que toda a transação de bloqueio deva ser confirmada ou revertida para que a transação bloqueada continue.

No cenário mostrado na tabela a seguir, a sessão 1 faz rollback para um ponto de salvamento criado antes de executar uma instrução DML. No entanto, a sessão 2 ainda está bloqueada porque está aguardando a conclusão da transação da sessão 1.

Exemplo de Rollback para Ponto de Salvamento da Tabela 3

T Sessão 1 Sessão 2 Sessão 3 Explicação
t0 
UPDATE employees
  SET salary=7000
  WHERE last_name=
  'Banda';
     A sessão 1 inicia uma transação. A sessão coloca um bloqueio exclusivo na linha Banda (TX) e um bloqueio de tabela subexclusivo (SX) na tabela.
t1 
SAVEPOINT
  after_banda_sal;
     A Sessão 1 cria um ponto de salvamento chamado after_banda_sal.
t2 
UPDATE employees
  SET salary=12000
  WHERE last_name=
  'Greene';
     A sessão 1 bloqueia a linha Greene.
t3   
UPDATE employees
  SET salary=14000
  WHERE last_name=
 'Greene';
   A sessão 2 tenta atualizar a linha Greene, mas não consegue adquirir um bloqueio porque a sessão 1 tem um bloqueio nesta linha. Nenhuma transação foi iniciada na sessão 2.
t4 
ROLLBACK
 TO SAVEPOINT
  after_banda_sal;
    

A sessão 1 faz rollback da atualização para o salário de Greene, que libera o bloqueio de linha para Greene. O bloqueio de tabela adquirido em t0 não é liberado.

Neste ponto, a sessão 2 ainda é bloqueada pela sessão 1 porque a sessão 2 enfileira a 1 transação, que ainda não foi concluída.

t5     
UPDATE employees
  SET salary=11000
 WHERE last_name=
 'Greene';
 A linha Greene está desbloqueada no momento; portanto, a sessão 3 adquire um bloqueio para uma atualização na linha Greene. Esta instrução inicia uma transação na sessão 3.
t6 
COMMIT;
     A sessão 1 é submetida a commit, encerrando sua transação. A Sessão 2 agora está enfileirada para sua atualização na linha Greene por trás da transação na sessão 3.

Consulte Também: "Duração do Bloqueio" para saber mais sobre quando o Oracle AI Database libera bloqueios

Reversão de Transações

Um rollback de uma transação não submetida a commit desfaz qualquer alteração nos dados que foram executados por instruções SQL dentro da transação.

Depois que uma transação é submetida a rollback, os efeitos do trabalho feito na transação não existem mais. Ao fazer rollback de uma transação inteira, sem fazer referência a nenhum ponto de salvamento, o Oracle AI Database executa as seguintes ações:

A duração de uma reversão é uma função da quantidade de dados modificados.

Consulte Também:

Confirmações de transações

Uma confirmação encerra a transação atual e torna permanentes todas as alterações realizadas na transação.

Na Tabela 13-1, uma segunda transação começa com sal_update2 e termina com uma instrução COMMIT explícita. As alterações que resultaram das duas instruções UPDATE agora se tornam permanentes.

Quando uma transação é submetida a commit, as seguintes ações ocorrem:

Depois que uma transação é confirmada, os usuários podem exibir as alterações.

Normalmente, um commit é uma operação rápida, independentemente do tamanho da transação. A velocidade de um commit não aumenta com o tamanho dos dados modificados na transação. A parte mais longa do commit é a E/S de disco físico executada pela LGWR. No entanto, o tempo gasto pelo LGWR é reduzido porque ele foi gravando incrementalmente o conteúdo do buffer de redo log no segundo plano.

O comportamento padrão é o LGWR gravar redo no redo log on-line de forma síncrona e as transações aguardarem que o redo armazenado no buffer esteja no disco antes de retornar um commit para o usuário. No entanto, para menor latência de commit de transação, os desenvolvedores de aplicativos podem especificar que o redo seja gravado de forma assíncrona para que as transações não precisem aguardar que o redo esteja no disco e possa retornar da chamada COMMIT imediatamente.

Consulte Também:

Visão Geral de Transações em Quarentena

Uma transação em quarentena é uma transação isolada e não recuperada durante a recuperação do banco de dados. Requer intervenção do DBA para resolver o problema antes que os bloqueios possam ser liberados.

O Oracle AI Database utiliza redo e undo para consistência de dados. Quando o banco de dados é aberto após uma falha, a aplicação de redo encaminha o banco de dados para obter todas as alterações submetidas a commit, conhecidas como recuperação em cache, e a ação de desfazer rollback das alterações feitas por não submetidas a commit e, agora, inativas devido à falha, retornam as transações. Isso é conhecido como recuperação de travamentos. A operação aberta do banco de dados não aguarda a aplicação de undo das transações não confirmadas para se atingir uma inicialização mais rápida. Em vez disso, ele marca o estado da transação como "inativo" na tabela de transações e o banco de dados é aberto rapidamente. Em seguida, a aplicação de desfazer para transações inativas é executada de forma assíncrona pelo processo em segundo plano do monitor do sistema (SMON) e é conhecida como recuperação da transação.

O outro momento em que as transações inativas são recuperadas pelo SMON é durante a recuperação da instância. Uma instância do Oracle RAC pode travar com transações em execução ativa. Essas transações inativas contêm bloqueios de linha que bloqueiam transações nas mesmas linhas nas outras instâncias RAC restantes. O processo em segundo plano do SMON em uma das instâncias restantes executa a recuperação da instância em duas fases, a recuperação do cache seguida pela recuperação da transação.

O processo em segundo plano PMON também pode descarregar o trabalho de encerrar uma transação grande durante a limpeza do processo com falha para o SMON.

O processo SMON executa tarefas no nível do sistema, como limpeza de segmentos temporários não utilizados, unificação de extensões contíguas e muitas outras tarefas. É um processo irrecuperável, o que significa que uma falha no SMON leva a uma falha na instância do CDB. A falha na recuperação da transação SMON pode ocorrer devido a uma variedade de motivos:

Não só uma falha interrompe a recuperação da transação que está sendo ativamente recuperada pelo SMON, mas a recuperação também para o resto das transações inativas. Quando há uma falha persistente, o suporte da Oracle recomenda que os clientes desativem a recuperação de transações SMON e abram o banco de dados para reduzir o impacto. Isso faz com que os bloqueios de linha sejam mantidos por transações inativas por mais tempo. Isso afeta severamente as operações comerciais críticas.

Qualquer transação que não possa ser recuperada é colocada em quarentena e deixada sem recuperação até que o DBA possa resolver o problema. O DBA é notificado sobre a transação em quarentena e deve tomar medidas imediatas para que os bloqueios de linha mantidos pela transação em quarentena possam ser liberados.

O DBA é alertado para a presença de transações em quarentena em vários logs e visualizações para ajudar na identificação de transações em quarentena e o motivo pelo qual elas são colocadas em quarentena. O DBA usa essas informações para resolver o problema específico para que a quarentena possa ser eliminada.

Quando falhas acontecem em várias transações ou abrangem todo o PDB, como corrupção de dados lógica devido a um bug de código, corrupção física de vários blocos ou corrupção de um PDB SGA, colocar em quarentena a recuperação de transação inativa com falha pode ou não ajudar. Depende se a causa raiz dessas falhas é a mesma ou não, porque a recuperação de outras transações inativas pode ter o mesmo problema. O sistema continua em execução em um estado inconsistente mesmo depois de colocar algumas transações em quarentena. Pode ser perigoso quando a falha é devido à corrupção lógica de dados, porque se espalha ao longo do tempo. Para evitar que isso aconteça, há um limite de quarentena de transação de três (3), após o qual a quarentena é escalada para o nível do banco de dados e o PDB será encerrado usando shutdown abort se o log de arquivamento estiver ativado para o PDB e for viável fazer shutdown do PDB. A recuperação da transação para o PDB é desativada automaticamente para que o DBA possa corrigir problemas na próxima inicialização. Depois que os problemas forem resolvidos, o DBA deverá ativar a recuperação para a próxima inicialização.

Observação: Como o Oracle Data Guard usa replicação lógica, os metadados de quarentena não são replicados para o servidor stand-by ao usar o Oracle Data Guard. Portanto, o conteúdo das views de quarentena da transação, como DBA_QUARANTINED_TRANSACTIONS, no servidor stand-by pode ser diferente das entradas no servidor principal.

Tópicos Relacionados

Visão Geral do Transaction Guard

O Transaction Guard é uma API que os aplicativos podem usar para fornecer idempotência da transação, que é a capacidade do banco de dados de preservar um resultado de commit garantido que indica se uma transação foi confirmada e concluída. O Oracle AI Database fornece a API para JDBC thin, OCI, OCCI e ODP.Net.

Um erro recuperável é causado por uma falha do sistema externo, independentemente da lógica da sessão do aplicativo em execução. Erros recuperáveis ocorrem após interrupções planejadas e não planejadas de processos em primeiro plano, redes, nós, armazenamento e bancos de dados. Se uma interrupção interromper a conexão entre um aplicativo cliente e o banco de dados, o aplicativo receberá uma mensagem de erro de desconexão. A transação que estava em execução quando a conexão quebrou é chamada de transação em andamento.

Para decidir se deve reenviar a transação ou devolver o resultado (commitido ou não) ao cliente, o aplicativo deve determinar o resultado da transação em andamento. Antes do Oracle Database 12c, as mensagens de commit retornadas ao cliente não eram persistentes. Verificar uma transação não era garantia de que ela não se comprometeria depois de ser verificada, permitindo transações duplicadas e outras formas de corrupção lógica. Por exemplo, um usuário pode atualizar um navegador da Web ao comprar um livro on-line e ser cobrado duas vezes pelo mesmo livro.

Consulte Também:

Benefícios do Transaction Guard

A partir do Oracle Database 12c, o Transaction Guard fornece aos aplicativos uma ferramenta para determinar o status de uma transação em andamento após uma interrupção recuperável.

Usando o Transaction Guard, um aplicativo pode garantir que uma transação seja executada no máximo uma vez. Por exemplo, se um aplicativo de livraria on-line determinar que o commit enviado anteriormente falhou, o aplicativo poderá reenviar com segurança.

O Transaction Guard fornece uma ferramenta para execução quase uma vez para evitar que o aplicativo execute envios duplicados. O Transaction Guard fornece um resultado conhecido para cada transação.

O Transaction Guard é um recurso principal do Oracle AI Database. O Application Continuity usa o Transaction Guard ao mascarar interrupções de usuários finais. Sem o Transaction Guard, uma nova tentativa de aplicativo após um erro pode fazer com que transações duplicadas sejam confirmadas.

Consulte Também:

Como o Transaction Guard Funciona

Esta seção explica o problema das mensagens de commit perdidas e como o Transaction Guard usa IDs lógicos de transação para resolver o problema.

Mensagens de Commit Perdidas

Ao projetar para idempotência, os desenvolvedores devem resolver o problema de falhas de comunicação após o envio de declarações de commit. As mensagens de commit não persistem no banco de dados e, portanto, não podem ser recuperadas após uma falha.

O gráfico a seguir é uma representação de alto nível de uma interação entre um aplicativo cliente e um banco de dados.

Figura 2: Mensagem de Commit Perdida

Descrição da ilustração cncpt356.png

No caso de commit padrão, o banco de dados faz commit de uma transação e retorna uma mensagem de êxito ao cliente. Na Figura 13-2, o cliente submete uma instrução de commit e recebe uma mensagem informando que a comunicação falhou. Esse tipo de falha pode ocorrer por vários motivos, incluindo uma falha na instância do banco de dados ou interrupção da rede. Neste cenário, o cliente não sabe o estado da transação.

Após uma falha de comunicação, o banco de dados ainda pode estar executando o envio e não estar ciente de que o cliente foi desconectado. Verificar o estado da transação não garante que uma transação ativa não será confirmada após ser verificada. Se o cliente reenviar o commit devido a essas informações desatualizadas, o banco de dados poderá repetir a transação, resultando em corrompimento lógico.

ID da Transação Lógica

O Oracle AI Database resolve a falha de comunicação usando um identificador globalmente exclusivo chamado ID de transação lógica.

Esse ID contém o número da sessão lógica alocado quando uma sessão se conecta pela primeira vez e um número de commit em execução que é atualizado toda vez que a sessão é submetida a commit ou rolls back.Foot 1 Do ponto de vista do aplicativo, o ID da transação lógica identifica exclusivamente a última transação do banco de dados submetida na sessão que falhou.

Para cada round-trip do cliente no qual uma ou mais transações são submetidas a commit, o banco de dados armazena um ID de transação lógica. Esse ID pode fornecer idempotência de transação para interações entre o aplicativo e o banco de dados para cada percurso de ida e volta que confirma dados.

O protocolo at-most-once permite o acesso ao resultado de commit, exigindo que o banco de dados faça o seguinte:

Enquanto uma transação está em execução, o banco de dados e o cliente mantêm o ID da transação lógica. O banco de dados fornece ao cliente um ID de transação lógica na autenticação, ao pedir emprestado de um pool de conexões e a cada ida e volta do driver do cliente que executa uma ou mais operações de commit.

Para que o aplicativo possa determinar o resultado da última transação após um erro recuperável, ele obtém o ID de transação lógica mantido no cliente usando Java, OCI, OCCI ou APIs ODP.Net. Em seguida, o aplicativo chama o procedimento PL/SQL DBMS_APP_CONT.GET_LTXID_OUTCOME com o ID de transação lógica para determinar o resultado do último envio: confirmado (true ou false) e chamada do usuário concluída (true ou false).

Ao usar o Transaction Guard, o aplicativo pode reproduzir transações quando o erro é recuperável e a última transação na sessão não foi confirmada. O aplicativo pode continuar quando a última transação tiver sido confirmada e a chamada do usuário tiver sido concluída. O aplicativo pode usar o Transaction Guard para retornar o resultado conhecido ao cliente para que o cliente possa decidir a próxima ação a ser tomada.

Consulte Também:

Transaction Guard: Exemplo

Neste cenário, a mensagem de commit é perdida por causa de um erro recuperável.

O Transaction Guard usa o ID da transação lógica para preservar o resultado da instrução COMMIT, garantindo que haja um resultado conhecido para a transação.

Figura 3: Verificação do Status da Transação Lógica

Descrição da ilustração cncpt365.png

Na Figura 13-3, o banco de dados informa ao aplicativo se a transação foi submetida a commit e se a última chamada do usuário foi concluída. O aplicativo pode então retornar o resultado ao usuário final. As possibilidades são:

Consulte Também: Guia de Desenvolvimento do Oracle AI Database para saber como usar o Transaction Guard

Visão Geral da Continuidade do Aplicativo

O serviço Application Continuity tenta mascarar interrupções de aplicativos repetindo solicitações de aplicativos incompletas após interrupções não planejadas e planejadas. Nesse contexto, uma solicitação é uma unidade de trabalho do aplicativo.

Normalmente, uma solicitação corresponde às instruções DML e outras chamadas de banco de dados de uma única solicitação Web em uma única conexão de banco de dados. Em geral, uma solicitação é demarcada pelas chamadas feitas entre o check-out e o check-in de uma conexão de banco de dados de um pool de conexões.

Essa seção contém os seguintes tópicos:

Benefícios da Continuidade de Aplicativos

Um problema básico para os desenvolvedores é como mascarar uma sessão de banco de dados perdida dos usuários finais.

O Application Continuity tenta resolver o problema de sessão perdida restaurando a sessão do banco de dados quando qualquer componente interrompe a conversa entre o banco de dados e o cliente. A sessão restaurada do banco de dados inclui todos os estados, cursores, variáveis e a transação mais recente quando existe uma.

Caso de Uso para Continuidade de Aplicativos

Em um caso típico, um cliente enviou uma solicitação ao banco de dados, que criou estados transacionais e não transacionais.

O estado no cliente permanece atual, potencialmente com dados inseridos, dados retornados e dados e variáveis armazenados em cache. No entanto, o estado da sessão do banco de dados no qual o aplicativo precisa operar é perdido.

Se a solicitação do cliente tiver iniciado uma ou mais transações, o aplicativo será confrontado com as seguintes possibilidades:

Se a repetição for bem-sucedida, o serviço de usuário do banco de dados para interrupções planejadas e não planejadas não será interrompido. Se o banco de dados detectar alterações nos dados vistos e potencialmente agidos pelo aplicativo, a repetição será rejeitada. Não há tentativa de repetição quando o tempo permitido para iniciar a repetição é excedido, o aplicativo usa uma chamada restrita ou o aplicativo desativou explicitamente a repetição usando o método disableReplay.

Consulte Também: Oracle Real Application Clusters Administration and Deployment Guide para saber mais sobre como o Application Continuity funciona para sessões de banco de dados

Continuidade do Aplicativo para Manutenção Planejada

A Continuidade de Aplicativos para interrupções planejadas permite que os aplicativos continuem as operações para sessões de banco de dados que podem ser drenadas ou migradas de forma confiável.

A manutenção programada não precisa interromper o trabalho do aplicativo. O Application Continuity oferece tempo de trabalho ativo para drenar de seu local atual para um novo local atualmente não afetado pela manutenção. No final do intervalo de drenagem, as sessões podem permanecer na instância do banco de dados em que a manutenção é planejada. Em vez de desconectar essas sessões à força, a Continuidade de Aplicativos pode fazer failover dessas sessões para um site restante e reenviar qualquer transação em andamento.

Com a Continuidade de Aplicativos ativada, o banco de dados pode fazer o seguinte:

Controle o comportamento de drenagem durante a manutenção planejada usando os atributos de serviço drain_timeout e stop_option do utilitário SRVCTL, do GDSCTL (Global Data Services Control Utility) e do Oracle Data Guard Broker. O pacote DBMS_SERVICE fornece a infraestrutura subjacente.

Consulte Também:

Arquitetura de Continuidade de Aplicativos

Os principais componentes da Continuidade de Aplicativos são runtime, reconexão e repetição.

As fases são as seguintes:

  1. Runtime normal

    Nessa fase, a Continuidade de Aplicativos executa as seguintes tarefas:

    • Identifica solicitações de banco de dados

    • Decide se as chamadas locais e de banco de dados podem ser repetidas

    • Cria objetos de proxy para ativar a repetição, se necessário, e para gerenciar filas

    • Mantém chamadas originais e validação dessas chamadas até que o final da solicitação ou repetição do banco de dados seja desativado

  2. Reconexão

    Esta fase é acionada por um erro recuperável. O Application Continuity executa as seguintes tarefas:

    • Garante que a repetição seja ativada para solicitações de banco de dados

    • Gerencia timeouts

    • Obtém uma nova conexão com o banco de dados e, em seguida, valida se este é um destino de banco de dados válido

    • Usa o Transaction Guard para determinar se a última transação foi confirmada com sucesso (as transações confirmadas não foram reenviadas)

  3. Repetir

    O Application Continuity executa as seguintes tarefas:

    • Repete chamadas que são mantidas na fila

    • Desativa a repetição se alterações visíveis pelo usuário nos resultados aparecerem durante a repetição

    • Não permite um commit, mas permite que o último recall (que encontrou o erro) seja confirmado

Após uma repetição bem-sucedida, a solicitação continua do ponto de falha.

Consulte Também:

Visão Geral de Transações Autônomas

Uma transação autônoma é uma transação independente que pode ser chamada de outra transação, que é a principal. Você pode suspender a transação de chamada, executar operações SQL e fazer commit ou desfazer na transação autônoma e, em seguida, retomar a transação de chamada.

As transações autônomas são úteis para ações que devem ser executadas de forma independente, independentemente de a transação de chamada ser confirmada ou revertida. Por exemplo, em uma transação de compra de ações, você deseja confirmar os dados do cliente, independentemente de a compra geral de ações ser realizada. Além disso, você deseja registrar mensagens de erro em uma tabela de depuração mesmo que a transação geral seja revertida.

As transações autônomas têm as seguintes características:

No PL/SQL, uma transação autônoma é executada em um escopo autônomo, que é uma rotina marcada com o pragma AUTONOMOUS_TRANSACTION. Nesse contexto, as rotinas incluem blocos PL/SQL anônimos de nível superior e subprogramas e triggers PL/SQL. Um pragma é uma diretiva que instrui o compilador a executar uma opção de compilação. O pragma AUTONOMOUS_TRANSACTION instrui o banco de dados de que esse procedimento, quando executado, deve ser executado como uma nova transação autônoma que é independente de sua transação pai.

O gráfico a seguir mostra como o controle flui da rotina principal (MT) para uma rotina autônoma e volta novamente. A principal rotina é proc1 e a rotina autônoma é proc2. A rotina autônoma pode fazer commit de várias transações (AT1 e AT2) antes que o controle retorne à rotina principal.

Figura 4: Fluxo de Controle de Transações

Descrição da ilustração cncpt288.gif

Quando você insere a seção executável de uma rotina autônoma, a rotina principal é suspensa. Quando você sai da rotina autônoma, a rotina principal é retomada.

Na Figura 13-4, o COMMIT dentro do proc1 torna permanente não apenas seu próprio trabalho, mas qualquer trabalho pendente executado em sua sessão. No entanto, um COMMIT no proc2 torna permanente apenas o trabalho executado na transação proc2. Assim, as instruções COMMIT nas transações AT1 e AT2 não têm efeito na transação MT.

Consulte Também: Oracle AI Database Development Guide e Oracle AI Database PL/SQL Language Reference para aprender a usar transações autônomas

Visão Geral de Transações Distribuídas

Transação distribuída é uma transação que inclui uma ou mais instruções que atualizam dados em dois ou mais nós distintos de um banco de dados distribuído, usando um objeto de esquema chamado link de banco de dados.

Um banco de dados distribuído é um conjunto de bancos de dados em um sistema distribuído que pode aparecer para aplicativos como uma única origem de dados. Um link do banco de dados descreve como uma instância do banco de dados pode fazer log-in em outra instância do banco de dados.

Ao contrário de uma transação em um banco de dados local, uma transação distribuída altera dados em vários bancos de dados. Consequentemente, o processamento de transações distribuídas é mais complicado porque o banco de dados deve coordenar a confirmação ou o rollback das alterações em uma transação como uma unidade atômica. Toda a transação deve ser confirmada ou revertida. O Oracle AI Database deve coordenar o controle de transações em uma rede e manter a consistência dos dados, mesmo que ocorra uma falha na rede ou no sistema.

Commit de Duas Fases

O mecanismo de commit de duas fases garante que todos os bancos de dados que participam de uma transação distribuída façam commit ou desfazam todas as instruções na transação. O mecanismo também protege a DML implícita executada por restrições de integridade, chamadas de procedimento remoto e acionadores.

Em um commit de duas fases entre vários bancos de dados, um banco de dados coordena a transação distribuída. O nó iniciador é chamado de coordenador global. O coordenador pergunta aos outros bancos de dados se eles estão preparados para fazer commit. Se algum banco de dados responder sem um não, será feito rollback de toda a transação. Se todos os bancos de dados votarem sim, o coordenador transmitirá uma mensagem para tornar o commit permanente em cada um dos bancos de dados.

O mecanismo de commit de duas fases é transparente para os usuários que emitem transações distribuídas. Na verdade, os usuários nem precisam saber que a transação é distribuída. Uma instrução COMMIT que denota o fim de uma transação aciona automaticamente o mecanismo de commit de duas fases. Nenhuma sintaxe de instrução complexa ou de codificação é necessária para incluir transações distribuídas no corpo de um aplicativo de banco de dados.

Consulte Também:

Transações Duvidosas

Uma transação distribuída inquestionável ocorre quando um commit de duas fases é interrompido por qualquer tipo de falha do sistema ou da rede.

Por exemplo, dois bancos de dados reportam ao banco de dados de coordenação que estavam preparados para fazer commit, mas a instância do banco de dados de coordenação falha imediatamente após receber as mensagens. Os dois bancos de dados que estão preparados para commit agora ficam suspensos enquanto aguardam a notificação do resultado.

O processo em segundo plano do recuperador (RECO) resolve automaticamente o resultado de transações distribuídas duvidosas. Depois que a falha é reparada e a comunicação é restabelecida, o processo RECO de cada banco de dados Oracle local faz commit ou rollback automaticamente de todas as transações distribuídas duvidosas consistentemente em todos os nós envolvidos.

No caso de uma falha de longo prazo, o Oracle AI Database permite que cada administrador local faça commit ou desfaça manualmente qualquer transação distribuída que esteja em dúvida por causa da falha. Essa opção permite que o administrador do banco de dados local libere todos os recursos bloqueados que são mantidos indefinidamente por causa da falha de longo prazo.

Se um banco de dados tiver que ser recuperado no passado, os recursos de recuperação de banco de dados permitirão que os administradores de banco de dados em outros sites retornem seus bancos de dados para o momento anterior. Essa operação garante que o banco de dados global permaneça consistente.

Consulte Também:

Legenda da Nota de Rodapé

Nota de rodapé 1:

Para o Oracle Real Application Clusters (Oracle RAC), o ID da transação lógica inclui o número da instância do banco de dados como prefixo.