oracle中数据是怎样前滚和回滚的

　　保持数据一致性和完整性，是每一款成功商业数据库软件都必须要做到的基本要求。从故障中恢复，保证ACID原则，保证事务完整性，一直是Oracle数据库核心功能组成部分。本篇主要介绍Oracle实例意外终止（断电或者强制关闭）之后，重新启动时发生的恢复过程，也可以称作“前滚和回滚”。

　　基础知识说明

　　为了更明确的说明问题，笔者首先介绍一下本文涉及到的一些重要知识。

　　数据库实例失败

　　我们经常说的数据库服务器failure是有多层含义的。Oracle数据库是一个由多进程组件共同构成的结构体系。最重要的部分包括监听器、Oracle数据库实例两个部分，当然还包括各类文件，更广义的还有硬件和操作系统OS。不同部分的Failure现象和处理方法都有所不同。本文所阐述的过程是Oracle实例失败后的自动恢复过程。

　　在实例失败的时候，往往是突然性的终止。此时Oracle数据库可能在进行一系列完成或者未完成的事务。实例失败恢复，就是要将这些状态进行还原，恢复到数据完整性的状态。

　　写日志（RedoLog）在先机制

　　Oracle数据库是采用“日志在先”机制的。当我们对数据库数据进行修改时，并不是立即将修改写入到文件中，而是写入到共享内存SGA空间中的BufferCache里。同时，将修改的日志不断的写入到SGA中另一块Log Buffer缓存中。有一个后台进程LGWR不断的将LogBuffer缓存中的日志内容写入到online redo log文件中。

　　写入LogBuffer缓存和LGWR写入文件的过程是异步进行的。那么LGWR会在哪些情况下将日志缓冲区(全部内容)转储到日志文件呢？如下：--参考OCA认证考试指南(1Z0-052,P40)ü 用户进行直接的commit操作；

　　ü RedoBuffer数据超过1/3；

　　ü DBWn启动，将BufferCache中的脏数据写入到文件中；ü 距离上次LGWR写入操作超过三秒(三秒超时，DBWn每三秒钟会对一些缓冲区清理一次，这个时候，刚好符合触发LGWR的第三点)；而数据文件写入进程DBWn工作的触发点(此处注意：DBWn会将高速缓冲区的脏缓冲区,即脏数据块写入数据文件，而不是缓冲区里头的全部内容---参考OCA认证考试指南(1Z0-052,P38))。

　　因为考虑到磁盘I/O会降低性能，DBWn采用的是极懒算法执行写入。如果对于经常变脏的缓冲区，即这边缓冲区处于十分忙碌的状态，那么DBWn不会将缓冲区写入磁盘的。反而一段时间来，任何会话都未曾关注的一些缓冲区，DBWn会将其写入到磁盘。因此DBWn写脏缓冲区比较平缓和低频率。但如果出现检查点的情况例外：DBWn会将所有脏缓冲区全部写入磁盘。---参考OCA认证考试指南(1Z0-052,P38中，P39)。

　　ü 当BufferCache中没有任何可用缓冲区；ü 脏缓冲区过多；

　　ü 遇到三秒超时(DBWn每三秒钟会对一些缓冲区清理一次)ü 遇到检查点

　　综合DBWn和LGWR工作的特点，我们可以得到日志文件的几个特点：

　　首先，日志文件的写入是很频繁的。LGWR会不断将日志信息从LogBuffer中写入Online Redo Log；其次，在日志文件上，可以有三个类型的事务事件。

　　1、事务结束，已经被commit，之后打过checkpoint检查点。这种事务记录在LogFile上，但是变化信息已经被DBWn写入进数据文件；2、事务结束，已经被commit，之后没有打入checkpint检查点。这种情况下，LogFile已经写入了日志项目，数据文件可能包括脏数据，也可能没有写入脏数据；3、事务未结束，没有commit。这种时候，数据块DirtyBlock上面是有事务槽信息，表示未结束事务，是不会将数据写入到数据文件中。但是，日志LogBuffer可能将部分未提交的DML操作项目写入到Log File中；检查点Checkpoint

