5.1 数据库管理概述

• 数据库管理的概念：数据库管理(Database Management)是指为保证数据库系统的正常运行和服务质量必须进行的系统管理工作。

5.1.1 数据库管理的必要性

• 数据库系统随规模增大,系统会变得异常复杂

• 多用户数据库应用带来数据库访问复杂性

• 数据安全和数据隐私对机构和用户都非常重要

• 数据库系统随数据量增加和使用时间增长其性能会降低

• 系统遭遇意外事件，数据库损坏或数据丢失

5.1.2 数据库管理的目标

• 保障数据库系统正常稳定运行

• 充分发挥数据库系统的软硬件处理能力

• 确保数据库系统安全和用户数据隐私性

• 有效管理数据库用户及其角色权限

• 解决数据库系统性能优化、系统故障与数据损坏等问题

• 最大程度地发挥数据库对其所属机构的作用

5.1.3 数据库管理内容

• DBMS系统运行管理

• 数据库性能监控

• 数据库索引管理

• 数据库查询优化

• 数据库事务并发控制

• 数据库角色管理

• 数据库用户管理

• 数据库对象权限管理

• 数据安全管理

• 数据库备份

• 数据库恢复

5.1.4 数据库管理员（DBA）职责

• 负责数据库系统开发与运维

• 负责数据库用户与权限管理

• 负责数据库备份与数据库恢复管理

• 负责数据库性能调优管理

5.1.5 DBMS系统层次结构

5.1.6 数据库管理工具

• Oracle SQL Developer——管理Oracle数据库

• SQL Server Management Studio——管理SQL Server数据库

• pgAdmin4——管理PostgreSQL数据库

• MySQL Workbench——管理MySQL数据库

5.2 事务管理

5.2.1 事务概念

• 事务的概念：在数据库中，事务（Transaction）是指由构成单个业务处理单元的一组数据库访问操作，要求它们要么都成功执行，要么都不执行（相当于是数据库管理系统中的原子操作了）

5.2.2 事务状态

• 事务的状态：在数据库系统中，事务是DBMS执行的最小任务单元。同时，事务也是DBMS最小的故障恢复任务单元和并发控制任务单元
事务的状态如下图：



image-20240518112132379
也就是如果执行失败的话就要回滚到这一个事务执行前的状态（所以说事务也是最小的故障恢复任务单元）

5.2.3 事务特性

• 事务ACID特性
• 原子性（Atomicity）：事务所有操作在数据库中要么全部执行，要么全部不执行。
• 一致性（Consistency）：事务多次执行，其结果应一致。
• 隔离性（Isolation）：事务与事务之间隔离，并发执行透明。
• 持续性（Durability ）：事务完成后，数据改变必须是永久的。

5.2.4 事务并发执行

• 事务并发执行原因（跟操作系统要并发很像）
• 改善系统的资源利用率
• 减少事务运行的平均等待时间

5.2.5 事务SQL程序

• 常用的事务SQL语句
• BEGIN 或 START TRANSACTION ：事务开始语句（一般是在事务开始时使用）
• ROLLBACK ：事务回滚语句（回滚到保存点或者是当前事务开始，一般在事务结尾使用。回滚到保存点需要执行保存点的名称）
• COMMIT ：事务提交语句（一般是在事务结束的时候使用）
• SAVEPOINT ：事务保存点语句（在事务创建一个保存点）

• 事务程序中不能使用的SQL语句
稍微了解一下就好了，大概都是一些数据定义语言语句还有数据控制语言语句不能使用
• 创建数据库 CREATE DATABASE
• 修改数据库 ALTER DATABASE
• 删除数据库 DROP DATABASE
• 恢复数据库 RESTORE DATABASE
• 加载数据库 LOAD DATABASE
• 备份日志文件 BACKUP LOG
• 恢复日志文件 RESTORE LOG
• 授权操作 GRANT

5.2.6 DBMS默认事务方式

5.3 并发控制

5.3.1 并发控制的必要性及目的

• 并发控制的必要性：当多个事务程序在DBMS系统中同时运行时，可能会出现对一些共享数据同时进行访问操作，如一些事务修改数据，另一些事务读取数据。这些并发的共享数据操作，如果在DBMS中没有一定的约束控制情况下，可能会带来数据不一致性或事务程序死锁问题。因此，在多个事务并发运行时，必须进行并发控制处理（跟操作系统里面是差不多的）

