在进行ArcSDE版本压缩的时候,好多用户会有这么一种担心的想法,这个版本压缩就是一点击功能,就等着,假如出现异常情况,比如死机情况,我的压缩进行了一段时间,是不是我的数据会有一部分压缩了一部分没有压缩而导致破坏。
这种担心是多余的,在ArcSDE进行版本压缩时,相关的事务会存放到UNDO表空间中,如果出现异常问题,相关的事务是会进行回滚的,不会出现破坏数据的情况。从上面的描述可以看出,在我们进行版本压缩之前,有必要对我们数据库的UNDO表空间进行扩容。
那么简单看看UNDO表空间
Undo数据的作用:
1. 回退事务 通过rollback语句可以取消事务变化
2. 读一致性 Commit提交后。。
3. 事务恢复 例程恢复的一部分。
4. 倒叙查询 从过去的某个时间点查询。
undo表空间是唯一的一个表空间用来存放undo信息,不可以创建其他的对象在这个表空间中,如表,索引,只有当db是自动undo管理模式时才使用它(默认),一个db可以包括多个undo表空间,但同一时间只能用其中的一个, undo表空间使用undo段去管理数据,db会自动创建和维护这些段.
每个事务的第一个dml操作产生时,事务被指定了一个undo段(可以认为是一个事务表)在当前的undo表空间中,在极少数环境中,如果实例没有设计undo表空间,那事务将使用system undo段,每个undo表空间由一组本地管理的数据文件组成,就像其他的表空间,区由undo块组成,每个区的状态都在bitmap中体现了,在任何点上,一个区要不就分配给一个事务表,要不就是空闲的,可以创建bigfile类型的undo表空间。
上面提到的两个参数决定
UNDO_MANAGEMENT=auto
UNDO_TABLESPACE=undotbs
在自动UNDO管理模式下,系统为UNDO段提供专门的处理事务任务和控制UNDO段空间的分配。一个异常的事务能消耗大量的UNDO空间,从而使整个系统瘫痪。资源管理程序通过UNDO_POOL指示来更清楚的方式控制大的事务。这让数据库管理员把用户划分成资源消耗的组,然后为每个组指派一个最大的UNDO空间限制。如果消耗UNDO空间合计超过该组的限定,这个组中的用户就不能再做更新操作直到其他事物结束使UNDO空间重新可用。UNDO_POOL默认值是UNLIMITED(不限制),用户可以消耗所有UNDO表空间的所有UNDO空间。数据库管理员还可以为具体用户设置UNDO_POOL限制指示。
在一个繁忙的DB中有可能对于一个长时间运行的事务由于其所在回滚段extent的过分扩展从而消耗几乎所有的undo表空间,这将可能导致ORA-1562错误的产生,为了防止此产生可以配置UNDO_POOL。
虽然不是初始化参数,但可以将 UNDO_POOL 数据库资源管理器计划指令设置为允许 sde 用户的用户组使用大量的撤消空间进行压缩操作。
要使用此功能,您需要建立 sde 用户的用户组,然后将 UNDO_POOL 计划指令更改为允许此用户组使用无限制撤消池。
UNDO_POOL 标识一个资源组的成员可以同时共同分配的撤消空间的总量。
总结:鉴于以上对在执行版本压缩过程中对UNDO表空间和UNDO_POOL的描述以及原理解释,我们在执行之前需要了解
1:该数据库是否将某个用户特别是sde用户添加资源组,如果添加查看相关的UNDO_POOL参数是否有设置,最后设置为无限制。
2:如果默认情况下,是不存在上面的问题,那么有必要创建一个新的大的UNDO表空间(根据用户States表和State_lineage表的数量),然后修改pfile文件,将UNDO表空间对应,然后进行版本压缩。
这种担心是多余的,在ArcSDE进行版本压缩时,相关的事务会存放到UNDO表空间中,如果出现异常问题,相关的事务是会进行回滚的,不会出现破坏数据的情况。从上面的描述可以看出,在我们进行版本压缩之前,有必要对我们数据库的UNDO表空间进行扩容。
那么简单看看UNDO表空间
Undo数据的作用:
1. 回退事务 通过rollback语句可以取消事务变化
2. 读一致性 Commit提交后。。
3. 事务恢复 例程恢复的一部分。
4. 倒叙查询 从过去的某个时间点查询。
undo表空间是唯一的一个表空间用来存放undo信息,不可以创建其他的对象在这个表空间中,如表,索引,只有当db是自动undo管理模式时才使用它(默认),一个db可以包括多个undo表空间,但同一时间只能用其中的一个, undo表空间使用undo段去管理数据,db会自动创建和维护这些段.
每个事务的第一个dml操作产生时,事务被指定了一个undo段(可以认为是一个事务表)在当前的undo表空间中,在极少数环境中,如果实例没有设计undo表空间,那事务将使用system undo段,每个undo表空间由一组本地管理的数据文件组成,就像其他的表空间,区由undo块组成,每个区的状态都在bitmap中体现了,在任何点上,一个区要不就分配给一个事务表,要不就是空闲的,可以创建bigfile类型的undo表空间。
上面提到的两个参数决定
UNDO_MANAGEMENT=auto
UNDO_TABLESPACE=undotbs
SQL> show parameter undo_tablespace;
NAME TYPE VALUE
------------------------------------ ----------- --------------------
undo_tablespace string UNDOTBS1
SQL> show parameter undo_management;
NAME TYPE VALUE
------------------------------------ ----------- --------------------
undo_management string AUTO
SQL>
在自动UNDO管理模式下,系统为UNDO段提供专门的处理事务任务和控制UNDO段空间的分配。一个异常的事务能消耗大量的UNDO空间,从而使整个系统瘫痪。资源管理程序通过UNDO_POOL指示来更清楚的方式控制大的事务。这让数据库管理员把用户划分成资源消耗的组,然后为每个组指派一个最大的UNDO空间限制。如果消耗UNDO空间合计超过该组的限定,这个组中的用户就不能再做更新操作直到其他事物结束使UNDO空间重新可用。UNDO_POOL默认值是UNLIMITED(不限制),用户可以消耗所有UNDO表空间的所有UNDO空间。数据库管理员还可以为具体用户设置UNDO_POOL限制指示。
在一个繁忙的DB中有可能对于一个长时间运行的事务由于其所在回滚段extent的过分扩展从而消耗几乎所有的undo表空间,这将可能导致ORA-1562错误的产生,为了防止此产生可以配置UNDO_POOL。
虽然不是初始化参数,但可以将 UNDO_POOL 数据库资源管理器计划指令设置为允许 sde 用户的用户组使用大量的撤消空间进行压缩操作。
要使用此功能,您需要建立 sde 用户的用户组,然后将 UNDO_POOL 计划指令更改为允许此用户组使用无限制撤消池。
UNDO_POOL 标识一个资源组的成员可以同时共同分配的撤消空间的总量。
编辑多版本化地理数据库时,必须定期执行压缩操作以清除旧信息并精简地理数据库中的内容。如果上次执行压缩操作后出现大量编辑内容,那么新的压缩过程将创建需要大量撤消空间的大型事务。如果 UNDO_POOL 设置得过低,压缩操作将失败,性能将变差。如果可能,为 sde 用户的用户组设置一个无限制撤消池。否则,必须监视压缩事务的大小,并对大型撤消池选择一个合适的大小。
执行上面可以参考:http://www.360doc.com/content/11/1218/07/7914128_173077618.shtml#
总结:鉴于以上对在执行版本压缩过程中对UNDO表空间和UNDO_POOL的描述以及原理解释,我们在执行之前需要了解
1:该数据库是否将某个用户特别是sde用户添加资源组,如果添加查看相关的UNDO_POOL参数是否有设置,最后设置为无限制。
2:如果默认情况下,是不存在上面的问题,那么有必要创建一个新的大的UNDO表空间(根据用户States表和State_lineage表的数量),然后修改pfile文件,将UNDO表空间对应,然后进行版本压缩。