今天在Itpub看到一个讨论大表的truncate与drop操作的帖子, 下面是我对其的回复.

1. drop 与 Truncate操作类似的地方.
drop 是直接处理数据字典,去掉object与其对应的data_object_id的对应关系..
truncate 操作是创建一个新的空的segment(对应于data object id), 并将此segment与现有对象关联起来.

2. drop 与 truncate 操作都会触发object checkpoint操作, 如果buffer Cache很大的话, 这两个操作都可能会出现较长时间的等待, 在Oracle 10gR2以后, Oracle对Buffer header做了些许变更, 以提高Fast Object Checkpoint的速度.

comment #9 By Jonathan Lewis

Re: KO - I think that appeared in 10.2. There is a new entry in the buffer header structure which allows for a linked list to be built between buffer headers of the same object. This, of course, means yet another little overhead when reading a block into the buffer in the first place. But it is useful for truncates, drops, and shrinks, as it avoids a massive scanning process if you drop a large object which has not been subject to much update.

3. 对于drop 与 Truncate 操作还涉及另外一块事情: 空间的回收.
对于使用Local Management的tablespace ,需要修改这个segment 涉及到的所有数据文件的bitmap 内容的修改.. 一般情况下, 速度都还可以..

如果是基于字典管理的表空间.. 由于所有的回收操作都是基于uet$,fet$表操作的,,所有如果使用的空间量非常大, 回收的操作将非常慢,,我层听说,,有人删除一个表要等待好几个小时甚至1-2天的情况..

解决办法是:

truncate table xxx reuse storage;
alter table xxx deallocate unused keep 2000m;
alter table xxx deallocate unused keep 1500m;
alter table xxx deallocate unused keep 1000m;
alter table xxx deallocate unused keep 500m;

因为, 在数据字典管理的表空间中,所有涉及到空间管理的操作,都需要持有一个ST lock,如果单个操作执行的时间过长, 可能导致整个系统的空间分配操作都无法继续, 这对于绝大部分的OLTP应用,应该都是不可接受的事情..

ST Enqueue - This type of enqueue is used for space management and allocation for dictionary-managed tablespaces

附注:
1. 涉及到fast object checkpoint的相关操作.

这一点包含普通的direct path read, 以及在Oracle 11g中引入的Adaptive Direct path read.

2. alter table exchange partition 操作涉及的主要也是object_id 与 data_object_id之间对应关系的切换, 这也是为什么这个操作效率为什么那么快的原因.

No related posts.

今天在Uwe Hesse的Blog上看到这篇文章,感觉很不错,简要地描述Oracle MAA架构的所有相关产品,虽然之前就有接触所有这些解决方案,但解释的如此清楚明了的还是第一次看到,特将其翻译如下. 原文: Oracle Database HA Architecture

Oracle高可用架构
作者: Uwe Hesse, 译者: Jametong
Oracle高可用架构是我所讲课程里的一个热门话题.本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC以及扩展RAC(有时也被称为”伸展集群”).Rac与Dataguard组合在一起就是Oracle公司推广的最大可用性架构(Maximum Availability Architecture,MAA).除这些Oracle的HA解决方案外,我还会简单介绍一个第三方的HA解决方案(远程镜像,Remote Mirroring).我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷.
首先,我们将考察目前为止仍然是应用最为广泛的Oracle数据库架构:单实例数据库.一个Oracle数据库总是由一个数据库(由数据文件,在线重做日志控制文件组成)与一个实例(有内存结构,比如数据库高速缓冲区;以及后台进程,例如数据库写进程)组成.如果我们有一个数据库以及多个访问这个数据库的实例,这就是一个RAC.如果只有一个实例访问这个数据库,就是单实例数据库.下图是一个所有组件都存储在一个服务器上的简单安装版本:

将数据库文件放置在SAN(存储区域网络)的配置也是目前比较常见的配置,如下图所示:

