归档日志

--DM7 --DM6 （1）DM7数据库 DM7数据库通过系统配置文件dm.ini（ARCH_INI参数）和dmarch.ini来进行归档的配置。DM7数据库有多种归档方式，部署DMHS时，需要开启本地归档方式，最多可以设置8个本地归档。 Ø 查询DM7数据库是否开启了归档模式 SQL> select arch_mode from v$database; 行号 ARCH_MODE ---------- --------- 1 Y 已用时间: 2.984(毫秒). 执行号:11926314. SQL> Ø 查询DM7数据库的归档配置信息 SQL> select arch_name,arch_type,arch_dest,arch_file_size,arch_space_limit from v$dm_arch_ini; 行号 ARCH_NAME ARCH_TYPE ARCH_DEST ARCH_FILE_SIZE ARCH_SPACE_LIMIT ---------- -------------- --------- ---------------- -------------- ---------------- 1 ARCHIVE_LOCAL1 LOCAL /home/dmdba/arch 128 0 已用时间: 0.740(毫秒). 执行号:11926317. SQL>

当手工删除了归档日志以后，Rman备份会检测到日志缺失，从而无法进一步继续执行。 所以此时需要手工执行crosscheck过程，之后Rman备份可以恢复正常。 1.Crosscheck日志 $ rman target / Recovery Manager: Release 9.2.0.4.0 - 64bit Production Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved. connected to target database: AVATAR2 (DBID=2480694409) RMAN> crosscheck archivelog all; using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=25 devtype=DISK validation failed for archived log archive log filename=/opt/oracle/oradata/avatar2/archive/1_2714.dbf recid=2702 stamp=545107659 validation

(一)问题背景 最近在生产环境中，开发人员误操作，使用truncate将oracle数据库某个表的数据全部删除了，在删除之后，开发人员发现自己闯祸了，于是联系值班的DBA进行紧急数据恢复。 经过分析，表被truncate后，使用一般的闪回表、闪回查询、闪回事物等方法，是不可能将数据找回来的，可以使用闪回数据库、闪回数据归档的方法来进行恢复，但是通常在生产环境中，都不会开启这2个特性，所以剩下的只有使用RMAN进行数据恢复了。 对于使用RMAN进行数据恢复，可以在生产环境上直接进行，也可以恢复到其它机器上。 直接在生产环境上恢复：①需要停止生产数据库；②数据库需要保持一致性，比如说，我需要将数据库恢复到12：00，那么数据库中其他表的数据也将恢复到12点，有可能会丢失较多数据；③如果恢复过程中出现其它问题也比较麻烦，耽误了生产业务执行。 恢复到其它机器上：②不需要停生产库；②仅仅丢失truncate表的数据，比如说，我需要将数据库恢复到12：00，那么我只需将整个库在测试环境上恢复到12点，再将我们丢失表的数据通过DB_LINK或数据泵等方式恢复到生产环境，生产环境其它表的数据是不受影响的；③恢复失败，并不会影响到生产库。 所以，经过一番考虑，决定将数据库恢复到其它机器上，然后再将truncate表的数据导回到生产环境。 此次恢复操作是同事做的，在恢复过程中，由于流程不熟悉

一、 REPORT 1、报告目标 数据库的物理结构 RMAN>REPORT SCHEMA 2、报告需要备份的数据文件 在执行备份之前，常常需要取得需要备份的数据文件信息，通过执行REPORT NEED BACKUP 命令，可以列出需要备份的数据文件。当使用REPORT NEED BACKUP命令时，可以带有INCREMENTAL、DAYS、REDUNDANCY、RECOVERY WINDOW四个选项。 (1)报告需要转储的增量备份超出特定个数的数据文件 当恢复数据文件时，需要转储数据文件备份，然后应用归档日志执行恢复。如果备份数据文件采用了增量备份和累积备份策略，那么在转储数据文件时依次转储 0、1、2..级别的增量备份，转储的数据文件备份越多，恢复时间越长，下面以报告恢复数据文件需要转储的增量备份个数超过3次的数据文件为例： RMAN>REPORT NEED BACKUP INCREMENTAL 3 其中file用于标识数据文件的编号，Incrementals用于标识需要转储的备份文件个数，Name用于标识数据文件的名称，如果某个文件出现转储的次数大于3次， 应该在该数据文件上执行完全备份或增量0级备份。 (2)报告特定天数未备份的数据文件 当恢复数据文件时，在转储了所需的数据文件备份之后，会应用从备份点开始的所有归档日志。需要应用的归档日志越多，恢复时间越长，为了减少恢复时间

