Skip to content

Oracle - 56. page

粗心大意的DBA还有SA导致OCR initialization failed accessing OCR device

一个比较大的升级项目，临时发现lv镜像问题，对程序进行Tar包调整相关目录做LV镜像，最后tar解压CRS和DATABASE的程序完成后，发现node1的CRS无法启动了，停止在 /etc/init.d/init.cssd startcheck上，在/tmp目录下找到最新生产的CRS相关的日志发现如下报错：

OCR initialization failed accessing OCR device: PROC-26: Error while accessing the physical storage Operating System error [No such device or address] [6]

通过查找/crs/log/client/xhdb1/alert.log也能够找到相关的日志，要更详细点.到了这一步其中的一个DBA就慌了，又是查RAW权限，又是查系统问题，再确认RAW的权限没问题之后，打算用DD导出OCR的信息进行查看，到这一步被我中止，在加班了将近13个小时情况下大家都已经疲惫了，生怕不小心把数据文件给dd掉了，我便登陆这个节点检测问题，一般碰到此类问题无非几个原因，如下：

1）RAW权限被改，没有读的权限
2）RAW的相关信息被变动过（查看最近的更改时间）
3）RAW所在的VG并未varyonvg
4）bug

按照这上面1个个检测去检测，基本都能找到问题，经过lspv的方式查看了节点1的时候，发现datavg处于inactive状态，问题已经发现了.经过一翻查询发现节点1在重启后HA并没有跟随OS的重启而重启，此时节点2正在运行集群，datavg在节点二上出于并发状态，节点1的HA并未启动也就意味着DATAVG处于OFF状态，最终导致CRS无法读取DATAVG上的OCR信息引起报错。

DD在生产库上，在没有准备的情况下突然要使用，这是对自己和客户的不负责，使用时候需三思。

Grid and Cluster Oracle 排障配置与调整 | Guang Cai Li | |   OCR

AIX系统中rootvg镜像遇到的lv未镜像问题

在一次客户的升级过程中，由于对crs目录的扩展碰到如下情况：

# lsvg -l rootvg
rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd5 boot 1 2 2 closed/syncd N/A
hd6 paging 67 134 2 open/syncd N/A
hd8 jfs2log 1 2 2 open/syncd N/A
hd4 jfs2 40 80 2 open/syncd /
hd2 jfs2 24 48 2 open/syncd /usr
hd9var jfs2 16 32 2 open/syncd /var
hd3 jfs2 20 40 2 open/syncd /tmp
hd1 jfs2 16 32 2 open/syncd /home
hd10opt jfs2 16 32 2 open/syncd /opt
hd11admin jfs2 16 32 2 open/syncd /admin
lg_dumplv sysdump 12 12 1 open/syncd N/A
livedump jfs2 16 32 2 open/syncd /var/adm/ras/livedump
fslv00 jfs2 344 344 2 open/syncd /oracle
fslv01 jfs2 60 120 2 open/syncd /crs

# lsvg rootvg
VOLUME GROUP: rootvg VG IDENTIFIER: 00c2f54500004c0000000125351247e2
VG STATE: active PP SIZE: 256 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 1092 (279552 megabytes)
MAX LVs: 256 FREE PPs: 150 (38400 megabytes)
LVs: 14 USED PPs: 942 (241152 megabytes)
OPEN LVs: 13 QUORUM: 1 (Disabled)
TOTAL PVs: 2 VG DESCRIPTORS: 3
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 2 AUTO ON: yes
MAX PPs per VG: 32512
MAX PPs per PV: 1016 MAX PVs: 32
LTG size (Dynamic): 1024 kilobyte(s) AUTO SYNC: no
HOT SPARE: no BB POLICY: relocatable

# bootlist -m normal -o
hdisk0 blv=hd5
hdisk1 blv=hd5

鉴定是否lv有镜像的办法：

