数据库知识点③

1.DeadLocks 死锁

　　Cycle of transactions waiting for locks to be released by each other.

　　

2.Handle:

　　(1) DeadLocks prevention

　　　　Based on timestamps;

　　　　　　Wait-Die

　　　　　　Wound-wait

　　(2) DeadLocks detection

　　　　　　wait-for graph(check for them and fix them if  a deadlocks was found, abort/rollback this transactions)

3.发生死锁的四个必要条件：

　　

　　(1)互斥条件

　　　　主体对于资源是独占的，上图中每条汽车道只能跑一队汽车，不能跑第二队。

　　(2)请求和等待条件　　

　　　　指主体已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它主体占有，此时请求主体阻塞，但又对自己已获得的其它资源保持不放。在上图中，每队汽车已经占有了一条车道，又想获得另一条由其它车队占有的车道，造成阻塞。

　　(3)不剥夺条件

　　　　指的是主体已经获得的资源在完成其目标之前不能被释放。在上图中，目标指的是汽车可以通过车道，不剥夺指的是在完成这个目标之前，车队并不会让出其已占的车道。

　　(4)环路等待条件

　　　　指在发生死锁时，必然存在一个主体——资源的环形链，即主体集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。在图1中可以看出，四条车道和四队汽车正好符号环路等待的条件，车队1希望获得车队2占有的车道，车队2希望获得车队3占有的车道，车队3希望获得车队4占有的车道,车队4反过来又希望获得车队1占有的车道，形成一个环路。

4.死锁的预防

　　(1)破坏互斥条件

　　　　假如资源不被独占，那么死锁就不会发生。

　　(2)破坏占有和等待条件

　　　　只要禁止进程在执行中请求其他资源，就不会发生死锁. [让每个进程在执行前就分配好它所需要的所有资源，但是存在一个问题:许多进程在执行时才知道自己需要多少资源. 假设我们知道每个进程所需要资源数，可以使用银行家算法来避免死锁]

　　(3)破坏不可抢占条件

　　　　对于某些特殊资源，可以使用虚拟化方式来实现.

　　(4)破坏环路等待条件

　　　　如果进程要请求另一个资源，则必须放弃前面已掌握的资源，这就可以避免环路出现.

5.线程调度算法

　　(1)"先进先出"策略

　　　　　　所有线程组成一个队列，新的线程加入队列末尾，每次取出队首来执行。但是存在一个缺陷:新生成的线程如果是紧急操作，需要系统尽快响应，则该方法不满足要求.

　　(2)按照优先级调度

　　　　　　每个线程有自己的优先等级，并且是可被操作系统修改的. 然而这种方法也存在缺陷。也就是所谓的饥饿 如果一个线程"看似无关紧要",被赋予一个很低的优先级，假设以后每个线程的优先等级都比它高，那么该线程一直得不到执行。(一个解决方法是随着时间的推移而提升线程的优先级)

6.线程状态以及转化：

　　(1)已初始化(Initialized)

　　(2)运行(Running)

　　(3)备份(Standby)

　　(4)已终止(Terminated)

　　(5)等待(Waiting)

　　(6)转移(Transition)

　　(7)延迟的就绪(DeferredReady)

　　(8)门等待(Gatewait)

 　　

7.SQL Server中死锁的检测

　　(1)通过服务端的Trace来做

　　　当死锁发生后，通过服务端的Trace就可以将死锁信息传到日志。在SQL Server 2000时代，只能通过Trace flag 1204来开启，由于Trace flag 1204并不能提供XML死锁图，在SQL Server 2005以及之后的版本被Trace flag 1222所取代。

    　　　为了在服务端针对所有的Session开启Trace flag 1222。可以通过如下代码所示。　　

DBCC TRACEON(1222,-1)

    　　　 针对所有Session开启1222这个Trace Flag

    　　　除去上述代码之外，还可以通过在启动SQL Server实例之前，对加启动参数 –t1222。这里就不再细说了。

    　　　此时，当发生死锁后，就能从日志看到相关的记录，如下图所示。

     

　　(2)通过SQL Profiler

　　　　 另一种方法是开启Profiler来捕捉,Profiler捕捉到的图示死锁信息内容就更直观了，Profiler的设置如下图所示。

 

    

    　　所抓到的死锁图如下图所示。

    

 8.SQL Server中产生死锁的一些情况

　　(1)由书签查找产生的死锁

