Friends Life and Oracle http://www.eygle.com/blog/ eygle的Oracle Blog，提供Oracle技术研究及深入探讨，同时记录个人爱好及生活历程。 Copyright 2006 Wed, 08 Nov 2006 11:48:58 +0800 http://www.movabletype.org/?v=3.33 http://blogs.law.harvard.edu/tech/rss DB link与检查点(checkpoint)和SCN 昨天在测试的时候发现了一个有趣的现象，就是通过DB查询的2个数据库间，SCN会被同步。

测试的过程如下.
1.首先获得本地的SCN

[oracle@jumper oracle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Nov 7 21:07:56 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> select dbms_flashback.GET_SYSTEM_CHANGE_NUMBER scn from dual;

SCN
----------
5287824

2.通过db link进行SCN查询

SQL> set serveroutput on
SQL> set feedback off
SQL> declare
  2  r_gname    varchar2(40);
  3  l_gname    varchar2(40);
  4  begin
  5     execute immediate
  6     'select GLOBAL_NAME from global_name@hsbill' into r_gname;
  7     dbms_output.put_line('gname of remote:'||r_gname);
  8     select GLOBAL_NAME into l_gname from global_name;
  9     dbms_output.put_line('gname of locald:'||l_gname);
 10  end;
 11  /
gname of remote:HSBILL.HURRAY.COM.CN
gname of locald:EYGLE


SQL> declare
  2  r_scn      number;
  3  l_scn      number;
  4  begin
  5     execute immediate
  6     'select dbms_flashback.GET_SYSTEM_CHANGE_NUMBER@hsbill from dual' into r_scn;
  7     dbms_output.put_line('scn of remote:'||r_scn);
  8     select dbms_flashback.GET_SYSTEM_CHANGE_NUMBER into l_scn from dual;
  9     dbms_output.put_line('scn of locald:'||l_scn);
 10  end;
 11  /
scn of remote:18992092078
scn of locald:18992092078

我们可以看到，通过DB Link查询后，两个数据库的SCN被同步。
手工执行checkpoint，此时可以发现数据库的checkpoint scn被增进:

SQL> col scn for 999999999
SQL> select file#,CHECKPOINT_CHANGE# scn from v$datafile;


     FILE#               SCN
---------- -----------------
         1           5287605
         2           5287605
         3           5287605
         4           5287605


SQL> alter system checkpoint;


System altered.


SQL> select file#,CHECKPOINT_CHANGE# scn from v$datafile;


     FILE#               SCN
---------- -----------------
         1       18992092162
         2       18992092162
         3       18992092162
         4       18992092162

这种机制其实是为了满足分布式事务(Distributed Transaction)的需要，只不过这里通过db link被触发。

-The End-

]]> http://www.eygle.com/archives/2006/11/db_link_checkpoint_scn.html http://www.eygle.com/archives/2006/11/db_link_checkpoint_scn.html Internal Wed, 08 Nov 2006 11:48:58 +0800 UTL_INADDR包获取ip地址的内部原理 今天有朋友在MSN上问我如何获得已经连接用户的IP地址。

我们知道，通过SYS_CONTEXT函数可以获得这部分信息，当前用户的ip等信息可以通过如下命令轻易获取：

SQL> select sys_context('userenv','host') from dual;

SYS_CONTEXT('USERENV','HOST')
--------------------------------------------------------------------------------
WORKGROUP\GQGAI

SQL> select sys_context('userenv','ip_address') from dual;

SYS_CONTEXT('USERENV','IP_ADDR
--------------------------------------------------------------------------------
172.16.34.20

可是如果我们希望获取其它session的地址信息等，通过SYS_CONTEXT函数就只能通过LOGON触发器来完成。

而如果没有触发器记录，则我们可以通过UTL_INADDR Package来实现。
我们看一下UTL_INADDR包获取ip等信息的实现原理。

我们在数据库中进行如下查询：

[oracle@jumper oracle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Wed Oct 25 11:24:22 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> !
[oracle@jumper oracle]$ ps -ef|grep sql
oracle 14700 14663 1 11:24 pts/0 00:00:00 sqlplus
oracle 14732 14702 0 11:24 pts/0 00:00:00 grep sql
[oracle@jumper oracle]$ ps -ef|grep LO
oracle 14701 14700 0 11:24 ? 00:00:00 oracleeygle (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle 14734 14702 0 11:24 pts/0 00:00:00 grep LO
[oracle@jumper oracle]$ exit
exit

SQL> SELECT UTL_INADDR.get_host_address('www.anysql.net') from dual;

UTL_INADDR.GET_HOST_ADDRESS('WWW.ANYSQL.NET')
---------------------------------------------------------------------
208.113.151.109

在Linux中我们通过strace跟踪这个进程，可以得到以下堆栈信息:

[oracle@jumper oracle]$ strace -p 14701
Process 14701 attached - interrupt to quit
read(7, "\0\313\0\0\6\0\0\0\0\0\3^\10a\200\0\0\0\0\0\0@\342\22\10"..., 2064) = 203
gettimeofday({1161746697, 269895}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 30000}, ru_stime={0, 10000}, ...}) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 10000}, ...}) = 0
gettimeofday({1161746697, 270542}, NULL) = 0
gettimeofday({1161746697, 270670}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 10000}, ...}) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 10000}, ...}) = 0
gettimeofday({1161746697, 271614}, NULL) = 0
gettimeofday({1161746697, 271748}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 10000}, ...}) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 10000}, ...}) = 0
gettimeofday({1161746697, 272347}, NULL) = 0
gettimeofday({1161746697, 272699}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 10000}, ...}) = 0
gettimeofday({1161746697, 272989}, NULL) = 0
gettimeofday({1161746697, 273140}, NULL) = 0
gettimeofday({1161746697, 273273}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 10000}, ...}) = 0
gettimeofday({1161746697, 273771}, NULL) = 0
gettimeofday({1161746697, 275526}, NULL) = 0
getpid() = 14701
open("/etc/resolv.conf", O_RDONLY) = 12
fstat64(12, {st_mode=S_IFREG|0644, st_size=46, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fba000
read(12, "search hurray.com.cn\nnameserver "..., 4096) = 46
read(12, "", 4096) = 0
close(12) = 0
munmap(0xb6fba000, 4096) = 0
socket(PF_UNIX, SOCK_STREAM, 0) = 12
connect(12, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory)
close(12) = 0
open("/etc/host.conf", O_RDONLY) = 12
fstat64(12, {st_mode=S_IFREG|0644, st_size=17, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fba000
read(12, "order hosts,bind\n", 4096) = 17
read(12, "", 4096) = 0
close(12) = 0
munmap(0xb6fba000, 4096) = 0
futex(0xb71a1a20, FUTEX_WAKE, 2147483647) = 0
open("/etc/hosts", O_RDONLY) = 12
fcntl64(12, F_GETFD) = 0
fcntl64(12, F_SETFD, FD_CLOEXEC) = 0
fstat64(12, {st_mode=S_IFREG|0644, st_size=175, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fba000
read(12, "# Do not remove the following li"..., 4096) = 175
read(12, "", 4096) = 0
close(12) = 0
munmap(0xb6fba000, 4096) = 0
open("/opt/oracle/product/9.2.0/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/i686/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libnss_dns.so.2", O_RDONLY) = 12
read(12, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\16"..., 512) = 512
fstat64(12, {st_mode=S_IFREG|0755, st_size=18632, ...}) = 0
old_mmap(NULL, 17100, PROT_READ|PROT_EXEC, MAP_PRIVATE, 12, 0) = 0xb6fb6000
old_mmap(0xb6fba000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 12, 0x3000) = 0xb6fba000
close(12) = 0
open("/opt/oracle/product/9.2.0/lib/libresolv.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/libresolv.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/i686/libresolv.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libresolv.so.2", O_RDONLY) = 12
read(12, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320(\0"..., 512) = 512
fstat64(12, {st_mode=S_IFREG|0755, st_size=76508, ...}) = 0
old_mmap(NULL, 73604, PROT_READ|PROT_EXEC, MAP_PRIVATE, 12, 0) = 0xb6fa4000
old_mmap(0xb6fb3000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 12, 0xf000) = 0xb6fb3000
old_mmap(0xb6fb4000, 8068, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6fb4000
close(12) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 12
connect(12, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("208.113.151.109")}, 28) = 0
send(12, "\324#\1\0\0\1\0\0\0\0\0\0\3www\5anysql\3com\0\0\1\0\1", 31, 0) = 31
gettimeofday({1161746697, 286025}, NULL) = 0
poll([{fd=12, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(12, FIONREAD, [74]) = 0
recvfrom(12, "\324#\201\200\0\1\0\1\0\1\0\0\3www\5anysql\3com\0\0\1\0"..., 1024, 0,
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("208.113.151.109")}, [16]) = 74
close(12) = 0
gettimeofday({1161746697, 290245}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 20000}, ...}) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 20000}, ...}) = 0
gettimeofday({1161746697, 291553}, NULL) = 0
write(10, "\2\275\0\0\6\0\0\0\0\0\20\31\266\344\217\3700\320\341S"..., 701) = 701
read(7, "\0\215\0\0\6\0\0\0\0\0\3^\t@\0\0\0\1\0\0\0\0\0\0\0\0\0"..., 2064) = 141
gettimeofday({1161746697, 294898}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 20000}, ...}) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 20000}, ...}) = 0
gettimeofday({1161746697, 295496}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 40000}, ru_stime={0, 20000}, ...}) = 0
gettimeofday({1161746697, 295847}, NULL) = 0
gettimeofday({1161746697, 295981}, NULL) = 0
lseek(9, 1024, SEEK_SET) = 1024
read(9, "\30\0$\0007\0@\0J\0V\0`\0i\0t\0~\0\232\0\245\0\320\0\330"..., 512) = 512
lseek(9, 47104, SEEK_SET) = 47104
read(9, "\f\0^\5\0\0P\0x\5\0\0\214\0y\5\0\0\250\0z\5\0\0\313\0{"..., 512) = 512
gettimeofday({1161746697, 297024}, NULL) = 0
write(10, "\0\202\0\0\6\0\0\0\0\0\4\1\0\0\0\1\1\0\0\0{\5\0\0\0\0\1"..., 130) = 130
read(7,
Process 14701 detached

在这个信息中，我们注意到Oracle顺序访问了如下文件来完成地址定位：

open("/etc/resolv.conf", O_RDONLY) = 12
open("/etc/host.conf", O_RDONLY) = 12
open("/etc/hosts", O_RDONLY) = 12

首先获取域名解析服务器，在根据host.conf文件确定解析顺序，因为缺省hosts文件优先，又继续读取/etc/hosts文件。

如果hosts文件存在解析关系，则返回信息；如果不存在，则继续问询DNS服务器，获得解析地址，如果不能解析，则会出错：

SQL> select UTL_INADDR.get_host_address('www.a.com') from dual;
select UTL_INADDR.get_host_address('www.a.com') from dual
*
ERROR at line 1:
ORA-29257: host www.a.com unknown
ORA-06512: at "SYS.UTL_INADDR", line 35
ORA-06512: at "SYS.UTL_INADDR", line 40
ORA-06512: at line 1

也就是说，UTL_INADDR的数据获取已经不依赖于数据库信息了，而SYS_CONTEXT的信息获取仍然来自数据库内部。

这就是UTL_INADDR包的工作原理。

-The End-

]]> http://www.eygle.com/archives/2006/10/how_to_getip_address.html http://www.eygle.com/archives/2006/10/how_to_getip_address.html HowTo Thu, 26 Oct 2006 11:30:06 +0800 获得Redo Block Size的非典型方法 我以前介绍过获得redo block size的方法，当然也可以通过dbfsize工具获得。

