[20231103]rename IDL_UB1$后使用bbed的恢复的后遗症.txt

这篇具有很好参考价值的文章主要介绍了[20231103]rename IDL_UB1$后使用bbed的恢复的后遗症.txt。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

[20231103]rename IDL_UB1$后使用bbed的恢复的后遗症.txt

--//前段时间遇到的问题,测试使用rename IDL_UB1$后使用bbed的恢复,当时没有发现这个问题,今天才意识到问题.
--//我只能继续前面的恢复操作.

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.问题提出:
--//我本来想再尝试rename修改后长度不一致的情况,发现问题.

SYS@book> rename IDL_UB1$ to IDL_UB1Y_BAK;
rename IDL_UB1$ to IDL_UB1Y_BAK
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [13011], [18], [4280486], [6], [4280486], [17], [], [], [], [], [], []
--//4280486 = set dba 1,86182 = alter system dump datafile 1 block 86182 = 0x4150a6,正好是当时insert obj$的块号.

--//很明显索引不一致.当时我犯了一个小错误,我仅仅analyze table IDL_UB1$,分析对象错了.
SYS@book> analyze table IDL_UB1$ validate structure cascade;
Table analyzed.

--//实际上应该分析obj$表.
SYS@book> analyze table obj$ validate structure cascade;
analyze table obj$ validate structure cascade
*
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file

--//检查跟踪文件发现如下:
row not found in index tsn: 0 rdba: 0x00400168
env [0x7fff55680a40]: (scn: 0x0003.1775a1d0  xid: 0x007b.020.00000008  uba: 0x00000000.0000.00  statement num=0  parent
xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0003.1775a11a  flg: 0x00000060)
col 0; len 3; (3):  c2 03 1a
col 1; len 2; (2):  c1 03
col 2; len 1; (1):  80
col 3; len 6; (6):  00 40 00 f3 00 17
Block header dump:  0x004000f3
 Object id on Block? Y
 seg/obj: 0x12  csc: 0x03.176048bd  itc: 1  flg: -  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000a.008.00004d7f  0x00c03342.0f06.13  --U-    1  fsc 0x0000.176048c2

--//0x00400168 = set dba 1,360 = alter system dump datafile 1 block 360 = 4194664

SYS@book> @ find_objz 1 360  '' 1
SYS@book> @ pr
==============================
FILE_ID          : 1
BLOCK_ID         : 360
BLOCKS           : 8
SEGMENT_TYPE     : INDEX
OWNER            : SYS
SEGMENT_NAME     : I_OBJ4
PARTITION_NAME   :
EXTENT_ID        : 0
BYTES            : 65536
TABLESPACE_NAME  : SYSTEM
RELATIVE_FNO     : 1
SEGTSN           : 0
SEGRFN           : 1
SEGBID           : 360
PL/SQL procedure successfully completed.

--//一看到这里我马上反应过来我前面的恢复有问题,因为rename 对象的操作实际上delete然后insert.
--//这样其它obj$涉及到的索引都要修改,我犯了教条主义的错误,有点想当然了.

--//0x004000f3 = set dba 1,243 = alter system dump datafile 1 block 243 = 4194547
--//很明显索引i_obj4找不到这个键值.
--//另外注意这样执行没有问题,看来oracle的索引检查存在问题的.
SYS@book> validate index i_obj4;
Index analyzed.

SYS@book> analyze index i_obj4 validate structure;
Index analyzed.

3.尝试恢复前看看obj$有那些索引:
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 86998    86998  1156 2017-02-04 06:00:11 1      VISIBLE
            OBJ$       I_OBJ2     NORMAL  YES  VALID  NO   N     3    875 86998    86998 64478 2017-02-04 06:00:11 1      VISIBLE
            OBJ$       I_OBJ3     NORMAL  NO   VALID  NO   N     2     16  3421     3421   249 2017-02-04 06:00:11 1      VISIBLE
            OBJ$       I_OBJ4     NORMAL  NO   VALID  NO   N     2    382  9342    86998  3259 2017-02-04 06:00:11 1      VISIBLE
            OBJ$       I_OBJ5     NORMAL  YES  VALID  NO   N     3    875 86998    86998 64466 2017-02-04 06:00:11 1      VISIBLE

4.尝试i_obj4索引恢复:

SYS@book> select /*+ full(obj$) */ rowid,DATAOBJ#,TYPE#,OWNER# from obj$ where name='IDL_UB1$' ;
ROWID                DATAOBJ#      TYPE#     OWNER#
------------------ ---------- ---------- ----------
AAAAASAABAAAADzAAX        225          2          0

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 ;