　　检查点Checkpoint是数据库一致性检查的一个标记。简单的说，就是在这个点上，Oracle保证各个文件（数据、控制、日志等）是一致的。检查点的作用就是在进行实例恢复的时候，告诉SMON进程，这个点之前的内容不需要进行恢复。

　　前滚和回滚介绍

　　“前滚和回滚”是Oracle数据库实例发生意外崩溃，重新启动的时候，由SMON进行的自动恢复过程。下面通过模拟实例和讲解介绍这个过程。

　　失败前场景说明

　　日志中记录过程如下：

　　1、事务A进行之后，结束commit。之后系统进行了一次checkpointA；2、Checkpoint之后，进行事务B，结束commit；3、进行事务C，C事务量较大，其中进行了一定量的RedoLog文件写入。之后系统断电；--按照LGWR的工作机制，C事务量比较大，所以应用程序将在几分之一秒内的时间里生成足以填充1/3秒的重做内容，因此这会触发LGWR将日志缓冲区的内容转储到日志文件，但始终得不到针对C事务的提交记录，这是需要回滚的。

　　4、还有种可能，事务B和D，事务D所用的缓冲区处于高速缓冲区不活跃的位置，而且事务B已提交，但其所用的缓冲区处于高速缓冲区活跃的位置。因此DBWn会将D事务缓冲区数据写入数据文件，而没将B事务的数据写入。此种情况需要回滚D事务，保留B事务。---参考OCP认证考试指南全册（P358下半部分内容)

　　1、系统启动过程，进入实例恢复阶段

　　当实例意外中断的时候，各类型文件，包括控制文件、数据文件和日志文件上，会存在不一致的问题。这种不一致主要体现在SCN值的差异上。

　　实例在启动的时候，经过三阶段（nomount、mount和open）。在open之前，会进行这种不一致现象的检查，如果出现不一致，要启动SMON进程的恢复流程。

　　SMON是Oracle实例的一个后台进程，主要负责进行系统监控恢复。进行恢复的依据主要是RedoLog记录。

　　2、前滚进程

　　SMON首先找到最后SCN记录的Redo LogFile。寻找最后一个打入的Checkpoint。

　　顺序找到CheckPointA之后，表示A之前的所有事务都是完全写入到数据文件中，不存在不一致性问题。恢复过程从CheckpointA开始，Oracle开始依据重做日志Redo Log的系列条目，进行推进。

　　首先遇到了事务B信息，由于事务B已经commit，所以事务B所有相关的Redo Log条目已经全都写入到Redo LogFile中。所以，按照日志继续条目推进，完全可以重演replay，并且应用apply事务B的全部过程。

　　这样，事务B全部实现，最终将通过DBWn完全写入到数据文件中。所以，实例失败之前提交commit的事务B，完全恢复。

　　进入事务C的范畴，由于一部分事务C的RedoLog条目已经进入Redo LogFile中(根据LGWR和DBWn的工作机制，事务C有可能将部分数据块写入日志文件和数据文件，但这时候C事务始终没提交，这是比较严重的讹误，所以需要回滚)，所以在进行前滚的时候，一定会replay到这部分的内容。不过，这部分内容中不可能出现commit的标记。所以，前滚的结果一定是遇到实例突然中断的那个时点。此时replay的结果是，事务C没有提交。这样结束了前滚过程，进入回滚阶段。

　　3、回滚过程(与普通的回滚一样（当事务执行失败后自动回滚或者命令:ROLLBACK）---参考OCP认证考试指南全册)对事务C(针对DML的update，当然其他同理)，要进行回滚过程，释放所有相关资源。在前滚中，利用日志填充了的撤销块和表数据块的值，然后在回滚的时候，会将撤销块的值复制回表数据块中(因为此事务没提交记录)，以此来进行SGA中BufferCache数据块恢复。

