oracle基础知识入门 oracle数据库

oracle数据库(Oracle基础知识介绍)
从2000年开始,作者和他的团队一直在开发CRM等系统,主要使用Oracle数据库作为应用数据库 。开发方法包括使用PLSQL编写存储过程/数据库函数/触发器,使用ODBC或OCI和ProC开发C++应用,使用JDBC开发Java应用,使用tuxdeo开发中间件应用 。这些应用有作者团队开发的,也有华为、亚信、思奇等国内厂商开发的 。总体来看,Oracle数据库功能强大,性能突出,系统健壮,确实是OLTP在线事务处理最受欢迎的数据库 。
由于Oracle高昂的服务费,以及国内数据库走出了自己的路,数据库的本地化越来越被提上日程,一些应用已经走出了成功之路 。而很多传统应用对国产数据库的改造需要大量的投入,也需要一个循序渐进的试点和改造过程 。所以Oracle依然是国内很多单位持续的应用选择 。
今天,Laoape根据20多年Oracle数据库应用开发和运维的经验教训,总结了Oracle数据库环境下应用开发的一些注意事项 。这些问题不仅可以作为Oracle数据库开发中的注意事项,大部分也适用于常见的关系型数据库开发,甚至非关系型数据开发 。
其实在数据库应用开发中,开发和维护的相关性是非常大的,好的开发和设计会给维护带来很大的便利 。因此,虽然维护和开发的角度不同,但在某些方面是统一的 。
1.禁忌:避免触发器代码的复杂性 。
由于数据库可以基于表级向前或向后处理所有的应用程序或手工DML操作数据,所以容易收敛逻辑,易于使用,容易受到很多开发者的喜爱 。
但是在使用中,触发器和操作数据的事务在同一个事务中,所以更适合简单的处理逻辑 。禁止在触发器上使用复杂的逻辑 。一般建议10行左右的代码比较合适,否则容易导致交易处理出现问题 。
如果必须通过触发器进行复杂的逻辑处理,最好的办法是通过触发器把要处理的数据写入单独的任务表,然后用单独的进程处理任务表数据 。这可以解耦触发器和触发器源之间的事务,并融合相关的数据处理 。
2:避免使用dblink 。
dblink提供的机制可以在一个数据库的存储过程、触发器和数据库函数中方便地访问另一个数据库,并且可以方便地连接一个数据库访问另一个数据库中的数据供应用程序使用,因此给多数据库环境的使用带来了很大的方便 。
但是dblink在跨数据库事务提交中容易出现问题,一般可以用在没有事务的DML简单查询中 。如果一定要带事务,一定要保证事务快速提交,否则很容易造成分布式事务锁 。但应用在使用时,由于运行环境复杂多变,无法100%保证事务的完整性和快速响应,很容易以一定概率触发分布式事务锁和ORACLE bugs 。同时,dblink本身会带来大概率甚至100%的scn跳号bug,并导致scn跳号在数据库间传播 。导致系统故障甚至数据库瘫痪 。所以不要在代码开发中使用dblink 。平时尽量少用运维 。如果一定要用,最好没有事务,尽快释放连接 。
3:禁忌:避免使用大表关联统计 。
在一个系统中,除了实时事务外,对实时数据的统计或查询也有一定的要求 。对于这种数据统计,禁止使用大表关联进行统计,因为这样会导致数据库消耗大量计算资源,占用过多的临时空室,影响其他实时业务的响应甚至使系统无法响应 。
对于这种需要跨多个大型表的统计,最好不要在OLTP数据库中执行 。如果一定要执行,第一,尽量限制数据范围(比如只能根据时间限制统计当天);其次,我们应该将与两个大表相关联的SQL拆分成两个SQL 。前面SQL获取的数据用游标打开后,会一个一个的去另一个大表,逐个访问索引数据,然后用客户端进行统计操作,或者用游标获取数据进行临时生产 。
4.禁忌:不要使用字典字段索引 。
只有当数据分散在索引字段中时,索引才有效 。如果索引是基于一些字典字段(如性别、课程等)建立的 。),不会有很好的效果,还会浪费存储空 。如果这个类似字典的字段必须扮演类似索引的角色,可以根据字典值构建分区键 。
禁忌:谨慎使用主键约束 。
从理论上来说,表的主键似乎是一个很好的机制,但是在一般的应用中,因为主键不能更新,会带来很多运维上的不便 。一般建议慎用,相反可以用非空和唯一性约束代替 。
6.禁忌:谨慎使用外键关联
当一个表的主键被其他表用作非主键时,外键关联可以确保两个表之间的数据一致性 。但是外键关联给程序开发和运维带来了更多的复杂性,良好的开发习惯可以保证有外键关联的两个表满足数据一致性要求 。因此,通常应谨慎使用外键关联 。实际上是基于应用在便捷性和数据一致性之间更倾向于哪个方面来决定使用方式 。


推荐阅读