现在在这里我想介绍的是另外一种非典型方法，有多非典型呢?

问题来自于N年前我在一个客户的机器上部署的监控脚本，现在那些脚本看来还在运行着，我最近收到了大量类似如下内容的邮件:

ORA-16038: log 2 sequence# 17151 cannot be archived
ORA-19504: failed to create file ""
ORA-00312: online log 2 thread 1: '/export/home/oracle/oradata/cuwap/redo02.log'
ORA-19504: failed to create file "/data1/oraarc/PTL017151.arc"
ORA-19504: failed to create file "/data1/oraarc/PTL017151.arc"
ORA-27044: unable to write the header block of file
ORA-16038: log 2 sequence# 17151 cannot be archived
ORA-19504: failed to create file ""
ORA-00312: online log 2 thread 1: '/export/home/oracle/oradata/cuwap/redo02.log'
ORA-19504: failed to create file "/data1/oraarc/PTL017151.arc"
ORA-19504: failed to create file "/data1/oraarc/PTL017151.arc"
ORA-27044: unable to write the header block of file
ORA-16038: log 2 sequence# 17151 cannot be archived
ORA-19504: failed to create file ""
ORA-00312: online log 2 thread 1: '/export/home/oracle/oradata/cuwap/redo02.log'
ORA-19502: write error on file "/data1/oraarc/PTL017151.arc", blockno 169985 (blocksize=512)
ORA-27072: skgfdisp: I/O error
ORA-19502: write error on file "/data1/oraarc/PTL017151.arc", blockno 169985 (blocksize=512)
ORA-19502: write error on file "/data1/oraarc/PTL017152.arc", blockno 57345 (blocksize=512)
ORA-27072: skgfdisp: I/O error
ORA-19502: write error on file "/data1/oraarc/PTL017152.arc", blockno 57345 (blocksize=512)
ORA-16038: log 2 sequence# 17151 cannot be archived
ORA-19502: write error on file "", blockno (blocksize=)
ORA-00312: online log 2 thread 1: '/export/home/oracle/oradata/cuwap/redo02.log'
ORA-16038: log 2 sequence# 17151 cannot be archived
ORA-19502: write error on file "", blockno (blocksize=)
ORA-00312: online log 2 thread 1: '/export/home/oracle/oradata/cuwap/redo02.log'
ORA-16038: log 2 sequence# 17151 cannot be archived
ORA-19502: write error on file "", blockno (blocksize=)
ORA-00312: online log 2 thread 1: '/export/home/oracle/oradata/cuwap/redo02.log'
ORA-16038: log 3 sequence# 17152 cannot be archived
ORA-19502: write error on file "", blockno (blocksize=)
ORA-00312: online log 3 thread 1: '/export/home/oracle/oradata/cuwap/redo03.log'

我们注意到，在这些错误信息中，这样的提示至关重要:

ORA-19502: write error on file "/data1/oraarc/PTL017151.arc", blockno 169985 (blocksize=512)
ORA-27072: skgfdisp: I/O error
ORA-19502: write error on file "/data1/oraarc/PTL017151.arc", blockno 169985 (blocksize=512)
ORA-19502: write error on file "/data1/oraarc/PTL017152.arc", blockno 57345 (blocksize=512)

这里的Blocksize就告诉我们，在该系统上（Solaris），Redo Block Size是512 bytes。

这里的BlockNo让我想到了另外一个内容。

参考Steve Adams网站上的关于Log Buffer Usage的说明我们能找到另外一个有意思的内容，引用一下Steve的图：
log_buffer_mapping

我们知道，Redo Log Buffer和Redo Log File是通过Block映射（map）来完成空间分配和使用的，于是也就有了两个变量：
1.用以标示SGA中Redo Log Buffer基准位置的变量b
2.用以标示Redo Log File基准位置的变量i

如果这里存在问题的是redo log file,那么无法写入的blockno实际上就应该和variable (i)有关；当然对于归档日志文件，这里的blockno自然也是由最初的变量推进和定界的。

由以上输出的错误信息我们可以知道:

169985 * 512 /1024 /1024 = 83M

所以我们还可以判断Redo Log File的大小肯定是大于83M的，在Oracle9i中，缺省的Redo Log File大小是100M。

-The End-

]]> http://www.eygle.com/archives/2006/10/redo_block_size_and_sga_variable.html http://www.eygle.com/archives/2006/10/redo_block_size_and_sga_variable.html Internal Tue, 17 Oct 2006 16:57:22 +0800 sql.bsq与数据库的创建 如果我们使用脚本创建数据库，那么最先运行的是一个叫做CreateDB.sql的脚本。
这个脚本发出CREATE DATABASE的命令,具体类似如下的例子:

CREATE DATABASE eygle
MAXINSTANCES 1
MAXLOGHISTORY 1
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
DATAFILE '/opt/oracle/oradata/eygle/system01.dbf'
SIZE 250M REUSE AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE '/opt/oracle/oradata/eygle/temp01.dbf'
SIZE 40M REUSE AUTOEXTEND ON NEXT  640K MAXSIZE UNLIMITED
UNDO TABLESPACE "UNDOTBS1" DATAFILE '/opt/oracle/oradata/eygle/undotbs01.dbf'
SIZE 200M REUSE AUTOEXTEND ON NEXT  5120K MAXSIZE UNLIMITED
CHARACTER SET ZHS16GBK
NATIONAL CHARACTER SET AL16UTF16
LOGFILE GROUP 1 ('/opt/oracle/oradata/eygle/redo01.log') SIZE 10240K,
GROUP 2 ('/opt/oracle/oradata/eygle/redo02.log') SIZE 10240K,
GROUP 3 ('/opt/oracle/oradata/eygle/redo03.log') SIZE 10240K;
exit;

 在这个过程中，Oracle会调用$ORACLE_HOME/rdbms/admin/sql.bsq脚本，用于创建数据字典。

这个文件的位置受到一个隐含的初始化参数 （_init_sql_file ）的控制:

SQL> @GetParDescrb.sql
Enter value for par: init_sql
old   6:    AND x.ksppinm LIKE '%&par%'
new   6:    AND x.ksppinm LIKE '%init_sql%'

NAME            VALUE                 DESCRIB
--------------- --------------------- ------------------------------------------------------------
_init_sql_file  ?/rdbms/admin/sql.bsq File containing SQL statements to execute upon database creation

 如果在创建过程中，Oracle无法找到sql.bsq文件，则数据库创建将会出错.
如果我们移除sql.bsq文件，再看这样一个数据库创建过程:

[oracle@jumper scripts]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Fri Aug 18 15:45:26 2006

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to an idle instance.

SQL> startup nomount;
ORACLE instance started.

Total System Global Area  252777592 bytes
Fixed Size                   451704 bytes
Variable Size             134217728 bytes
Database Buffers          117440512 bytes
Redo Buffers                 667648 bytes
SQL> @CreateDB.sql
CREATE DATABASE eygle
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced


Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

 此时日志中会记录:

Fri Aug 18 15:45:49 2006
Errors in file /opt/oracle/admin/eygle/udump/eygle_ora_3632.trc:
ORA-01501: CREATE DATABASE failed
ORA-01526: error in opening file '?/rdbms/admin/sql.bsq'
ORA-07391: sftopn: fopen error, unable to open text file.
Error 1526 happened during db open, shutting down database
USER: terminating instance due to error 1526
Fri Aug 18 15:45:49 2006
Errors in file /opt/oracle/admin/eygle/bdump/eygle_ckpt_3623.trc:
ORA-01526: error in opening file ''
Instance terminated by USER, pid = 3632
ORA-1092 signalled during: CREATE DATABASE eygle
MAXINSTANCES 1
MAXLOGHISTORY...

 这就是sql.bsq文件在数据库创建过程中的作用。知道了这个内容之后，我们可以通过手工修改sql.bsq文件来更改数据库字典对象参数，从而实现特殊要求数据库的创建或测试自定义库。

我们也可以通过修改_init_sql_file参数来重定位sql.bsq文件的位置。

ixora网站上有一篇文章可以参考:
http://www.ixora.com.au/tips/creation/bsq.htm
Itpub上的相关文章:
http://www.itpub.net/199099.html

-The End-

 

]]> http://www.eygle.com/archives/2006/08/createdb_sql_bsq.html http://www.eygle.com/archives/2006/08/createdb_sql_bsq.html Internal Wed, 23 Aug 2006 16:55:28 +0800 备份的控制文件和新的数据文件 继续上一节的介绍：

我们可以想象，如果控制文件是从备份中恢复的，那么数据库在open过程中又将如何呢?

首先备份控制文件，打开数据库，增进检查点: 

