20180614删除bootstrap$记录无法启动3补充

简介: [20180614][20180614]删除bootstrap$记录无法启动3(补充).txt --//昨天测试删除bootstrap$记录,导致数据库重启出现问题的修复方法: --//链接: http://blog.

[20180614][20180614]删除bootstrap$记录无法启动3(补充).txt

--//昨天测试删除bootstrap$记录,导致数据库重启出现问题的修复方法:
--//链接:
http://blog.itpub.net/267265/viewspace-2156144/=>[20180612]删除bootstrap$记录无法启动.txt
http://blog.itpub.net/267265/viewspace-2156149/=>[20180614]删除bootstrap$记录无法启动2.txt

--//有网友问的问题,就是使用bbed修复记录后,修改flag从0x3c=>0x2c后,如果执行verify会报错.
--//从我个人认为如果select正常,这些问题可以忽略.真要修复实际对于不经常使用bbed的用户还是难度的.
--//实际上这个问题可以参考链接:
http://blog.itpub.net/267265/viewspace-2137082/=>[20170412]bbed恢复修改记录(不等长).txt.
--//我喜欢通过例子讲解问题:

1.环境:
SCOTT@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

SCOTT@book> create table t as select * from dept ;
Table created.

SCOTT@book> select rowid,t.* from t ;
ROWID                  DEPTNO DNAME          LOC
------------------ ---------- -------------- -------------
AAAWEIAAEAAAAIjAAA         10 ACCOUNTING     NEW YORK
AAAWEIAAEAAAAIjAAB         20 RESEARCH       DALLAS
AAAWEIAAEAAAAIjAAC         30 SALES          CHICAGO
AAAWEIAAEAAAAIjAAD         40 OPERATIONS     BOSTON

SCOTT@book> @ &r/rowid AAAWEIAAEAAAAIjAAA
    OBJECT       FILE      BLOCK        ROW ROWID_DBA            DBA                  TEXT
---------- ---------- ---------- ---------- -------------------- -------------------- ----------------------------------------
     90376          4        547          0  0x1000223           4,547                alter system dump datafile 4 block 547 ;

SCOTT@book> delete from t where deptno in (10,30);
2 rows deleted.

SCOTT@book> commit ;
Commit complete.

SCOTT@book> alter system checkpoint;
System altered.

2.使用bbed修复:
BBED> set dba 4,547
        DBA             0x01000223 (16777763 4,547)

BBED> set count 10
        COUNT           10

--//注意在使用find前设置count不要太大,否则查询字符0x3c可能跳过.
--//补充一点: 0x3c对应asicc码是'<',0x2c对应asicc码是','.
BBED> map
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 547                                   Dba:0x01000223
------------------------------------------------------------
KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes                      @0
struct ktbbh, 96 bytes                     @20
struct kdbh, 14 bytes                      @124
struct kdbt[1], 4 bytes                    @138
sb2 kdbr[4]                                @142
ub1 freespace[7946]                        @150
ub1 rowdata[92]                            @8096
ub4 tailchk                                @8188

BBED> set offset 8096
        OFFSET          8096

BBED> find  /x 0x3c curr
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 547               Offsets: 8120 to 8129  Dba:0x01000223
----------------------------------------------------------------
3c020302 c11f0553 414c
<64 bytes per line>

BBED> x /rncc offset 8120
rowdata[24]                                 @8120
-----------
flag@8120: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH)
lock@8121: 0x02
cols@8122:    0

BBED> find
File: /mnt/ramdisk/book/users01.dbf (4)
Block: 547               Offsets: 8162 to 8171   Dba:0x01000223
-----------------------------------------------------------------
3c020302 c10b0a41 4343
<64 bytes per line>

--//可以发现删除记录偏移在8120,8162.执行如下:

assign dba 4,547 offset 8120 = 0x2c
assign dba 4,547 offset 8162 = 0x2c

--//检查记录情况.
BBED> x /4rncc *kdbr[3]
rowdata[0]                                  @8096
----------
flag@8096: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8097: 0x00
cols@8098:    3

col    0[2] @8099: 40
col   1[10] @8102: OPERATIONS
col    2[6] @8113: BOSTON

rowdata[24]                                 @8120
-----------
flag@8120: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8121: 0x02
cols@8122:    3

col    0[2] @8123: 30
col    1[5] @8126: SALES
col    2[7] @8132: CHICAGO

rowdata[44]                                 @8140
-----------
flag@8140: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8141: 0x00
cols@8142:    3

