목차
DUMP数据块的信息解读
使用BBED查看数据块,与上一步DUMP信息进行对应
데이터 베이스 MySQL 튜토리얼 ORACLE空间管理实验8:数据块格式分析

ORACLE空间管理实验8:数据块格式分析

Jun 07, 2016 pm 03:50 PM
du oracle 사용 분석하다 실험 데이터 체재 공간 관리하다

使用DUMP 数据块式结合BBED进行查看。 #################### 实验准备步骤 : BYS@ bys3create table test6(aa int,bb varchar2(10)); Table created. BYS@ bys3insert into test6 values(89,'bys'); 1 row created. BYS@ bys3insert into test6 values(69,'h

使用DUMP 数据块格式结合BBED进行查看。
####################实验准备步骤
BYS@ bys3>create table test6(aa int,bb varchar2(10));
Table created.
BYS@ bys3>insert into test6 values(89,'bys');
1 row created.
BYS@ bys3>insert into test6 values(69,'hello');
1 row created.
BYS@ bys3>commit;
Commit complete.
BYS@ bys3>alter system checkpoint;
System altered.
BYS@ bys3>select dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block#,aa,bb from test6;
     FILE#     BLOCK#         AA BB
---------- ---------- ---------- ----------
         4        477         89 bys
         4        477         69 hello
BYS@ bys3>alter system dump datafile 4 block 477;
System altered.
BYS@ bys3>select value from v$diag_info where name like 'De%';
VALUE
----------------------------------------------------------------------------------------------------

/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_8109.trc

DUMP数据块的信息解读

Start dump data blocks tsn: 4 file#:4 minblk 477 maxblk 477
Block dump from cache:  --这段信息来自buffer cache,详见: 详解Buffer Header--DUMP buffer结合X$BH视图各字段
Dump of buffer cache at level 4 for tsn=4 rdba=16777693
BH (0x22be4e74) file#: 4 rdba: 0x010001dd (4/477) class: 1 ba: 0x2286e000
  set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: 23326 objn: 23326 tsn: 4 afn: 4 hint: f
  hash: [0x227e6b54,0x2a7f74ac] lru: [0x217ee3d4,0x20ff4e64]
  ckptq: [NULL] fileq: [NULL] objq: [0x217ee3ec,0x20ff4e7c] objaq: [0x217ee3f4,0x20ff4e84]
  st: XCURRENT md: NULL fpin: 'ktspbwh2: ktspfmdb' tch: 3
  flags: block_written_once redo_since_read
  LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [1]
  ###########################################数据块头部分
Block dump from disk:   --下面的信息才是来自数据文件中的块。
buffer tsn: 4 rdba: 0x010001dd (4/477)  --数据块中4-8字节是RDBA--下面BBED部分可以看到
scn: 0x0000.00874dbb seq: 0x01 flg: 0x06 tail: 0x4dbb0601
frmt: 0x02 chkval: 0xeb56 type: 0x06=trans data   --第四个字节对应
---flg:0x01 (新建块)0x2(数据块延迟清洗推进scn和seq) 0X04(设置校验和) 0x08(临时块)     type:0x06(表/索引块)
--frmt:  0x01(v7)  0x02(v8)   --与第三字节A2对应,表示8I以上版本