[oracle@jumper eygle]$ cp control01.ctl control01.ctl.bak
[oracle@jumper eygle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Fri Aug 11 10:46:05 2006

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  139531744 bytes
Fixed Size                   452064 bytes
Variable Size             121634816 bytes
Database Buffers           16777216 bytes
Redo Buffers                 667648 bytes
Database mounted.
Database opened.
SQL> alter system checkpoint;

System altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

然后恢复旧的控制文件，mount数据库，转储数据文件头:

[oracle@jumper eygle]$ mv control01.ctl control01.ctl.n
[oracle@jumper eygle]$ mv control01.ctl.bak control01.ctl
[oracle@jumper eygle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Fri Aug 11 10:46:50 2006

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to an idle instance.

SQL> startup mount;
ORACLE instance started.

Total System Global Area  139531744 bytes
Fixed Size                   452064 bytes
Variable Size             121634816 bytes
Database Buffers           16777216 bytes
Redo Buffers                 667648 bytes
Database mounted.
SQL> alter session set events 'immediate trace name file_hdrs level 10';

Session altered.

SQL> !

我们看控制文件的信息（选择一个文件）:

DATA FILE #4:
  (name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:61 scn: 0x0000.002acb1e 08/11/2006 10:44:38
 Stop scn: 0x0000.002acb1e 08/11/2006 10:44:38
 Creation Checkpointed at scn:  0x0000.0015078d 06/06/2006 09:41:54

再看数据文件头信息:

 FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=989=0x3dd, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE  rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/11/2006 10:11:26
 status:0x0 root dba:0x00000000 chkpt cnt: 64 ctl cnt:63
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.002acb98 08/11/2006 10:46:24

我们注意到数据文件的chkpt cnt: 64 要大约控制文件的Checkpoint cnt:61，也就是说控制文件是旧的。

此时尝试打开数据库就会出现如下错误:

[oracle@jumper udump]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Fri Aug 11 10:51:20 2006

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/opt/oracle/oradata/eygle/system01.dbf'
ORA-01207: file is more recent than controlfile - old controlfile

Oracle告诉我们，控制文件是旧的。此时我们可以通过重建控制文件或者从旧的数据备份开始恢复。

未完待续...

 

]]> http://www.eygle.com/archives/2006/08/old_controlfile_and_new_datafile.html http://www.eygle.com/archives/2006/08/old_controlfile_and_new_datafile.html Internal Fri, 11 Aug 2006 11:05:54 +0800 关于控制文件与数据文件头信息的说明 为了回答关于《深入浅出Oracle》中的一些疑问，引出本系列文章，讨论链接参考:

http://www.itpub.net/609499.html

在上一讲中，我们说过：当我们使用file_hdrs事件来转储数据文件头信息时，Oracle会转储两部分信息，一部分来自控制文件，一部分来自数据文件，在数据库启动过程中，这两部分信息要用来进行启动验证。

在数据库open的过程中,Oracle要进行检查中包含以下两个过程:

第一次检查数据文件头中的Checkpoint cnt是否与对应控制文件中的Checkpoint cnt一致.
如果相等,进行第二次检查.

第二次检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致如果结束SCN等于开始SCN,则不需要对那个文件进行恢复.

对每个数据文件都完成检查后,打开数据库.同时将每个数据文件的结束SCN设置为无穷大.

通过以下过程我们来进一步说明一下这个内容。

我们来看以下来自控制文件部分(选取一个文件测试): 

DATA FILE #4:
  (name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:58 scn: 0x0000.002ac8ee 08/11/2006 09:48:29
 Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29
 Creation Checkpointed at scn:  0x0000.0015078d 06/06/2006 09:41:54
 thread:0 rba:(0x0.0.0)
................
 aux_file is NOT DEFINED

 这部分中包含的重要信息有:
检查点计数: Checkpoint cnt:58
检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29
数据文件Stop SCN:Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

我们再看来自数据文件头的信息:

 FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=979=0x3d3, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE  rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/10/2006 20:57:53
 status:0x0 root dba:0x00000000 chkpt cnt: 58 ctl cnt:57
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.002ac8ee 08/11/2006 09:48:29
.......................

这部分中包含的重要信息有:
检查点SCN: Checkpointed at scn:  0x0000.002ac8ee 08/11/2006 09:48:29
检查点计数: chkpt cnt: 58 ctl cnt:57

这两者都和控制文件中所记录的一致。如果这两者一致，数据库启动时就能通过验证，启动数据库。

那么如果不一致呢？
Oracle则请求进行恢复。
我们看，从备份中恢复eygle01.dbf文件.
首先第一部分从控制文件中获得的信息是相同的: 

DATA FILE #4:
  (name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:58 scn: 0x0000.002ac8ee 08/11/2006 09:48:29
 Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29
 Creation Checkpointed at scn:  0x0000.0015078d 06/06/2006 09:41:54
...................
 aux_file is NOT DEFINED

检查点计数: Checkpoint cnt:58
检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29
数据文件Stop SCN:Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

而从文件头中获得的备份文件信息则是： 

 FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=973=0x3cd, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE  rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/10/2006 20:57:53
 status:0x0 root dba:0x00000000 chkpt cnt: 53 ctl cnt:52
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.002ac5f9 08/10/2006 20:58:21
...................................

我们看到此时备份文件的信息：
检查点是：Checkpointed at scn:  0x0000.002ac5f9 08/10/2006 20:58:21
检查点计数为:chkpt cnt: 53 ctl cnt:52

这两者不再一致，首先是检查点技术不一致，当前文件的chkpt cnt为53，小于控制文件中记录的58，Oracle可以判断文件是从备份中恢复的，或者文件故障，需要进行介质恢复。

我们看如果此时我们试图打开数据库，则Oracle提示文件需要介质恢复: 

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/opt/oracle/oradata/eygle/eygle01.dbf'

执行恢复: 

SQL> recover datafile 4;
Media recovery complete.

我们看看恢复完成之后，控制文件和数据文件的变化.
首先看控制文件的变化: 

DATA FILE #4:
  (name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:59 scn: 0x0000.002ac8ee 08/11/2006 09:48:29
 Stop scn: 0x0000.002ac8ed 08/11/2006 09:48:29
 Creation Checkpointed at scn:  0x0000.0015078d 06/06/2006 09:41:54
......................

检查点计数: Checkpoint cnt:59
执行了恢复之后，检查点计数较前增加了1

检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29
数据文件Stop scn: 0x0000.002ac8ed 08/11/2006 09:48:29
数据文件Stop scn和数据文件进行了同步。

数据文件头信息: 

 FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=983=0x3d7, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE  rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/11/2006 10:11:26
 status:0x0 root dba:0x00000000 chkpt cnt: 59 ctl cnt:58
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.002ac8ed 08/11/2006 09:48:29
..........................

我们看到此时数据文件的信息：
检查点是：Checkpointed at scn:  0x0000.002ac8ed 08/11/2006 09:48:29
这个检查点和控制文件中记录的stop scn一致，数据库启动可以顺利进行。

检查点计数为:chkpt cnt: 59 ctl cnt:58

我们打开数据库: 

SQL> alter database open;

Database altered.

SQL> alter session set events 'immediate trace name file_hdrs level 10';

Session altered.

此时数据库恢复正常运行。
控制文件信息如下： 

DATA FILE #4:
  (name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:60 scn: 0x0000.002ac8ef 08/11/2006 10:19:30
 Stop scn: 0xffff.ffffffff 08/11/2006 09:48:29
 Creation Checkpointed at scn:  0x0000.0015078d 06/06/2006 09:41:54

 此时stop scn被置为无穷大。
数据文件头信息如下:

 FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=984=0x3d8, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE  rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/11/2006 10:11:26
 status:0x4 root dba:0x00000000 chkpt cnt: 60 ctl cnt:59
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.002ac8ef 08/11/2006 10:19:30

未完待续...

 

]]> http://www.eygle.com/archives/2006/08/event_controlfile_datafile.html http://www.eygle.com/archives/2006/08/event_controlfile_datafile.html Internal Fri, 11 Aug 2006 10:01:16 +0800 EVENT: FILE_HDRS 的信息来源 准备用几篇稿子来记录一下ITPUB上关于数据库Open的一个问题。
具体问题参考ITPUB链接:
http://www.itpub.net/609499.html

我们知道，可以通过一个内部事件来转储数据文件头信息，这个常用的命令是：

alter session set events 'immediate trace name file_hdrs level 10';

那么我们来看一下这个命令得到的trace文件及内容。
immediate关闭数据库，在mount状态下执行该命令: 

SQL> startup mount;
ORACLE instance started.

Total System Global Area  139531744 bytes
Fixed Size                   452064 bytes
Variable Size             121634816 bytes
Database Buffers           16777216 bytes
Redo Buffers                 667648 bytes
Database mounted.
SQL> alter session set events 'immediate trace name file_hdrs level 10';

Session altered.

选取一个文件的信息,这里选择eygle01.dbf文件，我们注意，以下就是trace文件摘录的信息:

DATA FILE #4:
  (name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:53 scn: 0x0000.002ac5f9 08/10/2006 20:58:21
 Stop scn: 0x0000.002ac5f9 08/10/2006 20:58:21
 Creation Checkpointed at scn:  0x0000.0015078d 06/06/2006 09:41:54
 thread:0 rba:(0x0.0.0)
 enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
 Offline scn: 0x0000.00000000 prev_range: 0
 Online Checkpointed at scn:  0x0000.00000000
 thread:0 rba:(0x0.0.0)
 enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
 Hot Backup end marker scn: 0x0000.00000000
 aux_file is NOT DEFINED
 FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=1407686520=0x53e79778, Db Name='EYGLE'
        Activation ID=0=0x0
        Control Seq=973=0x3cd, File size=1280=0x500
        File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - EYGLE  rel_fn:4
Creation   at   scn: 0x0000.0015078d 06/06/2006 09:41:54
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/10/2006 20:57:53
 status:0x0 root dba:0x00000000 chkpt cnt: 53 ctl cnt:52
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.002ac5f9 08/10/2006 20:58:21
 thread:1 rba:(0x35.1275.10)
 enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
Backup Checkpointed at scn:  0x0000.00000000
 thread:0 rba:(0x0.0.0)
 enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0000.00000000
Recovery fuzzy scn: 0x0000.00000000 08/10/2006 10:46:03
Terminal Recovery Stamp scn: 0x0000.00000000 01/01/1988 00:00:00

注意，这其中"FILE HEADER"开始的信息就是来自数据文件头，之前的相关内容来自控制文件。

我们可以在mount状态下将eygle01.dbf文件移除:

[oracle@jumper eygle]$ mv eygle01.dbf eygle01.dbf.n
[oracle@jumper eygle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Thu Aug 10 21:44:10 2006

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> alter session set events 'immediate trace name file_hdrs level 10';

Session altered.

SQL> !

则"FILE HEADER"部分信息将无法获得。

DATA FILE #4:
  (name #4) /opt/oracle/oradata/eygle/eygle01.dbf
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
 tablespace 4, index=4 krfil=4 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:53 scn: 0x0000.002ac5f9 08/10/2006 20:58:21
 Stop scn: 0x0000.002ac5f9 08/10/2006 20:58:21
 Creation Checkpointed at scn:  0x0000.0015078d 06/06/2006 09:41:54
 thread:0 rba:(0x0.0.0)
 enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
 Offline scn: 0x0000.00000000 prev_range: 0
 Online Checkpointed at scn:  0x0000.00000000
 thread:0 rba:(0x0.0.0)
 enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000
 Hot Backup end marker scn: 0x0000.00000000
 aux_file is NOT DEFINED
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: '/opt/oracle/oradata/eygle/eygle01.dbf'
*** Error 1157 in open/read file # 4 ***
DUMP OF TEMP FILES: 0 files in database

此时报出的错误是，文件无法找到，也就是说当我们执行trace file_hdrs时需要读取数据文件头，获得相关信息。

]]> http://www.eygle.com/archives/2006/08/event_file_hdrs.html http://www.eygle.com/archives/2006/08/event_file_hdrs.html Internal Thu, 10 Aug 2006 21:59:07 +0800 Oracle9iR2 NF:压缩表技术 上周了解了一下IBM的压缩技术,打算对比一下Oracle的表压缩技术做点研究,先讨论一下Oracle的表压缩技术.

从Oracle9iR2开始，Oracle推出了压缩表技术（table compression），用于压缩数据表中的重复数据，以节省存储空间，压缩技术倾向于在数据仓库中使用。

压缩在数据块级生效，当数据表定义为压缩时，数据库在每个数据块上保留空间存储重复数据的单个拷贝，保留空间被称为符号表（symbol table）。此后在具体行上不必再存储这些重复数据，只需要存放指向符号表相应数据的指针，存储空间因此得以节省。

关于压缩表的基本介绍，参考OTN上的文档:
http://www.oracle.com/technology/oramag/oracle/04-mar/o24tech_data.html

我们看一下简单的测试:

[oracle@jumper oracle]$ sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Mon Jun 26 16:07:24 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> create table test (c1 varchar2(20),c2 varchar2(20));

Table created.

SQL> begin
2 for i in 1 .. 10000 loop
3 insert into test values('eygle','test');
4 end loop;
5 end;
6 /

PL/SQL procedure successfully completed.

SQL> create table test_compress compress as select * from test;

Table created.

SQL> select table_name,COMPRESSION from user_tables where table_name like 'TEST%';

TABLE_NAME COMPRESS
------------------------------ --------
TEST DISABLED
TEST_COMPRESS ENABLED

SQL> analyze table test compute statistics;

Table analyzed.

SQL> analyze table test_compress compute statistics;

Table analyzed.

我们看一下两个表的空间使用情况:

SQL> select table_name,blocks,EMPTY_BLOCKS from user_tables
2 where table_name like 'TEST%';

TABLE_NAME BLOCKS EMPTY_BLOCKS
------------------------------ ---------- ------------
TEST 28 4
TEST_COMPRESS 18 6

SQL> select (28-4)/(18-6) from dual;

(28-4)/(18-6)
-------------
2

我们看到，压缩表只使用了常规表一半的空间。

我们转储一下数据块，看一下压缩表的存储结构：

SQL> select segment_name,file_id,block_id,blocks from dba_extents
2 where segment_name='TEST_COMPRESS';

SEGMENT_NAME FILE_ID BLOCK_ID BLOCKS
-------------------- ---------- ---------- ----------
TEST_COMPRESS 3 17 8
TEST_COMPRESS 3 25 8
TEST_COMPRESS 3 33 8

SQL> alter system dump datafile 3 block 20;

System altered.

找到跟踪文件：

SQL> @gettrcname.sql

TRACE_FILE_NAME
-------------------------------------------------------------------
/opt/oracle/admin/eygle/udump/eygle_ora_20984.trc

查看内容，首先看一下块头信息:

data_block_dump,data header at 0xaa84e7c
===============
tsiz: 0x1f80
hsiz: 0x5d2
pbl: 0x0aa84e7c
bdba: 0x00c00014
76543210
flag=-0------
ntab=2
nrow=727
frre=-1
fsbo=0x5d2
fseo=0x1144
avsp=0x1a
tosp=0x1a
r0_9ir2=0x0
mec_kdbh9ir2=0x1
r1_9ir2=0x0
76543210
flag_9ir2=-------C
fcls_9ir2[3]={ 0 32768 32768 }
0x1c:pti[0] nrow=1 offs=0
0x20:pti[1] nrow=726 offs=1
0x24:pri[0] offs=0x1f72
0x26:pri[1] offs=0x1f6d
我们看到这个Block中的ntab =2 也就是存在2张表，从下面可以找到table 0的信息:
tab 0, row 0, @0x1f72
tl: 14 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 5] 65 79 67 6c 65
col 1: [ 4] 74 65 73 74
bindmp: 02 d6 02 cd 65 79 67 6c 65 cc 74 65 73 74

这个table 0只有一条记录，就是我们之前所说的符号表。

此后的记录才是真实数据，每条数据记录包含一个指针，指向符号表：

tab 1, row 0, @0x1f6d
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 5] 65 79 67 6c 65
col 1: [ 4] 74 65 73 74
bindmp: 2c 00 01 02 00
tab 1, row 1, @0x1f68
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 5] 65 79 67 6c 65
col 1: [ 4] 74 65 73 74
bindmp: 2c 00 01 02 00

这里的bindmp就是指针。

关于压缩表存储结构的进一步探讨可以参考:

biti_rainy 的 关于 9iR2 的 compress table 的研究
http://www.itpub.net/showthread.php?threadid=197403

fuyuncat 的 数据段压缩（Data Segment Compression）浅析
http://fuyuncat.itpub.net/post/5203/45991

压缩表显然是通过CPU换取存储，存储的缩减必然导致存储和查询时压缩和解压缩的CPU消耗。
但是，I/O操作得以节约，我们看一下对以上2个表执行全表扫描的比较：

SQL> set autotrace on
SQL> select count(*) from test;

COUNT(*)
----------
10000

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'TEST' (Cost=4 Card=10000)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
31 consistent gets
0 physical reads
0 redo size
379 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

SQL> select count(*) from test_compress;
COUNT(*)
----------
10000


Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'TEST_COMPRESS' (Cost=3 Card=10000)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
17 consistent gets
0 physical reads
0 redo size
379 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

压缩表的一致性读只有17，较常规表的31大大减少。

压缩表是为数据仓库设计的特性，所以并不适合OLTP系统，在发生更新时，压缩表会因行链接而迅速扩展空间使用。
请看简单测试:

SQL> update test_compress set c1='oracle' where rownum <10;

9 rows updated.

SQL> commit;

Commit complete.

SQL> analyze table test_compress compute statistics;

Table analyzed.

SQL> select table_name,blocks,EMPTY_BLOCKS from user_tables
2 where table_name like 'TEST%';

TABLE_NAME BLOCKS EMPTY_BLOCKS
------------------------------ ---------- ------------
TEST 28 4
TEST_COMPRESS 24 0

具体可以参考wanghai 的文章: compress table
http://wzwanghai.spaces.msn.com/blog/cns!56626E237AFBD116!206.entry

 

]]> http://www.eygle.com/archives/2006/06/oracle9ir2_nf_table_compress.html http://www.eygle.com/archives/2006/06/oracle9ir2_nf_table_compress.html Internal Mon, 26 Jun 2006 15:27:46 +0800 隐含参数_disable_logging的几点说明 在很久以前,曾经介绍过Oracle的一个内部隐含参数_disable_logging,看到有朋友论述这个参数,今天忍不住做一点补充说明.

