【等待事件】等待事件系列(3+4)--System IO(控制文件)+日志类等待

 等待事件】等待事件系列(3+4--System IO(控制文件)+日志类等待

 

 BLOG文档结构图

wpsF0E.tmp 

 

 前言部分

 

2.1  导读和注意事项

各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~

① 控制文件类等待

② 日志类等待

 

2.2  相关参考文章链接

【推荐】 等待事件系列(1)--User I/O类型(下)

http://blog.itpub.net/26736162/viewspace-2124435/

【推荐】 等待事件系列(1)--User I/O类型(上)

http://blog.itpub.net/26736162/viewspace-2124417/

2016-09-07

【等待事件】System I/O类 等待事件(3.4)--control file single write

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771471&idx=1&sn=5922a52ac6294acf2802f44e2bb0d724&chksm=fe8bba77c9fc336151a61bdf876cb058df0d61d1404d8450cb7771330b6d44309d86dae4bb54&scene=21#wechat_redirect

2016-09-06

【等待事件】System I/O类 等待事件(3.3)--control file sequential read

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771468&idx=1&sn=fc7d83d1a9b12911f3c93d3b5b444e9a&chksm=fe8bba74c9fc3362b58717fca9e95c68d45e701fa2f733a643ba01db7969cca668858272fbfc&scene=21#wechat_redirect

2016-09-04

【等待事件】System I/O类 等待事件(3.2)--control file parallel write

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771458&idx=1&sn=e949dfa5bff65ce4a596005955c5be5a&scene=21#wechat_redirect

2016-09-03

【等待事件】System I/O类 等待事件(3.1)--db file parallel write

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771454&idx=1&sn=e90248954475dfd2c78bdec592405735&scene=21#wechat_redirect

2016-09-01

【等待事件】User I/O类 等待事件(2.10)--所有User I/O类 等待事件总结

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771447&idx=1&sn=22ae192f0d8a161f65514339ad763985&scene=21#wechat_redirect

2016-08-31

【等待事件】User I/O类 等待事件(2.9)--local write wait

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771443&idx=1&sn=02b4ad5ca03052013b69ae6bcb7e3487&scene=21#wechat_redirect

2016-08-30

【等待事件】User I/O类 等待事件(2.8)--read by other session

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771439&idx=1&sn=b3c01eed444cd6e597a63a3ed0687768&scene=21#wechat_redirect

2016-08-29

【等待事件】User I/O类 等待事件(2.7)--direct path read/write temp

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771429&idx=1&sn=50b5684e699165a34087db88e07edb34&scene=21#wechat_redirect

2016-08-27

【等待事件】User I/O类 等待事件(2.6)--direct path write(直接路径写、DRW)

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771420&idx=1&sn=458eb18dc26da94debcea62643d15181&scene=21#wechat_redirect

2016-08-26

【等待事件】User I/O类 等待事件(2.5)--direct path read(直接路径读、DPR)

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771416&idx=1&sn=b26c3135584c5b60ce14cc0749ac58a7&scene=21#wechat_redirect

2016-08-20

【等待事件】User I/O类 等待事件(2.4)--db file single write

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771403&idx=1&sn=054dd852dac5ac8837fa251f0e84332e&scene=21#wechat_redirect

2016-08-16

【等待事件】User I/O类 等待事件(2.3)--db file parallel read

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771387&idx=1&sn=0037fb89470d8e6dd5ff72714b18a3b7&scene=21#wechat_redirect

2016-08-15

【等待事件】User I/O类 等待事件(2.2)--db file scattered read(数据文件离散读)

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771379&idx=1&sn=5887eee02885000c1d293adfd04ee044&scene=21#wechat_redirect

2016-08-14

【等待事件】User I/O类 等待事件(2.1)--db file sequential read(数据文件顺序读)

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771376&idx=1&sn=42de046e73190f4e265f81bbb6e3ae00&scene=21#wechat_redirect

2016-08-13

【等待事件】等待事件概述(1)--等待事件的源起和分类

http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771373&idx=1&sn=1e55af795aae5f641b2c3cc610814ead&scene=21#wechat_redirect

 

  System I/O类型

SELECT *

FROM   v$event_name d

WHERE  d.WAIT_CLASS ='System I/O';

wpsF1F.tmp 

3.1  db file parallel write

SELECT *

FROM   v$event_name

WHERE  NAME IN ('db file parallel write');

wpsF20.tmp 

这个等待事件有3个参数:

Requests: 操作需要执行的I/O次数(DBWR写入批量的大小-块数)

interrupt(中断)

timeout:等待的超时时间。

 

V$SESSION_WAIT这个视图里面,这个等待事件有三个参数P1P2P3,其中P1代表Oracle正在写入的数据文件的数量,P2代表操作将会写入多少的BLOCK数量,P3Oracle9i release2版本之前代表总共有多少BLOCKI/O请求,等于P2的值;在Oracle9i release2版本之后则代表等待I/O完成的超时的时间,单位是百分之一秒。

 

经过高速缓冲区的所有数据是通过DBWR写入到磁盘上的。DBWR请求写入脏块的I/O后,在此工作结束期间等待db file parallel write事件。

这是一个后台等待事件,它同样和用户的并行操作没有关系,它是由后台进程DBWR产生的,当后台进程DBWR磁盘上写入脏数据时,会发生这个等待。

DBWR会批量地将脏数据并行地写入到磁盘上相应的数据文件中,在这个批次作业完成之前,DBWR将出现这个等待事件。 如果仅仅是这一个等待事件,对用户的操作并没有太大的影响,当伴随着出现free buffer waits等待事件时,说明此时内存中可用的空间不足,这时候会影响到用户的操作,比如影响到用户将脏数据块读入到内存中。          

当出现db file parallel write等待事件时,可以通过启用操作系统的异步I/O的方式来缓解这个等待。 当使用异步I/O时,DBWR不在需要一直等到所有数据块全部写入到磁盘上,它只需要等到这个数据写入到一个百分比之后,就可以继续进行后续的操作。

这个等待事件是指Oracle后台进程DBWR等待一个并行写入文件或者是BLOCK的完成,等待会一直持续到这个并行写入操作完成。这个等待事件即使在总的等待时间中占的比例比较大也不会对用户的会话有很大的影响,只有当用户的会话显示存在大量的等待时间消耗在"write complete waits" 或者是"free buffer waits"上的时候才会影响到用户的会话,较明显的影响是这个写操作的等待会影响到读取同一个磁盘上数据的用户会话的I/O

① 与其名称相反,该事件不与任何并行DML操作相关。

② 该等待事件属于DBWR进程,DBWR进程负责向数据文件写入脏数据块的唯一进程,即DBWR进程执行对使用SGA的所有数据库写入。阻塞该进程的是操作系统的IO子系统。当然DBWR进程的写入操作也会对同一磁盘操作的其他会话造成影响。

③ DBWR查找脏块的时机:

>> 每隔三秒一次的查找。

>> 当前台提交需要清除缓冲区内容时。

>> 当满足_DB_LARGE_DIRTY_QUEUE/_DB_BLOCK_MAX_DIRTY_TARGET /FAST_START_MTTR_TARGET阈值。

④ 缓慢的DBWR操作可以造成前台会话在write complete waits(前台不允许修改正在传输到磁盘的块)free buffer waits(DBWR不能满足释放缓冲区的需求)事件上。通过以下语句可以获知该事件的平均等待时间,如果平均等待时间大小10cs,则表明IO缓慢。如果不存在db file parallel write事件,很可能初始化参数disk_async_io=FALSE,这种情况一般发生在AIXHPUX平台上。

SELECT s.event, s.time_waited, s.average_wait

FROM v$system_event s

WHERE s.event IN ('db file parallel write', 'free buffer waits',

'write complete waits')

相关查询:

SELECT *

FROM v$sysstat

WHERE NAME IN ('write clones created in background',

'write clones created in foreground')

⑤ 操作说明:DBWR将一组脏数据编成"写入批量组",然后发布多个IO请求以将"写入批量组"写入数据文件,然后以此事件等待直到IO请求都完成。但是,当使用异步IO时,DBWR不等待整个批量写入完成,仅等待一定百分比的IO操作完成后,就将空闲缓冲区推到LRU链以使其可用。

⑥ 解决方法:

>> 如果平均等待时间长,要选择使用正确的IO操作。如果数据文件在裸设备上,并且平台支持异步IO,请应该使用异步IO。如果数据文件位于文件系统上,则应该使用同步写入和直接IO。相关的初始化参数是DISK_ASYNCH_IOFILESYSTEMIO_OPTIONS

>> 如果重做位于祼设备上,而数据文件位于文件系统上,则可以设置DISK_ASYNCH_IO=TRUEFILESYSTEMIO_OPTIONS=DIRECTIO。使用这种方法可以获得对于祼设备使用异步IO,而对于文件系统使用直接IO的效果。

>> 使用DB_WRITER_PROCESSES选项产生多个DBWR进程。

 

 

1I/O系统的性能缓慢时

db file parallel write等待的发生原因和解决方法如下:

如果DBWR进程上db file parallel write等待时间表现得过长,就可以判断为I/O系统上有问题。如果DBWR上的db file parallel write等待时间延长,服务器进程就会接连经历free buffer waits事件或write complete waits事件的等待。这个问题可以通过改善I/O系统解决,改善I/O性能的方法如下:

1)组合使用裸设备和异步I/O是目前为止的最好方法。

