11 2020 档案
摘要：生产库中，突然出现了大量的cursor pin s wait on x等待，第一反应是数据库出现了硬解析，查看最近的DDL语句，没有发现DDL。那么有可能这个sql是第一次进入 在OLTP高并发下产生硬解析，导致出现大量等待。但是，此次 发现等待时间很长，远远超过硬解析应该有的时间，再次分析后发现是
阅读全文
摘要：生产库中出现了大量的锁表，需要得到当时程式执行的SQL以及其带入的值 1.查看SQL SELECT SQL_ID FROM V$SESSION WHERE SID=(SELECT FINAL_BLOCKING_SESSION FROM V$SESSION WHERE BLOCKING_SESSION
阅读全文
摘要：1.查看统计信息被锁定的表 SELECT OWNER, TABLE_NAME FROM DBA_TAB_STATISTICS WHERE STATTYPE_LOCKED IS NOT NULL AND OWNER = 'XXXXX' GROUP BY OWNER, TABLE_NAME; 2.自动统
阅读全文
摘要：1.统计信息收集 参考：https://www.cnblogs.com/lijiaman/p/13039528.html 1.1.手动数据库统计信息收集 BEGIN DBMS_STATS.gather_database_stats; END; / 或者直接调用SYS下的GATHER_STATS_JO
阅读全文
摘要：1.cursor pin s是一个共享锁，一般情况下是因为发生在SQL短时间内大量执行 案例：在生产库中，突然出现大量的cursor pin s的等待，询问是否有动作后，同事说有编译存储过程（被误导了，如果是因为存储过程编译失效，大量调用，应该是library cache pin） 最后的原因是同时
阅读全文
摘要：library cache pin大部分都是因为编译存储过程造成的 查找造成问题的数据库对象（一般为存储过程） SELECT * FROM v$session_wait WHERE event = 'library cache pin' ORDER BY p1raw; SELECT kglnaown
阅读全文
摘要：1.异常现象 2.解决方法 2.1.进入单用户 输入root的密码，进入单用户模式 2.2.重新挂载 mount –o rw,remount / 2.3.取消自动挂载 vi /etc/fstab # 注释可以用# #/dev/sdb1 /D37data01 ext4 defaults 1 2 #/d
阅读全文