Hex dump of block: st=0, typ_found=1
Dump of memory from 0xB68A9200 to 0xB68AB200
B68A9200 0000A206 010001DD 00874DBB 06010000  [.........M......]   ---这一行的信息可以与块头中的SCN TYPE之类对应的。
B68A9210 0000EB56 00130001 00005B1E 00874DB6  [V........[...M..]
B68A9220 1FE80000 00321F02 010001D8 001A0002  [......2.........]
B68A9230 00001382 00C00B70 00070569 00002002  [....p...i.... ..]
………………………………
B68AB1D0 54415453 4D5F5355 454B5241 71780752  [STATUS_MARKER.xq]
B68AB1E0 2618100B 012C021E 46C10202 6C656805  [...&..,....F.hel]
B68AB1F0 012C6F6C 5AC10202 73796203 4DBB0601  [lo,....Z.bys...M]
##########################################下面是ITL
Block header dump:  0x010001dd
 Object id on Block? Y
 seg/obj: 0x5b1e  csc: 0x00.874db6  itc: 2  flg: E  typ: 1 - DATA      --数据类型是DATA。  
 -- seg/obj: 0x5b1e--对应的是dba_objects.data_object_id,未TRUNCATE操作过的表data_object_id与object_id相等。格式化也就是在块上写入这个seg/obj:
--csc: 0x00.874db6 延迟块清除时的SCN--查询时、第三次提交时--三个ITL会做延迟块清除
--flg: E   --指用的是ASSM,如果是O表示用的是free list
--typ: 1 - DATA 事务型的数据块(并且:数据块头的type:0x06),存放表和索引数据。

     brn: 0  bdba: 0x10001d8 ver: 0x01 opc: 0     
     inc: 0  exflg: 0
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0002.01a.00001382  0x00c00b70.0569.07  --U-    2  fsc 0x0000.00874dbb
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
--11G默认用快速提交,Flag是U,正常提交是C。
--Itl: ITL事务槽号的流水编号
--Xid:transac[X]tion identified(事务ID),由und的段号+undo的槽号+undo槽号的覆盖次数三部分组成
--Uba:undo block address记录了最近一次的该记录的前镜像(修改前的值)
--Flag:C是提交,U是快速提交,---是未提交(Flg C=Committed  U=Commit Upper Bound T=Active at CSC)
--Lck:锁住了几行数据,对应有几个行锁
--Scn/Fsc:Scn=SCN of commited TX; Fsc=Free space credit(bytes)
--这里fsc 0x0000.00874dbb是指提交的scn,这个值大于上次清除块时的scn=csc: 0x00.874db6(此scn是这个块中最小的SCN of commited)
--SCN WRAP:如果事务已提交并完成清洗,该字段保存事务提交SCN的SCN WRAP部分,否则该字段保存空闲预支字节数(FSC).比如删除了一行数据10个字节,在事务提前前,这10个字节就属于fsc(即会写到SCN WRAP),只有事务提交后,才能正式返回到空闲空间。


#################################################用户数据头
bdba: 0x010001dd  --当前数据块的DBA
data_block_dump,data header at 0xb68a9264
===============
tsiz: 0x1f98  块的total总可用空间 1f98--8088字节
hsiz: 0x16  --数据头部占的字节数-不固定

pbl: 0xb68a9264
     76543210
flag=--------
ntab=1              --数据块属于一个表, cluster表时不是1
nrow=2             --行数
frre=-1               --The first free row entry in the row directory 要加1
fsbo=0x16        --Free space begin offset  叫起始空间:可以存放数据空间的起始位置(即定义了数据层中空闲空间的起始offset)
fseo=0x1f82     -- Free space end offset  叫结束空间:可以存放数据空间的结束位置(即定义了数据层中空闲空间的结束offset)插入数据从此处开始--从后往前用
avsp=0x1f6c    -- --Available space for new entries  叫空闲空间:定义了数据层中空闲空间的字节数
tosp=0x1f6c     -- --Total space   叫最终空闲空间:定义了ITL中事务提交后,数据层中空闲空间的字节数
0xe:pti[0]      nrow=2  offs=0   --Table directory,整个表的开始,共2行数据 ,定义了该表在行索引中使用的插槽数
0x12:pri[0]     offs=0x1f8e   -Row index,叫行索引,定义了该块中包含的所有行数据的位置

0x14:pri[1]     offs=0x1f82

#######################################用户数据

block_row_dump:
tab 0, row 0, @0x1f8e  --1个表,第1行,@0x1f8e该表在行索引中的起始插槽号 8078
tl: 10 fb: --H-FL-- lb: 0x1  cc: 2
--fb: (Flag byte)--H-FL指H(Head piece of row)F(First data piece) L(Last data piece)
--lb: 0x1 --Lock byte和上面的ITL的lck相对应,表示这行是否被lock了
col  0: [ 2]  c1 5a   --第一行的第一列,有两个字符
col  1: [ 3]  62 79 73 --第一行的第二列,有三个字符

tab 0, row 1, @0x1f82        ----------使用这个转换为十进制在BBED以此为偏移量来查看,需要加100(ORACEL预留100字节)
tl: 12 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 2]  c1 46
col  1: [ 5]  68 65 6c 6c 6f
end_of_block_dump
End dump data blocks tsn: 4 file#: 4 minblk 477 maxblk 477
最后四字节tail: 0xa3eb0601=scnBASE+flg+seq,如果不相等会报块损坏
###################

