oracle9i的体系结构(编辑修改稿)内容摘要：
share pool 中没有做 keep。 （这个是普遍原因） cursor_sharing=force 或者会话缓存游标没有用（ session_cached_cursors） 共享池 2 SQL老化的问题 不停的被新 sql排挤出共享池的过程。 解决办法：绑定变量 共享池越大是否性能越高 不是， cpu管理开销增大， latch占用时间变长 绑定变量的作用 增加重用，防止老化 Cursor_sharing的影响 8174之后的版本中使用 force Log buffer 作用 计算依据 和 checkpoint的影响 每 3秒钟 有人提交 1/3满或者满 1M的 Log buffer内容时 注意：由于以上原因，动辄数十兆的 redo log buffer的分配是对内存的浪费。 从增大该参数中能获益的可能性极小。 大池 大池的推出的原因 系统需要使用大块内存，用完即可，无需缓存住其内容。 如果不存在，则这部分内存将从共享池中获取，变相的实现对共享池的保护 以下操作是将使用大池： MTS－在 SGA中分配 UGA区 平行操作－平行进程间的消息缓存区 RMAN－为备份操作分配大片的 IO缓存 大池与共享池的区别： 共享池中的内容由于使用频率高，所以被缓存；而大池不是。 进程 服务进程 专用模式和共享模式的权衡 专用模式：稳定但相对资源消耗多 共享模式：欠稳定，适合 olpt系统但并非最好解决办法 后台进程 Pid10,谨慎的 debug这些后台进程 从属进程。阅读剩余 0%
本站所有文章资讯、展示的图片素材等内容均为注册用户上传(部分报媒/平媒内容转载自网络合作媒体)，仅供学习参考。
用户通过本站上传、发布的任何内容的知识产权归属用户或原始著作权人所有。如有侵犯您的版权，请联系我们反馈本站将在三个工作日内改正。