【ASK_ORACLE】Library cache pin 与 library load lock的关系和区别

Library cache pin 与 library load lock 关系和区别Library cache pin 和 load lock 可能出现在对 PL/SQL, views, types 等的编译与重编译期间。这种编译总是显式的(比如应用安装，升级，打补丁)。但是对象重编译也可能发生在对象失效期间。 在处理那些让人摸不着头脑的 library cache pin 和 load lock 等待时，则需要检查为什么对象失效了。很有可能失效是由于某些操作修改了它所依赖的对象的"LAST_DDL"。通常来说这些操作包括对象维护操作，比如 ALTER, GRANT, REVOKE, replacing views 等等。还有就是收集 optimizer statistics 也会造成 cursor 失效，进而导致 library cache 的重装载。这个现象在 Oracle Server Application Developer's Guide 的object dependency maintenance 部分有描述。 对象失效以后，Oracle 尝试在第一次访问这个对象时去重编译它。有些情况下，如果其它 session 已经 pin 住这个对象，可能就会出现问题。并且在有大量活跃用户与复杂依赖关系(例如，很多交叉依赖的 packages 或package bodies)的情况下更容易出现问题。有些时候对对象的编译会持续数小时从而阻止其它 session 对其的访问。 在 library cache dump, level 10 可以看到:查找 ALTER ... COMPILE 语句和 lock=X 或 pin=X 的 objects/handles.  特别注意：1. 需要频繁使用的 stored PL/SQL 所依赖的对象，对其 altering, granting, evoking 操作需要特别小心。实际上，解决这种问题很大程度上依赖于应用程序和系统维护的时间。应用程序开发者需要考虑某些决定可能会对应用程序的可扩展性及性能产生负面影响。 2. Load lock总是以排它模式获得的。如果 session load lock 繁忙，session 将一直等待，直到锁变成可用。