20200511-记一次惨败的Oracle DBA面试经历

本文链接：https://blog.youkuaiyun.com/chenoracle/article/details/144728999

在这里插入图片描述

说明：

记录下前段时间一次印象比较深的 Oracle DBA 面试经历，为什么印象比较深呢，因为全程都是被按在地上摩擦的，暴露出很多技术盲点，之前对很多技术细节不求甚解，解决掉一个问题后，没有去深究问题的根本原因，总想着以后有时间再去研究。

之前面试官已经看过简历了，没有自我介绍环节，直接开始第一个问题：

1 说下你处理过比较有难度的一次故障

这个问题实际上是想看下我擅长的领域、对问题的理解、知识的深度等。

我说了一个4,5 年前处理的一个案例，确实是我印象最深的，一个 OLAP 类型的数据库宕机了，刚接手的数据库无备份，周五晚上出现宕机，历时两天时间，在周一早上我才将故障搞定。

故障大概是因为undo 段头块损坏导致数据库宕机，因为数据库同时有 5 个以上的用户在执行 impdp 操作，大量的数据加载， undo 一直处于繁忙状态。无备份情况下是可以通过 _corrupted_rollback_segments 跳过损坏段启动数据库的，但是数据库无法 open, 也就无法查看到具体的 rollback_segment 名称，告警日志和 trace 日志里也没有输出损坏的段名。问题似乎陷入了死循环，想 open 数据库的前提是知道 rollback_segment ，但是想知道 rollback_segment 的前提又是 open 数据库。实际上在不启动数据库的情况下也有很多方法可以知道 rollback_segment 名称的，比如通过操作系统 strings 命令查看 system 数据文件里的 rollback_segment 名称，命令如下：

strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u > listSMU

rollback_segment 信息是记录在 system 表空间 undo$ 表里的，我当时错误的认为 rollback_segment 信息是记录在 undo 表空间里的，所以执行 strings undotbs01.dbf 什么也没查到，这也是基础不牢的弊端，无奈只好考虑使用自己更不熟悉的 bbed 工具来查看 rollback_segment ，最终也是通过 bbed 工具，在数据库关闭的状态下，读取出了全部的 rollback_segment ，再将 rollback_segment 加入到 _corrupted_rollback_segments 解决了这个问题，具体问题可以看我的另一篇博客：

http://blog.itpub.net/29785807/viewspace-2128326/

在我讲述这个案例时突然意识到面试官会不会针对这个问题继续问我bbed 的细节，比如数据块格式，偏移量等等，时间过去很久了，具体细节已经都忘得差不多了。

面试官可能也是为了避免一开始问的太深我答不上来显得尴尬，并没有继续问我更深的细节，而是问了下比较基础的坏块问题：

2 说下坏块的种类

我只知道有物理坏块和逻辑坏块，物理坏块一般是块格式本身出现损坏，逻辑坏块一般是oracle BUG 引起的。

3 物理坏块和逻辑坏块又可以细分哪几类？比如物理坏块的块断裂等？

不清楚物理坏块和逻辑坏块更细的分类了，之前也没有关注过，即使面试官给了提示也没回答上来。也是平时处理问题时没有注意细节和及时总结的后果，存在很多技术上的盲点。

这是后来在网上查的关于坏块的描述。

Physical and Logical Block Corruptions. All you wanted to know about it. (Doc ID 840978.1)

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=80681922571215&id=840978.1&_afrWindowMode=0&_adf.ctrl-state=6q340rfff_80
Physical Block Corruptions

This kind of block corruptions are normally reported by Oracle with error ORA-1578 and the detailed corruption description is printed in the alert log. 

Corruption Examples are:
·  Bad header - the beginning of the block (cache header) is corrupt with invalid values
·  The block is Fractured/Incomplete - header and footer of the block do not match
·  The block checksum is invalid
·  The block is misplaced
·  Zeroed out blocks  Note 1545366.1

