第七十期自己？自己

来到70了，最近有点卷，写的稍微多了些。
吐槽一下五一调休，周末砍一天，连6天，放5天，上3天，周末又砍一天。
今天刷抖音看到现在是如何看伍佰演唱会的：“花500买票，去伍佰的演唱会，唱伍佰的歌给伍佰听，伍佰只要起个头，插不上嘴”。突然回忆起伍佰的《突然的自我》。最近还是除了很多跟“自己”相关的事情，记录一下。

1 自己吓自己

这里是前段时间做ADG搭建准备的时候发现的，dbca建库的时候开启了FRA和日志归档。到准备修改log_archive_dest_1参数时，发现这个值为空，理论上默认配置这个参数应该为：

log_archive_dest_1='LOCATION=use_db_recovery_file_dest'

ASMCMD> ls +RECOC1/db_unique_name/

发现里面没有ARCHIVELOG文件夹，归档虚空了？通过EM看备份日志，发现日常的备份日志是跑着的啊，有点小就是了（我一个日志组10G，每3小时的归档备份一般也就10-50G之间）。难道是只有备份期间的日志归档被备份了？平时没有产生。到这里我下出了一身冷汗，没有归档还没有搭ADG意味着备份几乎没啥用。
冷静一下，还是发现一个问题，归档刚刚备份完，有20多个G，我就尝试做了：

alter system switch logfile;

这时候“惊讶”的发现FRA目录下出现了ARCHIVELOG文件夹，刚刚切换生产的归档日志也有。当然参数还是正常配了：

alter system set log_archive_dest_1='LOCATION=use_db_recovery_file_dest VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=primary_db_unique_name';

这里可以看到在开启FRA功能的默认情况下，归档在配置的FRA路径下生产归档文件，我属于是在“正确”的时间看到了“正确”的输出做出了“正确”的惊吓。翻遍官方文档也就发现下面描述比较贴切：
在这里插入图片描述
归档模式，开了FRA默认就是在FRA，没开就会去dbs目录。这盘属实是自己吓自己。

2 自己坑自己

接下来到上面那个环境的ADG备库，因为服务器给我的时候，有台服务器HBA卡是坏的，更换需要时间，但是灾备环境上线又比较急（报了考核的），就只能把另外两台装好，先把ADG弄好，服务器修好了再加入集群。
在这中间出过一丢丢小插曲，其实以前遇到过，就是一个没有经过dbca的集群，db中因为$ORACLE_HOME/bin/oracle权限的问题是无法使用ASM磁盘组的，需要执行以下操作：

$GRID_HOME/bin/setasmgidwrap -o $ORACLE_HOME/bin/oracle

彻底弄完了观察了两天发现一个问题：

DGMGRL> show configuration

Configuration - dg

Protection Mode: MaxPerformance
Members:
	dbaas - Primary database
	dbdg - Physical standby database
		Warning: ORA-16632: instance being added to member profile

Fast-Start Failover: Disabled

Configuration Status:
WARNING (status updated 17 seconds ago)

DGMGRL> show database dbdg

Database - dbdg

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 1 second ago)
Average Apply Rate: 1.08 MByte/s
Real Time Query: ON
Instance(s):
	dbdg1
	dbdg2 (apply instance)
	-- dbdg3呢？？？？！！！！

首先发现第一个问题，我新加节点的忘记配置静态监听和tnsname了，搞完之后，configuration output能短暂恢复下，但是一会儿继续恢复报错，第三个实例仍然没有粗线。本来这个报错是会自动处理的：
在这里插入图片描述
但是通过DG Diagnostic检查后发现最后个节点无法正确的通过正确的tnsname连接到主库去（绝对正确，可以用sqlplus连过去的！！），SR给了个操作建议：

DGMGRL> disable database dbdg;
DGMGRL> enable database dbdg;
DGMGRL> enable configuration

仍然不能在配置中正确添加新加的节点，只能用大招了：

DGMGRL> remove database dbdg;
DGMGRL> add database dbdg as connect identifier is dbdg;
DGMGRL> edit database dbdg set property logxptmode='sync';

然后一切正常，我怀疑这里和没有在添加节点前配置好静态监听和tnsname这步有关，属实自己坑了自己一把。

3 自己挺自己

今天下午我这X8M那台一体机告警，CPU占用率超过95%，也算是小刀剌屁股——开眼了（虽然祖上也因为CBC遇到过），但是很久没出现了，这机器CPU常年15%以下。
到EM一看，第二次小刀剌屁股，一体机内两个PDB，一个PDB用dblink去另一个dblink查数据，然后并发达到了150次/s（后面AWR查出来一小时跑了660W次，而对应的接口调用记录一小时只有几万次），这里明显是业务侧出现了异常，150次/s的并发，dblink两端都在一体机上，即便语句单条执行只有不到4微妙，但是双倍压力引给了CPU多倍的“快乐”。（其实前一天还处理了也是涉及这两个PDB的一条SQL，是一个查询4张表，3张表涉及dblink不在本地，而且这3张表一张在一体机另外两张在另一套数据库，因为查询条件一点点的改动就会造成查询时长非常大的变化，最后把另一套库的两张表都弄到一体机搞定的），后面重启了对应应用正常了。
其实CPU高不高都没啥，主要是CPU那么高（超过了66%，具体见第二十四期），但是对所有业务（十多个PDB）都没造成啥影响，响应速度依旧飞快，毫无感知，甚至是除了CPU比较高，这两个PDB对应的业务都没啥感知。这当然是resource manager的功劳啊（详见第四期，算上古文章了），虽然这两个PDB都是share 2，CPU max 40%。资源管理在这个时候就是根据份额确保了各个PDB运行所需要的CPU资源。
这里算一下，平时整体CPU不超过15%，到95%之间有80个点，那么CPU整体突破95%时这两个PDB以外用的其实很少（可以算不超过15%），那么算下来这两个PDB各占用了40%（虽然，资源隔离其实没那么简单）。所以没有影响到其他业务，resource manager还是起到了CPU隔离的作用，当然整体常规负载低也是重要原因，要不这两个PDB的性能分配肯定会被挤压。
所以预先做好了配置，还是一定程度上避免了出现更大范围的问题，给自己点个赞！

4 自己懵自己

首先说明一点，本节内容仅限运营商环境，仅是本人观点。
上周不是国产数据沟通么，其实很多厂商都说过一句话或者表达一种态度，以前都在B域发力，O域不是太上心。之前一直觉得B域有钱，O域没钱，还有就是B域整体技术实力是普遍强于O域的。但是今天和客户讨论这事，被自己一句话点了一下：B域的业务其实很简单，比如BOSS计费，主要是高并发相对单一业务逻辑应用场景（插改为主），而且很多情况会通过其他方式汇聚结果或者结果只是根据请求反馈，很多时候的结果及时性有些场景反而没有O域那么明显（记录的实时性还是比较极端的哈）。而O域的很多业务都是流程类的，业务逻辑比较复杂，涉及的语句会更复杂，还可能会有大量的存储过程和触发器，实时性要求反而更高。
而现在很多国产数据库都在标榜自己的tpmC能力，其实更多也也是应对B域的应用场景，也就是业务逻辑相对单一的高并发OLTP。那么之前不重视O域也似乎找到了一点原因了。为啥现在又来了呢，一方面是占坑，另一方面是近一年大家的HTAP能力还是有了长足的进步，可以应对更加复杂的应用场景了。所以后面O域这边的数据库选型可能会有不一样的要求和侧重点。