Oracle可以将Redo Log联机日志文件保存到多个不同的位置，将联机日志转换为归档日志的过程称之为归档，相应的日志被称为归档日志。归档日志可以用来恢复数据库，因此它记录着数据库的各种操作。 如果我们需要记录某个操作消耗多少REDO，可以通过如下方式： SQL> select name,value from (select b.name,a.value from v$mystat a,v$statname b where a.STATISTIC#=b.statistic#) where name='redo size' or name like 'undo change%'; NAME VALUE ---------------------------------------------------------------- ---------- redo size 0 undo change vector size 0 SQL> select * from test; A ---------- SQL> insert into test select rownum from dual connect by rownum<=10; 10 rows inserted SQL> commit; Commit complete SQL> select name,value from

原文: http://blog.gqylpy.com/gqy/465 置顶：来自一名75后老程序员的武林秘籍——必读 （博主推荐） 来，先呈上武林秘籍链接： http://blog.gqylpy.com/gqy/401/ 你好，我是一名极客！一个 75 后的老工程师！ 我将花两分钟，表述清楚我让你读这段文字的目的！ 如果你看过武侠小说，你可以把这个经历理解为，你失足落入一个山洞遇到了一位垂暮的老者！而这位老者打算传你一套武功秘籍！ 没错，我就是这个老者！ 干研发 20 多年了！我也年轻过，奋斗过！我会画原理图，会画 PCB，会模拟，会数字！玩过 PLC，玩过单片机，会用汇编，会用 C！玩过 ARM，比如 PLC，STM32，和时下正在起飞的 NXP RT1052！搞过 DSP，比如 TMS320F28335！搞过 FPGA，不管 Xilinx 还是 Altera，也不管是 Verilog 还是 VHDL，或者直接画数字电路图！我懂嵌入式系统，比如 uCOS 和 Linux！我懂开源的硬件，比如 Arduino 和树莓派!我也搞软件，学了一堆上位机的语言C#，JAVA，Python，Kotlin，Swift！会写爬虫工具，又自学写APP，不管Android 还是 IOS！ 可是这一切有什么用呢？土鸡瓦狗！不值一提！干技术的永远就是最苦逼的那个人！ 我相信看到这里的你，应该是个 IT

一、环境描述 12c 变化很大，目前上线的系统越来越多，大家需要不断更新自己的知识库。 On : 12.1.0.2 version, RAC can't delete archivelog ERROR ----------------------- RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process archived log file name=+ARCHDG/ESBDG/ARCHIVELOG/2018_01_11/thread_1_seq_1416.987.965165573 thread=1 sequence=1416 RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process archived log file 二、处理过程 1、备库无法删除归档可能是日志没有应用 2、参数设置不当，本例是参数设置问题 SYS@esbdg> show parameter log_archive_dest_2 NAME TYPE VALUE ------------------------------------ -----------

Oracle控制文件在缺失归档日志的情况下的恢复 众所周知，恢复控制文件时“recover database”命令可能需要使用归档日志。所谓缺失归档日志，是指控制文件从备份还原之后，在执行“recover database”命令恢复时报告找不到相应的日志导致恢复终止的情况。 这种情况下的恢复操作主要步骤如下： ①　 首先还原控制文件，方式不限 ②　 执行“recover database”命令将报RMAN-06054错误，即找不到某归档日志 ③　 查看相关的动态性能视图，对问题定位，确认问题与控制文件，而不是数据文件相关（与数据文件相关必须进行不完全恢复） ④　 利用create controlfile 命令重建控制文件 ⑤　 再次执行“recover database”命令，还会报RMAN-06054错误，这次是找不到另一个归档日志，其序列号应该大于第二步中的 ⑥　 查看v$log视图确定第5步中所要的是哪个日志 ⑦　 执行SQLPLUS的”recover database using backup controlfile“命令，等”Specify log：“提示符出现后给出正确的在线日志路径，直到命令成功结束。 ⑧　 以resetlogs方式打开数据库 ⑨　 由于创建的控制文件内不会有临时数据文件的信息，需要重新将其添加回临时表空间 ⑩　

pt-archiver使用记录 功能：将MySQL表中的行存档到另一个表或文件中 用法：pt-archiver [OPTIONS] --source DSN --where WHERE # 不记录操作到binlog日志中的方法set sql_log_bin=0; truncate table test_article; select count(*) from test_article; set sql_log_bin=1; # 例如：将所有行从10.192.30.53归档到10.192.30.60并且归档到文件： pt-archiver --source h=10.192.30.53,P=3306,u="admin_m",p="rA75MQy*R*y@KO4z%LZe",D=dbtest,t=test_article,A=UTF8 --charset=UTF8 \ --dest h=10.192.30.60,P=3306,u="admin",p="rA75MQyRyKO4zLZe",D=db53,t=test_article,A=UTF8 \ --file "/data01/archivelog/%Y-%m-%d-%D.%t" --where "1=1" --limit 1000 --commit-each --no-delete 注意：

1 设置数据库为归档模式 作者：沈小然 日期：2014-9-23 地点：北京 1.1 设置归档模式 1 ）首先查看数据库是否处于归档模式， Oracle 数据库默认处于非归档模式下 SQL> archive log list Database log mode No Archive Mode Automatic archival Disabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 175 Current log sequence 177 上面显示没有处于归档模式，我们设成归档模式 2 ）更改归档模式，需要在启动模式为 mount 状态才能设置 关闭数据库 SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. 启动 mount 状态 SQL> startup mount ORACLE instance started. Total System Global Area 2438529024 bytes Fixed Size 2230792 bytes Variable Size 1107297784 bytes Database Buffers