***************************************
系统DBA工作指南
***************************************
一、 工作内容.
1、产品数据库相关的硬件上线测试, 以及配合SA做硬件的维护
2、产品数据库的监控,备份,恢复. 以及调优
3、协助开发DBA提高应用质量, 积极的与开发以及需求部门沟通, 预测产品数据库的未来风险.
4、定期Review系统的性能, 备份可靠性.
5、不断的提高对于知识与技能, 以及提高压力承受能力.
二、 基本技能
1、Oracle的相关技术学习, Concepts,backup & recovery, Administration & performance tunning, sql tunning & plsql developing.
2、shell 相关技术, 可以使用shell,perl编写简单脚本.
3、unix 系统相关知识, 熟练使用unix/linux的基本命令, 理解unix/linux 内存管理以及进程间通讯的基本知识, 对unix/linux 内核有基本的了解
三、工作范围：
1、日报检查：空间是否足够，数据库是否有异常对象，备份是否正常等。详细内容查看《日报检查规范》。
2、查看statspack：关注数据库各项性能指标是否正常，应用是否正常。
3、数据处理：处理各部门人员通过DBA服务系统提交的数据订正请求。
4、数据库变更：各种项目上线引起的变更，评估与处理开发DBA提交的各种数据库变更请求。
5、数据库日常管理：添加数据文件，备份与恢复，standby数据库维护。
6、数据库异常处理：处理各种紧急情况，比如load异常，数据库宕机，sql导致的性能问题，硬件损坏等。我们要尽可能避免这种事情的发生。
数据库升级与改造：数据库升级，硬件维护，数据迁移等。
四、产品DBA工作技巧：
1.熟悉你所负责的一切：包括主机，存储，数据库，甚至应用。
2.稳定压倒一切，我们可以拒绝任何可能影响数据库稳定性的请求。
3.防患于未然，不要等到事故发生后再想办法解决，我们不需要这样的英雄。
4.操作谨慎小心，严格按照规范执行，将人为误操作的可能性降到最低。
5.犯错并不可怕，最可怕的是重复犯同样的错误。
6.责任心很重要。
5.产品DBA与其他各部门的关系
（1）SA：我们经常需要SA部门的协助与支持，包括硬件，网络，基础架构等方面。
（2）开发DBA：相互配合，产品DBA在项目上线时，也需要了解应用的情况。当发现应用的异常时，需要与开发DBA配合解决问题。
（3）开发人员：我们一般不直接和开发人员打交道，但是必须熟悉和了解他们，很多紧急情况或者数据处理，我们需要和他们合作。
（4）产品设计：产品DBA有时也会参与产品设计，给出从数据库角度出发的专业建议。
************************************
开发DBA工作指南
************************************
做为一个开发DBA，要保障数据库应用的质量，很重要的一点就是必须在项目的每一个阶段都参与到项目组的工作中。这篇文章介绍我从毕业到现在在公司这段时间在做好一个开打DBA方面积累的一点点经验。
开发DBA如何有效地保障数据库应用的质量。
做为一个开发DBA，要保障数据库应用的质量，很重要的一点就是必须在项目的每一个阶段都参与到项目组的工作中。下面就各个阶段说一下我个人认为该做的一些工作吧：
一、需求阶段
要想能在整个项目周期中能够更早的了解项目所涉及到的内容，把握项目范围，而在后面的工作中取得更多的主动权使质量能够得到有效的控制，开发DBA就需要在需求被确认之前就开始参与。
1、项目孕育阶段：
在公司目前的项目流程中，需求阶段实际上是在项目还没有确认是否要做的时候就开始了。在这个时候，一般情况下PD（或者运营）部门可能不会和我们沟通，而是和技术不得RA和架构们沟通，描绘对该项目的一个大概的轮廓和需求，让技术部的同事提出一些对该项目的看法。一个项目最后是否需要做也正是在这个阶段来确定的。所以，这个时候如果RA或者架构对该项目在数据库方面的影响把握的不是很准确的话，可能就会造成后面项目的需求分析和确认的过程中DBA和PD部门之间可能会出现较多分歧。
要解决这个问题一般只有两种办法：一是通过沟通交流或者培训加强RA和架构对我们数据库的了解和把握能力；二是通过各种途径使我们自己能参与到这个阶段。对于第一种办法，好处是可以减少我们的工作量，而坏处就是架构和RA到底能对数据库方面的影响把握到什么程度是没办法很好地控制的。第二种方法的好处是我们能够完全由我们自己把握到项目对数据库的影响，给出更准确的评估，而坏处一是增加了我们的工作量，再就是比较难获得这个阶段的项目相关信息。考虑到这两种方法各自的优劣，在国际站这边我现在实际上是两者一起使用的。平时常通过沟通交流来加强RA和架构对数据库方面的一些了解，偶尔做一点培训。同时也和他们约定，如果有较大动作（或项目）的时候都提前和我们沟通。然后也加强和pd以及运营部门沟通，多了解一些他们的想法和打算，同时也常和他们聊聊网站哪些地方的内容对数据库影响比较大哪些地方比较小，哪些核心内容的调整会影响较大哪些较小，让他们头脑中有一个大概的轮廓，也和他们约定有什么大动作或者想法的时候提前和我们打声招呼。那么，如何让架构师、RA以及PD和运营真正会提前和我们沟通呢？就要靠我们加强和他们的沟通，加强他们对我们的信任程度。我们这边也时常和他们沟通，主动去了解一些他们最近的想法，了解他们的一些困惑。而且通过沟通还可以消除运营或更前端的需求部门认为我们不够配合的误会。其实总的一点来说就是像大师所说的，增强他们对我们的信任感,让他们在有什么想法或者需求的时候就主动想和我们聊聊征求一下我们的意见，这才是最根本的目的和我们的目标。要达到这个目标，最基本也是最有效的方法就是有效的沟通，通过实际行动尽我们的能力去帮助他们解决性能上面的问题，评估项目的影响和风险。在刚开始工作的时候Jacky就和我说过，开发DBA的工作中有一项非常重要的内容，就是需要和很多不同部门不同角色去沟通，所以，沟通技巧也是我们需要很好掌握的。
2、需求分析和确认阶段：
在项目确定了开始要做的时候，一般都会有一个项目kick off会议，也就是项目启动会议，这个时候一般都会叫上我们DBA参加。会议一般主要是公布一个项目的大概时间计划和项目组成员的组成，这个时候就是一个项目真正的开始了。之后接下来就是非常关键的需求分析工作了。这项工作主要由RA来主导，同时PD（或运营）一起参与进行。这个过程中，一般来说RA都会常征求架构师的意见，有时候也会征求我们DBA的意见（主要是RA以他们对数据库的把握能力来判断是否需要我们参与需求分析过程）。一般项目在需求分析过程中都会有两次需求确认会议：商业需求确认会和最终需求确认会，也就是我们常说的BRD确认会合FRD确认会。在项目流程中，我们的开发DBA都是需要参与到这两次会议的。但是有些时候，确认会议上只是向项目开发人员，架构师以及DBA介绍一些商业需求以及在系统中大概的实现逻辑，到这时候，大部分需求其实都已经定下来了。所以，有些时候如果在项目启动前我们没有获取到关于项目足够的信息，在需求分析的过程中又没有任何的情况下，可能会遇到在这个时候才发现该项目某些地方对数据库影响很大，风险较高。而这个时候才提出，很可能就会造成之前的需求分析工作很多都需要返工重新分析重新设计，甚至某些需求根本就无法实现，造成整个项目进度延后，严重的时候还会造成和PD等部门之间误会。所以，在项目启动之后需求确认之前，一定要常和RA沟通，跟进项目进度和相关细节。有任何问题疑问都要尽早提出，表名观点。对于比较重要的问题，一定要和RA以及PD等部门的人坐在一起当面沟通，说明问题的所在，并给出我们的建议（如果有）。
二、开发阶段
1、系统设计阶段
当需求完全确定下来后，开发人员就会开始进行系统设计的工作了。一般来说开发人员都会首先设计数据库schema（如果有建新表的需求），然后才是程序的设计。这个时候我们的重点沟通对象就从RA转移到开发工程师了。有些开发工程师可能会主动来找我们，沟通schema设计方面的一些内容，而有些开发工程师可能就不会和我们沟通，而是自己直接自己完成schema设计，然后就交给我们直接要求建表了。而往往那些不会主动找我们的开发工程师大多都是一些新手，更容易出问题，相对来说一些较为资深和能力较强的开发工程师反而都会和我们沟通一下，即使是一些很简单的表，也至少会先和我们说一下。所以，在项目启动会议的时候我们就该注意一下项目中负责开发的工程师情况。通过我们对他们的了解来判断对哪些人需要多花一点精力去跟进，哪些人是可以放心少花一些精力去跟进。当交道打的多了以后，肯定对每个人的工作习惯，做事态度等都有一个大致了解。
实际上不仅仅表结构的设计我们需要关注，有些时候他们程序的实现方法也需要了解一些，尤其是在实现一些我们认为比较重要或影响比较大的功能点需求的时候，我们最好是去了解一下他们是怎么来设计实现的。不同的实现会给数据库带来不一样的压力，一个好的实现所需要的数据库资源和一个较差的设计实现相比，有些时候的差别甚至都不是一个数量级的。当遇到较差的实现的时候，我们可以适当的提出一些我们的建议，如果遇到困难，也可以向架构师来寻求帮助。这也是我们要求开发DBA最好要有一定开发经验，对开发有一定的了解的原因之一。因为如果完全不懂开发，可能就无法在设计实现上面发现问题了。而且在这个过程中，通过不断的去和他们沟通，也可以让我们自己学习到更多的系统设计方面的知识和并积累相关经验，为今后更好的处理问题以及对项目影响的把握是有很大帮助的。而且在系统设计层面的关注，对于自身能力的提高也是非常有帮助的。对于一个DBA来说，最关注的就是系统的质量，系统的性能。而对于一个开发人员或者项目经理来说，可能更关注如何快速的实现需求，完成一个可交付使用的产品。一个DBA关注较多的系统设计和架构方面的内容以后，才能有更开阔的视野，才可能从更高的层面来掌控项目的质量和性能。不论是对于自身的能力还是以后的发展，不论是开发DBA还是产品DBA抑或是以后转型架构师，都会有很大的帮助。
2、开发编码阶段
当系统设计结束后，开发工程师就开始进行编码工作了。在这个过程中，有些开发工程师可能会随时主动的将自己认为比较重要或把握不准是否有性能问题的sql发给我们，征求我们的建议，但有些开发工程师是不会的，需求我们主动去找他们要。可能大家会说，我们可以等项目开发完成，提交测试的时候控制他们测试库的变更的时候让他们一次性的提交sql给我们，然后我们再集中review所有的sql。在项目周期不长范围较小，同时并行的项目也比较少的时候这样做确实是没有太多问题的，但是一旦同时有多个项目并行，或者项目比较大的话，就会出现问题了。最大的一个问题就是sql review的时间问题。如果一次性提交了很多的sql过来，很可能最后sql review过程就会成为项目的瓶颈，我们自己也会压力比较大，没办法尽可能的对一些sql进行较好的优化。再一个就是有些在review过程中发现的有些问题比较严重的sql的调整可能涉及到程序逻辑的改动，如果改动涉及到程序的变动比较大的话，开发工程师的返工工作量就会较大，不是很情愿配合，也会影响项目的进度。像我这边国际站，并行项目非常多，有些项目周期拉的也比较长，我一般都是在项目边开发的时候就边和他们沟通，即使有些时候并不是正式的让他们提交sql，也会和他们沟通一下他们有没有遇到数据库方面的问题或者困惑。经常这样和他们沟通后，很多人慢慢就会有了一个习惯，只要是自己觉得稍微有点拿捏不准的sql，都会直接拿来问我一下。虽然这个时候他们的判断可能并不一定准确，但是对于稍微较为复杂的sql他们肯定都会先发给我们看看，如果sql有什么问题我们就能马上开始优化，或者调整程序实现逻辑来解决掉，而不用等到所有代码都开发好了才开始做这件事情。这样在项目最后的sql review的工作实际上是在项目进行过程中就已经在慢慢进行了，我们自己最后的review工作时间也就更宽裕一些了，同时也可以让他们养成一个好的习惯。当然，即使是这种方法，我们在最后也应该让他们整理一遍用到的所有sql并发给我们。
三、测试和最后发布阶段
一个项目进入测试阶段后也是现在项目流程中所规定的开始review sql的时间，如果在之前的开发阶段我们就已经做了较多的工作，那么在这个阶段的时候可能就会比较容易控制了，但是如果之前没有做什么工作，所有sql都在这个时候才开始review，就需要把握好review的进度了。同时，在测试过程中，可能会因为修改某些bug，开发工程师改写某些sql，而这也是开发工程师最容易忘记将sql提交给我们的时候。所以在测试阶段我们在review开发工程师之前提交的所有sql的时候，同时也要不断的和测试沟通bug出现情况，和开发沟通有没有改动过什么sql。随时掌握sql的变动，才能随时掌控项目的性能质量。
在最后我们手上应该有一个文件，里面保存着这个项目中新增或者修改的所有sql，因为我们需要根据这份完整的sql文件来完善索引，之前sql没有完全定下来的时候你所创建的索引有些可能到这个时候有些已经不适用了。
项目测试结束了，我们也review完开发工程师给我们的sql了，这个时候我们最好再加一道保险，那就是从发布人员那边了解一下发布的文件列表，看看有没有我们没有看过的sql mapping文件的发布。像现在，国际站这边我就和配置管理员约定好了，项目发布的时候，她记下发布中需要更新哪些sql mapping文件并告诉我，随便什么方式都行，不管是mail还是贸易通都可以，这样我至少可以控制不要某个mapping文件里面的sql有变动我这边都完全不知道。当然这个工作本身并不是配置管理员的本职工作，她是否愿意帮这个忙就得靠我们自己了，呵呵。
四、发布后阶段
项目发布了，RA可能开始了一个新项目的需求分析，开发工程师可能又开始做其他项目去了，这个时候我们并不能马上就完全不去理会这个项目了，因为这个时候才是真正考验我们之前所做的工作成果的开始。我们需要多看看产品数据库上面整体压力情况，看看这个项目所涉及到的那些sql有没有冒出来成为top sql。如果一切正常，那至少说明我们之前的工作没有太多问题。如果发现里面有sql冒出来了，应该马上分析为什么会冒出来？执行计划和我们当初预想的是否一致？执行频率是否正常？之前准备的索引是否合理？然后着手优化，解决掉冒出来的sql。这个时候的优化工作必须要谨慎，对于已有系统上对象的任何改动都需要三思：是否会引起某些sql语句执行计划的改变，是否会让某些对象失效等等。
有些项目发布一段时间后会有一个项目总结会，总结项目过程中的一些经验教训，这个时候我们也应该从我们的角度提出对项目的看法，不管是好的还是不好的，这样做同时也可以让大家对数据库有更多一点的了解，更多一点的关注。
系统DBA工作指南
***************************************
一、 工作内容.
1、产品数据库相关的硬件上线测试, 以及配合SA做硬件的维护
2、产品数据库的监控,备份,恢复. 以及调优
3、协助开发DBA提高应用质量, 积极的与开发以及需求部门沟通, 预测产品数据库的未来风险.
4、定期Review系统的性能, 备份可靠性.
5、不断的提高对于知识与技能, 以及提高压力承受能力.
二、 基本技能
1、Oracle的相关技术学习, Concepts,backup & recovery, Administration & performance tunning, sql tunning & plsql developing.
2、shell 相关技术, 可以使用shell,perl编写简单脚本.
3、unix 系统相关知识, 熟练使用unix/linux的基本命令, 理解unix/linux 内存管理以及进程间通讯的基本知识, 对unix/linux 内核有基本的了解
三、工作范围：
1、日报检查：空间是否足够，数据库是否有异常对象，备份是否正常等。详细内容查看《日报检查规范》。
2、查看statspack：关注数据库各项性能指标是否正常，应用是否正常。
3、数据处理：处理各部门人员通过DBA服务系统提交的数据订正请求。
4、数据库变更：各种项目上线引起的变更，评估与处理开发DBA提交的各种数据库变更请求。
5、数据库日常管理：添加数据文件，备份与恢复，standby数据库维护。
6、数据库异常处理：处理各种紧急情况，比如load异常，数据库宕机，sql导致的性能问题，硬件损坏等。我们要尽可能避免这种事情的发生。
数据库升级与改造：数据库升级，硬件维护，数据迁移等。
四、产品DBA工作技巧：
1.熟悉你所负责的一切：包括主机，存储，数据库，甚至应用。
2.稳定压倒一切，我们可以拒绝任何可能影响数据库稳定性的请求。
3.防患于未然，不要等到事故发生后再想办法解决，我们不需要这样的英雄。
4.操作谨慎小心，严格按照规范执行，将人为误操作的可能性降到最低。
5.犯错并不可怕，最可怕的是重复犯同样的错误。
6.责任心很重要。
5.产品DBA与其他各部门的关系
（1）SA：我们经常需要SA部门的协助与支持，包括硬件，网络，基础架构等方面。
（2）开发DBA：相互配合，产品DBA在项目上线时，也需要了解应用的情况。当发现应用的异常时，需要与开发DBA配合解决问题。
（3）开发人员：我们一般不直接和开发人员打交道，但是必须熟悉和了解他们，很多紧急情况或者数据处理，我们需要和他们合作。
（4）产品设计：产品DBA有时也会参与产品设计，给出从数据库角度出发的专业建议。
************************************
开发DBA工作指南
************************************
做为一个开发DBA，要保障数据库应用的质量，很重要的一点就是必须在项目的每一个阶段都参与到项目组的工作中。这篇文章介绍我从毕业到现在在公司这段时间在做好一个开打DBA方面积累的一点点经验。
开发DBA如何有效地保障数据库应用的质量。
做为一个开发DBA，要保障数据库应用的质量，很重要的一点就是必须在项目的每一个阶段都参与到项目组的工作中。下面就各个阶段说一下我个人认为该做的一些工作吧：
一、需求阶段
要想能在整个项目周期中能够更早的了解项目所涉及到的内容，把握项目范围，而在后面的工作中取得更多的主动权使质量能够得到有效的控制，开发DBA就需要在需求被确认之前就开始参与。
1、项目孕育阶段：
在公司目前的项目流程中，需求阶段实际上是在项目还没有确认是否要做的时候就开始了。在这个时候，一般情况下PD（或者运营）部门可能不会和我们沟通，而是和技术不得RA和架构们沟通，描绘对该项目的一个大概的轮廓和需求，让技术部的同事提出一些对该项目的看法。一个项目最后是否需要做也正是在这个阶段来确定的。所以，这个时候如果RA或者架构对该项目在数据库方面的影响把握的不是很准确的话，可能就会造成后面项目的需求分析和确认的过程中DBA和PD部门之间可能会出现较多分歧。
要解决这个问题一般只有两种办法：一是通过沟通交流或者培训加强RA和架构对我们数据库的了解和把握能力；二是通过各种途径使我们自己能参与到这个阶段。对于第一种办法，好处是可以减少我们的工作量，而坏处就是架构和RA到底能对数据库方面的影响把握到什么程度是没办法很好地控制的。第二种方法的好处是我们能够完全由我们自己把握到项目对数据库的影响，给出更准确的评估，而坏处一是增加了我们的工作量，再就是比较难获得这个阶段的项目相关信息。考虑到这两种方法各自的优劣，在国际站这边我现在实际上是两者一起使用的。平时常通过沟通交流来加强RA和架构对数据库方面的一些了解，偶尔做一点培训。同时也和他们约定，如果有较大动作（或项目）的时候都提前和我们沟通。然后也加强和pd以及运营部门沟通，多了解一些他们的想法和打算，同时也常和他们聊聊网站哪些地方的内容对数据库影响比较大哪些地方比较小，哪些核心内容的调整会影响较大哪些较小，让他们头脑中有一个大概的轮廓，也和他们约定有什么大动作或者想法的时候提前和我们打声招呼。那么，如何让架构师、RA以及PD和运营真正会提前和我们沟通呢？就要靠我们加强和他们的沟通，加强他们对我们的信任程度。我们这边也时常和他们沟通，主动去了解一些他们最近的想法，了解他们的一些困惑。而且通过沟通还可以消除运营或更前端的需求部门认为我们不够配合的误会。其实总的一点来说就是像大师所说的，增强他们对我们的信任感,让他们在有什么想法或者需求的时候就主动想和我们聊聊征求一下我们的意见，这才是最根本的目的和我们的目标。要达到这个目标，最基本也是最有效的方法就是有效的沟通，通过实际行动尽我们的能力去帮助他们解决性能上面的问题，评估项目的影响和风险。在刚开始工作的时候Jacky就和我说过，开发DBA的工作中有一项非常重要的内容，就是需要和很多不同部门不同角色去沟通，所以，沟通技巧也是我们需要很好掌握的。
2、需求分析和确认阶段：
在项目确定了开始要做的时候，一般都会有一个项目kick off会议，也就是项目启动会议，这个时候一般都会叫上我们DBA参加。会议一般主要是公布一个项目的大概时间计划和项目组成员的组成，这个时候就是一个项目真正的开始了。之后接下来就是非常关键的需求分析工作了。这项工作主要由RA来主导，同时PD（或运营）一起参与进行。这个过程中，一般来说RA都会常征求架构师的意见，有时候也会征求我们DBA的意见（主要是RA以他们对数据库的把握能力来判断是否需要我们参与需求分析过程）。一般项目在需求分析过程中都会有两次需求确认会议：商业需求确认会和最终需求确认会，也就是我们常说的BRD确认会合FRD确认会。在项目流程中，我们的开发DBA都是需要参与到这两次会议的。但是有些时候，确认会议上只是向项目开发人员，架构师以及DBA介绍一些商业需求以及在系统中大概的实现逻辑，到这时候，大部分需求其实都已经定下来了。所以，有些时候如果在项目启动前我们没有获取到关于项目足够的信息，在需求分析的过程中又没有任何的情况下，可能会遇到在这个时候才发现该项目某些地方对数据库影响很大，风险较高。而这个时候才提出，很可能就会造成之前的需求分析工作很多都需要返工重新分析重新设计，甚至某些需求根本就无法实现，造成整个项目进度延后，严重的时候还会造成和PD等部门之间误会。所以，在项目启动之后需求确认之前，一定要常和RA沟通，跟进项目进度和相关细节。有任何问题疑问都要尽早提出，表名观点。对于比较重要的问题，一定要和RA以及PD等部门的人坐在一起当面沟通，说明问题的所在，并给出我们的建议（如果有）。
二、开发阶段
1、系统设计阶段
当需求完全确定下来后，开发人员就会开始进行系统设计的工作了。一般来说开发人员都会首先设计数据库schema（如果有建新表的需求），然后才是程序的设计。这个时候我们的重点沟通对象就从RA转移到开发工程师了。有些开发工程师可能会主动来找我们，沟通schema设计方面的一些内容，而有些开发工程师可能就不会和我们沟通，而是自己直接自己完成schema设计，然后就交给我们直接要求建表了。而往往那些不会主动找我们的开发工程师大多都是一些新手，更容易出问题，相对来说一些较为资深和能力较强的开发工程师反而都会和我们沟通一下，即使是一些很简单的表，也至少会先和我们说一下。所以，在项目启动会议的时候我们就该注意一下项目中负责开发的工程师情况。通过我们对他们的了解来判断对哪些人需要多花一点精力去跟进，哪些人是可以放心少花一些精力去跟进。当交道打的多了以后，肯定对每个人的工作习惯，做事态度等都有一个大致了解。
实际上不仅仅表结构的设计我们需要关注，有些时候他们程序的实现方法也需要了解一些，尤其是在实现一些我们认为比较重要或影响比较大的功能点需求的时候，我们最好是去了解一下他们是怎么来设计实现的。不同的实现会给数据库带来不一样的压力，一个好的实现所需要的数据库资源和一个较差的设计实现相比，有些时候的差别甚至都不是一个数量级的。当遇到较差的实现的时候，我们可以适当的提出一些我们的建议，如果遇到困难，也可以向架构师来寻求帮助。这也是我们要求开发DBA最好要有一定开发经验，对开发有一定的了解的原因之一。因为如果完全不懂开发，可能就无法在设计实现上面发现问题了。而且在这个过程中，通过不断的去和他们沟通，也可以让我们自己学习到更多的系统设计方面的知识和并积累相关经验，为今后更好的处理问题以及对项目影响的把握是有很大帮助的。而且在系统设计层面的关注，对于自身能力的提高也是非常有帮助的。对于一个DBA来说，最关注的就是系统的质量，系统的性能。而对于一个开发人员或者项目经理来说，可能更关注如何快速的实现需求，完成一个可交付使用的产品。一个DBA关注较多的系统设计和架构方面的内容以后，才能有更开阔的视野，才可能从更高的层面来掌控项目的质量和性能。不论是对于自身的能力还是以后的发展，不论是开发DBA还是产品DBA抑或是以后转型架构师，都会有很大的帮助。
2、开发编码阶段
当系统设计结束后，开发工程师就开始进行编码工作了。在这个过程中，有些开发工程师可能会随时主动的将自己认为比较重要或把握不准是否有性能问题的sql发给我们，征求我们的建议，但有些开发工程师是不会的，需求我们主动去找他们要。可能大家会说，我们可以等项目开发完成，提交测试的时候控制他们测试库的变更的时候让他们一次性的提交sql给我们，然后我们再集中review所有的sql。在项目周期不长范围较小，同时并行的项目也比较少的时候这样做确实是没有太多问题的，但是一旦同时有多个项目并行，或者项目比较大的话，就会出现问题了。最大的一个问题就是sql review的时间问题。如果一次性提交了很多的sql过来，很可能最后sql review过程就会成为项目的瓶颈，我们自己也会压力比较大，没办法尽可能的对一些sql进行较好的优化。再一个就是有些在review过程中发现的有些问题比较严重的sql的调整可能涉及到程序逻辑的改动，如果改动涉及到程序的变动比较大的话，开发工程师的返工工作量就会较大，不是很情愿配合，也会影响项目的进度。像我这边国际站，并行项目非常多，有些项目周期拉的也比较长，我一般都是在项目边开发的时候就边和他们沟通，即使有些时候并不是正式的让他们提交sql，也会和他们沟通一下他们有没有遇到数据库方面的问题或者困惑。经常这样和他们沟通后，很多人慢慢就会有了一个习惯，只要是自己觉得稍微有点拿捏不准的sql，都会直接拿来问我一下。虽然这个时候他们的判断可能并不一定准确，但是对于稍微较为复杂的sql他们肯定都会先发给我们看看，如果sql有什么问题我们就能马上开始优化，或者调整程序实现逻辑来解决掉，而不用等到所有代码都开发好了才开始做这件事情。这样在项目最后的sql review的工作实际上是在项目进行过程中就已经在慢慢进行了，我们自己最后的review工作时间也就更宽裕一些了，同时也可以让他们养成一个好的习惯。当然，即使是这种方法，我们在最后也应该让他们整理一遍用到的所有sql并发给我们。
三、测试和最后发布阶段
一个项目进入测试阶段后也是现在项目流程中所规定的开始review sql的时间，如果在之前的开发阶段我们就已经做了较多的工作，那么在这个阶段的时候可能就会比较容易控制了，但是如果之前没有做什么工作，所有sql都在这个时候才开始review，就需要把握好review的进度了。同时，在测试过程中，可能会因为修改某些bug，开发工程师改写某些sql，而这也是开发工程师最容易忘记将sql提交给我们的时候。所以在测试阶段我们在review开发工程师之前提交的所有sql的时候，同时也要不断的和测试沟通bug出现情况，和开发沟通有没有改动过什么sql。随时掌握sql的变动，才能随时掌控项目的性能质量。
在最后我们手上应该有一个文件，里面保存着这个项目中新增或者修改的所有sql，因为我们需要根据这份完整的sql文件来完善索引，之前sql没有完全定下来的时候你所创建的索引有些可能到这个时候有些已经不适用了。
项目测试结束了，我们也review完开发工程师给我们的sql了，这个时候我们最好再加一道保险，那就是从发布人员那边了解一下发布的文件列表，看看有没有我们没有看过的sql mapping文件的发布。像现在，国际站这边我就和配置管理员约定好了，项目发布的时候，她记下发布中需要更新哪些sql mapping文件并告诉我，随便什么方式都行，不管是mail还是贸易通都可以，这样我至少可以控制不要某个mapping文件里面的sql有变动我这边都完全不知道。当然这个工作本身并不是配置管理员的本职工作，她是否愿意帮这个忙就得靠我们自己了，呵呵。
四、发布后阶段
项目发布了，RA可能开始了一个新项目的需求分析，开发工程师可能又开始做其他项目去了，这个时候我们并不能马上就完全不去理会这个项目了，因为这个时候才是真正考验我们之前所做的工作成果的开始。我们需要多看看产品数据库上面整体压力情况，看看这个项目所涉及到的那些sql有没有冒出来成为top sql。如果一切正常，那至少说明我们之前的工作没有太多问题。如果发现里面有sql冒出来了，应该马上分析为什么会冒出来？执行计划和我们当初预想的是否一致？执行频率是否正常？之前准备的索引是否合理？然后着手优化，解决掉冒出来的sql。这个时候的优化工作必须要谨慎，对于已有系统上对象的任何改动都需要三思：是否会引起某些sql语句执行计划的改变，是否会让某些对象失效等等。
有些项目发布一段时间后会有一个项目总结会，总结项目过程中的一些经验教训，这个时候我们也应该从我们的角度提出对项目的看法，不管是好的还是不好的，这样做同时也可以让大家对数据库有更多一点的了解，更多一点的关注。
其实总的来说，要想控制好一个项目中数据库应用的质量，就必须让自己在项目的整个阶段随时了解项目当前情况，分析清楚状况，让自己处于主动的状态处理各种事情，而不是仅仅在最后看看开发工程师写出并提交给我们的sql，这只是最我们最基本的工作之一而已。
**********本博客所有内容均为原创，如有转载请注明作者和出处!!!**********
Name: guoyJoe
QQ: 252803295
Email: oracledba_cn@hotmail.com
Blog: http://blog.csdn.net/guoyJoe
ITPUB: http://www.itpub.net/space-uid-28460966.html
OCM: http://education.oracle.com/education/otn/YGuo.HTM
_____________________________________________________________
加群验证问题：哪些SGA结构是必需的，哪些是可选的？否则拒绝申请!!!
答案在：http://blog.csdn.net/guoyjoe/article/details/8624392
DSI&Core Search Ⅰ群：127149411（加群验证信息回复：from guoyJoe@csdn）
DSI&Core Search Ⅱ 群：177089463 （加群验证信息回复：from guoyJoe@csdn）
DSI&Core Search Ⅲ群： 284596437（加群验证信息回复：from guoyJoe@csdn）DSI&Core Search Ⅳ 群：192136702（加群验证信息回复：from guoyJoe@csdn）
DSI&Core Search Ⅴ群：285030382（加群验证信息回复：from guoyJoe@csdn）
扫一扫
358
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
