朋友咨询了一个问题，"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文件，记录了很多调用的堆栈信息，可以挖掘更多。
对众多的国产数据库来说，这种问题诊断的工具，是很值得借鉴的，无论是数据库本身还是数据库的使用者，都可能出现错误，但如果能提供一些暴露数据库内部执行的手段，就会有助于找到问题根因，解决这些问题。
如果您认为这篇文章有些帮助，还请不吝点下文章末尾的"点赞"和"在看"，或者直接转发pyq，
近期更新的文章：《推荐几款文本编辑器》《"'abrt-cli status' timed out"错误解决》《解读《行业标准管理办法》》
《学习和了解《行业标准管理办法》》
《MySQL的sysdate()和now()有什么区别？》
近期的热文：《推荐一篇Oracle RAC Cache Fusion的经典论文》
《"红警"游戏开源代码带给我们的震撼》
文章分类和索引：《公众号1300篇文章分类和索引》
