首先,我尝试登录PLSQL,想查询一下HOEGH用户下表的编译时间,确认一下我执行imp操作的具体时间。令人意外的是,使用PLSQL登录时报错了,提示“ORA-28000: the account is locked”。
有点晕,谁动了HOEGH用户?
我登陆到sys用户,通过下面的sql语句查询HOEGH用户的帐户状态以及锁定时间。
点击(此处)折叠或打开
从查询结果来看,HOEGH用户确实被锁了,而且,锁定操作就发生在几分钟之前。
虽然没弄明白怎么回事,还是先把问题解决了再说吧。我使用“alter user HOEGH account unlock”语句把HOEGH用户解锁,然后登录PLSQL,查询HOEGH用户下表的编译时间。结果证明我周五执行数据更新并没有遗漏HOEGH用户,所有表的编译时间都是上周五。
我怀疑是不是刚才启动的程序版本有问题。于是,我让同事重新运行应用程序,显示的界面仍然不是最新数据,问题依旧。
好吧,解决问题要紧!我重新执行了一次导入脚本,脚本先对所有表执行truncate操作,然后执行imp进行数据导入。没想到执行imp操作时再次报错,提示“ORA-28000: the account is locked”。
HOEGH用户被锁定了,again!
没想明白。
再次使用“alter user HOEGH account unlock”语句把HOEGH用户解锁,重新执行导入脚本,这次数据顺利导入成功。
这次总该没问题了吧。让同事第三次启动应用程序,问题依旧!!!
通常来说,程序不会出错,肯定有其他问题。
果然,过了一会,同事不好意思的告诉我,密码不小心配错了,改过来就OK了。
这个原因我还真没想到,问题弄清楚了就好,谁都有打盹的时候嘛。
可是,为什么HOEGH用户会被一而再地锁定呢?估计也和错误密码有关,最直接的就是Oracle数据库的安全策略。于是,我执行以下语句来查询:
点击(此处)折叠或打开
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/30162081/viewspace-1774056/ ,如需转载,请注明出处,否则将追究法律责任。