数据库erp数据日志关闭

关闭ERP系统的数据日志记录可能会对系统数据的追踪和安全性产生负面影响，因此建议您在 *** 作之前谨慎考虑。

如果您确定需要关闭ERP系统的数据日志记录，请根据您所使用的ERP系统类型和版本，在系统设置或管理界面中寻找相关选项进行关闭。通常的步骤如下：

登录ERP系统管理员账户，找到系统设置或管理界面。

在设置或管理界面中，找到数据日志记录相关选项。

如果有开关选项，将其关闭即可停止记录数据日志。

如果没有开关选项，可以尝试在系统配置文件或数据库中修改相关参数来关闭数据日志记录。

请注意，在关闭ERP系统的数据日志记录之前，最好备份相关数据以防止数据丢失或遗漏。如果您不确定如何关闭数据日志记录，建议咨询相关技术支持人员或ERP系统的开发商。

本文以数据库的基本原理为基础，分析了EXCHANGE SERVER的存储系统，并说明了各部分的作用。

一、IS服务和ESE的层次关系

IS服务是EXCHANGE服务器中重要的服务之一，它控制着对邮箱和PF的存储 *** 作请求，EXCHANGE服务器的存储实际上是由ESE的数据库引擎来管理的。这个ESE引擎是微软专门为保存非关系型数据而开发的，目前在微软的很多产品中都有广泛的应用，如：AD数据库、DHCP、WINS、SRS等等。

EXCHANGE的数据库是由EDB文件、STM文件和LOG文件组成。在这些文件里，微软使用了“B+树”的内部数据结构。ESE的引擎的任务之一，就是当IS服务请求访问数据库的时候，把这些请求转化为对内部数据结构的读写访问。B+树的特点是能够对存储在硬盘上的数据提供快速访问能力。微软利用“B+树”作为ESE的后台结构的主要原因，就是尽可能的提高访问数据时I/O性能。当然，这些结构对于EXCHANGE STORE来说是透明的。

另外，作为一个数据库系统，ESE有责任提供事务级别的 *** 作的支持，并维护数据库的完整性和一致性。对数据库系统而言，我们提到事务时，一般用ACID来描述事务的特点。

A--Atomic（原子的）：事务必须是全或全无的 *** 作，要么全部成功更新，要么全部不被更新

C--Consistent（一致的）：一个成功提交的事务必须使数据库处于一个一致的状态。

I--Isolated（孤立的）：所有未提交的更改都必须能够和其他事务孤立。

D--Durable（持久的）：当事务一旦提交，所做的更改必须存储到稳定的介质上，防止系统失败导致的数据库不一致。（此点非常重要！！）

二、EXCHANGE 2000/2003存储系统的新特点

在EX55中，ESE的版本为ESE97，而在EX2000/2003里，ESE版本已经升级ESE98了。ESE引起在以下方面得到了改进：

I/O性能进一步提高和优化

对日志文件增加了计算校验 *** 作

提高了ESEUTIL等工具的维护速度

而IS也在以下方面有了更新：

在每个SERVER上提供多个SG支持

数据库STM文件格式的引入，提高了INTERNET邮件的性能

WSS的引入，用户可以使用多种协议访问数据库

三、EDB和STM的关系

常有人问，EDB文件是数据库，那STM文件是做什么用的？可以删除吗？

在EX55里，只有EDB文件，因为在EX55发布时，微软主推的是内部邮件系统，因此其主要协议为MAPI，这是微软的私有邮件西医，EDB文件是专门为此协议优化过的。因此在EX55中，为了支持INTERNET邮件，必须在每次处理INTERNET邮件时，做一个格式转换。这显然带来了性能的损失。

在EX2000里，微软加大了对INTERNET邮件的支持，这就是STM文件的来源。MAPI格式是RPC和二进制标准的，而STM是纯文本加上一些MIME编码格式，这样的区别使得它们不可能存储在同一数据库里。因此EX2000中，微软开始使用EDB和STM两个文件来分别保存两种格式的邮件。并且在两个文件之间建立了引用和关联。对于用户来说，它的邮箱实际上是跨越了EDB和STM文件共同组成的。另外，需要注意的是，EDB文件中还保留着用户的邮箱结构。所以EDB文件更加重要。那么EDB和STM是怎么协同工作的呢？我们以几个情景来分析之。

情景一：用户使用OUTLOOK（MAPI）发送接收邮件

在该情景下，用户将邮件通过MAPI协议提交给数据库，直接被保存EDB文件中。当用户通过MAPI访问邮箱里的邮件时，如果被访问的邮件在EDB里，直接返回，如果在STM里（如外来邮件），则执行转换，将STM转换为EDB文件格式，再返回用户。

情景二：用户使用标准SMTP/POP3/IMAP4等协议访问

用户使用非MAPI协议提交的邮件，内容保存在STM文件里，但是由于EDB里有邮箱结构，STM没有，因此系统会把邮件的重要信息提取出来，放在EDB里。当用户用MAPI提取邮件时，过程同上，当用户通过标准协议访问时，同样需要进行格式转换，转换为STM文件格式返回。 这些转换是在后台发生的。对用户来说是透明的。通过上面的描述，你会看到，这两个文件是紧密联系的缺一不可。所以，在任何时间我们都不要单独 *** 作这两个文件，它们是一个整体。同时也要注意的是，无论用户使用何方式访问邮箱，都需要向EDB文件请求邮箱结构信息，这是需要注意的。

四、LOG文件的重大作用