使用BBED查看数据块,与上一步DUMP信息进行对应

要节约篇幅哈哈,BBED中只讲与DUMP中的对应及一些重要字段的意义,不太重要的就要在上一步的DUMP中看了。
##########################
BBED> set file 4 block 477
        FILE#           4
        BLOCK#          477
BBED> dump
 File: /u01/oradata/bys3/user01.dbf (4)
 Block: 477              Offsets:    0 to  511           Dba:0x010001dd
------------------------------------------------------------------------
 06a20000 dd010001 bb4d8700 00000106 56eb0000 01001300 1e5b0000 b64d8700
 从BBED的第一行信息,因为大小端的问题,这里要两位两位倒着看。
 16进制中两个字符表示1bytes,所以要以2个16进制字符为单位(1byte)来进行转换:
 前面的个字节是:0000 a206  0100 01dd,可以看到和DUMP数据块中第一行前8个字节是一样的,

#####
BBED> map
 File: /u01/oradata/bys3/user01.dbf (4)
 Block: 477                                   Dba:0x010001dd
------------------------------------------------------------
 KTB Data Block (Table/Cluster)
 struct kcbh, 20 bytes                      @0      
 struct ktbbh, 72 bytes                     @20     
 struct kdbh, 14 bytes                      @100    
 struct kdbt[1], 4 bytes                    @114    
 sb2 kdbr[2]                                @118    
 ub1 freespace[8044]                        @122    
 ub1 rowdata[22]                            @8166   
 ub4 tailchk                                @8188 

##############################3
BBED> print kcbh   ---这里面信息全部可以与DUMP中的对应上。对应图中 cache layer层
struct kcbh, 20 bytes                       @0       
   ub1 type_kcbh                            @0        0x06  --块类型。。。。ub4--代表:unsign bytes 4--是字节数
   ub1 frmt_kcbh                            @1        0xa2  --版本8I以上
   ub1 spare1_kcbh                          @2        0x00  
   ub1 spare2_kcbh                          @3        0x00
   ub4 rdba_kcbh                            @4        0x010001dd -DBA
   ub4 bas_kcbh                             @8        0x00874dbb -SCN低位
   ub2 wrp_kcbh                             @12       0x0000     -SCN高位
   ub1 seq_kcbh                             @14       0x01    --序号
   ub1 flg_kcbh                             @15       0x06 (KCBHFDLC, KCBHFCKV)
   ub2 chkval_kcbh                          @16       0xeb56  --DUMP中chkval
   ub2 spare3_kcbh                          @18       0x0000