Physical Corrupted Blocks consisting of all Zeroes indicate a problem with OS, HW or Storage (Doc ID 1545366.1)
Logical Block Corruptions

Corruption Examples are:
·  row locked by non-existent transaction - ORA-600 [4512], etc
·  the amount of space used is not equal to block size
·  avsp bad
·  etc.

https://blogs.oracle.com/database4cn/oraclecorruption-

概述
数据库坏块(corruption) 的类型可以按照坏块所属对象的不同，分为用户数据坏块，数据字典坏块， Undo 坏块，控制文件坏块， Redo 坏块， Lob 坏块， index 坏块等等；也可以按照坏块产生的原因，分为物理坏块 (physical corruption) 和逻辑坏块 (logical corruption ) 。

本文主要讨论用户数据发生物理坏块(physical corruption) 分析和解决方法。

物理坏块
常见的物理坏块（Physical Block Corruptions ）有块头和块尾信息不一致 (Fractured/Incomplete) ， checksum 值无效，数据块信息全部为 0 等情况，并且可能伴随错误 ORA-1578 和 ORA-1110 。

为了及时发现物理坏块和准确定位坏块产生的原因，oracle 建议设置初始化参数 DB_BLOCK_CHECKSUM=TYPICAL （默认值）。一般情况下，物理坏块是由于底层 OS/disk 系统错误 / 损坏，导致数据块被修改，数据块标志为坏块 (corruption)

数据块的Checksum 值无效是一种常见的物理坏块，当数据库初始化参数 DB_BLOCK_CHECKSUM=TYPICAL （默认值）时， DBWR 进程将数据块写入 disk 时会计算数据块的 Checksum ，并且将 Checksum 值记录在数据块的位置 offset 16 和 17 ；当从 disk 读取该数据块时， oracle 重新计算数据块的 Checksum ，并且与记录在数据块中的 Checksum 做异或运算（ Xor ），如果异或结果为非 0 ，说明数据块被修改过，数据块为坏块 (corruption) 。

https://www.cnblogs.com/yhq1314/p/11190045.html

oracle bug 可能导致逻辑坏块的产生 . 特别是 parallel dml. 例如 :
Bug 5621677 Logical corruption with PARALLEL update
Bug 6994194 Logical corruption from UPDATE DML
Bug 15980234 ORA-1400 / logical corruption from direct path INSERT ALL(fail with ORA-1400, in direct path / PDML) 。

看下docs.oracle.com 里对 corrupt block 的说明：

https://docs.oracle.com/en/database/oracle/oracle-database/20/bradv/glossary.html#GUID-44B5A820-D859-47F5-99CC-56A95AF4BB3E

corrupt block

An Oracle block that is not in a recognized Oracle format, or whose contents are not internally consistent. Typically, corruptions are caused by faulty hardware or operating system problems. Oracle identifies corrupt blocks as either logically corrupt (an Oracle internal error) or media corrupt (the block format is not correct).

You can repair a media corrupt block with block media recovery, or dropping the database object that contains the corrupt block so that its blocks are reused for another object. If media corruption is due to faulty hardware, then neither solution works until the hardware fault is corrected.

4 出现坏块后，如何判断是否是存储硬件问题呢？客户说他们存储硬件没问题，你能通过比如日志还是什么工具说明到底是不是存储硬件的问题？

这个也是我之前一直困扰的问题，之前处理过物理坏块的问题，也想过是不是因为存储硬件出现问题导致的坏块，因为客户曾不同时间多次出现过坏块问题，也让客户去检查存储问题了，但是后来没有继续深入研究过。

面试时回答的是先基于 rman 进行 block 级别的恢复，恢复坏块的影响，查看系统日志如 messages 等，然后观察，如果后续又常出现物理坏块问题，可能和硬件有关，物理坏块通常是由于底层OS/disk 系统错误 / 损坏，导致数据块被修改，但是当时也不能肯定到底是通过哪个日志或者哪种工具能 100% 确定到底是不是硬件问题导致的物理坏块。

