SlideShare uma empresa Scribd logo
1 de 28
Baixar para ler offline
TRANSAÇÕES 
Wagner Bianchi 
Certified MySQL 5.0 Developer 
Certified MySQL 5.0 Database Administrator 
Certified MySQL Cluster Database Administrator
Artigo recomendado: 
• http://imasters.uol.com.br/artigo/7755/mysql/stored_procedures_-_transacoes/
Transações 
" “Transação é uma unidade lógica de trabalho, envolvendo diversas 
operações de bancos dados” – (C. J. Date, Cambridge - UK 1964); 
" Os conceitos existentes de transação de bancos de dados relacionais ou 
objeto-relacionais estão diretamente ligados aos matemáticos, autores e 
pesquisadores Christopher J. Date e Edgard Frank Codd, ambos autores 
de vários livros e também do modelo relacional, introduzido por Codd ainda 
quando trabalhavam juntos na IBM, em 1983 no SGBD chamado SQL/DS; 
" Com maior abrangência, podemos definir transações em bancos de dados 
com um aglomerado sequencial de comandos SQL, executando várias 
consultas de transformação de dados, produzindo algum resultado, 
podendo alterar ou não o estado atual dos dados do banco de dados;
Transações 
" Transações podem ser implícitas ou explícitas; 
" Todo comando DML (Data Manipulation Language) ou DDL (Data 
Manipulation Language) que é enviado ao SGBD é considerado uma 
transação implícita, ou seja, após dispararmos o comando, via terminal, por 
exemplo, o SGBD se encarregará de enviar um COMMIT ao final; 
" ALTER TABLE, BEGIN, CREATE INDEX, DROP INDEX, DROP TABLE, 
LOAD MASTER DATA, LOCK TABLES, LOAD DATA INFILE, RENAME 
TABLE, START TRANSACTION, UNLOCK TABLES sofrem um COMMIT 
implícito; 
" Temos uma variável de ambiente do MySQL que controla tal feature, 
denominada autocommit, que pode ser acessada através do seguinte 
comando: 
SELECT @@autocommit;
Transações 
" O padrão da variável autocommit é 1, implicando diretamente no 
comportamento do SGBD para cada comando que é enviado pelo usuário 
de um banco de dados; 
" Após cada comando, a declaração COMMIT é enviada automaticamente 
para tornar permanente no log aquela transação – (mais à frente veremos 
com detalhes as declarações COMMIT e ROLLBACK e seus significados);
Transações 
" Caso configuremos o autocommit como 0, teremos uma nova situação em 
que, caso não enviemos um COMMIT explicitamente após a uma transação 
implícita, a última transação não se tornará permanente no arquivo de 
dados, pois, o SGBD considerará como uma transação ainda aberta; 
" O log binário do MySQL é responsável por registrar as transações em 
grupos – caso uma transações tenha mais de um comando -, ou uma a 
uma caso a transação seja formada de apenas um comando. Para que as 
modificações se tornem permanentes no arquivo de dados, o log ainda 
deve resgistrar um COMMIT ao final de cada transação;
Transações 
" O MySQL trabalha intensamente com o log-bin para checar quais dados 
devem ser gravados nas páginas de dados em disco ou se devem sofrer 
um ROLLBACK; com a limpeza do log e retirada dele as transações que não 
sofreram um COMMIT; 
" ROLLBACK é o contrário de COMMIT; 
" O MySQL checa a última transação ou grupos de transação que não 
receberam um COMMIT ao final e desfaz todas as modificações o banco de 
dados; 
BD 
START TRANSACTION; 
-- comando 1 
SELECT @A:=SUM(salary) 
FROM table1 WHERE type=1; 
-- comando 2 
UPDATE table2 
SET summary=@A WHERE type=1; 
COMMIT; 
LOG 
BIN 
COMMIT
Transações 
" Normalmente, as transações não só no MySQL, mas, na maioria dos 
SGBD’s relacionais são inciadas em meio à procedimentos armazenados; 
" Antes de iniciarmos de fato com os comandos de transação, temos que 
saber o que é o bloqueio de tabelas, as chamadas contenções; 
" O MySQL controla as contenções de tabelas de várias formas. Na verdade, 
esse controle é intrinseco ao Storage Engine utilizado pelas tabelas que se 
encontram em meio a uma transação, seja ela explícita ou implícita; 
" Quando estamos utilizado uma tabela, controlada pelo Storage Engine 
MyISAM, o bloqueio de tabelas será realizado em nível de tabela, ou 
seja, a tabela será travada por completo, enquanto a transação atual não 
terminar. Tabelas MyISAM somente suportam transações implícitas;
Transações 
" Tabelas InnoDB tem bloqueio em nível de linha, ou seja, caso uma dada 
transação A esteja atualizando uma linha de uma tabela, a transação B terá 
que esperar até que A termine suas atividades para atualizar esta mesma 
linha, nessa mesma tabela; 
" O Storage Engine mais utilizado para ambientes que precisam de suporte à 
transação é o INNODB. Este Engine tem suporte à transações e contempla 
em 100% o modelo de transação ACID, que é um acrônimo para as 
propriedades: 
– Atomicidade; 
– Consistência; 
– Isolamento; 
– Durabilidade; 
" Leitura complementar: 
http://databases.about.com/od/specificproducts/a/acid.htm
Transações - ACID 
" Atomicidade; 
" Toda transação deverá ser atômica, o verdadeiro “tudo ou nada”. Um 
exemplo interessante seria uma transferência bancária entre contas de 
mesmo banco. Imagine que subtraímos o saldo da conta A e checamos a 
existência da conta B. Caso a conta B exista, somamos o saldo à conta B; 
" Agora imaginemos que, ao checar a existência da conta B, esta conta não 
existe! A quantia subtraída da conta A não poderá simplesmente 
desaparecer, afinal, esse “dinheiro” tem dono; 
" O comando seguinte falhará e haverá um ROLLBACK, restaurando o valor 
antes subtraído à conta de origem, no caso, a conta A;
Transações - ACID 
" Consistência: 
" Transações devem preservar a consistência do banco de dados, ou seja, 
transforma um estado consistente do banco de dados em outro estado 
consistente, sem necessariamente preservar o estado de consistência em 
todos os pontos intermediários; 
" O ponto de inconsistência plena do estado do banco de dados no exemplo 
da transferência bancária é exatamente no momento em que o saldo é 
subtraído de uma conta para ser adicionado na outra; 
" O banco é coloca em um estado sem consistência e depois retorna ao 
estado consistente diferente do de antes – leve em consideração o conceito 
já visto de transação;
Transações - ACID 
" Isolamento: 
" Transações são isoladas umas das outras, de acordo com o nível de 
isolamento definido no momento em que a transação se inicia, que no 
MySQL são: REPEATABLE READ, READ COMMITED, READ 
UNCOMMITED e SERIALIZABLE; 
" Também chamados de TRANSACTION ISOLATION LEVEL e derivados 
dos termos do SQL:ANSI 1992, o INNODB no MySQL tem como padrão 
em todas as instalações o level REPEATABLE READ; 
" Podemos checar qual é o ISOLATION LEVEL atual com o seguinte 
comando: 
SHOW VARIABLES LIKE ‘%isolation%’;
Transações - ACID 
" Isolamento: 
" REPEATABLE READ: (SNAPSHOT) terá a mesma leitura de um dado 
mesmo que um SELECT se repita, provendo sempre o mesmo resultado 
para diferentes execuções da mesma consulta. Nesse nível de isolamento, 
se a leitura não fosse repetida, teríamos os conhecidos phantoms, que 
acontecem entre um SELECT e ou outro, com uma atualização dos dados 
nesse espaço de tempo. Isso não é possível com o Storage Engine 
INNODB; 
" READ COMMITED: permite que a transação atual leia/manipule somente 
os dados já permanetes ou “comitados” por outras transações. Dados já 
atualizados mas que ainda não receberam um COMMIT explícito ainda não 
serão vistos, sendo estes invisíveis. Como esse nível de isaolamento 
permite “non-repeatable reads”, phantoms podem ocorrer.
Transações - ACID 
" Isolamento: 
" READ UNCOMMITED: permite que uma transação veja manipulações não 
“comitadas” de outras transações, o que pode acarretar problemas com 
leituras sujas – dirty reads - e non-repeatable reads que colaboram para o 
aparecimento dos phantoms; 
" SERIALIZABLE: esse nível de isolamento, isola completamente uma 
transação de outra, ou seja, enquanto uma trabalha a outra aguarda para 
poder iniciar o seu trabalho. Similar ao nível READ REPEATABLE, 
diferindo que as linhas selecionadas por uma transação não são nem lidas 
e nem atualizadas por outra transação, “uma de cada vez”;
Transações - ACID 
" Os níveis de isolamento são importantes no contexto em que existam 
muitas transações acontecendo ao mesmo tempo. Os níveis trabalham os 
bloqueios nas linhas das tabelas ou nas tabelas para que não haja falta de 
consistência após o término de uma transação; 
" As leituras consistentes são possíveis devido ao multiversionamento feito 
pelo INNODB. Uma linhas poderá ter várias versões sendo trabalhadas em 
meio às transações, de acordo com o nível de isolamento selecionado; 
" Tal versionamento de linhas em meio à transações, que ocorre de acordo 
com o nível de isolamento configurado é chamado de MVCC (Multi-versioning 
Concurrency Control); 
" Para que esse versionamento acontece de forma consistente, ele depende 
também do log de undo (localizado junto com os arquivos de Tablespace);
Transações - ACID 
" Para alterar o nível de isolamento atual do MySQL, podemos editar o 
arquivo de opções (my.ini/my.cnf), e dentro do agrupamento [mysqld], 
colocamos a seguinte linha (reinicie o MySQL após esta alteração): 
[mysqld] 
transaction-isolation=READ-COMMITED 
" Podemos alterar a partir do Terminal ou Prompt de comando, através do 
seguinte comando, já logado no MySQL, através do mysql client: 
SET GLOBAL TRANSACTION ISOLATION LEVEL isolation_level; 
SET SESSION TRANSACTION ISOLATION LEVEL isolation_level; 
SET TRANSACTION ISOLATION LEVEL isolation_level;
Transação - ACID 
" Somente usuários do banco de dados com privilégio SUPER 
poderão utilizar o primeiro comando, que seta o nível de isolamento 
de forma global; 
" Qualquer usuário poderá utilizar a segunda e a terceira declaração, 
pois, só afetarão a sessão corrente. Após a desconexão o comando 
será desconsiderado;
DEADLOCKS 
" Deadlocks são um problema clássico em banco de dados transacionais, 
mas eles não são perigosos, a menos que eles sejam tão freqüentes que 
você não possa executar certas transações; 
" Normalmente você tem que escrever suas aplicações de forma que elas 
sempre estejam preparada a reexecutar uma transação se for feito um 
ROLLBACK por causa de deadlocks; 
" Uma dada transação A precisa atualizar uma linha da tabela Y, mas a 
transação para soltar o bloqueio desta linha, precisa adquirir um bloquieo 
da linha que A está lendo neste momento; 
" O INNODB tem mecanismos que detectam os possíveis deadlocks e faz 
um ROLLBACK nas transações. Caso ocorra, a menor transação – aquela 
que movimenta menor número de bytes – sofrerá um ROLLBACK;
Exercícios 
" Com base no assunto apresentado até aqui, resolva a LISTA 2 de 
exercícios, valendo pontos.
Principais Comandos 
" Quando se deseja trabalhar com o transações em bancos de dados 
contidos no MySQL, a primeira coisa que temos a fazer é entender o 
funcionamento do modo autocommit, que como já vimos, por padrão é 
configurado como 1, ou seja, ON; 
" Quando autocommit está setado como 1, um COMMIT implícito é disparado 
ao fim de cada comando. Quando setado como 0, desabilitado, todos os 
comandos seguintes a esta configuração são encarados pelo SGBD como 
parte de uma transação, for a os comandos que recebem um COMMIT 
implícito mesmo com autocommit desabilitado; 
" O comando START TRANSACTION, utilizado para iniciar uma transação, 
ignora o modo autocommit. Quando um procedimento dispara a 
declaração, autocommit é setado automaticamente para 0, sendo 
necessário um COMMIT ou ROLLBACK para finalizar a transação;
Principais Comandos 
" Os comandos para se iniciar uma transação e que anulam o modo 
autocommit são: 
– START TRANSACTION; 
– BEGIN WORK; 
– BEGIN (diferente de BEGIN … END); 
" Caso se inicie uma transação com qualquer das declarações acima e 
autocommit esteja habilitado, ele é implicitamente desabilitado até que a 
transação finalize; 
" Podemos então, iniciar transações de duas maneiras no MySQL, 
desabilitando explicitamente o autocommit mode ou utilizando das 
declarações supracitadas para desabilitar automaticamente antes de rodar 
os comandos;
Principais Comandos 
" Iniciando uma transação, desabilitando autocommit mode explicitamente: 
SET AUTOCOMMIT=0; 
…declarações da transação 1… 
[COMMIT | ROLLBACK]; 
SET AUTOCOMMIT=0; 
… declarações da transação 2 … 
[COMMIT | ROLLBACK]; 
" Demonstrações: 
– Iniciar uma transação desabilitando autocommit explicitamente; 
– Utilizar COMMIT e ROLLBACK;
Principais Comandos 
" Iniciando transações e suspendendo automaticamente o modo autocommit: 
[START TRANSACTION | BEGIN WORK | BEGIN] 
…declarações da transação 1… 
[COMMIT | ROLLBACK] 
[START TRANSACTION | BEGIN WORK | BEGIN] 
…declarações da transação 2… 
[COMMIT | ROLLBACK] 
" Demonstrações: 
– Iniciar uma transação desabilitando autocommit implicitamente; 
– Utilizar COMMIT e ROLLBACK;
Principais Comandos 
" Para se ter um ROLLBACK das transações de modo funcional e efetivo, sem 
correr riscos, é fundamental garantir que o modo autocommit esteja 
desabilitado explicita ou implicitamente; 
" Somente para salientar, ROLLBACK é retornar todas as modificações feitas 
em dados por uma trasação caso haja algum erro para completar esta de 
forma integral; 
" Podemos digitar o comando START TRANSACTION e iniciar nossa 
transação comando a comando e depois entrar com um ROLLBACK. 
Veremos que tudo aquilo que fizemos comando a comando foi retornado ao 
momento anterior; 
" O MySQL utiliza o log-binário e o tablespace do INNODB, que contém o 
segmento de rollback e informações de undo log para retornar ao momento 
anterior, transações que falharam;
Principais Comandos 
" É permitido fazermos um ROLLBACK parcial da transação, tanto 
explicitamente quanto em meio à procedimentos armazenados – Stored 
Procedures; 
" Utilizamos os SAVEPOINT’s para demarcar os pontos em meio às 
transações. Utilizando um SAVEPOINT nomeado, podemos solicitar que o 
SGBD faça um ROLLBACK até determinado ponto da transação, não 
voltando necessariamente tudo o que foi feito; 
" Múltiplos SAVEPOINT’s podem ser criados em meio à transações. Para 
retornar uma transação até um determinado ponto onde foi detado um 
SAVEPOINT, utilizamos a seguinte sintaxe: 
ROLLBACK TO SAVEPOINT savepoint_name;
Exemplo
Exemplo
Fim!