• 并发控制的目的（实际上就是并发的目的加上一致性和死锁啥的）
• 支持并发事务处理，使更多用户并行操作，提高系统的并发访问能力。
• 保证一个事务工作不会对另一个事务工作产生不合理的影响。

5.3.2 并发控制需解决的问题

• 丢失更新数据：实际上就是银行取钱的那个例子（就是没有做数据库数据访问互斥，导致update操作出现异常）



image-20240518120032001

• 不可重复读取：实际上还是因为没有实现读写互斥（因为没有做互斥导致SELECT、DELETE、INSERT操作出现异常）
• 同类问题
• 事务T1按一定条件从数据库中读取了某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录消失了。也称为不可重复读取。（DELETE操作异常）
• 事务T1按一定条件从数据库中读取某些数据记录后，事务T2在其中插入了一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。称为幻象读取。（INSERT操作异常。但是需要知道幻读好像并不是算在重复读中的，因为他并不会对已有数据造成影响，只会对聚合函数造成影响）



image-20240518120052219

• 脏数据读取：脏数据读取是指一个事务读取了被取消持久化的共享数据（也就是读取到了无效数据，或者说是在数据还没有被完全写入时就进行了读取。可以想想虚拟内存中的那个脏读也是，当页表项无效了还去读取这个页表项的话就会对脏读位置1）



image-20240518120721586

5.3.3 并发事务调度原理与策略

• 事务调度原理：在DBMS中，事务管理器将并发执行事务的SQL数据操作请求提交给并发控制调度器。由并发控制调度器将各个事务的SQL数据操作请求按照一定顺序进行调度执行，并完成对数据库缓冲区的读写操作。

• 事务调度策略（甚至都不知道这一小点为什么要叫策略。应该是在介绍怎么调度的吧）
• 可串行化调度：在事务并发执行中，只有当事务中数据操作调度顺序的执行结果与事务串行执行结果一样时，该并发事务调度才能保证数据操作的正确性和一致性。符合这样效果的调度称为可串行化调度（就是事务并行的结果与事务串行的结果相同）
• DBMS并发事务调度目标：使并发事务调度实现的处理结果与事务串行化调度处理结果一致。（就是要让并发控制调度器的调度是一个可串行化调度）

5.3.4 数据库锁机制

• 资源锁定访问：在DBMS中，通过加入锁表机制，来实现共享数据锁定访问，其加锁方式包含如下类型。
• 排它锁定(Lock-X)——锁定后，不允许其它事务对共享数据再加锁（写互斥）
• 共享锁定(Lock-S)——锁定后，只允许其它事务对共享数据添加读取锁（读共享）

• 资源锁定粒度：实际上就是要把锁加在什么地方上
• 数据库——粒度最大
• 表——粒度较大
• 页面——粒度中等（这里的页面应该是视图的意思。复习一下视图有什么用：简化SQL、数据安全、逻辑独立、集中展示）
• 行——粒度小

• 资源锁定实施方式
• 隐式锁定：DBMS缺省执行
• 显式锁定：加锁命令显式执行

5.3.5 基于锁机制的并发控制协议

• 锁操作的相容性（就是是不能能重复获得锁，相容性就是排他性的反义词）
锁操作的相容性如下：



image-20240518203551612
这个意思是，如果数据被加上了一个排它锁，就不能再获得排它锁和共享锁了；如果数据被加上了一个共享锁，就不能再获得排它锁和共享锁了。

• 加锁协议
• 一级加锁协议：任何事务在修改共享数据对象之前，必须对该数据执行排它锁定指令，直到该事务处理完成，才进行解锁指令执行
使用一级加锁协议，可避免出现更新丢失问题。但不能解决“不可重复读取”、“脏读”等数据不一致问题（因为加上了一个排他锁就只控制了写操作，对读操作不做任何限制）
• 二级加锁协议：在一级加锁协议基础上，针对并发事务的共享数据读操作，必须对该数据执行共享锁定指令，读完数据后即刻释放共享锁定。
该加锁协议不但可以防止“丢失更新”的数据不一致性问题（因为是在一级加锁协议的基础上实现的），还可防止出现脏读数据问题。但有可能会出现“不可重复读取”的数据不一致问题：