从高可用的角度来看,这个架构是非常脆弱的:服务器A与服务器B都是单点故障,数据库A与数据库B也都是单点故障.从而这些服务器所在的站点也是单点故障.这样,只要其中一个单点发生故障,整个数据库将不可用.一个”普通的”RAC就是为了解决其中的服务器单点故障的,如下图所示:

如果两个服务器的其中一个发生故障,数据库C将仍然可用.当然,使用RAC并不仅仅是为了实现HA.在使用RAC的其它的理由中,一个比较可靠的理由是为了实现伸缩性(Scalability):如果应用需求在将来出现增长,我们可以通过添加新的节点(Node)到集群中来解决.另外,通过使用RAC我们还可以选择使用服务管理(Service-Management)与负载均衡(Load Balance).简言之,RAC不仅仅是HA,在此详述其它原因已经超出本文的范畴了.从HA的视角看,使用RAC的缺陷是:数据库C以及相应的站点C是单点.如果站点C发生故障(比如火灾),数据库C将不可用.因此,将数据库伸展到两个站点就成为我们的选择了,这也是通常所说的扩展RAC.

现在,这两个站点就不再是单点了.数据库D是在两个站点之间做镜像的.这个架构的缺陷是两个站点之间的网络连接的成本,如果两个站点之间的距离比较远的话.这很关键,因为需要镜像的数据量会非常大.实际上,这使得两个站点之间的距离局限于几公里以内,而这与想要实现的灾难保护目标之间有冲突.这时,Dataguard就隆重登场了:利用DataGuard,我们很容易就可以实现长距离的灾难保护,因为,此时我们不再需要传输所有的数据量,而仅仅需要传输(相对小)的重做日志.在下图中,每个服务器都像上面的服务器A与服务器B一样,只有一个实例:

备用数据库由来自主数据库的重做日志. 当主库发生故障时,我们可以失败切换(Failover)到备库上并继续有效工作.这个失败切换工作可以由一个Observer(观察员程序,通常称为快速启动失败切换,Fast-Start Failover)自动实现.两个站点之间的距离达到几千公里(依赖于重做日志的传输策略与保护级别(protection level)).如果我们将RAC与Dataguard集合起来,我们就实现了MAA.显然,MAA是一个昂贵的解决方案,不过它也同时享有RAC与Dataguard的所有好处.
远程镜像是一个广受欢迎的第三方HA解决方案.总体上,它的架构与下图类似:

这时,也没有哪个站点是单点的,类似于使用扩展RAC架构.这个解决方案的缺陷是:站点间的距离也是严格受限制的,理由与扩展RAC架构类似.同时,在镜像进行的时候,第二个站点是无法提供服务的,这一点与上述的Oracle提供的HA解决方案不同.使用RAC时,所有的服务器与相应的站点都可以提供服务.哪怕是使用Dataguard,备用数据库也不仅仅是等待主库发生故障.除此之外,它还可以提供只读访问服务,这将可以有效降低主库的负载.

上图展示了Oracle 11g的新特性”物理备用数据库上的实时查询”.在恢复过程中时,备用数据库也在同时提供只读访问.另外,还可以在物理备库(Physical Standby)上做离线备份(OffLoad Backup).

附注:
其实还有另外一种可选择的架构. 基于Data Guard与单实例的一个结合.
类似于上面介绍的远程Data Guard方案, 做了一点修正: 将当前主库的一组Redo 日志放到远程(当然也受限于距离所产生的San 访问延时).

今天在Uwe Hesse的Blog上看到这篇文章,感觉很不错,简要地描述Oracle MAA架构的所有相关产品,虽然之前就有接触所有这些解决方案,但解释的如此清楚明了的还是第一次看到,特将其翻译如下. 原文: Oracle Database HA Architecture

