Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Artigo SQL Magazine 71 - Trabalhando com Transações no PostgreSQL
O artigo trata da definição do conceito de transações, estados das transações e como o PostgreSQL trabalha com esse conceito. Além disso, demonstra através de um estudo de caso prático como lidar com os principais comandos de transação no PostgreSQL.
SQL Magazine 71
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 71
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 71
PostgreSQL
Trabalhando com Transações no PostgreSQL
De que trata o artigo:
O artigo trata da definição do conceito de transações, estados das transações e como o PostgreSQL trabalha com esse conceito. Além disso, demonstra através de um estudo de caso prático como lidar com os principais comandos de transação no PostgreSQL.
Para que serve:
O conteúdo do artigo traz os benefícios de se implementar operações concorrentes no SGBD para que as mesmas não sejam conflitantes e deixem o banco de dados em um estado consistente.
Em que situação o tema é útil:
Essa estratégia é útil quando está sendo desenvolvida qualquer aplicação que tenha acesso a banco de dados e que se necessite prover meios para trabalhar com simultaneidade no acesso aos dados e controle da consistência dos mesmos.
O termo transação refere-se a uma coleção de operações que formam uma única unidade de trabalho lógica. Por exemplo, a transferência de dinheiro de uma conta para outra é uma transação consistindo de duas atualizações, uma para cada conta.
Uma transação é uma unidade de execução do programa que acessa e possivelmente atualiza vários itens de dados. Para garantir a integridade dos dados, é necessário que o SGBD mantenha as seguintes propriedades das transações: atomicidade, consistência, isolamento e durabilidade.
• Atomicidade: uma transação é uma unidade atômica de processamento; ou ela será executada em sua totalidade ou não será de modo nenhum.
• Consistência: uma transação deve ser preservadora de consistência se sua execução completa fizer o banco de dados passar de um estado consistente para outro também consistente.
• Isolamento: uma transação deve ser executada como se estivesse isolada das demais. Isto é, a execução de uma transação não deve sofrer interferência de quaisquer outras transações concorrentes.
• Durabilidade: as mudanças aplicadas ao banco de dados por uma transação efetivada devem persistir no banco de dados. Essas mudanças não devem ser perdidas em razão de uma falha.
Essas propriedades normalmente são conhecidas como propriedades ACID. Esse acrônimo é derivado da primeira letra de cada uma das quatro propriedades.
Quando se trabalham com transações, é necessário que se faça pelo menos duas ressalvas. A primeira é que em certas situações é interessante se agregar vários comandos como sendo integrantes de uma mesma transação, como, por exemplo, em uma transferência bancária que envolve a retirada de dinheiro de uma conta e o acréscimo em outra como se fosse apenas uma única operação lógica. A segunda ressalva é que em outras situações se faz necessário sacrificar ou flexibilizar as características ACID em virtude da necessidade de maior desempenho.
Estados de uma Transação
Na ausência de falhas, todas as transações são completadas com sucesso. Porém, uma transação nem sempre pode completar sua execução com sucesso. Caso isso ocorra, essa transação é considerada abortada.
Se tivermos que garantir a propriedade de atomicidade, uma transação abortada não pode ter efeito sobre o estado do banco de dados. Assim, qualquer mudança que a transação abortada tenha feito no banco de dados deve ser desfeita. Quando as mudanças causadas por uma transação abortada tiverem sido desfeitas, dizemos que a transação foi revertida (rolled back).
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Trabalhando com Transações no PostgreSQL
De que trata o artigo:
O artigo trata da definição do conceito de transações, estados das transações e como o PostgreSQL trabalha com esse conceito. Além disso, demonstra através de um estudo de caso prático como lidar com os principais comandos de transação no PostgreSQL.
Para que serve:
O conteúdo do artigo traz os benefícios de se implementar operações concorrentes no SGBD para que as mesmas não sejam conflitantes e deixem o banco de dados em um estado consistente.
Em que situação o tema é útil:
Essa estratégia é útil quando está sendo desenvolvida qualquer aplicação que tenha acesso a banco de dados e que se necessite prover meios para trabalhar com simultaneidade no acesso aos dados e controle da consistência dos mesmos.
O termo transação refere-se a uma coleção de operações que formam uma única unidade de trabalho lógica. Por exemplo, a transferência de dinheiro de uma conta para outra é uma transação consistindo de duas atualizações, uma para cada conta.
Uma transação é uma unidade de execução do programa que acessa e possivelmente atualiza vários itens de dados. Para garantir a integridade dos dados, é necessário que o SGBD mantenha as seguintes propriedades das transações: atomicidade, consistência, isolamento e durabilidade.
• Atomicidade: uma transação é uma unidade atômica de processamento; ou ela será executada em sua totalidade ou não será de modo nenhum.
• Consistência: uma transação deve ser preservadora de consistência se sua execução completa fizer o banco de dados passar de um estado consistente para outro também consistente.
• Isolamento: uma transação deve ser executada como se estivesse isolada das demais. Isto é, a execução de uma transação não deve sofrer interferência de quaisquer outras transações concorrentes.
• Durabilidade: as mudanças aplicadas ao banco de dados por uma transação efetivada devem persistir no banco de dados. Essas mudanças não devem ser perdidas em razão de uma falha.
Essas propriedades normalmente são conhecidas como propriedades ACID. Esse acrônimo é derivado da primeira letra de cada uma das quatro propriedades.
Quando se trabalham com transações, é necessário que se faça pelo menos duas ressalvas. A primeira é que em certas situações é interessante se agregar vários comandos como sendo integrantes de uma mesma transação, como, por exemplo, em uma transferência bancária que envolve a retirada de dinheiro de uma conta e o acréscimo em outra como se fosse apenas uma única operação lógica. A segunda ressalva é que em outras situações se faz necessário sacrificar ou flexibilizar as características ACID em virtude da necessidade de maior desempenho.
Estados de uma Transação
Na ausência de falhas, todas as transações são completadas com sucesso. Porém, uma transação nem sempre pode completar sua execução com sucesso. Caso isso ocorra, essa transação é considerada abortada.
Se tivermos que garantir a propriedade de atomicidade, uma transação abortada não pode ter efeito sobre o estado do banco de dados. Assim, qualquer mudança que a transação abortada tenha feito no banco de dados deve ser desfeita. Quando as mudanças causadas por uma transação abortada tiverem sido desfeitas, dizemos que a transação foi revertida (rolled back).
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Artigo SQL Magazine 52 - Estudos de Caso de Projeto de Bancos de Dados para Contas a Pagar e Receber
Artigo da SQL Magazine 26 - SQL Server 2000 fail-over clustering Parte II: Instalação e Configuração
Artigo SQL Magazine 23 - Influenciando o otimizador de consulta baseado em custo do Oracle - Parte 3
Artigo SQL Magazine 20 - Influenciando o otimizador de consulta baseadoem custo do Oracle - Parte II
Você está em:
canal SQL
Publicidade
Willamys Rangel Nunes De Sousa
Space do autor
Atua no ramo de tecnologia da informação e banco de dados há mais de 5 anos. Atualmente é professor do Instituto Federal de Educação, Ciência e Tecnologia do Piauí (IFPI). Possui especialização em Banco de Dados e é graduado em tecnologia da Informação.
Space do autor
1
0