1.当然,隐含有风险,设置请谨慎.

2.最初在9.2.0.6 Solaris版本上,设置该参数会触发Bug:3868748 使得数据库无法启动.

从警告日志中,通常可以获得的错误提示是:

ORA-07445: exception encountered:
core dump [kcrfwcint()+1625] [SIGFPE] [Integer divide by zero] [0x828739D] [] []

但是好在这个参数是动态的,在存在Bug版本中,我们可以修改数据库当前值来进行测试:

SQL> alter system set "_disable_logging"=true scope=memory;

System altered.

3.这个Bug的影响范围并非全部,9.2.0.6之下,Oracle9.2.0.5,Oracle9.2.0.4等,都不受这个Bug影响.Oracle声称的修正该Bug的版本是Oracle10gR2(我未验正).

4.这个参数在Oracle9.2.0.4版本的Linux/Solaris上是不存在这个Bug的.在我的环境中经过验证,过程请参考(附注1).

5.在归档模式下,设置该参数会导致日志文件损坏.因为在设置该参数与归档原则违背，归档进程无法识别该日志文件格式，会将该日志文件标记为损坏.所以需要谨慎测试,具体请参考(附注2).

附注1:Solaris Oracle9.2.0.4设置测试过程:

$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Thu Apr 13 22:51:24 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> show parameter disa

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_disable_logging boolean FALSE
SQL> alter system set "_disable_logging"=true scope=both;

System altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area 286755168 bytes
Fixed Size 731488 bytes
Variable Size 167772160 bytes
Database Buffers 117440512 bytes
Redo Buffers 811008 bytes
Database mounted.
Database opened.
SQL> show parameter disable

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_disable_logging boolean TRUE
SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Solaris: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production

附注2:归档模式下,该参数会导致日志文件损坏.

设置该参数后,切换日志:

SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /opt/oracle/oradata/conner/archive
Oldest online log sequence 20
Next log sequence to archive 23
Current log sequence 23
SQL> alter system switch logfile;

System altered.

SQL> select group#,status from v$Log;

GROUP# STATUS
---------- ----------------
1 INACTIVE
2 ACTIVE
3 INACTIVE
4 CURRENT

SQL> show parameter disable

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_disable_logging boolean TRUE

此时可以在警告日志中看到日志损坏的错误信息:

Thu Apr 13 23:33:25 2006
ARC0: Evaluating archive log 2 thread 1 sequence 23
ARC0: Beginning to archive log 2 thread 1 sequence 23
Creating archive destination LOG_ARCHIVE_DEST_1: '/opt/oracle/oradata/conner/archive/1_23.dbf'
ARC0: Log corruption near block 3849 change 0 time ?
ARC0: All Archive destinations made inactive due to error 354
Thu Apr 13 23:33:25 2006
Errors in file /opt/oracle/admin/conner/bdump/conner_arc0_21506.trc:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 3849 change 0 time 04/13/2006 21:13:03
ORA-00312: online log 2 thread 1: '/opt/oracle/oradata/conner/redo02.log'
ARC0: Archiving not possible: error count exceeded
ARC0: Failed to archive log 2 thread 1 sequence 23
ARCH: Archival stopped, error occurred. Will continue retrying
Thu Apr 13 23:33:26 2006
ORACLE Instance conner - Archival Error
ARCH: Connecting to console port...
Thu Apr 13 23:33:26 2006
ORA-16038: log 2 sequence# 23 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 2 thread 1: '/opt/oracle/oradata/conner/redo02.log'
ARCH: Connecting to console port...
ARCH:
Thu Apr 13 23:33:26 2006
ORA-16038: log 2 sequence# 23 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 2 thread 1: '/opt/oracle/oradata/conner/redo02.log'
]]> http://www.eygle.com/archives/2006/06/more_about_disable_logging.html http://www.eygle.com/archives/2006/06/more_about_disable_logging.html Internal Tue, 20 Jun 2006 11:27:41 +0800 时间再次停止运行 今天下班时,同事说,一个数据库上的Job进程不能启动,我登陆上去查看,果然,时间再次停止运行:

SQL> select * from v$timer;

HSECS
----------
4294967295

SQL> /

HSECS
----------
4294967295

此前曾经遭遇这个Bug,当主机持续运行497 days 2 hrs 28 mins 时,数据库系统时间将会停止.

Bug出现:

$ uptime
6:27pm up 497 day(s), 14:35, 6 users, load average: 0.43, 1.21, 2.19

这个Bug真是恼人,除了重起主机之外,别无办法.看来虽然9.2.0.4这个版本比较稳定,但是仍然需要考虑升级了.

此Bug在Oracle9.2.0.6中被修正.

在我的Oracle10g环境中,可以看到这个问题已经不再存在.

v$timer计时在溢出后会重新计算:

SQL*Plus: Release 10.1.0.3.0 - Production on Tue Jun 20 10:21:35 2006

Copyright (c) 1982, 2004, Oracle. All rights reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - 64bit Production
With the Partitioning and Data Mining options

SQL> select * from v$timer;

HSECS
----------
68297932

SQL> ! uptime
10:23am up 504 day(s), 23:31, 1 user, load average: 3.43, 3.37, 2.95

我们看到,Solaris系统的稳定性还是值得信赖的:)

 

]]> http://www.eygle.com/archives/2006/06/time_stop_again.html http://www.eygle.com/archives/2006/06/time_stop_again.html Internal Fri, 16 Jun 2006 09:38:20 +0800 Oracle热备期间的过量Redo生成控制 我们都知道为了防止热备期间的分裂块问题,Oracle在热备过程中会对修改块进行全块的Redo记录.

偶然发现居然还存在一个隐含参数可以控制这个行为:

SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ
2 FROM SYS.x$ksppi x, SYS.x$ksppcv y
3 WHERE x.inst_id = USERENV ('Instance')
4 AND y.inst_id = USERENV ('Instance')
5 AND x.indx = y.indx
6 AND x.ksppinm LIKE '%&par%'
7 /
Enter value for par: blocks
old 6: AND x.ksppinm LIKE '%&par%'
new 6: AND x.ksppinm LIKE '%blocks%'

NAME VALUE DESCRIB
------------------------------ -------------------- -------------------------------------------
_log_blocks_during_backup TRUE log block images when changed during backup