　　4、说说恢复过程的损耗

　　很多时候，由于我们事务规模较大，当出现实例崩溃的时候，重启所需要的时间很多。有一种经验说法是，事务有多长，前滚和回滚所消耗的时间有多长×2。而且，如果不能完成SMON恢复过程，数据库是不能算作正常的Open的。

　　SMON的恢复过程是Oracle强制进行的一个过程，即使恢复中发生断电或者其他中断失败事件。Oracle在下一次启动的时候，还是会继续这个过程，只有耐心等待。

　　通过检查一些内部视图（X$视图），可以观察到恢复进程和速度，但是丝毫不能影响到最终恢复的过程。

　　这个过程虽然可以保证数据一致性，但是也带来了系统不能启动，影响生产环境的问题。我们可以通过两个方式进行缓解：

　　首先，我们在设计开发系统时，要保证事务规模的可控性，不要让事务规模在技术层面上过大。避免一旦发生崩溃，大规模强制回滚的发生；其次，一旦出现了这个强制回滚，要注意对生产环境的影响。可以采用备库standby进行顶替，让主库安静的慢慢恢复；

饥荒联机版拥有回滚功能，可以由主机选择，回滚的最大天数貌似是3天吧使用后可以把存档回滚到前3天，或者主机设定的天数。

饥荒单机版没有这个功能，

单机版不能在游戏里存档读档，因为设计者原意就是要你们体会生存的残酷，这也是饥荒游戏的本意所在。

所以只能通过SL大法来达到回滚的目的。具体操作就是在饥荒单机版自动保存或者角色死亡之前直接ALT+F4或者点击窗口右上的“关闭窗口”，这样游戏就会回到上一次保存的存档。

linux配置已有的文件夹为svn的指定目录？

要实现这个想法，关键原理就是把default这个文件夹变成在svn控制之下的一个工作副本，然后通过post-commit钩子去自动更新这个工作副本。几个关键操作：

1、需要在服务器上安装svn服务器端，启动svn服务，并创建一个svn库；

2、将当前的default文件夹变成新建的svn库的工作副本（客户端存放数据的文件夹），具体操作：将当前default文件夹下的内容import到新建的svn库中，然后再清空default，然后再将svn库中的内容checkout到default；

3、使用svn的post-commit钩子（这个钩子是在每次成功commit后被SVN服务器自动调用的），编辑这个钩子，内容就是svnupdate文件夹default，这样每次commit成功后就会自动更新default文件夹；

4、在你自己的电脑上checkout那个svn库，然后你就可以从本地commit，然后服务器端就自动更新default文件夹了。

如何在Linux和windows上迅速建立svn+ssh？

1：采用Samba服务器，在Linux下设立个Samba服务器，这样windows就可以访问Linux上的Samba服务目录了；2：Vmware提供了一个sharefolder的功能，可以在Windows上设置一个共享目录，在Vmware里面可以去/mnt/hgfs里面找到共享的目录。

svn中怎么回滚到上一个版本的命令？

这种情况下，用svnmerge命令来进行回滚。回滚的操作过程如下：

1、保证我们拿到的是最新代码：svnupdate假设最新版本号是28。

2、然后找出要回滚的确切版本号：svnlog假设根据svnlog日志查出要回滚的版本号是25，此处的something可以是文件、目录或整个项目如果想要更详细的了解情况，可以使用svndiff-r28:25

3、回滚到版本号25：svnmerge-r28:25something为了保险起见，再次确认回滚的结果：svndiff发现正确无误，提交。

4、提交回滚：svncommit-m"Revertrevisionfromr28tor25,

教育网下LINUX系统的终端如何访问外网？

虚拟机下linux外网访问虚拟机下LINXU访问外网，可以有三种方式。我使用了默认的Bridge形式。启动xwindows,设置网络，将eth0（物理网卡）的IP地址设为局域网内可用的IP地址，同时设置网关、DNS。

