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

这个升级发生在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的一套数据库

相关文章

2条评论

  1. 有个疑问:primary2变成打开成主库后,数据怎么保证和primary的一致呢?

回复 sqlora 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据