这个参数缺省值为TRUE，设置在热备份期间允许在redo中记录数据块信息，如果数据库块大小等于操作系统块大小，则可以设置该参数为False，减少热备期间数据库的负担（这种情况极为少见）。

]]> http://www.eygle.com/archives/2006/05/oracle_hotbackup_redo.html http://www.eygle.com/archives/2006/05/oracle_hotbackup_redo.html Internal Wed, 31 May 2006 08:54:51 +0800 使用10203事件跟踪Oracle块清除 Oracle的10203事件可以用来跟踪数据库的块清除（cleanout）操作,从事件列表中，我们可以知道该时间的含义为：block cleanout 。

该事件需要在系统级设置，重启数据库后生效：

SQL> alter system set event="10203 trace name context forever" scope=spfile;

System altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  126948772 bytes
Fixed Size                   452004 bytes
Variable Size              92274688 bytes
Database Buffers           33554432 bytes
Redo Buffers                 667648 bytes
Database mounted.
Database opened.

SQL> show parameter event

NAME                                 TYPE        VALUE
------------------------------------ ----------- --------------------------------
event                                string      10203 trace name context forever

在跟踪文件中，我们可以发现类似如下的block cleanout 信息：

Begin cleaning out block ...
Found all committed transactions
Block cleanout record, scn:  0xffff.ffffffff ver: 0x01 opt: 0x02, entries follow...
  itli: 1  flg: 2  scn: 0x0819.0045cd54
Block cleanout under the cache...
Block cleanout record, scn:  0x0819.0045cea1 ver: 0x01 opt: 0x02, entries follow...
  itli: 1  flg: 2  scn: 0x0819.0045cd54
... clean out dump complete.

 

]]> http://www.eygle.com/archives/2006/04/event_10203_cleanout.html http://www.eygle.com/archives/2006/04/event_10203_cleanout.html Internal Thu, 20 Apr 2006 17:04:22 +0800 _disable_logging如何禁用日志 在非归档模式下(归档模式会导致日志损坏),使用_disable_logging可以禁止日志的生成,从而可以提高某些特殊操作(如批量加载或Benchmark测试等)的性能.

我们可以来看一下这个禁止是如何完成的.

启动2个Session,一个用于管理,一个用于测试.

1.Session 1 ,使用SYS用户连接数据库,当前_disable_logging未设置,数据库处于正常状态

$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Fri Apr 14 09:30:42 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> col member for a40
SQL> select * from v$logfile;

GROUP# STATUS TYPE MEMBER
---------- ------- ------- ----------------------------------------
1 ONLINE /opt/oracle9/oradata/testora9/redo01.log
2 ONLINE /opt/oracle9/oradata/testora9/redo02.log
3 ONLINE /opt/oracle9/oradata/testora9/redo03.log

SQL> alter system switch logfile;

System altered.

SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 148 104857600 1 NO CURRENT 262708457 14-APR-06
2 1 146 104857600 1 NO INACTIVE 262662667 14-APR-06
3 1 147 104857600 1 NO ACTIVE 262675537 14-APR-06

2.Session2通过SCOTT用户连接,执行如下更新:

SQL> connect scott/tiger
Connected.

SQL> update emp set sal=3000 where empno=7788;

1 row updated.

SQL> commit;

Commit complete.

3.在Session转储REDO日志

SQL> ALTER SYSTEM DUMP LOGFILE '/opt/oracle9/oradata/testora9/redo01.log';

System altered.

4.观察跟踪文件,记录正常状态下的REDO信息

$ ls
testora9_ora_16037.trc
$ cat *
/opt/oracle9/admin/testora9/udump/testora9_ora_16037.trc
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
ORACLE_HOME = /opt/oracle9/product/9.2.0
System name: SunOS
Node name: testdbserver.hurray.com.cn
Release: 5.8
Version: Generic_108528-25
Machine: sun4u
Instance name: testora9
Redo thread mounted by this instance: 1
Oracle process number: 15
Unix process pid: 16037, image: oracle@testdbserver.hurray.com.cn (TNS V1-V3)

*** 2006-04-14 09:32:01.356
*** SESSION ID:(17.3524) 2006-04-14 09:32:01.340

DUMP OF REDO FROM FILE '/opt/oracle9/oradata/testora9/redo01.log'
Opcodes *.*
DBA's: (file # 0, block # 0) thru (file # 65534, block # 4194303)
RBA's: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCN's scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
Times: creation thru eternity
FILE HEADER:
Software vsn=153092096=0x9200000, Compatibility Vsn=153092096=0x9200000
Db ID=1628068176=0x610a5950, Db Name='TESTORA9'
Activation ID=1628067152=0x610a5550
Control Seq=1161=0x489, File size=204800=0x32000
File Number=1, Blksiz=512, File Type=2 LOG
descrip:"Thread 0001, Seq# 0000000148, SCN 0x00000fa89ce9-0xffffffffffff"
thread: 1 nab: 0xffffffff seq: 0x00000094 hws: 0x1 eot: 1 dis: 0
reset logs count: 0x1f435110 scn: 0x0000.00000001
Low scn: 0x0000.0fa89ce9 04/14/2006 09:31:06
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
Enabled scn: 0x0000.00000001 04/26/2004 15:56:10
Thread closed scn: 0x0000.0fa89ce9 04/14/2006 09:31:06
Log format vsn: 0x8000000 Disk cksum: 0x9930 Calc cksum: 0x9930
Terminal Recovery Stamp scn: 0x0000.00000000 01/01/1988 00:00:00
Most recent redo scn: 0x0000.00000000
Largest LWN: 0 blocks
End-of-redo stream : No
Unprotected mode
Miscellaneous flags: 0x0

REDO RECORD - Thread:1 RBA: 0x000094.00000002.0010 LEN: 0x01b0 VLD: 0x01
SCN: 0x0000.0fa89cf0 SUBSCN: 1 04/14/2006 09:31:30
CHANGE #1 TYP:0 CLS:33 AFN:2 DBA:0x00800089 SCN:0x0000.0fa89cca SEQ: 1 OP:5.2
ktudh redo: slt: 0x000f sqn: 0x00009c89 flg: 0x000a siz: 132 fbi: 0
uba: 0x00800559.0352.01 pxid: 0x0000.000.00000000
CHANGE #2 TYP:1 CLS:34 AFN:2 DBA:0x00800559 SCN:0x0000.0fa89cf0 SEQ: 1 OP:5.1
ktudb redo: siz: 132 spc: 0 flg: 0x000a seq: 0x0352 rec: 0x01
xid: 0x0009.00f.00009c89
ktubl redo: slt: 15 rci: 0 opc: 11.1 objn: 30359 objd: 30359 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00800558.0352.57
prev ctl max cmt scn: 0x0000.0fa89887 prev tx cmt scn: 0x0000.0fa8988b
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0005.01e.00009810 uba: 0x00800615.032f.26
flg: C--- lkc: 0 scn: 0x0000.0f92af59
KDO Op code: URP row dependencies Disabled
xtype: XA bdba: 0x0040a482 hdba: 0x0040a481
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 7(0x7) flag: 0x2c lock: 0 ckix: 0
ncol: 8 nnew: 1 size: 0
col 5: [ 2] c2 29
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x0040a482 SCN:0x0000.0f92ced1 SEQ: 1 OP:11.5
KTB Redo
op: 0x11 ver: 0x01
op: F xid: 0x0009.00f.00009c89 uba: 0x00800559.0352.01
Block cleanout record, scn: 0x0000.0fa89cf0 ver: 0x01 opt: 0x02, entries follow...
itli: 2 flg: 2 scn: 0x0000.0f92ced1
KDO Op code: URP row dependencies Disabled
xtype: XA bdba: 0x0040a482 hdba: 0x0040a481
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 7(0x7) flag: 0x2c lock: 1 ckix: 0
ncol: 8 nnew: 1 size: 0
col 5: [ 2] c2 1f
CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
session number = 16
serial number = 651
transaction name =

REDO RECORD - Thread:1 RBA: 0x000094.00000002.01c0 LEN: 0x0054 VLD: 0x01
SCN: 0x0000.0fa89cf1 SUBSCN: 1 04/14/2006 09:31:30
CHANGE #1 TYP:0 CLS:33 AFN:2 DBA:0x00800089 SCN:0x0000.0fa89cf0 SEQ: 1 OP:5.4
ktucm redo: slt: 0x000f sqn: 0x00009c89 srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x00800559.0352.01 ext: 2 spc: 8016 fbi: 0

REDO RECORD - Thread:1 RBA: 0x000094.00000004.0010 LEN: 0x01f4 VLD: 0x01
SCN: 0x0000.0fa89cf2 SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:21 AFN:2 DBA:0x00800029 SCN:0x0000.0fa89ccc SEQ: 1 OP:5.2
ktudh redo: slt: 0x001b sqn: 0x00009c9b flg: 0x0012 siz: 108 fbi: 0
uba: 0x0080046b.0345.40 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:22 AFN:2 DBA:0x0080046b SCN:0x0000.0fa89ccb SEQ: 1 OP:5.1
ktudb redo: siz: 108 spc: 2908 flg: 0x0012 seq: 0x0345 rec: 0x40
xid: 0x0003.01b.00009c9b
ktubl redo: slt: 27 rci: 0 opc: 11.1 objn: 3643 objd: 3643 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x0080046b.0345.3f
prev ctl max cmt scn: 0x0000.0fa89888 prev tx cmt scn: 0x0000.0fa8988d
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0002.021.0000a088 uba: 0x0080091e.0714.47
flg: C--- lkc: 0 scn: 0x0000.0fa89ce0
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f7a hdba: 0x00401f79
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 0 to: 0
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x00401f7a SCN:0x0000.0fa89ce3 SEQ: 1 OP:11.4
KTB Redo
op: 0x11 ver: 0x01
op: F xid: 0x0003.01b.00009c9b uba: 0x0080046b.0345.40
Block cleanout record, scn: 0x0000.0fa89cf2 ver: 0x01 opt: 0x02, entries follow...
itli: 1 flg: 2 scn: 0x0000.0fa89ce0
itli: 2 flg: 2 scn: 0x0000.0fa89ce3
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f7a hdba: 0x00401f79
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 0 to: 1
CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.19
session number = 8
serial number = 1
current username = SYS
login username =
client info =
OS username = oracle9
Machine name = testdbserver.hurray.com.cn
OS terminal = UNKNOWN
OS process id = 2053
OS program name = oracle@testdbserver.hurray.com.cn (QMN0)
transaction name =

REDO RECORD - Thread:1 RBA: 0x000094.00000005.0014 LEN: 0x00dc VLD: 0x01
SCN: 0x0000.0fa89cf2 SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:22 AFN:2 DBA:0x0080046b SCN:0x0000.0fa89cf2 SEQ: 1 OP:5.1
ktudb redo: siz: 84 spc: 2798 flg: 0x0022 seq: 0x0345 rec: 0x41
xid: 0x0003.01b.00009c9b
ktubu redo: slt: 27 rci: 64 opc: 11.1 objn: 3635 objd: 3635 tsn: 0
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0008.01b.00009c85 uba: 0x008007a3.037e.0b
flg: C--- lkc: 0 scn: 0x0000.0fa89ce3
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 0 to: 0
CHANGE #2 TYP:2 CLS: 1 AFN:1 DBA:0x00401f3a SCN:0x0000.0fa89ce5 SEQ: 1 OP:11.4
KTB Redo
op: 0x01 ver: 0x01
op: F xid: 0x0003.01b.00009c9b uba: 0x0080046b.0345.41
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 0 to: 1