2OS级上使用Direct I/O。若CPU数量充足,可以调整db_writer_processes参数值,将DBWR数量增加。多个DBWR具有模拟异步的效果。oracle推荐的DBWR进程是CPU_COUNT/8

 

2I/O工作过多时

频繁发生检查点时,DBWR的活动量过多,可能导致DBWR的性能降低。DBWR的性能与整个系统的性能有直接的联系。将fast_start_mttr_target(MTTR指平均恢复时间,数据库进行崩溃恢复需要的秒数。)参数值设定过小时,将频繁发生增量检查点工作。日志文件过小时,将频繁发生日志文件的转换,因此检查点工作将增加。因Parallel Query发生direct path read时,在truncatedrophot backup时也发生检查点。如果I/O系统上不存在性能问题,但还是广泛出现db file parallel write等待,就应该检查是否存在给DBWR带来不必要的负荷的因素。

 

3、不能有效使用高速缓存区时

间接改善DBWR性能的另一种方法是合理使用多重缓冲池。与其说这个方法能改善I/O系统的性能,不如说是因为不必要的写入工作减少,进而减少了DBWR的负担。

3.2  控制文件I/O等待事件

 

SELECT A.* FROM V$EVENT_NAME A WHERE NAME LIKE 'control file%';

wpsF21.tmp 

