这两台服务器用的都是联志的国产低端PC Server，这些服务器的质量实在是差，上次一台备机的硬盘损坏，然后又有一台因为电源模块的问题反复重起，现在这一台服务器的硬盘再次出现问题。

Nov 24 10:27:48 wapcom1 kernel: attempt to access beyond end of device
Nov 24 10:27:48 wapcom1 kernel: 08:08: rw=0, want=1564747716, limit=5245191
Nov 24 10:27:48 wapcom1 kernel: EXT3-fs error (device sd(8,8)): ext3_readdir:
 directory #128110 contains a hole at offset 2011258880
Nov 24 10:27:49 wapcom1 kernel: attempt to access beyond end of device
Nov 24 10:27:49 wapcom1 kernel: 08:08: rw=0, want=1564747716, limit=5245191
Nov 24 10:27:50 wapcom1 kernel: EXT3-fs error (device sd(8,8)): ext3_readdir:
 directory #128110 contains a hole at offset 2011262976
Nov 24 10:27:50 wapcom1 kernel: attempt to access beyond end of device
Nov 24 10:27:50 wapcom1 kernel: 08:08: rw=0, want=1564747716, limit=5245191
Nov 24 10:27:50 wapcom1 kernel: EXT3-fs error (device sd(8,8)): ext3_readdir:
 directory #128110 contains a hole at offset 2011267072
Nov 24 10:27:50 wapcom1 kernel: attempt to access beyond end of device
Nov 24 10:27:50 wapcom1 kernel: 08:08: rw=0, want=1564747716, limit=5245191
Nov 24 10:27:50 wapcom1 kernel: EXT3-fs error (device sd(8,8)): ext3_readdir:
 directory #128110 contains a hole at offset 2011271168

好在数据库通过DataGuard可以切换到另外一台，没有数据损失：

Thu Nov 23 18:46:18 2006
ARC0: Complete FAL archive (thread 1 sequence 6045 destination bmarksb)
ARC0: Begin FAL archive (thread 1 sequence 6047 destination bmarksb)
Creating archive destination LOG_ARCHIVE_DEST_2: 'bmarksb'
ARC0: Complete FAL archive (thread 1 sequence 6047 destination bmarksb)
ARC0: Begin FAL archive (thread 1 sequence 6048 destination bmarksb)
Creating archive destination LOG_ARCHIVE_DEST_2: 'bmarksb'
Thu Nov 23 18:46:18 2006
ARC1: Complete FAL archive (thread 1 sequence 6046 destination bmarksb)
ARC1: Begin FAL archive (thread 1 sequence 6049 destination bmarksb)
Creating archive destination LOG_ARCHIVE_DEST_2: 'bmarksb'
Thu Nov 23 18:46:18 2006
ARC0: Complete FAL archive (thread 1 sequence 6048 destination bmarksb)
Thu Nov 23 18:46:18 2006
ARC1: Complete FAL archive (thread 1 sequence 6049 destination bmarksb)

现在是主库所在的服务器出现问题:

SQL> select dbid,name,PROTECTION_MODE,DATABASE_ROLE,SWITCHOVER_STATUS from v$database;

      DBID NAME      PROTECTION_MODE      DATABASE_ROLE    SWITCHOVER_STATUS
---------- --------- -------------------- ---------------- ------------------
3520694939 BMARK     MAXIMUM PERFORMANCE  PRIMARY          SESSIONS ACTIVE

备库现在一切正常:

SQL> select dbid,name,PROTECTION_MODE,DATABASE_ROLE,SWITCHOVER_STATUS from v$database;

      DBID NAME      PROTECTION_MODE      DATABASE_ROLE    SWITCHOVER_STATUS
---------- --------- -------------------- ---------------- ------------------
3520694939 BMARK     MAXIMUM PERFORMANCE  PHYSICAL STANDBY SESSIONS ACTIVE

现在需要的是一点停机时间进行切换。

切换日志:

