DBASK问答集萃第六期

5次阅读

共计 3169 个字符,预计需要花费 8 分钟才能阅读完成。

引言

近期我们在 DBASK 小程序新关联了 DB 备战室,新增加 60 多位技术专家,期待更多数据库领域的专家和公众号作者加入到墨天轮,共创开放、互助、专业的数据库技术社区。

问答集萃

接下来,我们分享本期整理出的问题和诊断总结,供大家参考学习,详细的诊断分析过程可以通过标题链接跳转到小程序中查看。

问题一、为什么 oracle 不需要像 mysql 那样 double write

为了解决 partial page write 问题,当 mysql 将脏数据 flush 到 data file 的时候, 先使用 memcopy 将脏数据复制到内存中的 double write buffer,之后通过 double write buffer 再分 2 次,每次写入 1MB 到共享表空间,然后马上调用 fsync 函数,同步到磁盘上,避免缓冲带来的问题,在完成 doublewrite 写入后,在将 double write buffer 写入各表空间文件,这时是离散写入。这个过程是 mysql double write。问题:oracle 也是会出现类似的情况,为什么那么自信,不需要 double write

诊断结论:这只能说是 InnoDB 的设计实现,不同的产品设计思路不同。又由于 InnoDB 只是一个存储引擎,考虑的情况还要复杂。MySQL 的引擎制还导致 redo 和 binlog 共存。在未来 Oracle 主导之下,这些都会慢慢被改变。

问题二、truncate 分区表的时候非常慢 3 个小时没跑完会是什么原因

分区表有 200 多 G,通过 truncate 删除其中的一个分区 使用了 update global indexes 选项,执行了 3 个小时没执行完成,分区表存在 global 索引,最终导致业务无法操作,kill 掉 truncate 分区表的 session 恢复操作,请问

1、这 3 个小时是在等待 update global indexes 嘛?

2、kill 了 truncate session,业务恢复,表数据也没有删除,不是 truncate 不走 undo 嘛,为什么 kill session 之后 能回滚了呢?

诊断结论:1、从描述看,很大可能是阻塞在 update global indexes 上面了;可以结合 ash 看看。2、Truncate 是 DDL,记录不计 redo,但是 medata 还是有 undo 的,你这个操作失败,自然就回滚了。

问题三、oracel 预定义处理语句转为 MySQL 写法

oracle 写法如下:

EXCEPTION
WHEN OTHERS THEN

V_RESULT := I_SERVICE_ID;
RETURN(V_RESULT);

如何转换为 MySQL 语句写法?看网上说 MySQL 用 DECLARE,或者是否可以实现这种写法的转换?

诊断结论:类似这种写法:DECLARE EXIT HANDLER FOR SQLWARNING,NOT FOUND,SQLEXCEPTION,但是感觉 MySQL 的 exit 和 Oracle 的 return 还是有差距。

问题四、对大表字段设置为 unuse 有哪些影响?

oracle 11.2 版本中对大表字段设置为 unuse 对后续的管理会产生哪些影响?

诊断结论:SET UNUSED 再 DROP UNUSED COLUMNS,是对于数据量很大的表的一种标准处理方法,所以,实际上大部分都是在 SET UNUSED 之后的几天内就会选择合适的时机,将这些列物理 drop 掉,因此不存在太多后续还要持续管理的机会吧。

问题五、rac 心跳机制导致重启的问题

rac 心跳机制包括网络和磁盘心跳,如遇节点间心跳超时(可能是由于服务器 hang 住或者网络出现问题),是否会重启非主节点的服务器?

节点重启是指集群服务重启还是服务器重启?如果服务器 hang 住,可以理解为不能对磁盘进行读写,磁盘心跳超时问题就一定会重启服务器?另外根据 mos 文档指出,11.2.0.2 之后的版本,节点驱逐并不一定会导致服务器重启。

