[20161128]關於Little Enddian.txt

[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。