当启动Binlog后，事务会产生Binlog Event，这些Event被看做事务数据的一部分。因此要保证事务的Binlog Event和InnoDB引擎中的数据的一致性。所以带Binlog的CrashSafe要求MySQL宕机重启后能够保证：

- 所有已经提交的事务的数据仍然存在。

- 所有没有提交的事务的数据自动回滚。

- 所有已经提交了的事务的Binlog Event也仍然存在。

- 所有没有提交事务没有记录Binlog Event。

这些要求很好理解，如果重启后数据还在，但是Binlog Event没有了，就没办法复制到其他节点上了。如果重启后，数据没了，但是Binlog Event还在，那么不存在的数据就会被复制到其他节点上，从而导致主从的不一致。

为了保证带Binlog的CrashSafe，MySQL内部使用的两阶段提交(Two Phase Commit)。

2 - MySQL的Two Phase Commit(2PC)

在开启Binlog后，MySQL内部会自动将普通事务当做一个XA事务来处理：

- 自动为每个事务分配一个唯一的ID

- COMMIT会被自动的分成Prepare和Commit两个阶段。

- Binlog会被当做事务协调者(Transaction Coordinator)，Binlog Event会被当做协调者日志。

想了解2PC，可以参考文档：https://enwikipediaorg/wiki/Two-phase_commit_protocol。

- 分布式事务ID(XID)

使用2PC时，MySQL会自动的为每一个事务分配一个ID，叫XID。XID是唯一的，每个事务的XID都不相同。XID会分别被Binlog和InnoDB记入日志中，供恢复时使用。MySQ内部的XID由三部分组成：

- 前缀部分

前缀部分是字符串"MySQLXid"

- Server ID部分

当前MySQL的server_id

- query_id部分

为了保证XID的的唯一性，数字部分使用了query_id。MySQL内部会自动的为每一个语句分配一个query_id，全局唯一。

参考代码：sql/xa。h的struct xid_t结构。

- 事务的协调者Binlog

Binlog在2PC中充当了事务的协调者（Transaction Coordinator）。由Binlog来通知InnoDB引擎来执行prepare，commit或者rollback的步骤。事务提交的整个过程如下：

1 协调者准备阶段(Prepare Phase)

告诉引擎做Prepare，InnoDB更改事务状态，并将Redo Log刷入磁盘。

2 协调者提交阶段(Commit Phase)

21 记录协调者日志，即Binlog日志。

22 告诉引擎做commit。

注意：记录Binlog是在InnoDB引擎Prepare(即Redo Log写入磁盘)之后，这点至关重要。

在MySQ的代码中将协调者叫做tc_log。在MySQL启动时，tc_log将被初始化为mysql_bin_log对象。参考sql/binlogcc中的init_server_components()：

if (opt_bin_log) tc_log= &mysql_bin_log;

而在事务提交时，会依次执行：

tc_log->prepare()；

tc_log->commit()；

参考代码：sql/binlogcc中的ha_commit_trans()。当mysql_bin_log是tc_log时，prepare和commit的代码在sql/binlogcc中：

MYSQL_BIN_LOG::prepare()；

MYSQL_BIN_LOG::commit()；

-协调者日志Xid_log_event

作为协调者，Binlog需要将事务的XID记入日志，供恢复时使用。Xid_log_event有以下几个特点：

- 仅记录query_id

因为前缀部分不变，server_id已经记录在Event Header中，Xid_log_event中只记录query_id部分。

- 标志事务的结束

在Binlog中相当于一个事务的COMMIT语句。

一个事务在Binlog中看起来时这样的：

Query_log_event("BEGIN");DML产生的events; Xid_log_event;

- DDL没有BEGIN，也没有Xid_log_event 。

- 仅InnoDB的DML会产生Xid_log_event

因为MyISAM不支持2PC所以不能用Xid_log_event ，但会有COMMIT Event。

