Skip to Main Content
  • Questions
  • The Data columns in Data Block is not equal to the table columns after "alter table" operation

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Dong.

Asked: March 23, 2017 - 6:52 am UTC

Last updated: March 28, 2017 - 1:43 am UTC

Version: 11.2.0

Viewed 1000+ times

You Asked

Hi,Tom,

I found that the data cols in 'alter system dump datafile x block x' is not equal to the table's columns.
1)first,I create a table 'test6' with 2 columns 'c1' and 'c2',and insert 2 rows into it:
create table test6 (c1 varchar(10),c2 varchar(10));
insert into test6 values('zzz','xxxxxx');
insert into test6 values('zzz','xxxxxx');

2)And then,I alter the table to add a new column:
alter table test6 add(c3 varchar(10));
now,the table has 3 columns.

3)third,I dump the block which stores these rows:
ALTER SYSTEM dump datafile 5 block 172;
But,in the trace file,the data block has only 2 columns:
---------------------------------------------------------->
Start dump data blocks tsn: 5 file#:5 minblk 172 maxblk 172
Block dump from cache:
Dump of buffer cache at level 4 for tsn=5 rdba=20971692
BH (0x783e2cd8) file#: 5 rdba: 0x014000ac (5/172) class: 1 ba: 0x78152000
  set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,19
  dbwrid: 0 obj: 66395 objn: 66395 tsn: 5 afn: 5 hint: f
  hash: [0x8d51b310,0x8d51b310] lru: [0x783e2f00,0x783e2c90]
  ckptq: [NULL] fileq: [NULL] objq: [0x783e2f28,0x783e2cb8] objaq: [0x783e2f38,0x783e2cc8]
  st: XCURRENT md: NULL fpin: 'kdswh01: kdstgr' tch: 2
  flags: only_sequential_access
  LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
Block dump from disk:
buffer tsn: 5 rdba: 0x014000ac (5/172)
scn: 0x0000.000dce43 seq: 0x01 flg: 0x06 tail: 0xce430601
frmt: 0x02 chkval: 0x603d type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00007FBD4BA1CA00 to 0x00007FBD4BA1EA00
7FBD4BA1CA00 0000A206 014000AC 000DCE43 06010000  [......@.C.......]
7FBD4BA1CA10 0000603D 00000001 0001035B 000DCE40  [=`......[...@...]
7FBD4BA1CA20 00000000 00320002 014000A8 00110002  [......2...@.....]
7FBD4BA1CA30 00000231 00C002B4 00250048 00002002  [1.......H.%.. ..]
7FBD4BA1CA40 000DCE43 00000000 00000000 00000000  [C...............]
7FBD4BA1CA50 00000000 00000000 00000000 00000000  [................]
7FBD4BA1CA60 00000000 00020100 0016FFFF 1F661F7C  [............|.f.]
7FBD4BA1CA70 00001F66 1F8A0002 00001F7C 00000000  [f.......|.......]
7FBD4BA1CA80 00000000 00000000 00000000 00000000  [................]
        Repeat 501 times
7FBD4BA1E9E0 0302012C 067A7A7A 78787878 012C7878  [,...zzz.xxxxxx,.]
7FBD4BA1E9F0 7A7A0302 7878067A 78787878 CE430601  [..zzz.xxxxxx..C.]
Block header dump:  0x014000ac
 Object id on Block? Y
 seg/obj: 0x1035b  csc: 0x00.dce40  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x14000a8 ver: 0x01 opc: 0
     inc: 0  exflg: 0

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0002.011.00000231  0x00c002b4.0048.25  --U-    2  fsc 0x0000.000dce43
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
bdba: 0x014000ac
data_block_dump,data header at 0x7fbd4ba1ca64
===============
tsiz: 0x1f98
hsiz: 0x16
pbl: 0x7fbd4ba1ca64
     76543210
flag=--------
ntab=1
nrow=2
frre=-1
fsbo=0x16
fseo=0x1f7c
avsp=0x1f66
tosp=0x1f66
0xe:pti[0]      nrow=2  offs=0
0x12:pri[0]     offs=0x1f8a
0x14:pri[1]     offs=0x1f7c
block_row_dump:
tab 0, row 0, @0x1f8a
tl: 14 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 3]  7a 7a 7a
col  1: [ 6]  78 78 78 78 78 78
tab 0, row 1, @0x1f7c
tl: 14 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 3]  7a 7a 7a
col  1: [ 6]  78 78 78 78 78 78
end_of_block_dump
End dump data blocks tsn: 5 file#: 5 minblk 172 maxblk 172


So,my question is:
1)Why the block has only 2 columns after 'alter table' operation? Why this happen?
2)How database return the query result with 3 columns based on a 2 columns's data block?
3)Is there any place to record the table version to satisfied the correctly transform from data block's binary data to query-result's ASCII data?

and Connor said...

Answer - Because why do work if you dont have to ?

When we do "alter table T add NEW_COL int", then if T had a 1billion rows, and we went back and stamped every blocks with "Hey...you have a new column", then it would take forever. We dont *need* to do it, because the block contents and the table definition are enough to work out it.

If my table has three columns, and my block has 2 columns of data...I know that the third column is null. In later versions we even some smarter things where if the new column has a default value, we 'know' this, and can 'slide' that into the data read from the block at runtime rather than updating all the existing blocks.

Sorry, I dont understand what you're asking in (3)

Is this answer out of date? If it is, please let us know via a Comment