20161114File Space Bitmap Block修复机制2

[20161114]File Space Bitmap Block修复机制2.txt

--前几天在测试File Space Bitmap Block时执行了,execute dbms_space_admin.TABLESPACE_REBUILD_BITMAPS('SUGAR')
--这样位图区全部设置为1,显示都是F。

--上次提到,execute dbms_space_admin.TABLESPACE_REBUILD_BITMAPS('SUGAR')会修改位图区全部设置为1,显示都是F。
--而内存中相应数据块是正确的,只要执行alter system checkpoint;就会"纠正这个错误".我还做了1个极端测试,就是
--execute dbms_space_admin.TABLESPACE_REBUILD_BITMAPS('SUGAR')后,另外一个会话强制执行shutdown abort。
--测试这个时候备份的情况,忘记先drop表了,补充测试.

1.环境:
SCOTT@book> @ &r/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

CREATE TABLESPACE SUGAR DATAFILE
  '/mnt/ramdisk/book/sugar01.dbf' SIZE 40M AUTOEXTEND ON NEXT 16M MAXSIZE UNLIMITED
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;

create table t1 tablespace sugar as select rownum id ,lpad('A',32,'A') name from dual connect by level<=1e5;
--建立大小5M的表。

create table t2 tablespace sugar as select rownum id ,lpad('B',32,'B') name from dual connect by level<=2e5;
create table t3 tablespace sugar as select rownum id ,lpad('C',32,'C') name from dual connect by level<=2e5;
alter system checkpoint;

2.做一个极端测试:

drop table t1 purge ;
drop table t2 purge ;
drop table t3 purge ;

SYS@book> execute dbms_space_admin.TABLESPACE_REBUILD_BITMAPS('SUGAR');
PL/SQL procedure successfully completed.

SYS@book> shutdown abort
ORACLE instance shut down.

$ bvi -b 24576 -s 8192 /mnt/ramdisk/book/sugar01.dbf
00006000  1E A2 00 00 03 00 80 01 55 46 62 00 00 00 01 04 79 41 00 00 06 00 00 00 80 00 00 00 00 00 00 00 ........UFb.....yA..............
00006020  00 F8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF ................................
00006040  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................................
00006060  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................................
00006080  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................................
000060A0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................................
000060C0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................................
000060E0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................................
00006100  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................................
00006120  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................................

--可以发现是FF。然后重新启动数据库到mount状态。

SYS@book> startup mount
ORACLE instance started.

Total System Global Area  634732544 bytes
Fixed Size                  2255792 bytes
Variable Size             197133392 bytes
Database Buffers          427819008 bytes
Redo Buffers                7524352 bytes
Database mounted.

RMAN> backup datafile 6 format '/u01/backup/d6_A.bak' ;

Starting backup at 2016-11-14 14:56:06
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/mnt/ramdisk/book/sugar01.dbf
channel ORA_DISK_1: starting piece 1 at 2016-11-14 14:56:07
channel ORA_DISK_1: finished piece 1 at 2016-11-14 14:56:08
piece handle=/u01/backup/d6_A.bak tag=TAG20161114T145607 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2016-11-14 14:56:08

$ ls -l /u01/backup/d6_A.bak
-rw-r----- 1 oracle oinstall 26066944 2016-11-14 14:56:07 /u01/backup/d6_A.bak

--大小26066944/1024/1024=24.859375M,可以发现备份时依赖这个位图区扫描。
--注:前面的分析有误,感谢别人纠正这个错误,做测试太不严谨了,我前面的测试实际上oracle对null block是不备份的的。

$ strings /u01/backup/d6_A.bak | grep  'AAAAAAAAAAAAA' |wc
100000  170040 3624269
$ strings /u01/backup/d6_A.bak | grep  'BBBBBBBBBBBBB' |wc
200000  340080 7243655
$ strings /u01/backup/d6_A.bak | grep  'CCCCCCCCCCCCC' |wc
200000  340080 7243655

SYS@book> alter database open ;
Database altered.

SYS@book> alter system checkpoint;
System altered.