在论坛里经常会看到有人说我的硬盘怎么很快就没了，一看原来是日志文件搞的鬼，于是就有人删除日志文件，甚至使用循环日志来强制减少日志，甚至有人提出这样的疑问，日志到底有什么用？是不是多余的'？那我们来看看日志的重大作用。

对于一个SG来说，系统会产生一系列的日志，这些日志的扩展名为LOG，前缀一般是E00、E01……除了这些连续的日志文件外，还有一些特殊的日志文件（res1log,res2log,e0xchk））），它们又有什么用呢？我们的管理员通常不喜欢备份这一 *** 作，因此对这些日志是痛恨不已啊。那么微软在EXCHANGE数据库系统中引入日志的作用难道真的是多此一举吗？我们从以下几个方面来考察一下日志的作用：

1、作为一个企业级的邮件系统，必须要保证数据安全和完整。必须能够面对随时可能发生的意外灾难，把数据损失降低到最小。

2、必须提供高性能的邮件处理能力，对数据库中的邮件的事务 *** 作在完成后必须马上（或是说立即）被记录在存储介质上（见前面的事务持久性说明）

3、灾难发生后，使用数据库备份恢复必须要返回到灾难发生前一刻的数据库状态（这是至关重要的！！）

现在我们来更进一步的看一下，当用户要修改邮箱中的内容时，被修改的内容首先被提取出来放到内存中，实际的修改是发生在内存里的，这是众所周知的，当修改完成后，这些内容必须被尽快写回存储介质，这样才表示一个事务成功完成了。

从事务的描述中我们可以看到，事务是具有原子特性的，为了保证数据库的一致和完整，事务必须全部成功或全部失败，如果事务失败，则必须回滚到事务开始的状态。而当邮件在内存中修改完成后，此时事务并没有完成（为什么呢？）因为一旦系统崩溃，这些修改就丢失了。所以要确保事务修改完成，必须尽快将修改写回到数据库里去（也就是硬盘上）。这也是事务的持久性要求。注意，我们这里说的第一时间或是尽快，是一个什么样的概念。如果我们直接修改EDB文件，由于EDB

文件比较大，那么在硬盘上修改一个大文件，就 需要花费大量的时间在等待和寻找数据存储块上（见 *** 作系统原理），当系统出现高负载的繁忙状态时，这将是一个非常大的瓶颈。也就无法做到“尽快”了。那怎么办呢？所以数据库系统使用了日志，而日志通常很小（EXCHANGE的日志只有5MB），向这些文件写入修改结果是很快速的，因此当内存的修改完成后，这些结果就会立即写入日志中，以保证了事务的持久性。当成功写入日志后，该事务就成功完成了（现在在硬盘上了，不会因为当机丢失了）接下来，ESE引擎会在后台慢慢将这些日志里的修改记录写回真正的数据库里去（这对用户来说已经不是那么重要了），这就是日志的第一个作用：确保事务在第一时间（尽可能快的）保存到非易失存储器上（提供了事务持久性支持）。

根据上面的藐视，我们看到运行中的EXCHANGE数据库，是由三个部分组成的：

内存中已经完成处理还没有写会到日志里的内容（Dirt page）

还没有写到数据库文件里的日志内容

EDB和STM数据库文件

对于第一个部分，一旦掉电就回丢失的，是最不安全的。而对于第二部分的内容，系统通过检查点文件（CHK）来标记哪些日志已经被写入数据库了，而哪些还没有。CHK文件类似一个指针。我们可以用“ESEUTIL /MK”来检查CHK文件里的内容，在该命令的输出中的checkpoint:<0x8,26d1,29>这样的东西就是检查点位置，它表示E0x00008的日志的页面序号已经被成功写入数据库了。大家可以自己看看。。：）

前面提到过，EXCHANGE系统在出现灾难时，应能恢复到灾难发生前的时刻的状态。这是非常重要的。但即使是最勤快的管理员，也只能在指定的预定时间内做系统备份，而不可能时时刻刻的都在备份。那么在备份完成后到灾难发生之前的这段数据该如何保护呢？是不是就任由它丢失呢？显然是不可能的。那答案是什么呢？就是日志文件。前面我们知道，任何对数据库的更改都先写入日志里，再由日志写入数据库，这样我们只要找到日志文件，就可以重新进行模拟的 *** 作来完成备份后的数据库文件的更改了，我们举个例子来看看：

假设我们在凌晨3点完成了一次FULLBACKUP，备份完成后，系统正常运行，到下午4点的时候，系统突然崩溃。管理员用凌晨3点的数据恢复了数据库，那么从凌晨3点到下午4点这段时间的数据变更，就只能依赖于日志了。当完成数据库恢复后，系统会自动的跟踪到关联的日志文件，如果发现有比当前数据库还新的日志存在，系统就会自动的按照日志的顺序将更改写回到数据库中去。因此这样一来，从凌晨3点到下午4点的数据变更就被完整的恢复了。这就是日志的第二个作用：保证系统备份和恢复的完整性。当然前提是没有使用循环日志！！（看到了吧，使用循环日志的危害是相当大的，比起你的数据来说，多做几次备份不是没有意义的吧？

说到这里，有人可能要问，如果数据库和日志同时损坏，如何办？答案是：尽量避免这样的情况发生。首先数据库损坏的几率要大于日志，另外，微软建议将数据库和日志分别存储在不同的磁盘上，要是这样还会同时坏，那就没有办法了，呵呵。。对于管理员对日志文件的抱怨，合理的解决方法是定期做备份。启用循环日志是不正确的做法，当启用循环日志后，一旦系统发生灾难恢复，将有可能不能将系统恢复到灾难发生时的状态，磁盘和数据谁更重要，管理员自己要考虑考虑了。

