一个非常有意思的跨平台迁移的问题

biti_rainy

起源：
os中看到的数据文件比db中看到的多一个 oracle block。

10g在做跨平台迁移的时候，不同  byte order(endianess) 的硬件平台下的文件，可以使用rman来修改文件字节顺序，这样就可以实现跨平台迁移，这也就是 10g 中提到的不同平台的 big /little 问题，也就是说高位在前还是高位在后，这是和硬件特征相关的。

那对于相同 byte  order 的硬件平台来说，唯一可能不同的地方，就在于 os 中比 db 中看到的多一个 block部分可能不一样。

由此我们产生一个想法，那我们是否可以修改这个block来迁移数据文件？


当前有2人做了这个测试
d.c.b.a  做的测试中，根据他的描述，数据库是8i，从  windows / sun solaris for  x86 pc 拷贝到linux ，重新创建控制文件后可以直接打开，并稳定运行了2天。

wanghai 刚才做了测试，从windows 拷贝到 linux ，创建控制文件不能识别数据文件，但是通过dd拷贝linux系统上的 block 来覆盖这个文件，则可以创建控制文件并open db使用。



由此我们是否可以在各硬件平台做进一步的测试和对比，找出规律，实现跨平台迁移（至少相同 byte  order 的可以迁移）。


OS 上查看首个文件头 block信息参考如下
目前在linux下我发现创建数据库的时候创建的文件的信息是一样的，手工创建的文件的信息是一样的，比如下面我怀疑  000001 056135 055133  这样的信息可能和 os 或者数据库版本有关，或者dbid有关，有待进一步考察。
   

[root@member-crm-db crmm]# od   users01.dbf  -N  8192
0000000 001000 000000 020000 000000 000200 000001 056135 055133
0000020 000000 000000 022207 000000 000000 000000 000000 000000
0000040 000000 000000 000000 000000 000000 000000 000000 000000
*
0020000
[root@member-crm-db crmm]# od   system01.dbf  -N  8192           
0000000 001000 000000 020000 000000 000200 000001 056135 055133
0000020 000000 000000 022207 000000 000000 000000 000000 000000
0000040 000000 000000 000000 000000 000000 000000 000000 000000
*
0020000
[root@member-crm-db crmm]# od   snapshot01.dbf  -N  8192            
0000000 001000 000000 020000 000000 000200 000002 056135 055133
0000020 000000 000000 022204 000000 000000 000000 000000 000000
0000040 000000 000000 000000 000000 000000 000000 000000 000000
*
0020000
[root@member-crm-db crmm]# od   snapshot02.dbf  -N  8192
0000000 001000 000000 020000 000000 000200 000002 056135 055133
0000020 000000 000000 022204 000000 000000 000000 000000 000000
0000040 000000 000000 000000 000000 000000 000000 000000 000000
*
0020000
[root@member-crm-db crmm]# od   member01.dbf  -N  8192              
0000000 001000 000000 020000 000000 000200 000002 056135 055133
0000020 000000 000000 022204 000000 000000 000000 000000 000000
0000040 000000 000000 000000 000000 000000 000000 000000 000000
*

xzh2000

你这样看不是很清楚.

[root@test esal]# od  temp.dbf -tc -N8192
0000000  \0 002  \0  \0  \0      \0  \0  \0   ?003  \0   ]   \   [   Z
0000020  \0  \0  \0  \0 005   ? \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000040  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0020000
[root@test esal]# od  klserver01.dbf -tc -N8192
0000000  \0 002  \0  \0  \0      \0  \0  \0   ? \0  \0   ]   \   [   Z
0000020  \0  \0  \0  \0 006   ? \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000040  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0020000
[root@test esal]# od  tools01.dbf -tc -N8192
0000000 002  \0  \0  \0  \0      \0  \0 200   1  \0  \0   ]   \   [   Z
0000020  \0  \0  \0  \0 204 027  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000040  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0020000
[root@test esal]# od perfstat.dbf -tc -N8192
0000000 002  \0  \0  \0  \0      \0  \0  \0  \0 002  \0   ]   \   [   Z
0000020  \0  \0  \0  \0 006   &  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000040  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0020000
[root@test esal]# od stat.dbf -tc -N8192
0000000 002  \0  \0  \0  \0      \0  \0 200   1  \0  \0   ]   \   [   Z
0000020  \0  \0  \0  \0 204 027  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000040  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0020000
[root@test esal]# uname -a
Linux test 2.4.21-15.EL #1 Sun May 16 02:07:24 EDT 2004 i686 i686 i386 GNU/Lin

piner

就算这样。。。
敢真做吗？呵呵。。。

zjxs

第一个块中包含了块的数量，所以不同大小文件的第一个块是不一样的

eygle

只要确认了，也没有什么。
可以考察一下10g 的RMAN是怎样实现的，应该是类似的方式。

4pal

不应该仅仅是rman得作用吧，要是oracle本身也做了一些修改，那再怎么把rman研究透，也还是不够得。

相同CPU架构的，还是有点希望的（10g之前）

rollingpig

最初由 biti_rainy 发布
[B]起源：

那对于相同 byte  order 的硬件平台来说，唯一可能不同的地方，就在于 os 中比 db 中看到的多一个 block部分可能不一样。


* [/B]

hehe
有没有各个硬件平台的byte  order 的资料？

比如说，那些硬件平台的byte  order是相同的？

biti_rainy

最初由 zjxs 发布
[B]第一个块中包含了块的数量，所以不同大小文件的第一个块是不一样的 [/B]

你所说的 第一个块是  oracle DB 中所看到的第一个 块，这在 os 上看来是第二个块。

biti_rainy

最初由 eygle 发布
[B]只要确认了，也没有什么。
可以考察一下10g 的RMAN是怎样实现的，应该是类似的方式。 [/B]

在 10G 中，transport  tablespace 的时候，如果是相同的 byte  order ，则数据不需要任何转换，oracle的描述是在 tablespace  read/write 的时候自动修改了 OS  file  header  block 。

biti_rainy

最初由 rollingpig 发布
[B]

hehe
有没有各个硬件平台的byte  order 的资料？

比如说，那些硬件平台的byte  order是相同的？ [/B]

在 oracle  10G 中有描述，可以在oracle中查询的

或者大家 google  Endianness ，可以得到相关信息

Default endian formats for certain computer platforms
Pure Big Endian: Sun SPARC, Motorola 68000
Bi-Endian, running in Big Endian mode: MIPS running IRIX, PA-RISC, most Power and PowerPC systems
Bi-Endian, running in Little Endian mode: MIPS running Ultrix, most DEC Alpha, IA-64 running Linux
Little Endian: Intel x86, AMD64, DEC VAX