REDO RECORD - Thread:1 RBA: 0x000094.00000005.00f0 LEN: 0x0054 VLD: 0x01
SCN: 0x0000.0fa89cf3 SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:21 AFN:2 DBA:0x00800029 SCN:0x0000.0fa89cf2 SEQ: 1 OP:5.4
ktucm redo: slt: 0x001b sqn: 0x00009c9b srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x0080046b.0345.41 ext: 2 spc: 2712 fbi: 0

REDO RECORD - Thread:1 RBA: 0x000094.00000006.0010 LEN: 0x0188 VLD: 0x01
SCN: 0x0000.0fa89cf5 SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:27 AFN:2 DBA:0x00800059 SCN:0x0000.0fa89ccd SEQ: 1 OP:5.2
ktudh redo: slt: 0x0020 sqn: 0x00009c72 flg: 0x0012 siz: 108 fbi: 0
uba: 0x0080027b.0352.1d pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:28 AFN:2 DBA:0x0080027b SCN:0x0000.0fa89ccc SEQ: 1 OP:5.1
ktudb redo: siz: 108 spc: 5718 flg: 0x0012 seq: 0x0352 rec: 0x1d
xid: 0x0006.020.00009c72
ktubl redo: slt: 32 rci: 0 opc: 11.1 objn: 3635 objd: 3635 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x0080027b.0352.1c
prev ctl max cmt scn: 0x0000.0fa8988a prev tx cmt scn: 0x0000.0fa8988e
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0002.01a.0000a089 uba: 0x0080091e.0714.49
flg: C--- lkc: 0 scn: 0x0000.0fa89ce5
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 0 to: 0
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x00401f3a SCN:0x0000.0fa89cf3 SEQ: 1 OP:11.4
KTB Redo
op: 0x11 ver: 0x01
op: F xid: 0x0006.020.00009c72 uba: 0x0080027b.0352.1d
Block cleanout record, scn: 0x0000.0fa89cf5 ver: 0x01 opt: 0x02, entries follow...
itli: 1 flg: 2 scn: 0x0000.0fa89cf3
itli: 2 flg: 2 scn: 0x0000.0fa89ce5
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 0 to: 2
CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
session number = 8
serial number = 1
transaction name =

REDO RECORD - Thread:1 RBA: 0x000094.00000006.0198 LEN: 0x0054 VLD: 0x01
SCN: 0x0000.0fa89cf6 SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:27 AFN:2 DBA:0x00800059 SCN:0x0000.0fa89cf5 SEQ: 1 OP:5.4
ktucm redo: slt: 0x0020 sqn: 0x00009c72 srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x0080027b.0352.1d ext: 2 spc: 5608 fbi: 0

REDO RECORD - Thread:1 RBA: 0x000094.00000007.0010 LEN: 0x00d4 VLD: 0x01
SCN: 0x0000.0fa89cf7 SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:33 AFN:2 DBA:0x00800089 SCN:0x0000.0fa89cf1 SEQ: 1 OP:5.2
ktudh redo: slt: 0x0027 sqn: 0x00009c88 flg: 0x0011 siz: 52 fbi: 0
uba: 0x00800559.0352.02 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:34 AFN:2 DBA:0x00800559 SCN:0x0000.0fa89cf0 SEQ: 2 OP:5.1
ktudb redo: siz: 52 spc: 8016 flg: 0x0012 seq: 0x0352 rec: 0x02
xid: 0x0009.027.00009c88
ktubl redo: slt: 39 rci: 0 opc: 5.7 objn: 0 objd: 0 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00800559.0352.01
prev ctl max cmt scn: 0x0000.0fa8988b prev tx cmt scn: 0x0000.0fa89894
CHANGE #3 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
session number = 8
serial number = 1
transaction name =

REDO RECORD - Thread:1 RBA: 0x000094.00000007.00e4 LEN: 0x0118 VLD: 0x01
SCN: 0x0000.0fa89cf8 SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:33 AFN:2 DBA:0x00800089 SCN:0x0000.0fa89cf7 SEQ: 1 OP:5.2
ktudh redo: slt: 0x0027 sqn: 0x00000000 flg: 0x0002 siz: 84 fbi: 0
uba: 0x00800559.0352.03 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:34 AFN:2 DBA:0x00800559 SCN:0x0000.0fa89cf7 SEQ: 1 OP:5.1
ktudb redo: siz: 84 spc: 7962 flg: 0x0022 seq: 0x0352 rec: 0x03
xid: 0x0009.027.00009c88
ktubu redo: slt: 39 rci: 0 opc: 11.1 objn: 3643 objd: 3643 tsn: 0
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0008.01b.00009c85 uba: 0x008007a3.037e.0a
flg: C--- lkc: 0 scn: 0x0000.0fa89ce3
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f7a hdba: 0x00401f79
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 1 to: 0
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x00401f7a SCN:0x0000.0fa89cf3 SEQ: 1 OP:11.4
KTB Redo
op: 0x01 ver: 0x01
op: F xid: 0x0009.027.00009c88 uba: 0x00800559.0352.03
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f7a hdba: 0x00401f79
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 1 to: 2

REDO RECORD - Thread:1 RBA: 0x000094.00000008.0010 LEN: 0x00dc VLD: 0x01
SCN: 0x0000.0fa89cf8 SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:34 AFN:2 DBA:0x00800559 SCN:0x0000.0fa89cf8 SEQ: 1 OP:5.1
ktudb redo: siz: 84 spc: 7876 flg: 0x0022 seq: 0x0352 rec: 0x04
xid: 0x0009.027.00009c88
ktubu redo: slt: 39 rci: 3 opc: 11.1 objn: 3635 objd: 3635 tsn: 0
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0003.01b.00009c9b uba: 0x0080046b.0345.41
flg: C--- lkc: 0 scn: 0x0000.0fa89cf3
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 1 to: 0
CHANGE #2 TYP:2 CLS: 1 AFN:1 DBA:0x00401f3a SCN:0x0000.0fa89cf6 SEQ: 1 OP:11.4
KTB Redo
op: 0x01 ver: 0x01
op: F xid: 0x0009.027.00009c88 uba: 0x00800559.0352.04
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 1 to: 1

REDO RECORD - Thread:1 RBA: 0x000094.00000008.00ec LEN: 0x0054 VLD: 0x01
SCN: 0x0000.0fa89cf9 SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:33 AFN:2 DBA:0x00800089 SCN:0x0000.0fa89cf8 SEQ: 1 OP:5.4
ktucm redo: slt: 0x0027 sqn: 0x00009c88 srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x00800559.0352.04 ext: 2 spc: 7790 fbi: 0

REDO RECORD - Thread:1 RBA: 0x000094.00000008.0140 LEN: 0x0188 VLD: 0x01
SCN: 0x0000.0fa89cfa SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:21 AFN:2 DBA:0x00800029 SCN:0x0000.0fa89cf3 SEQ: 1 OP:5.2
ktudh redo: slt: 0x001a sqn: 0x00009c9b flg: 0x0012 siz: 108 fbi: 0
uba: 0x0080046b.0345.42 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:22 AFN:2 DBA:0x0080046b SCN:0x0000.0fa89cf2 SEQ: 2 OP:5.1
ktudb redo: siz: 108 spc: 2712 flg: 0x0012 seq: 0x0345 rec: 0x42
xid: 0x0003.01a.00009c9b
ktubl redo: slt: 26 rci: 0 opc: 11.1 objn: 3635 objd: 3635 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x0080046b.0345.40
prev ctl max cmt scn: 0x0000.0fa8988d prev tx cmt scn: 0x0000.0fa898e6
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0006.020.00009c72 uba: 0x0080027b.0352.1d
flg: C--- lkc: 0 scn: 0x0000.0fa89cf6
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 1 to: 0
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x00401f3a SCN:0x0000.0fa89cf9 SEQ: 1 OP:11.4
KTB Redo
op: 0x11 ver: 0x01
op: F xid: 0x0003.01a.00009c9b uba: 0x0080046b.0345.42
Block cleanout record, scn: 0x0000.0fa89cfa ver: 0x01 opt: 0x02, entries follow...
itli: 1 flg: 2 scn: 0x0000.0fa89cf9
itli: 2 flg: 2 scn: 0x0000.0fa89cf6
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 1 to: 2
CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
session number = 8
serial number = 1
transaction name =

REDO RECORD - Thread:1 RBA: 0x000094.00000009.00d8 LEN: 0x0054 VLD: 0x01
SCN: 0x0000.0fa89cfb SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:21 AFN:2 DBA:0x00800029 SCN:0x0000.0fa89cfa SEQ: 1 OP:5.4
ktucm redo: slt: 0x001a sqn: 0x00009c9b srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x0080046b.0345.42 ext: 2 spc: 2602 fbi: 0

REDO RECORD - Thread:1 RBA: 0x000094.00000009.012c LEN: 0x00d4 VLD: 0x01
SCN: 0x0000.0fa89cfb SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:27 AFN:2 DBA:0x00800059 SCN:0x0000.0fa89cf6 SEQ: 1 OP:5.2
ktudh redo: slt: 0x000c sqn: 0x00009c72 flg: 0x0011 siz: 52 fbi: 0
uba: 0x0080027b.0352.1e pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:28 AFN:2 DBA:0x0080027b SCN:0x0000.0fa89cf5 SEQ: 1 OP:5.1
ktudb redo: siz: 52 spc: 5608 flg: 0x0012 seq: 0x0352 rec: 0x1e
xid: 0x0006.00c.00009c72
ktubl redo: slt: 12 rci: 0 opc: 5.7 objn: 0 objd: 0 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x0080027b.0352.1d
prev ctl max cmt scn: 0x0000.0fa8988e prev tx cmt scn: 0x0000.0fa89902
CHANGE #3 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
session number = 8
serial number = 1
transaction name =

REDO RECORD - Thread:1 RBA: 0x000094.0000000a.0010 LEN: 0x0148 VLD: 0x01
SCN: 0x0000.0fa89cfb SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:27 AFN:2 DBA:0x00800059 SCN:0x0000.0fa89cfb SEQ: 1 OP:5.2
ktudh redo: slt: 0x000c sqn: 0x00000000 flg: 0x0002 siz: 84 fbi: 0
uba: 0x0080027b.0352.1f pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:28 AFN:2 DBA:0x0080027b SCN:0x0000.0fa89cfb SEQ: 1 OP:5.1
ktudb redo: siz: 84 spc: 5554 flg: 0x0022 seq: 0x0352 rec: 0x1f
xid: 0x0006.00c.00009c72
ktubu redo: slt: 12 rci: 0 opc: 11.1 objn: 3643 objd: 3643 tsn: 0
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0003.01b.00009c9b uba: 0x0080046b.0345.40
flg: C--- lkc: 0 scn: 0x0000.0fa89cf3
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f7a hdba: 0x00401f79
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 2 to: 0
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x00401f7a SCN:0x0000.0fa89cf9 SEQ: 1 OP:11.4
KTB Redo
op: 0x11 ver: 0x01
op: F xid: 0x0006.00c.00009c72 uba: 0x0080027b.0352.1f
Block cleanout record, scn: 0x0000.0fa89cfb ver: 0x01 opt: 0x02, entries follow...
itli: 1 flg: 2 scn: 0x0000.0fa89cf3
itli: 2 flg: 2 scn: 0x0000.0fa89cf9
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f7a hdba: 0x00401f79
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 2 to: 1

