SQL e Transações

515 visualizações

Publicada em

Aspectos fundamentais no tuning de SQL. As transações em bases de dados relacionais. As propriedades ACID.

Publicada em: Software
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
515
No SlideShare
0
A partir de incorporações
0
Número de incorporações
24
Ações
Compartilhamentos
0
Downloads
8
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Application Design
  • Numa base de dados devem ser drasticamente limitadas o número de linguagens utilizadas.
  • One of the first rules to learn as a database developer is to let SQL, rather than the program logic, do the work. It is much better to filter out unwanted data at the DBMS level than to do so within the program. You'll achieve better efficiency by avoiding the actual movement of data between the DBMS and the program. For example, it is better to add more WHERE clauses to SQL SELECT statements than to simply select all rows and filter the data programmatically.

    To use another example, consider the cost of a multitable join statement. It will be easier to tune, say four-table join for efficiency than four independent SQL SELECT statements that are filtered and joined using application logic. Of course, this assumes an optimal physical database and the possibility of having to tweak that design (such as by adding indexes).

    The more work the DBMS can do to filter data, the greater the efficiency should be, because less data will need to be moved between the DBMS and the application program as it runs.
  • O papel da gestão de transacções é o de assegurar que as transacções são gravadas correctamente na base de dados. O gestor de transacções é o componente do SGBDR que processa esses movimentos de dados. Uma transacção é um conjunto de acções ou movimentos de dados considerados de modo a que sejam todos gravados na base de dados ou rejeitados na sua totalidade. Uma transacção é uma unidade atómica de trabalho em que todos os seus elementos têm que ser processados, caso contrário a base de dados ficará inconsistente. O pagamento de uma propina escolar, por exemplo, é uma transacção que se subdivide, em grandes linhas, em dois elementos: a actualização do saldo da conta de propinas da escola, e a actualização dos montantes pago por esse aluno. A base de dados ficaria inconsistente se se alterasse um único desses elementos: ou se faz tudo ou não se faz nada.

    O princípio da atomicidade transaccional exige que todo o conteúdo transaccional seja processado segundo a regra do “tudo-ou-nada”, e que cada conjunto de transacções seja transmissível em série / realizável (serializable). Quando uma transacção é interrompida antes do seu termo o gestor de transacções têm que repor a base de dados ao estado em que se encontrava, antes do início da operação, desfazendo todas as acções entretanto efectuadas. As transacções, por uma questão de eficiência e de eficácia, não devem durar mais do que o necessário de modo a assegurar a integridade do sistema. No caso da liquidação de uma propina o pagamento do aluno e o crédito na contabilidade da escola é a unidade mínima de trabalho necessária para manter as contas em dia.

    A transmissão em série numa transacção refere-se ao seu efeito no estado da base de dados.
  • O papel da gestão de transacções é o de assegurar que as transacções são gravadas correctamente na base de dados. O gestor de transacções é o componente do SGBDR que processa esses movimentos de dados. Uma transacção é um conjunto de acções ou movimentos de dados considerados de modo a que sejam todos gravados na base de dados ou rejeitados na sua totalidade. Uma transacção é uma unidade atómica de trabalho em que todos os seus elementos têm que ser processados, caso contrário a base de dados ficará inconsistente. O pagamento de uma propina escolar, por exemplo, é uma transacção que se subdivide, em grandes linhas, em dois elementos: a actualização do saldo da conta de propinas da escola, e a actualização dos montantes pago por esse aluno. A base de dados ficaria inconsistente se se alterasse um único desses elementos: ou se faz tudo ou não se faz nada.

    O princípio da atomicidade transaccional exige que todo o conteúdo transaccional seja processado segundo a regra do “tudo-ou-nada”, e que cada conjunto de transacções seja transmissível em série / realizável (serializable). Quando uma transacção é interrompida antes do seu termo o gestor de transacções têm que repor a base de dados ao estado em que se encontrava, antes do início da operação, desfazendo todas as acções entretanto efectuadas. As transacções, por uma questão de eficiência e de eficácia, não devem durar mais do que o necessário de modo a assegurar a integridade do sistema. No caso da liquidação de uma propina o pagamento do aluno e o crédito na contabilidade da escola é a unidade mínima de trabalho necessária para manter as contas em dia.

    A transmissão em série numa transacção refere-se ao seu efeito no estado da base de dados.
  • Atomicidade: unidade transaccional mais pequena e indivisível; realiza-se tudo ou não se realiza nada. Exemplo: numa caixa multibanco não se procede a um débito sem simultaneamente se realizar um crédito.

    Consistência: o estado dos dados é verificado antes e depois de terminar a transacção. Exemplo: Se é feito o cálculo do saldo de uma conta antes da transacção então a mesma operação é obrigatoriamente feita após a transacção.

    Isolamento: as transacções não interferem entre si. Exemplo: o marido só vê a actualização do saldo da conta após a sua esposa terminar uma determinada transacção num POS.

    Durabilidade: qualquer alteração proveniente de uma transacção é definitiva.
  • Row-Level Locking (Oracle)

    Both read committed and serializable transactions use row-level locking, and both will wait if they try to change a row updated by an uncommitted concurrent transaction. The second transaction that tries to update a given row waits for the other transaction to commit or roll back and release its lock. If that other transaction rolls back, the waiting transaction, regardless of its isolation mode, can proceed to change the previously locked row as if the other transaction had not existed.

    However, if the other blocking transaction commits and releases its locks, a read committed transaction proceeds with its intended update. A serializable transaction, however, fails with the error "Cannot serialize access", because the other transaction has committed a change that was made since the serializable transaction began.
  • Por exemplo: da página (page) para a linha (row).
  • Por exemplo: da página (page) para a linha (row).
  • Uncommitted: refere-se unicamente a aspectos de leitura (read); também conhecido como “dirty read” (lê lixo) dado que pode estar a ler dados que ainda são virtuais por não terem sido alvo de commit; Utilizar em análises de dados; data warehousing.

    Committed: só lê dados que já tenham sido objecto de um commit; este mecanismo também é conhecido por “cursor stability”. Thus, a transaction that runs a given query twice can experience both nonrepeatable read and phantoms.

    Repeatable: o mesmo dado pode ser acedido múltiplas vezes durante uma transacção. Implica um maior nível de integridade do que o método anterior.

    Serializable: este é o método com o maior nível de integridade. Impede a ocorrência de fantasmas, i.e., um cursor contém um determinado grupo de dados que é sujeito a uma operação, ao mesmo tempo que um outro cursor modifica dados que caem dentro dos valores do primeiro cursor fazendo commit antes da primeira transacção terminar, quando esta acaba os resultados já são incoerentes dado que não levam em linha de conta as alterações provocadas pela segunda transacção.

  • Uncommitted: refere-se unicamente a aspectos de leitura (read); também conhecido como “dirty read” (lê lixo) dado que pode estar a ler dados que ainda são virtuais por não terem sido alvo de commit; Utilizar em análises de dados; data warehousing.

    Committed: só lê dados que já tenham sido objecto de um commit; este mecanismo também é conhecido por “cursor stability”.

    Repeatable: o mesmo dado pode ser acedido múltiplas vezes durante uma transacção. Implica um maior nível de integridade do que o método anterior.

    Serializable: este é o método com o maior nível de integridade. Impede a ocorrência de fantasmas, i.e., um cursor contém um determinado grupo de dados que é sujeito a uma operação, ao mesmo tempo que um outro cursor modifica dados que caem dentro dos valores do primeiro cursor fazendo commit antes da primeira transacção terminar, quando esta acaba os resultados já são incoerentes dado que não levam em linha de conta as alterações provocadas pela segunda transacção.

  • Dirty read: leitura suja
    Nonrepeatable read: leitura não repetível
    Phantom read: leitura fantasma
  • Granularidade: page, row.

    Parametrização: O agrupamento de INSERT, UPADTE e DELETE e o lançamento destas acções no momento final de uma transacção melhora o acesso concorrencial dado que os recursos ficam bloqueados por períodos de tempo mais curtos.

    Isolamento (isolation): define o comportamento do mecanismo de locking numa transacção.
  • SQL e Transações

    1. 1. Desenho da Aplicação Administração de Bases de Dados SQL e Transações Carlos Pampulim Caldeira www.di.uevora.pt/~ccaldeira www.ecologiadosdados.com/ www.linkedin.com/in/carlospampulimcaldeira
    2. 2. Desenho da Aplicação • SQL e desenvolvimento da aplicação • Transacções • Locking
    3. 3. Análise proactiva da performance O DBA que resolva depois da aplicação estar em produção SQL e desenvolvimento da aplicação
    4. 4. • SQL, standard para acesso à informação • Alto nível de abstracção • Quais são os dados pretendidos • Não especifica como os ir buscar • Access paths, caminhos de acesso aos dados • Forma desestruturada de escrita • Operações a nível de conjuntos de dados SQL e desenvolvimento da aplicação
    5. 5. Etapas no SQL Erudição do SQL Optimizador de queries do SGBDR
    6. 6. SQL: flexibilidade
    7. 7. Tipos de SQL • Planeado ou Ad hoc • Embebido ou stand-alone • Dinâmico ou estático
    8. 8. SQL: integração Embeber numa linguagem COBOL, C, Java, Visual Basic ODBC ou JDBC
    9. 9. Deixar que o SQL faça a tarefa Minimização do I/O entre SGBDR e a aplicação SELECT * versus filtrar no programa Optimizar join versus SELECT’s individuais
    10. 10. Os dois objectivos da gestão de dados Objectivos Criar Disponibilidade Pesquisar Alterar Protecção Integridade Qualidade Confidencialidade
    11. 11. Estratégias manutenção da integridade • Legais: leis, regras, regulações (ou não…) • Administrativas: políticas de backup • Técnicas: regras de validação (checks)
    12. 12. Integridade da BD • Memória organizacional • Prevenção (backup/restore) • Assegurar a confidencialidade • Qualidade dos dados: • Regras de integridade • Concorrência no acesso
    13. 13. • Unidade atómica de trabalho – consistência e recuperação da base de dados • COMMIT, grava a transacção • ROLLBACK, estado anterior [antes do início] Gestão de Transacções
    14. 14. Gestão de Transacções ACTIVA ROLLEDBACK COMMITTED INSUCESSO CONFIRMAÇÂO PARCIAL Início da Transacção COMMIT Interrupção
    15. 15. Propriedades ACID • Atomicidade • Consistência • Isolamento • Durabilidade Transacção
    16. 16. Transacção
    17. 17. Controlo de alterações concorrentes Tempo Linha na tabelaAcção P1 Ana recebe papeis inscrição de mais 5 alunos na Tx P2 Ana lê Tx Tx 20 Tx 20 Turma Nº Inscritos P3 Adão retira 3 alunos de Tx P4 Adão lê Tx Tx 20 P5 Ana processa (20+5) P6 Ana actualiza Tx 25 P7 Adão processa (20-3) P8 Adão actualiza Tx 17
    18. 18. Controlo de alterações concorrentes Tempo Linha na tabelaAcção P1 Ana recebe papeis inscrição de mais 5 alunos na Tx P2 Ana lê Tx Tx 20 Tx 20 Turma Nº Inscritos P3 Adão retira 3 alunos de Tx P4 Adão lê Tx Tx 20 P5 Ana processa (20+5) P6 Ana actualiza Tx 25 P8 Adão processa (25-3) P9 Adão actualiza Tx 22 NEGADO P7 Adão lê Tx Tx 25
    19. 19. Transacção • Duração da transacção locks shared resources
    20. 20. Locking Coluna Linha Página (ou bloco) Tabela Espaço de tabelas Base de dados
    21. 21. Locking
    22. 22. Locking • LOCK TABLE aluno IN SHARE MODE; /* Other Transactions have to wait */ • COMMIT; /* This releases the lock */ • LOCK TABLE aluno IN ROW SHARE MODE; /* Set lock to default */
    23. 23. Tipos de Locks • Exclusive / Write lock – INSERT, UPDATE e DELETE [Xlocks] • Shared / Read lock – SELECT [Slocks]
    24. 24. Deadlock Problemas: alterar a granularidade de modo a que menos dados sejam bloqueados em cada lock
    25. 25. Deadlock
    26. 26. Nível isolamento lock curto até lock demorado Isolamento: define o comportamento do mecanismo de locking numa transacção.
    27. 27. • Read Uncommited (leitura descomprometida) – >disponibilidade; > concorrência • Read Commited: trans. só lê dados commited (leitura confirmada) • Read Repeatable: trans. repete a mesma leitura (leitura estável) • Serializable: evita a ocorrência de fantasmas (leitura em bloco) Nível isolamento
    28. 28. • Nível da transacção: SET TRANSACTION ISOLATION LEVEL READ COMMITTED; [default] • Nível da sessão: ALTER SESSION SET SOLATION_LEVEL = SERIALIZABLE; Nível isolamento - Oracle
    29. 29. O que se pretende evitar • Dirty reads: a T1 lê dados escritos por outra T2 que ainda não foram committed • Nonrepeatable reads: a T1 relê dados que foram previamente lidos e vê que outra T2 os modificou ou apagou • Phantom reads: a T1 reexecuta uma query que devolve um conjunto sujeito a uma condição e vê que a T2 inseriu linhas adicionais que satisfazem a condição
    30. 30. Tabela isolation level Nível de isolamento Dirty Read Nonrepeatable Read Phantom Read Read uncommitted Possível Possível Possível Read committed Impossível Possível Possível Repeatable read Impossível Impossível Possível Serializable Impossível Impossível Impossível
    31. 31. Video | SQL Rewriting SQL queries for Performance in 9 minutes
    32. 32. Sumário Cada SGBDR tem o seu próprio mecanismo de gestão de locks: granularidade do locking nível de isolamento parametrização de timeouts e deadlocks

    ×