col    0[2] @8143: 20
col    1[8] @8146: RESEARCH
col    2[6] @8155: DALLAS

rowdata[66]                                 @8162
-----------
flag@8162: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8163: 0x02
cols@8164:    3

col    0[2] @8165: 10
col   1[10] @8168: ACCOUNTING
col    2[8] @8179: NEW YORK

--//检查:
BBED> sum apply dba 4,547
Check value for File 4, Block 547:
current = 0xdc32, required = 0xdc32

BBED> verify dba 4,547
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/users01.dbf
BLOCK = 547

Block Checking: DBA = 16777763, Block Type = KTB-managed data block
data header at 0x7ff1765ed27c
kdbchk: the amount of space used is not equal to block size
        used=118 fsc=42 avsp=7946 dtl=8064
Block 547 failed with check code 6110
DBVERIFY - Verification complete
Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 1
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED

--//可以发现verify报错,实际上fsc保存了删除记录时保存的长度.
SCOTT@book> select sum(length(dname)+length(deptno)+length(loc)) n10 from dept where deptno in (10,30);
                  N10
---------------------
                   34

--//加上删除时每个记录前的长度指示器占1个字节(3个字段),3个字节.以及cols字段占1个字节(注意计算不包括flag,lock的长度)
--//34+4*2  = 42.也就是fsc记录删除记录时回收的长度.

3.检查:
SCOTT@book> alter system flush buffer_cache;
System altered.

SCOTT@book> select rowid,t.* from t ;
ROWID                  DEPTNO DNAME          LOC
------------------ ---------- -------------- -------------
AAAWEIAAEAAAAIjAAA         10 ACCOUNTING     NEW YORK
AAAWEIAAEAAAAIjAAB         20 RESEARCH       DALLAS
AAAWEIAAEAAAAIjAAC         30 SALES          CHICAGO
AAAWEIAAEAAAAIjAAD         40 OPERATIONS     BOSTON

--//可以发现即使verify错误,问题不大,显示已经正常.不必计较这个问题.
--//如果在该块以后有事务发生,itl槽被覆盖.可以执行多次.
select * from t where rownum=1 for update;
commit ;
alter system flush buffer_cache;

--//错误变成如下:
BBED> verify dba 4,547
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/users01.dbf
BLOCK = 547

Block Checking: DBA = 16777763, Block Type = KTB-managed data block
data header at 0x21d8e7c
kdbchk: the amount of space used is not equal to block size
        used=118 fsc=0 avsp=7988 dtl=8064
Block 547 failed with check code 6110

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 1
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED

--//当然显示没有任何问题:
SCOTT@book> select rowid,t.* from t ;
ROWID                  DEPTNO DNAME          LOC
------------------ ---------- -------------- -------------
AAAWEIAAEAAAAIjAAA         10 ACCOUNTING     NEW YORK
AAAWEIAAEAAAAIjAAB         20 RESEARCH       DALLAS
AAAWEIAAEAAAAIjAAC         30 SALES          CHICAGO
AAAWEIAAEAAAAIjAAD         40 OPERATIONS     BOSTON

--//如果真要修复,其实是很繁琐的.
--//参考http://blog.itpub.net/267265/viewspace-2137082/=>[20170412]bbed恢复修改记录(不等长).txt.
--//公式: dtl-used+fsc=avsp.
--//8064-118+0 = 7946,修改avsp=7946就ok了.

BBED> p dba 4,547 kdbh
struct kdbh, 14 bytes                       @124
   ub1 kdbhflag                             @124      0x00 (NONE)
   sb1 kdbhntab                             @125      1
   sb2 kdbhnrow                             @126      4
   sb2 kdbhfrre                             @128     -1
   sb2 kdbhfsbo                             @130      26
   sb2 kdbhfseo                             @132      7972
   sb2 kdbhavsp                             @134      7988
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
   sb2 kdbhtosp                             @136      7992

BBED> assign dba 4,547 kdbh.kdbhavsp=7946
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
sb2 kdbhavsp                                @134      7946

BBED> sum apply dba 4,547
Check value for File 4, Block 547:
current = 0x6371, required = 0x6371

BBED> verify dba 4,547
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/users01.dbf
BLOCK = 547

Block Checking: DBA = 16777763, Block Type = KTB-managed data block
data header at 0x7f60bb6a527c
kdbchk: space available on commit is incorrect
        tosp=7992 fsc=0 stb=0 avsp=7946