　　　　这类死锁产生的原因是书签查找和更新数据产生的僵持状态。简单来说,就是由于Update语句对基本表产生X锁，然后需要对表上的索引也进行更新，而表上的索引正好被另一个连接进行查找，加了S锁，此时又产生书签查找去基本表加了X锁的数据进行书签查找，此时形成死锁，这个概念可以从下图看到。

 

    

　　 这种死锁可以通过Include列来减少书签查找，从而减少这种类型死锁发生的概率。

　　(2)由外键产生的死锁

 

　　　　这类死锁产生的原因来自外键约束。当主表(也就是主键是从表外键的那个表)更新数据时，需要查看从表，以确定从表的外键列满足外键约束。此时会在主表上加X锁，但这并不能阻止同一时间，另一个SPID向从表添加被修改的主表主键，为了解决这个问题，SQL Server在进行这类更新时，使用Range锁，这种锁是当隔离等级为序列化时才有的，因此在这时虽然隔离等级可能是默认的已提交读，但是行为却是序列化。这很可能就会导致死锁。

 

   　　  解决办法之一是向外键列添加索引，使得Range锁加在索引上，而不是表本身。从而降低了死锁发生的概率。

　　(3)由于推进顺序不当产生的死锁

　　在多个事务对资源的使用顺序不当，形成死锁环路而引发的。解决方法是尽量是资源的使用顺序一致。这也是死锁问题出现最多的一种情况.

9.如何减少死锁

　　(1)预防死锁

　　   (a)破坏互斥条件

　　　　(b)破坏请求和等待条件

　　　　(c)破坏不剥夺条件

　　　　(d)破坏环路等待条件

　　 (2)避免死锁:资源有限条件下，主题争用资源不形成环路，使用银行家算法

　　 (3)检测死锁:通过系统所设置的监测机构及时地检测出死锁的发生，然后采用适当措施，清除死锁.

　　 (4)解除死锁:与检测死锁相配套的措施, 

　　　  (a)撤销或者是挂起一些进程

　　　　(b)分配资源给阻塞状态的进程,使进程转为就绪状态.

10.规范化问题的提出

　　(1)函数依赖

　　(2)范式

　　(3)模式设计

11.关系模式的存储异常问题

　　SCD(SNO,SN,AGE,DEPT,MN,CNO,SCORE)

　　SCD:教学管理系统　　SNO:学生学号　　　　 SN:学生姓名

　　AGE:学生年龄　　　　DEPT:学生所在院系　　MN:系主任姓名

　　CNO:课程号　　　　　SCORE:学生成绩

　　出现的问题：

　　　　(1)数据冗余

　　　　(2)插入异常(某个系没有招生，尚无学生，系名以及系主任的信息无法插入到表中)

　　　　(3)删除异常(这个系所有学生毕业,还没招生,删除所有的学生，则系名以及系主任信息也被删除，但是现实中该系仍然存在，却在表中无法找到相应的信息)

　　　　(4)更新异常(某个学生改名)

12.函数依赖的定义以及性质

　　(1)定义R(U,F)，U是属性全集，F是U上的函数依赖集，X和Y为U的子集.若对于每一个X的具体值，Y都有唯一的具体值与之对应，则称X决定函数Y 或者 Y函数依赖于X. 记做: X—>Y (X叫做决定因素,Y叫做依赖因素)

　　当Y不依赖X时: X -/->Y

　　当X—>Y且Y—>X 时记做 X <—>Y (等价条件)

　　举例:

　　　　知道某个学生学号 —>对应的身份证号

　　  知道某个学生的身份证号 —>对应的学号

　　   因此得到： 学生学号<—>学生身份证号　　

　　(2)函数依赖是语义范畴的概念

　　　　当学生不存在重名时: SN—>AGE 以及 SN—>DEPT

　　　　函数依赖反映了一种语义完整性约束

　　(3)函数依赖关系的存在与时间无关

　　　　(a)元组增加、删除、更新都不能破坏这种函数依赖

　　　　(b)因此,必须通过语义来确定属性之间的函数依赖，而不能单凭某一时刻关系中的实际数据来确定函数依赖

　　(4)函数依赖可以保证关系分解的无损连接性

 

上一篇数据库知识点②：http://www.cnblogs.com/zpfbuaa/p/5479733.html

下一篇数据库知识点④：http://www.cnblogs.com/zpfbuaa/p/5522527.html

wǒ bú xìn nǐ huì zhè mē wú liáo dē bǎ wǒ zhè jù huà dú yí biàn . rú guǒ nǐ zhēn dē dú lē . wǒ zhǐ xiǎng gào sù ni . wǒ xǐ huan ni .