Transcript
Page 1: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu1/35

Tudo que você precisa saber sobre transações

Carlos H. Cantuwww.firebase.com.br

Page 2: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu2/35

Transações

• Um dos maiores benefícios da mudança de bancos desktop para Cliente/Servidor.

• Modelo de gerenciamento varia entre os SGBDs.

• Visa manter a consistência dos dados.• Controle e seqüência de operações são

de responsabilidade do desenvolvedor.• “Protegem” os dados no caso de falha no

lado cliente, mas não do lado servidor (use nobreak, etc!)

Page 3: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu3/35

Transações no Firebird

• MGA – Multi Generational Architecture (conhecida também por MVCC)

• Armazena as alterações diretamente no banco de dados, juntamente com informações para reverter ao estado original (backversions).

• Dispensa log de transações.

Page 4: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu4/35

ACID

• Atomicidade• Consistência• Isolamento• Durabilidade

• Firebird é totalmente compatível com ACID

Page 5: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu5/35

ACID - Atomicidade

• Todas as operações realizadas dentro de uma única transação, são parte de uma única operação indivisível.

Page 6: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu6/35

ACID - Consistência

• O banco de dados deve ficar num estado consistente, tão logo a transação seja completada.

Page 7: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu7/35

ACID - Isolamento

• Cada transação deve ficar completamente isolada de outras transações concorrentes, fazendo com que as alterações nos dados não sejam expostas a outras transações antes da transação commitar.

Page 8: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu8/35

ACID - Durabilidade

• Assim que a transação se completar, as alterações nos dados se tornam permanentes.

• Durante o commit, o SGBD deve registrar que a transação foi terminada com sucesso, e realizar outros trabalhos, por exemplo, no caso do 2 phase commit ou eventos.

Page 9: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu9/35

Firebird

• Alterações nos dados são escritas diretamente no disco (não ficam na memória*), bem como os dados necessários para reverter para o estado original. Esses dados ocupam espaço temporariamente.

• Necessário uma forma de controlar esse lixo (Garbage Collection).

* Não confudir com cache de disco.

Page 10: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu10/35

Oracle, DB2, Sybase, SQLServer

• O BD contem sempre a informação da última atualização realizada.

• Para voltar ao estado anterior – é necessário log de transações.

• Implicações: – Alto custo de rollback– É possível voltar o BD em qualquer período de tempo.– Fácil limpar os logs de operacões (separados do BD)– Isolamento entre transações utiliza travas, pois o BD

tem somente a última informação escrita.

Page 11: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu11/35

Firebird, PostgreSQL

• O BD contem todas as versões de um registro que estão sendo utilizadas por diferentes transações concorrentes, dispensando o log de transações.

• Implicações: – Rollbacks “baratos”.– Sujeira no BD.– “Impossível” voltar o BD para um determinado

momento no tempo.– Transações podem ler os registros sem

necessidade de travas.

Page 12: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu12/35

Backversions

• Um mesmo registro pode ter diferentes versões disponíveis.

• Cada nova versão contém um link apontando para a versão anterior, formando uma cadeia de versões.

• Cada backversion possui o número da transação que o criou.

• Leitura começa sempre pela versão mais recente.

• Criados por updates ou deletes.

Page 13: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu13/35

Backversions e Deltas

• Backversion:– Delta – contém apenas os valores dos campos

alterados.– Full – contém os valores de todos os campos

do registro.• Full – é criado se a mesma transação

atualiza o mesmo registro pela segunda vez, ou se o tamanho do Delta ficar maior que a de um full.

Page 14: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu14/35

Iniciando uma transação no Firebird

• SET TRANSACTION [READ WRITE | READ ONLY] [WAIT | NO WAIT [LOCK TIMEOUT]] /* resolução de

conflitos */ [ISOLATION LEVEL] /* isolamento */

{SNAPSHOT [TABLE STABILITY] | READ COMMITTED [[NO] RECORD_VERSION]]}

[RESERVING <reserving-clause> | USING <db-handle> [, db-handle ...]];

• <reserving-clause> ::= <table> [, <table> ...] [FOR [SHARED | PROTECTED] {READ | WRITE}] [, <reserving-clause> [, <reserving-clause>..]]

Page 15: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu15/35

Encerrando uma transação

COMMIT /* Encerrar confirmando as alterações */

ROLLBACK /* Encerrar desfazendo as alterações */

COMMIT RETAIN /* Confirma alterações, mas mantém o contexto da transação */

ROLLBACK RETAIN /* Confirma alterações, mas mantém o contexto da transação */

Page 16: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu16/35

Controle transacional

• O controle transacional é feito pela aplicação cliente.

• Não há como iniciar ou encerrar uma transação de dentro de triggers ou stored procedures.

Page 17: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu17/35

DEADLOCK

• Deadlock é a forma que o Firebird tem para avisar que um conflito de atualizações foi encontrado.

• A aplicação cliente deve identificar os deadlocks e decidir o que fazer.

Page 18: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu18/35

Modo WAIT e NO WAIT

• NO WAIT - Determina se conflitos encontrados devem retornar imediatamente um deadlock.

• WAIT – Faz com que a transação que encontrou um conflito aguarde que a outra transação faça um rollback ou um commit.

• A partir do FB 2, é possível determinar um timeout para o modo WAIT.

Page 19: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu19/35

Isolamentos

• Determinam como as transações concorrentes interagem e enxergam os dados entre si.

• Isolamentos “comuns”:– Dirty Read– Read Commited– Repeatable Read– Serializable