$ bvi -b 24576 -s 8192 /mnt/ramdisk/book/sugar01.dbf
00006000  1E A2 00 00 03 00 80 01 57 46 62 00 00 00 01 04 79 41 00 00 06 00 00 00 80 00 00 00 00 00 00 00 ........WFb.....yA..............
00006020  00 00 00 00 00 F8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00006040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00006060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00006080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
000060A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
000060C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
000060E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................

--很奇怪这次位图区修复了。是否drop table t1 purge时没有写盘。重复测试在drop完成后加入检查点,这样建表是没有问题的。

RMAN> backup datafile 6 format '/u01/backup/d6_B.bak' ;
Starting backup at 2016-11-14 15:03:06
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/mnt/ramdisk/book/sugar01.dbf
channel ORA_DISK_1: starting piece 1 at 2016-11-14 15:03:07
channel ORA_DISK_1: finished piece 1 at 2016-11-14 15:03:08
piece handle=/u01/backup/d6_B.bak tag=TAG20161114T150306 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2016-11-14 15:03:08

$ ls -l /u01/backup/d6_B.bak
-rw-r----- 1 oracle oinstall 1089536 2016-11-14 15:03:07 /u01/backup/d6_B.bak
--可以发现这次备份不仅仅1M上下。

SCOTT@book> create table t4 tablespace sugar as select rownum id ,lpad('D',32,'D') name from dual connect by level<=1e5;
Table created.

3.重新测试再drop后加入检查点:
--步骤参考上面。仅仅在drop后加入alter system checkpoint;

--建立表空间,建表t1,t2,t3,

drop table t1 purge ;
drop table t2 purge ;
drop table t3 purge ;
alter system checkpoint;

SYS@book> execute dbms_space_admin.TABLESPACE_REBUILD_BITMAPS('SUGAR');
PL/SQL procedure successfully completed.

SYS@book> shutdown abort
ORACLE instance shut down.

--
SYS@book> startup
ORACLE instance started.
Total System Global Area  634732544 bytes
Fixed Size                  2255792 bytes
Variable Size             197133392 bytes
Database Buffers          427819008 bytes
Redo Buffers                7524352 bytes
Database mounted.
Database opened.

SCOTT@book> create table t4 tablespace sugar as select rownum id ,lpad('D',32,'D') name from dual connect by level<=1e5;
create table t4 tablespace sugar as select rownum id ,lpad('D',32,'D') name from dual connect by level<=1e5
                                                                                 *
ERROR at line 1:
ORA-00600: internal error code, arguments: [ktfbbssearch-9], [0], [624], [63488], [], [], [], [], [], [], [], []
--确实如此。

RMAN> backup datafile 6 format '/u01/backup/d6_C.bak' ;

Starting backup at 2016-11-14 15:23:58
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=46 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/mnt/ramdisk/book/sugar01.dbf
channel ORA_DISK_1: starting piece 1 at 2016-11-14 15:23:59
channel ORA_DISK_1: finished piece 1 at 2016-11-14 15:24:00
piece handle=/u01/backup/d6_C.bak tag=TAG20161114T152359 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2016-11-14 15:24:00

$ ls -l /u01/backup/d6_C.bak
-rw-r----- 1 oracle oinstall 26066944 2016-11-14 15:24:00 /u01/backup/d6_C.bak

--可以发现备份达到25M。

SYS@book> execute dbms_space_admin.TABLESPACE_REBUILD_BITMAPS('SUGAR');
PL/SQL procedure successfully completed.

RMAN> backup datafile 6 format '/u01/backup/d6_D.bak' ;

Starting backup at 2016-11-14 15:25:05
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=/mnt/ramdisk/book/sugar01.dbf
channel ORA_DISK_1: starting piece 1 at 2016-11-14 15:25:05
channel ORA_DISK_1: finished piece 1 at 2016-11-14 15:25:06
piece handle=/u01/backup/d6_D.bak tag=TAG20161114T152505 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2016-11-14 15:25:06

$ ls -l /u01/backup/d6_D.bak
-rw-r----- 1 oracle oinstall 1089536 2016-11-14 15:25:05 /u01/backup/d6_D.bak

--修复后一切正常,再次说明备份通过读取数据文件的问题信息,确定读取的数据块。而前一次测试存在错误。

时间: 2024-07-30 11:05:12

20161114File Space Bitmap Block修复机制2的相关文章