Oracle高可用架构
作者: Uwe Hesse, 译者: Jametong
Oracle高可用架构是我所讲课程里的一个热门话题.本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC以及扩展RAC(有时也被称为”伸展集群”).Rac与Dataguard组合在一起就是Oracle公司推广的最大可用性架构(Maximum Availability Architecture,MAA).除这些Oracle的HA解决方案外,我还会简单介绍一个第三方的HA解决方案(远程镜像,Remote Mirroring).我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷.
首先,我们将考察目前为止仍然是应用最为广泛的Oracle数据库架构:单实例数据库.一个Oracle数据库总是由一个数据库(由数据文件,在线重做日志控制文件组成)与一个实例(有内存结构,比如数据库高速缓冲区;以及后台进程,例如数据库写进程)组成.如果我们有一个数据库以及多个访问这个数据库的实例,这就是一个RAC.如果只有一个实例访问这个数据库,就是单实例数据库.下图是一个所有组件都存储在一个服务器上的简单安装版本:

将数据库文件放置在SAN(存储区域网络)的配置也是目前比较常见的配置,如下图所示:

从高可用的角度来看,这个架构是非常脆弱的:服务器A与服务器B都是单点故障,数据库A与数据库B也都是单点故障.从而这些服务器所在的站点也是单点故障.这样,只要其中一个单点发生故障,整个数据库将不可用.一个”普通的”RAC就是为了解决其中的服务器单点故障的,如下图所示:

如果两个服务器的其中一个发生故障,数据库C将仍然可用.当然,使用RAC并不仅仅是为了实现HA.在使用RAC的其它的理由中,一个比较可靠的理由是为了实现伸缩性(Scalability):如果应用需求在将来出现增长,我们可以通过添加新的节点(Node)到集群中来解决.另外,通过使用RAC我们还可以选择使用服务管理(Service-Management)与负载均衡(Load Balance).简言之,RAC不仅仅是HA,在此详述其它原因已经超出本文的范畴了.从HA的视角看,使用RAC的缺陷是:数据库C以及相应的站点C是单点.如果站点C发生故障(比如火灾),数据库C将不可用.因此,将数据库伸展到两个站点就成为我们的选择了,这也是通常所说的扩展RAC.

现在,这两个站点就不再是单点了.数据库D是在两个站点之间做镜像的.这个架构的缺陷是两个站点之间的网络连接的成本,如果两个站点之间的距离比较远的话.这很关键,因为需要镜像的数据量会非常大.实际上,这使得两个站点之间的距离局限于几公里以内,而这与想要实现的灾难保护目标之间有冲突.这时,Dataguard就隆重登场了:利用DataGuard,我们很容易就可以实现长距离的灾难保护,因为,此时我们不再需要传输所有的数据量,而仅仅需要传输(相对小)的重做日志.在下图中,每个服务器都像上面的服务器A与服务器B一样,只有一个实例:

备用数据库由来自主数据库的重做日志. 当主库发生故障时,我们可以失败切换(Failover)到备库上并继续有效工作.这个失败切换工作可以由一个Observer(观察员程序,通常称为快速启动失败切换,Fast-Start Failover)自动实现.两个站点之间的距离达到几千公里(依赖于重做日志的传输策略与保护级别(protection level)).如果我们将RAC与Dataguard集合起来,我们就实现了MAA.显然,MAA是一个昂贵的解决方案,不过它也同时享有RAC与Dataguard的所有好处.
远程镜像是一个广受欢迎的第三方HA解决方案.总体上,它的架构与下图类似:

这时,也没有哪个站点是单点的,类似于使用扩展RAC架构.这个解决方案的缺陷是:站点间的距离也是严格受限制的,理由与扩展RAC架构类似.同时,在镜像进行的时候,第二个站点是无法提供服务的,这一点与上述的Oracle提供的HA解决方案不同.使用RAC时,所有的服务器与相应的站点都可以提供服务.哪怕是使用Dataguard,备用数据库也不仅仅是等待主库发生故障.除此之外,它还可以提供只读访问服务,这将可以有效降低主库的负载.

上图展示了Oracle 11g的新特性”物理备用数据库上的实时查询”.在恢复过程中时,备用数据库也在同时提供只读访问.另外,还可以在物理备库(Physical Standby)上做离线备份(OffLoad Backup).

