好热，好热

周末就要有空调的房间出租了

我和同学赶紧在空调房间好好享受了一下夏日的清凉

好舒服啊

后悔没有选择住这个房间了

周日房客来了，还不错，应该是还好相处的了

不过就是有点不方便了

不能光着上身在家了

呜呜

 

 

 

 忙活了两年，终于到了出成功的时候了

 

很开心，因为晚上大部分的操作，都是我做的

 

很开心，我们项目组经过努力，共同把这个项目做下来了

 

很开心，很启动，领导宣布切换演练成功的哪一刻

 

8个小时后，出结果

 

期待中。。。

 

一定成功

 

 

 一年多没回北京了，终于抽出了时间，回北京一次

 

亲切又陌生着，到处都在修路，但是不能阻止我对这座城市的喜爱

 

见到了不少好朋友，和耀在一起最痛快，每次都是大醉而归，呵呵

 

同学们都忙自己的事业，也没什么时间聚聚。聚在一起的几个兄弟，都玩得不够尽兴。呵呵，真是有点怀疑了，是不是必须是我来请客，大家才能兴奋起来呢。不过，我现在可不打算做这个光掏钱的生意了。

 

师妹够意思，都从很远的地方跑过来看我

 

在公司，和老板谈了一个多小时，感觉收获很多。也许这些不是从经济上的，但是我现在要的，是那个可以让我发挥的空间

 

谢谢ju，和她在一起很开心很放松，她也从money上帮助了我，从心底有我

 

谢谢lin，也许，我们将来不一定能够在一起，但是你千里跑来，和我聚了几天，这个让我值得回忆

 

谢谢yu，这哥们够意思，说到做到

 

当然，现在最要谢的是耀了，如果这次没有他的帮助，我真的是逼上梁山了

 

呵呵，我整理的好乱的，也不知道看我的blog的人能否能读懂我内心的真实想法

 

别人对我好，我会对他更好。别人对我坏，我会对他更坏

 

呵呵

 

1．Oracle通过具有意向锁的多粒度封锁机制进行并发控制，保证数据的一致性。其DML锁（数据锁）分为两个层次（粒度）：即表级和行级。通常的DML操作在表级获得的只是意向锁（RS或RX），其真正的封锁粒度还是在行级；DB2也是通过具有意向锁的多粒度封锁机制进行并发控制，保证数据的一致性。其DML锁（数据锁）分为两个层次（粒度）：即表级和行级。通常的DML操作在表级获得的只是意向锁（IS，SIX或IX），其真正的封锁粒度也是在行级；另外，在Oracle数据库中，单纯地读数据（SELECT）并不加锁，这些都提高了系统的并发程度，Oracle强调的是能够"读"到数据，并且能够快速的进行数据读取。而DB2的锁强调的是"读一致性"，进行读数据(SELECT)时会根据不同的隔离级别（RR,RS,CS）而分别加S,IS,IS锁，只有在使用UR隔离级别时才不加锁。从而保证不同应用程序和用户读取的数据是一致的。

2. 在支持高并发度的同时，DB2和Oracle对锁的操纵机制有所不同：Oracle利用意向锁及数据行上加锁标志位等设计技巧，减小了Oracle维护行级锁的开销，使其在数据库并发控制方面有着一定的优势。而DB2中对每个锁会在锁的内存（locklist）中申请分配一定字节的内存空间，具体是X锁64字节内存，S锁32字节内存（注：DB2 V8之前是X锁72字节内存而S锁36字节内存）。

3. Oracle数据库中不存在锁升级，而DB2数据库中当数据库表中行级锁的使用超过locklist*maxlocks会发生锁升级。

4. 在Oracle中当一个session对表进行insert，update，delete时候，另外一个session仍然可以从Orace回滚段或者还原表空间中读取该表的前映象（before image）; 而在DB2中当一个session对表进行insert，update，delete时候，另外一个session仍然在读取该表数据时候会处于lock wait状态，除非使用UR隔离级别可以读取第一个session的未提交的值；所以Oracle同一时刻不同的session有读不一致的现象，而DB2在同一时刻所有的session都是"读一致"的。

 

还有篇文章《A Technical Discussion of Multi Version Read Consistency》，贴出来慢慢看吧。

