标签归档:scn

基于scn恢复ADG和ASM在rman备份恢复过程中的tuning

以下过程主要涉及如下3个问题: 1,根据SCN号“重做”ADG 2,主库是ASM数据库,使用了一半自动命名文件名的文件,和一部分手工指定文件名(别名)的文件: ——————————————————————————– 针对OMF的数据文件使用下面命令: catalog start with ‘+DATA1/MUM/DATAFILE/’; 针对非OFM的数据文件使用下面命令: catalog datafilecopy ‘<File-Specification>’; ——————————————————————————– 3,优化ASM的IO效率 源库: 备库: 查看主库force logging: 查看有哪些文件含有force logging操作,以及他们的scn(下次执行,应该带上orderby,这样更清晰): 备库: 生成批量的backup命令,进行基于scn的恢复(含有force logging的都需要) 主库,备份可以有两个方法: 1,根据上述备份命令写备份脚本 2,从最早的一个scn开始备份也可以 restore 数据文件: 总共新增加了3个文件,重新备份这3个文件即可: 现有ASM的文件信息如下: 有两个错误,这个是因为上面操作时没有注意到数据库中有2个offline的数据文件,下次操作记得备份时把offline的文件不要备份就好了。。。。。。 <bold>开始recover database,这个过程非常慢长,主要原因: 1,存储着实太差了。。。。。。 2,网络速度太差了(这个是NFS的空间) 3,ASM在recover 时需要tuning </bold> 监控rman恢复进度: … 继续阅读

发表在 ASM, backup&recovery, Dataguard | 标签为 , , , , | 留下评论

浅谈SCN_2–_kcmgas_函数

从oracle10g开始,我们可以通过查询v$database.current_scn来获取当前数据库的scn,这个是通过调用”kcmgas”函数来完成的,这是一个oracle intance的永久内存结构体,我们可以查询 v$syssta来观察该函数的调用情况: 先看对v$database.current_scn的查询来获取scn的方式: 详细描述请见:浅谈SCN_2-_kcmgas_函数 姊妹篇见:浅谈SCN_1–从oracle7至今,如何获取scn

发表在 Internal | 标签为 , | 留下评论

浅谈SCN_1–从oracle7至今,如何获取scn

SCN (System Change Number) 是Oracle数据库中保持数据一致性的主要机制。数据库内部的scn有好几种,会在后面的blog中慢慢细数。今天主要我们如何获取数据库的scn? SCN是一个很大的数字,Oracle使用6 Bytes记录SCN,也就是48bit(一个byte是8bit,每个bit存储0或者1),其最大值是其格式貌似由两部分组成: wrap.base 其中前面16bit的十进制数表示wrap,后面32bit的十进制数表示base,当base达到4 billion(4G),wrap就会增加1。 这是因为Oracle使用c语言写的,在c语言里面 long 类型是一个32bit整数,即最大是 4G(4294967296,2 power 32),因此,scn若在自增的时候采用long类型的整数,正好是4字节,因此,当scn base(ktuxescnb )增加到4G的时候,就需要扩充,于是就有了scn wrap (ktuxescnw),这个表示每满一个 4G(ktuxescnb) 则该值被重置为0,然后再次开始递增1。 详细描述请见:浅谈SCN_1-_从oracle7至今,如何获取scn

发表在 Internal | 标签为 | 留下评论