特征的
但是数据共享虽然为员工带来了便利
但也产生了些负面作用例如因用户并发存取而导致对数据致性破坏、由于在修改数据过程中意外事故导致数据完整性破坏、非法用户未经授权修改数据等等所以在数据库设计过程中数据库管理员方面要想着如何提高数据共享程度另方面也需要考虑如何保护数据安全性在Oracle数据库中
提供了种被称为“事务”控制机制通过事物能够完成对数据有效安全修改操作使数据库中数据达到个数据致状态举个简单例子现在有个借书系统中设涉及到两张表张是图书库存表张是用户借书情况表在用户借书时候数据库需要进行两个操作是从图书库存表中扣掉库存；另个操作时在用户借书表中加入这个借书操作数据库在操作时往往是先扣减库存然后再在用户借书情况表中加入借书纪录假设用户在借书时候第步操作成功即已经从图书库存表中扣除了某书库存；但是在第 2步时由于发现用户借书已经超量或者发现用户卡中还有罚款不能够借书时借书就会不成功若没有事务做控制话很明显图书库存就会不准而在事务管理下当第 2步不成功话第步操作就会发生回滚也就是说事务可以把数据库好几个操作步骤当作个整体当其中有某个操作没有成功话则所有操作都会发生回滚Oracle数据库就是通过这种机制来保障数据致性问题但是
事务若编写不好话则不但起不到应有作用还会大大降低数据库性能如在数据库事务执行时间比较长就很有可能导致锁冲突从而降低数据库并发访问性能所以数据库管理员在编写事务时还是需要遵守几个指导方针指导方针
:在事务中尽量使得访问纪录最小在事务中
若执行Update等记录操作语句数据库为了保障数据致性会对其所访问记录加锁防止在同时间内其他用户对其修改此时若其他用户需要访问加锁记录则必须等待此时就会发生锁冲突所以
在事务中要尽量使得访问记录量最小如此就可以减少锁定行数从而减少事务的间冲突这要求数据库管理员在事务中尽量精确定位语纪录如在数据库中读取记录时最好能够使用Where语句进行定位并且在编写Where语句时候要尽量详细最好能够实现对则是最好如在库存盘点
时候事务处理语句需要从数据库中读取定数量记录并且为这些记录进行加锁此时若记录读取过多话就会对其他用户访问表中记录造成麻烦为此数据库管理员应该建议应用前台应用
在开发过程中加入些限制条件如按照产品分类来更新库存如此话就可以减少个事务次性读取记录数量从而把锁影响降低到最低指导方针 2:保持事务尽可能
简洁在事务中尽量使得访问
纪录最小这是从数量角度来考虑锁冲突而保持事务尽可能简洁则是从时间角度来考虑避免锁冲突事情保持事务尽可能简洁主要是要求数据库管理员在编写事务时候不要把事务写太过于庞大和复杂否则事务在执行时候就会占用比较多时间而这直接导致后果就是数据库会把某些记录、甚至张数据表锁住比较长时间这就会恶化锁对数据库负面影响故当用户在知道了必须要进行修改
记录的后就要马上启动事务；并且在最短时间内执行完相关修改语句然后立即递交或者回滚而且只有在确实需要时才打开事务语句具体来说数据库管理员在事务简洁性方面可以尝试如下思路方法是在同个事务中不要加入过多修改或者删除语句如当用户需要更新用户信息表中相关数据例如在员工编号前加入YG前缀并且同时根据员工入职年份计算员工工龄这两个更新语句若从技术上来说放在同个事务中并没有什么不妥但是当员工数量比较多时若把他们合并在起则这个事务执行得时间会比较久为此最好在更新数据库表时候若预计执行时间会比较长则最好能够把更新语句进行分割如列列更新等等2是在更新时
若次性更新语句比较多最好能够选择合适时候更新更新某个数据库中记录其执行所需要时间往往跟数据库记录成正比其记录越多更新所需要时间越多为此笔者建议当需要更新记录比较多时候最好能够选择合理时机如有些应用在设计时可以把这个更新放在后台处理如此话应用就可以选择数据库比较空时候来更新表中记录这无疑可以在很大程度上降低事务对数据库负面影响指导方针 3:不要在事务处理期间要求用户输入
数据库管理员在编写事务时
要确保在事务启动的前让数据库系统获得事务执行所需要所有内容如记录查询条件、所需要更新内容等等如果在事务执行过程中还需要用户输入就回滚当前事务当用户提供了必要参数的后再重新启动这个事务
即使在事务执行过程中用户立即响应但是用户反应速度要比电脑响应速度慢多所以当用户在事务执行过程中需要输入参数话就会使得这个事务所占用数据库资源要保持很长时间这就有可能增加阻塞风险当用户没有及时输入所需要参数时事务仍然会保持活动状态并锁定相关资源直到他们响应为止若用户所需要输入参数比较多时用户可能会几分钟甚至个小时没有输入这不是
种理论上假设笔者在实际工作中就碰到过这种例子如在个ERP系统中有订单变更功能若在设计时候在用户打开销售订单变更单就触发变更事务话则用户输入订单变更所需要时间不能够确定有时候用户这边改改那边再确认下可能个小时就过去了此时这张销售订单对应内容其他用户就无法查看了数据库中已经被这个事务锁住这显然是设计不合理笔者认为应到在用户点击确认按钮时再触发这个变更事务此时用户已经输入了所需要更改所有内容在更新事务执行过程中不需要用户再输入其他额外参数通过这种方式就可以把事务所占用资源时间缩短到最低指导方针 4:在浏览数据时
尽量不要打开事务根据笔者
经验用户更改数据所需要时间其实很少而大部分时间则是在更改数据的前对数据分析上如在定位需要对哪些数据要进行更改；如在更改事务递交好审核;如在考虑该如何进行更改这个分析工作所占据时间往往是大头故笔者提醒数据库管理员
在所有预备数据分析完成的前在用户数据浏览时候不要启动事务也就是说在用户更改数据时候仍然不是触发更新事务最佳时间只有到用户确认无误后选择“更新”按钮此时才可以触发这个事务并且及时递交或者回滚这个事务如此在事后审核过程中事务就不会继续占用资源除了以上这些指导方针外
还有其他些小细节要注意如尽量采用级别低事务隔离级别数据库管理员要切记不是所有事务都要求串行事务隔离级别;如事务设计简短些；如在事务回退时可根据实际情况选择回退全部事务或者是部分事务等等另外要特别注意在事务中排他锁副作用在修改数据时为了保障数据致性往往需要利用排它锁保护修改过行以防止其他任何事务读取这行并且必须把排它锁控制到递交或者回滚事务为止为此数据库管理员在设计跟更新相关事务时要合理选择时机让事务在保障数据安全性同时最大限度降低其负面作用
最新评论