某客户核心数据库库升级前的问题处理和升级步骤

这个升级发生在1年前，客户的这个核心数据库可能是当时全球最大的9i OLTP数据库。有120多TB。

我的分享分成2部分，前一部分，讲讲这近1年来，帮助客户在升级测试中处理的一些问题。后面一部分，将他们的升级步骤，主要讲升级的架构变化，如何利用这个架构来减少风险。

（一）升级前的问题处理（那些年我们踩过的坑）：

1. 9i到11g查询all_synonyms效率变慢，从0.3秒到3秒。（在11g中的定义发生了改变，buffer gets从10变成5万多）
(1).替换成老的all_synonyms定义，但这是修改数据字典了，不推荐。（11.2.0.3之前使用）。（Doc ID 9371529.8）
(2).用物化视图，每次查询的时候查物化视图。
(3).加rule hint
(4).改查dba_synonyms

2. Wnnn进程自动预扩展的问题。
(1). BUG 13871316，Wnnn进程导致CPU冲高，但是在11.2.0.4中修复。测试当Wnnn进程被触发的时候，对其进行pstack和errorstack，没有看到bug相关的call stack。
(2). Wnnn预扩展时会处于db file init write等待，原表空间越大，扩展的就越大。受到隐含参数_kttext_warning影响，默认是5%。即剩余5%的时候，预扩展5%。（Doc ID 1459097.1）
(3).是否关闭，性能对比测试：
循环插入100次，开启预扩展比关闭预扩展的插入效率高。（51s VS 81s）
循环1000次，在insert的过程中伴随预扩展进行，则差距不多。（1220s VS 983s）

3. in但是绑定变量个数不确定：
(1)Table Function SubSelect
(2)Dynamic SQL and Context
(3)Temporary Table SubSelect
(参考ORACLE BASE的Dynamic IN-Lists)

4. db replay中大量的session处于WCR: replay clock的等待。
解决：设置dbms_workload_replay.prepare_replay(synchronization=> false)

5. 远程灾备库apply日志慢
加大media recovery的 并发数，alter database recover managed standby database parallel 128 disconnect
apply效率从3分钟一个到1分钟一个。

6. 11g的listener不再需要设置密码（Doc 1328725.1）。

7.exact_matching_signature和force_matching_signature的问题
只要语句中带有一个绑定变量，oracle就认为这是一个带绑定变量的sql，会把exact_matching_signature和force_matching_signature相等。
只有语句中所有变量都带入，没有绑定变量的情况下，force才不等于exact。

8. SQL解析时间过长。
一般sql执行时间长，还比较好解决，加索引，调整执行计划。但是解析时间长，怎么办
往往解析时间长，和bug有关，所以一般先根据sql的执行计划，去查一下有没有吻合的bug。如nestloop嵌套层数过多。。。。等等。

如果找不到bug，那就需要自己分析了。我们可以做oradebug short_stack，同时，在另外一个窗口用pstack -p 进程号，进行跟踪

然后看看大约是在那个函数的地方停的久一些，根据函数，去找x$ksppi中类似的名字，或者再打个10053的trace，看该SQL使用的优化机参数，可以找几个参数，用alter session set xxxx=yyy试试

如这个问题，我看到kkoBitmapAccPath函数，比较陌生，不像是在一般的short stack中能看到。看名字觉得这个是和bitmap转换有关。于是我尝试关闭了_b_tree_bitmap_plans
解析时间从30多秒，减低到了2秒多。

但是客户还是不满意。

我在继续分析，发现有kkqctdrvJPPD之类的函数调用和类似kkqctCostTransfQB之类的函数调用。尝试禁用jppd，没有改进。尝试禁用CBQT，解析时间从2秒多降低到了0.3秒多。暂时符合了客户的预期。但其实CBQT包含多种转换（参考Doc ID 1082127.1），后来进一步研究是在_unnest_subquery中这一步消耗的最多。后来就禁用了_unnest_subquery

注：CBQT禁用，影响的东西太多。所以最后还是只禁用了_unnest_subquery

9. 升级前回滚事务
客户要我两个问题：a)如何加快回滚，b) 如果回滚不完成，能否继续升级？