# lslv -m hd3
hd3:/tmp
LP PP1 PV1 PP2 PV2 PP3 PV3
0001 0224 hdisk0 0269 hdisk1
0002 0289 hdisk0 0270 hdisk1
0003 0290 hdisk0 0271 hdisk1
0004 0291 hdisk0 0272 hdisk1
0005 0292 hdisk0 0273 hdisk1
0006 0293 hdisk0 0274 hdisk1
0007 0294 hdisk0 0275 hdisk1
0008 0295 hdisk0 0276 hdisk1
0009 0296 hdisk0 0277 hdisk1
0010 0297 hdisk0 0278 hdisk1
0011 0298 hdisk0 0279 hdisk1
0012 0299 hdisk0 0280 hdisk1
0013 0300 hdisk0 0281 hdisk1
0014 0301 hdisk0 0282 hdisk1
0015 0302 hdisk0 0283 hdisk1
0016 0303 hdisk0 0284 hdisk1
0017 0387 hdisk0 0506 hdisk1
0018 0388 hdisk0 0507 hdisk1
0019 0389 hdisk0 0508 hdisk1
0020 0390 hdisk0 0509 hdisk1

# lslv -m fslv00
fslv00:/oracle
LP PP1 PV1 PP2 PV2 PP3 PV3
0001 0129 hdisk1
0002 0130 hdisk1
0003 0131 hdisk1
0004 0132 hdisk1
0005 0133 hdisk1
0006 0134 hdisk1
0007 0135 hdisk1
0008 0136 hdisk1
0009 0137 hdisk1

如上可以看到，fslv00是没有镜像的。

可以发现做了镜像的rootvg，两块盘为hdisk0，hdisk1，启动顺序为2块盘都可以启动，那么问题问题在哪里呢？
仔细观察LPs和PPs的数量对比时候，可以发现/crs和/oracle目录所在fslv00，fslv01的LPs=PPs的数量，而其他的文件系统所挂载的PPs=2*LPs，这个说明了系统工程师在创建集群件和数据库目录的时候，没有对相关的lv做镜像，导致了rootvg镜像的意义已经失去了，一旦Hdisk0故障，会导致主机所在的集群和数据库无法运行，无法达到rootvg的镜像效果，更糟糕的问题在于系统工程师在为crs增加空间的时候，把hdisk1的空间加到了crs目录，导致无法对fslv00直接做mirror，这时候有两种办法处理这种潜在的验证风险因子方法：
1）把crs在hdisk1中占用的空间清理之后转移到hdisk1中再对相关的fslv00，fslv01做lv级别的mirror；
参考连接：
链接1：如何处理lv镜像

2）在清理完crs占用hdisk1空间之后，取消hdisk1的mirror，然后重新extened做mirror；
参考连接：
链接2：Aix取消vg镜像，以及重做vg镜像

aix Oracle Unix and Linux | Guang Cai Li | |   lv 镜像

浅谈RMAN备份中"Unused Block Compression"使用限制

自从Oracle 10g推出Rman备份机制以来，其中的一个重要特性“空块不作备份”一直都深受DBA和广大客户的喜爱，节约空间以及提高备份效率等等，我也是如此喜欢，但是最近在一个项目上测试EMC备份软件备份时候，发现了一个怪事，具体如下描述：

1）数据库DB1通过EMC备份软件（备份方式为STB_TAPE）备出来大小为：780G。
期间尝试修改过3次参数，包括增量备份level=0，普通全备，filesperset参数取消，备份出来的大小均为780G不变。
2）数据库DB1通过Rman备份到本地硬盘（备份方式为DISK）大小为340G。

经过1和2的测试对比发现了明显的异常，通过第三方软件备份多出来了440G大小，随即进行跟踪分析，结果根据和之前做的清理400多G的数据进行联系，当时只是对数据做delete操作，但是并未做move以及空间回收操作，初步判断此次操作和EMC备份异常有关，在数据清理之前数据库的实际大小为700多G，根据Delete的特性可以判断这删掉的400多G的数据原先占有的数据块为空块，但是处于高水位线之下，属于曾经被使用过的块而且当前处于“不可用”状态，到此猜想，

是不是EMC备份把这些空块也一起备份了？
如果备了，那么为什么rman空数据块不被分的特性没有发挥作用么？

经过一番周折终于发现问题所在，这种现象发生在如下版本：

Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 11.2.0.2(Ludatou.com) – Release: 10.2 to 11.2

