教你用Linux完成Oracle自动物理备份

教你用Linux完成Oracle自动物理备份
本文的目标是通过执行一Shell脚本来完成Oracle数据库自动备份的全过程，而且能够在当前目录下生成其压缩文件。

具体实现步骤如下：
1．以Oracle用户身份登录到Linux系统下。

2．建立database.srcipt文件，以便生成备份数据库的一些参数信息并保存在文件database.p arm中。

这些信息对于以后恢复数据库具有重要的参考作用，所以在物理备份的过程中，需要保存这些信息，也可以把其他一些重要的信息写在这个脚本里。

$vi database.srcipt
spool database.p arm
--这是当前备份数据库的系统参数列表
select * from v$parameter;
--这是当前备份数据库的字符集部分参数
select * from props$;
--这是当前备份数据库数据文件存储位置及名称
select * from v$datafile;
--这是当前备份数据库控制文件存储位置及名称
select * from v$controlfile;
--这是当前备份数据库日志文件存储位置及名称
select * from v$logfile;
--可以在这里添加其他一些重要信息
--开始生成备份shell文件，可参考backup.sh
spool off
spool backup.sh
select 'cp '||name || ' backup/' from v$datafile ;
select 'cp '||name || ' backup/' from v$controlfile ;
select 'cp '||member || ' backup/' from v$logfile;
spool off
shutdown immediate
exit
!
3．修改上一步中生成的backup.sh文件，并执行它来完成数据库文件的操作系统备份。

为清晰起见，将这段脚本命名为文件alterbackup.sh。

$vi alterbackup.sh
echo “该脚本完成把数据库数据文件、控制文件、日志文件的复制到当前目录的过程”
cat backup.sh|grep ‘cp /’>c.sh
#该语句把backup.sh中所有以“cp /”开头的语句提取出来生成新的文件c.sh
rm backup.sh
mv c.sh backup.sh
chmod +x backup.sh
. backup.sh
#注意：点号“.”与backup.sh之间有一空格
4．建立数据库启动脚本，以便完成备份之后启动数据库，将这段脚本命名为startup.script。

$vi startup.script
spool StartStatus.readme
--开始启动数据库
startup
--数据库启动完成，可以查看StartStatus.readme文件检查数据库启动情况
spool off
exit
!
5．为节省磁盘空间和复制到其他存储位置，建立Shell文件gzip.script 来完成备份数据文件的压缩。

注意生成备份文件时，在文件名中注明时间。