Mais conteúdo relacionado

Mais procurados

Integração de ferramentas de código aberto (java, pentaho e android) e mapas,...
Integração de ferramentas de código aberto (java, pentaho e android) e mapas,...Integração de ferramentas de código aberto (java, pentaho e android) e mapas,...
Integração de ferramentas de código aberto (java, pentaho e android) e mapas,...Caio Moreno
 
codigos de detecao e correcao de erros_manuela
codigos de detecao e correcao de erros_manuelacodigos de detecao e correcao de erros_manuela
codigos de detecao e correcao de erros_manuelaChristian-life Cl
 
블록 체인 기술 원리, 이용 현황, 전망과 활용 분야.
블록 체인 기술 원리,  이용 현황, 전망과 활용 분야. 블록 체인 기술 원리,  이용 현황, 전망과 활용 분야.
블록 체인 기술 원리, 이용 현황, 전망과 활용 분야. JaeGon Lim
 
블록체인의 본질과 동작 원리
블록체인의 본질과 동작 원리블록체인의 본질과 동작 원리
블록체인의 본질과 동작 원리Seungjoo Kim
 
مدل دستیابی به بانکداری باز در ایران
مدل دستیابی به بانکداری باز در ایرانمدل دستیابی به بانکداری باز در ایران
مدل دستیابی به بانکداری باز در ایرانNader Heydari
 
