前言
作为DBA或运维/开发等技术人员，我们的职业生涯可能会遇到各种各样的技术问题，有已知的问题，当然也有未知的问题。
经常有人问到，“小y,为什么你知道的那么多呀，处理问题总是稳准快…”
实际上小y也是这么多年给客户做第三方数据库服务的过程中一点点积累起来的。
不放过任何一个未知问题，自成体系的方法论，对每一个未知问题进行持续和深入的研究，不断丰富/颠覆/完善自己的知识体系，并且去理解背后的实现原理以及背后实现的设计初衷，经年累月下来，自然就会懂的越来越多了。
原理的深入和积累，才是稳准快背后的支撑!
那么，当你遇到经验范围之外的未知问题或故障的时候,你是怎么做的呢...你的方法论又是什么呢。可能，我们当中的很多人也尝试努力过，但是坚持不下去，放弃了。
小y想说的是，这可能和你没有形成分析未知问题的方法论体系是有直接关系的。
今天的技术人生，依然还是文章预热加上晚上直播揭晓答案的方式，不过区别是今晚（2月17日）20点的直播，会增加更多互动，小y复现了一个“未知问题”，等你来挑战！赶紧预约今晚8点的直播吧！
1. 问题来了
这个问题，实际上是对背后原理不了解导致的！
2节点的ORACLE RAC，关掉节点1的数据库实例，SCAN IP和VIP还在节点1，不漂移，本身是正常现象，这本来就不是一个问题，就是这么设计的！
经过询问，这个问题背后实际上发生的真实的问题是：
应用一开始是可以通过RAC的SCAN IP成功连接到数据库的！
但是当关掉节点1的数据库实例时，虽然说剩下的节点2的实例处于正常服务状态，但是整个应用已经无法通过SCAN IP连接到数据库了！这不等于高可用失效了么！
应用无法连接数据库，报错为ORA-12514，监听里没有该服务。
进一步的检查，发现SCAN监听里只注册了节点1的实例，居然没有注册节点2的实例！如下图所示
而正常情况下，应该注册2个实例！应该如下图所示才对
那么问题的本质就是RAC部分节点无法注册实例信息到SCAN监听上！
2. 重现问题
小y接下来让这位同学停掉节点1的实例，重现连接数据库ORA-12514报错，如下所示：
节点1的SCAN监听里自然就没有服务了！
因此应用通过SCAN IP就无法连接到数据库上了，报错ORA-12514，监听里没有该服务！
连接过程和报错信息如下图所示：
这个时候SCAN IP和VIP1都还在节点1上，没有发生漂移，属于预期。
以下是该机器的IP信息（已脱敏），其中28是SCAP IP,26是节点1的VIP。
我们接下来到存活的节点2，查看本地监听LISTENER的状态，正常，如下图所示：
因此，应用通过修改数据库的连接串，改为连接节点2的VIP地址即27，可以成功连接DB。但不解决该问题，通过SCAN IP连接数据库就无法实现了。
3. 思考时间
文章到这里，大家不妨停一下，思考一下。
如果是你，接下来你打算分几步来分析，又需要哪些信息来帮助你找到问题的原因，并且如何解决呢…
思考时间
……
什么时候往下翻，由你决定…
……
4.一张比喻和
一张图来理解SCAN
在分析问题之前，我们需要掌握实例注册到SCAN监听的原理，以及应用通过SCAN IP连接到数据库的过程。
如果做一个比喻，SCAN监听的作用或原理，可以理解为医院的分诊台。
＋
当患者去看内科看病时，医院有多个科室都可以看，例如内科1（位于1号楼108室）和内科2（位于2号楼208室）。内科1和内科1就类似RAC 2个对外提供服务的实例。
＋
患者不需要记住内科1和内科2的位置，只需要记住分诊台的位置就可以了(应用只需要通过SCAN IP来连接数据库就可以了)。
＋
以后即使内科1不在1号楼108室了，而是搬到了3号楼303，对患者来说，也没关系，只要找到分诊台，分诊台告诉患者，你去3号楼303就可以到内科1看病了，或者你取2号楼208室就可以到内科2看病了！这是一个重定向的过程。
＋
当内科1开门时（数据库启动），内科1将会通知分诊台，内科1的位置在哪里。那么内科1如何知道分诊台在哪里呢？数据库参数remote_listener就定义了分诊台的位置。而内科1的位置在哪里，则是由数据库参数LOCAL_LISTENER参数来定义的。
＋
同样的，当内科2开门时，内科2也将会通知分诊台，自己的位置在哪里。
＋
SCAN LISTENER分诊台将按照2个科室的定期汇报的负载来进行患者分流和重定向，也就实现了负载均衡。
＋
应用访问SCAN IP的1521端口，想要建立连接。此时SCAN监听将返回节点1的VIP或节点2的VIP以及端口给应用，应用将按照VIP1或VIP2去连接具体某个节点的本地监听（名字为LISTENER的本地监听），是一个重定向的过程！
＋
当内科 1不方便接诊时（类似节点1停掉实例），分诊台也将即刻知悉该消息，因此数据库中SCAN监听里不再存在该实例的信息，后续也就不再分发/重定向到该节点上了。
SCAN的原理图如下图所示：
过程如下（上述解释还不理解的可以再看下这段描述）：
＋
RAC1的实例启动时，PMON或LREG进程将按照数据库参数REMOTE_LISTENER的值找到SCAN LISTENER的IP和端口，并告诉SCAN LISTENER自己本地的监听地址是多少（本地监听地址来自数据库参数LOCAL_LISTENER，后面SCAN监听将应用的连接重定向到该IP/port来），见上图1和2。
＋
同样的，RAC2的实例启动，PMON或LREG也按照类似过程注册自己的本地监听地址到SCAN监听，见上图3和4。
＋
如此一来，SCAN监听就知道了有2个实例可以提供服务，并且知道了两个实例的服务的监听地址是多少。
＋
应用通过SCAN IP连接数据库，SCAN监听处理创建链接的请求，见上图5。
＋
SCAN 监听按照注册进来的2个实例的负载，给应用返回2个实例的LOCAL_LISTENER地址，即返回节点1的VIP或节点2的VIP，见上图6。
＋
应用受到返回的重定向的请求，直接访问节点1的VIP1:1521或节点2的VIP2:1521，并最终建立连接。
那么，现在的问题就在于，为什么两个实例都活着，都可以对外提供服务，但是SCAN监听里确只有一个节点（节点1）的注册信息呢？数据库启动或者PMON/LREG后台进程不是定期往SCAN监听去注册自己实例的信息的么？
按照上述的原理图，我们一起进入头脑风暴…
5.头脑风暴
5.1 是因为remote_listener配置错误么
两个节点检查remote_listener参数，如下图所示：
其中ta19rac-scan是主机别名，在2个节点的/etc/hosts里都对应28这个scan ip，配置是正确的！
5.2 是remote_listener指向的SCAN IP
或端口不通么
如上图所示，在数据库2个节点分别ping和telnet remote_listener参数定义的ip和端口，都是通的，没问题。
5.3 是PMON的问题么
按照上节的原理图，PMON负责注册，是不是他出现了问题呢？
检查相关trace,没有生成trace,PMON top命令显示不消耗CPU等资源，v$session显示也没有处于异常等待。
BTW:该版本下，负责监听注册的后台进程不再是pmon,而是新增lreg(即Listener Registration)来负责。
5.4 是LREG的问题么
上图表示LREG进程没有继续更新。
5.5 SCAN监听日志有报错么
查看SCAN监听日志，发现日志里依然在定期注册，从返回码*0看，似乎是成功的，但实际没有注册进去。如下图所示。
5.6 手工注册可以解决问题么
定期注册解决不了，手工注册显然也不可以。
以下是在节点2（该节点实例信息在SCAN监听里没有）执行手工注册的截图。
SCAN监听日志listener_scan1.log显示（位于节点1）上可以收到服务注册请求，日志如下所示
5.7 是SCAN IP在网络上出现了重复IP么
使用ARP 命令显示没有出现多个MAC地址,因此网络上不存在重复IP。
再者，如果IP重复，则有一半概率是可以连接上数据库的，而不是现在的停掉节点1后，通过SCAN IP连接数据库会出现持续的报错。
5.8 是有其他数据库的remote_listener的参数设置到了该数据库的SCAN 监听上么
停掉节点1后，SCAN监听里显示不存在任何数据库（本库或者其他库）注册过来的信息！
因此不存在该情况。
5.9 郁闷…还有什么可能呢…
再想想，还有其他什么可能呢…
6.真相即将揭晓
请关注上图中的视频号，并预约直播， 2月17日（周四）即今天晚上八点，小y将用半个小时为大家揭晓服务无法注册到SCAN监听的真相！记得帮转发并预约直播哦。
另外，小y《量化思维下的SQL优化》课程正在热卖，希望能给大家带来不一样的收获！
另外，近期北京顺义附近有ORACLE DBA职位开放，如果你或你的朋友想在顺义附近发展，欢迎联系小y!
欢迎如果你想和小y成为同事，一起为各行各业的客户服务，欢迎加入我们。
中亦科技目前开放如下地区和职位：
//可添加公司HR同事的微信进行咨询
（1）Oracle DBA职位：
北京、上海、深圳、广州、呼和浩特、昆明
（2）MySQL DBA职位：
北京、上海、长春、杭州
更多实战分享和风险提示，请关注“中亦安图”公众号和小y视频号！也可以加小y微信，shadow-huang-bj，进微信群探讨技术。
喜欢就转发吧，您的转发是我们持续分享的动力！
小y微信以及公益问诊群（三群）的二维码如下（添加过公益群的朋友请勿重复添加）
