Archive for January, 2008
开发DBA如何有效地保障数据库应用的质量
Saturday, January 26th, 2008
做为一个开发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，这只是最我们最基本的工作之一而已。
dba跳舞记
Friday, January 25th, 2008
一日上午，突然发现被推荐去春节晚会节目组，甚为高兴，终于有了人生第一次登台献丑的机会，哈哈。
午饭后，去找导演面试，心想，该导演会不会玩潜规则，嘎嘎。没想到导演乃一美女，说话手捂嘴，心想该美女是不是兔唇，汗！
晚上排练，突然发现是跳舞，我狂晕，本以为会是小品相声，舞蹈 舞蹈 如何是好！！！
舞蹈老师来了，更是一大美女，心想还是兄弟好，见美女的机会都让给我。
开始跳舞了，老师把衣服（外套）一脱，同学们异口同声的说“里面是什么？”，老师说“先跳！”，同学们又说“跳完再看？”。
又一日，老师教动作，某男怎么也不会，老师就说你上小学的时候没有学过广播体操呀？某男很不好意思地说我没有上过小学，全倒。
还有我，某一动作，手和腿总是不一致，老师单独教我，大家都在看，10分钟了，还没有学会，张导受不了了“见过没基础的，没见过这么没基础的！”
感想：
评审前大家都很紧张，我更紧张，万一忘了怎么办？
没想到上台后大家都还可以，眼睛已经来不及看下面的观众了，看不到观众心里当然什么也不会想，心里什么都不想，当然也不紧张。
原来上台没有想象的那么可怕。
辛辛苦苦排练这么多天，希望最后一次评审不要被砍掉。
MS SQL SERVER的日志恢复概念
Friday, January 25th, 2008
关于数据库日志恢复的概念,我是在SQL SERVER里面弄清楚的,后来转做oracle后,基本没花什么精力来理解这一块,两者算是异曲同工,现在把以前写的老贴拖出来,大伙也可以体验下这种换汤不换药的东西,呵呵
物理日志文件：
这个比较好理解，实实在在的东西，数据库目录下面的.ldf文件就是，有些人喜欢改后缀，感觉不大好，数据库的事务日志记录就在这里面
虚拟日志：
对于一个或多个连续的物理日志文件，SQL SERVER在这些文件的内部又划分成了多个小的文件，称为虚拟日志文件，他是日志文件收缩和日志截断的最小单位，比如物理日志文件是400M，内部划分了4个100M的虚拟文件，收缩时你得到的是300M，200M，不可能得到239M，对于一个物理文件，会划分成多少个虚拟文件，这个由SQL自己维护，唯一可以人工干预的是指定较大的物理日志文件，并指定较大的增长比例，这样可能虚拟文件的块头会大点，数量会少点，系统的维护开销会低一点
逻辑日志：
感觉这个应该是数据库事务日志的真实写照，物理日志文件好比是一个容器，里面容纳的是日志记录，这些记录就称为逻辑日志，从物理日志文件的起点开始，逻辑日志顺序的生成，记录下数据库里发生的每个事务，这些事务被打上一个标签，LSN，顺序的排列下来，这样逻辑日志就在物理日志文件内慢慢的成长，直到充满了他，这个时候物理日志文件就会自动添加新的空间，以继续前面的步骤，这种情况是最直接的一种（从来不截断日志，基本上就是这样的），但事实上往往是复杂的多
检测点(checkpoint)和恢复周期(recovery interval)：
checkpoint不是用于检查数据是否完整，页面连接是否正确的，他是由系统维护的一个进程（你也可以手工的执行），用于将高速缓存里的脏页刷新到磁盘，两者的配合算是惟妙惟肖，当缓存中的脏页积累到一定的数量，SQL估计演算这些脏页要花的时间快要接近设定的recovery interval（分钟）时，系统就会产生一个checkpoint，所以checkpoint的产生不是定时的，它由recovery interval和数据库的更新频繁度决定。如果你的数据库永远不用重启，永远不会出现什么故障，就这么一直运行下去，那么checkpoint和recovery interval就没有想象中的重要了，SQL总是先写日志，情况应该是这样的：用户提交一个更新操作，SQL在高速缓存里缓冲了需要的数据页和日志页，然后打上begin tran标签，对日志进行修改，再修改数据页，然后打上commit tran标签，最后把修改过的日志页刷新到磁盘上，在保证了这个步骤完成后，数据页才被写入磁盘，如果这个时候机器突然断电导致高速缓存中数据页的丢失，那么重启机器时SQL的恢复进程将根据已经刷新的日志记录来演算刚才的数据页，保证数据的完整性，这就好比支票已经开到了，但货却在路上丢了，凭借支票，你还是可以得到你的东西,像这种提交了又还没来得及刷新数据页到磁盘的日志事务可以称为活动日志，虽然概念不是这么定义的，但可以这么理解，因为一旦日志记录和其对应的数据页被刷新到磁盘的话，这条日志的作用也就完成了，并称为非活动的日志，他的唯一用处就是备份下来留着以后做日志恢复，所以SQL的逻辑日志你就应该知道大概是怎么个样子了，前面一大部分，是已经演算的日志记录（非活动日志），后面一部分，是还没有演算的（活动日志），活动部分的第一条事务称为MinLSN，系统会搁段时间利用检测点（checkpoint）演算活动日志，来缩短数据库重启时的恢复时间，在演算结束后，checkpoint会在日志里打上一个结束语，并将MinLSN标识给下一个紧跟着的活动事务日志，这也是下一个checkpoint的起点
截断事务日志：
这个概念很是让初学者费解，截断是什么意思？？？截断后日志还会增长吗？？？截断总有个断点吧，他是从哪里开始截断的阿？？？截断后会释放日志空间吗？？？等等。。。。现在逐一击破
首先截断是对SQL逻辑日志的一个清除过程，清除非活动的逻辑事务日志。可以想象断点应该是活动与非活动的边界处–MinLSN，他会将MinLSN前面的这段日志清除掉,逻辑日志的起点也会指向断点MinLSN处，清除出来的空间并不会返还给操作系统，而是被标识为非活动的虚拟日志文件，他表示当有新的日志记录进来时，这些空间可以被再次利用，所以截断日志并不会减小物理日志文件的大小，只是清理了里面的一些内容，以便新的日志记录可以进来，SQL总是以循环链表的方式使用物理日志文件的，当逻辑日志增长到物理日志文件的尽头时，他会循环到日志文件的首部搜索被截断而释放出来的空间，如果这个时候没有空间的话，说明物理日志已经用完了，就得增加物理日志的大小，如果磁盘也用尽了，系统就会返回一个错误提示。至于截断后日志是否还会增长，疑点可能存在于trunc log on chkpt上，当数据库处于这种状态时用户会发现他们的日志文件总是那么小一点点，道理很简单，检查点截断日志后，日志文件里面总会有空间容纳新的日志记录，自然是不会变大了，但也有特殊情况，当一个较长的事务运行时（比如一个长达2个小时的UPDATE语句），他会迅速的充满日志，并补充新的空间进来，这个时候系统是来不及截断的，这样物理日志文件就马上变大了，当事务完成后，截断再进行时，对文件的大小他是无能为力了，只是清理下刚才的战场而已，所以截断日志后逻辑日志是继续增长的，至于物理日志，要看你提交事务的大小了
最后的话题：
经常听到这样的说法，定期转存事务日志，以释放日志空间，backup log…with no_log,backup log…with truncate_only,这些只能使日志文件不变大，要想减小日志文件，还的收缩日志文件，这样才真正将空间返还给操作系统，在sybase里面truncate_only和no_log还是有区别的，都是截断日志，但前者在截断之前会启动checkpoint,所以当你的日志完全被充满，truncate_only是不能成功的，他已经没有空间让你checkpoint，这时只能采用no_log(SQL里面我还不知道)，还有一个关键字就是no_truncate,他表示备份但不截断日志（默认是截断的），在数据库因故障损坏时用这个备份日志特别有效
dmx4的ssd可用于oracle数据库么？
Thursday, January 24th, 2008
参考大辉的blog中信息有提到 ssd的可搽写次数为 200w次，那么计算下来，假如平均每分钟搽写一次，则可支持接近4年。 那么看起来 oracle redo log 要放在上面是否合适呢？ 如果是相同存储位置被搽写多次的话，应该也是没问题的。对于整个盘来说这是没道理的了。 那么看起来对于oracle数据库来说这不应该成为主要问题。可问题是，谁先用呢？
数据库代码很有必要使用SVN管理(Vogts)
Thursday, January 24th, 2008
今天开发忽然问我，前几天这个TRIGGER是什么样的。我无语了。除非从前几天的备份集里去找，否则是基本上很难找了。
如果采用SVN管理的话，甚至可以找到1年前的记录，还能找出谁改的。
项目在特别复杂的情况下，这种作用是显而易见的。
目前我这里有两个开发团队，一个用SVN，另外没采用SVN。如今优势已经体现出来了！
Oracle Server Architeture
Thursday, January 24th, 2008
三亚行流水账(Donny)
Thursday, January 24th, 2008
08年1月1日~5日
爸妈，spring，我
行：
春秋订的杭州到海口的往返机票，389，2.5折
在海南租车网租了一辆自动1.6的C2，开到三亚。每天150元，油费6.69,没有高速路费。
gps导航，一点冤枉路都没走。
住：
1日晚在海口住锦江之星。
2日在三亚大东海住 海敦家庭旅馆。
3日在三亚亚龙湾住 喜来登
4日回三亚大东海住 海敦家庭旅馆。
5日返回
玩：
2日：
海口到三亚的路上，老爸突然提出没有去博鳌开过会，比较遗憾，想去看一看。于是中途前往游览。还不错，其他评价略。
晚上到了大东海，先吃了东北菜（饿了，量大）。然后在海边闲逛，全是酒吧。70%的俄罗斯人，比基尼。
后来知道他们放大假，一般都到三亚度假，所以这里的商贩都会说俄语，而且商店的招牌都有俄文的，甚至没中文。
晚上找海敦的老板娘帮忙买了 南田温泉的门票，第二天上午去泡温泉。
3日：
南田温泉最有趣的是那个有小鱼的，吃人身上的死皮，痒死。
这回90%的俄罗斯人，有穿丁字库的，靠，不过一眼望去全是人肉，也就没啥感觉了。
中午去 春园 吃海鲜
下午入住喜来登
4日：
亚龙湾是个国家度假区，有7家5星级酒店，围绕在一片私人海滩。
喜来登的花园非常漂亮。但是吃东西非常贵，下次要自己多带些东西吃。
下午前往天涯海角，爸妈进去逛了一圈，我和spring在车里小憩，吃水果，第一次吃到菠萝蜜。
晚上回到大东海海敦家庭旅馆。
5日：
返回海口，在机场还车。
下午到杭州。
遗憾：
开车虽然方便，但是海口-三亚 270公里，还是有点累的。
如果直接到三亚的机票可以接受，还是直飞比较好，在三亚租车，就舒服了。
温度不够高，不适合下海游泳。
spring有了baby，很多地方她玩不了。
所以 蜈之洲岛没有去，下次吧。
三亚城市比较落后，物价也很高，城市不是很漂亮，也就是亚龙湾还不错，但是要烧钱。
相比还是丽江好，虽然不是一个风格。
有一些在喜来登的pic，其他pic在老爸的相机里，回来再传上去。
http://www.flickr.com/photos/grassbell/tags/sanya/
组内分工
Wednesday, January 23rd, 2008
select
decode(username,
’大师’, ‘业界评论+吃喝玩乐’,
’旺旺’, ‘前沿技术+时事评论’,
’Donny’, ‘主机存储+旅行照片’,
’陈立’, ‘技术，美女，漫画，各种片’,
’老罗’, ‘加班以及加班的体会’,
’SKY’, ‘阿里开发DBA第一牛’,
’涛哥’, ‘oracle+mysql+postgresql+sqlserver+access+foxpro…’,
’小强’, ‘oracle技术心得’,
’勇斌’, ‘java+oracle’,
’jacky’, ‘流水帐+育儿知识’
) as 个人分工
from dual;
