显示在库缓存缓存（共享池）中被缓存的库对象它比动态性能表 V$LIBRARYCACHE提供更多细节，并且在寻找共享池
中活动对象方面更加有用这些对象包括表，索引簇，PL/SQL过程和包装并触发。在共享池对象级别的统计信息
|
|
对象所有者(如果是应用的sql语句，此列值一般都为空)
|
|
对象名称 (sql语句或者匿名块/游标的前1000个字符)
|
|
数據库的链接名 如果存在dblink
|
|
|
|
对象占用可共享内存的大小（单位：btyes）
|
|
这个对象被加载到内存的次数. 当这个对象无效的时候这个值仍然会增加.
|
|
|
当前鎖住这个对象的session数
|
|
当前执行这个对象的session数
|
|
|
保护这个对象的子锁数目.
|
6.相关sql语句:--形成生成pin住共享池中当前没有被pin住的对象的sql语句
--显示共享池Φ不同类型对象的分布.
--找出加载次数比较多的对象
可以看到许多对象（表）被反复loads的次数很大，在v$db_object_cache表里被反复load多数是因为缓存不够被挤絀。
而造成这种原因多数是因为没有绑定变量大量重复加载一样的语句造成的。而通过增加share_pool不能解决根本问题
1修改sql语句，改用变量代替常量（开发来完成）
2可以keep一些经常用到的小表。dbms_shared_pool数据包可以通过 loads的次数和表的大小综合考虑要keep那些表
--对象在共享池中消耗的内存 在8點中所描述的查找需要连续内存的查找语句
--数据库稳定时，决定哪个对象进行pin住操作.
--列出大的没有被pin住的对象.
--列出大的没有被pin住的过程包和函数
7.其它需要被pin入内存中的对象主要有：常用的较大的存储对象，如standard、diutil包；编译的常用的triggers；sequences
8.db_object_cache和碎片化碎片化造成在共享池中虽然有許多小的碎片可以使用，但没有足够大的连续空间这在共享池中是普遍的现象。
消除共享池错误的关键就是即将加载对象的大小是否可能会产生问题一旦知道了这个存在问题的PL/SQL，那么
就可以在数据库启动时(这时共享池是完全连续的)就将这个代码固定这将确保在调用大型包时，它已经在共
享池里而不是在共享池中搜索连续的碎片(在使用系统时，这些碎片可能就不复存在)
可以查询V$DB_OBJECT_CACHE视图来判断PL/SQL是否很大並且还没有被标识为"kept"的标记。今后需要加载这些
对象时可能会产生问题(因为它们的大小和需要占用大量连续的内存)。通过查询V$DB_OBJECT_CACHE表可以
發现那些没有固定，但由于所需空间太大而很有可能导致潜在问题的对象
}
点击联系发帖人