BBED> print ktbbh    ---与ITL 事务信息对应
struct ktbbh, 72 bytes          @20      
   ub1 ktbbhtyp                 @20       0x01 (KDDBTDATA)  --块类型
   union ktbbhsid, 4 bytes      @24         ---seg/obj:0x5b1e
      ub4 ktbbhsg1              @24       0x00005b1e
      ub4 ktbbhod1              @24       0x00005b1e
   struct ktbbhcsc, 8 bytes     @28        --csc: 0x00.874db6
      ub4 kscnbas               @28       0x00874db6
      ub2 kscnwrp               @32       0x0000
   sb2 ktbbhict                 @36       7938  --itc: 2我这里没对上
   ub1 ktbbhflg                 @38       0x32 (NONE) --flg: E
   ub1 ktbbhfsl                 @39       0x00
   ub4 ktbbhfnx                 @40       0x010001d8 --bdba:
   struct ktbbhitl[0], 24 bytes @44 --对应事务编号Xid:0x0002.01a.00001382   
      struct ktbitxid, 8 bytes  @44      
         ub2 kxidusn            @44       0x0002 -usn undo segment number
         ub2 kxidslt            @46       0x001a  --事务表第几行
         ub4 kxidsqn            @48       0x00001382 --行被重用次数
      struct ktbituba, 8 bytes  @52  --对应事务UBA 0x00c00b70.0569.07    
         ub4 kubadba            @52       0x00c00b70 --UNDO DBA
         ub2 kubaseq            @56       0x0569  --
         ub1 kubarec            @58       0x07
      ub2 ktbitflg              @60       0x2002 (KTBFUPB)
      union _ktbitun, 2 bytes   @62      
         sb2 _ktbitfsc          @62       0
         ub2 _ktbitwrp          @62       0x0000
      ub4 ktbitbas              @64       0x00874dbb
   struct ktbbhitl[1], 24 bytes @68      
      struct ktbitxid, 8 bytes  @68      
         ub2 kxidusn            @68       0x0000
         ub2 kxidslt            @70       0x0000
         ub4 kxidsqn            @72       0x00000000
      struct ktbituba, 8 bytes  @76      
         ub4 kubadba            @76       0x00000000
         ub2 kubaseq            @80       0x0000
         ub1 kubarec            @82       0x00
      ub2 ktbitflg              @84       0x0000 (NONE)
      union _ktbitun, 2 bytes   @86      
         sb2 _ktbitfsc          @86       0
         ub2 _ktbitwrp          @86       0x0000
      ub4 ktbitbas              @88       0x00000000

BBED> print kdbh  --对应的用户数据头
struct kdbh, 14 bytes     @100     
   ub1 kdbhflag           @100      0x00 (NONE)
   sb1 kdbhntab           @101      1  --对应DUMP中:ntab=1
   sb2 kdbhnrow           @102      2 --对应DUMP中:nrow=2
   sb2 kdbhfrre           @104     -1 --对应DUMP中:frre=-1
   sb2 kdbhfsbo           @106      22 --对应DUMP中:fsbo=0x16
   sb2 kdbhfseo           @108      8066 --对应DUMP中:fseo=0x1f82 插数据从此处开始
   sb2 kdbhavsp           @110      8044 --对应DUMP中avsp=0x1f6c
   sb2 kdbhtosp           @112      8044 --对应DUMP中tosp=0x1f6c
   
BBED> print kdbr  --对应的行索引信息
sb2 kdbr[0]    @118      8078  --对应DUMP中0x12:pri[0]     offs=0x1f8e
sb2 kdbr[1]    @120      8066  --对应DUMP中0x14:pri[1]     offs=0x1f82
##########
BBED> dump offset 8166  --这里DUMP出来的是行中的具体信息  第一行8078 第二行 8066 加100,从8166开始DUMP
 File: /u01/oradata/bys3/user01.dbf (4)
 Block: 477              Offsets: 8166 to 8191           Dba:0x010001dd
------------------------------------------------------------------------
 2c010202 c1460568 656c6c6f 2c010202 c15a0362 79730106 bb4d
02 c15a 03  62 7973  对应的第一行的值:  03是三个字节,
col  0: [ 2]  c1 5a
col  1: [ 3]  62 79 73

02 c14605  68 656c6c6f对应第二行的值:05是五个字节
col  0: [ 2]  c1 46
col  1: [ 5]  68 65 6c 6c 6f