Fri Nov 24 11:30:43 2006
alter database commit to switchover to physical standby with session shutdown
Fri Nov 24 11:30:43 2006
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY
Fri Nov 24 11:30:43 2006
SMON: disabling tx recovery
Fri Nov 24 11:30:44 2006
Active process 26743 user 'oracle' program 'oracle@wapcom1.hawa.cn (CJQ0)'
Active process 9033 user 'oracle' program 'oracle@wapcom1.hawa.cn (TNS V1-V3)'
Active process 7655 user 'oracle' program 'oracle@wapcom1.hawa.cn (TNS V1-V3)'
...............
Active process 8944 user 'oracle' program 'oracle@wapcom1.hawa.cn (TNS V1-V3)'
Active process 29104 user 'oracle' program 'oracle@wapcom1.hawa.cn (TNS V1-V3)'
Active process 30750 user 'oracle' program 'oracle@wapcom1.hawa.cn (TNS V1-V3)'
Active process 9045 user 'oracle' program 'oracle@wapcom1.hawa.cn (TNS V1-V3)'
CLOSE: waiting for server sessions to complete.
Fri Nov 24 11:31:51 2006
CLOSE: all sessions shutdown successfully.
Fri Nov 24 11:32:09 2006
SMON: disabling cache recovery
Fri Nov 24 11:32:10 2006
Shutting down archive processes
Archiving is disabled
Fri Nov 24 11:32:10 2006
ARCH shutting down
Fri Nov 24 11:32:10 2006
ARCH shutting down
Fri Nov 24 11:32:10 2006
ARC0: Archival stopped
Fri Nov 24 11:32:10 2006
ARC1: Archival stopped
Fri Nov 24 11:32:10 2006
Thread 1 closed at log sequence 6076
Successful close of redo thread 1
Fri Nov 24 11:32:28 2006
ARCH: noswitch archival of thread 1, sequence 6076
ARCH: End-Of-Redo archival of thread 1 sequence 6076
ARCH: Evaluating archive log 3 thread 1 sequence 6076
ARCH: Beginning to archive log 3 thread 1 sequence 6076
Creating archive destination LOG_ARCHIVE_DEST_2: 'bmarksb'
Creating archive destination LOG_ARCHIVE_DEST_1: '/var/oradata/arch/1_6076.arc'
ARCH: Completed archiving log 3 thread 1 sequence 6076
ARCH: archiving is disabled due to current logfile archival
Clearing standby activation ID 3520937155 (0xd1dd3cc3)
The primary database controlfile was created using the
'MAXLOGFILES 5' clause.
The resulting standby controlfile will not have enough
available logfile entries to support an adequate number
of standby redo logfiles. Consider re-creating the
primary controlfile using 'MAXLOGFILES 8' (or larger).
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 10485760;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 10485760;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 10485760;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 10485760;
Archivelog for thread 1 sequence 6076 required for standby recovery
MRP0 started with pid=8
MRP0: Background Managed Standby Recovery process started
Media Recovery Log /var/oradata/arch/1_6076.arc
Identified end-of-REDO for thread 1 sequence 6076
Identified end-of-REDO for thread 1 sequence 6076
Media Recovery End-Of-Redo indicator encountered
Media Recovery Applied until change 194025715
MRP0: Media Recovery Complete: End-Of-REDO
Resetting standby activation ID 3520937155 (0xd1dd3cc3)
MRP0: Background Media Recovery process shutdown
Fri Nov 24 11:32:35 2006
Switchover: Complete - Database shutdown required
Completed: alter database commit to switchover to physical st
Fri Nov 24 11:32:53 2006
Shutting down instance: further logons disabled
Shutting down instance (immediate)
License high water mark = 140
Fri Nov 24 11:32:53 2006
ALTER DATABASE CLOSE NORMAL
ORA-1507 signalled during: ALTER DATABASE CLOSE NORMAL...
ARCH: Archiving is disabled
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
ARCH: Archiving is disabled
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Fri Nov 24 11:33:14 2006
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 2
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.6.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
shared_pool_size = 83886080
large_pool_size = 33554432
standby_archive_dest = /var/oradata/arch
fal_server = bmarksb
fal_client = bmark
log_archive_format = %t_%s.arc
...........
CJQ0 started with pid=8
Fri Nov 24 11:33:15 2006
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=9
ARC0: Archival started
ARC1 started with pid=10
Fri Nov 24 11:33:15 2006
ARCH: STARTING ARCH PROCESSES COMPLETE
Fri Nov 24 11:33:15 2006
ARC1: Archival started
Fri Nov 24 11:33:15 2006
ARC0: Thread not mounted
Fri Nov 24 11:33:15 2006
ARC1: Thread not mounted
Fri Nov 24 11:33:22 2006
alter database mount standby database
Fri Nov 24 11:33:26 2006
Successful mount of redo thread 1, with mount id 3559140162
Fri Nov 24 11:33:26 2006
Standby Database mounted.
Completed: alter database mount standby database
Fri Nov 24 11:33:29 2006
ALTER DATABASE RECOVER managed standby database disconnect
Attempt to start background Managed Standby Recovery process
MRP0 started with pid=12
MRP0: Background Managed Standby Recovery process started
Fri Nov 24 11:33:34 2006
Completed: ALTER DATABASE RECOVER managed standby database d
Fri Nov 24 11:33:34 2006
Media Recovery Waiting for thread 1 seq# 6077
Media Recovery Log /var/oradata/arch/1_6077.arc
Media Recovery Waiting for thread 1 seq# 6078
Media Recovery Log /var/oradata/arch/1_6078.arc
Media Recovery Waiting for thread 1 seq# 6079