而且对任何平台都影响。
而且使用“Unused Block Compression”条件有如下限制：
1）备份集存放方式存放在本地硬盘上
2）为0级备份或者量备份或者全备方式中的备份集的一部分
3）数据文件为本地管理方式
4）没有定义还原点的数据库
5）COMPATIBLE设置为10.2以上
6）数据库版本高于（不等于）10.2.0.1

针对COMPATIBLE对“Unused Block Compression”影响官方文档《Oracle Database Backup and Recovery Reference》解释如下：

Oracle Database Backup and Recovery Reference
11g Release 2 (11.2)
Part Number E10643-04
.
Backup
backupTypeSpec

Note:
If COMPATIBLE is set to 10.2, then only tablespaces created with 10.2 compatibility will be optimized to exclude blocks that do not currently contain data. If COMPATIBLE is set to 11.0.0 or higher, however, then the first backup that produces backup sets after COMPATIBLE is set to 11.0.0 or higher will update the headers of all locally managed datafiles so that all locally managed datafiles can be optimized.

经过以上的解释还不能解释为什么EMC备份会出现异常，
而ORACLE的一段关于OSB（Oracle Secure Backup）的描述，则解释了为什么EMC的备份软件没能使用到“Unused Block Compression”特性原因：

When backing up to a media manager that is not Oracle Secure Backup, RMAN copies all the blocks regardless of whether they contain data or not.

就是说再使用MML（Media Management Layer）连接第三方备份软件的方式（包含我们熟悉的赛门铁克的NBU,康孚，IBM的TSM等备份软件）备份数据库，在除了oracle原厂的备份软件Oracle Secure Backup之外都不能够使用到“Unused Block Compression”的特性，到此我们也终于明白为什么EMC备份软件备份出来的ORACLE数据为什么和实际的数据量不一致。

如果不小心使用了原厂之外的第三方备份软件，那么只能寻求其他的解决方案。
解决方案：
1）对相关的datafile/tablespace进行空间回收工作
2）对delete频繁的对象进行move操作
3）对DML操作频繁的大索引定期进行rebuild操作
4）换OSB（Oracle Secure Backup）吧
5）用Rman的方式备到本地，再用files backup的方式备份到磁带（弃用MML的SBT_TAPE备份方式），比如TSM
6）针对“Unused Block Compression”限制的条件进行设置处理

Oracle Oracle恢复 浅谈oracle技术系列 | Guang Cai Li | |   ramn空块备份 SBT_TAPE，scb Unused Block Compression

11.1.0.6升级11.1.0.7遭遇错误“ dtexec dtfile dtsession dtterm dtwm java ksh rpc.ttdbserver ttsession”

平台：AIX 61006
版本：ORACLE 11.1.0.6 REAL APPLICATION CLUSTER and DATABASE
目标升级版本：
ORACLE CRS 11.1.0.7.7
ORACLE DATABASE 11.1.0.12

遭遇错误信息：
安装过程遭遇错误，错误信息如下

dtexec dtfile dtsession dtterm dtwm java ksh rpc.ttdbserver ttsession.

日志信息如下：

639014: execve(“/usr/sbin/fuser”, 0x0000000112BA7DD0, 0x000000011000E0D0) argc: 6
639014: argv: /usr/sbin/fuser -f -x -f -x
639014: /ora/oracle/product/11.1/db_1/bin/oracle

经过查询检验为AIX系统bug，补丁
IZ67400: FUSER GIVES INCORRECT PIDS WITH -X OPTION
APAR is a duplicate of IZ71207

△其次在不打系统补丁的情况下可以通过以下方式解决此类问题：

在root用户下操作:
1) 重命名 fuser
mv /usr/sbin/fuser /usr/sbin/fuser_renamed
2) touch /usr/sbin/fuser
3) chmod +x /usr/sbin/fuser

在oracle用户下操作:
1) 在图形界面中点击“try again”重试安装

安装成功后，登陆root用户执行以下操作:
1) rename fuser back to its original name
mv /usr/sbin/fuser_renamed /usr/sbin/fuser

Database Grid and Cluster Oracle 排障配置与调整 | Guang Cai Li | |   ksh rpc.ttdbserver ttsession