五、ESE与IS服务的启动和关闭

ESE引擎在加载数据库文件时，会去检查数据库文件的标志。这个标志保留了上次关闭数据库的状态，当状态为正常关闭说，系统将直接加载该数据库，当数据库标志为非正常关闭时，系统将先进行一个软恢复过程（你可以在事件里看到它），然后再加载。

那么，正常关闭和非正常关闭有什么区别呢？一个正常关闭的数据库，表示所有的日志信息都已经正确的写入数据库了。反之一个非正常关闭的数据库，则表示至少有一部分数据未能正确的从日志写入数据库。要注意的是，非正常关闭的数据库并不等于已经被破坏的数据库。只表示有数据没有提交到数据库文件。

使用ESEUTIL/MH命令可以看到数据库的该状态，其中的STATE字段标记的就是这个状态，“CLEANSHUTDOWN”表示数据库正常关闭。当系统加载处于非正常关闭的数据库时，就会根据检查点文件确定日志文件的位置，并做重放 *** 作。当检查点文件丢失或损坏时，系统将从最早的日志文件开始处理。有的时候，系统不能自动的修复数据库，这时我们也可以用“ESEUTIL /R”命令手工的恢复处于非正常关闭状态的数据库。强烈推荐在系统异常关闭后执行此命令。在执行前最好前确定数据库文件的状态确实为非正常关闭，不要对正常关闭的数据库执行该恢复命令！

由此可见，EXCHANGE系统对数据库有自我修复能力，能确保系统在发生意外后恢复正确的状态。但这并不是说我们可以随意的关闭系统，仍要UPS等必要的保护措施。

六、关于M盘

在EX2000里，有一个M盘的映射。这个映射只是提供开发人员通过API访问邮箱和邮件用的。因此对M盘的手工 *** 作都可能带来数据库的破坏，请注意，另外，有一种观点认为备份了M盘就备份了邮件，这是绝对错误的。M盘虽然是数据库的映射，但已经去掉了很多的关联和内在联系。因此备份M盘是不能恢复数据库的。所有的EXCHANGE管理员必须按规定认真的备份系统状态和SG。切不可偷懒哦。

1、SQL语句执行流程

MySQL大体上可分为Server层和存储引擎层两部分。

Server层：

连接器：TCP握手后服务器来验证登陆用户身份，A用户创建连接后，管理员对A用户权限修改了也不会影响到已经创建的链接权限，必须重新登陆。

查询缓存：查询后的结果存储位置，MySQL80版本以后已经取消，因为查询缓存失效太频繁，得不偿失。

分析器：根据语法规则，判断你输入的这个SQL语句是否满足MySQL语法。

优化器：多种执行策略可实现目标，系统自动选择最优进行执行。

执行器：判断是否有权限，将最终任务提交到存储引擎。

存储引擎层

负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 555版本开始成为了默认存储引擎(经常用的也是这个)。

SQL执行顺序

2、BinLog、RedoLog、UndoLog

BinLog

BinLog是记录所有数据库表结构变更（例如create、alter table）以及表数据修改(insert、update、delete)的二进制日志，主从数据库同步用到的都是BinLog文件。BinLog日志文件有三种模式。

STATEMENT 模式

内容：binlog 记录可能引起数据变更的 sql 语句

优势：该模式下，因为没有记录实际的数据，所以日志量很少 IO 都消耗很低，性能是最优的

劣势：但有些 *** 作并不是确定的，比如 uuid() 函数会随机产生唯一标识，当依赖 binlog 回放时，该 *** 作生成的数据与原数据必然是不同的，此时可能造成无法预料的后果。

ROW 模式

内容：在该模式下，binlog 会记录每次 *** 作的源数据与修改后的目标数据，StreamSets就要求该模式。

优势：可以绝对精准的还原，从而保证了数据的安全与可靠，并且复制和数据恢复过程可以是并发进行的

劣势：缺点在于 binlog 体积会非常大，同时，对于修改记录多、字段长度大的 *** 作来说，记录时性能消耗会很严重。阅读的时候也需要特殊指令来进行读取数据。

MIXED 模式

内容：是对上述STATEMENT 跟 ROW 两种模式的混合使用。

细节：对于绝大部分 *** 作，都是使用 STATEMENT 来进行 binlog 没有记录，只有以下 *** 作使用 ROW 来实现：表的存储引擎为 NDB，使用了uuid() 等不确定函数，使用了 insert delay 语句，使用了临时表

主从同步流程：

1、主节点必须启用二进制日志，记录任何修改了数据库数据的事件。

2、从节点开启一个线程（I/O Thread)把自己扮演成 mysql 的客户端，通过 mysql 协议，请求主节点的二进制日志文件中的事件 。

3、主节点启动一个线程（dump Thread），检查自己二进制日志中的事件，跟对方请求的位置对比，如果不带请求位置参数，则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。

4、从节点接收到主节点发送过来的数据把它放置到中继日志（Relay log）文件中。并记录该次请求到主节点的具体哪一个二进制日志文件内部的哪一个位置（主节点中的二进制文件会有多个）。

5、从节点启动另外一个线程（sql Thread ），把 Relay log 中的事件读取出来，并在本地再执行一次。