看来以后不能再采购联志服务器了。

-The End-

其本上采用了目前公司采用的所有技术，是一个全面的测试环境，这个环境帮我解决了一系列的Veritas技术问题。

这是一套HA的高可用性架构，把系统的结构截取了一下:

留念，这个环境要毁掉重做了。

bash-2.05# hastatus -summary

-- SYSTEM STATE
-- System State Frozen

A db210-1 RUNNING 0
A db210-2 RUNNING 0

-- GROUP STATE
-- Group System Probed AutoDisabled State

B ClusterService db210-1 Y N ONLINE
B ClusterService db210-2 Y N OFFLINE
B O10g db210-1 Y N ONLINE
B O10g db210-2 Y N OFFLINE

-The End-

ARCHIVE_LAG_TARGET参数可以设置一个时间，通过时间限制，指定数据库强制进行Log Switch，进行归档。

这个参数的缺省值是0，即为不启用该参数。该参数合理的取值范围在60 ~ 7200之间。
通常大于7200和小于1800不被推荐，低于30分钟的切换时间可能导致性能问题。

以下是我的一个生产环境的设置效果。
设置之前:

SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

SQL> col name for a60
SQL> select name,COMPLETION_TIME from v$archived_log where name is not null;

NAME COMPLETION_TIME
------------------------------------------------------------ -------------------
/data2/oradata/STAT/archive/1_5441_593258512.dbf 2006-11-20 10:49:57
/data2/oradata/STAT/archive/1_5442_593258512.dbf 2006-11-20 15:49:50

由于数据库并不繁忙，日志很久才会切换一次。

设置archive_lag_target参数:

SQL> show parameter archive_lag

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 0
SQL> alter system set archive_lag_target=1800;

System altered.

SQL> show parameter archive_lag

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 1800

此时可以看到日志切换时间发生改变:

[oracle@STAT ~]$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.2.0 - Production on Mon Nov 20 21:31:31 2006

Copyright (c) 1982, 2005, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining Scoring Engine options

SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /data2/oradata/STAT/archive
Oldest online log sequence 5449
Next log sequence to archive 5451
Current log sequence 5451
SQL> !
[oracle@STAT ~]$ ll /data2/oradata/STAT/archive
total 125776
-rw-r----- 1 oracle oinstall 43030016 Nov 20 10:49 1_5441_593258512.dbf
-rw-r----- 1 oracle oinstall 43122688 Nov 20 15:49 1_5442_593258512.dbf
-rw-r----- 1 oracle oinstall 14172672 Nov 20 17:31 1_5443_593258512.dbf
-rw-r----- 1 oracle oinstall 3620864 Nov 20 18:02 1_5444_593258512.dbf
-rw-r----- 1 oracle oinstall 3511296 Nov 20 18:32 1_5445_593258512.dbf
-rw-r----- 1 oracle oinstall 3626496 Nov 20 19:02 1_5446_593258512.dbf
-rw-r----- 1 oracle oinstall 4903936 Nov 20 19:32 1_5447_593258512.dbf
-rw-r----- 1 oracle oinstall 3521536 Nov 20 20:02 1_5448_593258512.dbf
-rw-r----- 1 oracle oinstall 5144576 Nov 20 20:32 1_5449_593258512.dbf
-rw-r----- 1 oracle oinstall 3916800 Nov 20 21:02 1_5450_593258512.dbf

这个参数在DataGuard/Standby环境中是非常有效的。

-The End-

测试了简单的表复制，结论是没有问题。
高级复制的详细过程可以参考我以前的文章:
http://www.eygle.com/archives/2005/06/oraclessoeaeaeo.html

测试的简单过程如下(略去了一些基本步骤).
首先测试两个数据库的连通性:

$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Oct 31 10:36:31 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> show parameter glob

NAME TYPE VALUE
------------------------------------ ----------- ---------------------
global_context_pool_size string
global_names boolean TRUE
SQL> select * from global_name;

GLOBAL_NAME
----------------------------------------------------------------------
HSBILL.HURRAY.COM.CN

SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

bash-2.03$ tnsping mars

TNS Ping Utility for Solaris: Version 9.2.0.4.0 - Production on 31-OCT-2006 10:39:41

Copyright (c) 1997 Oracle Corporation. All rights reserved.

Used parameter files:
/opt/oracle/product/9.2.0/network/admin/sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.31.110)(PORT = 1521))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = mars)))
OK (10 msec)

两个数据库分别创建db link:
9i的数据库:

bash-2.03$ sqlplus repadmin/repadmin

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Oct 31 10:57:49 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> create public database link "MARS.HURRAY.COM.CN" connect to repadmin identified by repadmin using 'MARS';

Database link created.

SQL> select * from dual@mars;

D
-
X

10g的数据库:

bash-2.03$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Tue Oct 31 10:15:20 2006

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> select username from dba_users where username='REPADMIN';

USERNAME
------------------------------
REPADMIN

SQL> connect repadmin/repadmin
Connected.
SQL> select * from tab;

no rows selected

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
MARS.HURRAY.COM.CN

SQL> create public database link "HSBILL.HURRAY.COM.CN" connect to repadmin identified by repadmin using 'HSBILL';

Database link created.

SQL> select * from dual@hsbill;

D
-
X

两个数据库分别创建测试表：

SQL> connect eygle/eygle
Connected.

SQL> create table eygle as select * from v$session;

Table created.

SQL> alter table eygle add (constraint pk_eygle primary key (SADDR));

Table altered.

进行复制创建:

SQL> connect repadmin/repadmin
Connected.

SQL> execute dbms_repcat.create_master_repgroup('rep_910');

PL/SQL procedure successfully completed.

SQL> execute dbms_repcat.create_master_repobject(sname=>'eygle',oname=>'eygle', type=>'table',use_existing_object=>true,gname=>'rep_910',copy_rows=>false);

PL/SQL procedure successfully completed.

SQL> execute dbms_repcat.generate_replication_support('eygle','eygle','table');

PL/SQL procedure successfully completed.

SQL> execute dbms_repcat.add_master_database(gname=>'rep_910',master=>'MARS.HURRAY.COM.CN',use_existing_objects=>true, copy_rows=>false, propagation_mode => 'synchronous');

