oracle 备份恢复 01备份恢复原理

2019独角兽企业重金招聘Python工程师标准>>>

一、备份原理
1.各种故障
    语句故障，用户异常断开，网络故障，误操作，实例故障，介质故障
    实例故障：断电，硬件故障，进程崩溃，非法关库 重启即可SMON自动恢复
    介质故障：磁盘，文件故障，文件有损坏
2.容灾：异地备份，防止自然灾害
3.DBA应对以上故障
    责任内事情：误操作，要求误操作及时报告，介质故障，其余故障发现后及时汇报
4.相关内存回顾
    large pool：备份的转储，100M即可，可随时改alter system set Large Pool Size=100M  
    java pool：使用java应用程序的都需要 20-50M即可
    uga：专用模式下载PGA里，共享模式下载shared pool里
    redo log buffer：个位数即可
    select * from v$sgainfo;
    自动内存管理模式下，可以手动指定各个子内存块的大小，为最小值；
5.检查点
    全局检查点：v$datafile的SCN， alter system checkpoint， 关库，open resetlogs三种情况下产生完全检查点；
    增量检查点：检查点队列管理，产生脏块后，切换覆盖日志的快慢 select group#,status from v$log; 
                alter system switch logfile;假写，待脏块达到脏队列的1/4满时才DBWR写
    部分检查点：脱机，只读，热备份，产生部分检查点，写脏块
6.DBWR写的条件
    发生检查点（全局检查点发生；部分检查点发生；增量检查点发生；）
    查找可覆盖的buffer时，已经扫描的数量达到一定程度， _db_block_max_scan_pct  一般40%
    脏到一定程度时 _db_large_dirty_queue  25%
    每隔3秒钟
    表空间脱机，只读，热备份时
    删除对象时
    select * from x$ksppcv where  indx in 
            (select indx from x$ksppi where ksppinm in 
            ('_shared_pool_reserved_pct','_shared_pool_reserved_min_alloc'));
    select kvittag,kvitval,kvitdsc from x$kvit where kvittag in('kcbldq','kcbfsp');
7.5个SCN，开库条件
    v$database,
    v$datafile,
    v$datafile_header  3个一样才能开库
    current_scn 当前数据库块里最大的SCN号v$database
    last_change#  正常未无穷大，mount状态下没有值时需要SMON恢复
8.跟踪实例恢复过程
    dump udump,bdump的目录，看alter日志
    A插入数据，B正常关库，启动到mount状态last_change#有值，且相同时，不用SMON干活，未提交的事务回滚
    A插入数据，B非法关库，不生成检查点，mount状态，没有值，SMON要干活了，恢复开库后仍没值
        Beginning crash recovery of 1 threads
         parallel recovery started with 2 processes
        Wed Jul 22 22:53:04 2015
        Started redo scan
        Wed Jul 22 22:53:04 2015
        Completed redo scan
         8354 redo blocks read, 560 data blocks need recovery
        Wed Jul 22 22:53:04 2015
        Started redo application at
         Thread 1: logseq 13, block 553
        Wed Jul 22 22:53:04 2015
        Recovery of Online Redo Log: Thread 1 Group 2 Seq 13 Reading mem 0
          Mem# 0 errs 0: /u01/app/oracle/oradata/ipemsdb/onlinelog/o1_mf_2_7p5b33sx_.log
          Mem# 1 errs 0: /u01/app/oracle/flash_recovery_area/ipemsdb/onlinelog/o1_mf_2_7p5b34v6_.log
        Wed Jul 22 22:53:04 2015
        Completed redo application
        Wed Jul 22 22:53:06 2015
        Completed crash recovery at
         Thread 1: logseq 13, block 8907, scn 2702757
         560 data blocks read, 560 data blocks written, 8354 redo blocks read
    crash recovery:崩溃
    instance failer:部分崩溃   
    扫描日志确认重做恢复，对未提交的事务回滚
    fast_start_mttr_target：崩溃恢复需要的时间，实例恢复时间，期望的秒数一般900最大值3600
    fast_start_io_target块数；log_checkpoint_interval，log_checkpoint_timeout日志量
    根据fast_start_mttr_target值生成不定期的检查点，非0即开启，设为1和3600看那个值最接近中间值，一般设置300,600,900
    alter system set fast_start_mttr_target=3600[1];
    select TARGET_MTTR,ESTIMATED_MTTR from v$instance_recovery;
9.开归档
    正常关库；
    创建归档目录；
    修改pfile中归档目录配置log_archive_dest_1='location=/u01/arc_dir  mandatory'；
    从pfile启动数据库到mount状态；startup mount pfile ''，或者通过pfile创建spfile直接启动;
    ALTER DATABASE ARCHIVELOG/noarchivelog; ARCHIVE  LOG  LIST  v$database的log_mode字段值
    ALTER  DATABASE  OPEN;
        不开归档，只能恢复到最后一次备份，归档可以恢复到最后一次提交，日志组的大小，15分钟切换一次，日
    志组成员500-800M之间，系统下降10%，开归档后，存储，管理，备份慢。    
9.归档与联机日志间的关联，默认序列号码相同
    select name,first_change#,next_change# from v$archived_log where thread#=1
    select GROUP# ,ARCHIVED,STATUS,FIRST_CHANGE# from v$log;

    

转载于:https://my.oschina.net/peakfang/blog/2245402