Skip to content

手工推进oracle scn方式(1)Oradebug 推进scn

环境:LINUX_x86

这里需要注意地方为:

1.我的系统为32bit的小端系统.
2.大小端的SCN_WRAP和SCN_BASE是相反的.在大端中,kcsgscn_的前4字节为SCN_BASE,5-8字节为SCN_WRAP.
3.在32bit系统中寻址只能是4字节,而64位系统可以8字节.

该测试为32bit 小端系统,环境如下:

[root@ludatou ~]# file /sbin/init
/sbin/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

[root@ludatou ~]# su - ora10g
[ora10g@ludatou ~]$ sqlplus '/as sysdba'

SQL*Plus: Release 10.2.0.4.0 - Production on Thu Jul 24 01:58:10 2014

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> startup mount
ORACLE instance started.

Total System Global Area  318767104 bytes
Fixed Size                  1267260 bytes
Variable Size             100665796 bytes
Database Buffers          213909504 bytes
Redo Buffers                2924544 bytes
Database mounted.

检查当前scn情况并以oradebug的方式推进scn:

--当前scn
SQL> select to_char(checkpoint_change#,'XXXXXXXXXXXXXXXX') from v$database;

TO_CHAR(CHECKPOIN
-----------------
A03E2F

SQL> oradebug setmypid
Statement processed.

--获取内存scn对应
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [20009228, 20009248) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 20009034
--因为32bit系统所以采用4字节寻址,更改scn_wrap
SQL> oradebug poke 0x20009228 4 0x01
BEFORE: [20009228, 2000922C) = 00000000
AFTER: [20009228, 2000922C) = 00000001
--更改scn_base
SQL> oradebug poke 0x2000922C 4 0x01
BEFORE: [2000922C, 20009230) = 00000000
AFTER: [2000922C, 20009230) = 00000001
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [20009228, 20009248) = 00000001 00000001 00000000 00000000 00000000 00000000 00000000 20009034
SQL> oradebug poke 0x2000922C 4 0xA03E2F
BEFORE: [2000922C, 20009230) = 00000001
AFTER: [2000922C, 20009230) = 00A03E2F
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [20009228, 20009248) = 00000001 00A03E2F 00000000 00000000 00000000 00000000 00000000 20009034
--更改完成后打开数据
SQL> alter database open;

Database altered.
--可以发现scn已经推进了wrap+1位
SQL> select to_char(current_scn,'XXXXXXXXXXXXXXXX') from v$database;

TO_CHAR(CURRENT_S
-----------------
100A04185

 

2014年7月最新的PSU和CPU补丁信息

关于数据库的补丁需要注意的地方:

 1.12.1.0.1.4 PSU依然是个non-composite的补丁

 2.没有关于Client-only installations 的新补丁发布

Patch Information 12.1.0.1.4 Comments
Final Patch
PSU On-Request platforms

Table 8 describes the available patches for Oracle Database 12.1.0.1.4.

Table 8 Patch Availability for Oracle Database 12.1.0.1.4

Product Home Patch Advisory Number Comments
Oracle Database home Database 12.1.0.1.4 PSU Patch 18522516, orGI 12.1.0.1.4 PSU Patch 18705901 for Linux x86-64, Solaris X64 & Solaris SPARC, or

GI 12.1.0.1.4 PSU Patch 18705972 for AIX, HP IA & zLinux

Microsoft Windows 32-Bit & x86-64 BP 11 Patch 19062327, or later;

Quarterly Full Stack download for Exadata (July 2014) 12.1.0.1 BP Patch 19069261

CVE-2013-3751, CVE-2013-3774, CVE-2014-4236, CVE-2014-4237, CVE-2014-4245 GI 12.1.0.1.4 PSU Patch 18705901 is applicable to Exadata database servers running Oracle Database 12.1.0.1. For more information, see Note 888828.1GI 12.1.0.1.4 PSU Patch 18705972 for AIX, HP IA & zLinux only contains DB PSU 12.1.0.1.4 sub-patch and no clusterware sub-patches

3.1.4.3 Oracle Database 11.2.0.4

Table 9 describes the Error Correction information for Oracle Database 11.2.0.4.

Table 9 Error Correction information for Oracle Database 11.2.0.4

Patch Information 11.2.0.4 Comments
Final Patch January 2018
SPU On-Request platforms HP-UX PA RISCIBM: Linux on System Z

32-bit client-only platforms except Linux x86

PSU On-Request platforms 32-bit client-only platforms except Linux x86

Table 10 describes the available patches for Oracle Database 11.2.0.4.

Table 10 Patch Availability for Oracle Database 11.2.0.4

Product Home Patch Advisory Number Comments
Oracle Database home Database 11.2.0.4 SPU Patch 18681862, orDatabase 11.2.0.4.3 PSU Patch 18522509, or

GI 11.2.0.4.3 PSU Patch 18706472, or

Microsoft Windows (32-Bit) & x64 (64-Bit) BP 7 Patch 18842982, or later;

Quarterly Database Patch for Exadata (July 2014) 11.2.0.4.9 BP Patch 18840215, or

Quarterly Full Stack download for Exadata (July 2014) BP Patch 19067488

CVE-2014-4236, CVE-2014-4237, CVE-2014-4245

3.1.4.4 Oracle Database 11.2.0.3

Table 11 describes the Error Correction information for Oracle Database 11.2.0.3.

Table 11 Error Correction information for Oracle Database 11.2.0.3

Patch Information 11.2.0.3 Comments
Final Patch July 2015
SPU On-Request platforms HP-UX PA RISCIBM: Linux on System Z

32-bit client-only platforms except Linux x86

PSU On-Request platforms 32-bit client-only platforms except Linux x86

Table 12 describes the available patches for Oracle Database 11.2.0.3.

Table 12 Patch Availability for Oracle Database 11.2.0.3

Product Home Patch Advisory Number Comments
Oracle Database home Database 11.2.0.3 SPU Patch 18681866, orDatabase 11.2.0.3.11 PSU Patch 18522512, or

GI 11.2.0.3.11 PSU Patch 18706488, or

Quarterly Database Patch for Exadata (July 2014) 11.2.0.3.24 BP Patch 18835772, or

Quarterly Full Stack download for Exadata (July 2014) 11.2.0.3 BP Patch 19067489, or

Microsoft Windows 32-Bit BP 32 Patch 18940193, orlater

Microsoft Windows x86-64 BP 32 Patch 18940194, orlater

CVE-2014-4245
Oracle Database home CPU Patch 13705478 Released April 2012 OC4J 10.1.3.4 one-off patch (Special OPatch needed, see README)

3.1.4.5 Oracle Database 11.1.0.7

Table 13 describes the Error Correction information for Oracle Database 11.1.0.7.

Table 13 Error Correction information for Oracle Database 11.1.0.7

Patch Information 11.1.0.7 Comments
Final Patch July 2015
SPU On-Request platforms
PSU On-Request platforms

Table 14 describes the available patches for Oracle Database 11.1.0.7.

Table 14 Patch Availability for Oracle Database 11.1.0.7

Product Home Patch Advisory Number Comments
Oracle Database home Database 11.1.0.7 SPU Patch 18681875, orDatabase 11.1.0.7.20 PSU Patch 18522513, or

Microsoft Windows (32-Bit) BP 57 Patch 18944207, orlater

Microsoft Windows x86-64 BP 57 Patch 18944208, orlater

CVE-2014-4245 Patches also applicable to Fusion Middleware 11.1.1.x and 11.1.2.x installations
Oracle Database home OHT BP Patch 16801095 Released July 2013 OHT BP 10.1.3.5 for DB Control
Oracle Database home CPU Patch 13705478 Released April 2012 OC4J 10.1.3.3 one-off patch (Special OPatch needed, see README)
Oracle CRS home CRS 11.1.0.7.7 PSU Patch 11724953 Released April 2011 Non-security content only
Oracle Database home CPU Patch 9288120 Released April 2011 Database UIXFor Oracle Secure Enterprise Search 11.1.2.x installations, follow the instructions in Note 1359600.1
Oracle Database home CPU Patch 10073948 Released April 2011 Enterprise Manager Database Control UIXNot applicable to Oracle Secure Enterprise Search 11.1.2.x
Oracle Database home CPU Patch 11738232 Released April 2011 Warehouse BuilderNot applicable to Oracle Secure Enterprise Search 11.1.2.x

浅谈如何计算oracle文件的偏移量

##############################
www.ludatou.com 大头
转载请指明处,否则追究法律责任
##############################

了解oracle的偏移量可以帮助在一些特殊恢复场景时候急救需求用到。
关于oracle 偏移量在10g之前一直是DBA需要惦记的事情,曾经有一个在AIX平台存在的经典bug2620053就是因为关于在裸设备上偏移量的问题,在那个时代DBA在aix系统普遍使用裸设备,每次加数据文件总是要考虑到offset的问题。

在众多平台中,目前只有在AIX平台上在为Oracle使用裸设备时候,会预留出4k的空间保留裸设备元数据,俗称磁盘头(lv header)。而在以前HP TRU64也存在一样的情况,只是目前TRU 64已经不受Oracle支持了。
在每一个oracle文件都存在一个系统文件头(block 0),它们由oracle维护,数据文件上的BLOCK 0的大小等于该数据文件的block_size,而重做日志文件上的BLOCK 0除了hp平台为1M外其他都为512bytes(具体可以通过dump logfile,通过tracefile的block_size查出)。BLOCK 0之后的BLOCK 1就是Oracle header block。这里的BLOCK 1的offset就等于v$datafile中的block1_offset。

在正常情况下,不算上AIX,HP tru64的平台中使用裸设备的话,实际的oracle数据的byte offset通用计算方法如下:

byte offset=oracle_block_number * oracle_block_size (对应文件上的block number)
另外一种算法是
byte offset=block1_offset + 1 + ((oracle_block_number - 1) * oracle_block_size)
因为严格意义上讲,block1_offset并不是oracle真实数据的起始块,这两种结果都一样,只是从意义上区分开来了。

在AIX,HP tru64系统上使用裸设备的情况下,byte offset计算方法如下:

offset = raw_device_block0_offset + 1 + (oracle_block_number * oracle_block_size) 

其实到这里就可以看出来了,在AIX平台上,当使用裸设备时候(这里的裸设备不是使用-T -O的big vg或者scan vg划分出来的lv),脱离了文件系统管理,file_syatem_block0_offset为0。只有在使用文件系统存放oracle文件的时才存在file_syatem_block0_offset为对应的blocksize或者redoblocksize。

AIX平台裸设备offset:

raw_device_block0_offset = 4096
file_system_block0_offset = 0

HP tru64平台裸设备offset:

raw_device_block0_offset = 65536
file_system_block0_offset = 0

从oracle 9203开始,Oracle就建议使用rlv这种不带raw_device_block0_offset的类型裸设备(lv),具体信息参考
《关于aix上的逻辑卷偏移量》

相比较而言,

如何检测oracle所在介质上的偏移量

##########################
www.ludatou.com 大头
转载请指明处,否则追责法律责任
##########################

该文主要是把当前我所知道的检测Oracle数据文件中在系统上真实数据的起始偏移量的方式,该文档只作为介绍检测偏移量的方式,关于偏移量的相关信息参考《如何计算oracle文件的偏移量》

1.v$datafile视图中的BLOCK1_OFFSET字段可以找出偏移量

默认为8192,在一个块为8k的数据库中每个数据文件在创建时候都会在文件头创建一个OS Header Block,该块大小与数据库块大小一致,所以默认的偏移量都是8192。但是由于现在raw用的少了因为raw中也会为os file system预留空间,在aix为4k,在AIX平台中使用裸设备的文件实际偏移量应该是8192+4096.

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0 Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.5.0 - Productio
NLSRTL Version 10.2.0.5.0 - Production

SQL> set linesize 200
SQL> col name for a50

SQL> select name,block1_offset from v$datafile

NAME BLOCK1_OFFSET
-------------------------------------------------- -------------
/data/ludatou/system01.dbf 8192
/data/ludatou/undotbs01.dbf 8192
/data/ludatou/sysaux01.dbf 8192
/data/ludatou/users01.dbf 8192

2.Oracle自带的dbfsize工具

无偏移量情况:

$ dbfsize /dev/rlvsystem01

Database file: /dev/rlvsystem01
Database file type: raw device without 4K starting offset
Database file size: 40960 8192 byte blocks

有偏移量情况:

MDDB$dbfsize /dev/rloradb1

Database file: /dev/rloradb1
Database file type: raw device
Database file size: 262016 8192 byte blocks

3.AIX系统下使用lslv的命令确认是否存在

#lslv datalv
LOGICAL VOLUME: DATALV VOLUME GROUP: datavg
LV IDENTIFIER: 00c3dff400004c00000001217a9d839e.84 PERMISSION: read/write
VG STATE: active/complete LV STATE: closed/syncd
TYPE: raw WRITE VERIFY: off
MAX LPs: 1024 PP SIZE: 32 megabyte(s)
COPIES: 1 SCHED POLICY: parallel
LPs: 64 PPs: 64
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: maximum RELOCATABLE: yes
INTRA-POLICY: middle UPPER BOUND: 1024
MOUNT POINT: N/A LABEL: None
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: NO
DEVICESUBTYPE : DS_LVZ

当存在DEVICESUBTYPE : DS_LVZ时候证明存在偏移量。

4.在AIX上使用checkoffset脚本检测

使用方法:checkoffset uraw_name
该脚本如下:

#!/bin/ksh

# input:
# string: raw character device to check

# output:
# numeric: offset in raw device where oracle data begins

# error exit codes:
# 255 - usage
# 254 - block device (instead of raw device)
# 253 - not a raw device (regular file, directory, etc.)
# 252 - LV not recognized by 'lslv' command

# notes:
# This script checks the output of the AIX 'lslv' command for a device subtype of DS_LVZ.
# Note that most implementations of 'lslv' will only output the DEVICESUBTYPE field if
# the value is something other than DS_LV.  If the DEVICESUBTYPE field is not displayed,
# or displays a value other than DS_LVZ, then offset is output as 4096, otherwise 0.  A
# device subtype of DS_LVZ indicates that the normal AIX Logical Volume Control Block
# (lvcb) does not occupy the first 512 bytes of the raw device file, and Oracle data
# begins at offset 0.  A device subtype of DS_LV (default) indicates the first 512 bytes
# of the raw device are occupied by the AIX lvcb, and Oracle data begins at offset 4096.

# check that one, and only one, parameter was passed
if [ $# -lt 1 -o $# -gt 1 ]; then
   /usr/bin/echo "Usage: checkoffset raw_device"
   /usr/bin/echo "Example: checkoffset /dev/rASMRAW1"
   exit 255
fi

# resolve relative path to full path
dirn=`/usr/bin/dirname $1`
if [ $dirn = "." ]; then
   dirn=`/usr/bin/pwd`
fi
if [ $dirn = "/" ]; then
   dirn=""
fi
basn=`/usr/bin/basename $1`
rdev="$dirn/$basn"

# check whether the parameter passed is a block device
if [ -b $1 ];  then
   /usr/bin/echo "Error: $rdev is a block device"
   exit 254
fi

# check whether the parameter passed is a raw character device
if [ ! -c $1 ];  then
   /usr/bin/echo "Error: $rdev is not a raw character device"
   exit 253
fi

# strip the 'r' from the device name to get the LV name
lvname=`/usr/bin/echo $basn | /usr/bin/cut -c 2-`

# check whether lslv accepts the LV name as valid
lvchk=`/usr/sbin/lslv $lvname > /dev/null 2>&1 ; print $?`
if [ $lvchk != "0" ]; then
   /usr/bin/echo "Error: Command failed: /usr/sbin/lslv $lvname"
   /usr/sbin/lslv $lvname
   exit 252
fi

# check lslv output for DEVICESUBTYPE of DS_LVZ and set offset
offset=`/usr/sbin/lslv $lvname | /usr/bin/grep DEVICESUBTYPE`
offset=`echo $offset | /usr/bin/grep DS_LVZ ; print $?`
if [ $offset = "0" ]; then
   offset="0"
else
   offset="4096"
fi

# display offset and exit cleanly
echo $offset
exit 0