你的位置:首页 > 数据库

[数据库]数据库知识点③


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并不能提供

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

DBCC TRACEON(1222,-1)

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

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

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

    5 

  (2)通过SQL Profiler

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

 

    6

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

    7

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

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

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

 

    8

   这种死锁可以通过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)函数依赖可以保证关系分解的无损连接性