年关，越怕越出事

fulzu

操作系统aix 5.3
数据库10.2.0.4
由于种种原因，需要给数据库打patch，并且把db_cache_size和shared_pool_size改小。
在操作之前，局方的人还开玩笑，说他最近运气特背；我说，没事，我最近运气不错。
现在备库打patch，期间，有一个lib文件提示无法覆盖；项目经理一看急了，马上给公司和一个ocm打电话，ocm的问的问题也让我很郁闷：数据库服务你都停了吧？
俺承认俺很菜，俺还不是ocp呢，但是起码也知道要停库打patch；项目经理要求ocm赶紧打车过来。
去metalink搜，发现note 739963.1,在aix下，升级和打patch过程中，即使所有服务都停止了，也会出现无法覆盖lib文件。
需要用root，执行/usr/sbin/slibclean，然后在重新运行patch apply。
ok，在ocm来之前解决这个，修改参数。
原来的db_cache_size=6G,shared_pool_size=4G,需要修改为4G和3G。
然后切换HA，再在主机继续打patch。
谁知道，在切换到备机后，修改过参数的数据库无法启动，直接报错：ora-00064 object is too large to allocate on this o/s.
看来问题是出在修改过的参数上。
没办法，创建pfile，将参数修改过来吧……
create pfile from spfile;
提示：无法获取设备状态！
头有点懵。
在$ORACLE_HOME/dbs下，找到了init$SID.ora文件，有一句话：spfile=/dev/rspfile，spfile被放在了裸设备上。
通过strings /dev/rspfile，创建pfile，然后将参数修改过来，数据库启动成功。
创建spfile:create spfile='/dev/rspfile' from pfile='/oracle/pfile.ora';
在发生问题的过程中，为了减少对业务影响，启动应急数据库和另外两台数据库。
应急数据库启动没问题，帐务数据库启动没问题；计费数据库启动失败，提示无法lock控制文件，查看vg状态，都正常，最后查lv的个数，主库26，bcv上有34……
大家冷汗直流，看来是盘阵出问题了，赶紧叫主机工程师过来。
bcv问题处理完，暂时业务不用中断，继续打patch。
局方的人将数据库切换到备机，我在主机打patch，又提示文件无法覆盖；执行/usr/sbin/slibclean也不管用！
ps -ef|grep ora发现很多oracle进程存在，ps -ef | grep pmon，没看到有记录；刚开始怀疑是局方没有切换HA，但是登录到备库，发现数据库已经在备库启动。
HA切换脚本是，先停listener，然后再停数据库，umount盘阵。但是不知道为什么还有进程在备库存在。
确认应用都已切换到应急数据库，杀掉主库所有oracle进程。
ps -ef|grep $ORACLE_SID|grep -v ora_|grep LOCAL=NO|awk '{print $2}'|xargs kill
重新打patch，一切正常。
后来在bcv验证，数据库启动不了，主要是share pool改小引起；本来以为100%没有事情的事情，最后还是出事了！

今天下午开发来找我，他的处理垃圾短信的存储过程跑不动了；昨天晚上10点前还是好好的；之后就出不来结果了……
大概看了下执行计划，主要原因还是variable peeking。他的有问题的过程类似如下形式：
-- Created on 2010-1-28 by ADMINISTRATOR
declare
  -- Local variables here
  i integer;
  p_date date:=to_date('2010012816','YYYYMMDDHH24');
begin
  -- Test statements here
      select count(*) into i from siebel.s_camp_con c, cboss.aicbs_pub_msisdn_prefix@cbossdb a where c.key_02 = '北京'
       And a.msisdn_prefix = substr(decode(substr(c.comments, 0, 2),'86','',substr(c.comments, 0, 2)) || substr(c.comments, 3, 11),1, 7)
       and a.tc_operator_id = '1'
       and C.CREATED between p_date-1/12 and p_date;
end;

跑了一个小时都没有出来，修改成如下：
-- Created on 2010-1-28 by ADMINISTRATOR
declare
  -- Local variables here
  i integer;
  p_date date:=to_date('2010012816','YYYYMMDDHH24');
  p2_date DATE:=p_date-1/12;
begin
  -- Test statements here
      select count(*) into i from siebel.s_camp_con c, cboss.aicbs_pub_msisdn_prefix@cbossdb a where c.key_02 = '北京'
       And a.msisdn_prefix = substr(decode(substr(c.comments, 0, 2),'86','',substr(c.comments, 0, 2)) || substr(c.comments, 3, 11),1, 7)
       and a.tc_operator_id = '1'
       and C.CREATED between p2_date and p_date;
end;
大概不到1s。

〇〇

我们一个数据库也启动不了了，oracle的顾问来了也不行，hp也不行

fulzu

原帖由 〇〇 于 2010-1-28 19:02 发表
我们一个数据库也启动不了了，oracle的顾问来了也不行，hp也不行

赶紧联系大师们，赚钱的机会来了。

zergduan

...改小shared_pool 数据库起不来？ 为什么？

wsf3809

这个年头，ocm 真不值钱，打个patch 还要ocm啊？？？？
楼主需要有点主机知识，HA机制是切换到备机，oracle正常运行，因为你的所有数据全部在阵列上，这个时候，你在主机打补丁？你能打的上去才怪呢。   楼主，这个升级肯定是要把ha 停下来的。

fulzu

原帖由 wsf3809 于 2010-1-28 19:14 发表
这个年头，ocm 真不值钱，打个patch 还要ocm啊？？？？
楼主需要有点主机知识，HA机制是切换到备机，oracle正常运行，因为你的所有数据全部在阵列上，这个时候，你在主机打补丁？你能打的上去才怪呢。   楼主，这个升级肯定是要把ha 停下来的。

现在备机打，然后将数据库切换到备机；主机没有任何oracle进程运行，再在主机打；
oracle软件是不在阵列上的。

wsf3809

原帖由 fulzu 于 2010-1-28 19:17 发表

现在备机打，然后将数据库切换到备机；主机没有任何oracle进程运行，再在主机打；
oracle软件是不在阵列上的。

你 在备机打了，你不需要切换到migrate 模式下 运行脚本吗？你还是得停数据库。 不如直接在主机打了，脚本运行结束，然后把软件tar 到备机呢，根本不需要打2次啊。 我知道oracle软件是在本机的。

zergduan

原帖由 wsf3809 于 2010-1-28 19:19 发表

你 在备机打了，你不需要切换到migrate 模式下 运行脚本吗？你还是得停数据库。 不如直接在主机打了，脚本运行结束，然后把软件tar 到备机呢，根本不需要打2次啊。 我知道oracle软件是在本机的。

patch 不是patchset

lz的做法没错，但是我不明白什么改小shared_pool会无法startup db~

maclean

老实说 这不算真正意义上的“出事”
还是业务不精引起的， 做变更的预案也没做好

viadeazhu

原帖由 wsf3809 于 2010-1-28 19:19 发表

你 在备机打了，你不需要切换到migrate 模式下 运行脚本吗？你还是得停数据库。 不如直接在主机打了，脚本运行结束，然后把软件tar 到备机呢，根本不需要打2次啊。 我知道oracle软件是在本机的。

lz的是interim patch，只需opatch apply下即可~不需执行脚本。