SYS@book> select  /*+ index(obj$ i_obj4) */ rowid,DATAOBJ#,TYPE#,OWNER# from obj$ where name='IDL_UB1$' ;
no rows selected
--//有点不理解,使用提示index(obj$ i_obj4)至少应该看到错误的rowid.

BBED> x  /rnnnx dba 1,363 *kd_off[10]
rowdata[4]                                  @4436
----------
flag@4436:     0x00 (NONE)
lock@4437:     0x00
data key:
col    0[3] @4439: 225
col    1[2] @4443: 2
col    2[1] @4446: 0
col    3[6] @4448:  0x00  0x41  0x50  0xa6  0x00  0x06

--//004150a6 = set dba 1,86182 = alter system dump datafile 1 block 86182 = 4280486,还是指向原来的位置.
--//噢明白了前面使用索引的查询不对,应该写成,实际上看上面的执行计划很容易明白,走的是 INDEX FULL SCAN:
SYS@book> select  /*+ index(obj$ i_obj4) */ rowid,DATAOBJ#,TYPE#,OWNER# from obj$ where DATAOBJ#=225 and TYPE#=2 and OWNER#=0 ;
ROWID                DATAOBJ#      TYPE#     OWNER#
------------------ ---------- ---------- ----------
AAAAASAABAAAVCmAAG        225          2          0

SYS@book> @ rowid AAAAASAABAAAVCmAAG
OBJECT FILE BLOCK ROW ROWID_DBA  DBA     TEXT
------ ---- ----- --- ---------- ------- ----------------------------------------
    18    1 86182   6   0x4150A6 1,86182 alter system dump datafile 1 block 86182
--//很明显指向rename后的对象.
--//修复就很简单就是col    3[6] 现在的0x00  0x41  0x50  0xa6  0x00  0x06 换成 00 40 00 f3 00 17.
BBED> dump  dba 1,363 offset 4448 count 6
 File: /mnt/ramdisk/book/system
 ------------------------------------
 004150a6 0006
 <16 bytes per line>

assign dba 1,363 offset 4448 = 0x00;
assign dba 1,363 offset 4449 = 0x40;
assign dba 1,363 offset 4450 = 0x00;
assign dba 1,363 offset 4451 = 0xf3;
assign dba 1,363 offset 4452 = 0x00;
assign dba 1,363 offset 4453 = 0x17;

BBED> sum apply
Check value for File 1, Block 363:
current = 0xc26a, required = 0xc26a

BBED> verify
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/system01.dbf
BLOCK = 363

SYS@book> alter system flush buffer_cache;
System altered.

SYS@book> select  /*+ index(obj$ i_obj4) */ rowid,DATAOBJ#,TYPE#,OWNER#,name from obj$ where DATAOBJ#=225 and TYPE#=2 and OWNER#=0 ;
ROWID              DATAOBJ# TYPE# OWNER# NAME
------------------ -------- ----- ------ ---------
AAAAASAABAAAADzAAX      225     2      0 IDL_UB1$
--//剩下i_obj1,i_obj3索引也是类似.

5.尝试i_obj1索引恢复:
SYS@book> @ treedump i_obj1
 OBJECT_ID
----------
        36

*** 2023-11-02 11:26:14.695
----- begin tree dump
branch: 0x400151 4194641 (0: nrow: 250, level: 1)
   leaf: 0x400152 4194642 (-1: nrow: 421 rrow: 421)
   leaf: 0x400153 4194644 (0: nrow: 420 rrow: 420)
   ....

SYS@book> select  /*+ index(obj$ i_obj1) */ rowid,obj#,OWNER#,type# from obj$ where OBJ#=225 and OWNER#=0 ;
ROWID                    OBJ#     OWNER#      TYPE#
------------------ ---------- ---------- ----------
AAAAASAABAAAVCmAAG        225          0          2

--//4194642 = set dba 1,338 = alter system dump datafile 1 block 338 = 0x400152

BBED> x  /rnnn dba 1,338 *kd_off[226]
rowdata[3711]                               @4688
-------------
flag@4688:     0x00 (NONE)
lock@4689:     0x02
keydata[6]:    0x00  0x41  0x50  0xa6  0x00  0x06

data key:
col    0[3] @4697: 225
col    1[1] @4701: 0
col    2[2] @4703: 2

--//i_OBJ1是唯 一索引 ,rowid在date key前面.

BBED> dump  dba 1,338 offset 4690 count 6
 File: /mnt/ramdisk/book/system
 ------------------------------------
 004150a6 0006
<16 bytes per line>