连续两个问题答的都不好，气氛难免有点尴尬，面试官不在继续问坏块相关的问题了，换个问题，缓解下气氛。

5 rac 网络心跳出现故障，一个节点服务器自动重启后又恢复正常了，如何判断是否是网卡有问题，查看哪些日志。

当时记得是有个集群同步服务的，是 css ，错记成了 ctss 了，概念和原理没记清，当时也是答的一塌糊涂。

实际上是集群层通过CSSD 进程来维护节点和节点之间关系的，在集群层做心跳，需要检查集群件的告警日志

alert<HOSTNAME>.log($GRID_HOME/log/$hostname)

和检查 ocssd.log($GRID_HOME/log//cssd) ，对应的后台进程为 cssd.bin 。

但是这些日志只能查看到misstime,nodexxx left cluster 等信息，并没有网卡故障信息。

还可以通过 ethtool 、 mii-too 等工具查看网卡状态，查看 messages 里关于网卡的信息，如果有监控平台，可以看对应网卡的历史监控信息，流量、连通性等。

6 说下 rac 有哪些进程分别什么用途。

Rac 后台进程有 LMON,LCK,LMD,LMS,DIAG 等，服务有 crs,css,ctss,evmd,ons 等。当时想起了几个进程 ,LMON,LMS,LMD, 但是却想不起来具体哪个进程做什么用的了，最后基本上什么也没答上来。

7 ASM 磁盘组或磁盘故障，在替换和修复之前需要提前准备什么。

之前处理过 OCR 磁盘组误被格式化的问题，也没提前准备什么，直接用本地的 ocr 和 votedisk 的自动备份恢复了丢失的数据到新的磁盘组里。也不清楚是要提前备份现有文件比如磁盘头、物理全备等，还是其他什么意思，平时遇到的并不多，经验和理论都有欠缺，也没说出需要准备和注意的。

8 log file sync 等待事件相关的 oracle bug 遇到过哪些？

说了下 log file sync 大概原理和可能的原因，但是具体哪些 oracle bug 一个也没记住。之前也整理过 log file sync 相关知识点，但是具体 bug 让我跳过了没有关注， MOS 上查了下， BUG 很多，只有真正处理过才会有印象吧。

http://support.oracle.com

WAITEVENT: "log file sync" Reference Note(Doc ID 34592.1)

The log file sync wait may be broken down into the following components:
1. Wakeup LGWR if idle 
2. LGWR gathers the redo to be written and issue the I/O
3. Time for the log write I/O to complete
4. LGWR I/O post processing
5. LGWR posting the foreground/user session that the write has completed
6. Foreground/user session wakeup

在这里插入图片描述
前面的问题回答的实在太水了，气氛极度尴尬，面试官又尝试出个送分题，缓和下气氛。

9 假如昨天下午 15 点到 15 点 01 数据库负载很大，今天如何去定位这 1 分钟内的问题：

分析昨天某个时间段1 分钟内的数据库性能？我常用 AWR 去分析过去某个时间段的数据库性能问题，但是 AWR 默认 1 小时收集一次快照，跨度太大了，很显然不适合分析过去 1 分钟的性能问题，除了 AWR 以外还有 ASH 和 ADDM ，平时用的也不多，好像也不能分析，难道是用一些我不知道的动态性能视图分析的吗？我知道的视图有

 v$session ， v$session_wait,v$session_wait_history

，但是这些最多只能保留最近 10 次的等待，昨天的会话信息肯定都没有了。实际上我已经想的差不多了，顺着 v $session_wait 和 v$ session_wait_history 视图再往下想应该就能想到 v $active_session_history ，然后想到 ASH 报告。 ASH 采用的策略是：保存处于等待状态的活动 session 的信息，每秒从 v$ session_wait 中采样一次，并将采样信息保存在内存中。由于平时处理性能问题时很少使用ASH 和 ADDM ，导致我直接把 ASH 跳过了，本来一道送分题的，硬生生让我答成送命题。