Modelo dimensional071009
Modelo dimensional071009Modelo dimensional071009
Modelo dimensional071009Valldo
 
Blockchain 101 - public, tokenized blockchains
Blockchain 101 - public, tokenized blockchainsBlockchain 101 - public, tokenized blockchains
Blockchain 101 - public, tokenized blockchainsBrett Colbert
 
비트코인으로 이해하는 블록체인 기술
비트코인으로 이해하는 블록체인 기술비트코인으로 이해하는 블록체인 기술
비트코인으로 이해하는 블록체인 기술Seong-Bok Lee
 
Modelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de softwareModelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de softwareFrancilvio Roberto Alff
 
Institutional DeFi Architecture
Institutional DeFi ArchitectureInstitutional DeFi Architecture
Institutional DeFi ArchitectureFloyd DCosta
 
Introdução a Banco de Dados (Parte 1)
Introdução a Banco de Dados (Parte 1)Introdução a Banco de Dados (Parte 1)
Introdução a Banco de Dados (Parte 1)Mario Sergio
 
Protocolo MQTT - Redes de Computadores
Protocolo MQTT - Redes de Computadores Protocolo MQTT - Redes de Computadores
Protocolo MQTT - Redes de Computadores Maurício Moreira Neto
 
Teste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e ValidaçãoTeste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e ValidaçãoJoeldson Costa Damasceno
 

Mais procurados (20)

Integração de ferramentas de código aberto (java, pentaho e android) e mapas,...
Integração de ferramentas de código aberto (java, pentaho e android) e mapas,...Integração de ferramentas de código aberto (java, pentaho e android) e mapas,...
Integração de ferramentas de código aberto (java, pentaho e android) e mapas,...
 
Sistemas supervisórios (SCADA Systems)
Sistemas supervisórios (SCADA Systems)Sistemas supervisórios (SCADA Systems)
Sistemas supervisórios (SCADA Systems)
 
codigos de detecao e correcao de erros_manuela
codigos de detecao e correcao de erros_manuelacodigos de detecao e correcao de erros_manuela
codigos de detecao e correcao de erros_manuela
 
블록 체인 기술 원리, 이용 현황, 전망과 활용 분야.
블록 체인 기술 원리,  이용 현황, 전망과 활용 분야. 블록 체인 기술 원리,  이용 현황, 전망과 활용 분야.
블록 체인 기술 원리, 이용 현황, 전망과 활용 분야.
 
Sql comandos agregacao
Sql comandos agregacaoSql comandos agregacao
Sql comandos agregacao
 
Modelo osi visão geral
Modelo osi   visão geralModelo osi   visão geral
Modelo osi visão geral
 
블록체인의 본질과 동작 원리
블록체인의 본질과 동작 원리블록체인의 본질과 동작 원리
블록체인의 본질과 동작 원리
 
مدل دستیابی به بانکداری باز در ایران
مدل دستیابی به بانکداری باز در ایرانمدل دستیابی به بانکداری باز در ایران
مدل دستیابی به بانکداری باز در ایران
 
Modelo dimensional071009
Modelo dimensional071009Modelo dimensional071009
Modelo dimensional071009
 
