以下是小编精心整理的Oracle诊断案例Spfile案例一则数据库教程(共含5篇），希望对大家有所帮助。同时，但愿您也能像本文投稿人“我是女的”一样，积极向本站投稿分享好文章。
oracle
Oracle诊断案例-Spfile案例一则
link:
www.eygle.com/case/spfile.htm
情况说明:
系统：SUN Solaris8
数据库版本:9203
问题描述：工程人员报告，数据库在重新启动时无法正常启动.检查发现UNDO表空间丢失.
问题诊断及解决过程如下:
1. 登陆系统检查alert.log文件
检查alert.log文件是通常是我们诊断数据库问题的第一步
SunOS 5.8
login: root
Password:
Last login: Thu Apr 1 11:39:16 from 10.123.7.162
Sun Microsystems Inc. SunOS 5.8 Generic Patch October
You have new mail.
# su - oracle
bash-2.03$ cd $ORACLE_BASE/admin/*/bdump
bash-2.03$ vi *.log
“alert_gzhs.log” 7438 lines, 283262 characters
Sat Feb 7 20:30:06
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 3
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.3.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
shared_pool_size = 1157627904
large_pool_size = 16777216
java_pool_size = 637534208
control_files = /u01/oradata/gzhs/control01.ctl,
/u02/oradata/gzhs/control02.ctl,
/u03/oradata/gzhs/control03.ctl
db_block_size = 8192
db_cache_size = 2516582400
compatible = 9.2.0.0.0
log_archive_start = TRUE
log_archive_dest_1 = LOCATION=/u06/oradata/gzhs/arch
log_archive_format = %t_%s.dbf
db_file_multiblock_read_count= 16
fast_start_mttr_target = 300
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = gzhs
dispatchers = (PROTOCOL=TCP) (SERVICE=gzhsXDB)
job_queue_processes = 10
hash_join_enabled = TRUE
background_dump_dest = /oracle/admin/gzhs/bdump
user_dump_dest = /oracle/admin/gzhs/udump
core_dump_dest = /oracle/admin/gzhs/cdump
sort_area_size = 524288
db_name = gzhs
open_cursors = 300
star_transformation_enabled= FALSE
query_rewrite_enabled = FALSE
pga_aggregate_target = 838860800
aq_tm_processes = 1
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
“alert_gzhs.log” 7438 lines, 283262 characters
USER: terminating instance due to error 30012
Instance terminated by USER, pid = 26433
ORA-1092 signalled during: ALTER DATABASE OPEN...
Thu Apr 1 11:11:08 2004
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 3
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.3.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
shared_pool_size = 1157627904
large_pool_size = 16777216
java_pool_size = 637534208
control_files = /u01/oradata/gzhs/control01.ctl, /u02/oradata/gzhs/control02.ctl, /u03/oradata/gzhs/control03.ctl
db_block_size = 8192
db_cache_size = 2516582400
compatible = 9.2.0.0.0
log_archive_start = TRUE
log_archive_dest_1 = LOCATION=/u06/oradata/gzhs/arch
log_archive_format = %t_%s.dbf
db_file_multiblock_read_count= 16
fast_start_mttr_target = 300
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = gzhs
dispatchers = (PROTOCOL=TCP) (SERVICE=gzhsXDB)
job_queue_processes = 10
hash_join_enabled = TRUE
background_dump_dest = /oracle/admin/gzhs/bdump
user_dump_dest = /oracle/admin/gzhs/udump
core_dump_dest = /oracle/admin/gzhs/cdump
sort_area_size = 524288
db_name = gzhs
open_cursors = 300
star_transformation_enabled= FALSE
query_rewrite_enabled = FALSE
pga_aggregate_target = 838860800
aq_tm_processes = 1
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
CJQ0 started with pid=8
Thu Apr 1 11:11:13 2004
starting up 1 shared server(s) ...
QMN0 started with pid=9
Thu Apr 1 11:11:13 2004
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=12
ARC0: Archival started
ARC1 started with pid=13
Thu Apr 1 11:11:13 2004
ARCH: STARTING ARCH PROCESSES COMPLETE
Thu Apr 1 11:11:13 2004
ARC0: Thread not mounted
Thu Apr 1 11:11:13 2004
ARC1: Archival started
ARC1: Thread not mounted
Thu Apr 1 11:11:14 2004
ALTER DATABASE MOUNT
Thu Apr 1 11:11:18 2004
Successful mount of redo thread 1, with mount id 1088380178.
Thu Apr 1 11:11:18 2004
Database mounted in Exclusive Mode.
Completed: ALTER DATABASE MOUNT
Thu Apr 1 11:11:27 2004
alter database open
Thu Apr 1 11:11:27 2004
Beginning crash recovery of 1 threads
Thu Apr 1 11:11:27 2004
Started first pass scan
Thu Apr 1 11:11:28 2004
Completed first pass scan
1 redo blocks read, 0 data blocks need recovery
Thu Apr 1 11:11:28 2004
Started recovery at
Thread 1: logseq 177, block 2, scn 0.33104793
Recovery of Online Redo Log: Thread 1 Group 3 Seq 177 Reading mem 0
Mem# 0 errs 0: /u01/oradata/gzhs/redo03.log
Thu Apr 1 11:11:28 2004
Completed redo application
Thu Apr 1 11:11:28 2004
Ended recovery at
Thread 1: logseq 177, block 3, scn 0.33124794
0 data blocks read, 0 data blocks written, 1 redo blocks read
Crash recovery completed successfully
Thu Apr 1 11:11:28 2004
LGWR: Primary database is in CLUSTER CONSISTENT mode
Thread 1 advanced to log sequence 178
Thread 1 opened at log sequence 178
Current log# 1 seq# 178 mem# 0: /u01/oradata/gzhs/redo01.log
Successful open of redo thread 1.
Thu Apr 1 11:11:28 2004
ARC0: Evaluating archive log 3 thread 1 sequence 177
Thu Apr 1 11:11:28 2004
ARC0: Beginning to archive log 3 thread 1 sequence 177
Creating archive destination LOG_ARCHIVE_DEST_1: '/u06/oradata/gzhs/arch/1_177.dbf'
Thu Apr 1 11:11:28 2004
SMON: enabling cache recovery
ARC0: Completed archiving log 3 thread 1 sequence 177
Thu Apr 1 11:11:28 2004
Errors in file /oracle/admin/gzhs/udump/gzhs_ora_27781.trc:
ORA-30012: 263267317373261355277325274344 'UNDOTBS1' 262273264346324332273362300340320315262273325375310
267
Thu Apr 1 11:11:28 2004
Error 30012 happened during db open, shutting down database
USER: terminating instance due to error 30012
Instance terminated by USER, pid = 27781
ORA-1092 signalled during: alter database open...
:q
.............
在警报日志末尾显示了数据库在Open状态因为错误而异常终止.
2. 尝试重新启动数据库
bash-2.03$ sqlplus “/ as sysdba”
SQL*Plus: Release 9.2.0.3.0 - Production on 星期四 4月 1 11:43:52 2004
Copyright (c) 1982, , Oracle Corporation. All rights reserved.
已连接到空闲例程，
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 4364148184 bytes
Fixed Size 736728 bytes
Variable Size 1845493760 bytes
Database Buffers 2516582400 bytes
Redo Buffers 1335296 bytes
数据库装载完毕，
ORA-01092: ORACLE 例程终止。强行断开连接
.............
工程人员报告的问题重现.
3. 检查数据文件
bash-2.03$ cd /u01/ oradata/gzhs
bash-2.03$ ls -l
total 55702458
-rw-r----- 1 oracle dba 1073750016 Apr 1 11:44 UNDOTBS2.dbf
-rw-r----- 1 oracle dba 1073750016 Apr 1 11:44 WAP12_BILLINGDETAIL.dbf
-rw-r----- 1 oracle dba 1073750016 Apr 1 11:44 WAP12_MAIN.dbf
-rw-r----- 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN10.dbf
-rw-r----- 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN11.dbf
-rw-r----- 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN2.dbf
-rw-r----- 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN3.dbf
-rw-r----- 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN4.dbf
-rw-r----- 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN5.dbf
-rw-r----- 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN6.dbf
-rw-r----- 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN7.dbf
-rw-r----- 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN8.dbf
-rw-r----- 1 oracle dba 2097160192 Apr 1 11:44 WAP12_MAIN9.dbf
-rw-r----- 1 oracle dba 1073750016 Apr 1 11:44 WAP12_MVIEW.dbf
-rw-r----- 1 oracle dba 1073750016 Mar 24 17:15 WAP12_TEMP1.dbf
.........................
.............
发现存在文件UNDOTBS2.dbf
4. mount数据库，检查系统参数
bash-2.03$ sqlplus “/ as sysdba” SQL*Plus: Release 9.2.0.3.0 - Production on 星期四 4月 1 11:46:20 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. 已连接到空闲例程。 SQL> SQL> SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area 4364148184 bytes Fixed Size 736728 bytes Variable Size 1845493760 bytes Database Buffers 2516582400 bytes Redo Buffers 1335296 bytes 数据库装载完毕。
SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- /u01/oradata/gzhs/system01.dbf /u01/oradata/gzhs/cwmlite01.dbf /u01/oradata/gzhs/drsys01.dbf /u01/oradata/gzhs/example01.dbf /u01/oradata/gzhs/indx01.dbf /u01/oradata/gzhs/odm01.dbf /u01/oradata/gzhs/tools01.dbf /u01/oradata/gzhs/users01.dbf /u01/oradata/gzhs/xdb01.dbf ......................... /u01/oradata/gzhs/UNDOTBS2.dbf
已选择23行。
SQL> SQL> show parameter undo NAME TYPE VALUE
------------------------------------ ----------- ------------------------------ undo_management string AUTO undo_retention integer 10800 undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS1
SQL> show parameter spfile
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string
.........................
.............
发现系统没有使用spfile,而初始化参数设置的undo表空间为UNDOTBS1
5. 检查参数文件
bash-2.03$ cd $ORACLE_HOME/dbs bash-2.03$ ls
init.ora initgzhs.ora initgzhs.ora.old orapwgzhs initdw.ora initgzhs.ora.hurray lkGZHS snapcf_gzhs.f bash-2.03$ vi initgzhs.ora
“initgzhs.ora” [Incomplete last line] 105 lines, 3087 characters
####################################################
# Copyright (c) 1991, 2001, 2002 by Oracle Corporation
####################################################
###########################################
# Archive
###########################################
log_archive_dest_1='LOCATION=/u06/oradata/gzhs/arch'
log_archive_format=%t_%s.dbf log_archive_start=true ###########################################
# Cache and I/O
###########################################
db_block_size=8192
db_cache_size=2516582400
db_file_multiblock_read_count=16
###########################################
# Cursors and Library Cache
###########################################
open_cursors=300
......................
###########################################
# System Managed Undo and Rollback Segments
###########################################
undo_management=AUTO
undo_retention=10800
undo_tablespace=UNDOTBS1
:q!
.............
这个设置是极其可疑的.
怀疑参数文件和实际数据库设置不符.
6. 再次检查alert文件
查找对于UNDO表空间的操作
第一部分，创建数据库时的信息:
Sat Feb 7 20:30:12 2004 CREATE DATABASE gzhs MAXINSTANCES 1 MAXLOGHISTORY 1 MAXLOGFILES 5 MAXLOGMEMBERS 3 MAXDATAFILES 100 DATAFILE '/u01/oradata/gzhs/system01.dbf' SIZE 500M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE '/u01/oradata/gzhs/temp01.dbf' SIZE 1000M REUSE AUTOEXTEND ON NEXT 250M MAXSIZE UNLIMITED UNDO TABLESPACE “UNDOTBS1” DATAFILE '/u01/oradata/gzhs/undotbs01.dbf' SIZE 1000M REUSE AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED
CHARACTER SET ZHS16GBK
NATIONAL CHARACTER SET AL16UTF16
LOGFILE GROUP 1 ('/u01/oradata/gzhs/redo01.log') SIZE 256M,
GROUP 2 ('/u01/oradata/gzhs/redo02.log') SIZE 256M,
GROUP 3 ('/u01/oradata/gzhs/redo03.log') SIZE 256M
.............
注意，这也是OCP教材上提到的两种创建UNDO表空间的方式之一
第二部分,发现创建UNDOTBS2的记录信息:
Wed Mar 24 20:20:58 2004/* OracleOEM */ CREATE UNDO TABLESPACE “UNDOTBS2” DATAFILE '/u01/oradata/gzhs/UNDOTBS2.dbf' SIZE 1024M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED Wed Mar 24 20:22:37 2004 Created Undo Segment _SYSSMU11$ Created Undo Segment _SYSSMU12$ Created Undo Segment _SYSSMU13$ Created Undo Segment _SYSSMU14$ Created Undo Segment _SYSSMU15$ Created Undo Segment _SYSSMU16$ Created Undo Segment _SYSSMU17$ Created Undo Segment _SYSSMU18$ Created Undo Segment _SYSSMU19$ Created Undo Segment _SYSSMU20$ Completed: /* OracleOEM */ CREATE UNDO TABLESPACE “UNDOTBS2”
Wed Mar 24 20:24:25 2004
Undo Segment 11 Onlined
Undo Segment 12 Onlined
Undo Segment 13 Onlined
Undo Segment 14 Onlined
Undo Segment 15 Onlined
Undo Segment 16 Onlined
Undo Segment 17 Onlined
Undo Segment 18 Onlined
Undo Segment 19 Onlined
Undo Segment 20 Onlined
Successfully onlined Undo Tablespace 15.
Undo Segment 1 Offlined
Undo Segment 2 Offlined
Undo Segment 3 Offlined
Undo Segment 4 Offlined
Undo Segment 5 Offlined
Undo Segment 6 Offlined
Undo Segment 7 Offlined
Undo Segment 8 Offlined
Undo Segment 9 Offlined
Undo Segment 10 Offlined
Undo Tablespace 1 successfully switched out.
.............
第三部分，新的UNDO表空间被应用
Wed Mar 24 20:24:25 2004
ALTER SYSTEM SET undo_tablespace='UNDOTBS2' SCOPE=MEMORY;
我们发现问题就在这里,创建了新的UNDO表空间以后，因为使用的是pfile文件，修改的只对当前实例生效，操作人员忘记了修改pfile文件.
如果使用spfile，缺省的修改范围是both,会同时修改spfile文件，就可以避免以上问题的出现.
第四部分，删除了UNDOTBS1的信息
Wed Mar 24 20:25:01 2004 /* OracleOEM */ DROP TABLESPACE “UNDOTBS1” INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS Wed Mar 24 20:25:03 2004 Deleted file /u01/oradata/gzhs/undotbs01.dbf Completed: /* OracleOEM */ DROP TABLESPACE “UNDOTBS1” INCLUDI
.............
这样再次重新启动数据库的时候，问题出现了，pfile中定义的UNDOTBS1找不到了，而且操作实在很久以前，没人能回忆起来，甚至无法得知是什么人的操作。
7. 更改pfile，启动数据库
修改undo表空间
###########################################
# System Managed Undo and Rollback Segments
###########################################
undo_management=AUTO
undo_retention=10800
undo_tablespace=UNDOTBS2
....
bash-2.03$ sqlplus “/ as sysdba”
SQL*Plus: Release 9.2.0.3.0 - Production on 星期四 4月 1 11:55:11 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
连接到:
Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 - Production
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production
PL/SQL Release 9.2.0.3.0 - Production
CORE 9.2.0.3.0 Production
TNS for Solaris: Version 9.2.0.3.0 - Production
NLSRTL Version 9.2.0.3.0 - Production
SQL> exit
从Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 - Production中断开
bash-2.03$
在这里我们可以看到，使用spfile可以免去手工修改pfile文件的麻烦，减少了犯错的可能。
既然Oracle9i给我们提供了这个新特性，就值得我们学习使用它.
恢复
1.1. 丢失spfile的恢复大前提：已经配置了数据库控制文件的自动备份，并且已经有可靠的备份：
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP on;
新的 RMAN 配置参数:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
已成功存储新的 RMAN 配置参数
正在启动全部恢复目录的 resync
完成全部 resync
RMAN>
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'D:RMANTEST%F';
新的 RMAN 配置参数:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'D:RMANTEST%F';
已成功存储新的 RMAN 配置参数
正在启动全部恢复目录的 resync
完成全部 resync
RMAN>
RMAN> show all;
RMAN 配置参数为:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'D:RMANTEST%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'D:ORACLE92DATABASE NCFTEST1.ORA'; # default
RMAN>
RMAN> run{
2> backup database
3> tag 'full_db_20041007'
4> format 'd:rmantestfull_dbtest_yyyymmdd%_u%.bak'
5> include current controlfile;
6> backup archivelog all
7> tag 'arch_bak'
8> format 'd:rmantestarch_yyyymmdd%_u%.bak'
9> delete input;}
启动 backup 于 07-10月-04
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=13 devtype=DISK
通道 ORA_DISK_1: 正在启动 full 数据文件备份集
通道 ORA_DISK_1: 正在指定备份集中的数据文件
备份集中包括当前控制文件
输入数据文件 fno=00001 name=D:ORACLE92TEST1 YSTEM01.DBF
输入数据文件 fno=00002 name=D:ORACLE92TEST1UNDOTBS01.DBF
输入数据文件 fno=00006 name=D:ORACLE92TEST1RMAN01.DBF
输入数据文件 fno=00003 name=D:ORACLE92TEST1INDX01.DBF
输入数据文件 fno=00005 name=D:ORACLE92TEST1USERS01.DBF
输入数据文件 fno=00004 name=D:ORACLE92TEST1TOOLS01.DBF
通道 ORA_DISK_1: 正在启动段 1 于 07-10月-04
通道 ORA_DISK_1: 已完成段 1 于 07-10月-04
段 handle=D:RMANTESTFULL_DBTEST_YYYYMMDD%_U%.BAK comment=NONE
通道 ORA_DISK_1: 备份集已完成, 经过时间:00:01:06
完成 backup 于 07-10月-04
启动 backup 于 07-10月-04
当前日志已存档
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 正在启动存档日志备份集
通道 ORA_DISK_1: 正在指定备份集中的存档日志
输入存档日志线程 =1 序列 =15 记录 ID=20 时间戳=538928248
通道 ORA_DISK_1: 正在启动段 1 于 07-10月-04
通道 ORA_DISK_1: 已完成段 1 于 07-10月-04
段 handle=D:RMANTESTARCH_YYYYMMDD%_U%.BAK comment=NONE
通道 ORA_DISK_1: 备份集已完成, 经过时间:00:00:02
通道 ORA_DISK_1: 正在删除存档日志
存档日志文件名 =D:ORACLE92ADMINTEST1ARCHARC00015.001 记录 ID=20 时间戳 =538928248
完成 backup 于 07-10月-04
启动 Control File and SPFILE Autobackup 于 07-10月-04
段 handle=D:RMANTESTC-910599446-20041007-00 comment=NONE
完成 Control File and SPFILE Autobackup 于 07-10月-04
RMAN>
1.1.1. 将当前spfile挪到其他位置来模拟spfile丢失
RMAN> host;
Microsoft Windows XP [版本 5.1.2600]
(C) 版权所有 1985-2001 Microsoft Corp.
C:>move D:oracle92database PFILETEST1.ORA D:oracle92databasebak PFILETEST1.ORA
C:>dir D:oracle92database PFILETEST1.ORA
驱动器 D 中的卷没有标签，
卷的序列号是 644D-03D9
D:oracle92database 的目录
找不到文件
C:>dir D:oracle92databasebak PFILETEST1.ORA
驱动器 D 中的卷没有标签。
卷的序列号是 644D-03D9
D:oracle92databasebak 的目录
2004-10-04 14:06 2,560 SPFILETEST1.ORA
1 个文件 2,560 字节
0 个目录 10,708,807,680 可用字节
C:>exit
主机命令完成
RMAN>
1.1.2. 设置ORACLE_SID
C:>set ORACLE_SID=TEST1
C:>ECHO ORACLE_SID
ORACLE_SID
C:>
1.1.3. 登陆RMAN
C:>rman
恢复管理器: 版本9.2.0.1.0 - Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
RMAN> connect target lunar/lunar@test1
已连接到目标数据库 (未启动)
RMAN> connect catalog rman/rman@rman
连接到恢复目录数据库
RMAN>
1.1.4. 在RMAN中设置DBID
使RMAN知道需要查找哪一个数据库的spfile
（必须在数据关闭的情况下设置DBID）
RMAN> set DBID=910599446
正在执行命令: SET DBID
RMAN>
1.1.5. 将数据库启动到nomount状态
RMAN> startup nomount;
启动失败: ORA-01078: failure in processing system parameters
LRM-00109: N^7(4r?*2NJ}ND<~ 'D:ORACLE92DATABASEINITTEST1.ORA'
正在尝试在没有参数文件的情况下启动 Oracle 例程...
Oracle 例程已启动
系统全局区域总计 97589952 字节
Fixed Size 453312 字节
Variable Size 46137344 字节
Database Buffers 50331648 字节
Redo Buffers 667648 字节
RMAN>
1.1.6. 从自动备份中还原参数文件
RMAN> show all;
RMAN 配置参数为:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'D:RMANTEST%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
RMAN> restore spfile from autobackup;
启动 restore 于 07-10月-04
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=9 devtype=DISK
通道 ORA_DISK_1: 寻找以下日期的自动备份: 20041007
通道 ORA_DISK_1: 已找到的自动备份: D:RMANTESTc-910599446-20041007-00
通道 ORA_DISK_1: 从自动备份复原 SPFILE 已完成
完成 restore 于 07-10月-04
RMAN> host;
恢复管理器完成，
C:>dir D:oracle92database PFILETEST1.ORA
驱动器 D 中的卷没有标签。
卷的序列号是 644D-03D9
D:oracle92database 的目录
2004-10-07 14:31 2,560 SPFILETEST1.ORA
1 个文件 2,560 字节
0 个目录 10,528,374,784 可用字节
C:> exit
恢复管理器: 版本9.2.0.1.0 - Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
连接到目标数据库: TEST1（未安装）
连接到恢复目录数据库
RMAN>
1.1.7. 用Shutdown immediate关闭数据库
RMAN> shutdown immediate;
Oracle 例程已关闭
RMAN>
1.1.8. 重新启动数据库
RMAN> set DBID=910599446
正在执行命令: SET DBID
RMAN> startup
已连接到目标数据库 (未启动)
Oracle 例程已启动
数据库已加载
数据库已打开
系统全局区域总计 101784276 字节
Fixed Size 453332 字节
Variable Size 75497472 字节
Database Buffers 25165824 字节
Redo Buffers 667648 字节
RMAN>
oracle|备份|恢复
一. 理解什么是数据库恢复
当我们使用一个数据库时，总希望数据库的内容是可靠的、正确的，但由于计算机系统的故障（硬件故障、软件故障、网络故障、进程故障和系统故障）影响数据库系统的操作，影响数据库中数据的正确性，甚至破坏数据库，使数据库中全部或部分数据丢失，因此当发生上述故障后，希望能重构这个完整的数据库，该处理称为数据库恢复。恢复过程大致可以分为复原(Restore)与恢复(Recover)过程。
数据库恢复可以分为以下两类：
1.1实例故障的一致性恢复
当实例意外地（如掉电、后台进程故障等）或预料地（发出SHUTDOUM ABORT语句）中止时出现实例故障，此时需要实例恢复。实例恢复将数据库恢复到故障之前的事务一致状态。如果在在线后备发现实例故障，则需介质恢复。在其它情况Oracle在下次数据库起动时（对新实例装配和打开），自动地执行实例恢复。如果需要，从装配状态变为打开状态，自动地激发实例恢复，由下列处理：
1） 为了解恢复数据文件中没有记录的数据，进行向前滚。该数据记录在在线日志，
包括对回滚段的内容恢复。
2） 回滚未提交的事务，按步1重新生成回滚段所指定的操作。
3） 释放在故障时正在处理事务所持有的资源。
4） 解决在故障时正经历一阶段提交的任何悬而未决的分布事务。
1.2介质故障或文件错误的不一致恢复
介质故障是当一个文件、一个文件的部分或磁盘不能读或不能写时出现的故障。文件错误一般指意外的错误导致文件被删除或意外事故导致文件的不一致。这种状态下的数据库都是不一致的，需要DBA手工来进行数据库的恢复，这种恢复有两种形式，决定于数据库运行的归档方式和备份方式。
（1） 完全介质恢复可恢复全部丢失的修改。一般情况下需要有数据库的备份且数据库运行在归档状态下并且有可用归档日志时才可能。对于不同类型的错误，有不同类型的完全恢复可使用，其决定于毁坏文件和数据库的可用性。
（2） 不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损的数据库，使其恢复介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复有不同类型的使用，决定于需要不完全介质恢复的情况，有下列类型：基于撤消、基于时间和基于修改的不完全恢复。
挥诔废(CANCEL)恢复：在某种情况，不完全介质恢复必须被控制，DBA可撤消在指定点的操作。基于撤消的恢复地在一个或多个日志组（在线的或归档的）已被介质故障所破坏，不能用于恢复过程时使用，所以介质恢复必须控制，以致在使用最近的、未损的日志组于数据文件后中止恢复操作。
挥谑奔(TIME)和基于修改(SCN)的恢复：如果DBA希望恢复到过去的某个指定点，是一种理想的不完全介质恢复，一般发生在恢复到某个特定操作之前，恢复到如意外删除某个数据表之前。
第二章. 数据库恢复案例测试环境
2.1 数据库环境
以下的所有案例都是通过测试经过，环境为：
OS：Windows Server
DB：Oracle 816
DBNAME：TEST
数据文件：
SQL> select file#,status,enabled,name from v$datafile;
FILE# STATUS ENABLED NAME
----------------------------------------------------------------
1 SYSTEM READ WRITE D:OracleORADATATEST YSTEM01.DBF
2 ONLINE READ WRITE D:OracleORADATATESTRBS01.DBF
3 ONLINE READ WRITE D:OracleORADATATESTUSERS01.DBF
4 ONLINE READ WRITE D:OracleORADATATESTTEMP01.DBF
5 ONLINE READ WRITE D:OracleORADATATESTTOOLS01.DBF
6 ONLINE READ WRITE D:OracleORADATATESTINDX01.DBF
控制文件：
SQL> select * from v$controlfile;
STATUS NAME
---------------------------------------------------------------------
D:OracleORADATATESTCONTROL01.CTL
D:OracleORADATATESTCONTROL02.CTL
D:OracleORADATATESTCONTROL03.CTL
联机日志：
SQL> select * from v$logfile;
GROUP# STATUS MEMBER
---------------------------------------------------------------------
1 STALE D:OracleORADATATESTREDO01.LOG
2 D:OracleORADATATESTREDO02.LOG
3 STALE D:OracleORADATATESTREDO03.LOG
2.2 数据库备份脚本
冷备份脚本:
rem script.:coldbak.sql
rem creater:chenjiping
rem date:5.8.
rem desc:offline full backup database
--connect database
connect internal/password;
--shutdown database
shutdown immediate;
--Copy Data file
!xcopy d:Oracleoradatatest*.dbf d:database/H/R;
--Copy Control file
!xcopy d:Oracleoradatatest*.ctl d:database/H/R;
--Copy Log file
!xcopy d:Oracleoradatatest*.log d:database/H/R;
--startup database
startup;
说明：
1、以上脚本在数据库关闭状态下备份数据库所有的数据文件，联机日志，控制文件（在一个目
录下），如果成功备份，所有文件是一致的;
2、没有备份参数文件，参数文件可以另外备份，没有必要每次都备份，只需要在改变设置后备份一次;
3、如果以上命令没有成功依次执行，那么备份将是无效的，如连接数据库不成功，那么肯定关闭数据库也不成功，那么备份则无效;
4、冷备份建议下人工干预下执行。
数据库OS热全备份脚本
rem script.:hotbak.sql
rem creater:chenjiping
rem date:5.8.2003
rem desc:backup all database datafile in archive
--connect database
connect internal/password;
--archive
alter system archive log current;
--start
alter tablespace system begin backup;
!xcopy d:Oracleoradatatest ystem01.dbf d:databak/H/R;
alter tablespace system end backup;
alter tablespace rbs begin backup;
!xcopy d:Oracleoradatatestrbs01.dbf d:databak/H/R;
alter tablespace rbs end backup;
alter tablespace users begin backup;
!xcopy d:Oracleoradatatestusers01.dbf d:databak/H/R;
alter tablespace users end backup;
alter tablespace tools begin backup;
!xcopy d:Oracleoradatatesttools01.dbf d:databak/H/R;
alter tablespace tools end backup;
alter tablespace indx begin backup;
!xcopy d:Oracleoradatatestindx01.dbf d:databak/H/R;
alter tablespace indx end backup;
--end
--bak control file
--binary
alter database backup controlfile to 'd:databakcontrolbinbak.000';
--ascii
alter database backup controlfile to trace;
alter system archive log current;
说明：
1、热备份必须在数据库归档方式下才可以运行；
2、以上脚本可以在数据库运行状态下备份数据库所有的数据文件（除了临时数据文件），没有必要备份联机日志；
3、归档日志至少需要一次完整备份之后的所有日志；
4、如果以上命令没有成功依次执行，那么备份也是无效的，如连接数据库不成功，那么备份则无效。
RMAN备份只讲叙有恢复目录的情况，如果没有恢复目录，情形大致相似。以下是RMAN的热备份全备份的脚本：
# script.:bakup.rcv
# creater:chenjiping
# date:5.8.2003
# desc:backup all database datafile in archive with rman
# connect database
connect rcvcat rman/rman@back;
connect target internal/virpure;
# start backup database
run{
allocate channel c1 type disk;
backup full tag 'dbfull' format 'd:backupfull%u_%s_%p' database
include current controlfile;
sql 'alter system archive log current';
release channel c1;
}
# end
说明：
1、 数据库必须运行在归档模式下;
2、 RMAN将自动备份数据文件，运行可靠;
3、 归档日志另外备份处理，但至少需要保存一次备份来的日志;
4、 没有必要用RMAN做冷备份，效果不好。
以上举例说明了数据库的恢复案例的测试环境与部分备份测试脚本，其它的备份脚本可以根据以上脚本演变而来或在案例中加以说明。
数据库的自动实例将不加以说明，这里只举例说明媒体错误或人为错误造成的恢复可能。
以上包括以下案例都是在WINDOWS+Oracle816上测试验证的，在不同的操作系统与不同的数据库版本中略有差别。
第三章. 了解与恢复相关的信息
1、 理解报警日志文件
报警日志文件一般记载了数据库的启动/关闭信息，归档信息，备份信息，恢复信息，常见错误信息，部分数据库修改记录等。一般令名规则为
报警日志文件的路径是根据初始化参数background_dump_dest来决定的，如在我的机器上，该参数值为 D:Oracleadmintestbdump，那么，你就可以在该路径下找到该文件。
2、 后台进程跟踪文件
后台进程跟踪文件的路径与报警日志文件的路径一致，在某些情况下，你可以通过后台跟踪文件的信息了解更多的需要恢复的信息。如在数据库需要恢复的时候，报警日志文件中常有这样的语句：
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
通过提示的DBWR跟踪文件，可以查询到更详细的信息。
3、 v$recover_file与v$recovery_log
这是两个动态性能视图，可以在mount下查看，通过这两个视图，你可以了解详细的需要恢复的数据文件与需要使用到的归档日志。
第四章. 数据库恢复案例
4.1非归档模式下的备份与恢复
备份方案：采用OS冷备份
1. 连接数据库并创建测试表
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2. 备份数据库
SQL> @coldbak.sql 或在DOS下 svrmgrl @coldbak.sql
3. 再插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
-------------------
1
2
4. 关闭数据库
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down.
5. 毁坏一个或多个数据文件，如删除user01.dbf
C:>del D:OracleORADATATESTUSERS01.DBF
模拟媒体毁坏。
6. 重新启动数据库，会发现如下错误
SQL> startup
Oracle instance started.
Total System Global Area 10364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:OracleORADATATESTUSERS01.DBF'
在报警文件中，会有更详细的信息
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:OracleORADATATESTUSERS01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
7. 拷贝备份复原到原来位置(restore过程)
C:>xcopy d:database*.* d:Oracleoradatatest/H/R/S
8. 打开数据库，检查数据
SQL> alter database open;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
这里可以发现，数据库恢复成功，但在备份之后与崩溃之前的数据丢失了。
说明：
1、非归档模式下的恢复方案可选性很小，一般情况下只能有一种恢复方式，就是数据库的冷备
份的完全恢复，仅仅需要拷贝原来的备份就可以(restore)，不需要recover；
2、这种情况下的恢复，可以完全恢复到备份的点上，但是可能是丢失数据的，在备份之后与崩溃之前的数据将全部丢失；
3、不管毁坏了多少数据文件或是联机日志或是控制文件，都可以通过这个办法恢复，因为这个恢复过程是Restore所有的冷备份文件，而这个备份点上的所有文件是一致的，与最新的数据库没有关系，就好比把数据库又放到了一个以前的“点”上；
4、对于非归档模式下，最好的办法就是采用OS的冷备份，建议不要用RMAN来作冷备份，效果不好，因为RMAN不备份联机日志，restore不能根本解决问题；
5、如果没有备份联机日志，如RMAN的备份，就需要利用不完全恢复(until cancel)的方法来重新创建联机日志文件。
4.2归档模式下丢失或损坏一个数据文件
4.2.1 OS备份方案
在归档方式下损坏或丢失一个数据文件，如果存在相应的备份与该备份以来的归档日志，恢复还是比较简单的，可以作到尽量少的Down机时间，并能作到数据库的完全恢复。
1、 连接数据库，创建测试表并插入记录
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int) tablespace users;
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、 备份数据库
SQL> @hotbak.sql 或在DOS下 svrmgrl @hotbak.sql
3、 继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
--------------------------------------
1
2
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
4、 关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down
C:>del D:OracleORADATATESTUSERS01.DBF
模拟媒体毁坏。
5、 启动数据库错误，脱机该数据文件：
SQL> startup
Oracle instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:OracleORADATATESTUSERS01.DBF'
还可以查看报警文件（见上一个恢复案例）或动态视图v$recover_file
如SQL> select * from v$recover_file;
FILE# ONLINE ERROR CHANGE# TIME
---------- ------- ------------------ ---------- -----------
3 ONLINE 1013500 2003-05-07
脱机数据文件
SQL> alter database datafile 3 offline drop;
Database altered.
6、 打开数据库，拷贝备份回来(restore)，恢复(recover)该数据文件，并联机:
SQL> alter database open;
Database altered.
拷贝备份从备份处
copy d:databak users01.dbf d:Oracleoradatatest;
恢复该数据文件
SQL> recover datafile 3;
ORA-00279: change 1053698 generated at 05/07/2003 17:51:26 needed for
thread 1
ORA-00289: suggestion :
D:OracleORADATATESTARCHIVETESTT001S00304.ARC
ORA-00280: change 1053698 for thread 1 is in sequence #304
Specify log: {
AUTO
ORA-00279: change 1053701 generated at 05/07/2003 17:51:39 needed for
thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00305.ARC
ORA-00280: change 1053701 for thread 1 is in sequence #305
ORA-00278: log file 'D:OracleORADATATESTARCHIVETESTT001S00304.ARC' no longer needed for this recovery Log applied.
Media recovery complete.
恢复成功，联机该数据文件
SQL> alter database datafile 3 online;
Database altered.
7、 检查数据库的数据（完全恢复）
SQL> select * from test;
A
--------------------------------
1
2
说明：
1、采用热备份，需要运行在归档模式下，可以实现数据库的完全恢复，也就是说，从备份后到数据库崩溃时的数据都不会丢失;
2、可以采用全备份数据库的方式备份，对于特殊情况，也可以只备份特定的数据文件，如只备份用户表空间（一般情况下对于某些写特别频繁的数据文件，可以单独加大备份频率）；
3、如果在恢复过程中，发现损坏的是多个数据文件，即可以采用一个一个数据文件的恢复方法（第5步中需要对数据文件一一脱机，第6步中需要对数据文件分别恢复），也可以采用整个数据库的恢复方法；
4、如果是系统表空间的损坏，不能采用此方法。
4.2.2 RMAN备份方案
RMAN也可以进行联机备份，而且备份与恢复方法将比OS备份更简单可靠。
1、连接数据库，创建测试表并插入记录
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int) tablespace users;
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、 备份数据库表空间users
C:>rman
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> connect rcvcat rman/rman@back
RMAN-06008: connected to recovery catalog database
RMAN> connect target internal/virpure
RMAN-06005: connected to target database: TEST (DBID=1788174720)
RMAN> run{
2> allocate channel c1 type disk;
3> backup tag 'tsuser' format 'd:backuptsuser_%u_%s_%p'
4> tablespace users;
5> release channel c1;
6> }
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=16 devtype=DISK
RMAN-03022: compiling command: backup
RMAN-03025: performing implicit partial resync of recovery catalog
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03023: executing command: backup
RMAN-08008: channel c1: starting full datafile backupset
RMAN-08502: set_count=5 set_stamp=494177612 creation_time=16-MAY-03
RMAN-08010: channel c1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00003 name=D:OracleORADATATESTUSER01.DBF
RMAN-08013: channel c1: piece 1 created
RMAN-08503: piece handle=D:BACKUPTSUSER_05EN93AC_5_1 comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:00:01
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
RMAN>
3、 继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
System altered.
SQL>r
1* alter system switch logfile;
System altered.
4、 关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down
C:>del D:OracleORADATATESTUSER01.DBF
5、 启动数据库，检查错误
SQL> startup
Oracle instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:OracleORADATATESTUSER01.DBF'
6、 先打开数据库
SQL> alter database datafile 3 offline drop;
Database altered.
SQL> alter database open;
Database altered.
7、 恢复该表空间
恢复脚本可以是恢复单个数据文件
run{
allocate channel c1 type disk;
restore datafile 3;
recover datafile 3;
sql 'alter database datafile 3 online';
release channel c1;
}
也可以是,恢复表空间
run{
allocate channel c1 type disk;
restore tablespace users;
recover tablespace users;
sql 'alter database datafile 3 online';
release channel c1;
}
过程如下：
C:>rman
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> connect rcvcat rman/rman@back
RMAN-06008: connected to recovery catalog database
RMAN> connect target internal/virpure
RMAN-06005: connected to target database: TEST (DBID=1788174720)
RMAN> run{
2> allocate channel c1 type disk;
3> restore datafile 3;
4> recover datafile 3;
5> sql 'alter database datafile 3 online';
6> release channel c1;
7> }
//输出内容冗长，省略--编者
RMAN>
8、 检查数据是否完整
SQL> alter database open;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
2
说明：
1、RMAN也可以实现单个表空间或数据文件的恢复，恢复过程可以在mount下或open方式下，如果在open方式下恢复，可以减少down机时间;
2、如果损坏的是一个数据文件，建议offline并在open方式下恢复;
3、这里可以看到，RMAN进行数据文件与表空间恢复的时候，代码都比较简单，而且能保证备份与恢复的可靠性，所以建议采用RMAN的备份与恢复.
4.3丢失多个数据文件，实现整个数据库的恢复.
4.3.1 OS备份方案
OS备份归档模式下损坏（丢失）多个数据文件，进行整个数据库的恢复
1、 连接数据库，创建测试表并插入记录
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、 备份数据库，备份除临时数据文件后的所数据文件
SQL> @hotbak.sql 或在DOS下 svrmgrl @hotbak.sql
3、 继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
4、 关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down
C:>del D:OracleORADATATEST YSTEM01.DBF
C:>del D:OracleORADATATESTINDX01.DBF
C:>del D:OracleORADATATESTTOOLS01.DBF
C:>del D:OracleORADATATESTRBS01.DBF
模拟媒体毁坏（这里删除多个数据文件）
5、 启动数据库，检查错误
SQL> STARTUP
Oracle instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:OracleORADATATEST YSTEM01.DBF'
详细信息可以查看报警文件
ORA-1157 signalled during: ALTER DATABASE OPEN...
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:OracleORADATATEST YSTEM01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 2 - see DBWR trace file
ORA-01110: data file 2: 'D:OracleORADATATESTRBS01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: 'D:OracleORADATATESTTOOLS01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
Thu May 08 09:39:36 2003
Errors in file D:OracleadmintestbdumptestDBW0.TRC:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: 'D:OracleORADATATESTINDX01.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
通过查询v$recover_file可以看到
SQL> select * from v$recover_file;
FILE# ONLINE ERROR CHANGE# TIME
---------- ------- ------------------ ---------- -----------
1 ONLINE FILE NOT FOUND 0
2 ONLINE FILE NOT FOUND 0
5 ONLINE FILE NOT FOUND 0
6 ONLINE FILE NOT FOUND 0
有四个数据文件需要恢复
6、 拷贝备份回到原地点(restore)，开始恢复数据库(recover)
restore过程:
C:>copy D:DATABAK YSTEM01.DBF D:OracleORADATATEST
C:>copy D:DATABAKTESTINDX01.DBF D:OracleORADATATEST
C:>copy D:DATABAKTESTTOOLS01.DBF D:OracleORADATATEST
C:>copy D:DATABAKTESTRBS01.DBF.DBF D:OracleORADATATEST
Recover过程:
SQL> recover database;
ORA-00279: change 1073849 generated at 05/08/2003 08:58:35 needed for thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00311.ARC
ORA-00280: change 1073849 for thread 1 is in sequence #311
Specify log: {
auto
ORA-00279: change 1073856 generated at 05/08/2003 09:03:27 needed for thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00312.ARC
ORA-00280: change 1073856 for thread 1 is in sequence #312
ORA-00278: log file 'D:OracleORADATATESTARCHIVETESTT001S00311.ARC' no
longer needed for this recovery
ORA-00279: change 1073858 generated at 05/08/2003 09:11:43 needed for thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00313.ARC
ORA-00280: change 1073858 for thread 1 is in sequence #313
ORA-00278: log file 'D:OracleORADATATESTARCHIVETESTT001S00312.ARC' no
longer needed for this recovery
ORA-00279: change 1073870 generated at 05/08/2003 09:11:46 needed for thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00314.ARC
ORA-00280: change 1073870 for thread 1 is in sequence #314
ORA-00278: log file 'D:OracleORADATATESTARCHIVETESTT001S00313.ARC' no
longer needed for this recovery
Log applied.
Media recovery complete.
7、 打开数据库，检查数据库的数据（完全恢复）
SQL> alter database open;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
2
说明：
1、只要有备份与归档存在，就可以实现数据库的完全恢复（不丢失数据）;
2、适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复;
3、恢复过程在mount下进行，如果恢复成功，再打开数据库，down机时间可能比较长一些。
4.3.2 RMAN备份方案
RMAN备份归档模式下损坏（丢失）多个数据文件，进行整个数据库的恢复
1、连接数据库，创建测试表并插入记录
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、备份数据库
DOS下 C:> rman cmdfile=bakup.rcv msglog=backup.log;
以下是backup.log内容。
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> # script.:bakup.rcv
2> # creater:chenjiping
3> # date:5.8.2003
4> # desc:backup all database datafile in archive with rman
5>
6> #connect database
7> connect rcvcat rman/rman@back;
8> connect target internal/virpure;
9>
10> #start backup database
11> run{
12> allocate channel c1 type disk;
13> backup full tag 'dbfull' format 'd:backupfull%u_%s_%p' database
14> include current controlfile;
15> sql 'alter system archive log current';
16> release channel c1;
17> }
18> #end
19>
RMAN-06008: connected to recovery catalog database
RMAN-06005: connected to target database: TEST (DBID=1788174720)
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=15 devtype=DISK
RMAN-03022: compiling command: backup
RMAN-03023: executing command: backup
RMAN-08008: channel c1: starting full datafile backupset
RMAN-08502: set_count=4 set_stamp=494074368 creation_time=15-MAY-03
RMAN-08010: channel c1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00002 name=D:OracleORADATATESTRBS01.DBF
RMAN-08522: input datafile fno=00001 name=D:OracleORADATATEST YSTEM01.DBF
RMAN-08011: including current controlfile in backupset
RMAN-08522: input datafile fno=00005 name=D:OracleORADATATESTTOOLS01.DBF
RMAN-08522: input datafile fno=00004 name=D:OracleORADATATESTTEMP01.DBF
RMAN-08522: input datafile fno=00006 name=D:OracleORADATATESTINDX01.DBF
RMAN-08522: input datafile fno=00003 name=D:OracleORADATATESTUSER01.DBF
RMAN-08013: channel c1: piece 1 created
RMAN-08503: piece handle=D:BACKUPFULL04EN5UG0_4_1 comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:01:16
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: sql
RMAN-06162: sql statement: alter system archive log current
RMAN-03023: executing command: sql
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
Recovery Manager complete.
到这里表示备份成功。
3、 继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL>alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
4、 关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down
C:>del D:OracleORADATATEST YSTEM01.DBF
C:>del D:OracleORADATATESTINDX01.DBF
C:>del D:OracleORADATATESTTOOLS01.DBF
C:>del D:OracleORADATATESTRBS01.DBF
5、启动数据库，检查错误
SQL> STARTUP
Oracle instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:OracleORADATATEST YSTEM01.DBF'
查询v$recover_file
SQL> select * from v$recover_file;
FILE# ONLINE ERROR CHANGE# TIME
---------- ------- ------------------ ---------- -----------
1 ONLINE FILE NOT FOUND 0
2 ONLINE FILE NOT FOUND 0
5 ONLINE FILE NOT FOUND 0
6 ONLINE FILE NOT FOUND 0
可以知道有四个数据文件需要恢复.
6、利用RMAN进行恢复
C:>rman
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> connect rcvcat rman/rman@back
RMAN-06008: connected to recovery catalog database
RMAN> connect target internal/virpure
RMAN-06005: connected to target database: TEST (DBID=1788174720)
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> recover database;
5> sql 'alter database open';
6> release channel c1;
7> }
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=17 devtype=DISK
RMAN-03022: compiling command: restore
RMAN-03025: performing implicit partial resync of recovery catalog
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: IRESTORE
RMAN-03023: executing command: IRESTORE
RMAN-08016: channel c1: starting datafile backupset restore
RMAN-08502: set_count=4 set_stamp=494074368 creation_time=15-MAY-03
RMAN-08089: channel c1: specifying datafile(s) to restore from backup set
RMAN-08523: restoring datafile 00001 to D:OracleORADATATEST YSTEM01.DBF
RMAN-08523: restoring datafile 00002 to D:OracleORADATATESTRBS01.DBF
RMAN-08523: restoring datafile 00003 to D:OracleORADATATESTUSER01.DBF
RMAN-08523: restoring datafile 00004 to D:OracleORADATATESTTEMP01.DBF
RMAN-08523: restoring datafile 00005 to D:OracleORADATATESTTOOLS01.DBF
RMAN-08523: restoring datafile 00006 to D:OracleORADATATESTINDX01.DBF
RMAN-08023: channel c1: restored backup piece 1
RMAN-08511: piece handle=D:BACKUPFULL04EN5UG0_4_1 tag=DBFULL params=NULL
RMAN-08024: channel c1: restore complete
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: recover
RMAN-03022: compiling command: recover(1)
RMAN-03022: compiling command: recover(2)
RMAN-03022: compiling command: recover(3)
RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-03022: compiling command: recover(4)
RMAN-06050: archivelog thread 1 sequence 327 is already on disk as file D:OracleORADATATESTARCHIVETESTT001S00327.ARC
RMAN-06050: archivelog thread 1 sequence 328 is already on disk as file D:OracleORADATATESTARCHIVETESTT001S00328.ARC
RMAN-06050: archivelog thread 1 sequence 329 is already on disk as file D:OracleORADATATESTARCHIVETESTT001S00329.ARC
RMAN-06050: archivelog thread 1 sequence 330 is already on disk as file D:OracleORADATATESTARCHIVETESTT001S00330.ARC
RMAN-03023: executing command: recover(4)
RMAN-08515: archivelog filename=D:OracleORADATATESTARCHIVETESTT001S00327.ARC thread=1 sequence=327
RMAN-08515: archivelog filename=D:OracleORADATATESTARCHIVETESTT001S00328.ARC thread=1 sequence=328
RMAN-08055: media recovery complete
RMAN-03022: compiling command: sql
RMAN-06162: sql statement: alter database open
RMAN-03023: executing command: sql
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
RMAN>
7、 检查数据库的数据（完全恢复）
SQL> select * from test;
A
---------------------------------------
1
2
说明：
1、只要有备份与归档存在，RMAN也可以实现数据库的完全恢复（不丢失数据）;
2、同OS备份数据库恢复，适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复;
3、目标数据库在mount下进行，如果恢复成功，再打开数据库;
4、RMAN的备份与恢复命令相对比较简单并可靠，建议有条件的话，都采用RMAN进行数据库的备份，
4.4 不完全恢复案例
4.4.1 OS备份下的基于时间的恢复
不完全恢复可以分为基于时间的恢复，基于改变的恢复与基于撤消的恢复，这里已基于时间的恢复为例子来说明不完全恢复过程。
基于时间的恢复可以不完全恢复到现在时间之前的某一个时间，对于某些误操作，如删除了一个数据表，可以在备用恢复环境上恢复到表的删除时间之前，然后把该表导出到正式环境，避免一个人为的错误。
1、 连接数据库，创建测试表并插入记录:
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、 备份数据库，这里最好备份所有的数据文件，包括临时数据文件:
SQL> @hotbak.sql 或在DOS下 svrmgrl @hotbak.sql
或冷备份也可以
3、 删除测试表，假定删除前的时间为T1，在删除之前，便于测试，继续插入数据并应用到归
档。
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
Statement processed.
SQL> alter system switch logfile;
Statement processed.
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
TO_CHAR(SYSDATE,'YY
-------------------
2003-05-21 14:43:01
SQL> drop table test;
Table dropped.
4、 准备恢复到时间点T1，找回删除的表，先关闭数据库:
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down.
5、 拷贝刚才备份的所有数据文件回来
C:>copy D:DATABAK*.DBF D:OracleORADATATEST
6、 启动到mount下
SQL> startup mount;
Oracle instance started.
Total System Global Area 102020364 bytes
Fixed Size 70924 bytes
Variable Size 85487616 bytes
Database Buffers 16384000 bytes
Redo Buffers 77824 bytes
Database mounted.
7、 开始不完全恢复数据库到T1时间
SQL> recover database until time '2003-05-21:14:43:01';
ORA-00279: change 30944 generated at 05/21/2003 14:40:06 needed for thread 1
ORA-00289: suggestion : D:OracleORADATATESTARCHIVETESTT001S00191.ARC
ORA-00280: change 30944 for thread 1 is in sequence #191
Specify log: {
auto
Log applied.
Media recovery complete.
8、 打开数据库，检查数据
SQL> alter database open resetlogs;
Database altered.
SQL> select * from test;
A
---------------------------------------
1
2
说明：
1、不完全恢复最好备份所有的数据，冷备份亦可，因为恢复过程是从备份点往后恢复的，如果因为其中一个数据文件的时间戳(SCN)大于要恢复的时间点，那么恢复都是不可能成功的;
2、不完全恢复有三种方式，过程都一样，仅仅是recover命令有所不一样，这里用基于时间的恢复作为示例;
3、不完全恢复之后，都必须用resetlogs的方式打开数据库，建议马上再做一次全备份，因为resetlogs之后再用以前的备份恢复是很难了;
4、以上是在删除之前获得时间，但是实际应用中，很难知道删除之前的实际时间，但可以采用大致时间即可，或可以采用分析日志文件(logmnr)，取得精确的需要恢复的时间;
5、一般都是在测试机后备用机器上采用这种不完全恢复，恢复之后导出/导入被误删的表回生产系统.
4.4.2 RMAN备份下的基于改变的恢复
以上用OS备份说明了一个基于时间的恢复，现在用RMAN说明一个基于改变的恢复
1、 连接数据库，创建测试表并插入记录
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2、 备份数据库
C:>rman
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN> connect rcvcat rman/rman@back
RMAN-06008: connected to recovery catalog database
RMAN> connect target internal/virpure
RMAN-06005: connected to target database: TEST (DBID=874705288)
RMAN> run{
2> allocate channel c1 type disk;
3> backup full tag 'dbfull' format 'd:backupfull%u_%s_%p' database
4> include current controlfile;
5> sql 'alter system archive log current';
6> release channel c1;
7> }
//屏幕输出内容冗长，省略--编辑
RMAN>
3、 删除测试表，在删除之前，便于测试，继续插入数据并应用到归档，并获取删除前的scn号。
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
A
---------------------------------------
1
2
SQL> alter system switch logfile;
Statement processed.
SQL> alter system switch logfile;
Statement processed.
SQL> select max(ktuxescnw * power(2, 32) + ktuxescnb) scn from x$ktuxe;
SCN
----------
31014
SQL> drop table test;
Table dropped.
4、 准备恢复到SCN 31014，先关闭数据库，然后启动到mount下
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down.
SQL> startup mount;
5、 开始恢复到改变点SCN 31014
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> recover database until scn 31014;
5> sql 'ALTER DATABASE OPEN RESETLOGS';
6> release channel c1;
7> }
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=10 devtype=DISK
RMAN-03022: compiling command: restore
RMAN-03022: compiling command: IRESTORE
RMAN-03023: executing command: IRESTORE
RMAN-08016: channel c1: starting datafile backupset restore
RMAN-08502: set_count=1 set_stamp=494613682 creation_time=21-MAY-03
RMAN-08089: channel c1: specifying datafile(s) to restore from backup set
RMAN-08523: restoring datafile 00001 to D:OracleORADATATEST YSTEM01.DBF
RMAN-08523: restoring datafile 00002 to D:OracleORADATATESTRBS01.DBF
RMAN-08523: restoring datafile 00003 to D:OracleORADATATESTUSERS01.DBF
RMAN-08523: restoring datafile 00004 to D:OracleORADATATESTTEMP01.DBF
RMAN-08523: restoring datafile 00005 to D:OracleORADATATESTTOOLS01.DBF
RMAN-08523: restoring datafile 00006 to D:OracleORADATATESTINDX01.DBF
RMAN-08023: channel c1: restored backup piece 1
RMAN-08511: piece handle=D:BACKUPFULL01ENMD5I_1_1 tag=DBFULL params=NULL
RMAN-08024: channel c1: restore complete
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: recover
RMAN-03022: compiling command: recover(1)
RMAN-03022: compiling command: recover(2)
RMAN-03022: compiling command: recover(3)
RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-03022: compiling command: recover(4)
RMAN-06050: archivelog thread 1 sequence 191 is already on disk as file D:ORACL
EORADATATESTARCHIVETESTT001S00191.ARC
RMAN-06050: archivelog thread 1 sequence 192 is already on disk as file D:ORACL
EORADATATESTARCHIVETESTT001S00192.ARC
RMAN-03023: executing command: recover(4)
RMAN-08515: archivelog filename=D:OracleORADATATESTARCHIVETESTT001S00191.AR
C thread=1 sequence=191
RMAN-08515:archivelog filename=D:OracleORADATATESTARCHIVETESTT001S00192.ARC
Thread=1 sequence=192
RMAN-08055: media recovery complete
RMAN-03022: compiling command: sql
RMAN-06162: sql statement: ALTER DATABASE OPEN RESETLOGS
RMAN-03023: executing command: sql
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
6、 检查数据
Database altered.
SQL> select * from test;
A
---------------------------------------
1
2
可以看到，表依然存在。
说明：
1、 RMAN也可以实现不完全恢复，方法比OS备份恢复的方法更简单可靠；
2、 RMAN可以基于时间，基于改变与基于日志序列的不完全恢复，基于日志序列的恢复可以指定恢复到哪个日志序列，如
run {
allocate channel ch1 type disk;
allocate channel ch2 type 'sbt_tape';
set until logseq 1234 thread 1;
restore controlfile to '$Oracle_HOME/dbs/cf1.f' ;
replicate controlfile from '$Oracle_HOME/dbs/cf1.f';
alter database mount;
restore database;
recover database;
sql “ALTER DATABASE OPEN RESETLOGS”;
}
3、 与所有的不完全恢复一样，必须在mount下，restore所有备份数据文件，需要resetlogs；
4、 基于改变的恢复比基于时间的恢复更可靠，但是可能也更复杂，需要知道需要恢复到哪一个改变号(SCN)，在正常生产中，获取SCN的办法其实也有很多，如查询数据库字典表(V$archived_log or v$log_history)，或分析归档与联机日志(logmnr)等。
第五章 其它恢复案例
5.1 损坏联机日志的恢复方法
5.1.1 损坏非当前联机日志
大家都清楚，联机日志分为当前联机日志和非当前联机日志，非当前联机日志的损坏是比较简单的，一般通过clear命令就可以解决问题。
1、启动数据库，遇到ORA-00312 or ORA-00313错误，如
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:OracleORADATATESTREDO01.LOG'
从这里我们知道日志组1的数据文件损坏了
从报警文件可以看到更详细的信息
2、 查看V$log视图
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 YES INACTIVE
2 2 YES INACTIVE
3 3 NO CURRENT
可以知道，该组是非当前状态，而且已经归档。
3、 用CLEAR命令重建该日志文件
SQL>alter database clear logfile group 1;
如果是该日志组还没有归档，则需要用
SQL>alter database clear unarchived logfile group 1;
4、 打开数据库，重新备份数据库
SQL>alter database open;
说明：
1、如果损坏的是非当前的联机日志文件，一般只需要clear就可以重建该日志文件，但是如果该数据库处于归档状态但该日志还没有归档，就需要强行clear；
2、建议clear，特别是强行clear后作一次数据库的全备份；
3、此方法适用于归档与非归档数据库。
5.1.2 损坏当前联机日志
归档模式下当前日志的损坏有两种情况，
一、是数据库是正常关闭，日志文件中没有未决的事务需要实例恢复，当前日志组的损 坏就可以直接用alter database clear unarchived logfile group n来重建。
二、是日志组中有活动的事务，数据库需要媒体恢复，日志组需要用来同步，有两种补救办法:
A. 最好的办法就是通过不完全恢复，可以保证数据库的一致性，但是这种办法要求在归档方式下，并且有可用的备份
B. 通过强制性恢复，但是可能导致数据库不一致。
下面分别用来说明这两种恢复方法：
5.1.2.1 通过备份来恢复
1、 打开数据库，会遇到一个类似的错误
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:OracleORADATATESTREDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件
2、 查看V$log，发现是当前日志
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
--------- ---------- -------- ----------------
1 1 NO CURRENT
2 2 YES INACTIVE
3 3 YES INACTIVE
3、 发现clear不成功
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:OracleORADATATESTREDO01.LOG'
4、 拷贝有效的数据库的全备份，并不完全恢复数据库：
可以采用获取最近的SCN的办法用until scn恢复或用until cnacel恢复
recover database until cancel
先选择auto，尽量恢复可以利用的归档日志，然后重新
recover database until cancel
这次输入cancel，完成不完全恢复，也就是说恢复两次。
如：
SQL> recover database until cancel;
Auto
……
SQL> recover database until cancel;
Cancel;
5、 利用alter database open resetlogs打开数据库.
说明：
1、这种办法恢复的数据库是一致的不完全恢复，会丢失当前联机日志中的事务数据;
2、这种方法适合于归档数据库并且有可用的数据库全备份;
3、恢复成功之后，记得再做一次数据库的全备份;
4、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。
5.1.2.2 如果没有备份，进行强制性恢复
1、 打开数据库，会遇到一个类似的错误
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:OracleORADATATESTREDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件
2、 查看V$log，发现是当前日志
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 NO CURRENT
2 2 YES INACTIVE
3 3 YES INACTIVE
3、 发现clear不成功
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:OracleORADATATESTREDO01.LOG'
4、 把数据库down掉
SQL>shutdown immediate
5、 在init
_allow_resetlogs_corruption=TRUE
6、 重新启动数据库,利用until cancel恢复
SQL>recover database until cancel;
Cancel
如果出错，不再理会，发出
SQL>alter database open resetlogs;
7、 数据库被打开后，马上执行一个full export
8、 shutdown数据库,去掉_all_resetlogs_corrupt参数
9、 重建库
10、import并完成恢复
11、建议执行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;
说明：
1、该恢复方法是没有办法之后的恢复方法，一般情况下建议不要采用，因为该方法可能导致数据库的不一致；
2、该方法也丢失数据，但是丢失的数据没有上一种方法的数据多，主要是未写入数据文件的已提交或未提交数据；
3、建议成功后严格执行以上的7到11步，完成数据库的检查与分析；
4、全部完成后做一次数据库的全备份；
5、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。
5.2 损坏控制文件的恢复方法
5.2.1 损坏单个控制文件
损坏单个控制文件是比较容易恢复的，因为一般的数据库系统，控制文件都不是一个，而且所有的控制文件都互为镜相，只要拷贝一个好的控制文件替换坏的控制文件就可以了。
1、 控制文件损坏，最典型的就是启动数据库出错，不能mount数据库
SQL>startup
ORA-00205: error in identifying controlfile, check alert log for more info
查看报警日志文件，有如下信息
alter database mount
Mon May 26 11:59:52 2003
ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
2、 停止数据库：
SQL>shutdown immediate
3、 拷贝一个好的控制文件替换坏的控制文件或修改init.ora中的控制文件参数，取消这个坏的控制文件。
4、 重新启动数据：
SQL>startup
说明：
1、损失单个控制文件是比较简单的，因为数据库中所有的控制文件都是镜相的，只需要简单的
拷贝一个好的就可以了；
2、建议镜相控制文件在不同的磁盘上；
3、建议多做控制文件的备份，长期保留一份由alter database backup control file to trace产生的控制文件的文本备份。
5.2.2 损坏全部控制文件
损坏多个控制文件，或者人为的删除了所有的控制文件，通过控制文件的复制已经不能解决问题，这个时候需要重新建立控制文件。
同时注意，alter database backup control file to trace可以产生一个控制文件的文本备份。
以下是详细重新创建控制文件的步骤：
1、 关闭数据库
SQL>shutdown immediate;
2、 删除所有控制文件，模拟控制文件的丢失
3、 启动数据库，出现错误，并不能启动到mount下
SQL>startup
ORA-00205: error in identifying controlfile, check alert log for more info
查看报警日志文件，有如下信息
alter database mount
Mon May 26 11:53:15 2003
ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
4、 关闭数据库
SQL>shutdown immediate;
5、 在internal或sys下运行如下创建控制文件的脚本，注意完整列出联机日志或数据文件的路径，或修改由alter database backup control file to trace备份控制文件时产生的脚本，去掉多余的注释即可。
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE “TEST” NORESETLOGS NOARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 254
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 'D:OracleORADATATESTREDO01.LOG' SIZE 1M,
GROUP 2 'D:OracleORADATATESTREDO02.LOG' SIZE 1M,
GROUP 3 'D:OracleORADATATESTREDO03.LOG' SIZE 1M
DATAFILE
'D:OracleORADATATEST YSTEM01.DBF',
'D:OracleORADATATESTRBS01.DBF',
'D:OracleORADATATESTUSERS01.DBF',
'D:OracleORADATATESTTEMP01.DBF',
'D:OracleORADATATESTTOOLS01.DBF',
'D:OracleORADATATESTINDX01.DBF'
CHARACTER SET ZHS16GBK;
-- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
RECOVER DATABASE
--if the last shutdown was not normal or immediate
--noarchive
-- RECOVER DATABASE UNTIL CANCELUSING BACKUP CONTROLFILE
--archive
-- RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
-- Database can now be opened normally.
ALTER DATABASE OPEN;
--if recover database until cancel
--ALTER DATABASE OPEN RESETLOGS;
6、 如果没有错误，数据库将启动到open状态下。
说明：
1、重建控制文件用于恢复全部数据文件的损坏，需要注意其书写的正确性，保证包含了所有的数据文件与联机日志；
2、经常有这样一种情况，因为一个磁盘损坏，我们不能再恢复(store)数据文件到这个磁盘，因此在store到另外一个盘的时候，我们就必须重新创建控制文件，用于识别这个新的数据文件，这里也可以用这种方法用于恢复。
5.3 损坏回滚数据文件的恢复方法
回滚段表空间中的一个数据文件丢失或者损坏导致数据库无法识别它，在启动数据库的时候会出现ORA-1157, ORA-1110的错误，或者操作系统级别的错误，例如ORA-7360。在关闭数据库的时候(normal或者immediate)会出现ORA-1116, ORA-1110的错误，或者操作系统级别的错误，例如ORA-7368。
感谢Coolyl的辛勤工作，关于回滚段的大部分内容都是摘自他在itpub的文章。
5.3.1 损坏数据文件，但数据库处于Open状态
如果你发现有回滚段的数据文件丢失或者损坏了，而此时的数据库是处于打开的状态下并且在运行，就千万不要关闭数据库了，因为在大多数的情况下打开的时候比关闭的时候好解决问题一些。
一般也是存在有两种情况：
A、是offline丢失或损坏的数据文件，然后从一个备份中恢复，执行介质恢复以保持一致性。但是这种情况要求数据库是归档方式下才可以采用的。
B、是offline那个存在丢失或损坏的数据文件所在的整个回滚段表空间，然后删除整个回滚段表空间并重建，但是你必须要杀掉那些在回滚段中已经激活的用户进程才可以offline的。
通常第一种情况就比较简单实现，但是更多的用户事务将会出错并且回滚。
A的具体步骤：
1、 offline丢失或损坏的数据文件
ALTER DATABASE DATAFILE '
2、 从一个有效的备份中恢复。
3、 执行以下查询：
SELECT V1.GROUP#, MEMBER, SEQUENCE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# ;
这个将列出你的所有redolog文件以及它们所代表的sequence numbers。
4、 恢复数据文件。
RECOVER DATAFILE '
5、 确信你应用了所有的redolog文件，直至出现提示信息“Media recovery complete”。
6、 online那个数据文件。
ALTER DATABASE DATAFILE '
B的具体步骤：
1、 offline存在丢失或损坏的数据文件的回滚段表空间中的所有回滚段。
ALTER ROLLBACK SEGMENT
2、 检测当然回滚段的状态。
SELECT SEGMENT_NAME, STATUS FROM DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME = '';
3、 删除所有offline的回滚段
DROP ROLLBACK SEGMENT
4、 处理那些online状态的回滚段。
重新执行第二步的查询
如果你已经执行过offline操作的回滚段状态仍然是online，则说明这个回滚段内有活动的事务。你要接着查询
SELECT SEGMENT_NAME, XACTS ACTIVE_TX, V.STATUS
FROM V$ROLLSTAT V, DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME = '' AND SEGMENT_ID = USN;
如果没有返回结果，则证明存在丢失或损坏的数据文件的回滚段表空间中的所有回滚段都已经被offline了，然后重新执行第二步，第三步。如果查询有结果返回，则状态应该是“PENDING OFFLINE”.接着查看ACTIVE_TX列，如果值为0，则表明此回滚段中已经没有未处理的事务了，很快就会被offline的，然后等它offline后重新执行2，3步后跳至第六步。如果值大于0，则继续到第五步。
5、 强制那些包含活动事务的回滚段offline。
活动的事务应该被提交或者回滚，执行下面的查询看看哪些用户占用了回滚段：
SELECT S.SID, S.SERIAL#, S.USERNAME, R.NAME “ROLLBACK”
FROM V$SESSION S, V$TRANSACTION T, V$ROLLNAME R
WHERE R.NAME IN ('
', ... ,
'
')
AND S.TADDR = T.ADDR AND T.XIDUSN = R.USN;
最好能直接联系到那些user让他们自己去回滚或者提交事务，如果不能做到的话，那就只能强制性的杀掉进程了。
ALTER SYSTEM KILL SESSION '
杀掉进程后再过一段时间后回滚段会自动清除那些事务，然后就可以回到第二步继续查询了。
6、 删除回滚段。
DROP TABLESPACE INCLUDING CONTENTS;
7、 重建回滚段并online它们。
说明：
1、数据库如果是open状态，就可以直接在open状态下解决问题，没有必要停下数据库，增加down机时间；
2、不管上上面那种恢复方法都是正常性的恢复，不会引起数据的不一致或错误。
5.3.2数据库关闭，但是数据文件中没有活动事务
这种情况下最简单的方法就是offline drop掉这个坏了的或者丢失的数据文件，然后以restricted模式打开数据库然后删除并且重建包含损坏文件的回滚段表空间。
具体步骤如下：
1、 确定数据库是正常的关闭的。方法是可以去查看alert文件，到最后看是否有如下信息：
“alter database dismount
Completed: alter database dismount”
如果有的话，就证明数据库是正常关闭的，否则就不能用这个方法去恢复。
2、 修改init参数文件，移去ROLLBACK_SEGMENTS中包含的损坏数据文件的回滚段表空间的回滚段，如果你不能确定哪些回滚段是坏的，简单的方法是你可以注释掉整个ROLLBACK_SEGMENTS。
3、 以restricted模式去mount数据库。
STARTUP RESTRICT MOUNT
4、 offline drop掉那个坏的数据文件
ALTER DATABASE DATAFILE '
5、 打开数据库
ALTER DATABASE OPEN
如果你看到如下信息“Statement processed”，则跳到第7步，如果你看到ORA-604, ORA-376, and ORA-1110的错误信息，继续第6步。
6、 正常的关闭数据库，然后在init文件中注释掉ROLLBACK_SEGMENTS，并加入隐含参数
_corrupted_rollback_segments = (
然后以restricted模式打开数据库
STARTUP RESTRICT
7、 删除掉那个包含损坏文件的回滚段表空间。
DROP TABLESPACE INCLUDING CONTENTS;
8、 重建回滚段表空间，记得创建后要把回滚段都online。
9、 重新使数据库对所有用户可用。
ALTER SYSTEM DISABLE RESTRICTED SESSION;
10、然后正常关闭数据库，修改init文件，如果开始只是注释掉了ROLLBACK_SEGMENTS的，就去掉注释即可，如果加了隐含参数的，注释掉它，并在ROLLBACK_SEGMENTS加入所有的回滚段。
11、正常启动数据库：
Startup
说明：
1、这种方法的前提条件是数据库是正常关闭（不是abort）可用；
2、这种方法是正常方法，不会引起数据错误。
5.3.3 数据库关闭，数据文件中有活动事务，没有可用备份。
一般造成这种原因的情况是采用了shutdown abort或其它原因异常关机（如断电）导致的。
1、开启一个事务
SQL> set transaction use rollback segment rbs0;
Transaction set.
SQL> insert into test (a) values (1);
1 row created.
2、异常关闭
SQL> shutdown abort;
Oracle instance shut down.
3、删除rbs的一个数据文件
C:>del D:Oracleoradatachenrbs01.
4、修改INIT
rollback_segments=(system)
添加_corrupted_rollback_segments=(rbs0,rbs1,rbs2……)
5、SQL>Startup mount
6、SQL>alter database datafile 'd:Oracleoradatat8irbs01.dbf' offline drop;
数据库已更改。
7、SQL>recover database ；
完成介质恢复。
8、SQL>alter database open ;
数据库已更改。
9、SQL>select * from v$rollname;
USN NAME
---- -------
0 SYSTEM
10、SQL>select segment_name,tablespace_name,status
FROM dba_rollback_segs;
SEGMENT_NAME TABLESPACE_NAME STATUS
----------- ------ ------------------------------------
SYSTEM SYSTEM ONLINE
RBS0 RBS NEEDS RECOVERY
RBS1 RBS NEEDS RECOVERY
RBS2 RBS NEEDS RECOVERY
11、SQL>drop rollback segment rbs0;
重算段已丢弃。
SQL>drop rollback segment rbs1;
重算段已丢弃。
SQL>drop rollback segment rbs2;
重算段已丢弃。
12、SQL>select segment_name,tablespace_name,status
FROM dba_rollback_segs;
SEGMENT_NAME TABLESPACE_NAME STATUS
-------------------------------------
SYSTEM SYSTEM ONLINE
13、SQL>drop tablespace rbs including contents;
表空间已丢弃。
14、重建新的回滚表空间及回滚段，并联机。
15、SQL>shutdown abort
16、再修改INIT
rollback_segments=(rbs0,rbs1,rbs2)
将_corrupted_rollback_segments=(rbs0,rbs1,rbs2)去掉。
17、SQL>startup
说明：
1、这种办法是万不得以的时候使用的方法，如果有备份，都建议从备份上进行恢复；
2、这种方法恢复的数据库，可能会引起数据库的数据错误；
3、恢复成功以后，建议exp/imp数据，并重新分析检查数据库。
5.3.4 数据库关闭，数据文件中有活动事务，从备份恢复
1、从一个有效的备份中恢复损坏的数据文件。
2、mount数据库。
3、执行以下查询：
SELECT FILE#, NAME, STATUS FROM V$DATAFILE;
如果发现要恢复的文件是offline状态的话，要先online它：
ALTER DATABASE DATAFILE '
4、执行以下查询
SELECT V1.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP# ;
这个将列出redlog文件所代表的sequence和first change numbers。
5、如果数据库是非归档情况下，执行以下查询：
SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;
如果CHANGE#大于最小的redolog文件的FIRST_CHANGE#，则数据文件可以被恢复，记得在应用日志的时候要把所有redolog文件全部应用一遍。
如果CHANGE#小于最小的redolog文件的FIRST_CHANGE#，则数据文件就不可以被恢复了，这时候你要从一个有效的全备份中去恢复数据库了，如果没有全备份的话，那你就只能把数据库强制打开到一个不一致的状态去exp出数据，然后重新建库导入数据，因为这种方式的恢复Oracle是不推荐用户自己做的，所以这里我就不详细说明了。
6、恢复数据文件：
RECOVER DATAFILE '
7、确信你应用了所有的redolog文件，直至出现提示信息“Media recovery complete”。
8、打开数据库。
说明：
1、这种方法要求在归档有备份的方式下进行，而且是建议方式；
2、这种方法不会导致数据库的错误。
5.4 损坏临时数据文件的恢复方法
临时数据文件的恢复是比较简单的，因为临时文件中不涉及到其它的有用的数据，所以可以删除后重建。
1、关闭数据库：
SQL>shutdown immediate
2、删除临时数据文件，模拟媒体失败；
3、启动数据库，检测到文件错误；
4、脱机该数据文件：
SQL>alter database datafile '文件名全名' offline drop;
5、打开数据库
SQL>alter database open
6、删除该临时表空间
SQL>drop tablespace temp(或其它临时表空间名称);
7、重新创建该表空间，并重新分配给用户。
说明：
1、临时数据文件是非重要文件，不保存永久数据，可以随时删除重建，不影响数据库的数据安全；
2、如果重新建立以后，别忘了重新分配给用户。
第六章. 常见恢复误区
1、可以不需要备份，只有归档就能进行数据库的向前的恢复
答：这个在Oracle 9i以前起码是不可能的，在别的数据库我也没有听说过，不完全恢复的主要思路是利用不完全点之前的备份，加上归档日志，恢复到不完全恢复点，9i中出现了一个flashback的特性，这个特性的使用，也是有很多局限的。
2、进行不完全恢复只需要拷贝一个需要恢复的备份数据文件
答：不完全恢复需要拷贝所有的数据文件，最好包括临时数据文件在内，否则需要另外的处理，如果有一个数据文件的SCN大于不完全恢复点，那么这个恢复都将是失败的。
3、使用RMAN目录与目标数据库在同一数据库能很好进行数据库的恢复
答：使用恢复目录与目标数据库在同一个数据库中，将存在很大的恢复局限，如该数据库的系统数据文件的损害，数据库根本不能open，那么RMAN也就无法连接恢复目录，也就不存在恢复了。
第七章. 小结
这里我们反复演示了多种情况下的恢复方案，通过这些演示，我们应该掌握了如下内容：
1、利用OS与RMAN进行各种常规备份与恢复。
2、熟悉没有备份或简单的非常规备份与恢复的方法。
金融篇：
“微码营销”已经不仅仅是中国本土数据库营销翘楚,北京世纪微码营销咨询有限公司的简称，而是中国本土数据库营销技术和市场推广手段的缩影，“微码营销”已经被越来越多的金融企业所采用，
数据库营销案例
。
“微码营销”走俏金融业 作者：武文斌
传统营销手段对市场的驱动越来越有限，追求领先的企业需要新的营销动力。微码营销（MicroMarketing）公司通过数据库营销和直复营销,帮助思科、甲骨文、德国宝马、中国网通、美国EMC公司、中国惠普等著名公司开发并获取更多的新客户等方面立下了汗马功劳。目前“微码营销”已经不仅仅是中国本土数据库营销翘楚,北京世纪微码营销咨询有限公司的简称（，）而是中国本土数据库营销技术和市场推广手段的缩影，“微码营销”已经逐步突破IT、电信、医疗、汽车、零售、医疗、教育等领域，在金融行业中也大受欢迎。
银行业呼唤数据库营销
银行业是中国对外开放的最后几个行业之一，随着WTO协议里中国金融业开放时间表的临近，银行业的竞争日趋激烈。外资银行和国内的新兴银行在中国的市场渠道、网点和客户数量相对于传统四大商业银行来说常处于被动地位，但是数据库营销的兴起却使这些创新型，新技术型的新银行找到了一种以小博大的营销制胜术。
民生银行是一家国内民营股份制商业银行。由于监管机构实行的8％资本充足率的要求，银行正在积极地通过加大对个人金融理财服务的投入力度来吸纳更多的优质存款，获取更多利润，以增加自有资本金量。但是民生银行在全国的高收入潜在客户资料有限，网点和渠道缺乏。为了实现个人银行业务的扩张，借助专业的数据库营销公司的力量成为其以小博大的一种手段。最终，民生银行把覆盖大约100000个目标客户，并在一年时间内发展出500个以上的合格客户的任务落实到了中国本土领先的专业数据库营销公司――微码营销身上。
“微码营销”项目小组立即成立，并很快为民生银行将目标锁定在目前国内年收入在10万元以上，平均年龄在28岁以上的高收入人群。最终，微码营销通过对其企业客户数据库的查询和分析以及市场搜寻建立了10万目标客户名单。通过对直邮广告的内容设计和创意把握及DM、EDM等沟通途径传递民生理财服务的特点，继而通过外呼电话与目标客户进行沟通，该个人理财项目总体反馈率达到了13％，并产生了数千销售机会。而这在以前是根本不敢想象的，然而民生银行的个人理财业务借“微码营销”插上翅膀。
除个人理财业务推广之外其实数据库营销的拓展也延伸到了信用卡推广、设立分行等具体业务中。万事达（Mastercard）选中“微码营销”就是一个典型的例子。
作为世界级的信用卡巨头万事达虽然在其它国家势如破竹，但在中国却遇到了消费者刷卡频率及消费额度还非常低的困境。此时，“微码营销”的进入给万事达卡带来了改变现状的希望。”微码营销”为此策划针对消费者的抽奖活动，在活动期间凡使用万事达卡进行刷卡消费者都可通过短信方式或者网站提交刷卡信息，参加抽奖。活动期间，该网站日浏览量最高可达1万,总计有近十万消费者参与了本次活动。
目前，许多外资银行及国内的新兴银行，如招商银行、民生银行、花旗银行、汇丰银行等一大批银行已经逐渐把数据库营销作为与其它银行和竞争对手争夺市场和客户的新利器，而“微码营销”更是成为银行首选的战略合作伙伴。
保险公司借力“微码营销”
保险公司也不甘寂寞。在对金融业客户维护和推广产生革命性影响的“微码营销”也被带进“汽车保险的大门”。
D保险公司，是国内一家中型保险企业，汽车保险是他的主营业务，
近一两年，在国内车市蓬勃发展，一路高歌的大环境下，D公司的业绩却一直平平，甚至出现下滑的现象。客户量很难取得明显突破，营业额停滞不前，市场投入一再增加，但始终效果甚微，公司上下显得一筹莫展。
采用数据库营销的战略方式，能否让D公司的这种状态得以改观？微码营销公司帮D公司解答了这个问题。微码营销公司经过营销战略咨询专家对D公司进行了缜密的研究，发现D公司存在1，争取新客户的手段单一，不易控制管理2，获取客户成本高，客户流失严重，难以维护3，无法界定出黄金客户4，公司过度依赖代理人，但没有有效的激励管理等4个主要问题。
寻找黄金客户成为“微码营销”帮助D保险公司首要目标。当专业并完善的数据库建立起来后，寻找黄金客户的困难就迎刃而解了。在微码营销公司的建议和帮助下，D公司采用计算客户时间价值的方法来衡量每个客户的重要性。最后在D公司的客户群中，客户价值较高，处于前15%的客户群被视为黄金级别客户。微码营销公司利用自己的电话营销中心，对这些黄金客户进行了电话访问。通过建立VIP俱乐部网站，以E-mail、直邮等方式与客户保持持续有效的沟通，D公司的黄金客户不但保留下来而且还增强了忠诚度。
保留黄金客户与开拓新市场双管齐下成为微码营销公司与D保险公司一致共识。而新客户的来源主要分为两类，从未买过车险的客户与从其他竞争对手流失的客户。
在微码营销公司的策略中两类客户是区别对待的。对从未买过车险的客户，是从所有潜在客户中，甄选出的从未买过汽车保险的人群，以近期内购买汽车的人群为主要目标。微码营销公司抓住了这一人群对汽车的关注，帮助D公司设计了一整套活动方案。借助北京国际汽车展的大力宣传，在车展前举办了“免费赢车展门票――汽车保险知识竞答”活动，收效显著。
D保险公司最后一道难题是保险代理人的管理和激励，为了有效地管理代理人微码营销设立了“代理人俱乐部”，使得D公司对代理人依赖严重的问题有了很大改观。
同样是利用网络的资源，微码营销公司为D公司量身定制了一个专门的保险代理人管理网站系统。代理人俱乐部的网站包含几个主要栏目。1. 最新保险行业资讯2. D公司保险产品推介（。）3. D公司最新活动公告4. D公司宣传资料库5. 客户资料查询6. 客户沟通活动报告7. D公司精英代理人。网站开通后，D公司分配给每个保险代理人一个专用的用户名密码，并对他的1000多位代理人进行了分期分批的培训，将代理人参与俱乐部的活动与业绩评估紧密结合，不但有效地激励了代理人的积极性，而且解决了对代理人管理困难的问题。
短短一年的时间，数据库营销战略为推动D公司的整体发展，充分地发挥出了它神奇的功效，D公司的汽车保险业务市场份额从8%猛增到了19%，成为了业内增长最快的佼佼者。更多的保险公司也竞相模仿，“微码营销”一时悄然走俏在众多保险公司中。
“微码营销”走俏金融企业
“微码营销”在众多金融企业中受欢迎来源于数据库营销在中国的兴起。在海外，诸如花旗银行、第一波士顿银行、汇丰等世界级金融机构运用数据库营销进行客户开发，维护已经数载并获得了丰硕成果。在国内，许多新兴银行和保险公司和有远见的金融企业也迫不及待抓住这一改写金融业格局的营销利器，纷纷与中国本土数据库营销翘楚 ―― 微码营销公司合作进行新世纪的营销革命。
正如微码营销总裁费建平先生所说，“直复营销更多研究的是客户沟通的手段，客户关系管理更多的是一种理念，而数据库营销将这种理念和营销技术落到实处。”
通过数据库营销和直复营销，微码营销（MicroMarketing）可以帮助金融企业开发并获取更多的新客户，也可以帮助企业提升老客户的忠诚度。综合利用电话营销、Email营销、反馈式直邮、网上营销等直接沟通手段，帮助客户建立客户数据库并管理相关客户信息，实现销售机会挖掘，产品促销推广，客户保留，经销商关系维护等营销目标。
约束条件就是Oracle数据库系统提供的对数据的完整性进行制约的机制，
Oracle 9i 约束条件数据库教程
。Oracle 9i允许创建5种约束条件。参见表7.8。创建检查约束条件
（1）在【管理目标导航器】中按照7.6节修改数据表结构的步骤进行操作。
（2）切换到图7.61所示的编辑表的【约束条件】选项卡。
（3）上述创建检查约束条件的SQL码如下?br> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
ALTER TABLE “SCOTT”.“STUDENT”
ADD (CONSTRAINT “研究生编号检查约束条件”
CHECK(student_id>=20020101 and student_id<=20030909))
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
【参见光盘文件】：第7章 createcheck.sql。
（4）读者也可以直接在【SQLPlus Worksheet】中执行createcheck.sql 文件完成检查约束条件的创建，如图7.62所示，
测试检查约束条件
（1）在7.63所示的【表数据编辑器】界面中按照图示内容输入，单击“应用(P)”按钮。
（2）上述输入数据的SQL代码如下。
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
INSERT INTO “SCOTT”.“STUDENT”
(“STUDENT_ID” ,“NAME” ,“PROFESSIONAL” ,“BIRTHDAY” ,“DIRECTOR_ID” )
VALUES (20010101 ,'纪晓芙' ,'软件工程' ,TO_DATE('15-7月 -1971', 'dd-Mon-yyyy HH:MI:SS AM') ,200201)
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
【参见光盘文件】：第7章 testcheck.sql。
（3）出现如图7.64所示界面。
（4）读者也可以直接在【SQLPlus Worksheet】中执行testcheck.sql 文件完成检查约束条件的测试，结果如图7.65所示。
