分类目录归档：Oracle

bbed修改数据内容

发表于 2011 年 8 月 28 日 由 惜分飞
1、创建模拟表
SQL> create table hr.b(id number,name varchar2(100)) tablespace xff;
Table created.
SQL> insert into hr.b values(1,’aaa’);
1 row created.
Commit complete.
2、查看数据位置
QL>  select   rowid,
2   dbms_rowid.rowid_relative_fno(rowid)rel_fno,
3   dbms_rowid.rowid_block_number(rowid)blockno,
4   dbms_rowid.rowid_row_number(rowid) rowno
5   from hr.b;
ROWID                 REL_FNO    BLOCKNO      ROWNO
—————— ———- ———- ———-
AAAHytAACAAAAIKAAA          2        522          0
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
虽然bbed 可以在db open 状态来进行修改，但是建议在做任何修改操作之前先shutdown db。 这样避免checkpoint 进程重写bbed 对block 的修改。 也避免oracle 在bbed 修改完成之前读block 或者申明block 为corrupt。
[oracle@localhost ~]$ bbed parfile=/tmp/parfile.cnf（/tmp/parfile.cnf文件见bbed破坏数据文件）
Password:
BBED: Release 2.0.0.0.0 – Limited Production on Sat Aug 20 17:10:24 2011
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED> show all
FILE#           2
BLOCK#          1
OFFSET          0
DBA             0×00800001 (8388609 2,1)
FILENAME        /opt/oracle/oradata/xifenfei/xff01.dbf
BIFILE          bifile.bbd
LISTFILE        /tmp/list
BLOCKSIZE       8192
MODE            Edit
EDIT            Unrecoverable
IBASE           Dec
OBASE           Dec
WIDTH           80
COUNT           512
LOGFILE         log.bbd
SPOOL           No
3、设置dba位置
BBED> set dba 2,522
DBA             0x0080020a (8389130 2,522)
4、查询aaa位置
BBED> find /c aaa
File: /opt/oracle/oradata/xifenfei/xff01.dbf (2)
Block: 522              Offsets: 8185 to 8191           Dba:0x0080020a
————————————————————————
61616101 067735
<32 bytes per line>
5、查看该位置内容
BBED> dump /v offset 8185
File: /opt/oracle/oradata/xifenfei/xff01.dbf (2)
Block: 522     Offsets: 8185 to 8191  Dba:0x0080020a
——————————————————-
61616101 067735                     l aaa..w5
<16 bytes per line>
BBED> show all
FILE#           2
BLOCK#          522
OFFSET          8185
DBA             0x0080020a (8389130 2,522)
FILENAME        /opt/oracle/oradata/xifenfei/xff01.dbf
BIFILE          bifile.bbd
LISTFILE        /tmp/list
BLOCKSIZE       8192
MODE            Edit
EDIT            Unrecoverable
IBASE           Dec
OBASE           Dec
WIDTH           80
COUNT           512
LOGFILE         log.bbd
SPOOL           No
6、修改aaa为bbb
BBED> modify /c bbb
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /opt/oracle/oradata/xifenfei/xff01.dbf (2)
Block: 522              Offsets: 8185 to 8191           Dba:0x0080020a
————————————————————————
62626201 067735
<32 bytes per line>
BBED> dump /v
File: /opt/oracle/oradata/xifenfei/xff01.dbf (2)
Block: 522     Offsets: 8185 to 8191  Dba:0x0080020a
——————————————————-
62626201 067735                     l bbb..w5
<16 bytes per line>
7、应用变更
BBED> sum
Check value for File 2, Block 522:
current = 0xa285, required = 0xa286
此时 current checksum 是0xa285，requiredchecksum 是0xa286
BBED> sum apply
Check value for File 2, Block 522:
current = 0xa286, required = 0xa286
加上apply参数，使checksum一致。即之前的修改生效。
8、开启数据测试
SQL> startup
ORACLE instance started.
Total System Global Area  236000356 bytes
Fixed Size                   451684 bytes
Variable Size             201326592 bytes
Database Buffers           33554432 bytes
Redo Buffers                 667648 bytes
Database mounted.
Database opened.
SQL> col name for a20
SQL> select * from hr.b;
ID NAME
———- ——————–
1 bbb
发表在 非常规恢复 | 标签为 | 一条评论

ORA-00600 [2662]

发表于 2011 年 8 月 28 日 由 惜分飞

一、错误现象（alert日志中）
Errors in file /opt/oracle/admin/conner/udump/conner_ora_31607.trc:
ORA-00600: internal error code, arguments: [2662], [0], [897694446], [0], [897695488], [8388697], [], []

