数据库管理-第四十八期 阳性、优化（20221216）

第四十八期 阳性、优化

本期聊一下阳性后的感受和本周做的一些优化方面的工作。还没好完，简短一点。

1 阳性

1.我是应该是上周四去移动另一个办公区开会加上晚上吃饭和阳性同事密接双重打击下染上的。星期五开始喉咙痒，星期六附加鼻塞头晕晚上开始发烧，星期天发到最高38.6开始上对乙酰氨基酚片，星期一二开始温度反复，星期星期三喉咙加重鼻塞也加重，星期四鼻塞几乎无法用鼻子呼吸喉咙好转睡了半天，星期五（今天）鼻塞好转。。。
2.大量喝水很有必要，但是一定少量多次，也最好是电解质水。反复出汗排尿太容易引起电解质紊乱了，一般的糖盐水钠是足够的但是没有补到钾，我媳妇之前就经常缺钾，感染后就出现过两次缺钾现象引起病程加剧与反复。所以加上苹果、香蕉或者不差钱买点外星人吧（不是打广告真心有用）
3.吃药的问题要注意，对症很重要但也别超量（这个网上到处都有）
4.如果不是特别严重别去医院添麻烦，现在医院压力已经很大了，很多医护也是一边抗毒一边诊疗
5.一定区分好电解质紊乱、新冠发病反应和药物反应，我媳妇儿就是因为发烧心率较快怕是药物不良反应逼着我在寒风中带着去了躺医院还好被接诊护士打回来说正常，我媳妇儿也一下子就舒服了，然后我那天加重了一点。新冠发病期间、特别是发烧期间心率120很正常，不超过140不要去医院。

2 40s->0.03s

这个优化光是从时间来看，我觉得我可以吹一辈子，1333.33倍的提升，先说说背景：
环境是X8M-2那台一体机，19.13，有一个PDB里面有两张表，是每天truncate掉然后去其他系统全量同步最新版本数据过来，都是千万级数据没分区。
这个PDB是作为一个对外统一查询用的，功能是齐备的，但是之前一直没有启用，就相当于是一大堆冷数据。这周四凌晨好巧不巧，诶~启用了，然后就有业务疯狂的关联查这两个表，速度那是贼慢啊，40s，造成了大量积压，好巧不巧，查的源头又是一体机的另一个PDB，可谓是魔法叠加了。一大早我就被两节点CPU100%的短信告警给干醒了，立马起来处理。
大概了解了下这两张表的情况，EM里面看了下语句SQL ID，我统共就做了三件事：
1.在这个查询PDB中把对应会话全干掉：

select 'alter system kill session '||''''||sid||','||serial#||',@'||inst_id||''''||';' from gv$session where sql_id='xxxxxxxxxx';
--根据查出内容直接干

2.对这两张表收集统计信息

exec dbms_stats.gather_table_stats(ownname=>'USER',tabname=>'TABLE1',cascade=>true,degree=16);
exec dbms_stats.gather_table_stats(ownname=>'USER',tabname=>'TABLE2',cascade=>true,degree=16);

3.手工刷表

select count(*) from USER.TABLE1;
select count(*) from USER.TABLE2;

然后语句查询性能就起飞了。
这里解释一下为什么会出现这一系列问题和为什么要这么处理：首先这个PDB对于一体机来说都是冷数据，而且和新录入的数据一样（这次正好二者都占），一体机会把数据仅存放到存储节点HDD里面，而不会到速度更快的闪存卡和傲腾里面，一体机会根据使用情况即是使用多就会朝更快的地方缓存；而统计信息本身也应该是大量数据操作后需要收集的，所以2,3两个操作一个是让表有正确的统计信息，另一个测试手工将数据从HDD缓存到闪存卡或者傲腾里面去。操作1就不用解释了，要释放CPU占用就必须释放之前错误执行的语句。

3 字典表

在我的理解里面，一个业务在数据库里面存了哪些表，该由业务自己建立一个或若干个字典表来维护并使用，但是我这X8-2上的业务（没错，又绕回来了）直接省去这一步骤，直接通过各类系统视图（dba_tables,dba_views,dba_tab|col_comment等）来作为本应字典表的功能，这就造成了一个问题，在很多的跨schema查询之前都要先去打击这些系统视图再做查询，偶尔一下还好，多了就贼慢，慢则是两方面，一是返回结果太多，花费大量时间在网络和output上；二是不要以为这些元数据查询很快，但其实有时候关联的东西一多，从SQL monitor来看，IO也能几十几百GB。所以，还是别偷懒，做好本来该自己做的事情。

总结

和上期一样还没好完，原谅我又双叒划水了。
老规矩，知道也不知道写了些啥。