附注:
其实还有另外一种可选择的架构. 基于Data Guard与单实例的一个结合.
类似于上面介绍的远程Data Guard方案, 做了一点修正: 将当前主库的一组Redo 日志放到远程(当然也受限于距离所产生的San 访问延时).

No related posts.

在一个测试环境进行统计信息收集，结果提示被锁定：

SQL> exec dbms_stats.gather_table_stats('erp','balance');
BEGIN dbms_stats.gather_table_stats('cnderp','balance'); END;

*
ERROR at line 1:
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: at "SYS.DBMS_STATS", line 13056
ORA-06512: at "SYS.DBMS_STATS", line 13076
ORA-06512: at line 1
Elapsed: 00:00:00.87

可以用以下命令解除锁定：

SQL> exec dbms_stats.unlock_table_stats('erp','balance');

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.47
SQL> exec dbms_stats.gather_table_stats('erp','balance');

PL/SQL procedure successfully completed.

Elapsed: 00:04:37.31

解除都整个schema对象的锁定

SQL> EXEC DBMS_STATS.unlock_schema_stats(ownname => 'erp');

PL/SQL procedure successfully completed.

统计信息被锁定的原因有多种：

Symptoms
---------
Either of the following two error messages are signaled:
1. ORA-38029: object statistics are locked
2. ORA-20005: object statistics are locked (stattype = ALL)

Cause
---------
Possible Cause 1:
DBMS_STATS.LOCK_[SCHEMA|TABLE]_STATS has been used to lock statistics on the table.

Possible Cause 2:
Using import (imp) or data pump import (impdp) to import a table without data results in the table's statistics being locked in 10gR2.

Possible Cause 3:
After an IMPORT is finished for which ROWS=N, the statistics for all tables imported will be locked.
Part Number B14233-04 Database Readme 10g Release 2 (10.2) (39.5 Original Export/Import)

Possible Cause 4: If the table is a queue table then the statistics are intended to be empty and locked so that dynamic sampling will be used due to the table's volatility. During an upgrade to 10gR2 statistics on queue tables are deleted and then locked. In 10gR2 when a queue table is created statistics are locked while still empty.

Solution
---------
If the table is a queue table then the statistics should remain empty and locked so that dynamic sampling is used due to the volatility of queue tables. If the table is not a queue table, unlock the statistics using DBMS_STATS.UNLOCK_[SCHEMA|TABLE]_STATS or gather statistics on the table using DBMS_STATS.GATHER_[SCHEMA|TABLE|INDEX]_STATS and the force=>true parameter.

To prevent import (imp) from locking the table's statistics when importing a table without therows (rows=n), use statistics=none. To prevent data pump import (impdp) from locking the table's statistics when importing a table without the rows (content=metadata_only), use exclude=(table_statistics,index_statistics).

我这里统计信息被锁定的原因就是在imp数据的时候没有导入约束，然后通过imp加rows=n参数又导入了约束信息后导致的。

但是奇怪的事情是，在完成了统计信息收集后，通过autotrace查看sql语句的统计信息时，统计信息显示的都是0：

SQL> connect sys/sys as sysdba
Connected.
SQL>
SQL> shutdown immediate
SQL> startup
ORACLE instance started.
Database opened.
SQL> connect erp/erp
Connected.

SQL> set timing on
SQL> set autotrace on statistics
SQL> select count(*) from balance;

COUNT(*)
----------
19548622

Elapsed: 00:00:01.31

Statistics
----------------------------------------------------------
0  recursive calls
0  db block gets
0  consistent gets
0  physical reads
0  redo size
0  bytes sent via SQL*Net to client
0  bytes received via SQL*Net from client
0  SQL*Net roundtrips to/from client
0  sorts (memory)
0  sorts (disk)
1  rows processed

尝试了很多种办法也没用：

SQL> drop table plan_table
2  /

Table dropped.

Elapsed: 00:00:02.83
SQL> @?/rdbms/admin/utlxplan.sql

Table created.

Elapsed: 00:00:00.26

SQL> analyze table balance estimate statistics;

Table analyzed.

开来这个问题有待进一步研究。