这一类等待事件通常发生在更新控制文件时,例如日志切换、检查点等发生时,需要更新控制文件内的System Change Number(SCN)所引起的相关等待事件,以下将为这些控制文件所引起的等待事件做详尽的介绍。

3.2.1   control file parallel write-控制文件并行写

SELECT A.*

  FROM V$EVENT_NAME A

 WHERE NAME IN ('control file parallel write');

wpsF22.tmp 

这个等待事件包含三个参数:

filesOracle要写入的控制文件个数。

block#:写入控制文件的数据块数目。

requests:写入控制文件请求的I/O次数。

V$SESSION_WAIT这个视图里面,这个等待事件有三个参数P1P2P3,这三个参数都设置为同样的值,代表控制文件对I/O的请求数量。当Oracle更新控制文件的时候是同时更新所有控制文件并写入同样的信息。

这个等待事件表明服务器进程(Server Process)在更新所有的控制文件的时候等待I/O的完成。因为控制文件所在的磁盘的I/O过高引起无法完成对所有控制文件的物理写入,写入控制文件的这个会话会拥有CF队列,因此其他的会话都会在这个队列中等待。

一般环境下,因为更新控制文件的次数不多,因此不怎么发生control file parallel write等待现象。但如下情况下可能发生与控制文件相关的争用。

1) 日志文件切换经常发生时:

