创新谈-冯皓洁

创新性应用：

近年来越来越多的软件开发模式，都是尽量的将数据库的访问以数据持久层的方式隔离开，使访问数据库的细节被屏蔽起来。同时也屏蔽掉了后台不同数据库的差异。这样做代表了整个软件开发方向，即软件开发的模块化，组件化，每层，每功能层次调用直接的独立性。这个观点是无可厚非的，也是正确的发展方向。但由于特定组件对数据库访问包装的功能的强弱，会导致某些对数据库访问和操作的低效率。SQL语句是对数据库访问的一个表达语句，他并不关心数据是如何从数据库里取出来的，是否合理，是否效率高，则是DBMS来负责的。但是，就目前的数据库管理系统来说，做到随意的数据访问的高效率，并自动解决效率的问题还是有一定困难的。因为这其中会包括存储子系统，操作系统，和访问数据等方面的诸多因素。而机器本身又不太可能了解到那么多丰富的外界环境因素，并且还有一些非技术的因素在内。所以，在现有条件，和访问效率方面的综合协调或者说相互平衡的过程中DBA的作用就不能被忽视。DBA要完成很多机器所无法完成的事情。当然，随着计算机技术的发展，以前很多必须由DBA来手动判断并处理的问题现在都已经可以自动实现了，比如Oracle的CBO，代替了以前的RBO使SQL语句的访问策略大大的简化了，使DBA从繁重的优化SQL语句中解脱出来，还有后来的自动管理的回滚段，都是实际的例子。

回到刚才的话题，就是说就目前的情况来讲还不是所有的工作和判断都能由数据库管理系统自动完成。所以说目前很多的自动屏蔽的数据库访问层的效率问题对于大数据量大并发的关键性业务来说就不太合适了。所以有必要针对特定的功能，进行特句的数据库访问语句的开发。这样可能无法享受到自动化产品的方便，但是换回了高性能的数据访问，同时也减轻了数据库的压力。

 

 

 

 

 

行业借鉴经验：

所谓的数据库管理分为两种,一种是小型数据库的管理,另一种是大型数据库系统。小型数据库的管理相对比较简单，无论是数据量和同时访问的并发用户数都不很多。所以只需要基本的知识和操作技能就可以满足。但是对于大型数据库系统来说，都面临着数据量大，高的访问并发，高的可用性限制。

对于大数据量访问性质的应用来说，首先要保证服务器的处理能力满足用户应用的处理负荷。并在一定程度上要满足用户3年内的业务增长的潜在的压力。所以数据库服务器的选项是数据库系统能否安全稳定运行的基础和前提。没有一个合适的数据库服务器，后续的一切对处理能力，和处理效率的努力都将是没有意义的。

一个数据库服务器的选行要根据用户的应用来定。首先分析用户应用的访问性质。是小数量大批量访问的OLTP在线处理应用，还是数据量大，数量相对较少的批处理应用（这里包括OLAP在线分析和决策支持DSS系统）。服务器选项包括CPU的主频，CUP的数量，内存的数量，IO访问接口的数量。一个服务器的性能是各个部件和处理系统合作完成的综合表现。所以也不能单一，片面的看某一个单元设备的性能。服务器厂商公布的TPCC值是对于服务器处理能力的一个综合评判。

CPU的处理能力是相当关键的，如果在优化了数据库访问SQL和程序结构以后仍然发现CPU的处理能力不够的时候，就应该考虑增加数据库服务器的CPU的数量，一般大型的服务器都是插入新的CPU板来增加CPU。

内存的容量也决定着一个数据库应用系统的处理能力。我们都知道所有的数据操作都是在内存中完成的。如果内存的容量不够的时候就会发生由于内存缓冲区不够而导致的频繁的系统页面交换的发生，从而发生大量的磁盘IO操作。足够大的内存可以保证需要访问的数据尽量能在内存缓冲区中命中。这样便最大限度的避免了磁盘IO的交换。因为IO的操作将会很大的降低系统出来速度，IO的访问速度是访问内存的几千分之一。

磁盘子系统的选择也是十分重要的。当大数据量的数据操作和访问过程中磁盘操作是难以避免的，高速度的磁盘子系统对于提高系统整体访问速度有相当重要的作用。

应用系统的处理过程和程序结构对应用系统的访问效率也起到非常重阳的影响。SQL语句的写法，和CBO统计信息的准确，还有正确的索引的建立能保证最大程度上的减少对磁盘IO的操作，提高系统访问速度最有效的措施就是减少磁盘操作。在这个前提的指导方针下，优化程序结构，优化SQL语句将会起到明显的效果。

 

 

 

应用难点技巧：

对于数据库性能调整方面：

性能问题的定位：性能的问题最终是反映在客户的操作界面的反应迟缓，或者报表生成时间太长等问题。但是究竟是什么原因导致的反应速度缓慢还是不太容易找到的。因为很多原因都会导致最终用户的反映慢。其中包括CPU，内存，网络，磁盘IO，SQL语句的问题，不正确的索引策略，甚至没有索引，还有程序结构的问题也是影响系统效率的关键因素。

对于数据库系统cpu，内存，缓冲区，和索引方面的问题定位可以借助于Oracle提供的性能检查包来完成。另外oracle也提供了一系列的性能和SQL语句检查工具，在企业管理器里可以找到。

但是对于应用程序结构的问题，这些工具就无能为力了。因为这些工具是针对Oracle数据库自身问题的检查和分析，这些工具只能间接的以一些SQL语句的执行次数，和执行时间，CUP的耗用，IO时间的占用来反应应用系统的问题。 我们可以分析业务逻辑来检查对于数据库访问的效率问题。

对于业务逻辑大部分存放于存储过程里的程序，我们可以方便的看到业务逻辑实现的每一个环节。但对于近年来比较常见的3层结构，比如J2EE和Dot Net程序，他们的业务逻辑一般是有企业java bean来实现，或者是Dot Net 组建来实现。这对于DBA来说检查和发现问题就比较困难。需要和开发和设计人员共同参与来定位和解决问题。另外，由于一些持久层组件对数据库的封装使得数据库的访问性能难以保证，因为这些代码都是程序自动完成的，DBA无法直接参与sql语句的优化，所以有条件的话可以考虑更改业务逻辑到持久层的业务代码，这样就可以根据业务的特点编写合适的，效率高的SQL语句。

 

 

 

 

 

 

 

 

文章请同时提交信箱：[e-mail]  [e-mail]