山上有风

上周某客户2个数据库分别做了分区和升级。
我做了分区的主要工作，方案是应用开发dba设计的。
升级是oracle原厂工程师做的。

升级后，cache buffer chain 争用严重（有500多个session等待这个事件），cpu使用100%，性能底下，最了回退；

分区后，buffer busy wait等待严重，经statspack分析后确认是大量全表扫描引起，创建索引后解决。

数据库升级这个我没有参与，估计没有做压力测试。
分区是做了压力测试的，但是从后来实际情况看，压力测试没有达到效果。
这个数据库有很多关联应用，可能部分压力测试没有做到。
在检查分区方案时，特别提出要做回退方案。虽然后来没有回退，但是如果没有回退方案，当时在处理时压力就更大。

这2个事情说明回退，即对原方案或者原环境的备份，是非常重要的。

简单的说，备份是非常重要的。

就是16号晚上6点开始到17号早上7点多才结束的主机迁移。

当前环境有3台主机，1台备机，是1备3，共4个节点。
这四个节点迁移到新的四个节点，主要工作在存储和小机，简单说就是把存储从原来的4个节点挂到新的4个节点。

数据库组的任务就是修改数据库环境，迁移后数据库启动正常，应用正常。
简单的想，就是spfile中相应路径修改一下。

本来计划是凌晨1:40完成，后来到7点多才完成，主要原因有：
1.预先对工作分析得不透，环境检查得不够。
在备用机上本来还有实例在运行，这个处理不在计划内。
2.部分工作没有考虑到
比如使用dblink，必须同步复制到新环境，侦听的配置
3.应用测试的时间没有考虑
因为是热备，测试热备需要花时间，测试时出现问题的处理，这个时间都没有考虑到。
4.额外发现的问题的处理时间

把事情做好，真的是要方方面面考虑到。
很重要的是在事情开始前，把步骤列好，check。确认步骤没有少。

这次7点多离开，12点多又接到电话，可能是归档空间满引起业务停止。

又匆匆赶过去，结果有人通过vpn上去解决了。后来了解到是系统组的人忘记把归档路径的权限设置为oracle了。

这个问题一方面是系统组漏了，另一方面，我当时应该检查alert文件，否则可以提早发现的。

当时系统组一起干活的兄弟，感觉做事也很细心，比较有章法，不过做了13个小时，谁都晕了。
难保不会漏个东西。所以说，在做之前，把东西想周全是最好，另外，如果有变化，先修改计划文档，再动手做，避免做的过程出现问题，导致漏掉其他内容。有点类似oralce的先保存到redo，也有点类似iso9001里面的“写下要做的”。

这里还是觉得iso9001的思路很好：
写下要做的；
按所写的做；
写下所做的。

好的习惯，有时候比技术本身更重要。

最近没有写oracle的帖子，一个是没有特别值得写的，一个是这段时间在整理oracle的学习case。
把oracle整个知识架构理出来，比较重要的知识点，以测试/实战/解释的方式做出来。
目的有几个：把知识点都补全，通过实践加深理解，加强记忆。

基本上把oracle知识框架分为
BA–base knowledge
BK–backup and recovery
HA– high availability, dataguard, partition, rac
TS– trouble shooting
PF– performance tuning
IN– install
NE–10g 11g new feathers.

bug list, 各个最常用版本，各个平台的bug清单。

工作开始了一段时间，记个符号。

今天有兴趣看看oracle各个版本什么时候发布的

google了一下，查到这样一些网页，

http://www.oracle.com/corporate/story.html

http://www.oracle.com/corporate/history.html

http://orafaq.com/faq/what_is_oracles_history

摘录其中oracle产品的发布日期：

1984 oracle4
1985 oracle5
1988 oracle6

1992 oracle7
1997 oracle8
1998 oracle for linux
1999 oracle 8i

2000 oracle 8i Release2
2001 oracle 9i
2002 oracle 92 Release2
2004 oracle 10g
2005 oracle 10g Release2
2007 oracle 11g

简单回顾一下自己oracle的使用历史：
从oracle 8.0.7开始使用，开发的系统需要支持oracle, informix, sybase数据库，oracle是在linux，solaris上运行的。当时安装还是文字界面，在linux上安装时有一些bug，
经常在linuxforum 上发帖。 应该是在redhat6上。
后来在redhat 7上安装8i,做了一个游戏从mysql到oracle8i的迁移。对oracle9i，在redhat上使用了9i rac, 是一个OID (oracle internet directory)系统。后来从suse-oracle10g rac开始, 各种平台，随着做oracle服务， 开始在各种版本，各种平台的oracle提供服务。

这件事遇到已经不是一次两次了，而是， 我处理的客户就有5个，有大客户，大得有几十个数据库，有小客户，只有一台pc server。
可见这种问题发生的普遍性，貌似没有技术的事情，但是遇到就是大问题，因为生产停止了。

总结起来，不外乎几种原因：

1.业务异常
这好像是最主要的原因
2.dba不懂得删（确实有）

业务异常的情况，有次遇到是9204的bug，做报表时使用了临时表，而9204里面有个bug，临时表的redo 比普通表还大好多（正常情况临时表的redo很少），这样看报表时归档日志那个快，一分钟100M，甚至删都来不及。
还有个客户，就是我最近遇到的这个，这个系统比较复杂，一个数据库上有几个应用，不同的应用的数据是不同的开发商维护的（乱），有个应用的开发商前几天删数据，导致归档日志狂增，增到来不及备份释放空间，结果就挂了。
另外一个大客户，前面几乎每周都有这个事情，也是业务突然有变化，归档空间不够大，发生了几次。