assign dba 1,338 offset 4690 = 0x00;
assign dba 1,338 offset 4691 = 0x40;
assign dba 1,338 offset 4692 = 0x00;
assign dba 1,338 offset 4693 = 0xf3;
assign dba 1,338 offset 4694 = 0x00;
assign dba 1,338 offset 4695 = 0x17;

BBED> sum apply
Check value for File 1, Block 338:
current = 0x6f2b, required = 0x6f2b

BBED> verify
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/system01.dbf
BLOCK = 338

SYS@book> alter system flush buffer_cache;
System altered.

SYS@book> select  /*+ index(obj$ i_obj1) */ rowid,obj#,OWNER#,type#,name from obj$ where OBJ#=225 and OWNER#=0 and type#=2;
ROWID              OBJ# OWNER# TYPE# NAME
------------------ ---- ------ ----- --------
AAAAASAABAAAADzAAX  225      0     2 IDL_UB1$

6.尝试i_obj3索引恢复:
--//剩下i_obj3索引也是类似.
SYS@book> set null null
SYS@book> select  /*+ full(obj$ ) */ rowid,oid$ from obj$ where name='IDL_UB1$';
ROWID              OID$
------------------ -----
AAAAASAABAAAADzAAX null

--//很幸运name='IDL_UB1$'的OID$是NULL,i_obj3不会存在这样的键值.也就是不需要修复操作.

SYS@book> analyze table obj$ validate structure cascade;
Table analyzed.

--//这样才算彻底恢复.
--//我不再做不等长rename的bbed测试了,这样工作量有点大,直接修改obj$数据字典的方法还是简单许多.

6.总结:
--//主要问题在于分析对象错误,实际上如果意识到rename操作是delete然后insert,就应该意识到自己的恢复没有完成.
--//另外不建议选择bbed的恢复模式.

7.补充相关ora-00600 13011错误信息:
ORA-00600: internal error code, arguments: [13011], [18], [4280486], [6], [4280486], [17], [], [], [], [], [], []

--//4280486 = set dba 1,86182 = alter system dump datafile 1 block 86182 = 0x4150a6
--//1,243 = file#,block# dba(10): 4194547 = file#,block# dba(16): 0x4000f3

--//仅仅是我的猜测:
参数1 : obj#  对象号,obj$的obj#=18.
参数2 : 块号  dba 1,86182
参数3 : 行号  索引上记录的行号 0x6
参数4 : 块号  dba 1,86182
参数5 : 行号  表上记录的行号   0x17=23
--//这里块号一样我不是很清楚。总感觉参数4应该记录的是4194547。

8.后记:
--//为了检验自己恢复正确,继续做rename测试,小心不要在生产系统做这样的测试!!
SYS@book> rename IDL_UB1$ to IDL_UB1Y_BAK;
Table renamed.

SYS@book> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SYS@book> startup
ORACLE instance started.
Total System Global Area  643084288 bytes
Fixed Size                  2255872 bytes
Variable Size             205521920 bytes
Database Buffers          427819008 bytes
Redo Buffers                7487488 bytes
Database mounted.
Database opened.
--//可以正常启动.

SYS@book> @ rowid AAAAASAABAAAADzAAX
       || DBMS_ROWID.ROWID_BLOCK_NUMBER ('AAAAASAABAAAADzAAX')
          *
ERROR at line 13:
ORA-00604: error occurred at recursive SQL level 1
ORA-00942: table or view does not exist

SYS@book> update obj$ set name='IDL_UB1$'  where name='IDL_UB1Y_BAK';
1 row updated.

SYS@book> commit ;
Commit complete.

SYS@book> alter system flush buffer_cache;
System altered.

SYS@book> alter system flush shared_pool;
System altered.

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 ;

--//OK,现在恢复正常.
SYS@book> select  /*+ index(obj$ i_obj4) */ rowid,DATAOBJ#,TYPE#,OWNER# from obj$ where name='IDL_UB1$' ;
ROWID              DATAOBJ# TYPE# OWNER#
------------------ -------- ----- ------
AAAAASAABAAAVCmAAt      225     2      0

SYS@book> @ rowid AAAAASAABAAAVCmAAt
OBJECT FILE BLOCK ROW ROWID_DBA  DBA     TEXT
------ ---- ----- --- ---------- ------- ----------------------------------------
    18    1 86182  45   0x4150A6 1,86182 alter system dump datafile 1 block 86182
--//rowid已经变了.

文章来源地址https://www.toymoban.com/news/detail-743719.html

