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

教你用Linux完成Oracle自动物理备份 本文的目标是通过执行一Shell脚本来完成Oracle数据库自动备份的全过程，而且能够在当前目录下生成其压缩文件。具体实现步骤如下：1以Oracle用户身份登录到Linux系统下。2建立database.srcipt文件，以便生成备份数据库的一些参数信息并保存在文件database.parm中。这些信息对于以后恢复数据库具有重要的参考作用，所以在物理备份的过程中，需要保存这些信息，也可以把其他一些重要的信息写在这个脚本里。$vi database.srciptspool database.parm-这是当前备份数据库的系统参数列表select * from v$parameter;-这是当前备份数据库的字符集部分参数select * from props$;-这是当前备份数据库数据文件存储位置及名称select * from v$datafile;-这是当前备份数据库控制文件存储位置及名称select * from v$controlfile;-这是当前备份数据库日志文件存储位置及名称select * from v$logfile;-可以在这里添加其他一些重要信息-开始生成备份shell文件，可参考backup.shspool offspool backup.shselect cp |name | backup/ from v$datafile ;select cp |name | backup/ from v$controlfile ;select cp |member | backup/ from v$logfile;spool offshutdown immediateexit!3修改上一步中生成的backup.sh文件，并执行它来完成数据库文件的操作系统备份。为清晰起见，将这段脚本命名为文件alterbackup.sh。$vi alterbackup.shecho “该脚本完成把数据库数据文件、控制文件、日志文件的复制到当前目录的过程”cat backup.sh|grep cp /c.sh#该语句把backup.sh中所有以“cp /”开头的语句提取出来生成新的文件c.shrm backup.shmv c.sh backup.shchmod +x backup.sh. backup.sh#注意：点号“.”与backup.sh之间有一空格4建立数据库启动脚本，以便完成备份之后启动数据库，将这段脚本命名为startup.script。$vi startup.scriptspool StartStatus.readme-开始启动数据库startup-数据库启动完成，可以查看StartStatus.readme文件检查数据库启动情况spool offexit!5为节省磁盘空间和复制到其他存储位置，建立Shell文件gzip.script来完成备份数据文件的压缩。注意生成备份文件时，在文件名中注明时间。$vi gzip.shecho “开始进行备份文件的压缩过程”thedate=date + %Y.%m.%d.%H.%M#注意：字符串前后都有一个反引号，不是单引号outfile=$thedatetar -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.shecho “开始进行数据库的自动物理备份过程，该Shell将在当前目录下生成backup.gz文件，该文件中包含数据库的一些参数信息及数据库的物理文件”mkdir backupsqlplus internal/oracle database.srcipt. alterbackup.shsqlplus internal/oracle 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权限登录: CONNECTSYS/internal_user_passswordASSYSDBA;启动数据库实例并打开数据库;创建相应用户帐号，对其授权(包括SYSOPER和SYSDBA): 授予权限:GRANTSYSDBATOuser_name;收回权限:REVOKESYSDBAFROMuser_name;现在这些用户可以以管理员身份登录数据库系统了;使用密码文件登录:有了密码文件后，用户就可以使用密码文件以SYSOPER/SYSDBA权限登录Oracle数据库实例了，注意初始化参数REMOTE_LOGIN_PASSWORDFILE应设置为EXCLUSIVE或SHARED。任何用户以SYSOPER/SYSDBA的权限登录后，将位于SYS用户的Schema之下，以下为两个登录的例子:1. 以管理员身份登录:假设用户scott已被授予SYSDBA权限，则他可以使用以下命令登录:CONNECTscott/tigerASSYSDBA2. 以INTERNAL身份登录:CONNECTINTERNAL/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)下，创建新用户test;create user testidentified by cartondefault tablespace dataspace1quota 100K对test用户授以权限;grant create session to test;grant resource to test;在test用户下建立一个存储函数mmtranslate,它其实是一个加密程序。下面是一个简单的例子。function mmtranslate(m varchar2)return varchar2asi number(2);kk varchar2(10);beginkk:=;i:=1;loopif iif instr(1234567890,substr(m,i,1),1,1)0 thenkk:=kk|chr(100+to_number(substr(m,i,1);elseif instr(wxyz,substr(m,i,1),1,1)0 thenkk:=kk|chr(-8+ascii(substr(m,i,1);elsekk:=kk|chr(4+ascii(substr(m,i,1);end if;elseexit;end if;i:=i+1;end loop;return kk;exceptionwhen others thenreturn -1;end;在test用户下建表mmtest并插入记录:create table mmtest(usnamevarchar2(6),-用户名称mimavarchar2(6)-加密前的密码);insert into mmtest values( sfyy,eds2);commit;执行以下语句SQLselect mmtranslate(eds2) from dual;MMTRANSLATE(EDS2)-ihwf利用DBA权限更改sfyy的密码为上面语句的执行结果:alter user sffyidentified by ihwf; ;修改应用程序，对于开发环境是Develope2000的程序来说，主要是修改主程序的on-lo gon触发器:declaremm varchar2(6);beginlogon(test,carton);select mima into mm from mmtest where usname=sfyy;mm:=mmtranslate(mm);logout;logon(sfyy,mm);end;然后再利用触发器WHEN-NEW-FROM-INSTANCE执行Callfrom或Newform等 命令，进入业务处理程序。这个主程序应当仅仅由管理员来掌握,编译之后将执行文件下发 到各收费点的Clien端。在System用户下，利用Oracle提供的pupbld.sql,建立表Productuserprofile,执行下面这样的命令，限制在非开发状态Sql命令的使用,例如insert into productuserprofile(product,userid,attribute,charvalue) values(SQL*Plus,TEST,CONNECT,DISABLED);insert into productuserprofile(product,userid,attribute,charvalue) values(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 scjmmmbefore insert or update of mm On ghxxb For each RowBegin:new.mm:=ENCRYPT(:new.mm,:NEW.GH,TO_CHAR(SYSDATE,SS);End;/-密码的加密程序ENCRYPT-Create or ReplaceFunction ENCRYPT (Inpass In Varchar2,IN_GH In Varchar2,IN_SS In Varchar2)Return Varchar2 Isbcs varchar2(20);bcs1 number;cs number;jg number;m_gh VARCHAR2(4);m_mm VARCHAR2(20);Beginm_gh:=IN_GH;m_mm:=INPASS;cs:=TO_NUMBER(IN_SS);If csbcs:=substr(to_char(ascii(substr(m_gh,1,1),1,2);If bcsm_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 #，它可以删除并重新创建日志文件，即使是它没有成功地归档，但是在执行了这条命令之后，它绝对就是执行整个数据库备份的一个至关重要的部分。一个受到损坏的日志文件需要使用备份和文档日志。在媒介失败导致日志文件的损坏之后，有两种选择用于恢复:完全恢复，意思是不丢失数据;还有不完全恢复，这时你通过在它完成之前停止恢复过程故意丢失一部分工作。不完全恢复是一个高级的程序，将会在第27章中讲述。完全恢复过程有两个阶段。首先，被损坏的文件必须从备份中重新存储。第二个，重新存储的文件必须被恢复，通过使用文档日志中的redo信息来把它及时地向前推进，直到它与数据库的其它部分同步。测验贴士:在Oracle环境中，“重新存储”的意思是用备份替换掉一个损坏或者丢失的文件;“恢复”的意思是通过使用文档日志使文件与数据库的其它部分同步。因为在线redo日志从来没有被RMAN备份过，那么RMAN就不能用来恢复损坏;修理由于媒介失败导致的在线日志文件损坏可以通过SQL*Plus完成，或者是通过数据库控制。控制文件和数据文件都可以通过RMAN来重新存储或者恢复;实际上，如果你把它们备份到备份集中去，RMAN就是你惟一的选项。要打开一个数据库，所有的控制文件拷贝，至少是每个在线日志文件组中的一个文件，还有所有的在线日志文件，都必须要显示出来并且同步。如果，在启动过程中，SMON发现情况不对劲，启动就无法完成。如果一个控制文件拷贝损坏了或者丢失了，启动就用NOMOUNT模式来终止。一条描述哪个(或者哪些)拷贝被损坏了的消息就会发送给警报日志。假设控制文件是好的，SMON就继续打开数据库。在这个过程中，它检查所有在线数据文件的头。如果头有丢失或者损坏，就会写适当的错误消息给警报日志，数据库会继续保持准备的模式。如果所有的在线文件都显示出来，并且没有损坏，但是其中的一个或者多个没有同步，SMON会尝试通过使用在线redo日志来对它们进行同步。这就是环境恢复的过程，在第18章有详细介绍，这个过程是自动进行的。如果所需的在线日志找不到，那么数据库就无法打开。如果一个或者多个数据文件从备份中重新存储了，那么它们可能会非常过时，在线redo日志也无法走那么远的时间去恢复它们:这是你就必须使用文档日志文件来恢复了，这是一个必须手工启动的过程从SQL*Plus中，如果你用的是操作系统的命令备份的话，或者使用RMAN，如果(是Oracle强烈推荐的)你是用RMAN来提交备份的。如果媒介损坏发生在数据库打开的时候，那么影响的范围就基于有哪些文件受到影响。任何控制文件拷贝的损坏都会导致数据库环境立即终止。如果受到损坏的数据文件是SYSTEM表空间或者活动的undo表空间，那么影响是一样的。但是对任何在线日志的损坏都不会导致环境的终止，只要还有部分日志文件组存在的话。实际上，环境会继续工作，你的终端用户也甚至不会注意到。但是错误消息会写到警报日志中去，这种情况也需要立即纠正;这样的纠正能够并且应该是在线的，当人们继续工作的时候。如果损坏的数据文件时表空间的一部分，而不是SYSTEM或者其他活动的undo表空间，也不会导致环境的失败，但是很明显，终端用户可能会有问题，因为数据库的部分内容消失了。你的应用程序如何应对这种情况是不可预期的它是完全根据应用程序是如何组织的。对损坏数据文件的重新存储或者恢复都可以在线完成，假如它们不是属于SYSTEM或者undo表空间的数据文件。最后，如果是组成你的临时表空间的临时文件受到损坏，终端用户也完全不会注意到。Oracle不会去验证临时文件的存在，除非要使用它们了，并且一个经过良好调整的数据库也许永远也不会用到它们。这就是说，临时文件可以在它们受到注意之前消失一阵子。同样也意味着损坏的临时文件可以被删除或者重新创建，在任何时间，除非正好在那个时候要用到它。在备份中重新存储可以通过RMAN或者操作系统工具来完成。但是如果你的RMAN备份是备份集合，而不是映像的拷贝，重新存储就只能通过RMAN来完成了:没有其他的方法从数据集中解压缩数据文件。重新存储后的恢复也可以通过SQL*Plus命令，或者用RMAN来完成，但是也有同样的约束条件:只有RMAN可以从备份集中解压缩文档日志。从媒介失败中恢复媒介失败之后的重新存储和恢复在下一章中会进行更加详细的描述，并且在第二个OCP考试中也会详细考察，但是了解一下初级考试中的简单问题的基本恢复也是很有必要的。这些简单的问题是丢失了多路控制文件中的一个，和一个在线redo日志文件，以及关键和非关键数据文件丢失之后的完全恢复。多路控制文件丢失的恢复只要挽救了现有控制文件的多路拷贝，恢复损失的控制文件就是简单的。只要用挽救回来的控制文件的拷贝替换它就可以了。要从备份中重新存储被损坏的或者丢失的控制文件拷贝在这样的情况下是没有用处的，因为控制文件的所有的拷贝都必须是同样的;很明显，一个重新存储的拷贝不会与其他幸存的拷贝同步，更不用说是数据库的其它部分了。实际上，在损坏发生的瞬间，环境就会终止。而像往常一样，数据库管理员的第一个反应就是坏了的环境应该重新启动。在NOMOUNT模式下，这不会成功的，并且会返回一个错误消息。警报日志将会描述哪个控制文件拷贝丢失了，还会在这个部分列出那些非默认情况的初始化参数实际上使用了多少控制文件，以及它们都在哪里。在这一点上，你要注意三点。第一点，你需要编辑参数文件来删除对丢失或者损坏的控制文件的参考。这样很好，但是你的数据库现在就要运行就会少了一部分多路拷贝，这有可能会违反你的安全条款。一个更好的选择就是用幸存下来的拷贝来替换损坏的文件，或者真的去更改CONTROL_FILES初始化参数来删掉对那些被损坏的文件的参考，重新参考一些新的文件，然后拷贝那些幸存的控制文件到那里去。测验贴士:恢复控制文件的丢失是必须要承担停机时间的。它无法在线完成。测验20-1:从控制文件的丢失中恢复在这个测验中，假设你丢失了多路控制文件，并且要用一个拷贝来替换它。7、用SQL*Plus连接到你的数据库上去，然后确保你的控制文件是多路传输到这个查询的:8、SQL select * from v$controlfile;这个查询必须返回至少2行。如果没有的话，多路传输你的控制文件。9、假设你的数据库受到攻击，一个控制文件损坏了，并且你的一个控制文件名字更改了。注意，在Win