$vi gzip.sh
echo “开始进行备份文件的压缩过程”
thedate=‘date + %Y.%m.%d.%H.%M’
#注意：字符串前后都有一个反引号，不是单引号
outfile=$thedate
tar -cvf backup$outfile.tar backup/*
#将备份到backup目录下的所有文件生成一档案文件
gzip backup$outfile.tar
#把档案文件进行压缩，以节省硬盘空间
rm -R backup #删除那些没有压缩的文件
6．把上面第2步到第5步生成的内容组织成一个Shell文件begin.sh，但这之前还需要先运行以下命令：
$chmod +x alterbackup.sh
$chmod +x gzip.sh
$vi begin.sh
echo “开始进行数据库的自动物理备份过程，该Shell将在当前目录下生成backup.gz文件，
该文件中包含数据库的一些参数信息及数据库的物理文件……”
mkdir backup
sqlplus internal/oracle < database.srcipt
. alterbackup.sh
sqlplus internal/oracle < startup.script
. gzip.sh
echo “数据库自动进行物理备份过程结束，请在当前目录下检查backup.tar.gz”
7．增加数据库参数文件的备份语句。

数据库参数文件通常存储在“ORACLE/ADMIN/数据库名/pfile/”目录下，其文件命名规则为“init+数据库名.ora”，数据库名缺省名称为orcl，可根据数据库安装名称来进行修改。

如果不知道该文件存储在什么位置，可使用下面命令进行查找：
$find $ORACLE_HOME -name ‘initorcl.ora’
该语句可能显示出/u01/app/oracle/product/8.1.7/dbs/initorcl.ora，由于在Linux中有一种链接文件，所以要查看显示出的文件是不是链接文件，如果是，还需要进一步查看其原始文件。

$ll /u01/app/oracle/product/8.1.7/dbs/initorcl.ora
本例中显示出该文件是一个链接文件，它指向
/u01/app/oracle/admin/orcl/pfile/initorcl.ora。

为此，可以修改第3步的alterbackup.sh，修改结果如下（粗体显示，该语句需要根据数据库安装情况进行修改）：
……
chmod +x backup.sh
cp /u01/app/oracle/admin/orcl/pfile/initorcl.ora
backup/initorcl.ora
. backup.sh
#注意：点号“.”与backup.sh之间有一空格
8．在准备进行备份时，先使用“ls -l（或ll）”命令检查当前目录下，此时应该有这样几个文件：alterbackup.Sh，begin.sh，database.script，gzip.sh，startup.script。

此后，还应执行命令：
$chmod +x begin.sh
如果一切完成，就可以执行begin.sh来完成备份过程了:
. begin.sh
#注意begin.sh与前面点号之前有一空格。

以后每次需要做备份时，只需运行begin.sh即可。

这里也可以使用crontab 自动完成按计划备份，有关如何使用crontab，请参考相关资料，也可在网上查询，本文不再做介绍。

使用此方法进行物理备份过程，不仅备份了数据库的数据文件，也同时记录了数据库的一些重要信息（第2步的database.p arm文件中），这对于以后恢复数据是非常重要的。

最后要提醒读者注意的是，本文提供的方法要求有足够大的剩余磁盘空间（尽管最后只保留了备份文件的压缩文件），这个缺撼留给读者去弥补。

Oracle安全全接触（完整版）
随着计算机的普及以及网络的发展，数据库已经不再仅仅是那些程序员所专有的话题。

而Oracle数据库更是凭借其性能卓越，操作方便灵活的特点，在数据库的市场中已经占据了一席之地。

但是同样随着网络技术的不断进步，数据信息的不断增加，数据安全已经不再是以前的“老生长谈”，也更不是以前书本上那些“可望不可及”的条条框框。

或许很久以前，大家都觉得Oracle数据库的安全并不存在隐患，因为Oracle 公司在去年11月份开始促销其数据库软件时提出的口号是“只有Oracle9i能够做到绝对安全”。

但是不管它这么说是为了促销，还是为了扩大知名度，总之伴去年12 月份，英国的安全专家 David Litchfield 发现的9iAS 中存在的程序错误导致的缓冲溢出漏洞以及后来，PenTest Limited 和 eEye Digital Security 各自提出了一个小的漏洞，所有使用Oracle公司产品的人都不由地紧张了原本松弛的大脑--这个对于用户来说，毕竟关系到了自己的“身家性命”。

下面笔者将带着大家走进Oracle数据安全的世界。

由于笔者水平有限，所以不足之处在所难免，望大家不吝赐教。

(一)Oracle数据库的一些基本常识
这里仅仅是为了以后的安全奠定一些基础，因为我们后面要用到它们。

1.Oracle所包含的组件:
在 Oracle，数据库是指整个 Oracle RDBMS 环境，它包括以下组件:
·Oracle 数据库进程和缓冲(实例)。

·SYSTEM 表空间包含一个集中系统类目，它可以由一个或多个数据文件构成。

·其它由数据库管理员 (DBA)(可选)定义的表空间，每个都由一个或多个数据文件构成。

·两个以上的联机恢复日志。

·归档恢复日志(可选)。

·其它文件(控制文件、Init.ora、Config.ora 等)。

每个 Oracle 数据库都在一个中央系统类目和数据字典上运行，它位于SYSTEM 表空间。

2.关于“日志”
Oracle数据库使用几种结构来保护数据:数据库后备、日志、回滚段和控制文件。

下面我们将大体上了解一下作为主要结构之一的“日志”:
每一个Oracle数据库实例都提供日志，记录数据库中所作的全部修改。

每一个运行的Oracle数据库实例相应地有一个在线日志，它与Oracle后台进程LGWR一起工作，立即记录该实例所作的全部修改。

归档(离线)日志是可选择的，一个Oracle数据库实例一旦在线日志填满后，可形成在线日志归档文件。

归档的在线日志文件被唯一标识并合并成归档日志。

·关于在线日志:一个Oracle数据库的每一实例有一个相关联的在线日志。

一个在线日志由多个在线日志文件组成。

在线日志文件(online redo log file)填入日志项(redo entry)，日志项记录的数据用于重构对数据库所作的全部修改。

·关于归档日志:Oracle要将填满的在线日志文件组归档时，则要建立归档日志(archived redo log)。

其对数据库备份和恢复有下列用处:
数据库后备以及在线和归档日志文件，在操作系统和磁盘故障中可保证全部提交的事物可被恢复。

在数据库打开和正常系统使用下，如果归档日志是永久保存，在线后备可以进行和使用。

数据库可运行在两种不同方式下:NOARCHIVELOG方式或ARCHIVELOG 方式。

数据库在NOARCHIVELOG方式下使用时，不能进行在线日志的归档。

如果数据库在ARCHIVELOG方式下运行，可实施在线日志的归档。

3.物理和逻辑存储结构:
Oracle RDBMS是由表空间组成的，而表空间又是由数据文件组成的。

表空间数据文件被格式化为内部的块单位。

块的大小，是由DBA在Oracle第一次创建的时候设置的，可以在512到8192个字节的范围内变动。

当一个对象在Oracle 表空间中创建的时候，用户用叫做长度的单位(初始长度((initial extent)、下一个长度(next extent)、最小长度(min extents)、以及最大长度(max extents))来标明该对象的空间大小。

一个Oracle长度的大小可以变化，但是要包含一个由至少五个连续的块构成的链。

4.Oracle与Microsoft SQL Server比较下的联网协议:
(二)Oracle数据安全的维护
记得某位哲学家说过:“事物的变化离不开内因和外因。

”那么对于Oracle 数据安全这个话题而言，也势必分为“内”和“外”两个部分。

那么好，我们就先从“内”开始说起:
§1.从Oracle系统本身说起
我们先抛开令人闻风色变的“hacker”和其他一些外部的原因，先想一下我们的数据库。

什么硬盘损坏
，什么软件受损，什么操作事物……一系列由于我们的“疏忽”而造成的系统问题就完全可以让我们辛苦建立的数据库中的数据一去不复返。

那么，我们就先从自己身上找找原因吧。

【一】解决系统本身问题的方法--数据库的备份及恢复
·数据库的备份:
关于Oracle数据库的备份，标准地有三中办法:导出/导入
(Export/Import)、冷备份、热备份。

导出备份是一种逻辑备份，冷备份和热备份是物理备份。

导出/导入(Export/Import)
利用Export可将数据从数据库中提取出来，利用Import则可将提取出来的数据送回Oracle数据库中去。

a.简单导出数据(Export)和导入数据(Import)
Oracle支持三种类型的输出:
(1)表方式(T方式)，将指定表的数据导出。

(2)用户方式(U方式)，将指定用户的所有对象及数据导出。

(3)全库方式(Full方式)，将数据库中的所有对象导出。

数据导出(Import)的过程是数据导入(Export)的逆过程，它们的数据流向不同。

b.增量导出/导入
增量导出是一种常用的数据备份方法，它只能对整个数据库来实施，并且必须作为SYSTEM来导出。

在进行此种导出时，系统不要求回答任何问题。

导出文件名缺省为export.dmp，如果不希望自己的输出文件定名为export.dmp，必须在命令行中指出要用的文件名。

增量导出包括三个类型:
(1)“完全”增量导出(Complete)
即备份整个数据库，比如:
$exp system/manager inctype=complete file=990702.dmp
(2)“增量型”增量导出
备份上一次备份后改变的数据。

比如:
$exp system/manager inctype=incremental file=990702.dmp
(3)“累计型”增量导出(Cumulative)
累计型导出方式只是导出自上次“完全” 导出之后数据库中变化了的信息。

比如:
$exp system/manager inctype=cumulative file=990702.dmp
数据库管理员可以排定一个备份日程表，用数据导出的三个不同方式合理高效地完成。

比如数据库的备份任务可作如下安排:
·星期一:完全导出(A)
·星期二:增量导出(B)
·星期三:增量导出(C)
·星期四:增量导出(D)
·星期五:累计导出(E)
·星期六:增量导出(F)
·星期日:增量导出(G)
如果在星期日，数据库遭到意外破坏，数据库管理员可按以下步骤来
恢复数据
库:
第一步:用命令CREATE DATABASE重新生成数据库结构;
第二步:创建一个足够大的附加回段。

第三步:完全增量导入A:
$imp system./manager inctype= RECTORE FULL=Y FILE=A
第四步:累计增量导入E:
$imp system/manager inctype= RECTORE FULL=Y FILE =E
第五步:最近增量导入F:
$imp system/manager inctype=RESTORE FULL=Y FILE=F
冷备份
冷备份发生在数据库已经正常关闭的情况下，当正常关闭时会提供给我们一个完整的数据库。

冷备份是将关键性文件拷贝到另外位置的一种说法。

对于备份Oracle信息而言，冷备份是最快和最安全的方法。

冷备份的优点是:
·是非常快速的备份方法(只需拷贝文件)
·容易归档(简单拷贝即可)
·容易恢复到某个时间点上(只需将文件再拷贝回去)
·能与归档方法相结合，作数据库“最新状态”的恢复。

·低度维护，高度安全。

但冷备份也有如下不足:
·单独使用时，只能提供到“某一时间点上”的恢复。

·在实施备份的全过程中，数据库必须要作备份而不能作其它工作。

也就是说，在冷备份过程中，数据库必须是关闭状态。

·若磁盘空间有限，只能拷贝到磁带等其它外部存储设备上，速度会很慢。

·不能按表或按用户恢复。

如果可能的话(主要看效率)，应将信息备份到磁盘上，然后启动数据库(使用户可以工作)并将所备份的信息拷贝到磁带上(拷贝的同时，数据库也可以工作)。

冷备份中必须拷贝的文件包括:
·所有数据文件
·所有控制文件
·所有联机REDO LOG文件
·Init.ora文件(可选)
值得注意的是冷备份必须在数据库关闭的情况下进行，当数据库处于打开状态时，执行数据库文件系统备份是无效的
下面是做冷备份的完整例子:
(1) 关闭数据库$sqldba lmode=y
SQLDBA >connect internal;
SQLDBA >shutdown normal;
(2) 用拷贝命令备份全部的时间文件、重做日志文件、控制文件、初始化参数文件
·向密码文件中增加、删除用户:
当初始化参数REMOTE_LOGIN_PASSWORDFILE设置为EXCLUSIVE时，系统允许除INTERNAL/SYS以外的其他用户以管理员身份从远端或本机登录到Oracle数据库系统，执行数据库管理工作;这些用户名必须存在于密码文件中，系统才能识别他们。

由于不管是在创建数据库实例时自动创建的密码文件，还是使用工具ORAPWD.EXE手工创建的密码文件，都只包含INTERNAL/SYS用户的信息;为此，在实际操作中，可能需要向密码文件添加或删除其他用户帐号。

由于仅被授予SYSOPER/SYSDBA系统权限的用户才存在于密码文件中，所以当向某一用户授予或收回SYSOPER/SYSDBA系统权限时，他们的帐号也将相应地被加入到密码文件或从密码文件中删除。

由此，向密码文件中增加或删除某一用户，实际上也就是对某一用户授予或收回SYSOPER/SYSDBA系统权限。

要进行此项授权操作，需使用SYSDBA权限(或INTERNAL帐号)连入数据库，且初始化参数REMOTE_LOGIN_PASSWORDFILE的设置必须为EXCLUSIVE。

具体操作步骤如下:
创建相应的密码文件;
设置初始化参数REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE;
使用SYSDBA权限登录: CONNECT SYS/internal_user_passsword AS SYSDBA;
启动数据库实例并打开数据库;
创建相应用户帐号，对其授权(包括SYSOPER和SYSDBA): 授予权限:GRANT SYSDBA TO user_name;
收回权限:REVOKE SYSDBA FROM user_name;
现在这些用户可以以管理员身份登录数据库系统了;
·使用密码文件登录:
有了密码文件后，用户就可以使用密码文件以SYSOPER/SYSDBA权限登录Oracle数据库实例了，注意初始化参数REMOTE_LOGIN_PASSWORDFILE应设置为EXCLUSIVE 或SHARED。

任何用户以SYSOPER/SYSDBA的权限登录后，将位于SYS用户的Schema 之下，以下为两个登录的例子:
1. 以管理员身份登录:
假设用户scott已被授予SYSDBA权限，则他可以使用以下命令登录:
CONNECT scott/tiger AS SYSDBA
2. 以INTERNAL身份登录:
CONNECT INTERNAL/INTERNAL_PASSWORD
·密码文件的维护:
1. 查看密码文件中的成员:
可以通过查询视图V$PWFILE_USERS来获取拥有SYSOPER/SYSDBA系统权限的用户的信息，表中SYSOPER/SYSDBA列的取值TRUE/FALSE表示此用户是否拥有相应的权限。

这些用户也就是相应地存在于密码文件中的成员。

2. 扩展密码文件的用户数量:
当向密码文件添加的帐号数目超过创建密码文件时所定的限制(即ORAPWD.EXE工具的MAX_USERS参数)时，为扩展密码文件的用户数限制，需重建密码文件，具体步骤如下:
a) 查询视图V$PWFILE_USERS，记录下拥有SYSOPER/SYSDBA系统权限的用户信息;
关闭数据库;
c) 删除密码文件;
d) 用ORAPWD.EXE新建一密码文件;
e) 将步骤a中获取的用户添加到密码文件中。

3. 修改密码文件的状态:
密码文件的状态信息存放于此文件中，当它被创建时，它的缺省状态为SHARED。

可以通过改变初始化参数REMOTE_LOGIN_PASSWORDFILE的设置改变密码文件的状态。

当启动数据库事例时，Oracle系统从初始化参数文件中读取REMOTE_LOGIN_PASSWORDFILE参数的设置;当加载数据库时，系统将此参数与口令文件的状态进行比较，如果不同，则更新密码文件的状态。

若计划允许从多台客户机上启动数据库实例，由于各客户机上必须有初始化参数文件，所以应确保各客户机上的初始化参数文件的一致性，以避免意外地改变了密码文件的状态，造成数据库登陆的失败。

4. 修改密码文件的存储位置:
密码文件的存放位置可以根据需要进行移动，但作此修改后，应相应修改系统注册库有关指向密码文件存放位置的参数或环境变量的设置。

5. 删除密码文件:
在删除密码文件前,应确保当前运行的各数据库实例的初始化参数REMOTE_LOGIN_PASSWORDFILE皆设置为NONE。

在删除密码文件后，若想要以管理员身份连入数据库的话，则必须使用操作系统验证的方法进行登录。

但是管理员都觉得乏味，因为在管理员中流行一种很简单的加密办法--就是经常，很频繁地修改自己的密码。

可是，每次修改都跟打一次仗似的--因为更新程序并不是每个人都愿意做的事情。

那么有没有什么简单点的办法呢?请往下看:
模型:Oracle7.3;开发工具:Develope2000。

收费系统(在数据库中的名称是SFYY)，其Client 端分散在市区的数个营业点，通过城域网与主机(小型机)相连。

过程:
·在收费小型机Oracle系统的system用户(DBA)下，创建新用户
identified by carton
·对test用户授以权限
·在test用户下建立一个存储函数mmtranslate,它其实是一个加密程序。

下面是一个简单的例子。

functio
if i
elseif instr(‘wxyz‘,subst
kk:=kk||chr(-
return ′-
·在test用户下建表mmtest并插入记录
(usnamevarchar2(6),------用户名称
mimavarchar2(6)------加密前的密码
commit;
·执行以下语句
----------------------------------------
利用DBA权限更改sfyy的密码为上面语句的执行结果
·修改应用程序，对于开发环境是Develope2000的程序来说，主要是修改主程序的on-lo gon触发器
logon(‘test‘,‘carton‘
然后再利用触发器WHEN-NEW-FROM-INSTANCE执行Callfrom或Newform等命令，进入业务处理程序。

这个主程序应当仅仅由管理员来掌握,编译之后将执行文件下发到各收费点的Clien端。

·在System用户下，利用Oracle提供的pupbld.sql,建立表Productuserprofile,执行下面这样的命令，限制在非开发状态Sql命令的使用,例如
(product,userid,attr
(‘SQL*Plus‘,‘SFYY‘,‘DELETE‘,‘DISABLED‘);这样，在SQL状态下，根本无法连接到TEST用户，而在sfyy用户下，delete命令将不能执行。

当然，DBA可以改变这些设置。

当然了，这个仅仅是属于一种“应用技巧”，但是足可以把那些每天忙于更新系统的管理员舒服好几天了。

但是另一方面，还要加强对源程序的管理，在Client端只存放执行程序。

加强审计，发现异常现象，及时处理。

这样才可以做到更高一层的“安全”。

在下面，我主要是向大家介绍一个REM对GHXXB制立数据库触发子,密码的加密程序。

REM 对GHXXB制立数据库触发子(当INSERT OR UPDATE GHXXB时触发)
drop trigger scjmmm;
create or replace trigger scjmmm
before insert or update of mm On ghxxb For each Row
Begin
:new.mm:=ENCRYPT(:new.mm,:NEW.GH,TO_CHAR(SYSDA TE,‘SS‘));
End;
/
---------------------------密码的加密程序ENCRYPT----------------------
Create or Replace
Function ENCRYPT (Inpass In Varchar2,IN_GH In Varchar2,IN_SS In Varchar2)
Return Varchar2 Is
bcs varchar2(20);
bcs1 number;
cs number;
jg number;
m_gh V ARCHAR2(4);
m_mm VARCHAR2(20);
Begin
m_gh:=IN_GH;
m_mm:=INPASS;
cs:=TO_NUMBER(IN_SS);
If cs
bcs:=substr(to_char(ascii(substr(m_gh,1,1))),1,2);
If bcs
m_gh:=substr(m_gh,2);
Loop EXIT WHEN nvl(length(m_gh),0)=0 ;
bcs:=bcs||substr(to_ch
数据库备份九点详解
第一种情况:
有RAID，还需要做数据库备份吗?
回答:需要。

有了RAID，万一部份磁盘损坏，可以修复数据库，有的情况下数据库甚至可以继续使用。

但是，如果哪一天，你的同事不小心删除了一条重要的记录，怎么办?RAID 是无能为力的。

你需要合适的备份策略，把那条被误删的数据恢复出来。

所以有了RAID，仍需要做备份集群，磁盘镜像同理。

第二种情况:
我们需要全备份+日志备份?
解答:如果你只做全备份，那么受限于全备份的大小和备份时间，不可能常做。

而且只有全备份，不能将数据库恢复至某个时间点。

所以，我们需要全备份+日志备份。

比如每天一个全备份，每隔1小时或若干分钟一个日志备份。

说到差异备份，因为微软的差异备份记录的是上一次全备份以来发生的变化，所以，如果数据库的改动很频繁的话，没过多久，差异备份就会和全备份的大小接近，因此这种情况下就不合适了。

因此，全备份+日志备份的方案适合绝大多数的用户。

第三种情况:
如果你仅在数据库本地做备份，万一磁盘损坏，或者整个服务器硬件损坏，备份也就没了，就没法恢复数据库。

解答:因此，你需要把备份文件传送至另一个物理硬件上。

大多数用户不用磁带机，因此不考虑。

一般，我们需要另一台廉价的服务器或者PC来存放数据库的备份，来防止硬件损坏造成的备份丢失。

第四种情况:
你可以在数据库服务器本地做完备份，然后使用某些方式将备份文件传送至备机。

你是在备份完成后就马上穿送的吗?其实可以考虑将传送备份的脚本用T-SQL语句来写。

第五种情况:
备份文件传送至备机后，就可以高枕无忧了吗?
解答:不。

作为DBA的你还需要检查备机上的备份文件是否能将数据库恢复至最新，如果采用日志备份，会不会因为丢失某一个日志备份文件而导致数据库不能恢复至最新?如何检查日志备份文件之间存在断档?
第六种情况:
为了将数据库尽可能的恢复到最新，你可能会每隔10分钟(甚至1分钟)执行一次日志备份，那么万一数据库坏了，在恢复的时候，手动恢复成百上千个日志文件，是不是不太现实?
第七种情况:
如果你所在公司有很多的数据库服务器(就像我所在的公司)，而且磁盘空间有限，那么你不得不经常登录服务器来删除旧的备份文件，如果哪天忘了，或者五一十一长假，磁盘空间用完了，就麻烦了。

第八种情况:
数据库在备份的时候，并不会检查数据页面的完整性，如果数据页坏了，备份作业仍会执行，而且不会报错，等到你发现数据页有错误的时候，你也很可能已经因为磁盘空间不足，而删除了早期的备份，而此时剩下的那些备份可能都是包含损坏的数据页，如果损坏的数据页是某个表的表头的话，那这个表你就再也没办法恢复了。

所以你需要定期执行DBCC检查，来尽早发现数据库页面的完整性。

在未作完DBCC检查之前，你不能删除旧的备份，以防止新的备份存在问题。

所以，删除备份文件的工作变的有些麻烦。

第九种情况:
你可能知道SQL Server提供了数据库维护计划。

没错，使用它可以定期做备份，执行DBCC检查，但这一切仅限于本机操作。

为了使数据库可靠，你还是需要自己把本地备份传送至备机。

专家在线：全面介绍恢复Oracle数据库
这是截取自Damir Bersinic 和John Watson合著的《Oracle Database 10g OCP Certification All-In-One Exam Guide》书中第20章，Oracle出版社出版copyright 2006 ，McGraw-Hill分公司。

在这章中你将会学到的是:
∙用控制文件挽回损失
∙用redo日志文件挽回损失
∙用系统关键数据文件挽回损失
∙用非系统关键数据文件挽回损失
要损坏Oracle数据是不可能的。

环境恢复的机制保证了这一点，就是使用redo和undo来将数据库返回到环境失败之前的一个一致性状态中去。

然而，在媒介失败之后丢失数据是可能的——如果数据库管理员没有予以适当的警惕。

预先防范是简单的:在归档日志模式下运行数据库;多路传送控制文件，在线日志文件，以及文档日志文件;支持数据文件和文档日志文件。

在媒介失败之后，备份和文档日志可以用于恢复数据库到失败前的点，不丢失任意一行已经被提交的数据。

但是，尽管环境恢复的确是自动化的，不可避免的——媒介恢复是一个手工的过程。

本章内容将会讲述基本的恢复技术。

可以用于更加复杂问题的比较高级的技术，将会在下章中涉及。

不可避免性——媒介的恢复是个手工的过程。

本章讨论的是基本的恢复技术。

更高级的，可以应用于更加复杂问题的技术，将会在稍后的章节中继续讨论。

恢复结构和处理过程
在媒介失败之后，有不同的技术用于恢复，根据哪个文件被损坏的情况。

数据库由3种文件类型组成:控制文件、在线redo日志文件，以及数据文件。

恢复控制文件和在线redo日志文件的过程是一个繁琐的过程，它们是通过多路传送的。

恢复一个或者多个数据文件的过程是比较复杂的，但是很直接。

损坏的控制文件可以通过多路传送的拷贝或者用CREATE CONTROLFILE命令重新创建的控制文件来进行恢复。

在极端的情况下，它可以从备份中重新存储，但是这一点在媒介失败之后是从来不需要的，如果你遵循的是一个合适的多路策略。

损坏的在线redo文件也可以被重新生成，Oracle提供了一条ALTER DATABASE CLEAR LOGFILE GROUP #(#是损坏成员的组的号码)命令，它可以删除并且重新创建日志文件组的成员。

如果数据库运行的是文档日志模式(也应该是这样的)，日志文件组必须在Oracle允许执行清楚日志文件命令之前进行归档。

这是因为，清除一个没有归档的日志文件组，就意味着文档日志流会丢失一个日志文件，因此恢复就是不可能的了。

这样的命令还可以有一些变化，ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP #，它可以删除并重新创建日志文件，即使是它没有成功地归档，但是在执行了这条命令之后，它绝对就是执行整个数据库备份的一个至关重要的部分。