Skip to content

浅谈oracle技术系列

浅谈Oracle数据库坏块( Database corruption part 1 )

关于坏块这一类的故障,从业这些年遇见得比较多,有的数据还能抢救,有的数据直接就丢了,更甚者数据库因此报废了. 一旦碰到,虽说不一定棘手,但是不免心里求佛一翻.

所谓Oracle数据库坏块顾名思义oracle数据库所在的数据存储介质的内容出现了讹误混乱或者无法访问.在Oracle自己的范围内对坏块有定义,这个可以参考文档[Note 840978.1].

坏块的种类有很多,它有可能因为各种原因出现在Oracle database的几种文件上面,报错也因此各有差异,处理的手段方法也各不相同,很早之前我就承诺过对这部分内容进行梳理更新到ludatou.com上,而现在我和陈辉正在对Mdata针对坏块部分的处理在做研发.所以趁此机会也尽量将文章更新到博客上,大部分上会是原创,有好的文章我也会转发.浅谈坏块这一系列的文章以方法和原理为主,除此之外我会把以往的坏块处理案例以日志方式更新,不作为浅谈部分文章.

浅谈坏块内容主要包含以下几部分:

    坏块分类以及产生的主要原因
    坏块的构造,检测方法以及可能发生的Oracle文件
    坏块的主要错误以及处理方法
    坏块的预防方式

本篇为坏块分类以及产生的主要原因

————————————————

1.坏块的主要分类,来自Oracle官方文档的解释,有助于更直接的了解区分物理坏块和逻辑坏块的区别(Note 840978.1有更加详细的描述):

For purposes of the paper we will categorize corruption under three general areasand give best practices for prevention, detection and repair for each:

    Memory corruption
    Logical corruption(soft corruption)
    Media corruption(Physicalcorruption)

Physicalor structural corruption can be defined as damage to internal data structureswhich do not allow Oracle software to find user data within the database. Logical corruption involves Oracle beingable to find the data, but the data values are incorrect as far as the end useris concerned.
Physica lcorruption due to hardware or software can occur in two general places — inmemory (including various IO buffers and the Oracle buffer cache) or on disk.Operator error such as overwriting a file can also be defined as a physicalcorruption. Logical corruption on theother hand is usually due to end-user error or non-robust(?) applicationdesign. A small physical corruption such as a single bit flip may be mistakenfor a logical error.

2.坏块的产生主要原因
坏块产生的原因很多 ,这里根据资料整理以及历史遭遇梳理出主要产生数据库坏块的原因.

    2.1 硬件问题
    Oracle进程在处理一个数据块时，首先将其读入物理内存空间，在处理完成后，再由特定进程将其写回磁盘；如果在这个过程中，出现内存故障，CPU计算失误，都会导致内存数据块的内容混乱，最后反映到写回磁盘的数据块内容有误。同样，如果存储子系统出现异常，数据块损坏也就随之出现了。比如硬盘出现坏道,那么这部分的数据就处于无法读取的情况,和坏块没有区别.

    2.2 操作系统BUG
    由于Oracle进程对数据块的读写，都是以操作系统内核调用（system call）的方式完成的，如果操作系统在内核调用存在问题，必然导致Oracle进程写入非法的内容。

    2.3 操作系统的I/O错误或缓冲问题
    比如写丢失,io系统缓存掉电,io操作结果被截断

    2.4 内存或paging问题
    Oracle软件有较多的bug能导致坏块问题的出现,

    2.5 非Oracle进程扰乱Oracle共享内存区域
    如上文所述，在当数据块的内容被读入主机的物理内存时，如果其他非Oracle进程，对Oracle使用的共享内存区域形成了扰乱，最终导致写回磁盘的数据块内容混乱。

    2.6 异常关机，掉电，终止服务
    异常关机，掉电，终止服务使进程异常终止，也会导致坏块产生。

    2.7 数据库操作人为失误
    使用nologging选项操作后再做恢复后可能造成坏块,或者人为的破坏文件导致的坏块。

Oracle恢复 异常恢复 数据技术 浅谈oracle技术系列 | Guang Cai Li | |   corruption 坏块

浅谈关于清理oracle监听log的方式以及考虑