PL/SQL procedure successfully completed.

SQL> execute dbms_repcat.resume_master_activity('rep_910',true);

PL/SQL procedure successfully completed.

基本测试:

SQL> select count(*) from eygle.eygle;

COUNT(*)
----------
20

SQL> select count(*) from eygle.eygle@mars;

COUNT(*)
----------
20

SQL> delete from eygle.eygle where rownum <11;

10 rows deleted.

SQL> commit;

Commit complete.

SQL> select count(*) from eygle.eygle;

COUNT(*)
----------
10

SQL> select count(*) from eygle.eygle@mars;

COUNT(*)
----------
10

SQL> select * from v$version@mars;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for Solaris: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Solaris: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production

SQL>

本例未作全面测试，仅用于说明Oracle9iR2和Oracle10gR2之间的高级复制功能上可行。

-The End-

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

SQL> set linesize 120
SQL> col segment_name for a30
SQL> col segment_type for a20
SQL> col tablespace_name for a20
SQL> select segment_name,segment_type,tablespace_name,bytes/1024 
  2  from dba_segments where segment_name like '%DEF$_%';

SEGMENT_NAME                   SEGMENT_TYPE         TABLESPACE_NAME      BYTES/1024
------------------------------ -------------------- -------------------- ----------
DEF$_AQCALL                    TABLE                SYSTEM                       64
DEF$_AQERROR                   TABLE                SYSTEM                       64
DEF$_TRANORDER                 INDEX                SYSTEM                       64
DEF$_ERROR_PRIMARY             INDEX                SYSTEM                       64
DEF$_ERROR                     TABLE                SYSTEM                       64
DEF$_DESTINATION               TABLE                SYSTEM                       64
DEF$_DESTINATION_PRIMARY       INDEX                SYSTEM                       64
DEF$_CALLDEST                  TABLE                SYSTEM                       64
DEF$_CALLDEST_PRIMARY          INDEX                SYSTEM                       64
DEF$_CALLDEST_N2               INDEX                SYSTEM                       64
DEF$_DEFAULTDEST               TABLE                SYSTEM                       64

SEGMENT_NAME                   SEGMENT_TYPE         TABLESPACE_NAME      BYTES/1024
------------------------------ -------------------- -------------------- ----------
DEF$_DEFAULTDEST_PRIMARY       INDEX                SYSTEM                       64
DEF$_LOB                       TABLE                SYSTEM                       64
DEF$_LOB_PRIMARY               INDEX                SYSTEM                       64
DEF$_LOB_N1                    INDEX                SYSTEM                       64
DEF$_TEMP$LOB                  TABLE                SYSTEM                       64
DEF$_PROPAGATOR                TABLE                SYSTEM                       64
DEF$_PROPAGATOR_PRIMARY        INDEX                SYSTEM                       64
DEF$_ORIGIN                    TABLE                SYSTEM                       64
DEF$_PUSHED_TRANSACTIONS       TABLE                SYSTEM                       64
DEF$_PUSHED_TRAN_PRIMARY       INDEX                SYSTEM                       64

21 rows selected.

在这种情况下，删除复制组将成为一个困难。
我们的尝试很容易以以下错误告终。

$ sqlplus repadmin/repadmin

SQL*Plus: Release 10.1.0.2.0 - Production on Tue Sep 19 16:54:10 2006

Copyright (c) 1982, 2004, Oracle. All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> select gname, status from dba_repgroup;

GNAME STATUS
------------------------------ ---------
REP_TT QUIESCED

SQL> EXEC dbms_repcat.drop_master_repgroup(gname => 'REP_TT',
2 drop_contents => false,all_sites => false);
BEGIN dbms_repcat.drop_master_repgroup(gname => 'REP_TT',
drop_contents => false,all_sites => false); END;

