[20231019]rename IDL_UB1$的恢復測試前準備.txt
[20231019]rename IDL_UB1$的恢復測試前準備.txt
--//前幾天看了連結,對方rename IDL_UB1$表操作,導致無法建立表操作使用包的語句都有問題.
--//測試時遇到許多其他事情打斷了恢復工作，最後我僅僅簡單嘗試了修改資料字典obj$的恢復方式。
--//我當時的執行命令是rename IDL_UB1$ to IDL_UB1X;,我開始以為這樣恢復會很簡單，因為我改名的長度與原來一樣。
--//僅僅$ 換成 X。但我實際看到的情況不同，先為rename IDL_UB1$的恢復測試前做一些知識儲備。
1.環境：
SYS@book> @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
2.事前準備:
SYS@book> select rowid,owner#,name from obj$ where name='IDL_UB1$';
ROWID OWNER# NAME
------------------ ------ --------
AAAAASAABAAAADzAAX 0 IDL_UB1$
SYS@book> @ rowid AAAAASAABAAAADzAAX/
OBJECT FILE BLOCK ROW ROWID_DBA DBA TEXT
------ ---- ----- --- ---------- ------ ----------------------------------------
18 1 243 23 0x4000F3 1,243 alter system dump datafile 1 block 243 ;
$ strings -t d /mnt/ramdisk/book/system01.dbf | grep 'IDL_UB1\$'| awk '{print int($1/8192), " ",$1-int($1/8192)*8192, " " ,$2}'
243 6325 IDL_UB1$
351 5692 IDL_UB1$
375 5692 IDL_UB1$
17086 4802 IDL_UB1$
34025 5594 SELECT
34029 5278 COMMIT"SELECT
36154 5278 COMMIT"SELECT
95511 4482 IDL_UB1$l
--//注：顯示的第一個欄位對應塊號，第一個欄位對應相應資料塊的偏移.
--//主要關注或者講修改資料塊243,351,375,17086,95511.
--//看看這些塊屬於那個物件。
SYS@book> @ find_objz 1 243 '' 1
SYS@book> @ pr
==============================
FILE_ID : 1
BLOCK_ID : 240
BLOCKS : 8
SEGMENT_TYPE : TABLE
OWNER : SYS
SEGMENT_NAME : OBJ$
PARTITION_NAME :
EXTENT_ID : 0
BYTES : 65536
TABLESPACE_NAME : SYSTEM
RELATIVE_FNO : 1
SEGTSN : 0
SEGRFN : 1
SEGBID : 240
PL/SQL procedure successfully completed.
SYS@book> @ find_objz 1 351 '' 1
SYS@book> @ pr
==============================
FILE_ID : 1
BLOCK_ID : 344
BLOCKS : 8
SEGMENT_TYPE : INDEX
OWNER : SYS
SEGMENT_NAME : I_OBJ2
PARTITION_NAME :
EXTENT_ID : 0
BYTES : 65536
TABLESPACE_NAME : SYSTEM
RELATIVE_FNO : 1
SEGTSN : 0
SEGRFN : 1
SEGBID : 344
PL/SQL procedure successfully completed.
SYS@book> @ find_objz 1 375 '' 1
SYS@book> @ pr
==============================
FILE_ID : 1
BLOCK_ID : 368
BLOCKS : 8
SEGMENT_TYPE : INDEX
OWNER : SYS
SEGMENT_NAME : I_OBJ5
PARTITION_NAME :
EXTENT_ID : 0
BYTES : 65536
TABLESPACE_NAME : SYSTEM
RELATIVE_FNO : 1
SEGTSN : 0
SEGRFN : 1
SEGBID : 368
PL/SQL procedure successfully completed.
SYS@book> @ find_objz 1 17086 '' 1
SYS@book> @ pr
==============================
FILE_ID : 1
BLOCK_ID : 17024
BLOCKS : 128
SEGMENT_TYPE : CLUSTER
OWNER : SYS
SEGMENT_NAME : C_TOID_VERSION#
PARTITION_NAME :
EXTENT_ID : 18
BYTES : 1048576
TABLESPACE_NAME : SYSTEM
RELATIVE_FNO : 1
SEGTSN : 0
SEGRFN : 1
SEGBID : 3464
PL/SQL procedure successfully completed.
SYS@book> @ find_objz 1 95511 '' 1
SYS@book> @ pr
==============================
FILE_ID : 1
BLOCK_ID : 95488
BLOCKS : 128
SEGMENT_TYPE : CLUSTER
OWNER : SYS
SEGMENT_NAME : C_OBJ#_INTCOL#
PARTITION_NAME :
EXTENT_ID : 6
BYTES : 1048576
TABLESPACE_NAME : SYSTEM
RELATIVE_FNO : 1
SEGTSN : 0
SEGRFN : 1
SEGBID : 2688
PL/SQL procedure successfully completed.
--//dba= 1,95511 屬於物件C_OBJ#_INTCOL#是1個CLUSTER物件。
BBED> set width 200
WIDTH 200
BBED> p kdbt
struct kdbt[0], 4 bytes @106
sb2 kdbtoffs @106 0
sb2 kdbtnrow @108 1
struct kdbt[1], 4 bytes @110
sb2 kdbtoffs @110 1
sb2 kdbtnrow @112 207
--//C_OBJ#_INTCOL#下僅僅有1個表。
BBED> x /rnnnnc *kdbr[90]
rowdata[3800] @4459
-------------
flag@4459: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)
lock@4460: 0x02
cols@4461: 5
col 0[2] @4463: 7
col 1[1] @4466: 0
col 2[2] @4468: 19
col 3[9] @4471: 380422925370589000000000000000000000
col 4[8] @4481: IDL_UB1$
--//是cluster的第1個表.下一個字元0x6c,對應字元l.所以上面掃描看到IDL_UB1$l字串是正常的.
SELECT ROWNUM -1 rn , a.*
FROM ( SELECT *
FROM dba_objects
WHERE owner = 'SYS' AND data_object_id = 444
ORDER BY object_id) a;
RN OWNER OBJECT_NAME SUBOBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE CREATED LAST_DDL_TIME TIMESTAMP STATUS T G S NAMESPACE EDITION_NAME
---------- ------ -------------- -------------- ---------- -------------- ------------------- ------------------- ------------------- ------------------- ------- - - - ---------- ------------
0 SYS C_OBJ#_INTCOL# 444 444 CLUSTER 2013-08-24 11:37:43 2013-08-24 11:37:43 2013-08-24:11:37:43 VALID N N N 5
1 SYS HISTGRM$ 446 444 TABLE 2013-08-24 11:37:43 2013-08-24 11:37:43 2013-08-24:11:37:43 VALID N N N 1
2 rows selected.
--//HISTGRM$ 應該是直方圖相關的表
BBED> x /rnn *kdbr[0]
rowdata[7503] @8162
-------------
flag@8162: 0xac (KDRHFL, KDRHFF, KDRHFH, KDRHFK)
lock@8163: 0x00
cols@8164: 2
kref@8165: 181
mref@8167: 68
hrid@8169:0x00417518.0
nrid@8175:0x00417518.0
col 0[3] @8181: 6579
col 1[2] @8185: 7
SYS@book> select * from HISTGRM$ where obj#=6579 and intcol#=7 and col#=7 and row#=0 and bucket=19
2 @ pr
==============================
OBJ# : 6579
COL# : 7
ROW# : 0
BUCKET : 19
ENDPOINT : 380422925370589000000000000000000000
INTCOL# : 7
EPVALUE : IDL_UB1$
SPARE1 :
SPARE2 :
PL/SQL procedure successfully completed.
SYS@book> @ oid 6579
owner object_name object_type SUBOBJECT_NAME CREATED LAST_DDL_TIME status DATA_OBJECT_ID OBJECT_ID
----- ----------------- ------------------ -------------- ------------------- ------------------- --------- -------------- ----------
SYS WRH$_SEG_STAT_OBJ TABLE 2013-08-24 11:39:10 2013-08-24 11:39:10 VALID 6579 6579
1 row selected.
--//明顯這個不重要.
--//dba = 1,17086.屬於C_TOID_VERSION# cluster。
BBED> map dba 1,17086
File: /mnt/ramdisk/book/system01.dbf (1)
Block: 17086 Dba:0x004042be
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
struct ktbbh, 72 bytes @20
struct kdbh, 14 bytes @92
struct kdbt[3], 12 bytes @106
sb2 kdbr[3] @118
ub1 freespace[7842] @124
ub1 rowdata[222] @7966
ub4 tailchk @8188
-//offset =4802 在freespace 區間,不用修改.
SYS@book> @ ind2 obj$
Display indexes where table or index name matches obj$...
TABLE_OWNER TABLE_NAME INDEX_NAME POS# COLUMN_NAME DSC
----------- ---------- ---------- ---- ------------------------------ ----
SYS OBJ$ I_OBJ1 1 OBJ#
2 OWNER#
3 TYPE#
I_OBJ2 1 OWNER#
2 NAME
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 NAMESPACE
4 REMOTEOWNER
5 LINKNAME
6 SUBNAME
7 TYPE#
8 SPARE3
9 OBJ#
I_OBJ3 1 OID$
I_OBJ4 1 DATAOBJ#
2 TYPE#
3 OWNER#
I_OBJ5 1 SPARE3
2 NAME
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 NAMESPACE
4 TYPE#
5 OWNER#
6 REMOTEOWNER
7 LINKNAME
8 SUBNAME
9 OBJ#
INDEX_OWNER TABLE_NAME INDEX_NAME IDXTYPE UNIQ STATUS PART TEMP H LFBLKS NDK NUM_ROWS CLUF LAST_ANALYZED DEGREE VISIBILIT
----------- ---------- ---------- ---------- ---- -------- ---- ---- -- ---------- ------------- ---------- ---------- ------------------- ------ ---------
SYS OBJ$ I_OBJ1 NORMAL YES VALID NO N 2 250 87018 87018 1158 2023-08-30 22:00:13 1 VISIBLE
OBJ$ I_OBJ2 NORMAL YES VALID NO N 3 876 87018 87018 64485 2023-08-30 22:00:13 1 VISIBLE
OBJ$ I_OBJ3 NORMAL NO VALID NO N 2 16 3421 3421 249 2023-08-30 22:00:13 1 VISIBLE
OBJ$ I_OBJ4 NORMAL NO VALID NO N 2 383 9358 87018 3237 2023-08-30 22:00:13 1 VISIBLE
OBJ$ I_OBJ5 NORMAL YES VALID NO N 3 876 87018 87018 64473 2023-08-30 22:00:13 1 VISIBLE
--//I_OBJ2,I_OBJ5都是obj#的索引,裡面都包含name欄位,換一句話講如果使用bbed恢復.這3塊(243,351,375)都需要恢復.
--//oracle建立這兩個索引有點奇怪,都是包含相同欄位,僅僅順序有一些不同,並且都是 unique索引.
3.探究資料塊243,351,375的一些細節：
BBED> x /rnnncncntttnccnxnnncct dba 1,243 *kdbr[23]
rowdata[5215] @6311
-------------
flag@6311: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@6312: 0x00
cols@6313: 18
col 0[3] @6314: 225
col 1[3] @6318: 225
col 2[1] @6322: 0
col 3[8] @6324: IDL_UB1$
col 4[2] @6333: 1
col 5[0] @6336: *NULL*
col 6[2] @6337: 2
col 7[7] @6340: 2013-08-24 11:37:39
col 8[7] @6348: 2013-08-24 11:37:39
col 9[7] @6356: 2013-08-24 11:37:39
col 10[2] @6364: 1
col 11[0] @6367: *NULL*
col 12[0] @6368: *NULL*
col 13[1] @6369: 0
col 14[0] @6371: *NULL*
col 15[1] @6372: 0
col 16[2] @6374: 1
col 17[1] @6377: 0
--//dba=1,351 , 索引i_obj2
BBED> p dba 1,351 kd_off
sb2 kd_off[0] @124 8032
sb2 kd_off[1] @126 0
sb2 kd_off[2] @128 4078
sb2 kd_off[3] @130 4120
sb2 kd_off[4] @132 4172
sb2 kd_off[5] @134 4214
..
sb2 kd_off[36] @196 5589
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sb2 kd_off[37] @198 5623
sb2 kd_off[38] @200 5657
sb2 kd_off[39] @202 5697
sb2 kd_off[40] @204 5731
sb2 kd_off[41] @206 5771
sb2 kd_off[42] @208 5809
sb2 kd_off[43] @210 5842
...
sb2 kd_off[99] @322 7861
sb2 kd_off[100] @324 7911
sb2 kd_off[101] @326 7952
--//前面記錄的偏移是5692,BBED> p dba 1,351 kd_off輸出的相對偏移.
--//5692-92 = 5600,前面還有一些flag,lock標識,而且i_obj2是unique索引,記錄的rowid在前面佔6位元組.對應的應該是kd_off[36]指向的內容。
BBED> x /rncncccnnn dba 1,351 *kd_off[36]
rowdata[1679] @5681
-------------
flag@5681: 0x00 (NONE)
lock@5682: 0x00
keydata[6]: 0x00 0x40 0x00 0xf3 0x00 0x17
data key:
col 0[1] @5690: 0
col 1[8] @5692: IDL_UB1$
--//偏移等於5692，能對上。
col 2[2] @5701: 1
col 3[0] @5704: *NULL*
col 4[0] @5705: *NULL*
col 5[0] @5706: *NULL*
col 6[2] @5707: 2
col 7[1] @5710: 0
col 8[3] @5712: 225
--//dba=1,375 , 索引i_obj5,也是unique索引.方法類似.
BBED> x /rncnnnnccn dba 1,375 *kd_off[36]
rowdata[1679] @5681
-------------
flag@5681: 0x00 (NONE)
lock@5682: 0x00
keydata[6]: 0x00 0x40 0x00 0xf3 0x00 0x17
data key:
col 0[1] @5690: 0
col 1[8] @5692: IDL_UB1$
col 2[2] @5701: 1
col 3[2] @5704: 2
col 4[1] @5707: 0
col 5[0] @5709: *NULL*
col 6[0] @5710: *NULL*
col 7[0] @5711: *NULL*
col 8[3] @5712: 225
4.階段總結：
--//如果需要使用bbed做這裡rename恢復，僅僅需要修改這3塊。
--//概括一下:
x /rnnncncntttnccnxnnncct dba 1,243 *kdbr[23]
x /rncncccnnn dba 1,351 *kd_off[36]
x /rncnnnnccn dba 1,375 *kd_off[36]
--//內容有點多，使用bbed的恢復另外寫一篇blog。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2990584/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- [20231020]rename IDL_UB1$後使用bbed的恢復.txt
- [20231103]rename IDL_UB1$後使用bbed的恢復的後遺症.txt
- [20181031]truncate IDL_UB1$恢復.txt
- [20210803]刪除user$的恢復準備.txt
- 【手摸手玩轉 OceanBase 174】恢復前準備準備工作有哪些？
- RMAN備份與恢復測試
- 【PG備份恢復】pg_basebackup 多表空間備份恢復測試
- linux下的測試流程，釋出前要做哪些準備？Linux
- 【PG備份恢復】pg_dump命令測試
- 求職前準備，軟體測試的3項挑戰！求職
- SQLSERVER恢復測試SQLServer
- Oracle RMAN恢復測試Oracle
- 阿里面試官：知道 MySQL 邏輯備份與恢復測試麼？阿里面試MySql
- 面試前最應該做的準備工作面試
- Nginx 下SSL證書安裝/配置/測試/備份/恢復Nginx
- Django測試環境準備Django
- JB的測試之旅-測試資料的準備/構造
- RAC備份恢復之Voting備份與恢復
- postgreSQL 恢復至故障點 精準恢復SQL
- DOSBOX使用前的準備工作
- 學前準備工作
- apiAutoTest: 介面自動化測試的資料清洗(備份/恢復)處理方案API
- [20190428]恢復oraInventory.txtAI
- 備份與恢復：polardb資料庫備份與恢復資料庫
- MySQL備份與恢復——基於Xtrabackup物理備份恢復MySql
- GitLab的備份與恢復Gitlab
- DB的備份與恢復
- 全鏈路壓測(10)：測試要做的準備工作
- 備份和恢復
- oracle冷備恢復Oracle
- mydumper備份恢復
- Mysql備份恢復MySql
- QPM 準備優化前的思考優化
- [20180627]truncate table的另類恢復.txt
- MySQL 非常規恢復與物理備份恢復MySql
- Laravel 開發前準備Laravel
- 當一個測試工程師準備找工作，需要準備什麼？工程師
- 詳解叢集級備份恢復：物理細粒度備份恢復