<![CDATA[随心所欲]]>

<![CDATA[随心所欲]]> http://www.stblog.net/ zh-cn PBlog2 v2.4 随心所欲 http://www.stblog.net/images/logos.gif http://www.stblog.net/ 随心所欲 http://www.stblog.net/article/photo/jinjilake_1.htm <![CDATA[金鸡湖]]> sonic.tang@hotmail.com(Sonic) Mon,26 Jul 2010 22:07:42 +0800 http://www.stblog.net/default.asp?id=474

]]> http://www.stblog.net/article/tech/install_sqlserver2008.htm <![CDATA[轻松安装SQL SERVER 2005 & 2008 & 2008R2]]> sonic.tang@hotmail.com(Sonic) Tue,20 Jul 2010 16:07:57 +0800 http://www.stblog.net/default.asp?id=472
http://technet.microsoft.com/en-us/sqlserver/ff625277.aspx]]> http://www.stblog.net/article/photo/qingdao.htm <![CDATA[又见青岛]]> sonic.tang@hotmail.com(Sonic) Tue,13 Jul 2010 21:39:18 +0800 http://www.stblog.net/default.asp?id=471

]]> http://www.stblog.net/article/write/microsoft.htm <![CDATA[我不是张江男了]]> sonic.tang@hotmail.com(Sonic) Wed,07 Jul 2010 20:31:33 +0800 http://www.stblog.net/default.asp?id=470
HP在张江，MS在闵行，从一个郊区换到另一个郊区，而且郊的更彻底，两家公司各有特色，HP特别是我所在的部门，因为做的是国外的项目，时差问题，所以可以自由支配时间，随便几点上班，随便几点下班，也可以随时在家办公，原则就是把项目最好，部门内部都是些年轻人，很好相处，一起打球，一起玩三国杀，一起喝酒。。。离开HP最舍不得就是那些刚认识的朋友们。。。MS大楼是新盖好的，环境很好，班车路线覆盖整个上海，咖啡牛奶饮料水果点心无限量免费供应，有桌球室，健身房，篮球场，X-BOX，按摩椅等设施，办公电脑都是顶级配置，在职员工的稳定度比较高，同事之间还不大熟悉，所以暂时还没怎么多沟通，感觉都是很好相处的人，希望能够尽快打成一片吧。

从张江搬来闵行，一个人来到一个陌生的环境，独来独往，孤单啊。。。]]> http://www.stblog.net/article/photo/gulangyu.htm <![CDATA[鼓浪屿]]> sonic.tang@hotmail.com(Sonic) Fri,25 Jun 2010 15:17:43 +0800 http://www.stblog.net/default.asp?id=469
第一天就在鼓浪屿的轮渡附近转了转，天气不好也没怎么拍照，坐在海边的椅子上独自发呆，晚上吃了点海鲜就洗洗睡了。

第二天买了套票，先去风琴博物馆，鼓浪屿里面的颇有情调的小路被闷热的天气搞的了无味道，然后去了百鸟园，上到厦门最高点月光岩，可惜天气很差，然后去了菽庄花园，海滩边无聊的抽着烟的时候，突然人品爆发，乌云被吹走，片刻过后蓝天白云，于是顺着环岛路走了四分之一圈，冒着酷热，拍了不少片子，吃了沙茶面之后重新登上月光岩，终于能够拍个全景了。。。还有最后一站皓月园，天色已晚，也没有体力了，回到酒店，洗澡，看球，睡觉。

第三天直奔厦门大学，从侧门进去的，没有被保安拦下，一进门就倾盆大雨，找了个屋檐，为了保护相机，最终还是浑身湿透，阵雨，雨过天晴，不可否认，厦大确实是目前我见过的最美丽的大学了，出了后门就是大海，隐约可以看到台湾金门，沙滩上很多学生穿着学士服合影留念，我租了辆自行车沿着大海骑行1/4圈后，最终实在由于天气太热放弃。。。

在厦门机场候机的时候，居然还看到了凤姐。。。

