Oracle数据库揭露问题本质的利器 - errorstack
Oracle数据库揭露问题本质的利器 - errorstack
朋友咨询了一个问题，"Oracle停了所有应用的情况下(还有一个zabbix连接数据库)，有一个用户被锁了，通过locked_date看是昨天晚上10:05锁的，然后今天早上解锁后也是10:05分锁住的，期间应用也没启动过，从监听日志看只有zabbix在连，没有失败的连接，从数据库看没有job，也没有触发器。这个用户锁住的问题还有哪个方向排查？数据库里面还有别的东西需要排查的呢？"
其实之前也曾问过一些大佬相近的问题，我们看到的可能都是问题表象，重要的是能定位到根因，抓住本质，才能找到合适的解决方案。
定位根因的途径可能有很多，对Oracle来说，errorstack是其中之一。以定位产生ORA-28000用户被锁的场景，展示下errorstack的强大。
全局开启针对ORA-28000的errorstack，
SQL> alter system set events '28000 trace name errorstack level 4';
System altered.通过客户端，用错误的密码，创造出ORA-28000的场景，
此时从alert.log看到这条信息，说明已经捕获ORA-28000的错误，并且记录到BISALCDB_ora_9061.trc的trace文件中，
BISALPDB1(3):Errors in file /opt/oracle/diag/rdbms/bisalcdb/BISALCDB/trace/BISALCDB_ora_9061.trc:
ORA-28000: The account is locked.trace文件的内容很多，4.3M，但是只需要找些关键的信息，就可以满足我们的需求，找到client details，可以看到导致出现ORA-28000错误的客户端是机器名叫"test-computer"的电脑，登录机器的用户名叫test，应用程序是DBeaver。现在就基本明确了导致出现ORA-28000的罪魁祸首了，下一步操作，就是找到他，锤他。。。
service name: bisalpdb1
client details:
O/S info: user: test, term: unknown, ospid: 1234
machine: test-computer program: DBeaver 7?3?2 ? Main
application name: DBeaver 7?3?2 ? Main, hash value=2195501301记得关闭errorstack，
SQL> alter system set events '28000 trace name errorstack off';
System altered.Oracle的errorstack就像应用程序中加了断点调试，可以让我们很方便的找到一些问题的线索，如果有兴趣，可以关注下trace文件，记录了很多调用的堆栈信息，可以挖掘更多。
对众多的国产数据库来说，这种问题诊断的工具，是很值得借鉴的，无论是数据库本身还是数据库的使用者，都可能出现错误，但如果能提供一些暴露数据库内部执行的手段，就会有助于找到问题根因，解决这些问题。