mysql默认的复制方式是异步的，并且复制的时候是有并行复制能力的。主库把日志发送给从库后不管了，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念。

全同步复制

主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响。

半同步复制

半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写 *** 作完成。

还可以延伸到由于主从配置不一样、主库大事务、从库压力过大、网络震荡等造成主备延迟，如何避免这个问题？主备切换的时候用可靠性优先原则还是可用性优先原则？如何判断主库Crash了？互为主备的情况下如何避免主备循环复制？被删库跑路了如何正确恢复？( o )… 感觉越来越扯到DBA的活儿上去了。

RedoLog

可以先通过下面demo理解：

饭点记账可以把账单写在账本上也可以写在粉板上。有人赊账或者还账的话，一般有两种做法：

1、直接把账本翻出来，把这次赊的账加上去或者扣除掉。

2、先在粉板上记下这次的账，等打烊以后再把账本翻出来核算。

生意忙时选后者，因为前者太麻烦了。得在密密麻麻的记录中找到这个人的赊账总额信息，找到之后再拿出算盘计算，最后再将结果写回到账本上。

同样在MySQL中如果每一次的更新 *** 作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本、查找成本都很高。而粉板和账本配合的整个过程就是MySQL用到的是Write-Ahead Logging 技术，它的关键点就是先写日志，再写磁盘。此时账本 = BinLog，粉板 = RedoLog。

1、 记录更新时，InnoDB引擎就会先把记录写到RedoLog（粉板）里面，并更新内存。同时，InnoDB引擎会在空闲时将这个 *** 作记录更新到磁盘里面。

2、 如果更新太多RedoLog处理不了的时候，需先将RedoLog部分数据写到磁盘，然后擦除RedoLog部分数据。RedoLog类似转盘。

RedoLog有write pos 跟checkpoint

write pos ：是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。

check point：是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

write pos和check point之间的是粉板上还空着的部分，可以用来记录新的 *** 作。如果write pos追上checkpoint，表示粉板满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint推进一下。

有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。 redolog两阶段提交：为了让binlog跟redolog两份日志之间的逻辑一致。提交流程大致如下：

1 prepare阶段 --> 2 写binlog --> 3 commit

当在2之前崩溃时，重启恢复后发现没有commit，回滚。备份恢复：没有binlog 。一致

当在3之前崩溃时，重启恢复发现虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。备份：有binlog 一致

binlog跟redolog区别：

redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。

redo log是物理日志，记录的是在某个数据页上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如给ID=2这一行的c字段加1。

redo log是循环写的，空间固定会用完；binlog是可以追加写入的。追加写是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

UndoLog

UndoLog 一般是逻辑日志，主要分为两种：

insert undo log

代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃

update undo log

事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

3、MySQL中的索引

索引的常见模型有哈希表、有序数组和搜索树。

哈希表：一种以KV存储数据的结构，只适合等值查询，不适合范围查询。

有序数组：只适用于静态存储引擎，涉及到插入的时候比较麻烦。可以参考Java中的ArrayList。

搜索树：按照数据结构中的二叉树来存储数据，不过此时是N叉树(B+树)。广泛应用在存储引擎层中。

B+树比B树优势在于：

B+ 树非叶子节点存储的只是索引，可以存储的更多。B+树比B树更加矮胖，IO次数更少。

B+ 树叶子节点前后管理，更加方便范围查询。同时结果都在叶子节点，查询效率稳定。

B+树中更有利于对数据扫描，可以避免B树的回溯扫描。

索引的优点：

1、唯一索引可以保证每一行数据的唯一性

2、提高查询速度

3、加速表与表的连接

4、显著的减少查询中分组和排序的时间

5、通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。

索引的缺点：

1、创建跟维护都需要耗时

2、创建索引时，需要对表加锁，在锁表的同时，可能会影响到其他的数据 *** 作

3、 索引需要磁盘的空间进行存储，磁盘占用也很快。

4、当对表中的数据进行CRUD的时，也会触发索引的维护，而维护索引需要时间，可能会降低数据 *** 作性能

索引设计的原则不应该：

1、索引不是越多越好。索引太多，维护索引需要时间跟空间。

2、 频繁更新的数据，不宜建索引。

3、数据量小的表没必要建立索引。

应该：

1、重复率小的列建议生成索引。因为重复数据少，索引树查询更有效率，等价基数越大越好。

2、数据具有唯一性，建议生成唯一性索引。在数据库的层面，保证数据正确性

3、频繁group by、order by的列建议生成索引。可以大幅提高分组和排序效率

4、经常用于查询条件的字段建议生成索引。通过索引查询，速度更快

索引失效的场景

1、模糊搜索：左模糊或全模糊都会导致索引失效，比如'%a'和'%a%'。但是右模糊是可以利用索引的，比如'a%' 。

2、隐式类型转换：比如select from t where name = xxx , name是字符串类型，但是没有加引号，所以是由MySQL隐式转换的，所以会让索引失效 3、当语句中带有or的时候：比如select from t where name=‘sw’ or age=14

4、不符合联合索引的最左前缀匹配：(A,B,C)的联合索引，你只where了C或B或只有B,C

关于索引的知识点：

主键索引：主键索引的叶子节点存的是整行数据信息。在InnoDB里，主键索引也被称为聚簇索引（clustered index）。主键自增是无法保证完全自增的哦，遇到唯一键冲突、事务回滚等都可能导致不连续。

唯一索引：以唯一列生成的索引，该列不允许有重复值，但允许有空值(NULL)