日志文件过小时,将经常发生日志文件的切换。每当发生日志文件切换时,需要对控制文件进行更新,所以LGWR进程等待control file parallel write事件的时间将延长。

2) 检查点经常发生时:

MTTR设定得过短或频繁发生人为的检查点时,CKPT进程等待control file parallel write事件的时间将延长。

3) nologging引起频繁的数据文件修改时:

对数据文件在nologging选项下执行修改工作时,为了修改unrecoverable SCN需要更新控制文件。这时,服务器进程将等待control file parallel write事件。

4) I/O系统的性能缓慢时:

最好是将控制文件位于独立的磁盘空间上,使用裸设备或direct I/O

control file parallel write等待,通常与control file sequential read等待或enq: CF - contention等待一同出现的情况较多。enq: CF - contention等待是在多个会话为了同时更新控制文件获得CF锁的过程中发生的。control file parallel writecontrol file sequential readCF - contention等待,全是因为过多的控制文件更新或I/O系统的性能问题引发的。

server 进程更新所有控制文件时,这个事件可能出现。如果等待很短,可以不用考虑。如果等待时间较长,检查存放控制文件的物理磁盘I/O 是否存在瓶颈。

多个控制文件是完全相同的拷贝,用于镜像以提高安全性。对于业务系统,多个控制文件应该存放在不同的磁盘上,一般来说三个是足够的,如果只有两个物理硬盘,那么两个控制文件也是可以接受的。在同一个磁盘上保存多个控制文件是不具备实际意义的。

当数据库中有多个控制文件的拷贝时,Oracle 需要保证信息同步地写到各个控制文件当中,这是一个并行的物理操作过程,因为称为控制文件并行写,当发生这样的操作时,就会产生control file parallel write等待事件。

控制文件频繁写入的原因很多,比如:

l 日志切换太过频繁,导致控制文件信息相应地需要频繁更新。当系统出现日志切换过于频繁的情形时,可以考虑适当地增大日志文件的大小来降低日志切换频率。

l 系统I/O 出现瓶颈,导致所有I/O出现等待。

 

如果在等待时间中这个等待事件占的比重比较大,可以从如下几个方面来调整:

l 在确保控制文件不会同时都丢失的前提下,将控制文件的数量减小到最少降低控制文件的拷贝数量(在确保安全的前提下)

l 如果系统支持异步I/O,则推荐尽量使用异步I/O,这样可以实现真正并行的写入控制文件。

l 将控制文件移动到负载比较低,速度比较快的磁盘上去。

l 将控制文件的拷贝存放在不同的物理磁盘上的方式来缓解I/O 争用

3.2.2   control file sequential read

SELECT A.*

  FROM V$EVENT_NAME A

 WHERE NAME IN ('control file sequential read');

wpsF23.tmp 

 

这个等待事件有三个参数:

File#:要读取信息的控制文件的文件号。

Block#:读取控制文件信息的起始数据块号。

Blocks:需要读取的控制文件数据块数目。

V$SESSION_WAIT这个视图里面,这个等待事件有三个参数P1P2P3,其中P1代表正在读取的控制文件号,通过下面的SQL语句可以知道究竟是具体是哪个控制文件被读取:

SELECT * FROM X$KCCCF WHERE INDX = <file#>

P2代表开始读取的控制文件BLOCK号,它的BLOCK大小和操作系统的BLOCK大小一样,通常来说是512K,也有些UNIX的是1M或者2MP3代表会话要读取BLOCK的数量。一般来说使用参数P1P2来查询BLOCK,当然也可以包括参数P3,但是那样最终就变成了一个多BLOCK读取,因此我们一般都忽略参数P3

Wait Time: The wait time is the elapsed time of the read

Parameter

Description

file#

The control file from which the session is reading

block#

Block number in the control file from where the session starts to read. The block size is the physical block size of the port (usually 512 bytes, some UNIX ports have 1 or 2 Kilobytes).

blocks

The number of blocks that the session is trying to read

 

控制文件连续读/控制文件单个写对单个控制文件I/O 存在问题时,这两个事件会出现。如果等待比较明显,检查单个控制文件,看存放位置是否存在I/O 瓶颈。

