神马文学网深入了解游标与共享SQL区、私有SQL区的问题
来源：百度文库 编辑：神马文学网 时间：2024/05/05 02:16:08
UGA堆中所包含的内存结构包括：
私有SQL区域（Private SQL Area）：这部分区域包含绑定变量信息以及运行时的内存结构等数据。每一个发出SQL语句的session都有自己的私有SQL区域。这部分区域又可分成两部分：
永久内存区域：这里存放了相同SQL语句多次执行时都需要的一些游标信息，比如绑定变量信息、数据类型转换信息等。这部分内存只有在游标被关闭时才会被释放。
运行时区域：这里存放了当SQL语句运行时所使用的一些信息。这部分区域的大小尺寸依赖于所要执行的SQL语句的类型（sort或hash-join等）和复杂度以及所要处理的数据行的行数以及行的大小。在处理SQL语句时的第一步就是要创建运行时区域，对于DML（INSERT、UPDATE、DELETE）语句来说，SQL语句执行完毕就释放该区域；而对于查询语句（SELECT）来说，则是在所有数据行都被获取并传递给用户以后被释放，或者该查询被取消以后也会被释放。
Session相关的信息。这部分信息包括：
正在使用的包（package）的状态信息。
使用alter session这样的命令所启用的跟踪信息、或者所修改的session级别的优化器参数（optimizer_mode）、排序参数（sort_area_size等）、修改的NLS参数等。
所打开的dblinks。
可使用的角色（roles）等。
The private SQL area of a cursor is itself divided into two areas whose lifetimes are
different:
The persistent area, which contains, for example, bind information. It is freed
only when the cursor is closed.
The run-time area, which is freed when the execution is terminated.
分析树与执行计划只保留一份，并且只存在于shared pool中，至于为什么？如果保留多份，我们如何控制这条SQL语句所引用的相关对象不发生变化呢？
应该不会拷贝的，这样会造成object不一致的可能uga里存的是类似指针，用户再次调用这个cursor，uga里存了足够的信息都指向shared pool里，不需要再去和别的进程竞争查找，如果拷贝会很麻烦，如果上千个用户开了cursor cache，难道要拷贝上千个？而且如果shared有重要的变化的话那就更麻烦了
no, 分析=parse，先parse，再execute. 而且open cursor也绝对是在execute之前，甚至在parse之前。open了cursor才能parse, exexute, fetch。
cursor是idea of you do everything，提交了sql，想处理，想开始parse, exec？行！open cursor先！cursor在处理sql得最开始打开，在处理完sql关掉-----或应该被关掉。
soft parse 实际上是 hard parse 所经历的步骤的一部分，它不再重新生成执行计划，但是需要做 语法、权限等检查和校验，然后要去 shared pool 中搜索相同的sql ，搜索到之后发现可以 使用已经存在的执行计划 就不再自己生成了。
设想一下
soft parse 是得到 SQL 的 hash_value , 根据hash_value 在 shared_pool 中 找到相应SQL , 然后还要对比一下 SQL的执行环境/参数等，才能确定使用某个SQL_PLAN ,并把这个SQL_PLAN 和当前的cursor 做关联
而soft soft parse 是直接得到一个 cursor , cursor 直接就对应了 SQL_PLAN
效率当然不一样
私有SQL区域（Private SQL Area）：这部分区域包含绑定变量信息以及运行时的内存结构等数据。每一个发出SQL语句的session都有自己的私有SQL区域。这部分区域又可分成两部分：
永久内存区域：这里存放了相同SQL语句多次执行时都需要的一些游标信息，比如绑定变量信息、数据类型转换信息等。这部分内存只有在游标被关闭时才会被释放。
运行时区域：这里存放了当SQL语句运行时所使用的一些信息。这部分区域的大小尺寸依赖于所要执行的SQL语句的类型（sort或hash-join等）和复杂度以及所要处理的数据行的行数以及行的大小。在处理SQL语句时的第一步就是要创建运行时区域，对于DML（INSERT、UPDATE、DELETE）语句来说，SQL语句执行完毕就释放该区域；而对于查询语句（SELECT）来说，则是在所有数据行都被获取并传递给用户以后被释放，或者该查询被取消以后也会被释放。
Session相关的信息。这部分信息包括：
正在使用的包（package）的状态信息。
使用alter session这样的命令所启用的跟踪信息、或者所修改的session级别的优化器参数（optimizer_mode）、排序参数（sort_area_size等）、修改的NLS参数等。
所打开的dblinks。
可使用的角色（roles）等。
The private SQL area of a cursor is itself divided into two areas whose lifetimes are
different:
The persistent area, which contains, for example, bind information. It is freed
only when the cursor is closed.
The run-time area, which is freed when the execution is terminated.
分析树与执行计划只保留一份，并且只存在于shared pool中，至于为什么？如果保留多份，我们如何控制这条SQL语句所引用的相关对象不发生变化呢？
应该不会拷贝的，这样会造成object不一致的可能uga里存的是类似指针，用户再次调用这个cursor，uga里存了足够的信息都指向shared pool里，不需要再去和别的进程竞争查找，如果拷贝会很麻烦，如果上千个用户开了cursor cache，难道要拷贝上千个？而且如果shared有重要的变化的话那就更麻烦了
no, 分析=parse，先parse，再execute. 而且open cursor也绝对是在execute之前，甚至在parse之前。open了cursor才能parse, exexute, fetch。
cursor是idea of you do everything，提交了sql，想处理，想开始parse, exec？行！open cursor先！cursor在处理sql得最开始打开，在处理完sql关掉-----或应该被关掉。
soft parse 实际上是 hard parse 所经历的步骤的一部分，它不再重新生成执行计划，但是需要做 语法、权限等检查和校验，然后要去 shared pool 中搜索相同的sql ，搜索到之后发现可以 使用已经存在的执行计划 就不再自己生成了。
设想一下
soft parse 是得到 SQL 的 hash_value , 根据hash_value 在 shared_pool 中 找到相应SQL , 然后还要对比一下 SQL的执行环境/参数等，才能确定使用某个SQL_PLAN ,并把这个SQL_PLAN 和当前的cursor 做关联
而soft soft parse 是直接得到一个 cursor , cursor 直接就对应了 SQL_PLAN
效率当然不一样
深入了解游标与共享SQL区、私有SQL区的问题
共享SQL区、私有SQL区与游标
sql server 游标的使用
oracle11g新特性-自适应游标与 SQL 计划管理
[精华] [原创]PL/SQL的SELECT FOR UPDATE游标
SQL
rs.open sql,conn 与conn.execute(sql)的区别
v$sql v$sqlarea v$sql_shared_cursor及游标
SQL对象名无效的问题
深入SQL SERVER 2000的内存管理机制(一)
深入SQL SERVER 2000的内存管理机制(二)
深入SQL SERVER 2000的内存管理机制(三)
深入探索MS SQL Server 2000网络连接的安全问题
深入分析SQL Server的数据转换服务
深入SQL SERVER 2000的内存管理机制(二)
sql 面试问题
Sql Server 版本问题
sql 面试问题1
ASP连接SQL Server---未与信任 SQL Server 连接相关问题_醉爱
SQL中与IP相关的常见问题
SQL 2005 札记 (1) -- SQL 2005 远程连接的问题 - Vitoria...
SQL Server 2000的远程连接问题 MS-SQL Server / 应用实例 -...
SQL Server 2008 对 T-SQL 语言的增强-其它相关问题-华夏名网
SQL Server还原问题总结