Introduction
There has been a lot of debate in recent years regarding the various RDBMS
implementations of concurrency models. Oracle claims that because readers
don't block writers and writers don't block readers that they have a better
solution for concurrency and that applications run better on Oracle1. The
reality is that with Oracle, as with any other database, you design and code
your application with an understanding of the underlying isolation and
concurrency model. DB2 implements the ANSI standard isolation levels
(RR, RS, CS and UR). No other database vendor has implemented Oracle's
Multi Version Read Consistency isolation nor has it proven to be a
performance advantage in industry standard, ISV or real life customer
benchmarks. Simply stated; Oracle is taking an old architectural decision
and trying to showcase it as a differentiator, when in fact it is simply a
concurrency model that developers must code around and one that adds an
extra burden of management on the DBA as described below.

How Multi Version Read Consistency Works
In Oracle, when a block of data is updated, the old version of the block is
stored in what is known as a Rollback Segment. Rollback segments are now
called Undo Tablespaces in Oracle 9i but the two names refer to virtually the
same entity with slightly different management characteristics so for the
purposes of this paper we will refer to Rollback Segments or RBS. Note that
these rollback segments are not for crash recovery but rather they are for
transactional purposes. This means that, not only is the old block of data
stored in the rollback segment, but the undo and redo images of the changed
data are also stored in the redo logs for recovery purposes.
Each Oracle block (known as a page in DB2) has what is called a System
Change Number (SCN) associated with it. Logically you can think of this as
a timestamp for the data page to indicate the version of the page. So when a
row on a page is updated, the current version of the block with the current
SCN is copied into the rollback segment, then the data page is updated and
given a new SCN (which is stored in the block header).

With Oracle, the data you see in any query is the data as it existed at the start
of that query. This does not conform to any ANSI standard isolation level,
nor is it the way other RDBMSs work. To accomplish this, each statement
picks up the SCN from the time the statement started (i.e. it picks up the
data timestamp of the statement start time). Then as it reads data blocks, it
checks to see if the data block has a higher (newer) SCN than the statement
SCN. If the SCN of the block is higher, then Oracle knows that this block
must have been updated since this statement first started so the transaction
then goes to the rollback segment to try to find an older version of that block
to satisfy the query. But it's a bit more onerous than it sounds. The way this
works is as follows:
1. statement A starts and is assigned SCN 105
2. the statement starts a table scan of table X (for example)
3. for every block that is read in from disk into the bufferpool, the SCN of
that block is checked
4. if the block SCN is greater than SCN 105 then the block is duplicated
(cloned) inside the bufferpool
5. lets assume that the block SCN is 108
6. the statement then sidetracks into the rollback segmentlooking for the
last transaction to update this page. The transaction that updated this
block to 108 is undone on the clone block using the information found in
the rollback segment. So the block now has SCN 107 (for example).
7. continue cloning the block and applying the rollback segment images as
in step 6 until you have a block that has an SCN < 105 (your
transactions SCN)
8. then continue to read the next block from the table into the bufferpool
(and go to step 6 as needed)
So in essence, any statement that is trying to read a page that either has been
updated or is currently in the process of being updated, must go to the
rollback segment to get an older version of the data so that it does not wait on
the updaters lock. It is true that a pure reader will not wait on a writer but it
is reading old, and possibly out of date data, performing additional I/O, filling
the bufferpool with non-reusable pages, and using up extra CPU intructions.
Even committed transactions are not seen by the reader if the reading
statement started before the updating statement.

How DB2 handles Locking and Concurrency
DB2 supports the following standard isolation levels:
Repeatable Read
Repeatable read (RR) locks all the rows an application references within a
unit of work. Using repeatable read, a SELECT statement issued by an
application twice within the same unit of work in which the cursor was
opened, gives the same result each time. With repeatable read, lost updates,
access to uncommitted data, and phantom rows are not possible.
Read Stability
Read stability (RS) locks only those rows that an application retrieves within a
unit of work. It ensures that any qualifying row read during a unit of work is
not changed by other application processes until the unit of work completes,
and that any row changed by another application process is not read until the
change is committed by that process. That is, "nonrepeatable read" behavior
is not possible.
Cursor Stability
Cursor stability (CS) locks any row accessed by a transaction of an application
while the cursor is positioned on the row. This lock remains in effect until the
next row is fetched or the transaction is terminated. However, if any data on a
row is changed, the lock must be held until the change is committed to the
database.
No other applications can update or delete a row that a cursor stability
application has retrieved while any updatable cursor is positioned on the row.
Cursor stability applications cannot see uncommitted changes of other
applications.
Uncommitted Read
Uncommitted read (UR) allows an application to access uncommitted changes
of other transactions. The application also does not lock other applications
out of the row it is reading, unless the other application attempts to drop or
alter the table. Uncommitted read works differently for read-only and
updatable cursors.