当数据库需要读取控制文件上的信息时,会出现这个等待事件,因为控制文件的信息是顺序写的,所以读取的时候也是顺序的,因此称为控制文件顺序读,它经常发生在以下情况:

l 备份控制文件

l RAC环境下不同实例之间控制文件的信息共享

l 读取控制文件的文件头信息

l 读取控制文件其他信息

Reading from the control file. This happens in many cases. For example, while:

1Making a backup of the control files

2Sharing information (between instances) from the control file

3Reading other blocks from the control files

4Reading the header block

读取控制文件的时候遇到I/O等待就会出现这个等待事件,例如备份控制文件的时候、读取BLOCK头部都会引起这个等待事件,等待的时间就是消耗在读取控制文件上的时间。

如果这个等待事件等待的时间比较长,则需要检查控制文件所在的磁盘是否很繁忙,如果是,将控制文件移动到负载比较低,速度比较快的磁盘上去。如果系统支持异步I/O,则启用异步I/O。对于并行服务器来说,如果这种等待比较多,会造成整个数据库性能下降,因为并行服务器之间的一些同步是通过控制文件来实现的。

 解决方式与control file parallel write的解决方式一样。

首先,该等待事件并不表明数据库有问题。一个健康的系统,物理读事件应是除空闲等待事件外的最大等待事件。而该事件在RAC中尤其明显,依照经验来看,在一个正常的RAC集群中,该事件应该排在top10中,因为实例间共享同一份控制文件,对控制文件读取是很频繁的,如果被其他等待事件挤出前10了,那就得看看是哪些等待事件了。其次,可以查看AWR报告该事件的等待次数,平均等待时间,最大等待时间等信息进行进一步确认。看看这些信息比起日常AWR报告信息是否有明显的异常。

3.2.3   control file single write

SELECT A.*

  FROM V$EVENT_NAME A

 WHERE NAME IN ('control file single write');

wpsF24.tmp 

P2代表开始读取的控制文件BLOCK号,它的BLOCK大小和操作系统的BLOCK大小一样,通常来说是512K,也有些UNIX的是1K或者2KP3代表会话要读取BLOCK的数量。一般来说使用参数P1P2来查询BLOCK,当然也可以包括参数P3,但是那样最终就变成了一个多BLOCK读取,因此我们一般都忽略参数P3

V$SESSION_WAIT这个视图里面,这个等待事件有三个参数P1P2P3,其中P1代表正在读取的控制文件号,通过下面的SQL语句可以知道究竟是具体是哪个控制文被读取:

SELECT * FROM X$KCCCF WHERE INDX = <file#>

这个等待事件出现在写控制文件的共享信息到磁盘的时候,这是个自动操作,并且通过一个实例来保护的,如果是并行的数据库服务器,那么对于并行服务器来说也只能有一个实例能够执行这个操作。这个事件的等待事件就是写操作所消耗的时间。

尽管这个事件的是single write,事实上也会出现多BLOCK写的情况,即P3>1。使用参数P1P2来查询检测BLOCK而不用去考虑P3的值。

如果这个等待事件等待的时间比较长,则需要检查控制文件所在的磁盘是否很繁忙,如果是,将控制文件移动到负载比较低,速度比较快的磁盘上去。如果系统支持异步I/O,则启用异步I/O。对于并行服务器来说,如果这种等待比较多,会造成整个数据库性能下降,因为并行服务器之间的一些同步是通过控制文件来实现的。

解决方式与control file parallel write的解决方式一样。

 日志相关等待--联机重做日志文件I/O等待事件

REDO对于数据库来说非常重要,有一系列等待事件和日志相关,通过V$EVENT_NAME视图可以找到这些等待事件

我们以11g为主:

SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIKE '%log%';

wpsF25.tmp 

 

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
今儿需要部署一个Oracle环境,为了简单些,选择了Oracle提供的Linux版本介质:OracleLinux-R6-U2-Server-x86_64-dvd.iso,在安装的过程中碰见了几个常见的问题,简要记录下,便于日后查找。 问题1:无法登陆图形界面   按照正常流程安装后,默认是没有安装图形界面的,因此进入的是命令行界面,若不用静默安装或克隆安装,则必须需要图形界面。于是按照常规做如下操作:  (1) 修改/etc/inittab中id:3:initdefault的3为5。  (2) start