a)加快回滚，我们可以开启fast start parallel rollback，从false设置成high，发现不行，没有启动并发。因为原事务就不是并发度事务
设置隐含参数_cleanup_rollback_entries从100改到400，但是速度还是上不去。
最终还是客户的人自己解决了，客户叫了主机和存储的人，把回滚的表，切到pure flash闪存上，速度提升了7倍，终于在升级当天12：30的时候完成了回滚
大家平时做升级项目的时候，也注意提醒下客户，升级前一天千万不能有大事务回滚

b)如果回滚不完成，能否继续升级？
这个问题实在不好回答，因为我查遍了MOS中如rollback transaction upgrade fail或者rollback transaction upgradesuccessfully，都没有找到答案。而开了SR，GCS也是没有给出明确的答复。

最终我从他们的升级手册入手

他们的升级手册是基于Complete Checklist for Manual Upgrades to 11gR2 [ID 837570.1]的文档来做的。而那个文档，在说升级的第一步，是shutdown immediate
所以既然有回滚事务，你就无法干净的shutdown。所以。。。。升级条件不满足。从这个角度回答了他们的提问。

10. enq TX row lock contention： v$open_cursor找历史sql，logmnr

11. rman做backup validate check logical database，分配18个channel就报ora-600的错误：
RMAN-03009:failure of allocate command on ch18 channel at 05/18/2015 03:38:46
ORA-00600:internal error code, garuments:[1916][][][][][][][]

经检查和databas中设置隐含参数“*._backup_disk_io_slaves”=4有关，取消这个参数后，可以使用18个channel。

 

（二）升级步骤
Primary是主库，生产库。LDG是local DG，同城灾备库。RDG是remote DG，远程灾备库。

######################
# BEFORE:
######################

b1)这是最初的状态

 

b2)为了升级，他们在RDG后面，再搭了一个RDG2.一会你可以看到RDG2的作用。此时，这条线上面对库都是9i的，是一个primary带着多个standby

 

b3)这是一开始做的升级方案，就是将primary用存储同步的方式，mirror一个出来。注意，mirror是在线操作的，出来的存储，是Pure Flash闪存。
但是问题出在了，生产端和新的闪存做同步，同步的时候，非常消耗性能，iops可以从2w多跌到700多。影响了生产数据库，发生了生产故障。

 

b4)所以，临时调整了升级方案，如下：Pure Flash不和生产同步，而是和LDG同步。

######################
# AFTER:
######################
a1)将LDG再次用存储同步的方式，同步一份，成LDG2。

 

a2)不采用激活LDG的方法，因为激活的话，后面的dataguard就废了。而用这种方式：将生产库的controlfile和redo拷贝到LDG，将LDG打开。注：这种方式，在oracle7和8可以用。见SWITCHOVER BETWEEN PRIMARY AND STANDBY DATABASES (Doc ID 39673.1 INTERNAL)

但是在9i没说支持，我问了内部的helpha mail list，得到的回复是“We do not support this for random customers anymore as of 9i. Use Data Guard failover. ”

Anyway，客户还是采用了这种方式打开了LDG成primary，好处是后面的standby还能用。

 

a3)然后将LDG2的oracle home挂到11g下，进行升级。注意此时LDG2和LDG一直是出于存储同步到状态，所以LDG升级到11g后，LDG2也升级到11g

 

a4)将LDG2做convert to physical standby。此时LDG和LDG2就成了dataguard了，我们把LDG称为primary2，带的是LDG2。

 

a5)再将RDG2，接到LDG2后面。

 

a6)切换RDG2的oracle home到11g，用apply日志的方式，升级到了11g

 

a7)此时，架构上，就有一套9i的primary，同城standby和远程standby。
以及一套11g的primary，同城的standby和远程的standby。
搭建11g primary的OGG链路到9i的primary，这样，在11g上的DML也会同步到9i上，万一11g需要回滚，还是能切到9i上的，9i的数据也是和11g是一样的。
且此时，2套架构，都有本地容灾和远程容灾。

 

 

a8)最后，待一个星期之后，运行没问题，就拆掉ogg的回滚链路。
回收9i的primary，ldg和rdg的主机资源,只留下11g的一套数据库