普通索引跟唯一索引查询性能：InnoDB的数据是按数据页为单位来读写的，默认每页16KB，因此这两种索引查询数据性能差别微乎其微。

change buffer：普通索引用在更新过程的加速，更新的字段如果在缓存中，如果是普通索引则直接更新即可。如果是唯一索引需要将所有数据读入内存来确保不违背唯一性，所以尽量用普通索引。

非主键索引：非主键索引的叶子节点内容是主键的值。在InnoDB里，非主键索引也被称为二级索引（secondary index）

回表：先通过数据库索引扫描出数据所在的行，再通过行主键id取出索引中未提供的数据，即基于非主键索引的查询需要多扫描一棵索引树。

覆盖索引：如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为覆盖索引。

联合索引：相对单列索引，组合索引是用多个列组合构建的索引，一次性最多联合16个。

最左前缀原则：对多个字段同时建立的组合索引(有顺序，ABC，ACB是完全不同的两种联合索引) 以联合索引(a,b,c)为例，建立这样的索引相当于建立了索引a、ab、abc三个索引。另外组合索引实际还是一个索引，并非真的创建了多个索引，只是产生的效果等价于产生多个索引。

索引下推：MySQL 56引入了索引下推优化，可以在索引遍历过程中，对索引中包含的字段先做判断，过滤掉不符合条件的记录，减少回表字数。

索引维护：B+树为了维护索引有序性涉及到页分裂跟页合并。增删数据时需考虑页空间利用率。

自增主键：一般会建立与业务无关的自增主键，不会触发叶子节点分裂。

延迟关联：通过使用覆盖索引查询返回需要的主键，再根据主键关联原表获得需要的数据。

InnoDB存储: frm文件是一份定义文件，也就是定义数据库表是一张怎么样的表。ibd文件则是该表的索引，数据存储文件，既该表的所有索引树，所有行记录数据都存储在该文件中。

MyISAM存储： frm文件是一份定义文件，也就是定义数据库表是一张怎么样的表。 MYD文件是MyISAM存储引擎表的所有行数据的文件。 MYI文件存放的是MyISAM存储引擎表的索引相关数据的文件。MyISAM引擎下，表数据和表索引数据是分开存储的。

MyISAM查询：在MyISAM下，主键索引和辅助键索引都属于非聚簇索引。查询不管是走主键索引，还是非主键索引，在叶子结点得到的都是目的数据的地址，还需要通过该地址，才能在数据文件中找到目的数据。

PS：InnoDB支持聚簇索引，MyISAM不支持聚簇索引

4、SQL事务隔离级别

ACID的四个特性

原子性（Atomicity）：把多个 *** 作放到一个事务中，保证这些 *** 作要么都成功，要么都不成功

一致性（Consistency）：理解成一串对数据进行 *** 作的程序执行下来，不会对数据产生不好的影响，比如凭空产生，或消失

隔离性（Isolation，又称独立性）：隔离性的意思就是多个事务之间互相不干扰，即使是并发事务的情况下，他们只是两个并发执行没有交集，互不影响的东西；当然实现中，也不一定需要这么完整隔离性，即不一定需要这么的互不干扰，有时候还是允许有部分干扰的。所以MySQL可以支持4种事务隔离性

持久性（Durability）：当某个 *** 作 *** 作完毕了，那么结果就是这样了，并且这个 *** 作会持久化到日志记录中

PS：ACID中C与CAP定理中C的区别

ACID的C着重强调单数据库事务 *** 作时，要保证数据的完整和正确性，数据不会凭空消失跟增加。CAP 理论中的C指的是对一个数据多个备份的读写一致性

事务 *** 作可能会出现的数据问题

1、脏读(dirty read)：B事务更改数据还未提交，A事务已经看到并且用了。B事务如果回滚，则A事务做错了

2、 不可重复读(non-repeatable read)：不可重复读的重点是修改: 同样的条件, 你读取过的数据, 再次读取出来发现值不一样了，只需要锁住满足条件的记录

3、 幻读(phantom read)：事务A先修改了某个表的所有纪录的状态字段为已处理，未提交；事务B也在此时新增了一条未处理的记录，并提交了；事务A随后查询记录，却发现有一条记录是未处理的造成幻读现象，幻读仅专指新插入的行。幻读会造成语义上的问题跟数据一致性问题。

4、 在可重复读RR隔离级别下，普通查询是快照读，是不会看到别的事务插入的数据的。因此，幻读在当前读下才会出现。要用间隙锁解决此问题。

在说隔离级别之前，你首先要知道，你隔离得越严实，效率就会越低。因此很多时候，我们都要在二者之间寻找一个平衡点。SQL标准的事务隔离级别由低到高如下： 上图从上到下的模式会导致系统的并行性能依次降低，安全性依次提高。

读未提交：别人改数据的事务尚未提交，我在我的事务中也能读到。

读已提交(Oracle默认)：别人改数据的事务已经提交，我在我的事务中才能读到。

可重复读(MySQL默认)：别人改数据的事务已经提交，我在我的事务中也不去读，以此保证重复读一致性。

串行：我的事务尚未提交，别人就别想改数据。

标准跟实现：上面都是关于事务的标准，但是每一种数据库都有不同的实现，比如MySQL InnDB 默认为RR级别，但是不会出现幻读。因为当事务A更新了所有记录的某个字段，此时事务A会获得对这个表的表锁，因为事务A还没有提交，所以事务A获得的锁没有释放，此时事务B在该表插入新记录，会因为无法获得该表的锁，则导致插入 *** 作被阻塞。只有事务A提交了事务后，释放了锁，事务B才能进行接下去的 *** 作。所以可以说 MySQL的RR级别的隔离是已经实现解决了脏读，不可重复读和幻读的。

