Logminer依赖于2个包:DBMS_LOGMNR和DBMS_LOGMNR_D,Oracle 11g默认已安装 Logminer 基本使用步骤 <1>. Specify a LogMiner dictionary.   指定Logminer字典 <2>. Specify a list of redo log files for analysis.   指定需要挖掘的redo或者archivelog日志文件 <3>. Start LogMiner.    开始日志挖掘

日志挖掘 log miner 6.1 log miner的作用: 数据库恢复中有时会需要对Redo log进行分析, 要会使用log miner,以便确定要恢复的时间点或SCN 6.2 有两种日志挖掘方法 针对DML和DDL,整理如下 : 6.2.1 对语句DML进行日志挖掘: 1)添加database补充日志SQL>ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; //注意:通过PL/SQL包的DML的日志挖掘,这步要先执行,在此之后的DML操作才能从日志里挖

Oracle 的Redo 机制DB的一个重要机制,理解这个机制对DBA来说也是非常重要,之前的Blog里也林林散散的写了一些,前些日子看老白日记里也有说明,所以结合老白日记里的内容,对oracle 的整个Redo log 机制重新整理一下. 一．Redo log 说明 Oracle 的Online redo log 是为确保已经提交的事务不会丢失而建立的一个机制. 因为这种健全的机制,才能让我们在数据库crash时,恢复数据,保证数据不丢失. 1.1 恢复分类 恢复分两种: (1)    Cra

Oracle重做日志(redo log)是用来记录操作条目,用于数据库数据恢复.为了提高效率,oracle通常建议设置三组redo log.本文将对重做日志组的状态以及多种状态之间切换做解析,力求掌握该知识点. 概述 oracle重做日志组通常有四种状态,即unused,inactive,active,current. unused:通常指从未被使用的日志组,即新添加的日志组. current:状态为LGWR进程正把redo log buffer的日志写进日志组中. active:为刚刚完成日志

以下易容翻译自oracle dba官方文档,不足之处还望指出. 管理重做日志文件 学习目标:1.解释重做日志文件的目的2.描述重做日志文件的结构3.学会控制日志切换与检查点4.多元化管理重做日志文件5.使用OMF管理重做日志文件 1.概念介绍:重做日志文件通过记录数据的所有改变情况对系统或介质故障提供恢复机制.1)重做日志文件以组的形式存在2)一个oracle数据库至少需要两组,每组至少有一文件3)在一组里的每一重做日志文件叫做成员The redo log files are used only

组提交(group commit)是MYSQL处理日志的一种优化方式,主要为了解决写日志时频繁刷磁盘的问题.组提交伴随着MYSQL的发展不断优化,从最初只支持redo log 组提交,到目前5.6官方版本同时支持redo log 和binlog组提交.组提交的实现大大提高了mysql的事务处理性能,下文将以innodb 存储引擎为例,详细介绍组提交在各个阶段的实现原理. redo log的组提交 WAL(Write-Ahead-Logging)是实现事务持久性的一个常用技术,基本原理是在提交事务

1.查看当前日志组成员: SQL> select member from v$logfile; MEMBER ------------------------------------------------------ C:\ORACLE\PRODUCT\10.2.0\ORADATA\FYDB\REDO01.LOG C:\ORACLE\PRODUCT\10.2.0\ORADATA\FYDB\REDO02.LOG C:\ORACLE\PRODUCT\10.2.0\ORADATA\FYDB\REDO

[ora11@lixora ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.1.0 Production on Wed Oct 8 09:57:50 2014 Copyright (c) 1982, 2009, Oracle.  All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Productio

检查点是一串递增的数字. 在两个检查点之间,存在有一个MLOG_FILE_NAME的文件,里面记录着space和路径和MLOG_CHECKPOINT的一个检查点. MLOG_FILE_NAME总是在上一次检查点flush之后开始记录下一个检查点之间的变化的. 如果在下一次检查点之前宕机的话,那么innodb引擎会检查到MLOG_CHECKPOINT和MLOG_FILE_NAME文件开始时的检查点,恢复的就是这段的数据. 如果recover中没有检测到MLOG_CHECKPOINT或者检测到多个M

http://blog.itpub.net/27039319/viewspace-2120623/ 11.2和11.2以下的区别:http://blog.itpub.net/27039319/viewspace-2120623/

在Data Guard环境中,Standby Redo Log是一个比较特殊的日志类型.从最新的DG安装指导中,都推荐在Primary和Standby端,都配置Standby Redo Log. 简单的说,Standby Redo Log就是在Standby端应用传递Redo Log过程中,逐步执行的online redo log.Standby端虽然也有online redo log,但是在redo apply应用的过程中,是不使用online redo log的.即使是11g Active

为保证重新创建的日志组成员可以成功创建,我们在删除日志组后需要手工删除对应的日志文件. 1.查看数据库当前REDO LOG日志相关信息1)查看日志组信息sys@ora10g> select * from v$log; GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS   FIRST_CHANGE# FIRST_TIME---------- ---------- ---------- ---------- ---------

