Some notes on DB2 for z/OS
来源:互联网 发布:linux操作系统第二版 编辑:程序博客网 时间:2024/05/18 00:34
DB2 Isolation Levels
A speculation on the internal mechanisms of the 4 types of Isolation to get a better understanding of the notion of isolation levels and different sorts of anomalies.
The following guess is mainly based common sence and a general idea of locking and concurrency.
a) To protect the system against non-repeatable read, we may need to lock the specific rows to prevent it from being accessible from the operator when one user is accessing it and even during the period between the user's sequential operations (multiple-phased user access).
b) To keep away phantom row anomalies, we may need to lock the entire table to prevent it from being accessible from the operator when one user is accessing it and even during the period between the user's sequential operations. (multiple phased user access).
* Of cause for both (a) and (b) they might also be implemented by preserving a separate temporary table for the user to look through during his session of using the service.
c) To handle dirty read anomalies, we may need to lock the the entire table when one operator is working on the table. or prevent the uncommitted data being presented in the database and shown to the user.
d) To handle lost update anomalies, we'd better grant to only one user at a time the access to the database.
As we can see, generally speaking, the levels of restriction of the above four protection are sorted from lowest to highest as follows,
c)
d)
a)
b)
The last two are concerning multiple-phased user access, they lock up when the user (customer)'s session is active and keep the server side away from accessing the database. And the requirement of isolation is so unreasonably high for (b) that even such high level protection as RS is unable to fulfill it.
1. Repeatable Read (RR) which is able to prevent all anomalies
2. Read Stability (RS) which is able to prevent all anomalies except for phantom row anomalies (b)
3. Cursor Stabiltiy (CS) able to prevent all but (b) and (a)
4. Uncommited read (UR) unable to prevent any anomalies aforementioned except for (d). The strange thing is that (c) is not protected against, that is probably due to the mutual-exclusion between customers being provided while that between customer and server is not.
- Some notes on DB2 for z/OS
- DB2 SQL PL : Essential Guide for DB2 UDB on Linux, UNIX, Windows, i5/OS, and z/OS, Second Edition
- Notes for Installing FFmpeg on Linux OS
- DB2 for z/OS V8 迁移到 DB2 9
- Some notes for Java
- DB2 for z/OS REORG INDEX 学习笔记(1)
- Oracle 到 DB2 Version 9.1 for z/OS 迁移揭密!
- Some Miscellaneous Notes on Android
- Some notes on shared libraries with ld
- DB2(R) for z/OS(R) Version 8 DBA Certification Guide
- 我常用的DB2 for z/OS DBA面试题及答案
- Some Notes
- Some notes
- Some Notes
- Some Notes
- Benefit of Clergy: Some Notes on Salvador Dali
- Some Notes on Windows 7 Professional Computer Install Linux Mint
- english joke,and some notes for english study
- Solaris 10 开启root用户ftp权限
- 我开通了博客,换音大家来做客!
- 数学那点事……
- Linux查看系统当前用户命令
- WAS和IHS配置SSL 加密传输
- Some notes on DB2 for z/OS
- JS农历日历
- Flex 计时器 Timer
- 360&腾讯
- 增加Distinct后查询效率反而提高(转载)
- Introduction to Using PBS
- vfp运行应用软件时出现错误提示:路径或文件名找不到
- javascript常用小技巧
- Program received signal SIGPIPE, Broken pipe