5、MySQL中的锁

无论是Java的并发编程还是数据库的并发 *** 作都会涉及到锁，研发人员引入了悲观锁跟乐观锁这样一种锁的设计思想。

悲观锁：

优点：适合在写多读少的并发环境中使用，虽然无法维持非常高的性能，但是在乐观锁无法提更好的性能前提下，可以做到数据的安全性

缺点：加锁会增加系统开销，虽然能保证数据的安全，但数据处理吞吐量低，不适合在读书写少的场合下使用

乐观锁：

优点：在读多写少的并发场景下，可以避免数据库加锁的开销，提高DAO层的响应性能，很多情况下ORM工具都有带有乐观锁的实现，所以这些方法不一定需要我们人为的去实现。

缺点：在写多读少的并发场景下，即在写 *** 作竞争激烈的情况下，会导致CAS多次重试，冲突频率过高，导致开销比悲观锁更高。

实现：数据库层面的乐观锁其实跟CAS思想类似， 通数据版本号或者时间戳也可以实现。

数据库并发场景主要有三种：

读-读：不存在任何问题，也不需要并发控制

读-写：有隔离性问题，可能遇到脏读，幻读，不可重复读

写-写：可能存更新丢失问题，比如第一类更新丢失，第二类更新丢失

两类更新丢失问题：

第一类更新丢失：事务A的事务回滚覆盖了事务B已提交的结果 第二类更新丢失：事务A的提交覆盖了事务B已提交的结果

为了合理贯彻落实锁的思想，MySQL中引入了杂七杂八的各种锁：

锁分类

MySQL支持三种层级的锁定，分别为

表级锁定

MySQL中锁定粒度最大的一种锁，最常使用的MYISAM与INNODB都支持表级锁定。

页级锁定

是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁，表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。

行级锁定

Mysql中锁定粒度最细的一种锁，表示只针对当前 *** 作的行进行加锁。行级锁能大大减少数据库 *** 作的冲突。其加锁粒度最小，但加锁的开销也最大行级锁不一定比表级锁要好：锁的粒度越细，代价越高，相比表级锁在表的头部直接加锁，行级锁还要扫描找到对应的行对其上锁，这样的代价其实是比较高的，所以表锁和行锁各有所长。

MyISAM中的锁

虽然MySQL支持表，页，行三级锁定，但MyISAM存储引擎只支持表锁。所以MyISAM的加锁相对比较开销低，但数据 *** 作的并发性能相对就不高。但如果写 *** 作都是尾插入，那还是可以支持一定程度的读写并发

从MyISAM所支持的锁中也可以看出，MyISAM是一个支持读读并发，但不支持通用读写并发，写写并发的数据库引擎，所以它更适合用于读多写少的应用场合，一般工程中也用的较少。

InnoDB中的锁

该模式下支持的锁实在是太多了，具体如下：

共享锁和排他锁 (Shared and Exclusive Locks)

意向锁（Intention Locks）

记录锁（Record Locks）

间隙锁（Gap Locks）

临键锁 （Next-Key Locks）

插入意向锁（Insert Intention Locks）

主键自增锁 (AUTO-INC Locks)

空间索引断言锁（Predicate Locks for Spatial Indexes）

举个栗子，比如行锁里的共享锁跟排它锁：lock in share modle 共享读锁：

为了确保自己查到的数据没有被其他的事务正在修改，也就是说确保查到的数据是最新的数据，并且不允许其他人来修改数据。但是自己不一定能够修改数据，因为有可能其他的事务也对这些数据使用了 in share mode 的方式上了S 锁。如果不及时的commit 或者rollback 也可能会造成大量的事务等待。

for update排它写锁:

为了让自己查到的数据确保是最新数据，并且查到后的数据只允许自己来修改的时候，需要用到for update。相当于一个 update 语句。在业务繁忙的情况下，如果事务没有及时的commit或者rollback 可能会造成其他事务长时间的等待，从而影响数据库的并发使用效率。

Gap Lock间隙锁：

1、行锁只能锁住行，如果在记录之间的间隙插入数据就无法解决了，因此MySQL引入了间隙锁(Gap Lock)。间隙锁是左右开区间。间隙锁之间不会冲突。

2、间隙锁和行锁合称NextKeyLock，每个NextKeyLock是前开后闭区间。

间隙锁加锁原则(学完忘那种)：

1、加锁的基本单位是 NextKeyLock，是前开后闭区间。

2、查找过程中访问到的对象才会加锁。

3、索引上的等值查询，给唯一索引加锁的时候，NextKeyLock退化为行锁。

4、索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，NextKeyLock退化为间隙锁。

5、唯一索引上的范围查询会访问到不满足条件的第一个值为止。

