Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Utility to inspect RAW disk
22 views
Skip to first unread message
Cats
Feb 8, 2012, 2:42:04 PM2/8/12
to
Is there a utility in either Informix or Solaris that will let me
inspect RAW disk, when Informix isn't running? And will I see the
name of the dbspace that Informix knew that bit of RAW by somewhere
near the start?
The customer decided to do something to their SAN without consulting
and are now facing either sorting out which bit of disk is which, or
restoring from a level 0 which is missing the last hour or more of
work.
inspect RAW disk, when Informix isn't running? And will I see the
name of the dbspace that Informix knew that bit of RAW by somewhere
near the start?
The customer decided to do something to their SAN without consulting
and are now facing either sorting out which bit of disk is which, or
restoring from a level 0 which is missing the last hour or more of
work.
Gabriel MOSCALU
Feb 8, 2012, 2:57:27 PM2/8/12
to ramw...@uk2.net, inform...@iiug.org
Hi,
There's no tool in solaris afaik. IDS uses it's own formatting for raw devices.
You might try with oncheck and see if that works... Eitherway , when i did this before, i ended up restoring a L0 backup.
Best regards,
Gabriel
Sent from my HTC phone
There's no tool in solaris afaik. IDS uses it's own formatting for raw devices.
You might try with oncheck and see if that works... Eitherway , when i did this before, i ended up restoring a L0 backup.
Best regards,
Gabriel
Sent from my HTC phone
_______________________________________________
Informix-list mailing list
Inform...@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
Informix-list mailing list
Inform...@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
Art Kagel
Feb 8, 2012, 3:18:20 PM2/8/12
to Cats, inform...@iiug.org
You can use the following command:
dd if=<raw disk path> bs=2k count=2 | od -x | more
to examine the page headers for each chunk file. If this is Informix 10 or later then the first four bytes on each page are the page number (the first page in a chunk is page zero) and the 5th and 6th bytes on each page is the chunk number (note if the chunk belongs to a dbspace with a larger pagesize (so all windows and AIX users) adjust the bs=2k appropriately so you can compare this 16bit integer from page to page to validate that it looks like a good Informix chunk file). These are binary values so you will have to interpolate the hex output and recognize whether your system is BIG-ENDIAN or LITTLE-ENDIAN if there are more than 255 chunks. (Older versions encoded the chunk number in the first twelve bits out of the first four bytes <once bytes were rearranged for endianness>.)
You will find the chunk list starting on page 6 or 7 (the engine alternates updating one of the other) of the root chunk (chunk #1) and can view the paths using od -c. If you have more than a few chunks you will have to look at the extended chunk table pages which IB begin on page 14 of the root chunk (there will actually be a pointer to the page number in the header of the first chunk page naming the actual next page).
This is all described in more detail in my Informix Internals presentation which I last presented at the IIUG Conference in 2008 which should be online at the IIUG site members pages.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.
dd if=<raw disk path> bs=2k count=2 | od -x | more
to examine the page headers for each chunk file. If this is Informix 10 or later then the first four bytes on each page are the page number (the first page in a chunk is page zero) and the 5th and 6th bytes on each page is the chunk number (note if the chunk belongs to a dbspace with a larger pagesize (so all windows and AIX users) adjust the bs=2k appropriately so you can compare this 16bit integer from page to page to validate that it looks like a good Informix chunk file). These are binary values so you will have to interpolate the hex output and recognize whether your system is BIG-ENDIAN or LITTLE-ENDIAN if there are more than 255 chunks. (Older versions encoded the chunk number in the first twelve bits out of the first four bytes <once bytes were rearranged for endianness>.)
You will find the chunk list starting on page 6 or 7 (the engine alternates updating one of the other) of the root chunk (chunk #1) and can view the paths using od -c. If you have more than a few chunks you will have to look at the extended chunk table pages which IB begin on page 14 of the root chunk (there will actually be a pointer to the page number in the header of the first chunk page naming the actual next page).
This is all described in more detail in my Informix Internals presentation which I last presented at the IIUG Conference in 2008 which should be online at the IIUG site members pages.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.
Gabriel MOSCALU
Feb 8, 2012, 5:07:02 PM2/8/12
to Gabriel MOSCALU, ramw...@uk2.net, inform...@iiug.org
Having a deeper thought on this: if they re-defined your luns on the san, and wwn numbers changed (i am just guessing here, as you just loose luns
located on a san when everyday ops are done there), you have very low chances of actually getting your data back.
It is worth trying Art's suggestion but i guess you don't have your partnum & dbspace names written anywhere to recognize them.
Do you still have your logical logs backed-up for a point-in-time restore, or traces to replay your 1 hour transactions? I guess it's all up to how much time you got to take action to recover...
It is worth trying Art's suggestion but i guess you don't have your partnum & dbspace names written anywhere to recognize them.
Do you still have your logical logs backed-up for a point-in-time restore, or traces to replay your 1 hour transactions? I guess it's all up to how much time you got to take action to recover...
Best regards,
Gabriel
Sent from my HTC phone
----- Reply message -----
From: "Gabriel MOSCALU" <gabriel...@eservglobal.com>
To: "ramw...@uk2.net" <ramw...@uk2.net>, "inform...@iiug.org" <inform...@iiug.org>
Subject: Utility to inspect RAW disk
Date: Wed, Feb 8, 2012 10:05 pm
From: "Gabriel MOSCALU" <gabriel...@eservglobal.com>
To: "ramw...@uk2.net" <ramw...@uk2.net>, "inform...@iiug.org" <inform...@iiug.org>
Subject: Utility to inspect RAW disk
Date: Wed, Feb 8, 2012 10:05 pm
Hi,
There's no tool in solaris afaik. IDS uses it's own formatting for raw devices.
You might try with oncheck and see if that works... Eitherway , when i did this before, i ended up restoring a L0 backup.
Best regards,
Gabriel
Sent from my HTC phone
There's no tool in solaris afaik. IDS uses it's own formatting for raw devices.
You might try with oncheck and see if that works... Eitherway , when i did this before, i ended up restoring a L0 backup.
Best regards,
Gabriel
Sent from my HTC phone
----- Reply message -----
From: "Cats" <ramw...@uk2.net>
To: "inform...@iiug.org" <inform...@iiug.org>
Subject: Utility to inspect RAW disk
Date: Wed, Feb 8, 2012 9:45 pm
From: "Cats" <ramw...@uk2.net>
To: "inform...@iiug.org" <inform...@iiug.org>
Subject: Utility to inspect RAW disk
Date: Wed, Feb 8, 2012 9:45 pm
Cats
Feb 9, 2012, 2:36:34 AM2/9/12
to
They managed to guess lucky about which bit of disk was which bit of
dbspace. Visiting this morning for some debriefing.
dbspace. Visiting this morning for some debriefing.
0 new messages