Blockchain 101 - public, tokenized blockchains
Blockchain 101 - public, tokenized blockchainsBlockchain 101 - public, tokenized blockchains
Blockchain 101 - public, tokenized blockchains
 
비트코인으로 이해하는 블록체인 기술
비트코인으로 이해하는 블록체인 기술비트코인으로 이해하는 블록체인 기술
비트코인으로 이해하는 블록체인 기술
 
Fundamentos de arquitetura Web
Fundamentos de arquitetura WebFundamentos de arquitetura Web
Fundamentos de arquitetura Web
 
Modelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de softwareModelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de software
 
Institutional DeFi Architecture
Institutional DeFi ArchitectureInstitutional DeFi Architecture
Institutional DeFi Architecture
 
DeFi PPT.pptx
DeFi PPT.pptxDeFi PPT.pptx
DeFi PPT.pptx
 
Introdução a Banco de Dados (Parte 1)
Introdução a Banco de Dados (Parte 1)Introdução a Banco de Dados (Parte 1)
Introdução a Banco de Dados (Parte 1)
 
Protocolo MQTT - Redes de Computadores
Protocolo MQTT - Redes de Computadores Protocolo MQTT - Redes de Computadores
Protocolo MQTT - Redes de Computadores
 
Smart Contract Security
Smart Contract SecuritySmart Contract Security
Smart Contract Security
 
Teste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e ValidaçãoTeste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e Validação
 
Modelo OSI
Modelo OSIModelo OSI
Modelo OSI
 

Destaque