image-20240518204235701
这里就通过共享锁防止了脏读（也就是读取数据之前要求数据已经被完全写入）
不能解决不可重复读取中的数据一致性问题是因为当一个事务正在进行时，先读取一个数据，然后另一个事务执行一个写操作，然后再回到原来的任务执行读操作。这个时候就会出现数据不一致的问题（这是个问题是因为在编写事务程序的时候都是认为数据是不变的，因为没办法预测其他事务会将数据修改成什么样）
• 三级加锁协议：在一级加锁协议基础上，针对并发事务对共享数据进行读操作，必须对该数据执行共享锁定指令，直到该事务处理结束才释放共享锁定（这里就不可避免的要牺牲一些并发度来解决数据不一致的问题了）
该加锁协议不但可以防止“丢失更新”（因为三级一定是一级，能保证写互斥）、“脏读”问题（因为三级一定是二级，能保证读取数据有效），还可防止出现“不可重复读取”的数据一致性问题（因为在当前事务结束的时候才会释放锁定，这样就保证了当前事务在读取的过程中不会出现数据的写操作，也就使得前后读取的数据一致了）
如下图：



image-20240518205159061

• 不同级别锁协议比较（这个更像是一个对上面的三级加锁协议的总结吧）：



image-20240518205317794

5.3.6 两阶段锁定协议

• 两阶段锁定协议：用于保证调度的可串行化（也就是能保证事务的正确调度）。分为下面两个阶段
• 增长阶段，事务只能获得锁，但不能释放锁。
• 缩减阶段，事务只能释放锁，但不能获得新锁
若并发事务执行的所有事务都遵从两阶段锁定协议，则这些事务的任何并发调度都是可串行化调度，即这些并发调度执行结果可以保证数据库一致性

5.3.7 死锁问题解决

• 事务死锁：在多个事务竞争共享资源的情况下，出现的相互永远等待的封锁请求，若无外力作用，这 些事务永远不能向前推进，称为死锁（跟操作系统中死锁的定义是完全相同的）

• 死锁出现的必要条件（狠狠背）
• 互斥条件
• 请求和保持条件
• 不剥夺条件
• 环路等待条件

• 防范死锁的策略（破坏死锁的必要条件？）
• 允许用户一次发出当前所需全部资源的锁定，使用完成后，再释放给其它用户访问——破坏请求和保持条件
• 规定所有应用程序锁定资源的顺序必须完全相同——破坏环路等待条件（操作系统中说的，按照序号递增顺序提出资源申请，按照序号递减顺序释放资源）

• 解决死锁的方法：当发生死锁时，回滚其中的一个事务，并取消它对数据库所做的改动（在操作系统中就不能这么直接的处理了，因为进程之间如果锁住了就很难再将进程恢复到上一个状态了，开销太大了）

5.3.7 事务隔离级别

5.4 安全管理

5.4.1 数据库系统面临的安全风险

• 黑客利用系统漏洞，攻击系统运行、窃取和篡改系统数据。

• 内部人员非法地泄露、篡改、删除系统的用户数据。

• 系统运维人员操作失误导致数据被删除或数据库服务器系统宕机。

• 系统故障导致数据库的数据损坏、数据丢失、数据库实例无法启动。

• 意外灾害事件（火灾、水灾、地震等自然灾害）导致系统被破坏

5.4.2 数据库系统安全模型

• 身份验证：从应用系统层面确认登录用户是否是合法使用者

• 权限控制：从DBMS系统层面通过存取权限机制控制用户对数据的访问

• 系统防护：从操作系统层面提供的安全机制防范非法系统访问

• 加密存储：从数据存储层面通过加密算法对数据库中数据进行加密存储

5.4.3 数据库存取权限控制安全模型

5.4.4 用户管理

• 用户管理：在数据库安全管理中，DBMS需要对每个用户进行管理，如用户创建、用户修改、用户删除管理等。

• 用户创建SQL语句
• 语句基本格式：
这个应该算是一个数据定义语言
如创建一个新用户，其账号名字为“userA”，密码为“123456”。该用户具有登录权限（Login）和角色继承权限（Inherit）系统权限，但它不是超级用户（SuperUser），不具有创建数据库权限（CreateDB）、创建角色权限（CreateRole）、数据库复制权限（Replication），此外数据库连接数（Connection Limit）不受限：
需要注意的是如果是不给这个权限，就在这个权限前面加上NO；如果不限制数量，就写-1；密码是一个字符串

• 用户修改SQL语句
• 语句基本格式
为什么说没用呢，是因为如果要修改的话（修改用户“userA”的账号密码为“gres123”。同时也限制该用户的数据库连接数为10）：
甚至什么关键字都不需要加），只需要ALTER USER就好了（这里就跟数据定义语言好像没什么区别了，用的都是CREATE、ALTER、DROP啥的）

