标签归档：scn

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

发表于 2013 年 10 月 18 日 由 Lunar

以下过程主要涉及如下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_函数

发表于 2013 年 8 月 22 日 由 Lunar

从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

发表于 2013 年 8 月 22 日 由 Lunar

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 | 标签为 | 留下评论