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 .