• 用户删除SQL语句
• 语句基本格式

5.4.4 权限管理

• 权限管理：数据库权限管理是指DBA管理员或数据库对象拥有者对其所拥有对象进行权限控制设置。

• 权限管理基本操作（刚好回忆一下数据控制语言）
• 授予权限——GRANT
• 收回权限——REVOKE
• 拒绝权限——DENY

• 权限类别
• 数据库系统权限（除了访问和定义以外的权限，就是除了增删改查的权限）
• 数据库对象访问操作权限
• 数据库对象定义操作权限

• 权限管理SQL语句（跟前面介绍的数据控制语句是一样的）
• 授予权限：
• 收回权限：
• 拒绝权限：
需要注意的点跟之前是一样的，这里就稍微再复习一下
这里的权限名一般就是SELECT、INSERT等；GRANT和DENY使用的关键字是TO，而REVOKE使用的关键字是FROM

5.4.5 角色管理

• 角色管理：在DBMS中，为了方便对众多用户及其权限进行管理，通常将一组具有相同权限的用户定义为角色(Role)。所以角色就好像是用户组

• 角色管理内容（盲猜是数据定义语言）
• 创建角色
• 修改角色
• 删除角色

• 角色管理实现方式（将物理模型转换为数据库对象时也是这两种方法）
• 执行SQL语句管理角色
• 通过GUI操作管理角色

• 角色管理SQL语句（实际上跟用户管理SQL语句是完全一样的，只不过把USER改成了ROLE）
• 语句基本格式
需要注意的点是，创建角色的时候是不用提供PASSWORD的

• 角色权限授予：也就是用权限管理那些数据控制语言来给角色权限罢了（授予就是GRANT了），只不过在TO或者FROM关键字后面给出的是一个角色名而不是用户名罢了（ON后面跟的是数据库对象！！！）

5.5 数据库备份与恢复

5.5.1 数据库系统故障原因

• 数据库服务器硬件故障

• 系统软件故障

• 用户误操作

• 系统意外断电

5.5.2 数据库备份与恢复

• 数据库备份：数据库备份是指将数据库当前数据和状态进行副本复制，以便当数据库受到破坏或丢失数据时可以进行修复。

• 数据库恢复：数据库恢复是指数据库中数据丢失或被破坏时，从备份副本将数据库从错误状态恢复到某一正确状态（所以出现丢失或者破坏的时候总是会出现点问题的）。

5.5.3 备份内容与备份角色

• 备份内容——包括数据文件、日志文件等

• 备份角色——可以是服务器管理员（sysadmin）、数据库所有者（db_owner）、数据库备份员（db_backupoperator）角色之一。

5.5.4 备份介质与备份时机

• 备份介质——包括磁盘阵列、磁带库、光盘库等。

• 备份时机——当系统数据库重要数据被修改、日志被清理、用户数据库创建、用户数据库加载等事件出现时。

5.5.5 数据库备份方法

• 数据库备份方法
• 完全数据库备份
• 差异数据库备份
• 事务日志备份
• 文件备份

• 数据库备份方式（去年有考，但是在wyd的ppt上没有给出概念）
• 冷备份：冷备份是指在数据库停止运行时进行备份操作， 可以确保备份的数据完整性和一致性，但会中断数据库的正常服务。
• 热备份：热备份是指在数据库运行时进行备份操作，不会中断数据库的正常运行。热备份通常需要数据库支持相应的备份工具和机制

5.5.6 备份实现方式

• 执行SQL命令实现备份

• 操作GUI工具实现备份

5.5.7 数据库恢复方法

• 通过备份文件恢复
也就是备份数据库的时候采用的是文件备份方法
下面给出一个通过备份文件恢复的例子：
需要注意的是数据恢复是使用的关键字是RESTORE和FROM，因为使用的是通过备份文件恢复，所以还是使用DISK关键字，后缀同样是.bak
通过备份文件恢复的特点如下：
• 恢复技术简单，易于实现
• 对于多用户系统，难以接受备份周期内出现的数据丢失（疑问这个是什么意思）

• 利用事务日志按前滚或回滚方式进行数据库恢复
也就是备份数据库时采用的是事务日志备份方法
这里就是直接根据日志然后将事务回滚（或者前滚，也就是向前走到某一个位置）到某一个正确位置（所以能发现事务回滚操作一定是要有日志的支持信息的）
如下图：



image-20240518224714028