tag:blogger.com,1999:blog-2724506662751331553.post1941115765637479547..comments2024-02-20T02:12:29.073-08:00Comments on Oracle Database 12c: ASM 12c External Redundancy Diskgroup Handles Corrupted Blocks BetterJavier Ruizhttp://www.blogger.com/profile/12820988076924632290noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-2724506662751331553.post-30677978038792903932017-05-12T15:25:04.073-07:002017-05-12T15:25:04.073-07:00Change the seek=2048 that would hit all first 200m...Change the seek=2048 that would hit all first 200mbJavier Ruizhttps://www.blogger.com/profile/12820988076924632290noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-52547037170880618862017-05-10T07:46:20.247-07:002017-05-10T07:46:20.247-07:00Javier,
I have external redundancy diskgroup in 1...Javier,<br /><br />I have external redundancy diskgroup in 12C and want currupt it more 2 MB or 3 MB data loose so My diskgroup will be dismount.I want test this scenario in my test env.<br /><br />can you help out me How can i loose 2 or 3 MB data in diskgrpup using dd command?<br /><br />Thanks,<br />Vijay<br />email id:wise693@gmail.comAnonymoushttps://www.blogger.com/profile/01301093735551733274noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-85926845875551549912015-01-19T10:15:57.104-08:002015-01-19T10:15:57.104-08:00Was the compatible.asm set to 12.1?Was the compatible.asm set to 12.1?Javier Ruizhttps://www.blogger.com/profile/12820988076924632290noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-29637736129371921102015-01-19T08:37:32.059-08:002015-01-19T08:37:32.059-08:00Javier,
Some reason 12c didnt recover the block 40...Javier,<br />Some reason 12c didnt recover the block 40 corruption on one of the disk on external redundancy.<br /><br />NOTE: starting meta-data replication for disk 18 of group DG01 at FCN 0.31612998<br />Mon Jan 19 09:37:52 2015<br />WARNING: cache read a corrupt block: group=4(DG01) dsk=18 blk=40 disk=18 (DISK019) incarn=3620249718 au=0 blk=40 count=1<br />Mon Jan 19 09:37:52 2015<br />Errors in file /oragridbase/diag/asm/+asm/+ASM/trace/+ASM_ars0_5002.trc:<br />ORA-15196: invalid ASM block header [kfc.c:29297] [check_kfbh] [2147483666] [40] [2213122942 != 304098278]<br />NOTE: a corrupted block from group DG01 was dumped to /oragridbase/diag/asm/+asm/+ASM/trace/+ASM_ars0_5002.trc<br />WARNING: cache read (retry) a corrupt block: group=4(DG01) dsk=18 blk=40 disk=18 (DISK019) incarn=3620249718 au=0 blk=40 count=1<br />Mon Jan 19 09:37:52 2015<br />Errors in file /oragridbase/diag/asm/+asm/+ASM/trace/+ASM_ars0_5002.trc:<br />ORA-15196: invalid ASM block header [kfc.c:29297] [check_kfbh] [2147483666] [40] [2213122942 != 304098278]<br />ORA-15196: invalid ASM block header [kfc.c:29297] [check_kfbh] [2147483666] [40] [2213122942 != 304098278]<br />ERROR: cache failed to read group=4(DG01) dsk=18 blk=40 from disk(s): 18(DISK019) 18(DISK019)<br />ORA-15196: invalid ASM block header [kfc.c:29297] [check_kfbh] [2147483666] [40] [2213122942 != 304098278]<br />ORA-15196: invalid ASM block header [kfc.c:29297] [check_kfbh] [2147483666] [40] [2213122942 != 304098278]<br /><br />NOTE: cache initiating offline of disk 18 group DG01<br />NOTE: process _ars0_+asm (5002) initiating offline of disk 18.3620249718 (DISK019) with mask 0x7e in group 4 (DG01) with client assisting<br />NOTE: initiating PST update: grp 4 (DG01), dsk = 18/0xd7c8a076, mask = 0x6a, op = clear<br />Mon Jan 19 09:37:52 2015<br />GMON updating disk modes for group 4 at 69 for pid 21, osid 5002<br />ERROR: disk 18(DISK019) in group 4(DG01) cannot be offlined because the disk group has external redundancy.<br />Mon Jan 19 09:37:52 2015<br />ERROR: too many offline disks in PST (grp 4)<br />Mon Jan 19 09:37:52 2015<br />NOTE: cache dismounting (not clean) group 4/0x7DD86EFF (DG01)<br />NOTE: messaging CKPT to quiesce pins Unix process pid: 5038, image: oracle@alpqdbs001 (B000)<br />Mon Jan 19 09:37:52 2015<br />NOTE: halting all I/Os to diskgroup 4 (DG01)<br />Mon Jan 19 09:37:52 2015<br />NOTE: LGWR doing non-clean dismount of group 4 (DG01) thread 1<br />NOTE: LGWR sync ABA=604.8015 last written ABA 604.8015<br />Mon Jan 19 09:37:52 2015<br />NOTE: cache dismounted group 4/0x7DD86EFF (DG01)<br />Mon Jan 19 09:37:52 2015<br />SQL> alter diskgroup DG01 dismount force /* ASM SERVER:2111336191 */<br />Anonymoushttps://www.blogger.com/profile/04703919779565209026noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-78068223876872900272013-07-18T12:45:55.316-07:002013-07-18T12:45:55.316-07:00Thanks for the reply
I agree with the md_backup b...Thanks for the reply<br /><br />I agree with the md_backup but remember md_backup/md_restore does not take care of the superblocks. The true solution for preventing a diskgroup outage due to some disk issue is to use normal or high redundancy diskgroup.<br /><br />ASM 12101 Normal Redundancy Testing http://db12c.blogspot.com/2013/07/asm-12101-normal-redundancy-testing.htmlJavier Ruizhttps://www.blogger.com/profile/12820988076924632290noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-3068648050794408392013-07-18T12:22:37.081-07:002013-07-18T12:22:37.081-07:00Javier:
Thanks for the great post and research in ...Javier:<br />Thanks for the great post and research in 12c.<br />Since the header info is backed up in second last block of allocation unit 1, "kfed repair" finds header block with KFBTYP_DISKHEAD type and restores it. Hence the reason that if first 2 to 3 MB info is lost you will likely have to recreate the diskgroup. This means that we still have to backup ASM metadata using md_backup so that we can also backup attributes, templates, directories etc, otherwise one has to find all that information from ASM alert log while re-creating disk group.<br /><br />Bottom line is if you are still using 10g then backup first 4k using dd command. 11g onwards use md_backup or kfed utility.Anonymoushttps://www.blogger.com/profile/10084480900480880757noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-56258597760054233992013-07-17T16:04:33.922-07:002013-07-17T16:04:33.922-07:00Thank You BelMan you may also be interested in my ...Thank You BelMan you may also be interested in my other blog post for ASM 12c<br /><br />ASM 12101 Normal Redundancy Testing http://db12c.blogspot.com/2013/07/asm-12101-normal-redundancy-testing.html<br /><br />ASM 12c New Feature Replace Command http://db12c.blogspot.com/2013/07/asm-12c-new-feature-replace-command.html<br /><br /><br />Javier Ruizhttps://www.blogger.com/profile/12820988076924632290noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-85490113394528566092013-07-17T13:21:49.096-07:002013-07-17T13:21:49.096-07:00Good JobGood JobBelManhttps://www.blogger.com/profile/01153346357984118886noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-60601616460302590112013-07-15T11:33:28.922-07:002013-07-15T11:33:28.922-07:00You can also check my blog on ASM 12c Normal Redun...You can also check my blog on ASM 12c Normal Redundancy testing http://db12c.blogspot.com/2013/07/asm-12101-normal-redundancy-testing.htmlJavier Ruizhttps://www.blogger.com/profile/12820988076924632290noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-34195760065551844432013-07-15T11:31:28.839-07:002013-07-15T11:31:28.839-07:00Based on information from Oracle the protection of...Based on information from Oracle the protection of Metadata is transparent and automatic with PHY_META_REPLICATED. Seems the metadata is being rebuilt from the replicated blocks. Oracle did note that in external redundancy diskgroup if more the 2 or 3 MB of is lost the diskgroup would need to be rebuilt. See the info in the conclusion of the blog.Javier Ruizhttps://www.blogger.com/profile/12820988076924632290noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-62115324845834242952013-07-15T11:25:43.263-07:002013-07-15T11:25:43.263-07:00Good info Javier. How did 12.1 recover the block 4...Good info Javier. How did 12.1 recover the block 40 since this details not on alertlog?Anonymoushttps://www.blogger.com/profile/04703919779565209026noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-24112831157217384952013-07-12T06:17:20.622-07:002013-07-12T06:17:20.622-07:00You're WelcomeYou're WelcomeJavier Ruizhttps://www.blogger.com/profile/12820988076924632290noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-28061931748217882752013-07-12T06:00:18.855-07:002013-07-12T06:00:18.855-07:00Really interesting. Thanks for sharing this.Really interesting. Thanks for sharing this.SYSDBAhttps://www.blogger.com/profile/04171778675369505586noreply@blogger.comtag:blogger.com,1999:blog-2724506662751331553.post-91888473263668315452013-07-12T05:52:22.287-07:002013-07-12T05:52:22.287-07:00Great!!Great!!Anonymoushttps://www.blogger.com/profile/01933542265766541268noreply@blogger.com