飞机晚点了半个小时，起飞的时候，看着夜色中的厦门逐渐消失在视野中，一股不舍油然而升，很少会有这样的感觉，不知为何。。。

]]> http://www.stblog.net/article/write/montain_dream.htm <![CDATA[感慨于登山运动]]> sonic.tang@hotmail.com(Sonic) Wed,26 May 2010 23:16:24 +0800 http://www.stblog.net/default.asp?id=468
感慨颇多，却无以用文字阐述，无论如何，愿此次最终留在大山上没能下来的韩昕、李斌、赵亮能够安息，也希望那些疯狂追逐14座8K梦想的山友们在出发前，能够深深的看看你的父母妻儿的眼神，如果有泪光，那么请扔下行囊，让梦想深埋起来吧！

]]> http://www.stblog.net/article/tech/oracle_ddl_lock.htm <![CDATA[Oracle数据一致性之锁机制（三）]]> sonic.tang@hotmail.com(Sonic) Wed,26 May 2010 22:20:49 +0800 http://www.stblog.net/default.asp?id=467
当执行以下语句：AUDIT，NOAUDIT，COMMENT，Create [OR REPLACE] VIEW/ PROCEDURE/PACKAGE/PACKAGE BODY/FUNCTION/ TRIGGER，Create SYNONYM，及 Create TABLE（没有使用 CLUSTER 参数时）时，会产生共享 DDL 锁（share DDL lock），而其他的DDL语句产生的都是排他 DDL 锁（exclusive DDL lock），而解析锁是在 SQL 语句执行的解析阶段（parse phase）获得的，当其他DDL操作造成与此锁产生冲突时候，此锁会被解除，所以称之为可解除的解析锁（breakable parse lock）。

对簇（cluster）执行的 DDL 操作需要获取簇及簇内所有表及物化视图上的排他 DDL 锁（exclusive DDL lock）。对簇内表及物化视图的 DDL 操作需要获取簇上的共享 DDL 锁（share DDL lock），以及表或物化视图上的共享 DDL 锁或排他 DDL 锁。簇上的共享 DDL 锁能够防止操作期间其他 DDL 操作将簇移除。

这些比较难以通过实验来查看，所以了解下概念即可。

闩锁（latche）及内部锁（internal lock）的作用是保护数据库及其内存结构。闩锁（latche）是一种简单的底层串行化机制，用于保护 SGA 内的共享数据结构。内部锁（internal lock）更高层且复杂，分为三类，

数据字典缓存锁（dictionary cache lock）：当用户更新或使用时数据字典缓存内的条目（entry）时获取，作用是确保正在被解析的语句不会看到不一致的对象定义。语句解析结束时释放。
文件及重做日志管理锁：用于保护各种文件，例如，保护控制文件（control file）的锁，确保同一时间只有一个进程能够对其进行修改。还有协调重做日志文件（redo log file）使用与归档的锁。以及数据文件（datafile）锁，实现多实例在共享模式下挂载数据库，或一个实例在排他模式下挂载数据库。
表空间及回滚段锁：用于保护表空间及回滚段（rollback segment）。例如，一个表空间处于联机（online）还是脱机（offline）状态对访问同一数据库的所有实例应该是一致的。回滚段上的锁保证同一时间只有一个实例能够对其执行写操作。

在管理锁时，Oracle 提供了一个 DBMS_LOCK 的 Package，详细可参考：http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_lock.htm#CHDICHDC#CHDICHDC]]> http://www.stblog.net/article/tech/oracle_tm_lock.htm <![CDATA[Oracle数据一致性之锁机制（二）]]> sonic.tang@hotmail.com(Sonic) Mon,24 May 2010 14:53:46 +0800 http://www.stblog.net/default.asp?id=466
表级锁之前的关联可参考下图:

我们可以通过 v$lock, dba_objects 来得知产生锁的 object 是哪个，产生了什么类型的锁，举例如下

复制内容到剪贴板

程序代码

程序代码

SQL> update SONIC_TEST set VALUE='CCCC' where ID=1;

1 row updated

SQL> select l.TYPE,
  2         decode(l.lmode,
  3                0,'None',
  4                1,'Null',
  5                2,'Row-S',
  6                3,'Row-X',
  7                4,'Share',
  8                5,'S/Row-X',
  9                6,'Exclusive',
10                'Unknown') LockMode,
11         decode(l.request,
12                0,'None',
13                1,'Null',
14                2,'Row-S',
15                3,'Row-X',
16                4,'Share',
17                5,'S/Row-X',
18                6,'Exclusive',
19                'Unknown') RequestMode,
20         o.OWNER,
21         o.OBJECT_NAME,
22         o.OBJECT_TYPE
23    from v$lock l, dba_objects o
24   where l.ID1 = o.OBJECT_ID
25     and l.SID = 42;

