[20161128]关于Little Enddian.txt-CSDN博客

[20161128]关于Little Enddian.txt

Intel字节顺序称为"Little-Endian"，反之Sun，还有网络上采用标准是"Big-Endian"。在将应用程序从一种架构类型迁移至另一种架构
类型的过程中，经常会遇到字节排列顺序(endianness)问题。字节排列顺序是数据元素及其单个字节在内存中存储和表示时的顺序。

我个人简单的理解就是低字节在前，高字节在后。我自己做一些探究，主要想了解数据块在内存的存储情况。

1.环境：
SCOTT@book> @ &r/ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SYS@book> select PLATFORM_ID,PLATFORM_NAME from v$database;
PLATFORM_ID PLATFORM_NAME
----------- -------------------------------------------------
13 Linux x86 64-bit

--//我使用intel的服务器。

2.测试：
SCOTT@book> select rowid,dept.* from dept;
ROWID                  DEPTNO DNAME          LOC
------------------ ---------- -------------- -------------
AAAVRCAAEAAAACHAAA         10 ACCOUNTING     NEW YORK
AAAVRCAAEAAAACHAAB         20 RESEARCH       DALLAS
AAAVRCAAEAAAACHAAC         30 SALES          CHICAGO
AAAVRCAAEAAAACHAAD         40 OPERATIONS     BOSTON

SCOTT@book> @ &r/rowid AAAVRCAAEAAAACHAAA
OBJECT FILE BLOCK ROW ROWID_DBA DBA TEXT
---------- ---------- ---------- ---------- -------------------- ------ ----------------------------------------
87106 4 135 0 0x1000087 4,135 alter system dump datafile 4 block 135 ;

SYS@book> @ &r/bh 4 135
HLADDR DBARFIL DBABLK CLASS CLASS_TYPE STATE TCH CR_SCN_BAS CR_SCN_WRP CR_UBA_FIL CR_UBA_BLK CR_UBA_SEQ BA OBJECT_NAME
---------------- ---------- ---------- ---------- ------------------ ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- ------------
0000000084A57EF0 4 135 1 data block xcur 2 0 0 0 0 0 0000000073A3C000 DEPT

--//可以知道BA的地址是0000000073A3C000。

3.转储分析：

SCOTT@book> alter system dump datafile 4 block 135 ;
System altered.

Dump of memory from 0x00007F4B6A4F3A00 to 0x00007F4B6A4F5A00
7F4B6A4F3A00 0000A206 01000087 000E0EF0 06010000 [................]
7F4B6A4F3A10 0000E273 00160001 00015442 000E0EE4 [s.......BT......]
7F4B6A4F3A20 1FE80000 00321F02 01000080 00020009 [......2.........]
...
7F4B6A4F59A0 0203012C 4F0A29C1 41524550 4E4F4954 [,....).OPERATION]
7F4B6A4F59B0 4F420653 4E4F5453 0203012C 53051FC1 [S.BOSTON,......S]
7F4B6A4F59C0 53454C41 49484307 4F474143 0203012C [ALES.CHICAGO,...]
7F4B6A4F59D0 520815C1 41455345 06484352 4C4C4144 [...RESEARCH.DALL]
7F4B6A4F59E0 012C5341 0BC10203 4343410A 544E554F [AS,......ACCOUNT]
7F4B6A4F59F0 08474E49 2057454E 4B524F59 0EF00601 [ING.NEW YORK....]

SYS@book> oradebug setmypid
Statement processed.
SYS@book> oradebug peek 0x0000000073A3C000 16
[073A3C000, 073A3C010) = 0000A206 01000087 000E0EF0 06010000
SYS@book> oradebug peek 0x0000000073A3C010 16
[073A3C010, 073A3C020) = 0000E273 00160001 00015442 000E0EE4
SYS@book> oradebug peek 0x0000000073A3C020 16
[073A3C020, 073A3C030) = 1FE80000 00321F02 01000080 00020009

--再看看最后16个字节。
--8192-16=8176
--8176 = 0x1ff0
SYS@book> oradebug peek 0x0000000073A3DFF0 16
[073A3DFF0, 073A3E000) = 08474E49 2057454E 4B524F59 0EF00601

--//对比着看可以发现2者一致，但是如果你仔细看Dump of memory的后面显示的字符串。
--//以 7F4B6A4F59F0 08474E49 2057454E 4B524F59 0EF00601 [ING.NEW YORK....]为例说明：

可以发现后面显示的字符串 ascii码 0x08 肯定不是I ，而是4个字节反转的显示字符串的。

SCOTT@book> @ &r/16to10 47
16 to 10 DEC
------------
71

SCOTT@book> select chr(71) from dual ;
C
-
G

--第2个字符显示的是G。 0x49 才是'I'.

4.使用bbed观察对比就很容易明白：
BBED> dump /v dba 4,135 count 16 offset 8176
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 135 Offsets: 8176 to 8191 Dba:0x01000087
-----------------------------------------------------------------------------------------------------------
494e4708 4e455720 594f524b 0106f00e l ING.NEW YORK....
<32 bytes per line>

--对比[073A3DFF0, 073A3E000) = 08474E49 2057454E 4B524F59 0EF00601，正好4个字节倒过来。

BBED> dump /v dba 4,135 count 16 offset 0
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 135 Offsets: 0 to 15 Dba:0x01000087
-----------------------------------------------------------------------------------------------------------
06a20000 87000001 f00e0e00 00000106 l ................
<32 bytes per line>

BBED> dump /v dba 4,135 count 16 offset 16
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 135 Offsets: 16 to 31 Dba:0x01000087
-----------------------------------------------------------------------------------------------------------
73e20000 01001600 42540100 e40e0e00 l s.......BT......
<32 bytes per line>

BBED> dump /v dba 4,135 count 16 offset 32
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 135 Offsets: 32 to 47 Dba:0x01000087
-----------------------------------------------------------------------------------------------------------
0000e81f 021f3200 80000001 09000200 l ......2.........
<32 bytes per line>

--对比上面的转储以及内存的转储，就可以发现就是4个字节反转显示的。

--//Big-Endian 没有机器探究，估计是保存一致的。研究这个没有什么意思，是想到另外的问题，有时候服务器异常，
--//oracle会转储内存或者磁盘的数据块信息，通过这个是否还原原来的数据块，再写篇幅有点长，另外写一篇blog。