在oracle数据库的开发环境和测试环境中 数据库的日志模式和自动归档模式一般都是不设置的 这样有利于系统应用的调整 也免的生成大量的归档日志文件将磁盘空间大量的消耗 但在系统上线 成为生产环境时 将其设置为日志模式并自动归档就相当重要了 因为 这是保证系统的安全性 有效预防灾难的重要措施 这样 通过定时备份数据库和在两次备份间隔之间的日志文件 可以有效的恢复这段时间的任何时间点的数据 可以在很多时候挽回或最大可能的减少数据丢失 虽然ORACLE数据库的日志模式和自动归档设置并不复杂 但其中的一些概念和 *** 作过程还是容易混淆的 现在根据本人的经验 分析介绍如下 所用环境为UNIX(HPUX SOLARIES AIX TRU UNIX)和ORACLE 一 要使OARCLE数据库进行日志的自动归档 需要做两方面的事情 一是数据库日志模式的设置(database log mode 可为Archive Mode和No Archive Mode) 另外就是自动归档模式设置(Automatic archival 可为Enabled和Disabled) 二 如何查看数据库的现行日志和自动归档模式的设置 可用archive log list命令来查看 例如 运行在日志自动归档模式下的数据库系统查看结果如下（一般是生产环境）SVRMGR> archive log listDatabase log mode　Archive ModeAutomatic archival EnabledArchive destination/backup/archivelogOldest online log sequence Next log sequence to archive　 Current log sequence　 没有启动数据库日志模式和自动归档的数据库系统查看结果如下（一般是测试环境）SVRMGR> archive log listDatabase log mode　No Archive ModeAutomatic archival DisabledArchive destination/u /app/oracle/product/ /dbs/archOldest online log sequence Current log sequence　 三 数据库日志模式的设置 在创建数据库时 可以在CREATE DATABASE 语句中指定数据库的日志模式 假如没有指明 则缺省为NOARCHIVELOG模式 由于如果在创建数据库时指明是Archive Mode的话 会增加约 %的创建时间 而在以后启动INSTANCE时再设置的话 一般只用去几秒的时间 所以一般在创建数据库时是不设置为ARCHIVE MODE的 如要确定一系统数据库的日志模式设置 除了(二)中的方法外也可以执行如下 *** 作查看 SVRMGR> Select from V$DATABASENAME　CREATEDLOG_MODE　CHECKPOINT　ARCHIVE_CH ORCL　 / / : :NOARCHIVELOG　 将数据库的日志模式设置切换（Archive Mode 和No Archive Mode之间的切换）的步骤和 *** 作如下 关闭运行的数据库实例SVRMGRL>　shutdown在进行日志模式切换之前 必须将运行的数据库正常关闭 备份数据库该备份跟以后产生的日志一起用于将来的灾难恢复（很重要 如要改为归档日志模式 没有这个数据库备份 仅有日志文件是无法从该时间点恢复的） 启动数据库实例到mount状态 但不要打开 SVRMGRL> startup mount注意 如果是使用OPS的话 请只打开一个数据库实例进行模式切换 *** 作 切换数据库日志模式 SVRMGRL> alter database archivelog;(设置数据库为归档日志模式)或SVRMGRL> alter database noarchivelog;(设置数据库为归档日志模式) 打开数据库SVRMGRL> alter database open; 确认数据库现在处于归档日志模式 SVRMGRL> archive log list;Database log mode　 Archive ModeAutomatic archival　EnabledArchive destination for example: $ORACLE_HOME/dbs/archOldest on line log sequence Next log sequence　 Current log sequence 将这个时间点的redo logs归档SVRMGRL> archive log all; 确认新产生的日志文件已在相应的归档目录下面 四 自动归档模式设置(Automatic archival 可为Enabled和Disabled) 在该模式下 数据库启动一个arch进程 专门负责将redo logs写到系统归档设备的相应目录下 在数据库的参数文件中设置参数（一般是在$ORACLE_HOME/dbs/init ora文件中） LOG_ARCHIVE_START=LOG_ARCHIVE_DEST=LOG_ARCHIVE_FORMAT=LOG_ARCHIVE_START:如要求自动归档的话 则设为TRUE 如要求为非自动归档的话 则设为FALSELOG_ARCHIVE_DEST:该参数设定了archive logs 归档存放的路径 LOG_ARCHIVE_FORMAT:该参数设定了archive logs的命名格式 例如 如将格式设为:　arch%s arclog 文件将为:　arch arc arch arc arch arc这几个参数设置只有在数据库实例启动前设置才能生效 如果在数据库运行中进行设置 要使其生效 必须重起数据库 如果数据库正在运行中 不能即刻重起 要设置其为自动归档模式 则做如下 *** 作 SVRMGRL> ALTER SYSTEM ARCHIVE LOG START;如要设置其为非自动归档模式(取消自动归档) 则 SVRMGRL> ALTER SYSTEM ARCHIVE LOG STOP;但如果数据库重起后 给语句修改的结果就失效了 自动归档的设置还是按照系统参数文件中的LOG_ARCHIVE_START的值来设置 五 几种设置情况 ( )　Database log mode　Archive ModeAutomatic archival Enabled这是在大部分生产环境中的ORACLE数据库日志及归档模式设置 这种情况下 做好数据库的定期备份（有热备和冷备）和归档日志备份 可有效的将数据库恢复到有归档日志的全部时间点 ( )　Database log mode　Archive ModeAutomatic archival Disabled这种情况下 数据库不能自动归档 需要进行手工归档 如果所有在线日志都写满了 又没有的及时进行手工归档的话 由于LGWR没有可用的在线日志可写 数据库将会挂在这儿 只有进行手工归档后 有可用的在线日志后才能继续 在生产环境中应该避免这种情况 手工归档 *** 作如下 SVRMGRL> ALTER SYSTEM ARCHIVE LOG ALL;数据库将会把在线日志进行归档处理( )　Database log mode　NO Archive ModeAutomatic archival Enabled有些相对欠缺经验的管理员在进行设置时 只在数据库参数文件中设置了LOG_ARCHIVE_START=TRUE 然后在数据库起来后查看到ARCH归档进程已经起来了 可是尽管ORACLE已经作了几次日志切换 但还是没有归档日志 这时的设置就是这种情况 如果数据库不是处在ARVHIVELOG模式 redolog 还是不会被归档 ( )　Database log mode　NO Archive ModeAutomatic archival Disabled这种设置是刚安装的oracle数据库的缺省设置 开发环境也大部分如此 即没有进行归档 lishixinzhi/Article/program/Oracle/201311/18755