[20161111File Space Bitmap Block修复机制

[20161111]File Space Bitmap Block修复机制.txt --前几天在测试File Space Bitmap Block时执行了,execute dbms_space_admin.TABLESPACE_REBUILD_BITMAPS('SUGAR') --这样位图区全部设置为1,显示都是F.它的修复机制不是非常清楚,今天做一些深入的探究. --继续重复昨天的测试. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING            

1108File Space Bitmap Block损坏能修复吗2

[20161108]File Space Bitmap Block损坏能修复吗? --这阵子做了数据文件的一些探究,还是回到File Space Bitmap Block损坏修复的问题. --链接http://www.itpub.net/thread-2071023-1-1.html提到File Space Bitmap Block损坏,问能修复吗? --通过我前面的测试,可以把空间设置为1.这样就可以解决这个问题,问题在在于相应的数据块如何构造. --实际上很简单我仅仅建立1个相同大小的数据文

1104File Space Bitmap Block损坏能修复吗

[20161104]File Space Bitmap Block损坏能修复吗?.txt -- 链接http://www.itpub.net/thread-2071023-1-1.html提到File Space Bitmap Block损坏,问能修复吗? 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------

小而美的自我管理和修复机制

摘要: 借助微信,杭州微车队实现了不可思议的自我组织.协调.分工,这个自发的民间组织不属于任何一个商业机构,但是他们有序的自我管理能力令团队每个成员月收入至少提升了20%以上 借助微信,杭州微车队实现了不可思议的自我组织.协调.分工,这个自发的民间组织不属于任何一个商业机构,但是他们有序的自我管理能力令团队每个成员月收入至少提升了20%以上.今后或许会有越来越多类似的小而美组织的出现,移动互联网令去中心化的社会化协作变得更加高效. 周一下午4点多,邵展成在杭州机场出租车入口处静静地等待.几分钟前

测量block size 为8K ,自动分配的本地管理表空间的位图block一位能管理多少空间

从oracle8i起,oracle推出了本地管理表空间的来代替数据字典管理的表空间,数据字典管理表空间是用uet$,fet$这两个表来管理的,它们现在依然存在于数据库中,不过不起任何作用. SQL> select count(*) from uet$;   COUNT(*) ----------          0 SQL> select count(*) from fet$;   COUNT(*) ----------          0 下面来探究自动分配的本地管理表空间中一个bit

[20161107]关于数据文件位图区.txt

[20161107]关于数据文件位图区.txt --上个星期写一篇 [20161104]File Space Bitmap Block损坏能修复吗?.txt 链接:http://blog.itpub.net/267265/viewspace-2127826/       http://www.itpub.net/thread-2071023-1-1.html --里面提到 --正常数据文件第1块OS.第2块是文件头,第3块开始-128块是位图区. --我文件很小,估计在1块里面: --8192*

dump命令3——dump数据文件

转自网络: 1.dump数据文件头 就是datafile 的第1,第2个block,我们直接通过alter system dump datafile n block min 1 max 2;是得不到任何信息的,请看测试: SQL> alter system dump datafile 1 block min 1 block max 2; 系统已更改. 部分的DUMP文件内容 Start dump data blocks tsn: 0 file#: 1 minblk 1 maxblk 2 Bloc

[20171206]位图区一定在数据文件开头吗.txt

[20171206]位图区一定在数据文件开头吗.txt --//如果问你oracle数据文件的位图区位于数据文件开头部分吗?我想大家的回答一定,实际上在10g下未必,因为10g建立的数据文件. --//在数据区前面仅仅8块,第1块作为文件头,第2块作为位图区头,第3-8块(共6块)作为位图区,一般1个位图区块能容纳 --//(494+2)*32*4= 63488区,1个区=64K(对于SEGMENT SPACE MANAGEMENT AUTO). --//这样1个位图块可以容纳63488*64*

[20170412]op code列表.txt

[20170412]op code列表.txt 转载:http://www.itpub.net/thread-1517926-1-1.html --看redo转储,需要了解OP的含义,做一个记录: 附op code列表(来自网络): 格式:layer: opcode        LAYER的含义:                4 - Block Cleanout                5 - Transaction Management              10 - 索引操作