BBED> print tailchk    --与DUMP中数据块最后四个字节对应4DBB0601,是数据块的校验值。
ub4 tailchk          @8188     0x4dbb0601




본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

AI Hentai Generator

AI Hentai Generator

AI Hentai를 무료로 생성하십시오.

인기 기사

R.E.P.O. 에너지 결정과 그들이하는 일 (노란색 크리스탈)
3 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 최고의 그래픽 설정
3 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 아무도들을 수없는 경우 오디오를 수정하는 방법
3 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌

뜨거운 도구

메모장++7.3.1

메모장++7.3.1

사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전

SublimeText3 중국어 버전

중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기

스튜디오 13.0.1 보내기

강력한 PHP 통합 개발 환경

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

SublimeText3 Mac 버전

SublimeText3 Mac 버전

신 수준의 코드 편집 소프트웨어(SublimeText3)

Oracle 데이터베이스 로그는 얼마나 오래 보관됩니까? Oracle 데이터베이스 로그는 얼마나 오래 보관됩니까? May 10, 2024 am 03:27 AM

Oracle 데이터베이스 로그의 보존 기간은 다음을 포함한 로그 유형 및 구성에 따라 다릅니다. 재실행 로그: "LOG_ARCHIVE_DEST" 매개변수로 구성된 최대 크기에 의해 결정됩니다. 보관된 리두 로그: "DB_RECOVERY_FILE_DEST_SIZE" 매개변수로 구성된 최대 크기에 따라 결정됩니다. 온라인 리두 로그: 보관되지 않고 데이터베이스를 다시 시작하면 손실되며 보존 기간은 인스턴스 실행 시간과 일치합니다. 감사 로그: "AUDIT_TRAIL" 매개변수로 구성되며 기본적으로 30일 동안 보관됩니다.

Oracle 데이터베이스 시작 단계의 순서는 다음과 같습니다. Oracle 데이터베이스 시작 단계의 순서는 다음과 같습니다. May 10, 2024 am 01:48 AM

Oracle 데이터베이스 시작 순서는 다음과 같습니다. 1. 전제 조건을 확인합니다. 3. 데이터베이스 인스턴스를 시작합니다. 5. 데이터베이스에 연결합니다. . 서비스를 활성화합니다(필요한 경우). 8. 연결을 테스트합니다.

오라클에는 얼마나 많은 메모리가 필요합니까? 오라클에는 얼마나 많은 메모리가 필요합니까? May 10, 2024 am 04:12 AM

Oracle에 필요한 메모리 양은 데이터베이스 크기, 활동 수준 및 필요한 성능 수준(데이터 버퍼 저장, 인덱스 버퍼, SQL 문 실행 및 데이터 사전 캐시 관리에 필요)에 따라 다릅니다. 정확한 양은 데이터베이스 크기, 활동 수준 및 필요한 성능 수준에 따라 달라집니다. 모범 사례에는 적절한 SGA 크기 설정, SGA 구성 요소 크기 조정, AMM 사용 및 메모리 사용량 모니터링이 포함됩니다.

Oracle에서 특정 문자의 발생 횟수를 확인하는 방법 Oracle에서 특정 문자의 발생 횟수를 확인하는 방법 May 09, 2024 pm 09:33 PM

Oracle에서 문자 발생 횟수를 찾으려면 다음 단계를 수행하십시오. 문자열의 전체 길이를 얻습니다. 문자가 나타나는 부분 문자열의 길이를 얻습니다. 부분 문자열 길이를 빼서 문자 발생 횟수를 계산합니다. 전체 길이에서.

Oracle 데이터베이스 서버 하드웨어 구성 요구 사항 Oracle 데이터베이스 서버 하드웨어 구성 요구 사항 May 10, 2024 am 04:00 AM

