【SQL】数据库安全性、完整性、数据库恢复技术

一、基本内容

安全性;完整性;数据库恢复技术;SQL Server的数据恢复机制;

二、完整性

2.1 定义
  • 数据库完整性就是保证数据库中的数据的正确性和一致性,防止数据库中出现不符合要求的数据
2.2 实现完整性
  • 约束、默认、规则、触发器、存储过程
2.3 违反完整性
  • 当操作违反实体和用户自定义完整性时,一般DBMS都拒绝执行操作
  • 当操作违反参照完整性时,还要根据应用执行一些语句,保证数据安全性
2.4 约束
  • 表级约束
    若干元组间以及关系之间联系的数据约束。
    例如:选课表中,每个人最多能选 10 门课;学生表中,学生的学号必须唯一;选课表中的学号和课程号必须在学生表和课程表中存在。
  • 元组级约束
    同一个元组属性之间必须满足的约束条件。
    如学生表中年龄属性的值应该等于当前日期减去出生日期。
  • 属性级约束
    针对列的类型、取值范围、精度、排序等而制定的约束条件。
    例如:性别只能是‘男’或‘女’。
  • 常用约束
    • primary key主码,实体完整性(主码)
    • foreign key外码,参照完整性(外码)
    • (not) null非空
    • unique唯一性
    • check检查,使用时,例如check (sex in (''男,‘女’))
      CHECK(SNO LIKE ‘[1-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]’)
    • default默认,例如创建表时设置属性 sex default ‘男’
2.5 规则

**定义:**规则是数据库对存储在表的列或用户自定义数据类型中的值的规定和限制,规则只有绑定到列或者用户定义数据类型时才起作用。
规则是作为一个独立的数据库对象存在,表中每列或者每个用户定义数据类型只能和一个规则绑定。

  • 创建规则:
CREATE RULE rulename AS condition_expression
  • 绑定规则可以通过 sp_bindrule 存储过程实现:
 exec sp_bindrule 'rule_name','属性列'
  • 解除规则:
exec sp_unbindrule '属性列'
drop rule  rule_name
2.6 触发器

三、安全性

3.1 定义:

安全性是指保护数据库以防不合法的使用造成数据的泄露、更改或破坏,确保只有授权的用户使用数据库中数据和执行操作

3.2 安全级别

A1,B3,B2,B1,C2,C1,D

3.3 角色

每次单独设置用户的权限麻烦,SQL提供了角色的用户分组,将具有相同权限的角色分配到一个组中

  • 服务器角色: 由服务器账户组成的组,根据对服务器的管理任务以及这些任务的相对的重要性等级把具有sql server管理职能的用户划分到服务器角色组
  • 固定服务器角色: sysadmin,serveradmin,diskadmin,processadmin,securityadmin,setupadmin,dbcreator和 bulkadmin
  • 数据库角色: 由数据库成员组成的组,一个用户可以属于同一个数据库中的多个角色

创建角色:

create role role_name

为角色添加成员,使用系统存储过程,存储过程:

sp_addrolemember 'role_name'
3.4 授权粒度

可以定义的数据对象的范围,如果粒度越细,可以定义的数据对象范围越小,授权系统就越灵活.

关系数据库中的粒度:数据库、表、列、行。

授权操作:

grant 权限名称/角色名称 on 对象 对象名称 to user_name 【with grant option】

回收权限:

 revoke 权限名称 on 对象 对象名称 from user_name【cascade | restrict】

权限类别:

  • 对象权限
    对特定的安全对象(表、视图、列、存储过程、函数)的操作权限,如select,update,insert,delete,execute,references。
  • 语句权限
    对数据库的操作权限,通常是一些具有管理性的操作
3.5数据加密

审计:将用户对数据库的所有操作记录在审计日志上,DBA利用审计日志找出非法存储数据的人、时间、内容

  • 系统级审计: DBA设置,检测grant和revoke等操作
  • 用户级审计: 检测所有用户对表和视图的访问和操作
    设置审计功能:
audit alter,update on table_name;

取消审计功能:

noaudit alter,update on table_name;

四、数据库恢复技术

4.1事务

4.1.1 定义:用户自定义的数据库操作序列,要么全做要么全不做,是恢复和并发的基本单位
4.1.2 特性,ACID
  • 原子性Atomicity:要么全做要么全不做
  • 一致性Consistency:事务执行结果是从一个一致性状态到另一个一致性状态
  • 隔离性Isolation:事务的执行不受其他事务的干扰
  • 持续性Duration:一个事务一旦执行成功,那么对数据库的影响是持久性的
4.1.3事务状态
  • 活动:事务处于执行状态
  • 部分提交:事务的所有语句都执行完成,但是结果数据还在内存中
  • 失败:事务不能成功执行,必须进行回滚
  • 终止:事务回滚,数据库恢复到事务执行之前的状态
  • 提交:事务执行完成且对数据的修改已经完全写入数据库中,日志信息也保存了执行记录

4.2 数据库故障

  • 系统故障
    DBMS代码错误;硬件故障;操作员失误;特定类型故障;停电
    Undo未完成的事务,Redo已完成的事务,用队列进行记录

  • 事务内部故障
    事务进入失败状态,即将回滚,往往是非预期的

  • 存储设备故障
    发生概率低但是破坏性极大
    重装数据库,重做已完成的事务

  • 其他原因

4.3数据库恢复原理——冗余技术

利用存储在系统特定部分的冗余数据来重建数据库中被破坏的数据

4.3.1冗余恢复技术
  • 数据转储和登记日志,通常二者结合使用
  • 数据转储
    • 静态转储
      • 静态转储在无事务执行时对数据进行转储
      • 转储开始时数据库必须处于一致的状态
      • 转储期间不允许对数据库进行任何的修改
    • 动态转储
      • 转储操作和用户事务同时进行,不能保护副本数据有效性,需要配合日志文件进行恢复
    • 增量转储和海量转储
      • 每次转储的数据量是全部数据量还是变化的数据量,一般长间隔海量,短间隔增量

登记日志
登记的日志必须严格按照时间顺序,必须先写日志文件再写数据文件
Redo技术: 发生故障重做事务。
Undo技术: 撤销失败的事务对数据的一切option。

4.3.2检查点恢复技术

使用Redo和Undo消耗大量时间和资源,日志文件中增加了检查点记录,增加重启动文件
检查点: 记录在日志文件中表示数据库是否正常运行的一个标志,记录所有当前活动的事务
重启动文件: 记录各个检查点记录在日志文件中的地址

恢复步骤:

  1. 从重启动文件中找到最后一个检查点记录
  2. 得到检查点中所有事务清单,并加入Undo队列中
  3. 从检查点开始正向扫描事务,遇到完成的事务就加入Redo队列
  4. 对Undo事务进行Undo处理,对Redo事务进行Redo处理
4.3.3数据库镜像恢复技术

建立两个数据库,DBMS自动将数据库变化复制过去,保证两个数据库一致性
实际使用中纸赋值关键数据和日志文件
镜像数据库也可用于并发访问

五、SQL Server数据恢复机制

备份方法:

  • 完全备份
  • 差异备份
  • 事务日志备份
  • 数据库文件或文件组备份
  • 2
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小子挺不错

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值