1.3 使用模板创建数据库
前面提到,除了定制数据库之外,还可以使用模板来创建数据库,接下来就让我们一起来了解一下使用模板创建数据库的过程。
1.3.1 启动创建
在1.1节中我们提到可以通过命令行启动DBCA工具,可能更多的朋友是通过"开始"菜单中Oracle创建的快捷项里来启动DBCA的,如图1-20所示。

从这个快捷项的属性对话框中,可以看到如图1-21所示的内容:
这个快捷项的目标执行的是以下命令:
C:\\Oracle\\10.2.0\\BIN\\launch.exe C:\\oracle\\10.2.0\\assistants\\dbca dbca.cl
此处的dbca.cl文件和前面的dbca.bat批处理文件执行的功能是一致的:
那么DBCA为什么指向这个目录呢?这个目录又是做什么用的呢?
实际上这个目录是Oracle的缺省模板目录,当我们使用模板来创建数据库时,就用到了这个目录下的文件。
1.3.2 数据库创建模板
下面来看一下使用模板创建数据库的过程。
使用模板和前面的过程主要不同之处在于第二个步骤,在这里选择"定制数据库"之外的选项,就都使用了模板,并且包含了数据文件(eygle模板是我们之前保存的),如图1-22所示。
使用模板创建数据库通常速度都会很快,原因就在于数据文件是从种子数据库中恢复出来的,而不需要创建文件及字典对象等信息。
这里通过脚本说明一下通过模板创建数据库和定制数据库的不同。
首先eygle.sql脚本记录如下内容:
该脚本首先调用的是CloneRmanRestore.sql脚本,该脚本记录如下内容:
这个脚本首先启动实例到Nomount模式,然后调用rmanRestoreDatafiles.sql来恢复文件。
1.3.3 Rman的引入
rmanRestoreDatafiles.sql脚本是通过系统包dbms_backup_restore来恢复备份集中的文件,从而实现数据恢复,其主要内容如下:
关于RMAN的有关知识,我们会在后面的章节详细介绍,但是关于dbms_backup_restore包这里有必要提前介绍一下。
当通过RMAN进行数据库备份时,RMAN会将多个数据文件写出到一个或多个备份文件(称为备份集)中,RMAN的相关的备份信息或者存储在控制文件中,或者存储在RMAN的专用目录数据库(Catalog)中,如果RMAN的备份信息丢失,那么通常备份集中的文件是没有办法读取出来的,其他工具无法识别RMAN的备份集文件;而dbms_backup_restore就是针对这种情况提供的一种解决方案,dbms_backup_restore可以在数据库nomount状态下调用,直接从备份集中读取数据文件,功能十分强大。
DBMS_BACKUP_RESTORE包由dbmsbkrs.sql和prvtbkrs.plb这两个脚本创建,创建数据库时执行的catproc.sql 脚本会调用这两个脚本以创建包,这些脚本文件可以在$ORACLE_HOME/rdbms/admin目录下找到,脚本文件中对包的内容有详细的介绍。
下面通过具体的例子来介绍一下这个工具的用法,以下是一次真实的恢复案例,由于控制文件丢失,只能通过DBMS_BACKUP_RESTORE包从备份集中恢复数据文件,当然恢复之前我们需要知道一些数据库的相关信息,了解备份集中包含了哪些文件。
首先启动数据库到nomount状态:
然后可以执行脚本,将数据文件恢复到指定目录:
至此,从备份集中读取文件完毕,但是由于没有控制文件,就需要重建一个控制文件用于恢复,创建控制文件的脚本可以自己根据经验编写,也可以根据备份的文本进行修改,当然也可以从其他数据库中转储一个控制文件脚本,仿照改写。
正常情况下,可以通过如下的命令将控制文件的创建语句转储到跟踪文件中(位于udump目录中):
可以找到trace文件,编辑、执行重建控制文件的需要部分:
如果存在部分归档日志,创建控制文件之后可以执行恢复:
恢复到最后可用日志后,通过resetlogs方式打开数据库:
至此恢复完成。
这是一次常规恢复,dbms_backup_restore的功能远不止于此,还可以通过该包恢复备份集中的控制文件、归档日志等文件等。
继续前面的讨论,rmanRestoreDatafiles.sql脚本通过dbms_backup_restore包从种子文件Seed_Database.dfb恢复出数据文件,来看一下模板目录中存放的模板和种子数据库(自定义的模板也存放在这个目录中):
Seed_Database.dfb文件就是包含种子文件的一个备份集。
前面提到,除了定制数据库之外,还可以使用模板来创建数据库,接下来就让我们一起来了解一下使用模板创建数据库的过程。
1.3.1 启动创建
在1.1节中我们提到可以通过命令行启动DBCA工具,可能更多的朋友是通过"开始"菜单中Oracle创建的快捷项里来启动DBCA的,如图1-20所示。