TYPE LOCKMODE  REQUESTMODE OWNER      OBJECT_NAME     OBJECT_TYPE
---- --------- ----------- ---------- --------------- ------------
TM   Row-X     None        SYSTEM     SONIC_TEST      TABLE

]]> http://www.stblog.net/article/tech/oracle_tx_tm_lock.htm <![CDATA[Oracle数据一致性之锁机制（一）]]> sonic.tang@hotmail.com(Sonic) Thu,20 May 2010 15:44:16 +0800 http://www.stblog.net/default.asp?id=465
排他锁（exclusive lock）模式：能够阻止共享被加锁的资源。对数据进行修改时必须获得此种模式的锁。第一个排他地对资源加锁的事物是唯一可以对此资源进行修改的事物，直至排他锁被释放。
共享锁（share lock）模式：依据操作类型有条件地允许共享被加锁的资源。对数据进行读取的多个用户可共享此数据，这些用户可以对资源加以共享锁，防止其他用户并发地修改此资源（对数据进行修改的用户需要排他锁）。多个事务可以对相同的资源加共享锁。

锁有三种类型：

DML锁（数据锁）：DML锁的作用是保护数据。例如，表级锁（table lock）对整个表加锁，行级锁（row lock）则对选定的数据行加锁。
DDL锁（数据字典锁）：DDL锁的作用是保护方案对象的结构。例如，表及视图的定义。
内部锁（internal lock）及闩锁（latch）：内部锁及闩锁用于保护数据库的内部结构，例如，数据文件。内部锁及闩锁的管理完全由 oracle 自动完成。

继续细化，DML锁分为：

行级锁（TX）：作用是防止两个事务同时修改相同的数据行。当一个事务需要修改一行数据时，就需对此行数据加锁。此为粒度最精细的锁。
表级锁（TM）：作用是对并发的 DDL 操作进行访问控制，例如防止在 DML 语句执行期间相关的表被变更或移除。表级锁（TM）具备一下几种模式：行共享（row share，RS），行排他（row exclusive，RX），共享（share，S），共享行排他（share row exclusive，SRX），及排他（exclusive，X）

我们来做个测试，打开一个Session并且获得此Session ID为38,先执行查询

SQL> select * from SONIC_TEST;

     ID VALUE
------- -----
      1 AAAA
      2 BBBB

事务A开始对第一行update，但是暂不提交

SQL> update SONIC_TEST set VALUE='CCCC' where ID=1;

1 row updated

查看此时生成的锁的情况

SQL> select TYPE,LMODE,REQUEST from v$lock where SID=38;

TYPE      LMODE    REQUEST
---- ---------- ----------
TM            3          0
TX            6          0

发现事务A(Session ID=42)产生了两个锁，类型为 TM 与 TX，然后打开事务B，针对ID=1的行进行操作

SQL> update SONIC_TEST set VALUE='DDDD' where ID=1;

发现此条语句并不执行，查看此Session的状态

SQL> select sid,status,event,state from v$session where SID=42;

       SID STATUS   EVENT                             STATE
---------- -------- --------------------------------- -------------------
        42 ACTIVE   enq: TX - row lock contention     WAITING

看到此事务在等待TX锁，这就是行级锁（TX）的作用，若此时事务B针对ID=2的行进行操作

SQL> update SONIC_TEST set VALUE='CCCC' where ID=2;

1 row updated

可以看到可以成功 update，由此可见，行级锁（TX）只对数据所在行做锁定

再来看一下另外一个表级锁（TM）的作用，同样如果在事务A还没有提交的时候，如果事务B对该表进行DDL操作，比如说drop该表

SQL> drop table SONIC_TEST purge;

drop table SONIC_TEST purge

orA-00054: resource busy and acquire with NOWAIT specified

会报错，提示资源繁忙，这就是表级锁（TM）的作用。]]> http://www.stblog.net/article/tech/data_consistency_isolation.htm <![CDATA[Oracle数据一致性之事务隔离级别]]> sonic.tang@hotmail.com(Sonic) Wed,19 May 2010 23:08:23 +0800 http://www.stblog.net/default.asp?id=464
ANSI/ISO SQL 标准（SQL92）定义了四种事务隔离级别，分别为 Read uncommitted, Read committed, Repeatable read, Serializable，此四种隔离级别是针对多用户模式下出现的三种现象所定义，此三种现象分别为 dirty read, nonrepeatable read, phantom read