【函数】wm_concat包的订制 - 2016-09-20 14:09:39

  【 函数 】 wm_concat 包的订制   1    BLOG 文档结构图     2    前言部分   2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  利用系统包创建 WM_CONCAT 函数 (重点) ② ORA-00904: "wm_concat":invalid identifier 错误解决 ③  订制自己的 WM_CONCAT 函数 ④  listagg 分析函数的使用 ⑤ ORA-0
数据迁移中有一种解决方案很有亮点,如果表的数据量大,迁移涉及的表不多,同时对于维护时间有要求的情况下,物化视图的prebuilt方式就是一种很不错的选择。 大体的步骤和方法如下: 假设源环境是test_source,目标环境是test_target 在源环境中test_source的操作如下: Create table test_mv as select *from all_objects  ; alter table test_mv modify(object_id primary key); creat

【MySQL】5.7新特性之六 - 2016-09-15 17:09:05

写在前面   本系列文章基于 5.7.12 版本讲述MySQL的新特性。从安装,文件结构,SQL ,优化 ,运维层面 复制,GITD等几个方面展开介绍 5.7 的新特性和功能。同时也建议大家跟踪官方blog和官方文档,以尽快知悉其新的变化。 6.1  优化(工具方面)增强   5.7 版本中如果一个会话正在执行sql,且该sql 是支持explain的,那么我们可以通过指定会话id,查看该sql的执行计划。 EXPLAIN  [ options ]   FOR  CONNECTION connection
工具用于查看指定时间内show global status指标的变化,能够帮助运维人员了解系统负载的走势 本工具在5.5 5.6 5.7中测试通过 源码我放在百度云盘了 http://pan.baidu.com/s/1mhIeKp6 源码一共5个文件 conmysql.c main.c findv.c other.c type.h 如果源码编译使用如下方法 1、建立一个MYSQL用户用于监控,不需要什么权限只要能够show global status 即可 mysql create user mmon@'l
本文以双节点RAC为例,揭示了在执行select及DML操作过程中,Cache Fusion在幕后是如何对block进行锁管理的。 ###实例1上查询scott.t0820_1表 select * from scott.t0820_1;         ID ----------          2 select dbms_rowid.rowid_relative_fno(rowid) rfno,dbms_rowid.rowid_block_number(rowid) blkno from scott.
【故障处理】队列等待之 enq: US - contention 案例 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ① enq: US - contention 等待事件的解决 ② 一般等待事件的解决办法 ③ 队列等待的基本知识   Tips: ① 本文在 ITpub ( http://blog.itpub.net/26736162 )、博客园
    在Oracle 10g的中搭建Data Guard环境真是一个纠结,目前大体都是采用两种方式,一种是rman备份,一种是duplicate的方式,但是这两个地方不够让我满意,一来是rman备份数据量不小,需要先在本地生成备份,然后拷贝到备库去,这个搭建周期略长,另外一个就是推荐的方式duplicate,在10g中有些鸡肋的味道,本地备份,然后拷贝到备库,然后动用duplicate的方式,这样的方式还不如手工rman的方式同步来得顺心顺意,所以在10g中我是不怎么喜欢duplicate方式。当然11g
【故障处理】队列等待之 TX - allocate ITL entry 引起的死锁处理 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ① enq: TX - allocate ITL entry 等待事件的解决 ② 一般等待事件的解决办法 ③ 队列等待的基本知识 ④  ITL 死锁解决 ⑤  ITL 死锁模拟 ⑥  Merge 语句的非关联形式的查
【技巧】如何使用客户端发布 BLOG+ 如何快速发布微信公众号文章   1    BLOG 文档结构图     2    前言部分   2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  如何使用客户端发布 BLOG (重点) ②  如何快速发布微信公众号文章 ③  如何批量上传图片到blog ④  如何批量上传图片到微信公众号上     Tips: ① 本文在 itpub ( http://blog.itpu