诊断结论:从 11.2.0.2 开始, 当集群中的某个节点被驱逐(例如丢失网络心跳)或者该节点的 ocssd.bin 出现问题时,集群将不会直接重新启动该节点,而是首先尝试重新启动 GI stack 来解决问题,如果 GI stack 不能够在指定的时间内(short disk I/O timeout)完成 graceful shutdown,才会重新启动节点。关于网络心跳和磁盘心跳的机制请查看详情。

问题六、oracle goldengate 实现一对多复制

目前一套 oracle RAC 做为源端,需要同步到同一机房的异机一份数据,还需要同步到异地机房一份数据,用一套 ogg 做一对多复制对源端性能影响大嘛?还是先同步到同一机房异机一份在从异机的目标端同步数据到异地?

像这种既有同机房异机数据同步,又异地同步,有更好的方案嘛?

诊断结论:一对多可以共用同一个抽取进程,只需多配一个投递进程就可以。

只要是同平台、同版本的 Oracle 容灾,基本上现在都用的 ADG。但是由于源端为 ibm 小机,目标端为 x86 的服务器,没考虑用 ADG,基本上能用的只有 OGG 了,不过 OGG 也不太稳定,特别是全库同步,DDL 频繁的场景。

问题七、pdb 级别的负载监控性能诊断

在 12c 以前可以通过例如 dbtime 的指标,判断数据库负载,在升级到 12c,18c 后,对于数据库的负载监控有没有一个指标,判断当前容器内那个 pdb 占用 cdb 资源最多?在使用 oratop 时只能看到 cdb 层面的负载信息,还有别的指标可以快速定位资源占比较高的 pdb

诊断结论:12.2 可以生成 pdb 级别的 awr 报告,另外可以通过 OEM CC 监控查看各个 PDB 的负载情况。

问题八、重启多路径跟 udev 时,需要关闭数据跟数据库集群吗?

12c3 节点 rac 在 asm 添加新的磁盘时,用的多路径,跟 udev,修改 multipath.conf de 重启多路径跟 udev 时,需要关闭数据跟数据库集群吗?

诊断结论:一般情况下重启 udev 和 multipath 是不会影响到集群的,原来的链路都在,且重启过程很快。但是重启过程中也可能存在链路超时或者原链路夯住导致集群重启的情况。还有网卡如果使用 udev 绑定也会存在节点重启的情况。另外 multipath 有 reload 命令。

问题九、oracle 目录.cache 文件是否可以清理

数据库所在的文件系统 /u01 使用率基本快满,根据 find / -szie +500M -type f 查看大于 500M 的文件进行清理,释放空间,询问您后缀为.cache 文件可以清理吗,文件大小为 500M,或者那些文件可以清理,我一一查找进行清理。

专家解答:不知道能不能删的文件,最好 mv 到其他地方,过一段时间后再删除。另外,文件系统慢不一定是大文件占用,可能是很多小文件,比如 oracle 的 trace 文件。通过 du 命令去找到占用空间较大的文件或目录,再考虑删除。

问题十、oracle 11g 怎么清理 tnslsnr alert 日志

请问一下,oracle 11g 怎样安全清理生产环境的 alert 日志。我想清理。diag/tnslsnr/ERP-DB/listener/alert

诊断结论:这些都是监听日志文件,如果不需要使用,可以直接删除所有带数字的 xml 文件。
另外禁用 xml 形式生成监听日志,可以通过在 lisneter.ora 中设置如下参数:

DIAG_ADR_ENABLED_LISTENER = OFF

另外如果是数据库 alert 日志可以先压缩备份 alert 日志,再执行:> alert_SID.log

问题十一、请问如何怎么快速定位存储过程中执行慢的语句

请问如何快速定位存储过程中执行慢的语句

诊断结论:可以通过 ASH 找到存储过程的主 SQL 然后依次找到递归的所有 SQL,然后对这些 SQL 资源消耗做排序;存储过程记录日志;用 10046 跟踪运行存储过程的会话;用 PLSQL DEVELOPER 的 Profiler 调试,会展示每个 SQL 的运行时长。

正文完
 0