首先简述一下SQL Server内存占用的特点 SQL Server所占用的内存除程序(即SQL Server引擎)外 主要包括缓存的数据(Buffer)和执行计划(Cache) SQL Server以 KB大小的页为单位存储数据 这个和SQL Server数据在磁盘上的存储页大小相同 当SQL Server执行SQL 语句时 如果需要的数据已经在其内存中 则直接从内存缓冲区读取并进行必要的运算然后输出执行结果 如果数据还未在内存中 则首先将数据从磁盘上读入内存Buffer中 而我们通常评价SQL性能指标中的IO逻辑读取数对应的正是从内存缓冲区读取的页数 而IO物理读取数则对应数据从磁盘读取的页数

注 以下的试验在多人共享的开发测试服务器上也可以进行 因为实际上可以分别看到某个表所占用的内存情况 但为了方便 笔者在做此试验时 在一个单独的 确认没有其它并发任务的数据库上进行 因此所看到的内存变化正是每一次所执行的SQL语句引起的

我们首先来看一个简单的实例 创建下表

以下是引用片段 Create Table P_User ( UserMobileStatus int NOT NULL MobileNo int NOT NULL LastOpTime DateTime Not NULL )

然后为该表插入一定的数据

以下是引用片段 Declare @i int Set @i= WHILE @i< BEGIN Insert Into P_User Select @i %  @i GetUTCDate() Set @i=@i+ END

然后我们在查询分析器中首先执行:

以下是引用片段 Set Statistics IO ON

并按下Ctrl+M以显示实际的执行计划

此时 可以开始进行我们的试验了 为了准确观察每一次SQL语句变化情况 在执行第一条SQL语句以前 我们首先清空SQL Server所占用的数据内存

以下是引用片段 CHECKPOINT GO DBCC DROPCLEANBUFFERS

这将清空SQL Server所占用的数据缓冲区(此语句在生产服务器上慎用 因为将导致一段时间内后续的SQL语句执行变慢)

执行高选择性选取

执行如下的SQL语句

以下是引用片段 Select  From P_Order A Inner merge JOIN P_User B ON A MobileNo=B MobileNo Where A MobileNo=

在两个表都没有任何索引情况下 两张表都将执行全表扫描 要读入所有的数据页到内存 总体逻辑读取决于两表的数据页数

在一个表有聚集索引或者非聚集索引情况下 该表将执行Index Seek 另一个表将出现全表扫描 内存数据缓冲区中 将有一张表只读入最终数据所在的数据页 一张表读入全部数据页 逻辑读数取决于表在联接中的秩序 以及无索引表的数据页数

lishixinzhi/Article/program/SQLServer/201311/22449

top查看系统的checkpoint动作

我们可以通过将LOG_checkpointS_TO_ALERT设置成TRUE来打开checkpoint的trace，这样就可以跟踪checkpoint的 *** 作了。

ALTER SYSTEM SET LOG_checkpointS_TO_ALERT=TRUE;

这设置以后系统的checkpoint将会被记录alert_$SIDlog文件中。

在V$DATAFILE_HEADER里面也保存了发生完全checkpoint的时候一些相关信息，包括checkpoint发生时间、对应SCN已经checkpoint的次数。

select file# NO, status, tablespace_name, name, dbms_flashbackget_system_change_number CUR_SCN,

to_char（resetlogs_time, 'YYYY-MM-DD HH24:MI:SS'） RST_DT, resetlogs_change# RST_SCN,

to_char（checkpoint_time, 'YYYY-MM-DD HH24:MI:SS'） CKPT_DT, checkpoint_change# CKPT_SCN, checkpoint_count CKPT_CNT

from v$datafile_header;

/

NO STATUS TABLESPACE_NAME CUR_SCN RST_DT RST_SCN CKPT_DT CKPT_SCN CKPT_CNT

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

1 ONLINE SYSTEM 533541 2008-01-12 16:51:53 446075 2008-08-04 22:03:58 532354 65

2 ONLINE UNDOTBS1 533541 2008-01-12 16:51:53 446075 2008-08-04 22:03:58 532354 28

3 ONLINE SYSAUX 533541 2008-01-12 16:51:53 446075 2008-08-04 22:03:58 532354 65

4 ONLINE USERS 533541 2008-01-12 16:51:53 446075 2008-08-04 22:03:58 532354 64

5 ONLINE EXAMPLE 533541 2008-01-12 16:51:53 446075 2008-08-04 22:03:58 532354 24

可由用户设定参数决定 命令格式: CHECKPOINT [ 间隔时间(int型，单位:秒) ]， 也可由系统自动决定：1备份之前 2 日志丰满 3停止服务。 听起来复杂，其实就是DB做了一个刷新日志缓冲的动作而已。

以上就是关于数据库erp数据日志关闭全部的内容，包括:数据库erp数据日志关闭、邮件服务器邮件存储和日志的介绍、mysql 核心内容-上等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！