因为数据仓库ETL过程中,某个mapping的执行时间超过了一个小时, select event,count(*) fromv$session_wait group by event order bycount(*) desc 发现日志切换占用了大量的时间,估尝试增大redo log的大小. (1) redo log的大小可以影响  DBWR 和 checkpoint : (2)larger redo log files provide better performance. Undersize

(1)redo log的大小可以影响 DBWR 和 checkpoint : (2)arger redo log files provide better performance. Undersized logfiles increase checkpoint activity and reduce performance.          大的log file可以提供更好的性能,小的logfile 会增加checkpoint 和降低性能: (3) A rough guide is to sw

日志系统主要有redo log(重做日志)和binlog(归档日志).redo log是InnoDB存储引擎层的日志,binlog是MySQL Server层记录的日志, 两者都是记录了某些操作的日志(不是所有)自然有些重复(但两者记录的格式不同). 图来自极客时间的mysql实践,该图是描述的是MySQL的逻辑架构. redo log日志模块 redo log是InnoDB存储引擎层的日志,又称重做日志文件,用于记录事务操作的变化,记录的是数据修改之后的值,不管事务是否提交都会记录下来.在实例

之前我们了解了一条查询语句的执行流程,并介绍了执行过程中涉及的处理模块.一条查询语句的执行过程一般是经过连接器.分析器.优化器.执行器等功能模块,最后到达存储引擎. 那么,一条 SQL 更新语句的执行流程又是怎样的呢? 首先我们创建一个表 user_info,主键为 id,创建语句如下: CREATE TABLE `T` ( `ID` int(11) NOT NULL, `c` int(11) DEFAULT NULL, PRIMARY KEY (`ID`) ) ENGINE=InnoDB DE

文章内容学习:极客时间-林晓彬老师-MySQL实战45讲 整理而得 我们知道MySQL数据库在发生意外宕机的情况下,可以将数据恢复到历史的某个时间点,能实现这个功能依靠的是日志,MySQL提供两种类型的日志,也是两个模块中的日志,分别是存储引擎中的日志(redo log(重做日志))和Server层的日志(binlog(归档日志)) redo log MySQL在执行一条更新语句的时候,需要更新内存中的数据,然后在更新磁盘中的数据,这里运用到了WAL技术,全称是Write-Ahead Loggi

@ 目录 redo log(物理日志\重做日志) binlog(逻辑日志/归档日志) update语句执行流程 Uodolog(回滚日志/重做日志) undo log+redo log保证持久性 redo log(物理日志\重做日志) redo log是InnoDB存储引擎层的日志,又称重做日志文件,是物理日志.redo log记录数据修改后新数据的备份.冗杂的undo log.未提交的事务和回滚的事务,数据缓存到内存中,只是在事务提交前将redo log持久化到磁盘 redo log 可以保证

Data Guard在最大保护和最高可用性模式下,Standby数据库必须配置standby redo log,通过下面的实验展示创建的原则和过程. 1.原则1).standby redo log的文件大小与primary 数据库online redo log 文件大小相同2).standby redo log日志文件组的个数依照下面的原则进行计算    Standby redo log组数公式>=(每个instance日志组个数+1)*instance个数    例如在我的环境中,只有一个节点

全文建立在MySQL的存储引擎为InnoDB的基础上 先看一条SQL如何入库的: 这是一条很简单的更新SQL,从MySQL服务端接收到SQL到落盘,先后经过了MySQL Server层和InnoDB存储引擎. Server层就像一个产品经理,分析客户的需求,并给出实现需求的方案. InnoDB就像一个基层程序员,实现产品经理给出的具体方案. 在MySQL"分析需求,实现方案"的过程中,还夹杂着内存操作和磁盘操作,以及记录各种日志. 他们到底有什么用处?他们之间到底怎么配合的?MySQL

前言 InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性. 和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文件前,保证之前的redo日志已经写到磁盘. LSN(log sequence number) 用于记录日志序号,它是一个不断递增的 unsigned long long 类型整数.在 InnoDB 的日志