本文整理自网络,侵删。
目录
- 引言
- 禁忌1:触发器代码忌复杂
- 禁忌2:忌使用dblink
- 禁忌3:忌用大表关联统计
- 禁忌4:忌用字典式字段索引
- 禁忌5:慎用主键约束
- 禁忌6:慎用外键关联
- 禁忌7:组合索引使用要注意
- 禁忌8:慎重考虑表字段调整
- 禁忌9:忌直接使用用户名和密码连接数据
- 禁忌10:慎用数据库连接
- 禁忌11:忌用并行
- 禁忌12:忌SQL语句不使用绑定变量
- 禁忌13:忌索引数量过多
- 禁忌14:select for update 要带nowait
- 禁忌15:批量任务要控制好事务提交的频度
- 禁忌16:sequence使用注意
- 禁忌17:慎用rowid更新数据
- 禁忌18:慎用子查询
- 禁忌19:忌用SELECT *
- 禁忌20:where 子句中慎用!=或<>操作符
- 禁忌21:where 子句中慎用like
- 禁忌22:where 子句中慎用in和not in
- 禁忌23:where字句中慎用字段函数操作
- 禁忌24:忌用select count(*)
- 禁忌25:索引字段访问慎用OR
- 禁忌26:慎重考虑字符集
- 禁忌27、慎用视图嵌套
- 禁忌28: 忌数据对象名过长
- 禁忌29:谨慎表和索引的inittrans设置
- 禁忌30:数据模型和数据对象的设计必须商DBA确认
- 小结:
引言
笔者及所在团队从2000年开始的CRM等系统开发,一直主要使用ORACLE数据库作为应用数据库,开发方式包括使用PLSQL编写存储过程/数据库函数/触发器、使用ODBC或OCI和ProC开发C++应用、使用JDBC开发Java应用、使用tuxdeo开发中间件应用等。这些应用开发笔者所在团队自己做过,也委托华为、亚信、思特奇等国内厂商合作做过,整体来说ORACLE数据库功能强大、性能出众、系统健壮,确实是OLTP联机事务处理的最受欢迎的数据库。
因ORACLE服务费居高不下、加上最近几年美国的操弄打压,国产数据库也走出了一条自己的路,因此数据库国产化也越来越被提上日程,也有部分应用走出了成功之路,但众多传统应用进行国产数据库的改造需要大量投入,也需要一个逐步试点及改造的过程,因此ORACLE仍然是国内众多单位持续应用的选择。
今天老猿结合二十余年的ORACLE数据库应用开发和运维的经验教训,总结在使用ORACLE数据库环境中的应用开发中需要注意的一些注意事项,这些问题不但可以作为ORACLE数据库开发的注意事项,大多数也适用于常见的关系型数据库开发甚至非关系型数据开发。
实际上,在数据库应用开发上,开发和维护关联度是非常大的,好的开发设计会给维护带来极大方便。因此虽然维护关注的角度和开发有所不同,但在部分内容上二者是统一的。
禁忌1:触发器代码忌复杂
数据库触发器由于可以基于表级进行所有应用或手工DML操作数据增删改查的前向或后向处理,易于收敛逻辑,使用方便,容易受到众多开发人员的喜爱。
但在使用上触发器与操作数据的事务处于同一个事务,因此比较适合简单处理逻辑,切忌不能在触发器上使用复杂逻辑,一般推荐在10行左右代码比较适合,否则容易导致事务处理出现问题。
如果一定要通过触发器进行复杂逻辑处理,最好的做法是通过触发器将需要处理的数据写入到单独的任务表中,然后使用单独进程对任务表数据进行处理。这样能使得触发器和触发源二者的事务解耦,又能收敛相关数据处理。
禁忌2:忌使用dblink
dblink提供的机制可以使得在一个数据库的存储过程、触发器、数据库函数中方便的访问另一个数据库,可以方便地为应用只需连接一个数据库就可以访问另一个数据库中的数据,因此给多数据库环境使用带来了很大的便利性。
但dblink在跨数据库事务提交上容易引发问题,一般可以在不带事务的DML简单查询中使用,如果一定要带事务必须确保事务提交迅速,否则容易引发分布式事务锁。而应用程序中使用时,由于运行的环境复杂多变,无法百分之百保障事务的完整性和响应快速,很容易引发分布式事务锁并有一定几率触发ORACLE的BUG,同时dblink本身会大概率甚至百分之百带来scn号跳变bug,并引发scn号跳变在数据库间传播。导致系统故障甚至数据库瘫痪。因此不要在代码开发中使用dblink。平时运维也尽量少用,如果一定要用最好不带事务,并尽快释放连接。
禁忌3:忌用大表关联统计
在一个系统中,除了实时类交易外,也存在一定要求数据实时的统计或查询需求,针对这种数据统计,切忌使用大表关联进行统计,因为会导致数据库消耗大量计算资源、占用过多的临时空间,影响其他实时业务的响应甚至导致系统无法响应。
对于这种需要跨多个大表的统计,最理想的是不放在OLTP数据库执行,如果一定要执行,一是要想办法限制数据的范围(如基于时间限制只能统计当天的),二是对于两个大表关联的SQL进行拆分,拆分成两个SQL,前一个SQL获取的数据通过游标打开后再逐条去另一个大表使用索引逐条数据进行访问,再用客户端进行统计运算,或者通过游标获取数据生产临时表再基于临时表进行统计。
禁忌4:忌用字典式字段索引
索引只有说数据在索引字段比较分散才有效果,如果基于一些字典式字段(如性别、课程等)建索引,起不到很好的效果不说,还浪费存储空间。这种字典式的字段如果一定要发挥类似索引的效果,可以按字典值建分区键。
禁忌5:慎用主键约束
某个表的主键理论上看起来是个很好的机制,但在一般性应用中,由于主键不能更新,因此在运维时会带来很多不便,一般建议慎用,而是可以用非空和唯一性约束方式来替代。
禁忌6:慎用外键关联
外键关联可以确保某个表的主键被其他表作为非主键使用时来保障两个表数据的一致性,但外键关联给程序开发、运维都带来了更多的复杂性,而好的开发习惯能确保两个有外键关联的表满足数据一致性的要求,因此一般情况下慎用外键关联。这其实是根据在方便性、数据一致性之间应用更倾向于哪方面来决策使用方式。
禁忌7:组合索引使用要注意
- 使用多个字段的混合索引是常见的,但索引使用的字段越多,就意味着开发时需要关注的字段越多,开发时部分人员容易忘记索引字段,导致容易写出用不到索引的语句。因此一般建议复合索引使用字段不超过5个;
- 组合索引中字段的顺序是非常重要的,越是唯一的字段越是要靠前;
- 程序代码使用组合索引时,在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,并且应尽可能的让字段顺序与索引顺序相一致。
禁忌8:慎重考虑表字段调整
当一个初始设计的表在运行一段时间后,随着业务的发展和系统的持续运营,对表结构进行调整是迟早的事,但调整表结构如增加新字段、字段长度调整等都需要慎重,特别是针对数据量大访问频繁的表更要谨慎。
在评估表结构调整时,一般需要考虑:
- 是否需要停系统调整,对于高并发访问频繁的表至少要等到业务闲时进行调整;
- 如果是调整字段大小需要评估是否有代码限制了字段大小;
- 如果是新增字段需要评估是否有代码采用了select *方式访问;
- 是否需要初始化历史数据?如果有是否会造成行迁移?是否需要重建表?
- 是否会影响外围接口或系统数据的交互?
为了应对字段增加可能带来的风险,有2个方法来提取预防:
- 给一些大表预留一定的字段,这样可以避免停系统、减少行数据迁移、并避免系统运行时进行表结构调整的风险,但要规划好预留字段的数量、并做好启用管理;
- 尽量不动大表本身,而是设计扩展表来解决。
禁忌9:忌直接使用用户名和密码连接数据
在信息安全非常重视的今天,数据库的安全性是重中之重,应用系统不应该在程序代码或配置文件中直接使用用户名和密码方式连接访问业务数据。如果这样,对开发人员和维护人员密码就和没有密码一样,另外如果出现数据库必须修改密码时,需要到处改密码相关的代码或配置文件。
比较好的解决办法是用最小权限的用户登录,登录后通过专用加密配置表获取用户真正使用的用户和密码,这就是二次登录。
禁忌10:慎用数据库连接
在一个大型系统内,数据库连接是宝贵的资源,ORACLE的连接数单实例一般限制在4096个,看起来不少,但如果连接节点多真正使用起来后会发现连接数往往不够用。为此需要对数据库的访问进行连接收敛管控,实现连接的复用。
要实现连接的收敛,有如下做法:
- WEB服务器通过连接池管理收敛客户端的数据访问;
- 后台进程或中间间通过数据访问代理层来进行连接的复用和收敛;
- 后台维护限制单机登录会话数。
禁忌11:忌用并行
在程序代码或表的参数设置里,都可以设置并行参数,并行对于单表或单语句能起到迅速提高执行效率的作用,但这种并行是以抢占其他任务的资源为代价,因此在OLTP数据库应用中,最好别使用并行的DML语句或将表的并行参数打开。临时执行任务考虑到执行速度需要使用并行时,一定要与DBA协商是否可以开启并行,并在任务执行结束后关闭
表的并行参数。
相关阅读 >>
更多相关阅读请进入《oracle》频道 >>
数据库系统概念 第6版
机械工业出版社
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。
转载请注明出处:木庄网络博客 » ORACLE数据库应用开发的三十个注意事项
相关推荐
评论
管理员已关闭评论功能...