Query_log_event("BEGIN");DML产生的events;Query_log_event("COMMIT");

问题：Query_log_event("COMMIT")和Xid_log_event 有不同的影响吗？

- Xid_log_event 中的Xid可以帮助master实现CrashSafe。

- Slave的CrashSafe不依赖Xid_log_event

事务在Slave上重做时，会重新产生XID。所以Slave服务器的CrashSafe并不依赖于Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT")，只是作为事务的结尾，告诉Slave Applier去提交这个事务。因此二者在Slave上的影响是一样的。

3 - 恢复(Recovery)

这个机制是如何保证MySQL的CrashSafe的呢，我们来分析一下。这里我们假设用户设置了以下参数来保证可靠性：

- 恢复前事务的状态

在恢复开始前事务有以下几种状态：

- InnoDB中已经提交

根据前面2PC的过程，可知Binlog中也一定记录了该事务的的Events。所以这种事务是一致的不需要处理。

- InnoDB中是prepared状态，Binlog中有该事务的Events。

需要通知InnoDB提交这些事务。

- InnoDB中是prepared状态，Binlog中没有该事务的Events。

因为Binlog还没记录，需要通知InnoDB回滚这些事务。

- Before InnoDB Prepare

事务可能还没执行完，因此InnoDB中的状态还没有prepare。根据2PC的过程，Binlog中也没有该事务的events。 需要通知InnoDB回滚这些事务。

- 恢复过程

从上面的事务状态可以看出：恢复时事务要提交还是回滚，是由Binlog来决定的。

- 事务的Xid_log_event 存在，就要提交。

- 事务的Xid_log_event 不存在，就要回滚。

恢复的过程非常简单：

- 从Binlog中读出所有的Xid_log_event

- 告诉InnoDB提交这些XID的事务

- InnoDB回滚其它的事务

公司服务器把Jenkins安装在了Windows上，很多构建都需要使用dos命令，十分难受，写这篇文章记录一下遇到的坑。

原本是想部署之后运行即可，结果还要备份。上网查了一下，有用 ThinBackup 插件进行备份的，还有自己创个目录备份的……五花八门。于是我先选择了自己创个目录备份的方案，设想是这样的：

结果说怎么可以是手动回退呢，让我改。再加上第4点用bat实在太难写了，于是就改成用Jenkins自带的备份（或者说是将生成的文件进行保存）。自带的备份方式如下：

这里使用到了 Jenkins的环境变量 。备份文件的路径和配置详见第5步。

还有更方便的 ，直接更改ProcessTreeKiller正在寻找的环境变量 BUILD_ID 即可暂时禁用ProcessTreeKiller。官网只给出了Shell命令的写法，在运行jar之前写上

BUT，我们是Windows， 故应该改成

之后再用Linux的 nohup 或者Windows的 javaw 命令即可后台运行jar包了。

还有一个打印日志的问题：在Linux中使用 nohup 命令还好办；而在Windows中，单独使用 javaw 命令并配合管道工具（ > 和 >> ）可以打印日志，但即使改变了BUILD_ID，Jenkins也不会关闭，会一直提示“构建中”。我们使用了start命令，但是start命令只能运行一个命令，会忽略掉后面的管道工具，从而不能打印日志。解决方案是，写一个bat命令保存在本地，并使用外部参数来作为jar包的路径和日志的路径。bat命令内容如下：

上面的命令行则变成：

日志就会保存在每次构建的目录中。其中的 BUILD_NUMBER 即构建的序号。

后端写好了前端就好办了，直接照前端办即可。我的步骤是：

在前端部署之前，需要通过nginx反向代理将后端端口挂载到80端口的路径上，这里就不详说了。特别坑的地方是，反向代理有时候不能生效，是因为反复打开关闭nginx过程中产生了好几个nginx进程，把它们全部关闭再重新打开，反向代理就能够生效了。

　Oracle数据库服务器是整个系统的核心 它的性能高低直接影响整个系统的性能 为了调整Oracle数据库服务器的性能 主要从以下几个方面考虑

　