Banco de Dados II Aula 12 - Gerenciamento de transação (controle de concorrên...
Banco de Dados II Aula 12 - Gerenciamento de transação (controle de concorrên...Banco de Dados II Aula 12 - Gerenciamento de transação (controle de concorrên...
Banco de Dados II Aula 12 - Gerenciamento de transação (controle de concorrên...Leinylson Fontinele
 
Introducao Base Dados I
Introducao Base Dados IIntroducao Base Dados I
Introducao Base Dados Iguest3118b2
 
Mecanismo de falhas
Mecanismo de falhasMecanismo de falhas
Mecanismo de falhassm_carvalho
 
Conceitos e arquitetura do sistema de banco de dados
Conceitos e arquitetura do sistema de banco de dadosConceitos e arquitetura do sistema de banco de dados
Conceitos e arquitetura do sistema de banco de dadosElaine Cecília Gatto
 
Banco de Dados - Transações e Controle de Concorrência
Banco de Dados - Transações e Controle de ConcorrênciaBanco de Dados - Transações e Controle de Concorrência
Banco de Dados - Transações e Controle de ConcorrênciaJuliano Padilha
 
Oralidade e Linguagem Visual na Comunicação Científico-JufídicaÍ: Técnicas p...
Oralidade e Linguagem Visual na Comunicação Científico-JufídicaÍ:  Técnicas p...Oralidade e Linguagem Visual na Comunicação Científico-JufídicaÍ:  Técnicas p...
Oralidade e Linguagem Visual na Comunicação Científico-JufídicaÍ: Técnicas p...Alejandro Knaesel Arrabal
 

Destaque (6)

Banco de Dados II Aula 12 - Gerenciamento de transação (controle de concorrên...
Banco de Dados II Aula 12 - Gerenciamento de transação (controle de concorrên...Banco de Dados II Aula 12 - Gerenciamento de transação (controle de concorrên...
Banco de Dados II Aula 12 - Gerenciamento de transação (controle de concorrên...
 
Introducao Base Dados I
Introducao Base Dados IIntroducao Base Dados I
Introducao Base Dados I
 
Mecanismo de falhas
Mecanismo de falhasMecanismo de falhas
Mecanismo de falhas
 
Conceitos e arquitetura do sistema de banco de dados
Conceitos e arquitetura do sistema de banco de dadosConceitos e arquitetura do sistema de banco de dados
Conceitos e arquitetura do sistema de banco de dados
 
Banco de Dados - Transações e Controle de Concorrência
Banco de Dados - Transações e Controle de ConcorrênciaBanco de Dados - Transações e Controle de Concorrência
Banco de Dados - Transações e Controle de Concorrência
 
Oralidade e Linguagem Visual na Comunicação Científico-JufídicaÍ: Técnicas p...
Oralidade e Linguagem Visual na Comunicação Científico-JufídicaÍ:  Técnicas p...Oralidade e Linguagem Visual na Comunicação Científico-JufídicaÍ:  Técnicas p...
Oralidade e Linguagem Visual na Comunicação Científico-JufídicaÍ: Técnicas p...
 

Semelhante a UNIFAL - MySQL Transações - 5.0/5.6

Java memory model primary ref. - faq
Java memory model   primary ref. - faqJava memory model   primary ref. - faq
Java memory model primary ref. - faqPedro De Almeida
 
SQL Server 2014 New Feature - Delayed Transaction Durability
SQL Server 2014 New Feature - Delayed Transaction DurabilitySQL Server 2014 New Feature - Delayed Transaction Durability
SQL Server 2014 New Feature - Delayed Transaction DurabilityEdvaldo Castro
 
Gerência de Transações Distribuídas de Consultas
Gerência de Transações Distribuídas de ConsultasGerência de Transações Distribuídas de Consultas
Gerência de Transações Distribuídas de ConsultasWendel Moreira
 
Sqlite - Introdução
Sqlite - IntroduçãoSqlite - Introdução
Sqlite - IntroduçãoJoao Johanes
 
NoSQL, Base VS ACID e Teorema CAP
NoSQL, Base VS ACID e Teorema CAPNoSQL, Base VS ACID e Teorema CAP
NoSQL, Base VS ACID e Teorema CAPAricelio Souza
 
Confiabilidade de pacotes no SSIS
Confiabilidade de pacotes no SSISConfiabilidade de pacotes no SSIS
Confiabilidade de pacotes no SSISLuciano Moreira
 
Isolamento e mvcc
Isolamento e mvccIsolamento e mvcc
Isolamento e mvccLocaweb
 
Sistemas Distribuídos - Replicação de Banco de Dados
Sistemas Distribuídos - Replicação de Banco de DadosSistemas Distribuídos - Replicação de Banco de Dados
Sistemas Distribuídos - Replicação de Banco de DadosValdir Junior
 
UNIFAL - MySQL Logs - 5.0/5.6
UNIFAL - MySQL Logs - 5.0/5.6UNIFAL - MySQL Logs - 5.0/5.6
UNIFAL - MySQL Logs - 5.0/5.6Wagner Bianchi
 
Scale out database apps através de galera cluster e maria db
Scale out database apps através de galera cluster e maria dbScale out database apps através de galera cluster e maria db
Scale out database apps através de galera cluster e maria dbFrancisco Gonçalves
 

Semelhante a UNIFAL - MySQL Transações - 5.0/5.6 (20)

Java memory model primary ref. - faq
Java memory model   primary ref. - faqJava memory model   primary ref. - faq
Java memory model primary ref. - faq
 
Banco de Dados 2: Controle de Concorrência
Banco de Dados 2: Controle de ConcorrênciaBanco de Dados 2: Controle de Concorrência
Banco de Dados 2: Controle de Concorrência
 
Monolith - An epic journey
Monolith - An epic journeyMonolith - An epic journey
Monolith - An epic journey
 
DB2 Express-C
DB2 Express-CDB2 Express-C
DB2 Express-C
 
SQL Server 2014 New Feature - Delayed Transaction Durability
SQL Server 2014 New Feature - Delayed Transaction DurabilitySQL Server 2014 New Feature - Delayed Transaction Durability
SQL Server 2014 New Feature - Delayed Transaction Durability
 
Gerência de Transações Distribuídas de Consultas
Gerência de Transações Distribuídas de ConsultasGerência de Transações Distribuídas de Consultas
Gerência de Transações Distribuídas de Consultas
 
Sqlite
Sqlite Sqlite
Sqlite
 
Sqlite - Introdução
Sqlite - IntroduçãoSqlite - Introdução
Sqlite - Introdução
 
NoSQL, Base VS ACID e Teorema CAP
NoSQL, Base VS ACID e Teorema CAPNoSQL, Base VS ACID e Teorema CAP
NoSQL, Base VS ACID e Teorema CAP
 
Confiabilidade de pacotes no SSIS
Confiabilidade de pacotes no SSISConfiabilidade de pacotes no SSIS
Confiabilidade de pacotes no SSIS
 
CURSO JAVA 01
CURSO JAVA 01CURSO JAVA 01
CURSO JAVA 01
 
Isolamento e mvcc
Isolamento e mvccIsolamento e mvcc
Isolamento e mvcc
 
Sistemas Distribuídos - Replicação de Banco de Dados
Sistemas Distribuídos - Replicação de Banco de DadosSistemas Distribuídos - Replicação de Banco de Dados
Sistemas Distribuídos - Replicação de Banco de Dados
 
Java13
Java13Java13
Java13
 
UNIFAL - MySQL Logs - 5.0/5.6
UNIFAL - MySQL Logs - 5.0/5.6UNIFAL - MySQL Logs - 5.0/5.6
UNIFAL - MySQL Logs - 5.0/5.6
 
Scale out database apps através de galera cluster e maria db
Scale out database apps através de galera cluster e maria dbScale out database apps através de galera cluster e maria db
Scale out database apps através de galera cluster e maria db
 
No sql std
No sql stdNo sql std
No sql std
 
Postgre sql
Postgre sqlPostgre sql
Postgre sql
 
Bancos de dados NoSQL: uma visão geral
Bancos de dados NoSQL: uma visão geralBancos de dados NoSQL: uma visão geral
Bancos de dados NoSQL: uma visão geral
 
Apostila sql
Apostila sqlApostila sql
Apostila sql
 

Mais de Wagner Bianchi

Migrations from PLSQL and Transact-SQL - m18
Migrations from PLSQL and Transact-SQL - m18Migrations from PLSQL and Transact-SQL - m18
Migrations from PLSQL and Transact-SQL - m18Wagner Bianchi
 
Maxscale switchover, failover, and auto rejoin
Maxscale switchover, failover, and auto rejoinMaxscale switchover, failover, and auto rejoin
Maxscale switchover, failover, and auto rejoinWagner Bianchi
 
Meetup São Paulo, Maxscale Implementação e Casos de Uso
Meetup São Paulo, Maxscale Implementação e Casos de UsoMeetup São Paulo, Maxscale Implementação e Casos de Uso
Meetup São Paulo, Maxscale Implementação e Casos de UsoWagner Bianchi
 
Escalando o ambiente com MariaDB Cluster (Portuguese Edition)
Escalando o ambiente com MariaDB Cluster (Portuguese Edition)Escalando o ambiente com MariaDB Cluster (Portuguese Edition)
Escalando o ambiente com MariaDB Cluster (Portuguese Edition)Wagner Bianchi
 
NY Meetup: Scaling MariaDB with Maxscale
NY Meetup: Scaling MariaDB with MaxscaleNY Meetup: Scaling MariaDB with Maxscale
NY Meetup: Scaling MariaDB with MaxscaleWagner Bianchi
 
Webinar: MariaDB Provides the Solution to Ease Multi-Source Replication
Webinar: MariaDB Provides the Solution to Ease Multi-Source ReplicationWebinar: MariaDB Provides the Solution to Ease Multi-Source Replication
Webinar: MariaDB Provides the Solution to Ease Multi-Source ReplicationWagner Bianchi
 
MySQL Multi-Source Replication for PL2016
MySQL Multi-Source Replication for PL2016MySQL Multi-Source Replication for PL2016
MySQL Multi-Source Replication for PL2016Wagner Bianchi
 
MySQL 5.7 Multi-Source Replication
MySQL 5.7 Multi-Source ReplicationMySQL 5.7 Multi-Source Replication
MySQL 5.7 Multi-Source ReplicationWagner Bianchi
 
UNIFAL - MySQL 5.6 - Replicação
UNIFAL - MySQL 5.6 - ReplicaçãoUNIFAL - MySQL 5.6 - Replicação
UNIFAL - MySQL 5.6 - ReplicaçãoWagner Bianchi
 
UNIFAL - MySQL Storage Engine - 5.0/5.6
UNIFAL - MySQL Storage Engine - 5.0/5.6UNIFAL - MySQL Storage Engine - 5.0/5.6
UNIFAL - MySQL Storage Engine - 5.0/5.6Wagner Bianchi
 
UNIFAL - MySQL Views - 5.0/5.6
UNIFAL - MySQL Views - 5.0/5.6UNIFAL - MySQL Views - 5.0/5.6
UNIFAL - MySQL Views - 5.0/5.6Wagner Bianchi
 
UNIFAL - MySQL Triggers - 5.0/5.6
UNIFAL - MySQL Triggers - 5.0/5.6UNIFAL - MySQL Triggers - 5.0/5.6
UNIFAL - MySQL Triggers - 5.0/5.6Wagner Bianchi
 
UNIFAL - MySQL Stored Routines - 5.0/5.6
UNIFAL - MySQL Stored Routines - 5.0/5.6UNIFAL - MySQL Stored Routines - 5.0/5.6
UNIFAL - MySQL Stored Routines - 5.0/5.6Wagner Bianchi
 
UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6
UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6
UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6Wagner Bianchi
 
UNIFAL - MySQL & Vagrant (iniciando os trabalhos)
UNIFAL - MySQL & Vagrant (iniciando os trabalhos)UNIFAL - MySQL & Vagrant (iniciando os trabalhos)
UNIFAL - MySQL & Vagrant (iniciando os trabalhos)Wagner Bianchi
 
Wagner Bianchi, GUOB 2014 MySQL Cluster 7.3
Wagner Bianchi, GUOB 2014 MySQL Cluster 7.3Wagner Bianchi, GUOB 2014 MySQL Cluster 7.3
Wagner Bianchi, GUOB 2014 MySQL Cluster 7.3Wagner Bianchi
 
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6Introdução ao MySQL 5.6
Introdução ao MySQL 5.6Wagner Bianchi
 
InnoDB Plugin - II Fórum da Comunidade MySQL
InnoDB Plugin - II Fórum da Comunidade MySQLInnoDB Plugin - II Fórum da Comunidade MySQL
InnoDB Plugin - II Fórum da Comunidade MySQLWagner Bianchi
 
MySQL Cluster Product Overview
MySQL Cluster Product OverviewMySQL Cluster Product Overview
MySQL Cluster Product OverviewWagner Bianchi
 

Mais de Wagner Bianchi (20)

Migrations from PLSQL and Transact-SQL - m18
Migrations from PLSQL and Transact-SQL - m18Migrations from PLSQL and Transact-SQL - m18
Migrations from PLSQL and Transact-SQL - m18
 
Maxscale switchover, failover, and auto rejoin
Maxscale switchover, failover, and auto rejoinMaxscale switchover, failover, and auto rejoin
Maxscale switchover, failover, and auto rejoin
 
Meetup São Paulo, Maxscale Implementação e Casos de Uso
Meetup São Paulo, Maxscale Implementação e Casos de UsoMeetup São Paulo, Maxscale Implementação e Casos de Uso
Meetup São Paulo, Maxscale Implementação e Casos de Uso
 
Escalando o ambiente com MariaDB Cluster (Portuguese Edition)
Escalando o ambiente com MariaDB Cluster (Portuguese Edition)Escalando o ambiente com MariaDB Cluster (Portuguese Edition)
Escalando o ambiente com MariaDB Cluster (Portuguese Edition)
 
NY Meetup: Scaling MariaDB with Maxscale
NY Meetup: Scaling MariaDB with MaxscaleNY Meetup: Scaling MariaDB with Maxscale
NY Meetup: Scaling MariaDB with Maxscale
 
Webinar: MariaDB Provides the Solution to Ease Multi-Source Replication
Webinar: MariaDB Provides the Solution to Ease Multi-Source ReplicationWebinar: MariaDB Provides the Solution to Ease Multi-Source Replication
Webinar: MariaDB Provides the Solution to Ease Multi-Source Replication
 
MySQL Multi-Source Replication for PL2016
MySQL Multi-Source Replication for PL2016MySQL Multi-Source Replication for PL2016
MySQL Multi-Source Replication for PL2016
 
MySQL 5.7 Multi-Source Replication
MySQL 5.7 Multi-Source ReplicationMySQL 5.7 Multi-Source Replication
MySQL 5.7 Multi-Source Replication
 
UNIFAL - MySQL 5.6 - Replicação
UNIFAL - MySQL 5.6 - ReplicaçãoUNIFAL - MySQL 5.6 - Replicação
UNIFAL - MySQL 5.6 - Replicação
 
UNIFAL - MySQL Storage Engine - 5.0/5.6
UNIFAL - MySQL Storage Engine - 5.0/5.6UNIFAL - MySQL Storage Engine - 5.0/5.6
UNIFAL - MySQL Storage Engine - 5.0/5.6
 
UNIFAL - MySQL Views - 5.0/5.6
UNIFAL - MySQL Views - 5.0/5.6UNIFAL - MySQL Views - 5.0/5.6
UNIFAL - MySQL Views - 5.0/5.6
 
UNIFAL - MySQL Triggers - 5.0/5.6
UNIFAL - MySQL Triggers - 5.0/5.6UNIFAL - MySQL Triggers - 5.0/5.6
UNIFAL - MySQL Triggers - 5.0/5.6
 
UNIFAL - MySQL Stored Routines - 5.0/5.6
UNIFAL - MySQL Stored Routines - 5.0/5.6UNIFAL - MySQL Stored Routines - 5.0/5.6
UNIFAL - MySQL Stored Routines - 5.0/5.6
 
UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6
UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6
UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6
 
UNIFAL - MySQL & Vagrant (iniciando os trabalhos)
UNIFAL - MySQL & Vagrant (iniciando os trabalhos)UNIFAL - MySQL & Vagrant (iniciando os trabalhos)
UNIFAL - MySQL & Vagrant (iniciando os trabalhos)
 
Wagner Bianchi, GUOB 2014 MySQL Cluster 7.3
Wagner Bianchi, GUOB 2014 MySQL Cluster 7.3Wagner Bianchi, GUOB 2014 MySQL Cluster 7.3
Wagner Bianchi, GUOB 2014 MySQL Cluster 7.3
 
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
 
Mysql for IBMers
Mysql for IBMersMysql for IBMers
Mysql for IBMers
 
InnoDB Plugin - II Fórum da Comunidade MySQL
InnoDB Plugin - II Fórum da Comunidade MySQLInnoDB Plugin - II Fórum da Comunidade MySQL
InnoDB Plugin - II Fórum da Comunidade MySQL
 
MySQL Cluster Product Overview
MySQL Cluster Product OverviewMySQL Cluster Product Overview
MySQL Cluster Product Overview
 

UNIFAL - MySQL Transações - 5.0/5.6

  • 1. TRANSAÇÕES Wagner Bianchi Certified MySQL 5.0 Developer Certified MySQL 5.0 Database Administrator Certified MySQL Cluster Database Administrator
  • 2. Artigo recomendado: • http://imasters.uol.com.br/artigo/7755/mysql/stored_procedures_-_transacoes/
  • 3. Transações " “Transação é uma unidade lógica de trabalho, envolvendo diversas operações de bancos dados” – (C. J. Date, Cambridge - UK 1964); " Os conceitos existentes de transação de bancos de dados relacionais ou objeto-relacionais estão diretamente ligados aos matemáticos, autores e pesquisadores Christopher J. Date e Edgard Frank Codd, ambos autores de vários livros e também do modelo relacional, introduzido por Codd ainda quando trabalhavam juntos na IBM, em 1983 no SGBD chamado SQL/DS; " Com maior abrangência, podemos definir transações em bancos de dados com um aglomerado sequencial de comandos SQL, executando várias consultas de transformação de dados, produzindo algum resultado, podendo alterar ou não o estado atual dos dados do banco de dados;
  • 4. Transações " Transações podem ser implícitas ou explícitas; " Todo comando DML (Data Manipulation Language) ou DDL (Data Manipulation Language) que é enviado ao SGBD é considerado uma transação implícita, ou seja, após dispararmos o comando, via terminal, por exemplo, o SGBD se encarregará de enviar um COMMIT ao final; " ALTER TABLE, BEGIN, CREATE INDEX, DROP INDEX, DROP TABLE, LOAD MASTER DATA, LOCK TABLES, LOAD DATA INFILE, RENAME TABLE, START TRANSACTION, UNLOCK TABLES sofrem um COMMIT implícito; " Temos uma variável de ambiente do MySQL que controla tal feature, denominada autocommit, que pode ser acessada através do seguinte comando: SELECT @@autocommit;
  • 5. Transações " O padrão da variável autocommit é 1, implicando diretamente no comportamento do SGBD para cada comando que é enviado pelo usuário de um banco de dados; " Após cada comando, a declaração COMMIT é enviada automaticamente para tornar permanente no log aquela transação – (mais à frente veremos com detalhes as declarações COMMIT e ROLLBACK e seus significados);
  • 6. Transações " Caso configuremos o autocommit como 0, teremos uma nova situação em que, caso não enviemos um COMMIT explicitamente após a uma transação implícita, a última transação não se tornará permanente no arquivo de dados, pois, o SGBD considerará como uma transação ainda aberta; " O log binário do MySQL é responsável por registrar as transações em grupos – caso uma transações tenha mais de um comando -, ou uma a uma caso a transação seja formada de apenas um comando. Para que as modificações se tornem permanentes no arquivo de dados, o log ainda deve resgistrar um COMMIT ao final de cada transação;
  • 7. Transações " O MySQL trabalha intensamente com o log-bin para checar quais dados devem ser gravados nas páginas de dados em disco ou se devem sofrer um ROLLBACK; com a limpeza do log e retirada dele as transações que não sofreram um COMMIT; " ROLLBACK é o contrário de COMMIT; " O MySQL checa a última transação ou grupos de transação que não receberam um COMMIT ao final e desfaz todas as modificações o banco de dados; BD START TRANSACTION; -- comando 1 SELECT @A:=SUM(salary) FROM table1 WHERE type=1; -- comando 2 UPDATE table2 SET summary=@A WHERE type=1; COMMIT; LOG BIN COMMIT
  • 8. Transações " Normalmente, as transações não só no MySQL, mas, na maioria dos SGBD’s relacionais são inciadas em meio à procedimentos armazenados; " Antes de iniciarmos de fato com os comandos de transação, temos que saber o que é o bloqueio de tabelas, as chamadas contenções; " O MySQL controla as contenções de tabelas de várias formas. Na verdade, esse controle é intrinseco ao Storage Engine utilizado pelas tabelas que se encontram em meio a uma transação, seja ela explícita ou implícita; " Quando estamos utilizado uma tabela, controlada pelo Storage Engine MyISAM, o bloqueio de tabelas será realizado em nível de tabela, ou seja, a tabela será travada por completo, enquanto a transação atual não terminar. Tabelas MyISAM somente suportam transações implícitas;
  • 9. Transações " Tabelas InnoDB tem bloqueio em nível de linha, ou seja, caso uma dada transação A esteja atualizando uma linha de uma tabela, a transação B terá que esperar até que A termine suas atividades para atualizar esta mesma linha, nessa mesma tabela; " O Storage Engine mais utilizado para ambientes que precisam de suporte à transação é o INNODB. Este Engine tem suporte à transações e contempla em 100% o modelo de transação ACID, que é um acrônimo para as propriedades: – Atomicidade; – Consistência; – Isolamento; – Durabilidade; " Leitura complementar: http://databases.about.com/od/specificproducts/a/acid.htm
  • 10. Transações - ACID " Atomicidade; " Toda transação deverá ser atômica, o verdadeiro “tudo ou nada”. Um exemplo interessante seria uma transferência bancária entre contas de mesmo banco. Imagine que subtraímos o saldo da conta A e checamos a existência da conta B. Caso a conta B exista, somamos o saldo à conta B; " Agora imaginemos que, ao checar a existência da conta B, esta conta não existe! A quantia subtraída da conta A não poderá simplesmente desaparecer, afinal, esse “dinheiro” tem dono; " O comando seguinte falhará e haverá um ROLLBACK, restaurando o valor antes subtraído à conta de origem, no caso, a conta A;
  • 11. Transações - ACID " Consistência: " Transações devem preservar a consistência do banco de dados, ou seja, transforma um estado consistente do banco de dados em outro estado consistente, sem necessariamente preservar o estado de consistência em todos os pontos intermediários; " O ponto de inconsistência plena do estado do banco de dados no exemplo da transferência bancária é exatamente no momento em que o saldo é subtraído de uma conta para ser adicionado na outra; " O banco é coloca em um estado sem consistência e depois retorna ao estado consistente diferente do de antes – leve em consideração o conceito já visto de transação;
  • 12. Transações - ACID " Isolamento: " Transações são isoladas umas das outras, de acordo com o nível de isolamento definido no momento em que a transação se inicia, que no MySQL são: REPEATABLE READ, READ COMMITED, READ UNCOMMITED e SERIALIZABLE; " Também chamados de TRANSACTION ISOLATION LEVEL e derivados dos termos do SQL:ANSI 1992, o INNODB no MySQL tem como padrão em todas as instalações o level REPEATABLE READ; " Podemos checar qual é o ISOLATION LEVEL atual com o seguinte comando: SHOW VARIABLES LIKE ‘%isolation%’;
  • 13. Transações - ACID " Isolamento: " REPEATABLE READ: (SNAPSHOT) terá a mesma leitura de um dado mesmo que um SELECT se repita, provendo sempre o mesmo resultado para diferentes execuções da mesma consulta. Nesse nível de isolamento, se a leitura não fosse repetida, teríamos os conhecidos phantoms, que acontecem entre um SELECT e ou outro, com uma atualização dos dados nesse espaço de tempo. Isso não é possível com o Storage Engine INNODB; " READ COMMITED: permite que a transação atual leia/manipule somente os dados já permanetes ou “comitados” por outras transações. Dados já atualizados mas que ainda não receberam um COMMIT explícito ainda não serão vistos, sendo estes invisíveis. Como esse nível de isaolamento permite “non-repeatable reads”, phantoms podem ocorrer.
  • 14. Transações - ACID " Isolamento: " READ UNCOMMITED: permite que uma transação veja manipulações não “comitadas” de outras transações, o que pode acarretar problemas com leituras sujas – dirty reads - e non-repeatable reads que colaboram para o aparecimento dos phantoms; " SERIALIZABLE: esse nível de isolamento, isola completamente uma transação de outra, ou seja, enquanto uma trabalha a outra aguarda para poder iniciar o seu trabalho. Similar ao nível READ REPEATABLE, diferindo que as linhas selecionadas por uma transação não são nem lidas e nem atualizadas por outra transação, “uma de cada vez”;
  • 15. Transações - ACID " Os níveis de isolamento são importantes no contexto em que existam muitas transações acontecendo ao mesmo tempo. Os níveis trabalham os bloqueios nas linhas das tabelas ou nas tabelas para que não haja falta de consistência após o término de uma transação; " As leituras consistentes são possíveis devido ao multiversionamento feito pelo INNODB. Uma linhas poderá ter várias versões sendo trabalhadas em meio às transações, de acordo com o nível de isolamento selecionado; " Tal versionamento de linhas em meio à transações, que ocorre de acordo com o nível de isolamento configurado é chamado de MVCC (Multi-versioning Concurrency Control); " Para que esse versionamento acontece de forma consistente, ele depende também do log de undo (localizado junto com os arquivos de Tablespace);
  • 16. Transações - ACID " Para alterar o nível de isolamento atual do MySQL, podemos editar o arquivo de opções (my.ini/my.cnf), e dentro do agrupamento [mysqld], colocamos a seguinte linha (reinicie o MySQL após esta alteração): [mysqld] transaction-isolation=READ-COMMITED " Podemos alterar a partir do Terminal ou Prompt de comando, através do seguinte comando, já logado no MySQL, através do mysql client: SET GLOBAL TRANSACTION ISOLATION LEVEL isolation_level; SET SESSION TRANSACTION ISOLATION LEVEL isolation_level; SET TRANSACTION ISOLATION LEVEL isolation_level;
  • 17. Transação - ACID " Somente usuários do banco de dados com privilégio SUPER poderão utilizar o primeiro comando, que seta o nível de isolamento de forma global; " Qualquer usuário poderá utilizar a segunda e a terceira declaração, pois, só afetarão a sessão corrente. Após a desconexão o comando será desconsiderado;
  • 18. DEADLOCKS " Deadlocks são um problema clássico em banco de dados transacionais, mas eles não são perigosos, a menos que eles sejam tão freqüentes que você não possa executar certas transações; " Normalmente você tem que escrever suas aplicações de forma que elas sempre estejam preparada a reexecutar uma transação se for feito um ROLLBACK por causa de deadlocks; " Uma dada transação A precisa atualizar uma linha da tabela Y, mas a transação para soltar o bloqueio desta linha, precisa adquirir um bloquieo da linha que A está lendo neste momento; " O INNODB tem mecanismos que detectam os possíveis deadlocks e faz um ROLLBACK nas transações. Caso ocorra, a menor transação – aquela que movimenta menor número de bytes – sofrerá um ROLLBACK;
  • 19. Exercícios " Com base no assunto apresentado até aqui, resolva a LISTA 2 de exercícios, valendo pontos.
  • 20. Principais Comandos " Quando se deseja trabalhar com o transações em bancos de dados contidos no MySQL, a primeira coisa que temos a fazer é entender o funcionamento do modo autocommit, que como já vimos, por padrão é configurado como 1, ou seja, ON; " Quando autocommit está setado como 1, um COMMIT implícito é disparado ao fim de cada comando. Quando setado como 0, desabilitado, todos os comandos seguintes a esta configuração são encarados pelo SGBD como parte de uma transação, for a os comandos que recebem um COMMIT implícito mesmo com autocommit desabilitado; " O comando START TRANSACTION, utilizado para iniciar uma transação, ignora o modo autocommit. Quando um procedimento dispara a declaração, autocommit é setado automaticamente para 0, sendo necessário um COMMIT ou ROLLBACK para finalizar a transação;
  • 21. Principais Comandos " Os comandos para se iniciar uma transação e que anulam o modo autocommit são: – START TRANSACTION; – BEGIN WORK; – BEGIN (diferente de BEGIN … END); " Caso se inicie uma transação com qualquer das declarações acima e autocommit esteja habilitado, ele é implicitamente desabilitado até que a transação finalize; " Podemos então, iniciar transações de duas maneiras no MySQL, desabilitando explicitamente o autocommit mode ou utilizando das declarações supracitadas para desabilitar automaticamente antes de rodar os comandos;
  • 22. Principais Comandos " Iniciando uma transação, desabilitando autocommit mode explicitamente: SET AUTOCOMMIT=0; …declarações da transação 1… [COMMIT | ROLLBACK]; SET AUTOCOMMIT=0; … declarações da transação 2 … [COMMIT | ROLLBACK]; " Demonstrações: – Iniciar uma transação desabilitando autocommit explicitamente; – Utilizar COMMIT e ROLLBACK;
  • 23. Principais Comandos " Iniciando transações e suspendendo automaticamente o modo autocommit: [START TRANSACTION | BEGIN WORK | BEGIN] …declarações da transação 1… [COMMIT | ROLLBACK] [START TRANSACTION | BEGIN WORK | BEGIN] …declarações da transação 2… [COMMIT | ROLLBACK] " Demonstrações: – Iniciar uma transação desabilitando autocommit implicitamente; – Utilizar COMMIT e ROLLBACK;
  • 24. Principais Comandos " Para se ter um ROLLBACK das transações de modo funcional e efetivo, sem correr riscos, é fundamental garantir que o modo autocommit esteja desabilitado explicita ou implicitamente; " Somente para salientar, ROLLBACK é retornar todas as modificações feitas em dados por uma trasação caso haja algum erro para completar esta de forma integral; " Podemos digitar o comando START TRANSACTION e iniciar nossa transação comando a comando e depois entrar com um ROLLBACK. Veremos que tudo aquilo que fizemos comando a comando foi retornado ao momento anterior; " O MySQL utiliza o log-binário e o tablespace do INNODB, que contém o segmento de rollback e informações de undo log para retornar ao momento anterior, transações que falharam;
  • 25. Principais Comandos " É permitido fazermos um ROLLBACK parcial da transação, tanto explicitamente quanto em meio à procedimentos armazenados – Stored Procedures; " Utilizamos os SAVEPOINT’s para demarcar os pontos em meio às transações. Utilizando um SAVEPOINT nomeado, podemos solicitar que o SGBD faça um ROLLBACK até determinado ponto da transação, não voltando necessariamente tudo o que foi feito; " Múltiplos SAVEPOINT’s podem ser criados em meio à transações. Para retornar uma transação até um determinado ponto onde foi detado um SAVEPOINT, utilizamos a seguinte sintaxe: ROLLBACK TO SAVEPOINT savepoint_name;
  • 28. Fim!