到了这里,关于[20231103]rename IDL_UB1$后使用bbed的恢复的后遗症.txt的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • [20231026]bbed查看索引kd_off结构的问题.txt

    [20231026]bbed查看索引kd_off结构的问题.txt --//使用bbed查看索引kd_off结构时存在问题,前面两项指向的偏移不对,从kd_off[2]算起,而且记录的是相对偏移=绝对偏移-kdxle偏移. --//遗漏的两项可以通过最大的kd_off项记录的地址+2 ,+4 获得. --//dump offset kd_off[max]+2 count 2 --//dump offset kd_off

    2024年02月08日
    浏览(37)
  • ChatGPT:竟然精通ENVI IDL、ArcGIS等软件!

    目录 01 使用途径 02 使用 我试了很多网站,包括注册登录、插件、镜像网站,微信机器人,QQ机器人,但是目前这些或多或少都由于OpenAI的限制无法正常使用。所以总的来说需要科学上网并且需要国外手机号,这有一定的难度。 总所周知,ENVI IDL是在编程语言中是多么冷门的

    2023年04月16日
    浏览(36)
  • 微服务间请求响应定义方式对比 (Apache Dubbo, IDL 定义,RESTful API)

    1. Apache Dubbo 分布式RPC Apache Dubbo 是一种分布式服务框架,它提供了一种透明的 RPC 机制,可以让服务之间像调用本地方法一样进行调用。Dubbo 使用 IDL 来定义服务接口,并使用各种协议(如 HTTP、Dubbo 协议等)进行通信。 优点: 透明化调用:无需关心服务部署细节,就像调用本

    2024年02月19日
    浏览(42)
  • 计算机毕业设计springboot基于微信小程序的综合旅游管理系统的设计与实现ub9429【附源码+数据库+部署+LW】

    本项目包含程序+源码+数据库+LW+调试部署环境,文末可获取一份本项目的java源码和数据库参考。 系统的选题背景和意义 选题背景: 随着旅游业的快速发展和人们对旅游体验的不断提升,传统的旅游管理方式已经无法满足日益增长的需求。综合旅游管理系统涉及到旅游线路规

    2024年02月03日
    浏览(43)
  • 【Python】进阶学习:pandas--rename()用法详解

    【Python】进阶学习:pandas-- rename()用法详解 🌈 个人主页:高斯小哥 🔥 高质量专栏:Matplotlib之旅:零基础精通数据可视化、Python基础【高质量合集】、PyTorch零基础入门教程👈 希望得到您的订阅和支持~ 💡 创作高质量博文(平均质量分92+),分享更多关于深度学习、PyTorch、

    2024年04月11日
    浏览(50)
  • npm install 报错 Error: EPERM: operation not permitted, rename

    用管理员身份打开终端再执行命令。 删除C:Users{账户}下的.npmrc文件 删除node_modules文件夹 执行命令 npm cache clean -f 然后执行安装命令 删除node_modules文件夹 执行命令 npm cache clean -f 重启电脑 再次执行安装命令 执行 npm install npm@6.0.0 执行安装命令 切换npm的下载源: npm config se

    2023年04月23日
    浏览(44)
  • Error: EACCES: permission denied, rename ‘/usr/local/lib/node_modules/appium‘

    在使用npm uninstall -g appium卸载appium的过程中报错 1、首先检查谁拥有该目录 它拒绝访问,因为 node_module 文件夹下的appium归 root 所有    因此需要通过将 root 更改为您的用户来更改此设置,但首先运行下面的命令来检查您当前的用户如何通过 OS X 中的命令行获取活动用户的名称

    2024年02月12日
    浏览(68)
  • vscode重命名文件时卡住,错误信息Error: EPERM: operation not permitted, rename xxx -> xxx

    本人小白,最近使用vscode编写学习设计动态网页时,发现无法重命名文件,并且vscode会卡住导致其他文件也无法访问,只能重启vscode,或是等设置的运行时长结束后弹出报错信息才会恢复。 看了很多大佬的文章并尝试后也是药不对症。最后在不断的摸索下找到了我这种情况的

    2024年02月13日
    浏览(54)
  • npm install cnpm -g命令报错:npm ERR! Error: EPERM: operation not permitted, rename ‘C:

    完整报错如下: C:Windowssystem32npm install cnpm -g npm WARN rollback Rolling back minipass@3.3.6 failed (this is probably harmless): EPERM: operation not permitted, lstat \\\'C:UsersQGLiuAppDataRoamingnpmnode_modulescnpmnode_modulesminipass-fetchnode_modules\\\' npm WARN notsup Unsupported engine for cnpm@9.4.0: wanted: {\\\"node\\\":\\\"= 14.18.0\\\"} (cu

    2024年04月10日
    浏览(40)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包