dirty read（脏读）是指一个事务读取了被其他事务写入但还未提交的数据。
nonrepeatable read（不可重复读）是指一个事务再次读取其之前曾经读取过的数据时，发现数据已被其他已提交的事务修改或删除。
phantom read（幻想读）是指事务按照之前的条件重新查询时，返回的结果集中包含其他已提交事务插入的满足条件的新数据。

oracle 支持其中两种 Read committed 和 Serializable，并且额外添加一种为 Read only。

Read committed 是 oracle 默认的事务隔离级别，做个测试来看下针对三种现象的处理方式

SQL> create table SONIC_TEST (C1 varchar(5));

Table created

SQL> insert into SONIC_TEST values ('AAAA');

1 row inserted

SQL> commit;

Commit complete

事务A执行查询

SQL> select * from SONIC_TEST;

C1
-----
AAAA

切换事务B执行update但是没有commit

SQL> update SONIC_TEST set C1='BBBB';

1 row updated

回到事务A再次执行查询

SQL> select * from SONIC_TEST;

C1
-----
AAAA

显然事务隔离级别 Read committed 阻止了 dirty read，继续

此时事务B执行commit，然后再回到事务A，进行同样的查询

SQL> select * from SONIC_TEST;

C1
-----
BBBB

这时候数据产生了变化，也就是说 Read committed 没有阻止 nonrepeatable read，继续

事务B中进行一个insert语句

SQL> insert into SONIC_TEST values ('CCCC');

1 row inserted

SQL> commit;

Commit complete

回到事务A再次用同样语句查询

SQL> select * from SONIC_TEST;

C1
-----
BBBB
CCCC

显然 Read committed 也没有阻止 phantom read

-----------------------------------------------------我是分割线----------------------------------

我们继续对事务隔离级别 Serializable 做同样的测试:

将数据恢复到原始状态，并且事务A的隔离级别调整为 Serializable

SQL> truncate table SONIC_TEST;

Table truncated

SQL> insert into SONIC_TEST values ('AAAA');

1 row inserted

SQL> commit;

Commit complete

SQL> alter session set isolation_level=serializable;

Session altered

SQL> select * from SONIC_TEST;

C1
-----
AAAA

切换到事务B,执行update操作但是不执行commit

SQL> update SONIC_TEST set C1='BBBB';

1 row updated

回到事务A，重新查询

SQL> select * from SONIC_TEST;

C1
-----
AAAA

显然事务隔离级别 Serializable 也阻止了 dirty read，继续

此时事务B执行commit，然后再回到事务A，进行同样的查询

SQL> select * from SONIC_TEST;

C1
-----
AAAA

这时候发现虽然事务B中对数据进行了更改，并且commit，但是事务A中读取到的依旧是做修改前的数据，这个表明事务隔离级别 Read committed 阻止了 nonrepeatable read，继续

事务B中进行insert

SQL> insert into SONIC_TEST values ('CCCC');

1 row inserted

SQL> commit;

Commit complete

返回事务A再次查询

SQL> select * from SONIC_TEST;

C1
-----
AAAA

数据依旧没有变化，表明事务隔离级别 Read committed 同样阻止了 phantom read。

结合测试，我们很容易得出结论
已提交读取（read committed）允许 dirty read，不允许 read uncommitted，不允许 phantom read
串行化（rerializable）不允许 dirty read，不允许 read uncommitted，不允许 phantom read

而如果在同时支持此四种事务隔离级别的 SQL Server 中对另外两种隔离级别也做测试，会得出最后的结论如下

这个时候表 SONIC_TEST 中的数据实际上已经被变更了，但是事务A因为运行在 rerializable 隔离级别下，所以查询出来的结果依旧是修改前的，那么如果这个时候事务A如果也对该表做 update 操作会发生什么情况呢？继续测试

事务A中对表进行update操作

SQL> update SONIC_TEST set C1='DDDD';

update SONIC_TEST set C1='DDDD'

ora-08177: can't serialize access for this transaction

出现 ora-08177 错误，更新失败，那么 oracle 具体是如何来控制这样的机制的呢？且听下回分解:)
]]>