*
ERROR at line 1:
ORA-23313: object group "PUBLIC"."REP_TT" is not mastered at
EYGLE.HURRAY.COM.CN
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 105
ORA-06512: at "SYS.DBMS_REPCAT_UTL4", line 2860
ORA-06512: at "SYS.DBMS_REPCAT_MAS", line 2660
ORA-06512: at "SYS.DBMS_REPCAT", line 635
ORA-06512: at line 1

我们可以查看一下dba_repgroup依赖的底层基本对象:

SQL> set autotrace on explain
SQL> select gname,status,owner from dba_repgroup;

GNAME STATUS OWNER
------------------------------ --------- ------------------------------
REP_TT QUIESCED PUBLIC

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=2 Bytes=82)
1 0 NESTED LOOPS (OUTER) (Cost=2 Card=2 Bytes=82)
2 1 TABLE ACCESS (FULL) OF 'REPCAT$_REPCAT' (TABLE) (Cost=2
Card=2 Bytes=44)

3 1 INDEX (UNIQUE SCAN) OF 'REPCAT$_FLAVORS_UNQ1' (INDEX (UN
IQUE)) (Cost=0 Card=1 Bytes=19)

如果对系统状况足够了解和确认，我们可以直接从底层表'REPCAT$_REPCAT' 中删除这个复制组的信息:

SQL> delete from system.REPCAT$_REPCAT;

1 row deleted.

SQL> commit;

Commit complete.

SQL> select gname,status,owner from dba_repgroup;

no rows selected

在进行这些操作之前，请做好备份，并做好确认。

这个故事告诉我们的是，做事情一定要遵循正确的步骤，即使失败了，也应该按照正常的步骤退回原点，否则留下的各类不完全操作可能为数据库留下种种隐患。

-The End-

$ sqlplus repadmin/repadmin

SQL*Plus: Release 10.1.0.2.0 - Production on Tue Sep 19 10:34:30 2006

Copyright (c) 1982, 2004, Oracle. All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> set linesize 120
SQL> col sname for a10
SQL> col gname for a10
SQL> col schema_comment for a1
SQL> col fname for a10
SQL> col owner for a10
SQL> select * from dba_repgroup;

SNAME M STATUS S GNAME FNAME R OWNER
---------- - --------- - ---------- ---------- - ----------
REP_TEST Y NORMAL REP_TEST N PUBLIC

SQL> exec dbms_repcat.drop_master_repgroup(gname=>'rep_test',all_sites => true);
BEGIN dbms_repcat.drop_master_repgroup(gname=>'rep_test',all_sites => true); END;

*
ERROR at line 1:
ORA-23353: deferred RPC queue has entries for object group "PUBLIC"."REP_TEST"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.DBMS_REPCAT_MAS", line 1190
ORA-06512: at "SYS.DBMS_REPCAT_MAS", line 2666
ORA-06512: at "SYS.DBMS_REPCAT", line 635
ORA-06512: at line 1

这表明此时，在deftran中还有记录，而可能在deftrandest中已经没有需要push的事务

SQL> select count(*) from deftran;

COUNT(*)
----------
3

SQL> select count(*) from deftrandest;

COUNT(*)
----------
0

正常情况下可以通过dbms_defer_sys.purge过程去清除队列。
在异常情况下，我们可以选择直接截断(truncate)，强制删除复制组:

SQL> truncate table system.def$_aqcall;

Table truncated.

SQL> exec dbms_repcat.drop_master_repgroup(gname=>'rep_test',all_sites => true);

PL/SQL procedure successfully completed.

-The End-

上周一个客户的高级复制环境出现问题，两边的复制组状态异常，一个主体站点的复制组处于QUIESCING状态，无法执行DML操作。

经过检查发现用户的队列表空间占用极大：

SQL> select segment_name,SEGMENT_TYPE,bytes/1024/1024,tablespace_name
  2  from dba_segments where bytes/1024/1024 > 500;

