恢复起点及终点RBA(Redo Bytes Address)问题
low cache rba就是CKPT记录的DBWR写的进度,即dbwr 进度点所对应的日志文件点(rba)。on disk rba就是LGWR的写进度,lgwr写日志文件的最末位置的地址(没有写进日志文件的日志自然就丢失了),也就是写到磁盘上的日志截止点。这是恢复所能达到的最新状态。如果数据库carsh,low cache rba是恢复的起点,on disk rba是恢复的终点。dbwr成功写完后并不把此刻scn信息写到控制文件中,只有CKPT才更新控制文件和数据文件头,dbwr只要成功将dirty data写入数据文件就是成功, CKPT只要能将最新DBWR写完的SCN更新到控制文件和数据文件头就算成功。但是
恢复相关的各种SCN及在恢复中的关系
摘自:http://space.itpub.net/35489/viewspace-694069数据库系统的当前SCN,是一直在变化的,其变动因素包括事务的提交与回滚,以及每三秒一次的心跳。而涉及到数据库启动关闭时检查的SCN有四种,其中三种记录在控制文件中:系统SCN、datafile SCN、stop SCN,另一种是记录在各个数据文件头中的start SCN。其中,数据文件头的start SCN来自系统当前SCN,而控制文件的系统SCN来自系统当前SCN,datafile SCN来自读取各个数据文件头已经改写好的start SCN,stop SCN在数据库启动后一直为NULL,而正常关闭时会被置为系统当前SCN。 数据库正常
resetlogs和noresetlogs的用法
有时在恢复数据库时,当要OPEN时,提示要以resetlogs和noresetlogs的方式打开。那么这两种方式有什么区别,在什么时候用什么方式完全恢复 -- 利用重做日志或增量备份将数据块恢复到最接近当前时间的时间点。之所以叫做完整恢复是由于Oracle应用了归档日志和联机重做日志中所有的修改。如果只是数据文件损坏,且存在备份及备份以来的所有归档日志文件,那么就能把数据库完全恢复到发生介质损坏的那个时间点。完全恢复分为数据库级别,数据文件级别以及表空间级别。不完全恢复 -- 需要将数据库恢复到历史上某个时间点,或由于丢失了联机日志
Oracle GoldenGate和Dataguard以及stream复制的区别
Oracle GoldenGate和Dataguard以及stream复制的区别可以这么说,GoldenGate是Oracle在数据迁移和数据同步方面要重点发展的产品,当然支持异构是其最大亮点。与Dataguard对比,GoldenGate在战略上是更高层次的产品,这点从GoldenGate的购买中甚至包含Dataguard的License就可见一斑,从功能上来说,GoldenGate针对Dataguard的最大优势当然是支持异构,但是,GoldenGate也不会取代Dataguard,原因很简单,Dataguard支持同步复制,而GoldenGate从原理上来说实现不了,因此,这两个产品都会持续发展下去,但从重要性来讲,GoldenGate的发展要重
SCN基础 (转)
SCN是什么在《Concepts》中是这么描述SCN的:A system change number (SCN) is a logical, internal timestamp used by Oracle Database. SCNs order events that occur within the database, which is necessary to satisfy the ACID properties of a transaction. Oracle Database uses SCNs to mark the SCN before which all changes are known to be on disk so that recovery avoids applying unnecessary redo. The database also uses SCNs to mark the point at which no redo exists for a set of data so that recovery can st
Oracle checkpoint 详解(转)
checkpoint扫盲什么是checkpoint在数据库系统中,写日志和写数据文件是数据库中IO消耗最大的两种操作,在这两种操作中写数据文件属于分散写,写日志文件是顺序写,因此为了保证数据库的性能,通常数据库都是保证在提交(commit)完成之前要先保证日志都被写入到日志文件中,而脏数据块着保存在数据缓存(buffer cache)中再不定期的分批写入到数据文件中。也就是说日志写入和提交操作是同步的,而数据写入和提交操作是不同步的。这样就存在一个问题,当一个数据库崩溃的时候并不能保证缓存里面的脏数据全部写入到数据文件中,这样在实例启
解决行迁移实例
行分链与行迁移----------------如果经常删除,那么可能不能重用块中的自由空间,所以对于这种情况,我们要利用空间的话,可以把pctused设置高点主要是在INSERT操作期间引发行分链操作。而行的迁移主要由UPDATE操作引起。行链接-- 行链接: Insert or Update引起,一个Row存在不同的block中, 行不同部分通过不同块地址(ROWID)链成一个链, 可以通过设置大的DB_BLOCK_SIZE来减少行链接的发生,但无法避免(LOB) -- 行迁移: Update引起,由于PCTFREE过小,ROWID未变, 可以通过增大PCTFREE的值减少行迁移的发生 ------行分链是DB_BLOCK_SIZE设置不够
限制某段或某个IP登陆
通过对oracle参数文件的设置,可以控制访问计算机的ip地址。在配置文件sqlnet.ora中增加:#开启对ip地址的检查tcp.validnode_checking=yes#允许访问的iptcp.invited_nodes=(ip1,ip2……)#禁止访问的ipTCP.excluded_nodes= (ip1,ip2……)然后重启LISTENER就可以了下面这种会产生额外的成生,对性能有一定的影响create or replace trigger afafter LOGON on databasebegin if(sys_context('userenv','ip_address') = '168.9.200.10') then raise_application_error(-20001,'refuse'); end if;end;/[@more@]
Oracle中查看已执行sql的执行计划
摘自:http://space.itpub.net/7607759/viewspace-445628有时候我们可能会希望查看一条已经执行过的sql的执行计划,常用的方式有两种:a,set autotrace后再重新执行一遍,不过重新执行可能会浪费时间,而且有些语句也不允许(例如修改操作的语句),或者查询v$sql_plan视图,但v$视图的可读性又不是那么好,这里提供一个新方式,通过dbms_xplan.display_cursor来获取执行过的sql的执行计划。首先看看该函数的语法:DBMS_XPLAN.DISPLAY_CURSOR(sql_id IN VARCHAR2 DEFAULT NULL,child_number IN NUMBER DEFAULT NULL,format IN VARCHAR2 DEFA
查询oracle中主外键列
一、查询表主键列select column_name from dba_cons_columns where constraint_name in (select constraint_name from dba_constraints where table_name = upper('tablename') and constraint_type = 'P');二、查询表外键列select column_name from dba_cons_columns where constraint_name in (select constraint_name from dba_constraints where table_name = upper('tablename') and constraint_type = 'R');三、查询表中列select column_name from dba_tab_columns where table_name = upper('tablename');四、查询表之间的主外键关