Read-only cursors can access most uncommitted changes of other
transactions. However, tables, views, and indexes that are being created or
dropped by other transactions are not available while the transaction is
processing. Any other changes by other transactions can be read before they
are committed or rolled back.
Issues with Multi Version Read Consistency
There are several issues with multi version read consistency
Management of rollback segments.
Rollback segments are simply disk space set aside to store old images of data.
They are physically a set of operating system files of a predefined size that
work in a circular fashion. That is, old data is put into rbs 1 followed by rbs 2
and so on. When all of the rollback segments are full, the process wraps back
around to the first segment. Undo Tablespaces in Oracle 9i work in a similar
fashion except that the information is stored in an Oracle managed tablespace
which is made up of operating system data files so the process is almost
identical. There is a DBA management burden to configure and maintain
rollback segments. How big should your rollback segments be? What if you
have a single transaction that does not fit into your rollback segments? What
happens if you run out of space?
Well running out of space is not a problem...Oracle simply cancels your
transaction! Yes that's right, if there is not enough rollback segment space for
your transaction, the transaction fails. Similarly what happens if the rollback
segment has filled up and wrapped on itself, overwriting an old image that
you need (i.e. your statement is long running and you need an image that is
older but no longer in the rollback segment). That read only transaction also
fails with an ORA-1555 "Snapshot too old". Ask any Oracle DBA what ORA-
1555 means and they will be all too aware of it. Many DBAs have spent
significant amounts of time trying to manage the size of their rollback
segments or undo tablespaces to avoid this problem. This is not an issue
with DB2 as there are no rollback segments to worry about so you would
never get a Snapshot Too Old error.

As shown above, transactions that need older versions of data that are no
longer around can fail with an ORA-1555. To get around this well known
Oracle problem, application developers using Oracle will write their
applications and commit as infrequently as possible. Why? Because
uncommitted changes do not get overwritten in the rollback segments so this
type of application coding attempts to alleviate the ORA-1555 problem.
What you will often find is that if you directly port an Oracle application to
DB2, you will find an excess of locks being held and concurrency will suffer
because the application is not designed to take advantage of the underlying
concurrency model. Similarly if you took a DB2 application and ported it
directly to Oracle, you would find that it may have problems with ORA-1555
because of the frequent commits in the application. Each implementation
does what it is designed to do and it's the application development that either
makes the best use of the technology or runs into issues.
Here is a quote from the Oracle Application Developer’s Guide –
Fundamentals
Long running read-only transactions sometimes receive a
"snapshot too old" error (ORA-01555). Create more, or
larger, rollback segments to avoid this. You can also issue
long-running queries when online transaction processing is
at a minimum, or you can obtain a shared lock on the table
before querying it, preventing any other modifications during
the transaction. 2
Oracle's concurrency model is page based not row based
In Oracle, the SCN is stored in the header of each data block (a.k.a. page).
So if any record on that block is modified, the SCN for that block is updated.
If a transaction is looking for record 5 on block 106, it may have to clone and
reconstruct several different version of block 106 even if record 5 has never
changed. With DB2, the concurrency mechanisms work on the row level so
if one transaction is locking row Y and another transaction wants to look at
row X (even if they are both on the same page), then both transaction would
be able to proceed.

..... 

也许不错，一切的一切，都只能靠我自己了

自从给家里买了套房子后

自己的压力好大

原来以为朋友们如果答应了我的事情

多少也不会放我鸽子

现在倒好，开始都答应得很好

可是到时间了，一问，都没有了

好在有耀，谢谢你，耀

不然我真是会被我认为是最好的朋友们逼得上树了

这次回北京，又只能找耀了

不过也好，认清了很多事情，也终于知道了，什么叫求人不如求己