《循序渐进Oracle》第一章连载-之七

来源:互联网 发布:网店美工论文目录 编辑:程序博客网 时间:2024/06/05 17:46

《循序渐进Oracle》第一章连载-之七

作者:eygle |English Version 【转载时请以超链接形式标明文章出处和作者信息及本声明】
链接:http://www.eygle.com/archives/2007/08/stepbs_oracle_chp1_07.html
站内相关文章|Related Articles
  • 《循序渐进Oracle》一书及相关信息
  • 《循序渐进Oracle》再次重印
  • 《循序渐进Oracle》一书重印
  • 《循序渐进Oracle》之后写什么?
  • 《循序渐进Oracle》一书序言
  • 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批处理文件执行的功能是一致的:

    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文件就是包含种子文件的一个备份集。


    1.3.4 克隆数据库

    数据文件具备了,接下来是通过这些文件"克隆"一个数据库,这个工作由cloneDBCreation.sql脚本继续执行,这个脚本更为复杂,下面分开介绍一下。
    首先根据指定的数据库名称(测试数据库指定的名称为eygle)创建一个控制文件:

    connect "SYS"/"&&sysPassword" as SYSDBA
    set echo on
    spool C:/oracle/admin/eygle/scripts/cloneDBCreation.log
    Create controlfile reuse set database "eygle"
    MAXINSTANCES 8
    MAXLOGHISTORY 1
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    Datafile
    'C:/oracle/oradata/eygle/SYSTEM01.DBF',
    'C:/oracle/oradata/eygle/UNDOTBS01.DBF',
    'C:/oracle/oradata/eygle/SYSAUX01.DBF',
    'C:/oracle/oradata/eygle/USERS01.DBF'
    LOGFILE GROUP 1 ('C:/oracle/oradata/eygle/redo01.log') SIZE 51200K,
    GROUP 2 ('C:/oracle/oradata/eygle/redo02.log') SIZE 51200K,
    GROUP 3 ('C:/oracle/oradata/eygle/redo03.log') SIZE 51200K RESETLOGS;

    然后通过dbms_backup_restore包清空dbid等信息:
    exec dbms_backup_restore.zerodbid(0);

    看到这里再次使用到了dbms_backup_restore包,zeroDbid是包中的一个过程,用于清空数据文件头的部分信息,新的dbid在之后的控制文件创建时可以被计算,对于数据库克隆,这是必须的。
    zeroDbid有一个输入参数,即文件号:
    PROCEDURE zeroDbid(fno IN binary_integer);

    当fno==0时,控制文件中包含的所有数据文件头都将被清零,zeroDbid主要用于清除数据文件头的3类信息:Database id信息、Checksum信息和Checksum符号位信息。
    继续看这个脚本,清零完成之后,数据库重新启动,控制文件被重新创建,此时新的dbid被计算并最终写入所有数据文件:

    shutdown immediate;
    startup nomount pfile="C:/oracle/admin/eygle/scripts/initeygleTemp.ora";
    Create controlfile reuse set database "eygle"
    MAXINSTANCES 8
    MAXLOGHISTORY 1
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    Datafile
    'C:/oracle/oradata/eygle/SYSTEM01.DBF',
    'C:/oracle/oradata/eygle/UNDOTBS01.DBF',
    'C:/oracle/oradata/eygle/SYSAUX01.DBF',
    'C:/oracle/oradata/eygle/USERS01.DBF'
    LOGFILE GROUP 1 ('C:/oracle/oradata/eygle/redo01.log') SIZE 51200K,
    GROUP 2 ('C:/oracle/oradata/eygle/redo02.log') SIZE 51200K,
    GROUP 3 ('C:/oracle/oradata/eygle/redo03.log') SIZE 51200K RESETLOGS;

    注意,在启动数据库时Oracle使用了一个临时的参数文件initeygleTemp.ora,在这个参数文件的最后一行设置了一个内部参数:

    C:/Oracle/admin/eygle.t/scripts>tail -1 initeygleTemp.ora

    _no_recovery_through_resetlogs=true

    _no_recovery_through_resetlogs这个参数的作用是什么呢?可以从数据库中找到一点说明:

    SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ
    2 FROM SYS.x$ksppi x, SYS.x$ksppcv y
    3 WHERE x.inst_id = USERENV ('Instance')
    4 AND y.inst_id = USERENV ('Instance')
    5 AND x.indx = y.indx
    6 AND x.ksppinm LIKE '%&par%'
    7 /
    Enter value for par: no_reco
    old 6: AND x.ksppinm LIKE '%&par%'
    new 6: AND x.ksppinm LIKE '%no_reco%'

    NAME VALUE DESCRIB
    ------------------------------ ----- ----------------------------------------------
    _no_recovery_through_resetlogs FALSE no recovery through this resetlogs operation

    这个参数用于限制恢复能否跨越resetlogs,对于数据库的恢复来说,resetlogs通常意味着不完全恢复,在数据库resetlogs打开之后,控制文件中的很多信息被改写,在Oracle10g之前,如果数据库resetlogs打开,那么将不再能够通过当前的控制文件再次进行resetlogs点之前的恢复,而Oracle10g改变了这个历史。
    在Oracle10g中,即使通过resetlogs方式打开了数据库,Oracle仍然支持再次从resetlogs时间点之前进行恢复;在Clone数据库时,Oracle设置这个参数为True,意思就是不允许再次进行跨越resetlogs时间点的恢复。关于这部分内容,我们将在后面章节进行更为详细的介绍。
    继续解读这个脚本,接下来Oracle设置restricted session模式,resetlogs打开数据库:

    alter system enable restricted session;
    alter database "eygle" open resetlogs;

    修改global_name,添加临时文件等:

    alter database rename global_name to "eygle";
    ALTER TABLESPACE TEMP ADD TEMPFILE 'C:/oracle/oradata/eygle/TEMP01.DBF'SIZE 20480K REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED;
    select tablespace_name from dba_tablespaces where tablespace_name='USERS';
    select sid, program, serial#, username from v$session;

    由于种子数据库的字符集通常与用户要求的不符,接下来Oracle通过内部操作强制更改了字符集、国家字符集(这个内容在后面的章节有详细的介绍):

    alter database character set INTERNAL_CONVERT ZHS16GBK;
    alter database national character set INTERNAL_CONVERT AL16UTF16;

    最后修改用户口令,禁用restricted session模式,这个克隆过程执行完毕:

    alter user sys identified by "&&sysPassword";
    alter user system identified by "&&systemPassword";
    alter system disable restricted session;

    至此,种子数据库已经按照用户的意图脱胎换骨得以重生。


    历史上的今天...
          >> 2006-08-03文章:
                 任何伟大的网站都死过至少一次
          >> 2005-08-03文章:
                 Google与DBA
                 Oracle10gR2中一些新特性
                 Oracle9i安装make错误解决一例
                 GreenBrowser开源
    ------
    这篇 【《循序渐进Oracle》第一章连载-之七】来自 www.eygle.com | CSDN技术网摘| del.icio.us|365Key
    原创粉丝点击