从这个快捷项的属性对话框中,可以看到如图1-21所示的内容:

这个快捷项的目标执行的是以下命令:
C:\\Oracle\\10.2.0\\BIN\\launch.exe C:\\oracle\\10.2.0\\assistants\\dbca dbca.cl
此处的dbca.cl文件和前面的dbca.bat批处理文件执行的功能是一致的:
Command=("C:\\oracle\\10.2.0\\jdk\\jre\\BIN\\JAVA" -Dsun.java2d.font.DisableAlgorithmicStyles=true
-DORACLE_HOME="C:\\oracle\\10.2.0" -DJDBC_PROTOCOL=thin
-mx128m -classpath .....OraInstaller.jar" oracle.sysman.assistants.dbca.Dbca)
那么DBCA为什么指向这个目录呢?这个目录又是做什么用的呢?
实际上这个目录是Oracle的缺省模板目录,当我们使用模板来创建数据库时,就用到了这个目录下的文件。
1.3.2 数据库创建模板
下面来看一下使用模板创建数据库的过程。
使用模板和前面的过程主要不同之处在于第二个步骤,在这里选择"定制数据库"之外的选项,就都使用了模板,并且包含了数据文件(eygle模板是我们之前保存的),如图1-22所示。

使用模板创建数据库通常速度都会很快,原因就在于数据文件是从种子数据库中恢复出来的,而不需要创建文件及字典对象等信息。
这里通过脚本说明一下通过模板创建数据库和定制数据库的不同。
首先eygle.sql脚本记录如下内容:
......
host C:\\oracle\\10.2.0\\bin\\orapwd.exe
file=C:\\oracle\\10.2.0\\database\\PWDeygle.ora password=&&sysPassword force=y
@C:\\oracle\\admin\\eygle\\scripts\\CloneRmanRestore.sql
@C:\\oracle\\admin\\eygle\\scripts\\cloneDBCreation.sql
@C:\\oracle\\admin\\eygle\\scripts\\postScripts.sql
host "echo SPFILE='C:\\oracle\\10.2.0/dbs/spfileeygle.ora'
> C:\\oracle\\10.2.0\\database\\initeygle.ora"
@C:\\oracle\\admin\\eygle\\scripts\\postDBCreation.sql
该脚本首先调用的是CloneRmanRestore.sql脚本,该脚本记录如下内容:
C:\\Oracle\\admin\\eygle\\scripts>type CloneRmanRestore.sql
connect "SYS"/"&&sysPassword" as SYSDBA
set echo on
spool C:\\oracle\\admin\\eygle\\scripts\\CloneRmanRestore.log
startup nomount pfile="C:\\oracle\\admin\\eygle\\scripts\\init.ora";
@C:\\oracle\\admin\\eygle\\scripts\\rmanRestoreDatafiles.sql;
这个脚本首先启动实例到Nomount模式,然后调用rmanRestoreDatafiles.sql来恢复文件。
1.3.3 Rman的引入
rmanRestoreDatafiles.sql脚本是通过系统包dbms_backup_restore来恢复备份集中的文件,从而实现数据恢复,其主要内容如下:
set echo off;
set serveroutput on;
select TO_CHAR(systimestamp,'YYYYMMDD HH:MI:SS') from dual;
variable devicename varchar2(255);
declare
omfname varchar2(512) := NULL;
done boolean;
begin
dbms_output.put_line(' ');
dbms_output.put_line(' Allocating device.... ');
dbms_output.put_line(' Specifying datafiles... ');
:devicename := dbms_backup_restore.deviceAllocate;
dbms_output.put_line(' Specifing datafiles... ');
dbms_backup_restore.restoreSetDataFile;
dbms_backup_restore.restoreDataFileTo(1,
'C:\\oracle\\oradata\\eygle\\SYSTEM01.DBF', 0, 'SYSTEM');
dbms_backup_restore.restoreDataFileTo(2,
'C:\\oracle\\oradata\\eygle\\UNDOTBS01.DBF', 0, 'UNDOTBS1');
dbms_backup_restore.restoreDataFileTo(3,
'C:\\oracle\\oradata\\eygle\\SYSAUX01.DBF', 0, 'SYSAUX');
dbms_backup_restore.restoreDataFileTo(4,
'C:\\oracle\\oradata\\eygle\\USERS01.DBF', 0, 'USERS');
dbms_output.put_line(' Restoring ... ');
dbms_backup_restore.restoreBackupPiece(
'C:\\oracle\\10.2.0\\assistants\\dbca\\templates\\Seed_Database.dfb', done);
if done then
dbms_output.put_line(' Restore done.');
else
dbms_output.put_line(' ORA-XXXX: Restore failed ');
end if;
dbms_backup_restore.deviceDeallocate;
end;
/
select TO_CHAR(systimestamp,'YYYYMMDD HH:MI:SS') from dual;
关于RMAN的有关知识,我们会在后面的章节详细介绍,但是关于dbms_backup_restore包这里有必要提前介绍一下。
当通过RMAN进行数据库备份时,RMAN会将多个数据文件写出到一个或多个备份文件(称为备份集)中,RMAN的相关的备份信息或者存储在控制文件中,或者存储在RMAN的专用目录数据库(Catalog)中,如果RMAN的备份信息丢失,那么通常备份集中的文件是没有办法读取出来的,其他工具无法识别RMAN的备份集文件;而dbms_backup_restore就是针对这种情况提供的一种解决方案,dbms_backup_restore可以在数据库nomount状态下调用,直接从备份集中读取数据文件,功能十分强大。
DBMS_BACKUP_RESTORE包由dbmsbkrs.sql和prvtbkrs.plb这两个脚本创建,创建数据库时执行的catproc.sql 脚本会调用这两个脚本以创建包,这些脚本文件可以在$ORACLE_HOME/rdbms/admin目录下找到,脚本文件中对包的内容有详细的介绍。
下面通过具体的例子来介绍一下这个工具的用法,以下是一次真实的恢复案例,由于控制文件丢失,只能通过DBMS_BACKUP_RESTORE包从备份集中恢复数据文件,当然恢复之前我们需要知道一些数据库的相关信息,了解备份集中包含了哪些文件。
首先启动数据库到nomount状态:
[oracle@jumper conner]$ sqlplus "/ as sysdba"
Connected to an idle instance.
SQL> startup nomount;
ORACLE instance started.
<...ignore SGA info here...>
然后可以执行脚本,将数据文件恢复到指定目录:
SQL> DECLARE
2 devtype varchar2(256);
3 done boolean;
4 BEGIN
5 devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'t1');
6 sys.dbms_backup_restore.restoreSetDatafile;
7 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>01,
toname=>'/opt/oracle/oradata/conner/system01.dbf');
8 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02,
toname=>'/opt/oracle/oradata/conner/undotbs01.dbf');
9 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03,
toname=>'/opt/oracle/oradata/conner/users01.dbf');
10 sys.dbms_backup_restore.restoreBackupPiece(done=>done,
handle=>'/opt/oracle/product/9.2.0/dbs/0ggmiabq_1_1', params=>null);
11 sys.dbms_backup_restore.deviceDeallocate;
12 END;
13 /
PL/SQL procedure successfully completed.
至此,从备份集中读取文件完毕,但是由于没有控制文件,就需要重建一个控制文件用于恢复,创建控制文件的脚本可以自己根据经验编写,也可以根据备份的文本进行修改,当然也可以从其他数据库中转储一个控制文件脚本,仿照改写。
正常情况下,可以通过如下的命令将控制文件的创建语句转储到跟踪文件中(位于udump目录中):
SQL> alter database backup controlfile to trace;
Database altered.
可以找到trace文件,编辑、执行重建控制文件的需要部分:
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 101782828 bytes
Fixed Size 451884 bytes
Variable Size 37748736 bytes
Database Buffers 62914560 bytes
Redo Buffers 667648 bytes
SQL> set echo on
SQL> @ctl.sql
SQL>
SQL> CREATE CONTROLFILE REUSE DATABASE "CONNER" RESETLOGS ARCHIVELOG
2 -- SET STANDBY TO MAXIMIZE PERFORMANCE
3 MAXLOGFILES 5
4 MAXLOGMEMBERS 3
5 MAXDATAFILES 100
6 MAXINSTANCES 1
7 MAXLOGHISTORY 1361
8 LOGFILE
9 GROUP 1 '/opt/oracle/oradata/conner/redo01.log' SIZE 10M,
10 GROUP 2 '/opt/oracle/oradata/conner/redo02.log' SIZE 10M,
11 GROUP 3 '/opt/oracle/oradata/conner/redo03.log' SIZE 10M
12 -- STANDBY LOGFILE
13 DATAFILE
14 '/opt/oracle/oradata/conner/system01.dbf',
15 '/opt/oracle/oradata/conner/undotbs01.dbf',
16 '/opt/oracle/oradata/conner/users01.dbf'
17 CHARACTER SET ZHS16GBK
18 ;
Control file created.
如果存在部分归档日志,创建控制文件之后可以执行恢复:
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 240560269 generated at 06/09/2005 17:33:48 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_7.dbf
ORA-00280: change 240560269 for thread 1 is in sequence #7
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 240600632 generated at 06/10/2005 10:42:26 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_8.dbf
ORA-00280: change 240600632 for thread 1 is in sequence #8
ORA-00278: log file '/opt/oracle/oradata/conner/archive/1_7.dbf' no longer needed for this recovery
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 240620884 generated at 06/10/2005 10:45:42 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_9.dbf
ORA-00280: change 240620884 for thread 1 is in sequence #9
ORA-00278: log file '/opt/oracle/oradata/conner/archive/1_8.dbf' no longer needed for this recovery
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [3020], [4242465], [1], [9], [314], [272], [], []
ORA-10567: Redo is inconsistent with data block (file# 1, block# 48161)
ORA-10564: tablespace SYSTEM
ORA-01110: data file 1: '/opt/oracle/oradata/conner/system01.dbf'
ORA-10560: block type 'DATA SEGMENT HEADER - UNLIMITED'
ORA-01112: media recovery not started
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 240620949 generated at 06/10/2005 10:45:44 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_9.dbf
ORA-00280: change 240620949 for thread 1 is in sequence #9
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
恢复到最后可用日志后,通过resetlogs方式打开数据库:
SQL> alter database open resetlogs;
Database altered.
SQL> select name from v$datafile;
NAME
------------------------------------------------------------
/opt/oracle/oradata/conner/system01.dbf
/opt/oracle/oradata/conner/undotbs01.dbf
/opt/oracle/oradata/conner/users01.dbf
至此恢复完成。
这是一次常规恢复,dbms_backup_restore的功能远不止于此,还可以通过该包恢复备份集中的控制文件、归档日志等文件等。
继续前面的讨论,rmanRestoreDatafiles.sql脚本通过dbms_backup_restore包从种子文件Seed_Database.dfb恢复出数据文件,来看一下模板目录中存放的模板和种子数据库(自定义的模板也存放在这个目录中):
C:\\Oracle\\admin\\eygle\\scripts>dir C:\\oracle\\10.2.0\\assistants\\dbca\\templates
驱动器 C 中的卷是 SYSTEM
卷的序列号是 8C88-D1B4
C:\\oracle\\10.2.0\\assistants\\dbca\\templates 的目录
2007-01-05 17:02.
2007-01-05 17:02..
2005-08-30 17:31 5,893 Data_Warehouse.dbc
2005-09-07 13:02 983,040 example.dmp
2005-09-07 13:02 20,897,792 example01.dfb
2007-01-05 17:02 5,812 eygle.dbc
2007-01-05 15:32 12,588 eygle.dbt
2005-08-30 17:31 5,770 General_Purpose.dbc
2005-05-16 15:49 12,411 New_Database.dbt
2005-09-07 13:02 7,061,504 Seed_Database.ctl
2005-09-07 13:02 95,543,296 Seed_Database.dfb
2005-08-30 17:31 5,829 Transaction_Processing.dbc
Seed_Database.dfb文件就是包含种子文件的一个备份集。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。
评论
相关阅读
【纯干货】Oracle 19C RU 19.27 发布,如何快速升级和安装?
Lucifer三思而后行
635次阅读
2025-04-18 14:18:38
Oracle RAC 一键安装翻车?手把手教你如何排错!
Lucifer三思而后行
616次阅读
2025-04-15 17:24:06
XTTS跨版本迁移升级方案(11g to 19c RAC for Linux)
zwtian
513次阅读
2025-04-08 09:12:48
Oracle数据库一键巡检并生成HTML结果,免费脚本速来下载!
陈举超
507次阅读
2025-04-20 10:07:02
【ORACLE】记录一些ORACLE的merge into语句的BUG
DarkAthena
474次阅读
2025-04-22 00:20:37
Oracle 19c RAC更换IP实战,运维必看!
szrsu
452次阅读
2025-04-08 23:57:08
【ORACLE】你以为的真的是你以为的么?--ORA-38104: Columns referenced in the ON Clause cannot be updated
DarkAthena
448次阅读
2025-04-22 00:13:51
【活动】分享你的压箱底干货文档,三篇解锁进阶奖励!
墨天轮编辑部
448次阅读
2025-04-17 17:02:24
一页概览:Oracle GoldenGate
甲骨文云技术
447次阅读
2025-04-30 12:17:56
火焰图--分析复杂SQL执行计划的利器
听见风的声音
393次阅读
2025-04-17 09:30:30