如在
个ERP系统中有订单变更
功能若在设计时候
在用户打开销售订单变更单就触发变更事务话则
用户输入订单变更所需要时间不能够确定有时候用户这边改改那边再确认下可能个小时就过去了此时这张销售订单对应内容其他用户就无法查看了数据库中已经被这个事务锁住这显然是设计不合理笔者认为应到在用户点击确认按钮时再触发这个变更事务此时用户已经输入了所需要更改所有内容在更新事务执行过程中不需要用户再输入其他额外参数通过这种方式就可以把事务所占用资源时间缩短到最低指导方针 4:在浏览数据时
尽量不要打开事务根据笔者
经验用户更改数据所需要时间其实很少而大部分时间则是在更改数据的前对数据分析上如在定位需要对哪些数据要进行更改；如在更改事务递交好审核;如在考虑该如何进行更改这个分析工作所占据时间往往是大头故笔者提醒数据库管理员
在所有预备数据分析完成的前在用户数据浏览时候不要启动事务也就是说在用户更改数据时候仍然不是触发更新事务最佳时间只有到用户确认无误后选择“更新”按钮此时才可以触发这个事务并且及时递交或者回滚这个事务如此在事后审核过程中事务就不会继续占用资源除了以上这些指导方针外
还有其他些小细节要注意如尽量采用级别低事务隔离级别数据库管理员要切记不是所有事务都要求串行事务隔离级别;如事务设计简短些；如在事务回退时可根据实际情况选择回退全部事务或者是部分事务等等另外要特别注意在事务中排他锁副作用在修改数据时为了保障数据致性往往需要利用排它锁保护修改过行以防止其他任何事务读取这行并且必须把排它锁控制到递交或者回滚事务为止为此数据库管理员在设计跟更新相关事务时要合理选择时机让事务在保障数据安全性同时最大限度降低其负面作用TAG: 事务 数据库 Oracle ORACLE 编写 方针
最新评论