Phone: +86 13764045638 Email: service@parnassusdata.com 7 x 24 online support!

    You are here

    • You are here:
    • Home > Blogs > PDSERVICE's blog > Is it possible to access the oracle asm diskgroup if the underline disk partition table is corrupted

Is it possible to access the oracle asm diskgroup if the underline disk partition table is corrupted

Is it possible to access the oracle asm diskgroup if the underline disk partition table is corrupted

We had issues with one of RAC node going down and were reported saying the LUN/partition table missing due to which the issue occured. But the ASM, database and CRS logs during the issue occurance were analyzed. The analysis does not reveal any evidence pointing to missing partition table OR even block corruption. In fact database was up during said period. Further, team analyzed OS logs during which the issue occured and beyond that timestamp but did not find evidence to show partition table missed or damaged during the period.
 
So, we would like to know that,
 
a) Can ASM work for days with partition table on cache while partition table on disk is damaged?
b) What is periodic update/syncing protocol between ASM cache and disk for partition information?
 
We would appreciate for looking into our queries mentioned above and respond back immediately to take the analysis further ahead to find the RCA and take preventive measures to avoid the same in future.
 
 
 
 
 
SM can continue to function when the ASM disk header on disk is corrupted or lost. ASM keeps the ASM disk header in the (ASM instance) cache, not the disk partition table.
 
If the disk partition table is lost/damaged/deleted/modified, the ASM disk header may or may not be affected. For example, if the disk partition table is deleted, that would not affect the ASM disk header at all. ASM disk group would stay mounted and all would seem to be fine. You would be able to dismount the disk group just fine. But the next time you try to mount the disk group, ASM will not be able to find the disk header as it will look at the beginning of the disk. The disk header, and in fact all other data, including ASM metadata, will be there, but ASM will not be able to find it. If this was the only thing that happened, i.e. lost or deleted disk partition table, the fix is very easy. Just recreate the partition table on that disk.
 
But if the partition table and ASM disk header are in fact damaged, say someone overwrote the first megabyte of the disk, then again ASM disk group will stay mounted and all would appear to be fine. That is because ASM keeps the ASM disk header in the cache. But if you were to dismount the disk group, you would not be able to mount it again as the ASM metadata is now truly lost.
 
 
 
 
"what happen when we  insert a data?"  Remember also that the ASM instance only keeps track of where database data file extents are stored and does not take part in actual database IO.  Each database instance caches the ASM file information it gets and uses this information to perform the IO directly to the data files.  Everything would work until such time as ASM was unable to provide the database with needed file information.