REDO RECORD - Thread:1 RBA: 0x000094.0000000a.0158 LEN: 0x00dc VLD: 0x01
SCN: 0x0000.0fa89cfb SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:28 AFN:2 DBA:0x0080027b SCN:0x0000.0fa89cfb SEQ: 2 OP:5.1
ktudb redo: siz: 84 spc: 5468 flg: 0x0022 seq: 0x0352 rec: 0x20
xid: 0x0006.00c.00009c72
ktubu redo: slt: 12 rci: 31 opc: 11.1 objn: 3635 objd: 3635 tsn: 0
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0009.027.00009c88 uba: 0x00800559.0352.04
flg: C--- lkc: 0 scn: 0x0000.0fa89cf9
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 2 to: 0
CHANGE #2 TYP:2 CLS: 1 AFN:1 DBA:0x00401f3a SCN:0x0000.0fa89cfb SEQ: 1 OP:11.4
KTB Redo
op: 0x01 ver: 0x01
op: F xid: 0x0006.00c.00009c72 uba: 0x0080027b.0352.20
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 2 to: 1

REDO RECORD - Thread:1 RBA: 0x000094.0000000b.0044 LEN: 0x0054 VLD: 0x01
SCN: 0x0000.0fa89cfc SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:27 AFN:2 DBA:0x00800059 SCN:0x0000.0fa89cfb SEQ: 2 OP:5.4
ktucm redo: slt: 0x000c sqn: 0x00009c72 srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x0080027b.0352.20 ext: 2 spc: 5382 fbi: 0

REDO RECORD - Thread:1 RBA: 0x000094.0000000b.0098 LEN: 0x0188 VLD: 0x01
SCN: 0x0000.0fa89cfd SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:33 AFN:2 DBA:0x00800089 SCN:0x0000.0fa89cf9 SEQ: 1 OP:5.2
ktudh redo: slt: 0x000d sqn: 0x00009c89 flg: 0x0012 siz: 108 fbi: 0
uba: 0x00800559.0352.05 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:34 AFN:2 DBA:0x00800559 SCN:0x0000.0fa89cf8 SEQ: 2 OP:5.1
ktudb redo: siz: 108 spc: 7790 flg: 0x0012 seq: 0x0352 rec: 0x05
xid: 0x0009.00d.00009c89
ktubl redo: slt: 13 rci: 0 opc: 11.1 objn: 3635 objd: 3635 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00800559.0352.02
prev ctl max cmt scn: 0x0000.0fa89894 prev tx cmt scn: 0x0000.0fa89905
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0003.01a.00009c9b uba: 0x0080046b.0345.42
flg: C--- lkc: 0 scn: 0x0000.0fa89cfb
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 2 to: 0
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x00401f3a SCN:0x0000.0fa89cfc SEQ: 1 OP:11.4
KTB Redo
op: 0x11 ver: 0x01
op: F xid: 0x0009.00d.00009c89 uba: 0x00800559.0352.05
Block cleanout record, scn: 0x0000.0fa89cfd ver: 0x01 opt: 0x02, entries follow...
itli: 1 flg: 2 scn: 0x0000.0fa89cfc
itli: 2 flg: 2 scn: 0x0000.0fa89cfb
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 2 to: 2
CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
session number = 8
serial number = 1
transaction name =

REDO RECORD - Thread:1 RBA: 0x000094.0000000c.0030 LEN: 0x0054 VLD: 0x01
SCN: 0x0000.0fa89cfe SUBSCN: 1 04/14/2006 09:31:31
CHANGE #1 TYP:0 CLS:33 AFN:2 DBA:0x00800089 SCN:0x0000.0fa89cfd SEQ: 1 OP:5.4
ktucm redo: slt: 0x000d sqn: 0x00009c89 srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x00800559.0352.05 ext: 2 spc: 7680 fbi: 0

REDO RECORD - Thread:1 RBA: 0x000094.0000000d.0010 LEN: 0x00d4 VLD: 0x01
SCN: 0x0000.0fa89cff SUBSCN: 1 04/14/2006 09:31:37
CHANGE #1 TYP:0 CLS:21 AFN:2 DBA:0x00800029 SCN:0x0000.0fa89cfb SEQ: 1 OP:5.2
ktudh redo: slt: 0x0017 sqn: 0x00009c9c flg: 0x0011 siz: 52 fbi: 0
uba: 0x0080046b.0345.43 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:22 AFN:2 DBA:0x0080046b SCN:0x0000.0fa89cfa SEQ: 1 OP:5.1
ktudb redo: siz: 52 spc: 2602 flg: 0x0012 seq: 0x0345 rec: 0x43
xid: 0x0003.017.00009c9c
ktubl redo: slt: 23 rci: 0 opc: 5.7 objn: 0 objd: 0 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x0080046b.0345.42
prev ctl max cmt scn: 0x0000.0fa898e6 prev tx cmt scn: 0x0000.0fa89907
CHANGE #3 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
session number = 8
serial number = 1
transaction name =

REDO RECORD - Thread:1 RBA: 0x000094.0000000d.00e4 LEN: 0x0118 VLD: 0x01
SCN: 0x0000.0fa89cff SUBSCN: 1 04/14/2006 09:31:37
CHANGE #1 TYP:0 CLS:21 AFN:2 DBA:0x00800029 SCN:0x0000.0fa89cff SEQ: 1 OP:5.2
ktudh redo: slt: 0x0017 sqn: 0x00000000 flg: 0x0002 siz: 84 fbi: 0
uba: 0x0080046b.0345.44 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:22 AFN:2 DBA:0x0080046b SCN:0x0000.0fa89cff SEQ: 1 OP:5.1
ktudb redo: siz: 84 spc: 2548 flg: 0x0022 seq: 0x0345 rec: 0x44
xid: 0x0003.017.00009c9c
ktubu redo: slt: 23 rci: 0 opc: 11.1 objn: 3643 objd: 3643 tsn: 0
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0009.027.00009c88 uba: 0x00800559.0352.03
flg: C--- lkc: 0 scn: 0x0000.0fa89cf9
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f7a hdba: 0x00401f79
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 3 to: 0
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x00401f7a SCN:0x0000.0fa89cfc SEQ: 1 OP:11.4
KTB Redo
op: 0x01 ver: 0x01
op: F xid: 0x0003.017.00009c9c uba: 0x0080046b.0345.44
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f7a hdba: 0x00401f79
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 3 to: 2

REDO RECORD - Thread:1 RBA: 0x000094.0000000e.0010 LEN: 0x00dc VLD: 0x01
SCN: 0x0000.0fa89cff SUBSCN: 1 04/14/2006 09:31:37
CHANGE #1 TYP:0 CLS:22 AFN:2 DBA:0x0080046b SCN:0x0000.0fa89cff SEQ: 2 OP:5.1
ktudb redo: siz: 84 spc: 2462 flg: 0x0022 seq: 0x0345 rec: 0x45
xid: 0x0003.017.00009c9c
ktubu redo: slt: 23 rci: 68 opc: 11.1 objn: 3635 objd: 3635 tsn: 0
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
0x00000000
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0006.00c.00009c72 uba: 0x0080027b.0352.20
flg: C--- lkc: 0 scn: 0x0000.0fa89cfc
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 3 to: 0
CHANGE #2 TYP:2 CLS: 1 AFN:1 DBA:0x00401f3a SCN:0x0000.0fa89cfe SEQ: 1 OP:11.4
KTB Redo
op: 0x01 ver: 0x01
op: F xid: 0x0003.017.00009c9c uba: 0x0080046b.0345.45
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 3 to: 1

REDO RECORD - Thread:1 RBA: 0x000094.0000000e.00ec LEN: 0x0054 VLD: 0x01
SCN: 0x0000.0fa89d00 SUBSCN: 1 04/14/2006 09:31:37
CHANGE #1 TYP:0 CLS:21 AFN:2 DBA:0x00800029 SCN:0x0000.0fa89cff SEQ: 2 OP:5.4
ktucm redo: slt: 0x0017 sqn: 0x00009c9c srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x0080046b.0345.45 ext: 2 spc: 2376 fbi: 0

REDO RECORD - Thread:1 RBA: 0x000094.0000000e.0140 LEN: 0x0188 VLD: 0x01
SCN: 0x0000.0fa89d01 SUBSCN: 1 04/14/2006 09:31:37
CHANGE #1 TYP:0 CLS:27 AFN:2 DBA:0x00800059 SCN:0x0000.0fa89cfc SEQ: 1 OP:5.2
ktudh redo: slt: 0x001f sqn: 0x00009c72 flg: 0x0012 siz: 108 fbi: 0
uba: 0x0080027b.0352.21 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:28 AFN:2 DBA:0x0080027b SCN:0x0000.0fa89cfb SEQ: 3 OP:5.1
ktudb redo: siz: 108 spc: 5382 flg: 0x0012 seq: 0x0352 rec: 0x21
xid: 0x0006.01f.00009c72
ktubl redo: slt: 31 rci: 0 opc: 11.1 objn: 3635 objd: 3635 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x0080027b.0352.1e
prev ctl max cmt scn: 0x0000.0fa89902 prev tx cmt scn: 0x0000.0fa89908
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0009.00d.00009c89 uba: 0x00800559.0352.05
flg: C--- lkc: 0 scn: 0x0000.0fa89cfe
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 3 to: 0
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x00401f3a SCN:0x0000.0fa89d00 SEQ: 1 OP:11.4
KTB Redo
op: 0x11 ver: 0x01
op: F xid: 0x0006.01f.00009c72 uba: 0x0080027b.0352.21
Block cleanout record, scn: 0x0000.0fa89d01 ver: 0x01 opt: 0x02, entries follow...
itli: 1 flg: 2 scn: 0x0000.0fa89d00
itli: 2 flg: 2 scn: 0x0000.0fa89cfe
KDO Op code: LKR row dependencies Disabled
xtype: XA bdba: 0x00401f3a hdba: 0x00401f39
itli: 2 ispac: 0 maxfr: 4863
tabn: 0 slot: 3 to: 2
CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
session number = 8
serial number = 1
transaction name =

REDO RECORD - Thread:1 RBA: 0x000094.0000000f.00d8 LEN: 0x0054 VLD: 0x01
SCN: 0x0000.0fa89d02 SUBSCN: 1 04/14/2006 09:31:37
CHANGE #1 TYP:0 CLS:27 AFN:2 DBA:0x00800059 SCN:0x0000.0fa89d01 SEQ: 1 OP:5.4
ktucm redo: slt: 0x001f sqn: 0x00009c72 srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x0080027b.0352.21 ext: 2 spc: 5272 fbi: 0