Page 20: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu20/35

Isolamentos – Dirty Read/Read Uncommited

• Não é suportado pelo Firebird (não faz sentido para o FB, pois ele permite que as transações concorrentes enxerguem os dados previamente commitados).

Page 21: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu21/35

Isolamentos – Read Commited

• A transação só pode ver os dados que já estão commitados.

• Geralmente, nos outros BDs, as transações não conseguem ler registros que estão com alterações pendentes.

• Indicado para “browse”, manutenção de dados.

• FB suporta dois modos neste isolamento: – record_version– no_record_version (imita os outros SGBDs que

usam travas/log de transações)

Page 22: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu22/35

Isolamentos – Repeatable Read

• Firebird fornece isolamento similar: Concurrency/Snapshot

• “Foto” do BD - a transação não enxerga alterações feitas por outras transações.

• Diferença para o Repeatable Read: o Firebird não garante que os registros lidos poderão ser alterados pela própria transação (outra transação pode alterar ele primeiro).

• Indicado para relatórios.

Page 23: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu23/35

Isolamentos – Serializable/Consistency

• Também chamado de Snapshot Table Stability

• Semelhante ao Snapshot, mas garante que os registros lidos poderão ser atualizados pela transação.

• Bloqueia outras transações de gravar nas tabelas que foram acessadas pela transação.

• Nota: A tabela é travada somente depois que alguma instrução SQL à acessou.

Page 24: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu24/35

Firebird – Table Reservation Transaction

• Permite iniciar uma transação e colocar travas em tabelas específicas.

• A trava é colocada assim que a transação é iniciada.

• Sucesso depende do WAIT/NOWAIT e se há escritas pendentes feitas por outras transações.

• Permite travar tabelas "dependentes" (que sofrem alterações por triggers, etc)

Page 25: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu25/35

Table Reservation Transaction

• Modos suportados:– Shared read. Todas as transações podem ler

e gravar (maior grau de concorrência).– Shared write. Todas as transações, exceto as

com isolamento consistency podem ler e gravar.

– Protected read. Todas as transações (incluindo esta) só podem ler.

– Protected write. Todas as transações, exceto as consistency, podem ler, mas somente esta transação pode gravar.

Page 26: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu26/35

Table Reservation - exemplo

• SQL> set transaction isolation level read committed reserving clientes for protected write;

• Faz com que a tabela clientes só possa ser gravada pela transação atual.

Page 27: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu27/35

Two Phase Commit

• Permite que uma mesma transação esteja conectada à diferentes bancos de dados.

• Útil, por exemplo, em replicações síncronas.

• Pode gerar transações em limbo.

Page 28: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu28/35

Garbage Collection

• Faz a limpeza do lixo.• No FB >= 2.0 pode ser cooperativa ou

background.• Apaga as versões dos registros anteriores

à OST, diminuindo o tamanho da “cadeia” de backversions.

• Libera o espaço ocupado pelos backversions para ser reaproveitado.

Page 29: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu29/35

SWEEP

• Limpeza do banco de dados.• Pode ser disparado manualmente ou

automaticamente (OAT – OIT).• Percorre todas as tabelas do BD,

descartando as backversions, liberando o espaço para ser reaproveitado.

• Incrementa a OIT. Se o acesso for exclusivo, o número será o da Next Transaction menos 1.

Page 30: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu30/35

GSTAT -h

Database "employee.fdb"Database header page information:

Flags 0Checksum 12345Generation 199Page size 4096ODS version 11.1Oldest transaction 194 -- OITOldest active 195 -- OATOldest snapshot 192 -- OSTNext transaction 197 -- NTBumped transaction 1Sequence number 0Next attachment ID 8Implementation ID 16Shadow count 0Page buffers 0Next header page 0Database dialect 3Creation date Feb 27, 2009 23:24:29Attributes force write

Variable header data:*END*

Page 31: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu31/35

Números importantes

• OAT – Oldest Active Transaction• OIT – Oldest Interesting Transaction -

transações com estado diferente de commit, ex: active, limbo, rolled back.

• OST = Oldest Snapshot Transaction.• Os valores da OAT, OST, OIT e Next são

atualizados sempre que uma nova transação é iniciada.

Page 32: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu32/35

Situações “interessantes”

• Deadlock gerado com um select:– Transações com isolamento read committed

no record_version e no wait;

• Transações Read Committed READ ONLY não bloqueiam a coleta de lixo.

• 90% das reclamações de lentidão com o Firebird estão relacionadas com o controle incorreto das transações (ou falta dele).

Page 33: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu33/35

Situações “interessantes”

• Commit RetainingOperação Trans. ID OAT

Start Transaction 1 1

Commit 1 1

Start Transaction 2 2

Commit Retaining 2 2

Commit Retaining 2 2

Commit Retaining 2 2

Commit Retaining 2 2

Commit 2 2

Start Transaction 3 3

Operação Trans. ID OAT

Start Transaction 1 1

Commit 1 1

Start Transaction 2 2

Update... 2

Commit Retaining 3 2

Commit Retaining 3 2

Update... 2

Commit Retaining 4 2

Commit Retaining 4 2

Commit 4 2

Start Transaction 5 5

Page 34: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu34/35

Utilitários que podem ajudar

• FB Scanner• FB DataGuard

• Versões de avaliação e Free no CD do FDD.

Page 35: Carlos H Cantu - Tudo Sobre Transacoes

www.FirebirdDevelopersDay.com.br © 2009 – Carlos H. Cantu35/35

Dúvidas?


Top Related