Block 547 failed with check code 6111

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 1
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED

--//avsp+fsc+stb=tops,7946+0+0=7975,fsc=0.要修改kdbh.kdbhtosp=kdbh.kdbhavsp。

BBED> assign dba 4,547 kdbh.kdbhtosp= dba 4,547 kdbh.kdbhavsp
sb2 kdbhtosp                                @136      7946

BBED> p dba 4,547 kdbh
struct kdbh, 14 bytes                       @124
   ub1 kdbhflag                             @124      0x00 (NONE)
   sb1 kdbhntab                             @125      1
   sb2 kdbhnrow                             @126      4
   sb2 kdbhfrre                             @128     -1
   sb2 kdbhfsbo                             @130      26
   sb2 kdbhfseo                             @132      7972
   sb2 kdbhavsp                             @134      7946
   sb2 kdbhtosp                             @136      7946

BBED> sum apply dba 4,547
Check value for File 4, Block 547:
current = 0x6343, required = 0x6343

BBED> verify dba 4,547
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/users01.dbf
BLOCK = 547

--//总之,剩下的修复很烦,自己不经常做也会搞晕.而且在修改前一定要做好备份,特别是生产系统!!
--//实际上就是2步:(在itl槽覆盖后,不覆盖要修改itl槽的对于信息设置fsc=0)
1.dtl-used+fsc=avsp.
  used=118 fsc=0 avsp=7988 dtl=8064
  8064-118+0 = 7946
  assign dba 4,547 kdbh.kdbhavsp=7946
2.assign dba 4,547 kdbh.kdbhtosp= dba 4,547 kdbh.kdbhavsp

目录
相关文章
|
4月前
|
Java Serverless 应用服务中间件
函数计算操作报错合集之JVM启动时找不到指定的日志目录,该如何解决
Serverless 应用引擎(SAE)是阿里云提供的Serverless PaaS平台,支持Spring Cloud、Dubbo、HSF等主流微服务框架,简化应用的部署、运维和弹性伸缩。在使用SAE过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
4月前
|
前端开发 NoSQL JavaScript
若依修改---重新部署项目注意事项,新文件初始化需要修改的地方,打包后的文件很难进行修改,如果想要不断修改项目,注意保存原项目,才可以不断修改,前端:在Vue.config.js文件中修改target
若依修改---重新部署项目注意事项,新文件初始化需要修改的地方,打包后的文件很难进行修改,如果想要不断修改项目,注意保存原项目,才可以不断修改,前端:在Vue.config.js文件中修改target
|
Linux
Linux不停止服务快速清空日志文件(包含所有文件,不光是日志)
Linux不停止服务快速清空日志文件(包含所有文件,不光是日志)
143 0
|
SQL 存储 小程序
[原]排错实战——VS清空最近打开的工程记录
快速清理 visual studio 最近打开的工程列表,有脚本也有小程序
jira学习案例38-清除警告信息
jira学习案例38-清除警告信息
81 0
jira学习案例38-清除警告信息
|
存储 数据库
laravel-admin 查询过滤时间戳(数据库使用int类型)不起作用案例复现及解决办法
laravel-admin 查询过滤时间戳(数据库使用int类型)不起作用案例复现及解决办法
280 0
laravel-admin 查询过滤时间戳(数据库使用int类型)不起作用案例复现及解决办法
|
缓存 索引
ES的删除和更新,旧数据到低是如何处理的?
根据ES的读写入原理,大家都知道ES写入时每秒从内存缓冲区(memory buffer)生成小的segment,将其递交给系统缓存(OS filesystem cache)中,后台会定期的对这些小的segment 合并成一个大的segment段
382 0
ES的删除和更新,旧数据到低是如何处理的?
Confluence 6 针对合并完全失败的内容重新运行合并
如果在系统合并的时候有任何内容的合并失败的话,一个 Confluence 的管理员可以再次重新启动内容合并(请参考前面页面的内容)。只有内容还是使用 wiki 格式的才会被合并,因此重新合并所需要的时间总是会少于原始内容合并所需要的时间的。
835 0
|
关系型数据库 MySQL 数据库
日常问题记录及解决方法
日常问题记录及解决方法
1405 0
|
Oracle 前端开发 关系型数据库
[20180614]删除bootstrap$记录无法启动2
[20180614]删除bootstrap$记录无法启动2.txt --//前几天看链接http://www.xifenfei.com/2018/05/willfully-delete-bootstrap.
1387 0
下一篇
无影云桌面