REDO RECORD - Thread:1 RBA: 0x000094.0000000f.012c LEN: 0x00d4 VLD: 0x01
SCN: 0x0000.0fa89d02 SUBSCN: 1 04/14/2006 09:31:37
CHANGE #1 TYP:0 CLS:33 AFN:2 DBA:0x00800089 SCN:0x0000.0fa89cfe SEQ: 1 OP:5.2
ktudh redo: slt: 0x0028 sqn: 0x00009c88 flg: 0x0011 siz: 52 fbi: 0
uba: 0x00800559.0352.06 pxid: 0x0000.000.00000000
CHANGE #2 TYP:0 CLS:34 AFN:2 DBA:0x00800559 SCN:0x0000.0fa89cfd SEQ: 1 OP:5.1
ktudb redo: siz: 52 spc: 7680 flg: 0x0012 seq: 0x0352 rec: 0x06
xid: 0x0009.028.00009c88
ktubl redo: slt: 40 rci: 0 opc: 5.7 objn: 0 objd: 0 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00800559.0352.05
prev ctl max cmt scn: 0x0000.0fa89905 prev tx cmt scn: 0x0000.0fa8990a
CHANGE #3 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
session number = 8
serial number = 1
transaction name =

REDO RECORD - Thread:1 RBA: 0x000094.00000010.0010 LEN: 0x0054 VLD: 0x01
SCN: 0x0000.0fa89d03 SUBSCN: 1 04/14/2006 09:31:37
CHANGE #1 TYP:0 CLS:33 AFN:2 DBA:0x00800089 SCN:0x0000.0fa89d02 SEQ: 1 OP:5.4
ktucm redo: slt: 0x0028 sqn: 0x00009c88 srt: 0 sta: 9 flg: 0x2
ktucf redo: uba: 0x00800559.0352.06 ext: 2 spc: 7626 fbi: 0
END OF REDO DUMP
----- Redo read statistics for thread 1 -----
Read rate (ASYNC): 7Kb in 0.19s => 0.00 Mb/sec
Longest record: 0Kb, moves: 0/27 (0%)
Change moves: 6/63 (9%), moved: 0Mb

5.禁用日志生成,并切换日志

SQL> alter system set "_disable_logging"=true;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 148 104857600 1 NO ACTIVE 262708457 14-APR-06
2 1 149 104857600 1 NO CURRENT 262708606 14-APR-06
3 1 147 104857600 1 NO INACTIVE 262675537 14-APR-06

6.SCOTT用户再更新

SQL> show parameter disable

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_disable_logging boolean TRUE
SQL> update emp set sal=4000 where empno=7788;

1 row updated.

SQL> commit;

Commit complete.

 

7.转储日志

SQL> ALTER SYSTEM DUMP LOGFILE '/opt/oracle9/oradata/testora9/redo02.log';

System altered.

8.记录此时REDO信息

DUMP OF REDO FROM FILE '/opt/oracle9/oradata/testora9/redo02.log'
Opcodes *.*
DBA's: (file # 0, block # 0) thru (file # 65534, block # 4194303)
RBA's: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCN's scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
Times: creation thru eternity
FILE HEADER:
Software vsn=153092096=0x9200000, Compatibility Vsn=153092096=0x9200000
Db ID=1628068176=0x610a5950, Db Name='TESTORA9'
Activation ID=1628067152=0x610a5550
Control Seq=1163=0x48b, File size=204800=0x32000
File Number=2, Blksiz=512, File Type=2 LOG
descrip:"Thread 0001, Seq# 0000000149, SCN 0x00000fa89d7e-0xffffffffffff"
thread: 1 nab: 0xffffffff seq: 0x00000095 hws: 0x1 eot: 1 dis: 0
reset logs count: 0x1f435110 scn: 0x0000.00000001
Low scn: 0x0000.0fa89d7e 04/14/2006 09:33:43
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
Enabled scn: 0x0000.00000001 04/26/2004 15:56:10
Thread closed scn: 0x0000.0fa89d7e 04/14/2006 09:33:43
Log format vsn: 0x8000000 Disk cksum: 0xcac7 Calc cksum: 0xcac7
Terminal Recovery Stamp scn: 0x0000.00000000 01/01/1988 00:00:00
Most recent redo scn: 0x0000.00000000
Largest LWN: 0 blocks
End-of-redo stream : No
Unprotected mode
Miscellaneous flags: 0x0
END OF REDO DUMP

我们看到此时已经没有REDO生成.数据库仅记录少量必要信息而已.

这就是日志禁用的本质所在.

 

]]> http://www.eygle.com/archives/2006/04/how_disable_loggin_work.html http://www.eygle.com/archives/2006/04/how_disable_loggin_work.html Internal Fri, 14 Apr 2006 21:04:51 +0800 _disable_logging对于性能的影响 设置了_disable_logging参数,可以禁用日志的生成,从而提高某些测试的性能.

以下测试,纯属测试目的,其他内容请参考本站其他文章:

http://www.eygle.com/archives/2006/04/more_about_disable_logging.html

禁用日志情况下:

SQL> connect / as sysdba
Connected.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  286755168 bytes
Fixed Size                   731488 bytes
Variable Size             167772160 bytes
Database Buffers          117440512 bytes
Redo Buffers                 811008 bytes
Database mounted.
Database opened.
SQL> connect eygle/eygle
Connected.
SQL> show parameter disable

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_disable_logging                     boolean     TRUE

测试创建100万数据表:

SQL> create table test as select * from dba_objects where 1=0;

Table created.

SQL> set timing on
SQL> begin    
  2  for i in 1 .. 10000 loop
  3  insert into test select * from dba_objects where rownum < 101;
  4  commit;
  5  end loop;
  6  end;
  7  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:40.46
SQL> truncate table test;

Table truncated.

Elapsed: 00:00:52.72

大约时间用了40秒.

再看正常日志生成下:

 

SQL> connect / as sysdba
Connected.
SQL> alter system set "_disable_logging"=false;

System altered.

Elapsed: 00:00:00.05
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  286755168 bytes
Fixed Size                   731488 bytes
Variable Size             167772160 bytes
Database Buffers          117440512 bytes
Redo Buffers                 811008 bytes
Database mounted.
Database opened.
SQL> show parameter disable

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_disable_logging                     boolean     FALSE

SQL> connect eygle/eygle
Connected.
SQL> set timing on
SQL>
SQL> begin    
  2    for i in 1 .. 10000 loop
  3   insert into test select * from dba_objects where rownum < 101;
  4  commit;
  5    end loop;
  6  end;
  7 /  

PL/SQL procedure successfully completed.

Elapsed: 00:01:54.04
SQL>
SQL> truncate table test;

Table truncated.

Elapsed: 00:01:01.56

此时大约用时1分54秒.

两者差距为: 114 / 40 = 2.85 倍.

我们可以看出两者的差距是显著的.不作过多测试了,就此打住.大家有兴趣的可以自己测试一下.

 以上测试的环境为:

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
PL/SQL Release 9.2.0.4.0 - Production
CORE    9.2.0.3.0       Production
TNS for Solaris: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production

 

]]> http://www.eygle.com/archives/2006/04/disable_logging_performance.html http://www.eygle.com/archives/2006/04/disable_logging_performance.html Internal Fri, 14 Apr 2006 16:57:06 +0800 隐含参数_disable_logging的几点说明 在很久以前,曾经介绍过Oracle的一个内部隐含参数_disable_logging,看到有朋友论述这个参数,今天忍不住做一点补充说明.

1.当然,隐含有风险,设置请谨慎.

2.最初在9.2.0.6 Solaris版本上,设置该参数会触发Bug:3868748 使得数据库无法启动.

从警告日志中,通常可以获得的错误提示是:

ORA-07445: exception encountered:
core dump [kcrfwcint()+1625] [SIGFPE] [Integer divide by zero] [0x828739D] [] []

但是好在这个参数是动态的,在存在Bug版本中,我们可以修改数据库当前值来进行测试:

SQL> alter system set "_disable_logging"=true scope=memory;

System altered.

3.这个Bug的影响范围并非全部,9.2.0.6之下,Oracle9.2.0.5,Oracle9.2.0.4等,都不受这个Bug影响.Oracle声称的修正该Bug的版本是Oracle10gR2(我未验正).

4.这个参数在Oracle9.2.0.4版本的Linux/Solaris上是不存在这个Bug的.在我的环境中经过验证,过程请参考(附注1).

5.在归档模式下,设置该参数会导致日志文件损坏.因为在设置该参数与归档原则违背，归档进程无法识别该日志文件格式，会将该日志文件标记为损坏.所以需要谨慎测试,具体请参考(附注2).

附注1:Solaris Oracle9.2.0.4设置测试过程:

$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Thu Apr 13 22:51:24 2006

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> show parameter disa

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_disable_logging                     boolean     FALSE
SQL> alter system set "_disable_logging"=true scope=both;

System altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  286755168 bytes
Fixed Size                   731488 bytes
Variable Size             167772160 bytes
Database Buffers          117440512 bytes
Redo Buffers                 811008 bytes
Database mounted.
Database opened.
SQL> show parameter disable

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_disable_logging                     boolean     TRUE
SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
PL/SQL Release 9.2.0.4.0 - Production
CORE    9.2.0.3.0       Production
TNS for Solaris: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production

附注2:归档模式下,该参数会导致日志文件损坏.

设置该参数后,切换日志:

SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /opt/oracle/oradata/conner/archive
Oldest online log sequence     20
Next log sequence to archive   23
Current log sequence           23
SQL> alter system switch logfile;

System altered.

SQL> select group#,status from v$Log;

    GROUP# STATUS
---------- ----------------
         1 INACTIVE
         2 ACTIVE
         3 INACTIVE
         4 CURRENT

SQL> show parameter disable

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_disable_logging                     boolean     TRUE

此时可以在警告日志中看到日志损坏的错误信息:

Thu Apr 13 23:33:25 2006
ARC0: Evaluating archive   log 2 thread 1 sequence 23
ARC0: Beginning to archive log 2 thread 1 sequence 23
Creating archive destination LOG_ARCHIVE_DEST_1: '/opt/oracle/oradata/conner/archive/1_23.dbf'
ARC0: Log corruption near block 3849 change 0 time ?
ARC0: All Archive destinations made inactive due to error 354
Thu Apr 13 23:33:25 2006
Errors in file /opt/oracle/admin/conner/bdump/conner_arc0_21506.trc:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 3849 change 0 time 04/13/2006 21:13:03
ORA-00312: online log 2 thread 1: '/opt/oracle/oradata/conner/redo02.log'
ARC0: Archiving not possible: error count exceeded
ARC0: Failed to archive log 2 thread 1 sequence 23
ARCH: Archival stopped, error occurred. Will continue retrying
Thu Apr 13 23:33:26 2006
ORACLE Instance conner - Archival Error
ARCH: Connecting to console port...
Thu Apr 13 23:33:26 2006
ORA-16038: log 2 sequence# 23 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 2 thread 1: '/opt/oracle/oradata/conner/redo02.log'
ARCH: Connecting to console port...
ARCH:
Thu Apr 13 23:33:26 2006
ORA-16038: log 2 sequence# 23 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 2 thread 1: '/opt/oracle/oradata/conner/redo02.log'

 

]]> http://www.eygle.com/archives/2006/04/more_about_disable_logging.html http://www.eygle.com/archives/2006/04/more_about_disable_logging.html Internal Fri, 14 Apr 2006 16:54:22 +0800