dba不懂的，我只遇到一个，真是不懂。

解决方法：原因找到了，问题就好解决，改扩大空间的扩大空间，改增加备份频率的增加备份频率。

但是救急的解决方法很重要，比较简单的，就是把归档日志移动到其他目录（不要删）。
然后 archive log start;启动归档进程，业务马上恢复。
如果空间比较多，而且是aix的，那么可以临时调大归档空间，最容易了。（一般大客户才有这个条件）；
如果把文件移走了，后面rman备份时找不到，也是个问题。
在备份前要先change archivelog all crosscheck,让oracle检查一下哪些归档日志实际不存在，就不会去备份，否则因为找不到而备份失败。 后面可以再通过change … available把移走的归档日志状态改回来，下次备份的时候，这些归档日志还可以被备份。

另外有个方法，我没有测试过，frank提出来的。就是备份归档日志时，把最后切换归档日志那句去掉，这样不会因为没有空间导致切换日志失败，导致备份归档日志失败。因为一般备份归档日志后都会删除这些归档日志，这样也可以解决空间不足的问题。

对这些问题，主要是每天检查归档日志备份是否成功，以及业务是否有变化。

使用oracle数据库开发应用，对于应用的扩展性，一直以为绑定变量是最重要的。
现在知道，连接方式也是非常重要的。

有2个应用和oracle文档的说明让我认识到这点。2个应用有点类似，号称3层架构，使用了websphere中间件，但是客户端直接连接数据库，没有使用连接池。
每处理一条业务，要连接3次数据库，处理完成就断开。

每秒要处理2条业务，数据库连接7次左右。

结果是：
一个应用发生过2次telnet不上的情况，虽然业务还在跑，当时没有办法连接上去看系统性能，估计是内存耗尽导致。
另外一个应用每秒处理业务逐渐降低，具体原因还不是很清楚，但是在改用连接池后，性能提高了有10倍。

看看oracle官方文档的说明：
Oracle9i Database Performance Planning Release 2 (9.2)
Part Number A96532-01

Good Database Connection Management

Connecting to the database is an expensive operation that is highly unscalable. Therefore, the number of concurrent connections to the database should be minimized as much as possible. A simple system, where a user connects at application initialization, is ideal. However, in a Web-based or multitiered application, where application servers are used to multiplex database connections to users, this can be difficult. With these types of applications, design efforts should ensure that database connections are pooled and are not reestablished for each user request.

很久没有更新了，工作忙是一个借口，也是一个理由。

前面给客户培训oracle，连续5天，够累的， 不过正如frank所说， 培训对于讲师的收获可能更大。
信夫！

通过讲课，对oracle的很多知识点可以明确，理论可以更好得贯穿起来，对于提高oracle水平非常有帮助。

另外，这段时间客户的事情确实比较多：数据库升级（oracle 8i已经不提供补丁支持）；因为
DDL引起数据库挂起，引起后续性能问题； 数据库备份恢复测试等等，不一而足。好像5月是事故多发期。后面陆续得：数据库迁移测试，压力测试，等等。

不过随着对oracle知识面扩大和知识点深入了解，各种问题的分析和解决基本心中有数， 思路明确，应该可以在预估的时间内解决问题。

前些日子花了些时间看asktom的归档的资料，感觉颇有收获。觉得好多都是书上看不到的，实战的东西。看多了，总觉得很凌乱，很松散，没有形成一个体系。
前几天将031,仔细回读了一下教材，发现很有收获。真是每次读每次都有收获。
后面好多oracle基础文档要再尽快过一遍，趁热打铁。不然过几天可能又没有感觉，没有兴趣了。

最近接触了几个调优的case， 很有感触。

自己没有开发人员的客户，上线的业务系统，或者由于选择的开发商不是很有经验，或者没有很好的前期检查、测试， 都是上线后发现问题很多，系统负载大，影响业务运行。

有开发人员的，对于选择产品，上线前测试都多多少少做了一些工作。
在系统架构，数据库开发方面都不会很差，可能在业务运行一段时间后，因为数据量问题引起性能下降，需要调优。
自己没有开发人员的，在引进系统方面不是很了解，或许别的原因（比如上级指定产品），导致使用的产品开发不完善，架构不合理，系统上线就面临问题。

这些都说明压力测试是多么重要，无论用什么方式获得的软件产品， 在上线前，只要充分进行压力测试，问题都可以发现。

想想以前开发的软件，都是简单的c/s，哪儿有考虑并发，压力？
现在一般都是三层架构，并发压力大，如果不充分考虑各种因素，开发完成后，可能发现距离上线还有很大差距。

也许这些也是数据库顾问可以做的工作。

今天在压力大时做statspack,分析下 library cache 等待位于top 1. 每秒 hard parse 17, parse 90
使用三层架构,但没有使用连接池(真是少见).
判断是soft parse, hard parse 过多引起library cache严重等待.

1)减少hard parse.
修改程序。
2）减少soft parse.
修改应用。尽量使用sp. 客户端调用sp.
3）启用连接缓冲池。可以减少soft parse.