二、错误解释
ORA-600 [2662] “Block SCN is ahead of Current SCN”，说明当前数据库的数据块的SCN早于当前的SCN，主要是和存储在UGA变量中的dependent SCN进行比较，如果当前的SCN小于它，数据库就会产生这个ORA-600 [2662]的错误了。这个错误一共有五个参数，分别代表不同的含义
ORA-600 [2662] [a] [b] {c} [d] [e]
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg {c} dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
注：897694446<897695488
三、错误原因
1.使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库
2.硬件错误引起数据库没法写控制文件和重做日志文件
3.错误的部分恢复数据库
4.恢复了控制文件但是没有使用recover database using backup controlfile进行恢复
5.数据库crash后设置了_DISABLE_LOGGING隐含参数
6.在并行服务器环境中DLM存在问题

四、解决办法
1、如果SCN相差不多，可以通过多次重起数据库解决（每次加1）

2、通过10015 ADJUST_SCN事件来增进current SCN
1）计算level
1.1) Arg {c}* 4得出一个数值，假设为V_Wrap
1.2) 如果Arg [d]=0，则V_Wrap值为需要的level
Arg [d] < 1073741824，V_Wrap+1为需要的level Arg [d] < 2147483648，V_Wrap+2为需要的level Arg [d] < 3221225472，V_Wrap+3为需要的level 1.3）SCN被增进了1024*1024*1024*level（level*10 billion）
2）执行内部事件
alter session set events ’10015 trace name adjust_scn level N’;
注：mount状态下执行（open下无效）
alert日志中会出现：
Sat Aug 20 15:41:07 2011
Debugging event used to advance scn to 107374182400

发表在 ORA-xxxxx | 标签为 | 4 条评论

SCN与Oracle数据库恢复的关系

发表于 2011 年 8 月 28 日 由 惜分飞

一、SCN类型
1).System Checkpoint SCN
当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中。
我们可以通过下面SQL语句查询：
select checkpoint_change# from v$database;

2).Datafile Checkpoint SCN
当一个检查点动作完成之后，Oracle就把每个数据文件的scn单独存放在控制文件中.
我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt SCN号。
select name,checkpoint_change# from v$datafile;

3).Start SCN (启动SCN)
checkpoint完成后，将产生的checkpoint SCN 写入数据文件头(称之为start scn).这个SCN用于检查数据库启动过程是否需要做media recovery.
我们可以通过以下SQL语句查询：
select name,checkpoint_change# from v$datafile_header;
注意：数据文件头中的检查点SCN(start SCN) 与控制文件中记录的数据文件检查点SCN号含义是一样的。 也就是说，一旦发生全局范围以及文件级别的检查点时，不仅会将这时的检查点SCN号记录到控制文件，还会记录在检查点作用的数据文件头部。

4).End SCN号(stop scn, 终止SCN)
这个SCN号用于检查数据库启动过程是否需要做instance recovery.
我们可以通过以下SQL语句查询：
select name,last_change# from v$datafile;
在正常的数据库操作过程中，所有正处于联机读写模式下的数据文件的终止scn都为null.

二、各SCN之间关系
1）数据库运行期间的scn值
在数据库打开并运行之后，控制文件中的系统检查点、控制文件中的数据文件检查点scn和每个数据文件头中的启动scn都是相同的。控制文件中的每个数据文件的终止scn都为null.

2）数据库正常关闭的scn值
在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。

3）数据库重启过程中scn作用
在数据库重新启动的时候, Oracle将文件头中的那个启动scn与数据库文件检查点scn(控制文件中)进行比较，如果这两个值相互匹配，那么不需要Media Recovery， oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn, 如果这两个值也一致，就意味着所有对数据库的修改都没有在关闭数据库的过程中丢失，因此这次启动数据库的过程也不需要任何恢复操作(即不需要实例恢复)，此时数据库就可以打开了。当所有的数据库都打开之后，存储在控制文件中的数据文件终止scn的值再次被更改为null，这表示数据文件已经打开并能够正常使用了。

还需要注意的是:
在数据库重新启动的时候, Oracle首先比较(每个)文件头中的那个启动scn (start SCN) 与控制文件中记录的 (每个) 数据库文件检查点scn， 如果他们都相互匹配，那么不需要Media Recovery. 但是如果只是控制文件中记录的数据文件检查点(多个数据文件，对应多个SCN), 与 (对应的) 数据文件头中的启动SCN (start scn) 相同 , 而在每个在线的可读可写的数据文件“之间”，他们的检查点SCN不相同， 那么也要求Media Recovery .

发表在 Oracle | 评论关闭