　◆ 调整操作系统以适合Oracle数据库服务器运行 Oracle数据库服务器很大程度上依赖于运行服务器的操作系统 如果操作系统不能提供最好性能 那么无论如何调整 Oracle数据库服务器也无法发挥其应有的性能

　

　 为Oracle数据库服务器规划系统资源

　

　据已有计算机可用资源 规划分配给Oracle服务器资源原则是 尽可能使Oracle服务器使用资源最大化 特别在Client/Server中尽量让服务器上所有资源都来运行Oracle服务

　

　 调整计算机系统中的内存配置

　多数操作系统都用虚存来模拟计算机上更大的内存 它实际上是硬盘上的一定的磁盘空间 当实际的内存空间不能满足应用软件的要求时 操作系统就将用这部分的磁盘空间对内存中的信息进行页面替换 这将引起大量的磁盘I/O操作 使整个服务器的性能下降 为了避免过多地使用虚存 应加大计算机的内存

　

　 为Oracle数据库服务器设置操作系统进程优先级

　

　不要在操作系统中调整Oracle进程的优先级 因为在Oracle数据库系统中 所有的后台和前台数据库服务器进程执行的是同等重要的工作 需要同等的优先级 所以在安装时 让所有的数据库服务器进程都使用缺省的优先级运行

　

　◆ 调整内存分配

　

　Oracle数据库服务器保留 个基本的内存高速缓存 分别对应 种不同类型的数据 库高速缓存 字典高速缓存和缓冲区高速缓存 库高速缓存和字典高速缓存一起构成共享池 共享池再加上缓冲区高速缓存便构成了系统全程区(SGA) SGA是对数据库数据进行快速访问的一个系统全程区 若SGA本身需要频繁地进行释放 分配 则不能达到快速访问数据的目的 因此应把SGA放在主存中 不要放在虚拟内存中 内存的调整主要是指调整组成SGA的内存结构的大小来提高系统性能 由于Oracle数据库服务器的内存结构需求与应用密切相关 所以内存结构的调整应在磁盘I/O调整之前进行

　

　 库缓冲区的调整

　

　库缓冲区中包含私用和共享SQL和PL/SQL区 通过比较库缓冲区的命中率决定它的大小 要调整库缓冲区 必须首先了解该库缓冲区的活动情况 库缓冲区的活动统计信息保留在动态性能表v$librarycache数据字典中 可通过查询该表来了解其活动情况 以决定如何调整 Select sum(pins) sum(reloads) from v$librarycache; Pins列给出SQL语句 PL/SQL块及被访问对象定义的总次数 Reloads列给出SQL 和PL/SQL块的隐式分析或对象定义重装载时在库程序缓冲区中发生的错误 如果sum(pins)/sum(reloads) ≈ 则库缓冲区的命中率合适 若sum(pins)/sum(reloads)> 则需调整初始化参数 shared_pool_size来重新调整分配给共享池的内存量

　

　 数据字典缓冲区的调整

　

　数据字典缓冲区包含了有关数据库的结构 用户 实体信息 数据字典的命中率 对系统性能影响极大 数据字典缓冲区的使用情况记录在动态性能表v$librarycache中 可通过查询该表来了解其活动情况 以决定如何调整 Select sum(gets) sum(getmisses) from v$rowcache; Gets列是对相应项请求次数的统计 Getmisses 列是引起缓冲区出错的数据的请求次数 对于频繁访问的数据字典缓冲区 sum(getmisses)/sum(gets)< %～ % 若大于此百分数 则应考虑增加数据字典缓冲区的容量 即需调整初始化参数shared_pool_size来重新调整分配给共享池的内存量

　

　 缓冲区高速缓存的调整

　

　用户进程所存取的所有数据都是经过缓冲区高速缓存来存取 所以该部分的命中率 对性能至关重要 缓冲区高速缓存的使用情况记录在动态性能表v$sysstat中 可通过查询该表来了解其活动情况 以决定如何调整

　

