scn

[20190913]完善vim的bccacl插件2.txt --//继续完善vim的bccacl插件。 --//\bc 计算也可以直接使用 \bb 操作，这样操作更快一些。 --//增加直接写好算式计算的快捷\cc(注不用输入最后等号),这步直接调用bc，这样算式没有问题，都能计算正确。 "" calculate expression on current line, pick a mapping, or use the Leader nnoremap <Leader>bx <Esc>A <Esc>"eyy$:call CalcLines(0)<CR> nnoremap <Leader>bc <Esc>A = <Esc>"eyy:call CalcLines(0)<CR> nnoremap <Leader>bb <Esc>A = <Esc>"eyy:call CalcLines(0)<CR> noremap <Leader>cc Yp!!bc -lq<CR>kA = <ESC>J --//例子： x=12;y=23.1;x*y = 277.2 (输入\cc) a=12;b=F; a+b = 27 (输入\cc) scale=0;4300011211%2^32 = 5043915 (输入\cc) 4300011211%2^32 = .00000000003987734528 (输入

Cr块consistent read块也就是用来维护oracle的读一致性的数据块。当查询某些数据的时候，发现数据块的版本比我们要查询的新，例如session1执行了dml操作并没有提交，session2此时查找跟session1相关的dml操作的数据信息，此时查询的数据却是原来的数据信息。 查询的过程会在undo段中查找该数据块的前映像后，然后把前映像和current块合并形成了一个CR block，通过查询cr block就可以满足数据的一致性了。 CR block存在与sga的buffer cache中，在db cache里申请一个数据块，然后对应的回滚段的前映像生成cr block。 cr块的数量是由隐含参数_db_block_max_cr_dba控制的，默认是最高同时存在5个cr块，构造cr块时cr block created计数器都会增加1. 由于cr block和current block的数据块的rdba都是相同的，会放在相同的hash链上，当然某些block的cr block的版本过多，自然会引起hash链上的竞争，导致latch buffer cache chain闩竞争。 当然在利用回滚段的前映像和current block构造cr块时，很有可能回滚段的已经被覆盖，也就会出现常见的ora-01555快照过旧。 一个sql语句如何去查询数据信息了

SCN（system change number） 系统更改号 RBA （redo block address）onlin redo log的重做块地址 select dbms_flashback.get_system_change_number from dual; 系统当前的SCN SCN的更新触发是由commit来进行的，每隔3秒种系统也都会刷新一次SCN CKPT进程是在checkpoint发生的时候将数据库当前的SCN更新入数据库文件头和控制文件当中，DBWn进程将buffer cache中的脏数据块(dirty block)写到数据文件中，而是ckpt在更新控制文件和数据文件头的有关信息后，通知DBWn进程，产生一个检查点，在产生检查点的时候，DBWn进程会将buffer cache中的脏数据(当前online redo log对应的脏数据)，写入我们的数据文件当中，基本就是这么一个循环过程，ckpt进程还会在控制文件当中记录RBA，这个地址用来标志实例恢复的时候需要从日志中的那个位置开始，也就是一个checkpoint对应一个rba，当instance recovery（实例恢复）的时候oracle就会知道从那个检查点开始在redo的那个rba开始介质恢复！ 创建检查点（checkpoint）的条件： 1.alter system checkpoint 　 　2

使用_allow_resetlogs_corruption打开无归档日志rman备份库 rman还原恢复操作 --还原数据库 RMAN> restore database; --恢复数据库 RMAN> recover database; Starting recover at 2012-03-08 21:20:45 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=65 device type=DISK starting media recovery RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 03/08/2012 21:20:47