SEGMENT_NAME                  SEGMENT_TYPE      BYTES/1024/1024 TABLESPACE_NAME
----------------------------- ------------------ --------------- ---------------
I_WRI$_OPTSTAT_IND_OBJ#_ST    INDEX                          699 SYSAUX
WRI$_OPTSTAT_IND_HISTORY      TABLE                          513 SYSAUX
SYS_LOB0000004603C00003$$    LOBSEGMENT                  63637 SYSTEM
SYS_LOB0000004603C00004$$    LOBSEGMENT                    1540 SYSTEM
DEF$_LOB                      TABLE                        4330 SYSTEM
DEF$_AQCALL                  TABLE                        3762 SYSTEM
SYS_LOB0000058045C00106$$    LOBSEGMENT                  15133 USERS
SYS_LOB0000058012C00025$$    LOBSEGMENT                    4394 USERS

8 rows selected.

而且一些大对象占用了系统表空间大量的空间。
最重要的队列表DEF$_AQCALL已经扩展到了3762M大小，这显然为管理和维护带来了麻烦，而且在Oracle10gR1中，高级复制的对象仍然位于SYSTEM表空间，这是一个极大的问题，实际上在创建之初我们就应该将这些对象分离到SYSAUX表空间或其它独立的表空间，减少对于系统表空间的冲击。

这些问题加上用户的一些不当操作，最终导致了数据库故障。
而且这个环境相当复杂，Oracle10gR1 + Crs + ASM 的2套RAC环境间的高级复制，处理过程着实花了一番功夫。

最后体会深刻的是，不管哪一项技术，前期的规划都极其重要，如果规划不当，后期的问题将会曾出不穷。

-The End-

如果有时间，就把遇到的一些问题整理出来，不过遇到了实在太多的问题。

在重建高级复制的队列表时曾经出过这样一个错误:

SQL> delete from eygle.test;
delete from eygle.test
*
ERROR at line 1:
ORA-25207: enqueue failed, queue SYSTEM.DEF$_AQCALL is disabled from enqueueing

这个错误通常是因为某些异常而导致了队列停顿，一般不建议手工处理复制字典表，解决这个错误很简单，启动队列即可：

SQL> exec dbms_aqadm.start_queue('SYSTEM.DEF$_AQCALL',true,true);

PL/SQL procedure successfully completed.

此时数据库可以恢复正常，复制对象可以正常操作：

SQL> delete from eygle.test;

20 rows deleted.

SQL> commit;

Commit complete.

如果队列不能正常启动，则可能需要重建，会麻烦许多。

-The End-

1. truncate分区以后，物化视图快速刷新出错
2. drop分区以后，物化视图快速刷新出错

测试Oralce9i的情况:

SQL> create table T_PART
  2  (
  3    C1 NUMBER,
  4    C2 NUMBER,
  5    C3 NUMBER
  6  )
  7  partition by range (C2)
  8  (
  9    partition T_P2 values less than (20)
 10  ,
 11    partition T_P3 values less than (30)
 12  )
 13  ;

Table created.
SQL> insert into t_part values(1,2,3);

1 row created.

SQL> insert into t_part values(1,25,3);

1 row created.

SQL> insert into t_part values(1,18,3);

1 row created.

SQL> commit;

Commit complete.

SQL> create materialized view log on t_part with rowid;

Materialized view log created.

SQL> create materialized view mv_t_part refresh with rowid as select * from t_part;

Materialized view created.

SQL> select * from t_part;

        C1         C2         C3
---------- ---------- ----------
         1          2          3
         1         18          3
         1         25          3

SQL> select * from mv_t_part;

        C1         C2         C3
---------- ---------- ----------
         1          2          3
         1         18          3
         1         25          3

SQL> alter table t_part truncate partition t_p2;

Table truncated.

SQL> exec dbms_mview.refresh('mv_t_part','f');
BEGIN dbms_mview.refresh('mv_t_part','f'); END;

*
ERROR at line 1:
ORA-32313: REFRESH FAST of "SYS"."MV_T_PART" unsupported after PMOPs
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 794
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 851
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 832
ORA-06512: at line 1

这里出现错误。

ORA-32313 REFRESH FAST of "string"."string" unsupported after PMOPs