备份和恢复 20131224

来源:互联网 发布:vantagepoint软件下载 编辑:程序博客网 时间:2024/06/05 18:26

数据不能丢!——首先强调一下.


MTBF 平均无故障时间

MTTR 平均恢复时间

MTBF 平均故障间隔时间


oracle实现高可用的选项:RAC和stream流.还有Data Guard


流的容错能力超过RAC,因为RAC节点虽多,但用的还是一套存储介质,介质坏了(假设没有raid)就完了.但流可以防御磁盘和网络故障,硬件,操作系统和软件故障也能防.简直防御无敌.


任何容错环境都严重依赖硬件冗余.当然了,多少钱办多大事,要是不差钱的话,RAC stream和DG配置全了,那就是100%高可用系统.


失败类型:

语句失败:语句失败此语句将回滚,其他任何DML语句将保持完好,而且不会提交.

用户进程失败:异常退出啦;终端重启啦,导致地址违规的程序啦等等,结果相同——PMON进程定时轮询所有的服务进程来确定会话的状态,如果某进程报告失去了与其用户进程的联系,此时PMON会残忍并迅速的解决这个问题.如果会话位于某个事务中间,PMON会先回滚这个事务并释放该会话的所有锁定,然后终止该服务进程,同时将PGA释放回操作系统.

网络故障:通过配置Oracle Net来杜绝.真挺一般情况下不崩溃,但同时接收到大量连接请求,也随时受不了.配置多个监听好一些.网络接口失败就得多配几个网卡了,网卡便宜么.同时为多个网卡配置多个监听.路由问题或局部网络失败,此时db运行正常,但就是连不上,能把你急死.如果服务器有两个以上的网络接口卡,将它们连接到物理上分离的子网是非常理想的(此句不懂,哪位懂的请指点一二).

用户错误:典型的是update没加where子句,然后又潇洒的提交了,此时dba杀你的心都有.此时闪回查询,山吹删除,闪回数据库和不完全恢复能解决这个问题.


来个例子说明一下闪回查询的用法之一:

delete  emp;

---------------------------------------

commit;

---------------------------------------

select  *    from   emp;

-----------------空-------------------

insert   into   emp (select * from  emp as  of  timestamp(sysdate  -  5/1440));

---------------------------------------

commit;

---------------------------------------

select * from   emp;

----------一切都恢复了-----------


======================


drop    table   emp

---------------------------------------

select  *   from    emp;
-----------------溜光----------------

flashback  table  emp  to  before  drop

---------------------------------------

select  *  from  emp;

------------数据又有了------------


以上方法能不用就别用,因为闪回后容易丢失在此期间的其它事务.本人经验:少用sql语句执行更改操作,尽量用编译的较成熟软件来操作,本人工作业务负责一些软件开发(初级开发,基本复制粘贴if esle用的最熟),出现数据问题尽量用软件操作更改,因为软件中内嵌的SQL代码编写的很严密,缺少where基本不可能.


介质失败:磁盘损坏,存储的文件也就跟着完了.但无论任何文件被破坏,那都不是损失数据的理由,看看第一句话是啥?!适当配置数据库,就可以在不丢失任何已提交数据的情况下恢复数据库的任何文件.删除文件也归类于介质错误——因为结果就是数据没了,跟磁盘坏了对数据库的影响是一样的.配置raid情况下介质损坏磁盘坏掉,这时需要归档日志来协助恢复.


实例失败:实例无序关闭,断电,服务器硬件重启,或硬件异常导致实例关闭,都叫实例失败.这种情况比较让人省心,只需执行startup即可,SMON发现文件不一致,会自动进行实例恢复.实例恢复也需要联机日志.记住喽,实例的任何崩溃都应当startup,此命令可解决所有问题.


为了保证数据库的最大可恢复性,必须多路复用控制文件;多路复用联机重做日志;必须以归档日志模式运行数据库,并多路复用归档日志文件;最后必须做常规备份.


控制文件很小,但很重要.它用于加载数据库,打开时可不断读写控制文件.(我公司习惯就不好,3个控制文件都在一个目录下,磁盘一坏全都完犊子.当然了,备份时会备份控制文件到别的路径.我仅仅想说的是最好还是放在不同的路径下,这样磁盘坏一个两个根本不需要太复杂的操作就会恢复.)添加或移动控制文件要关闭数据库.


来个例子

show parameter control_files
-----------------                      --------------------------------------------------------------------------------------------------
control_files                        string   D:\ORACLE\PRODUCT\10.2.0\ORADATA\BOB\CONTROL01.CTL, 
                                                            D:\ORACLE\PRODUCT\10.2.0\ORADATA\BOB\CONTROL02.CTL

-------------------------------------------------------------------------------------------------------------------------------------

shutdown immediate

关闭后操作系统命令复制出一个新的控制文件

-------------------------------------------------------------------------------------------------------------------------------------

startup nomount

-------------------------------------------------------------------------------------------------------------------------------------

alter system set control_files="D:\ORACLE\PRODUCT\10.2.0\ORADATA\BOB\CONTROL01.CTL, 
                                                        D:\ORACLE\PRODUCT\10.2.0\ORADATA\BOB\CONTROL02.CTL, 
                                                        D:\ORACLE\PRODUCT\10.2.0\ORADATA\BOB\CONTROL03.CTL" scope=spfile;

-------------------------------------------------------------------------------------------------------------------------------------

startup force

-------------------------------------------------------------------------------------------------------------------------------------

我有强迫症,所以sql写的美观,看着舒服,但实际命令不能这么写,大段的空格要去掉.



0 0