　Select name value from v$sysstat

　

　where name in ( dbblock gets consistent gets physical reads );

　

　dbblock gets和consistent gets的值是请求数据缓冲区中读的总次数 physical reads的值是请求数据时引起从盘中读文件的次数 从缓冲区高速缓存中读的可能性的高低称为缓冲区的命中率 计算公式

　

　Hit Ratio= (physical reds/(dbblock gets+consistent gets))如果Hit Ratio< %～ % 则应增大db_block_buffers的参数值 db_block_buffers可以调整分配给缓冲区高速缓存的内存量 即db_block_buffers可设置分配缓冲区高速缓存的数据块的个数 缓冲区高速缓存的总字节数=db_block_buffers的值db_block_size的值 db_block_size 的值表示数据块大小的字节数 可查询 v$parameter 表 select name value from v$parameter where name= db_block_size ; 在修改了上述数据库的初始化参数以后 必须先关闭数据库 在重新启动数据库后才能使新的设置起作用

　

　◆ 调整磁盘 I/O

　

　磁盘的I/O速度对整个系统性能有重要影响 解决好磁盘I/O问题 可显著提高性能 影响磁盘I/O的性能的主要原因有磁盘竞争 I/O次数过多和数据块空间的分配管理

　

　为Oracle数据库服务器创建新文件时 不论是表空间所用的数据文件还是数据事务登录所用的日志文件 都应仔细考虑数据库服务器上的可用磁盘资源 如果服务器上有多个磁盘 则可将文件分散存储到各个可用磁盘上 减少对数据库的数据文件及事务日志文件的竞争 从而有效地改善服务器的性能 对于不同的应用系统都有各自的数据集 应当创见不同的表空间分别存储各自应用系统的数据 并且尽可能的把表空间对应的数据文件存放在不同的磁盘上 这种从物理上把每个应用系统的表空间分散存放的方法 可以排除两个应用系统竞争磁盘的可能性 数据文件 事务日志文件分别存放在不同的磁盘上 这样事务处理执行的磁盘访问不妨碍对相应的事物日志登记的磁盘访问 如果有多个磁盘可用 将两个事物日志成员放在不同的磁盘驱动器上 就可以消除日志文件可能产生的磁盘竞争 应把一个应用的表数据和索引数据分散存放不同表空间上 并且尽量把不同类型的表空间存放在不同磁盘上 这样就消除了表数据和索引数据的磁盘竞争

　

　◆ 调整数据库服务器的回滚段

　

　回滚段是一个存储区域 数据库使用该存储区域存放曾经由一个事务更新或删除的行的原始数据值 如果用户要回滚一个事务所做的改变 那么数据库就从回滚段中读回改变前的数据并使该事务影响的行改变为它们的原状态 回滚段控制着数据库处理事务的能力 因而在数据库成功中起著关键性的作用 不管数据库的其它部分设计得多好 如果它设计得不合理 将会严重影响系统的性能 建立和调整回滚段的原则如下

　

　 分离回滚段

　

　分离回滚段是指单独为回滚段创建一个以上的表空间 使回滚段与数据字典 用户数据 索引等分离开来 由于回滚段的写入与数据和索引的写入是并行进行的 因此将它分离出来可以减少I/O争用 如果回滚段与数据不分离 倘若要某个表空间脱机或撤消 那么在该表空间中的各个回滚段没有全部脱机之前 不能将这个表空间脱机或撤消 而一旦该表空间不可用 则该表空间中的所有回滚段也不能使用 这将浪费所有分配的磁盘空间 所以 独立回滚段可使数据库管理变得容易 回滚段的经常性收缩 使得表空间的自由块更容易形成碎片 分离回滚段可以减少数据库表空间的碎片产生

　

　 创建不同大小的回滚段群

　

lishixinzhi/Article/program/Oracle/201311/18922