数据库管理 2023-03-27
第六十三期 烦
上个周末呢，因为一些客户的事情整的一个周末都在干活，其中两天还搞到的晚上12点，几乎没咋休息，现在感觉贼累，继续写文章换换脑子，这篇也许也是3月份的最后一篇了，争取干货。
1 跨版本PDB迁移补遗
上周又进行了3个业务PDB的跨版本迁移操作，其中又遇到了一些问题，这里总结一下：
1.迁移前的PDB需要把PGA大小配置至少2G左右，1G是不够，会报4036，有概率影响迁移操作。
alter system set pga_aggregate_limit=2g sid='*';
2.迁移前需要把MAX_IOPS和MAX_MBPS参数关掉，虽然19c之前的版本这两个参数是否生效比较玄学（我觉得打了补丁有概率有用）。但是只要这两个参数生效了就会影响迁移的速度。
alter system set max_iops=0 sid='*';
alter system set max_mbps=0 sid='*';
2 BUGs
其实这是前两周遇到的问题，数据库在运行过程中突然出现大量的报错：
<msg time='2023-03-16T12:02:06.022+08:00' org_id='oracle' comp_id='rdbms'
msg_id='2468823781' type='INCIDENT_ERROR' group='Generic Internal Error'
level='1' host_id='xxxx01' host_addr='xx.xx.xx.xx'
pid='26032' prob_key='ORA 600 [qosdExpStatRead: expcnt mismatch]' downstream_comp='SQL_Plan_Directive'
errid='1314479' detail_path='/u01/app/oracle/diag/rdbms/DBNAME/SID/trace/SID_mz00_26032.trc' con_uid='3392884123'
con_id='6' con_name='PDB_DWDB'>
<txt>Errors in file /u01/app/oracle/diag/rdbms/DBNAME/SID/trace/SID_mz00_26032.trc (incident=1314479) (PDBNAME=PDB_XXDB):
ORA-00600: internal error code, arguments: [qosdExpStatRead: expcnt mismatch], [65537], [1], [92820], [1], [], [], [], [], [], [], []
</txt>
<arg name='PDBNAME' value='PDB_XXDB'/>
</msg>
这个报错并没有影响生产，就是短信告警太多了，MOS上查了下相关BUG，确实有，但是在当前19.16是修复了的，所以还是收集信息开SR，这里发现了另一个关于tfactl diagcollect的惊喜：
Choose an event to perform a diagnostic collection:
1 . 2023-03-15 21:45:26.000 [RDBMS,DBNAME,SID] ORA-00600: internal error code,arguments:[qosdExpstatRead:expcnt mi,,[9 times].
2 . Display Problem Categories
3 . Enter a different event time
X . Exit
新版本的AHF能够更加精确的判断日志中的告警内容，在生成诊断收集文件时可以更加精准的收集需要的文件，减少文件大小、减少网络传输压力同时更快的进行分析。
SR分析后还是找到了之前我在MOS查到的对应BUG：
Bug 28681153 - ORA-600: [qosdexpstatread: expcnt mismatch] （19.7修复但不包含19.8）
Bug 31143146 - ORA-600: [qosdexpstatread: expcnt mismatch] even after applying 28681153 （19.12修复）
但是我这边版本是19.16，且仅在一个PDB出现，这里由涉及另一个文档：
ORA-00600 [qosdExpStatRead: expcnt mismatch] Still Happens Even After Applied both Patch 28681153 and Patch 31143146 (Doc ID 2803002.1) （涉及Bug 33131200 : ENABLE FIX CONTROL FOR BUG 31143146）
说白了就是补丁不生效，需要在出问题的PDB执行下面的命令：
alter system set "_fix_control"='31143146:on' scope=both;
执行完成以后，并没有第一时间生效（但确实告警慢慢变少了），后台给了进一步操作：
SQL> delete from sys.exp_stat$ b
2 where b.snapshot_id = 1 and b.objn = 92820 ;
65537 rows deleted.
SQL> update sys.exp_obj$ a
2 set a.EXP_CNT=0
3 where a.SNAPSHOT_ID= 1
4 and a.objn = 92820;
1 row updated.
SQL> commit;
Commit complete.
SQL> With b as (
2 select count(*) cnt,objn,snapshot_id from sys.exp_stat$ es group by
3 objn,snapshot_id)
4 select * from sys.exp_obj$ a, b where a.objn=b.objn and
5 a.snapshot_id=b.snapshot_id
6 and a.EXP_CNT<>b.CNT;
no rows selected
对比下第一条语句的各个数值、结果数值和告警内容，还是有点意思，具体可以自己去看看初始BUG内容说明。
3 就低不就高
这一节内容才是上周末加班的罪魁祸首，因为一些不能说的原因，需要将我这19c上的数据传到另一个地方的11g数据库，这里就出现了一系列问题，一开始要求导出为文本CSV，但是我们原始数据涉及183张表高达约7亿条338GB，如果整成CSV不仅操作复杂，而且容量巨大。因此dump才是最快的方法，这里又遇到个问题，众所周知11g的标识符（表名、索引名、统计信息记录等）长度限制为30，12c开始标识符长度可以可以达到128，因此只能将数据转至表名长度不超过30的中间表再导出。当然还有其他问题，就是11g的varchar2最长是4000，读过我文章的都知道为了满足业务对长字段的需求，我这里的库都是开启了varchar2(32K)的支持（详见第四十七期），因此这里面还有接近一半的表存在超长字段，在目标方数据库专家的指导下，用CTAS的方式配合to_clob将超长的字段全部给处理了，当然，这个需要人工操作，到现在都还没有弄完（意味着我的加班还没有结束）。当然最后一个问题都不是问题，AL32UTF8向ZHS16GBK迁移，中文占位3到2反而还不是问题了。
这事我想吐槽的是，这盘这事，目标数据库要接收很多地方过去的库，虽说大多数是Oracle，但已经知晓不都是11g的库，还有一些非Oracle的库，虽然大多数提供的都是文本CSV，但是实际数据并不是都满足11g的要求，为啥要用11g的库，主要还是那边。。。不说了（以前说过），美其名曰求稳，但其实长期使用一个不受技术支持版本的数据库，无论从稳定性还是安全性出发最终结果都是不稳，更多的还是以前说过的，守旧，没有能力进步了。Oracle做的好的一点就是向下兼容，但不是向上兼容！
总结
老规矩，知道写了些啥。