Oracle 데이터베이스 서버 하드웨어 구성 요구 사항: 프로세서: 기본 주파수가 2.5GHz 이상인 멀티 코어, 대규모 데이터베이스의 경우 32개 이상의 코어가 권장됩니다. 메모리: 소규모 데이터베이스의 경우 최소 8GB, 중간 크기의 경우 16~64GB, 대규모 데이터베이스 또는 과도한 작업 부하의 경우 최대 512GB 이상. 스토리지: SSD 또는 NVMe 디스크, 중복성 및 성능을 위한 RAID 어레이. 네트워크: 고속 네트워크(10GbE 이상), 전용 네트워크 카드, 지연 시간이 짧은 네트워크. 기타: 안정적인 전원 공급 장치, 이중 구성 요소, 호환 가능한 운영 체제 및 소프트웨어, 열 방출 및 냉각 시스템.

AI 스타트업들이 집단적으로 OpenAI로 직무를 전환했고, Ilya가 떠난 후 보안팀이 재편성되었습니다! AI 스타트업들이 집단적으로 OpenAI로 직무를 전환했고, Ilya가 떠난 후 보안팀이 재편성되었습니다! Jun 08, 2024 pm 01:00 PM

지난주 내부 사퇴와 외부 비판의 물결 속에서 OpenAI는 대내외적 난관에 봉착했다. - 미망인 여동생의 침해로 글로벌 열띤 논의가 촉발됐다. - '대군주 조항'에 서명한 직원들이 잇달아 폭로됐다. - 네티즌들은 울트라맨의 '' 일곱 가지 대죄" ” 소문 파기: Vox가 입수한 유출된 정보와 문서에 따르면 Altman을 포함한 OpenAI의 고위 경영진은 이러한 지분 회수 조항을 잘 알고 있었고 이에 서명했습니다. 또한 OpenAI가 직면한 심각하고 시급한 문제인 AI 보안이 있습니다. 최근 가장 눈에 띄는 직원 2명을 포함해 보안 관련 직원 5명이 퇴사하고, '슈퍼얼라인먼트' 팀이 해체되면서 OpenAI의 보안 문제가 다시 한 번 주목을 받고 있다. 포춘지는 OpenA가

오라클에서 dbf 파일을 읽는 방법 오라클에서 dbf 파일을 읽는 방법 May 10, 2024 am 01:27 AM

Oracle은 다음 단계를 통해 dbf 파일을 읽을 수 있습니다. 외부 테이블을 만들고 dbf 파일을 참조하여 데이터를 Oracle 테이블로 가져옵니다.

70B 모델은 몇 초 안에 1,000개의 토큰을 생성하고 코드 재작성은 OpenAI가 투자한 코드 아티팩트인 Cursor 팀의 GPT-4o를 능가합니다. 70B 모델은 몇 초 안에 1,000개의 토큰을 생성하고 코드 재작성은 OpenAI가 투자한 코드 아티팩트인 Cursor 팀의 GPT-4o를 능가합니다. Jun 13, 2024 pm 03:47 PM

70B 모델에서는 1000개의 토큰을 몇 초 만에 생성할 수 있으며 이는 거의 4000자로 변환됩니다! 연구진은 Llama3를 미세 조정하고 가속 알고리즘을 도입하여 기본 버전과 비교하여 속도가 13배 빨라졌습니다. 속도가 빠를 뿐만 아니라 코드 재작성 작업 성능도 GPT-4o를 능가합니다. 이 성과는 인기 있는 AI 프로그래밍 아티팩트인 Cursor를 개발한 팀과 OpenAI도 투자에 참여한 anysphere에서 이루어졌습니다. 빠른 추론 가속 프레임워크로 잘 알려진 Groq에서는 70BLlama3의 추론 속도가 초당 300개 토큰이 조금 넘는다는 사실을 아셔야 합니다. Cursor의 속도 덕분에 거의 즉각적인 완전한 코드 파일 편집이 가능하다고 할 수 있습니다. 어떤 사람들은 좋은 사람이라고 커스를 넣으면

See all articles