SQL e Transações
•Als PPTX, PDF herunterladen•
0 gefällt mir•667 views
Aspectos fundamentais no tuning de SQL. As transações em bases de dados relacionais. As propriedades ACID.
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Ähnlich wie SQL e Transações
Ähnlich wie SQL e Transações (20)
Mehr von Carlos Pampulim Caldeira
Mehr von Carlos Pampulim Caldeira (20)
SQL e Transações
- 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. Desenho da Aplicação • SQL e desenvolvimento da aplicação • Transacções • Locking
- 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. • 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. Etapas no SQL Erudição do SQL Optimizador de queries do SGBDR
- 7. Tipos de SQL • Planeado ou Ad hoc • Embebido ou stand-alone • Dinâmico ou estático
- 8. SQL: integração Embeber numa linguagem COBOL, C, Java, Visual Basic ODBC ou JDBC
- 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. Os dois objectivos da gestão de dados Objectivos Criar Disponibilidade Pesquisar Alterar Protecção Integridade Qualidade Confidencialidade
- 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. Integridade da BD • Memória organizacional • Prevenção (backup/restore) • Assegurar a confidencialidade • Qualidade dos dados: • Regras de integridade • Concorrência no acesso
- 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. Gestão de Transacções ACTIVA ROLLEDBACK COMMITTED INSUCESSO CONFIRMAÇÂO PARCIAL Início da Transacção COMMIT Interrupção
- 15. Propriedades ACID • Atomicidade • Consistência • Isolamento • Durabilidade Transacção
- 16. Transacção
- 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. 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. Transacção • Duração da transacção locks shared resources
- 21. Locking
- 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. Tipos de Locks • Exclusive / Write lock – INSERT, UPDATE e DELETE [Xlocks] • Shared / Read lock – SELECT [Slocks]
- 24. Deadlock Problemas: alterar a granularidade de modo a que menos dados sejam bloqueados em cada lock
- 25. Deadlock
- 26. Nível isolamento lock curto até lock demorado Isolamento: define o comportamento do mecanismo de locking numa transacção.
- 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. • 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. 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. 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. Video | SQL Rewriting SQL queries for Performance in 9 minutes
- 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
Hinweis der Redaktion
- 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.