8 Replies Latest reply: Oct 14, 2013 4:52 PM by Andrey Goryunov RSS

    ASM Endianess conversion

    OraInsights

      Hi,

      anyone ever tried to mount a big endian asm disk (AIX for example) on little endian env (linux x86)?

       

      I have a disk that KFED is able to read but ASM is unable to mount it due to endianess incompatibility.

       

      Thanks!

       

      from the KFED read:

       

      kfbh.endian:                          0 ; 0x000: 0x00

      kfbh.hard:                          130 ; 0x001: 0x82

      kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD

      kfbh.datfmt:                          1 ; 0x003: 0x01

      kfbh.block.blk:                       0 ; 0x004: blk=0

      kfbh.block.obj:                     128 ; 0x008: file=128

      kfbh.check:                  1999209486 ; 0x00c: 0x7729840e

      kfbh.fcn.base:                        0 ; 0x010: 0x00000000

      kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000

      kfbh.spare1:                          0 ; 0x018: 0x00000000

      kfbh.spare2:                          0 ; 0x01c: 0x00000000

      kfdhdb.driver.provstr:         ORCLDISK ; 0x000: length=8

      kfdhdb.driver.reserved[0]:            0 ; 0x008: 0x00000000

      kfdhdb.driver.reserved[1]:            0 ; 0x00c: 0x00000000

      kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000

      kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000

      kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000

      kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000

      kfdhdb.compat:                     4106 ; 0x020: 0x0000100a

      kfdhdb.dsknum:                        0 ; 0x024: 0x0000

      kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL

      kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER

      kfdhdb.dskname:              AIXDG_0000 ; 0x028: length=10

      kfdhdb.grpname:                   AIXDG ; 0x048: length=5

      kfdhdb.fgname:               AIXDG_0000 ; 0x068: length=10

      kfdhdb.capname:                         ; 0x088: length=0

      kfdhdb.crestmp.hi:           3043620609 ; 0x0a8: HOUR=0x1 DAYS=0x18 MNTH=0xd YEAR=0x5a7

      kfdhdb.crestmp.lo:              9184640 ; 0x0ac: USEC=0x180 MSEC=0x309 SECS=0x8 MINS=0x0

      kfdhdb.mntstmp.hi:           3043620609 ; 0x0b0: HOUR=0x1 DAYS=0x18 MNTH=0xd YEAR=0x5a7

      kfdhdb.mntstmp.lo:              7910528 ; 0x0b4: USEC=0x80 MSEC=0x22d SECS=0x7 MINS=0x0

      kfdhdb.secsize:                       2 ; 0x0b8: 0x0002

      kfdhdb.blksize:                      16 ; 0x0ba: 0x0010

      kfdhdb.ausize:                     4096 ; 0x0bc: 0x00001000

      kfdhdb.mfact:                2159804672 ; 0x0c0: 0x80bc0100

      kfdhdb.dsksize:                 7864320 ; 0x0c4: 0x00780000

      kfdhdb.pmcnt:                  33554432 ; 0x0c8: 0x02000000

      kfdhdb.fstlocn:                16777216 ; 0x0cc: 0x01000000

      kfdhdb.altlocn:                33554432 ; 0x0d0: 0x02000000

      kfdhdb.f1b1locn:               33554432 ; 0x0d4: 0x02000000

      kfdhdb.redomirrors[0]:                0 ; 0x0d8: 0x0000

      kfdhdb.redomirrors[1]:                0 ; 0x0da: 0x0000

      kfdhdb.redomirrors[2]:                0 ; 0x0dc: 0x0000

      kfdhdb.redomirrors[3]:                0 ; 0x0de: 0x0000

      kfdhdb.dbcompat:                   4106 ; 0x0e0: 0x0000100a

      kfdhdb.grpstmp.hi:           3043620609 ; 0x0e4: HOUR=0x1 DAYS=0x18 MNTH=0xd YEAR=0x5a7

      kfdhdb.grpstmp.lo:              2630528 ; 0x0e8: USEC=0x380 MSEC=0x208 SECS=0x2 MINS=0x0

      kfdhdb.vfstart:                       0 ; 0x0ec: 0x00000000

      kfdhdb.vfend:                         0 ; 0x0f0: 0x00000000

      kfdhdb.spfile:                        0 ; 0x0f4: 0x00000000

      kfdhdb.spfflg:                        0 ; 0x0f8: 0x00000000

      kfdhdb.ub4spare[0]:                   0 ; 0x0fc: 0x00000000

      kfdhdb.ub4spare[1]:                   0 ; 0x100: 0x00000000

      kfdhdb.ub4spare[2]:                   0 ; 0x104: 0x00000000

      kfdhdb.ub4spare[3]:                   0 ; 0x108: 0x00000000

      kfdhdb.ub4spare[4]:                   0 ; 0x10c: 0x00000000

      kfdhdb.ub4spare[5]:                   0 ; 0x110: 0x00000000

      kfdhdb.ub4spare[6]:                   0 ; 0x114: 0x00000000

      kfdhdb.ub4spare[7]:                   0 ; 0x118: 0x00000000

      kfdhdb.ub4spare[8]:                   0 ; 0x11c: 0x00000000

      kfdhdb.ub4spare[9]:                   0 ; 0x120: 0x00000000

      kfdhdb.ub4spare[10]:                  0 ; 0x124: 0x00000000

      kfdhdb.ub4spare[11]:                  0 ; 0x128: 0x00000000

      kfdhdb.ub4spare[12]:                  0 ; 0x12c: 0x00000000

      kfdhdb.ub4spare[13]:                  0 ; 0x130: 0x00000000

      kfdhdb.ub4spare[14]:                  0 ; 0x134: 0x00000000

      kfdhdb.ub4spare[15]:                  0 ; 0x138: 0x00000000

      kfdhdb.ub4spare[16]:                  0 ; 0x13c: 0x00000000

      kfdhdb.ub4spare[17]:                  0 ; 0x140: 0x00000000

      kfdhdb.ub4spare[18]:                  0 ; 0x144: 0x00000000

      kfdhdb.ub4spare[19]:                  0 ; 0x148: 0x00000000

      kfdhdb.ub4spare[20]:                  0 ; 0x14c: 0x00000000

      kfdhdb.ub4spare[21]:                  0 ; 0x150: 0x00000000

      kfdhdb.ub4spare[22]:                  0 ; 0x154: 0x00000000

      kfdhdb.ub4spare[23]:                  0 ; 0x158: 0x00000000

      kfdhdb.ub4spare[24]:                  0 ; 0x15c: 0x00000000

      kfdhdb.ub4spare[25]:                  0 ; 0x160: 0x00000000

      kfdhdb.ub4spare[26]:                  0 ; 0x164: 0x00000000

      kfdhdb.ub4spare[27]:                  0 ; 0x168: 0x00000000

      kfdhdb.ub4spare[28]:                  0 ; 0x16c: 0x00000000

      kfdhdb.ub4spare[29]:                  0 ; 0x170: 0x00000000

      kfdhdb.ub4spare[30]:                  0 ; 0x174: 0x00000000

      kfdhdb.ub4spare[31]:                  0 ; 0x178: 0x00000000

      kfdhdb.ub4spare[32]:                  0 ; 0x17c: 0x00000000

      kfdhdb.ub4spare[33]:                  0 ; 0x180: 0x00000000

      kfdhdb.ub4spare[34]:                  0 ; 0x184: 0x00000000

      kfdhdb.ub4spare[35]:                  0 ; 0x188: 0x00000000

      kfdhdb.ub4spare[36]:                  0 ; 0x18c: 0x00000000

      kfdhdb.ub4spare[37]:                  0 ; 0x190: 0x00000000

      kfdhdb.ub4spare[38]:                  0 ; 0x194: 0x00000000

      kfdhdb.ub4spare[39]:                  0 ; 0x198: 0x00000000

      kfdhdb.ub4spare[40]:                  0 ; 0x19c: 0x00000000

      kfdhdb.ub4spare[41]:                  0 ; 0x1a0: 0x00000000

      kfdhdb.ub4spare[42]:                  0 ; 0x1a4: 0x00000000

      kfdhdb.ub4spare[43]:                  0 ; 0x1a8: 0x00000000

      kfdhdb.ub4spare[44]:                  0 ; 0x1ac: 0x00000000

      kfdhdb.ub4spare[45]:                  0 ; 0x1b0: 0x00000000

      kfdhdb.ub4spare[46]:                  0 ; 0x1b4: 0x00000000

      kfdhdb.ub4spare[47]:                  0 ; 0x1b8: 0x00000000

      kfdhdb.ub4spare[48]:                  0 ; 0x1bc: 0x00000000

      kfdhdb.ub4spare[49]:                  0 ; 0x1c0: 0x00000000

      kfdhdb.ub4spare[50]:                  0 ; 0x1c4: 0x00000000

      kfdhdb.ub4spare[51]:                  0 ; 0x1c8: 0x00000000

      kfdhdb.ub4spare[52]:                  0 ; 0x1cc: 0x00000000

      kfdhdb.ub4spare[53]:                  0 ; 0x1d0: 0x00000000

      kfdhdb.acdb.aba.seq:                  0 ; 0x1d4: 0x00000000

      kfdhdb.acdb.aba.blk:                  0 ; 0x1d8: 0x00000000

      kfdhdb.acdb.ents:                     0 ; 0x1dc: 0x0000

      kfdhdb.acdb.ub2spare:                 0 ; 0x1de: 0x0000

        • 1. Re: ASM Endianess conversion
          Levi Pereira

          I already tried that, won't work and is not supported by Oracle.

           

          Every AU, Extent, etc.. have own ENDIAN, change it manually corrupt de ASM block.

          https://forums.oracle.com/thread/2387671


          Big-endian files are stored different way of little-endian. In a little-endian file these bytes are reversed compared with big-endian files.

          Some compilers have options to generate code that globally enables the conversion for all file IO operations. This allows one to reuse code on a system with the opposite endianness without having to modify the code itself. If the compiler does not support such conversion, the programmer needs to swap the bytes via ad hoc code. (I believe that ASM does not do that)


          If you have the number 0xDEADBEEF in a big endian platform, in little endian platform system stored as 0xEFBEADDE), because that you will need a compiler to convert data, the parameter "kfbh.endian" is only a parameter, changing it you will corrupt the datablock.


           

          Message was edited by: Levi-Pereira

          • 2. Re: ASM Endianess conversion
            OraInsights

            Thanks! I did try to mess around with the endian parameter in the asm metadata using kfed write and asm did show the asm diskgroup. However the disk is not mountable

            • 3. Re: ASM Endianess conversion
              OraInsights

              do you know any other way to mount big endian asm disk on little endian server?

              thanks

              • 4. Re: ASM Endianess conversion
                Levi Pereira

                Using ASM the anwser is NO, also you need convert database before move to another ENDIAN does not matter if you are ASM or not, then you should use Convert Datafile on source  and Import it on Linux.


                This post is Linux to AIX but also work AIX to Linux

                How Convert full Database 10g Linux-x86-64bit to AIX-64bit different Endian Format | Levi Pereira


                 

                The point is AVOID LAN, correct?

                 

                Using RAW Devices during migration can avoid copy over LAN. You can test it to make sure will work.

                 

                eg

                CONVERT TABLESPACE

                   DATA_MOVE TO PLATFORM = "Linux x86 64-bit"

                    DB_FILE_NAME_CONVERT ('+TSM/tsm/datafile/data_move.285.782738837', '/dev/rhdisk12');

                 

                Starting conversion at source at 08-MAY-12

                allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=498 device type=DISK

                channel ORA_DISK_1: starting datafile conversion input

                datafile file number=00011 name=+TSM/tsm/datafile/data_move.285.782738837

                converted datafile=/dev/rhdisk12

                channel ORA_DISK_1: datafile conversion completed

                Then when import dumpfile just point the raw disk.

                The raw device must not be created under VG. (i.e you must create each datafile as raw device (LUN)on storage, NOT use LV of AIX).

                • 5. Re: ASM Endianess conversion
                  OraInsights

                  The RMAN convert is not helpful in my case. In my scenarion I'm left with a diskgroup containing redo logs and archive logs and I need to mount them into little endian platform when the source is big...

                  • 6. Re: ASM Endianess conversion
                    Levi Pereira

                    I don't get it.

                     

                    You are trying mount ASM Disk from different endian, but Database files (such as redo,archivelog, datafile,controlfile) also have own ENDIAN  on your case is BIG.

                     

                    What you are trying to do is, such as  copy a redo/archivelog from jfs2 to ext3, even if you are able to copy it (which I make sure you can) you can not use it, because they are from different endian.

                     

                    Does not matter what filesystem (ASM, NFS, JFS2, EXT4, etc) you are using, you MUST convert ALL Database files between different ENDIAN.

                     

                    Is not about filesystem, but it's about Migrate Database between different Endian.

                    • 7. Re: ASM Endianess conversion
                      OraInsights

                      I think I wasn't so clear in my original post. So here it is again:

                       

                      -- Production OS is AIX (other big endian OS)

                      -- DB lies on ASM. RAC / NO RAC is irrelevant but ASM is.

                      -- One LUN is dedicated to Redo and Archive logs.

                       

                      Production is lost and I need to extract just this specific LUN but the challenge is to read the data on a little endian OS (such as Linux x86).

                       

                      I do not mind how to access the disk, I just need to extract the files and be able to convert them to little endian (mount them first of course..)

                       

                      Couldn't find a way so far to do it.

                      btw, a non supported way is also optional...

                      Thanks again!

                      • 8. Re: ASM Endianess conversion
                        Andrey Goryunov

                        I personally never tried to extract any of files

                        but might be the utility amdu will help you somehow

                        http://asmsupportguy.blogspot.com.au/2011/09/amdu-asm-metadata-dump-utility.html

                         

                        HTH,

                        Andrey