listener log是一个比较有意思的东西，作为日常运维的一个点，多数的dba都知道清理的方式就是定期备份清下，而这小点子细挖下去会发现还是有些意思的。这里介绍几种日常的清理监听日志的方式以及关注点，我的观点是在做这方面清理的时候，日志有必要制定一个备份策略。

1.offline listener清理
这种方式主要是在停掉了监听或者直接停掉了业务数据库后，对listener.log进程mv或者backup的操作后新建listener.log，或者就是以清理文件内容的方式进行清理。

2.online listener清理
这种清理可以理解为在不影响业务的情况下清理log，这个以oracle角度来区分，区别在于是否禁止listener进程持续写日志上，关闭listener写日志命令如下：

LSNRCTL> set current_listener
LSNRCTL> set log_status off
--之后备分listener.log,清除log后恢复listener进程的日志记录，
LSNRCTL> set log_status on

那么这里在清除log的系统命令上有多种，这里介绍下linux下的3种以及windows上的1种

linux/unix平台：

2.1 cat /dev/null > 要清空的文件
例：

cat /dev/null > /u01/oracle/product/db/network/log/listener.log

2.2 echo “” > 要清空的文件
例：

echo "" > /u01/oracle/product/db/network/log/listener.log

2.3 cp /dev/null 要清空的文件
例：

cp /dev/null /u01/oracle/product/db/network/log/listener.log

以上三种清理都支持在线直接清理日志，可以不禁止listener进程持续写日志的情况下直接执行，只是在考虑点上在前面所说的是否禁止listener进程持续写日志。我日常使用2.1的方式，从系统效率上cp /dev/null的方式会优于其他2种。

Windows平台

2.4 @echo.> 要清空的文件
例：

@echo.> D:\oracle\listener.log

3.rename file方式清理

这个方法在10g之前的版本可以使用，在11g由于adr的设置需要禁止adr后才能够使用，否则会遭遇“TNS-01251: Cannot set trace/log directory under ADR”的错误。
登陆listener控制台，命令如下：

LSNRCTL>set current_listener LSNRCTL>set log_file
LSNRCTL>save_config

例：

LSNRCTL>set current_listener LISTENER1
LSNRCTL>set log_file listener1_1.log
LSNRCTL>save_config

当执行完set log_file这个命令后，系统更新listener.ora文件，同时生成新的listener日志，此后就可以对老的listener.log进行处理。这种方式在sun的solaris蹭遭遇过bug导致监听进程offline，所以使用时候注意平台。还有一个注意点就是在多个监听下分别对每个监听的日志进行清理时候需要分开执行，因为save_config会覆盖当前设置之前的其他监听的设置，导致前面的设置失效。

Database Oracle Oracle 排障配置与调整 数据技术 浅谈oracle技术系列 | Guang Cai Li |

浅谈datapump迁移数据时候的一些技巧以及坑点（待细化）

做了不少数据迁移和升级的项目，大大小小的，为此也总结了一些技巧和坑点，记录下来以作分享和日后参考。

1.方案，流程，测试，完善
2.借机梳理系统交互的dblink
梳理dblink的思路流程和测试脚本
function和procedures对此有依赖
tnsnames的切换与外部dblink的重建
3.导出数据有技巧
完整数据的导出需要注意的设置
停机以及增量追进的办法
4.缩短数据传输时间的优化选择
数据传输的方式
5.导入数据有技巧
导入前的role，profile补建检查
导入效率上的设置：内存，并行，索引控制，归档，logging
导入约束触发器，约束和任务的设置

大坑之对象权限在基于单个schemas的迁移时候会丢失。

6.迁移顺便把索引和表的分离存储，表分区

7.job和scheduler的迁移注意点
注意检测源和目的对比，impdp导入job有缺陷
job的执行时间点

8.编译对象有技巧

9.导入后数据的对比是必要的

10.收集统计信息有技巧

11.一个最小报错的迁移方法建议

1.impdp必检job/scheduler
2.复制schemas时候impdp不会导入系统权限
2.一个最小报错的迁移方法

Database Oracle 数据技术 浅谈oracle技术系列 | Guang Cai Li |