Oracle Life

Linux many lost ticks 和 NIC Copper Link Down

eygle@eygle.com(eygle) — Sat, 06 Feb 2010 15:09:45 +0800

昨天装好的RAC，客户已经打了几个电话咨询，严重质疑RAC的稳定性。

结果是，昨天有人把网线都插拔了一遍，两台机器都挂了；
今天有台机器的网线又被扯，又断了一台。

客户质疑RAC，我只好一遍一遍解释，这个网络啊、心跳啊、VIP啊，对Oracle是灰常灰常重要的。

当然看看日志也有收获，NIC网卡Down的信息，这没什么好说的：

Feb 6 10:13:21 wg1 kernel: bnx2: eth0 NIC Copper Link is Down
Feb 6 10:57:20 wg1 kernel: input: AT Translated Set 2 keyboard on isa0060/serio0
Feb 6 10:57:29 wg1 login(pam_unix)[7424]: session opened for user root by LOGIN(uid=0)
Feb 6 10:57:29 wg1 -- root[7424]: ROOT LOGIN ON tty1
Feb 6 10:58:31 wg1 kernel: bnx2: eth0 NIC Copper Link is Up, 100 Mbps full duplex

确认当时的确是有人动了网线，否则不能排除是否网卡本身不稳定。

又发现有Lost ticks的提示信息：

kernel: warning: many lost ticks.
kernel: If your CPU support 'CPU Frequency scaling',You could ignore this warning
kernel: else your time source seems to be instable or some driver is hogging interupts
kernel: rip __do_softirq+0x4d/0xd0

关于lost ticks找到一些参考信息：

在某些系统上，当首次访问一些 IDE 设备时，可能显示信息warning:many lost ticks（警告：丢失许多嘀嗒信号）。当 IDE 设备没有使用 DMA 进行数据传输时，会显示此信息，因为非 DMA 传输所用的时间比计时器嘀嗒信号间隔长很多（在此期间，处理器无法处理计时器嘀嗒信号中断）。此信息并不表示系统出现故障，也不会导致任何功能问题。如果系统运行的是带 Update 1 或更高版本（含适用于此控制器的更新驱动程序）的 Red Hat Enterprise Linux 4，则连接至 Intel ICH7 IDE控制器的设备不会遇到这种问题。但是，由于其它 IDE 设备无法使用DMA，因此该信息仍然会显示。

在基于 AMD 处理器的系统上，如果启用非一致内存存取 (Non Uniform Memory Access) 功能，则系统在高负载情况下将显示"lost ticks"（丢失嘀嗒信号）信息当运行 Red Hat Enterprise Linux 4（更新 4 之前的版本）的系统处于高负载时，屏幕将显示以下信息：
warning: many lost ticks.（警告：丢失许多嘀嗒信号。）
Your time source seems to be instable or some driver is hogging interrupts
（时间源似乎不稳定或者某些驱动程序干扰中断）
rip __do_softirq+0x4d/0xd0
当在基于 AMD 处理器的系统上使用非一致内存存取 (NUMA) 功能时，将出现此问题。要解决此问题，请将以下参数添加到内核命令行：
console=tty0 numa=off
注：确保 numa=off 为内核命令行中的最后一个选项。如果 numa=off 不是最后一个选项，
将不能识别此参数。
在 Red Hat Enterprise Linux 4 更新 4 中已解决这一问题。

（上面这一篇是DELL的文档上的解释）

您可以安心忽略 RHEL4 U4 丟失滴答計時的訊息(6483062)
在沈重的負載下，RHEL4 訊息檔案與 dmesg 記錄檔可能顯示類似下列的訊息：
Warning many lost ticks
Your time source seems to be unstable or some driver is hogginginterrupts.
此訊息是由不同 IRQ 處理常式之間的爭用所導致，但是對於系統沒有負面影響。
(上面一小段是SUN的文档上的解释)

同时注释一下HPET的全称吧：High Precision Event Timer (HPET)

另外一篇文章则为我解释了CPU Frequency scaling的含义：

CPU Frequency scaling，这一选项允许改变CPU的主频，使CPU在低负荷或使用电池时降低主频，达到省电的目的。

Enable CPUfreq debugging，是否允许调试CPU改变主频的功能，如果要调试，还需要在启动时加上参数。cpufreq.debug=
1：变频技术的内核调试
2：变频技术的驱动调试
4：变频技术的调节器调试

感谢网络，感谢网友们的分享，我要继续不断学习。

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2010/02/linux_many_lost_ticks.html

Redflag Linux安装Oracle 10gR2 RAC记事

eygle@eygle.com(eygle) — Fri, 05 Feb 2010 22:29:51 +0800

作者：eygle 发布在 eygle.com

今天帮助客户在RedFlag Linux上安装了一套Oracle 10gR2 RAC，这是第一次接触红旗Linux，发现其中文化和Windows办公化作的很好，X Windows启动就仿佛Windows 2000的样子。

而且红旗内置了为Oracle而设置的参数和软件包，客户装好了OS之后，我没有打任何rpm包即可正常安装Oracle软件。

基础安准过非常顺利，但是设置高内存是遇到OUT OF MEMORY的错误，Kamus遇到过：

SQL> startup nomount
ORA-27102: out of memory
Linux-x86_64 Error: 28: No space LEFT ON device

这和内核参数 shmall 有关，修改设置 kernel.shmall = 16475728 。

后来离开没多久，客户打电话说两台机器都挂了，我检查了一下message信息：

Feb 5 16:57:22 ywg1 kernel: bnx2: eth1 NIC Copper Link is Down
Feb 5 17:02:55 ywg1 syslogd 1.4.1: restart.
Feb 5 17:02:55 ywg1 syslog: syslogd startup succeeded
Feb 5 17:02:55 ywg1 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Feb 5 17:02:55 ywg1 kernel: 4.S2E0.S2E9 OSHP fails=0x5
Feb 5 17:02:55 ywg1 syslog: klogd startup succeeded
Feb 5 17:02:56 ywg1 irqbalance: irqbalance startup succeeded
Feb 5 17:02:56 ywg1 netfs: Mounting other filesystems: succeeded
Feb 5 17:02:56 ywg1 rc: Starting lm_sensors: succeeded
Feb 5 17:02:56 ywg1 mDNSResponder: startup succeeded
Feb 5 17:02:56 ywg1 acpid: acpid startup succeeded
Feb 5 17:02:57 ywg1 sshd: succeeded
Feb 5 17:02:57 ywg1 crond: crond startup succeeded
Feb 6 01:02:18 ywg1 rc.sysinit: -e

发现有网卡Down的信息，问了客户，有人折腾网线。

再看message信息里有大量的pci告警信息，系统初始化之后就存在，原因未知，不知道有人遇到过没有：

Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 OSHP fails=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 _HPP fail=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 OSHP fails=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 _HPP fail=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 OSHP fails=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 _HPP fail=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 OSHP fails=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 _HPP fail=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 OSHP fails=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 _HPP fail=0x5

安装难度不大，不过遇到不少问题。

-The End-

相关文章|Related Articles

评论数量(1)|Add Comments

本文网址：http://www.eygle.com/archives/2010/02/redflag_linux_rac.html

ORA-00600 4000 及 4194 错误小记

eygle@eygle.com(eygle) — Thu, 04 Feb 2010 21:41:56 +0800

作者：eygle 发布在 eygle.com

刚刚帮朋友处理一则CURRENT日志损坏的恢复，当然是使用到了：
_allow_resetlogs_corruption= TRUE

在初期恢复时出现了ORA-600 4000号错误，这个错误以前写过几个案例，一般没有好的办法，只能通过bbed修复。

不过4000号错误不一定非要用bbed修改坏块，有时候经过反复几次重新启动数据库，就可以暂时规避，尝试将数据导出。

首先出现的是：

Thu Feb 04 13:36:58 2010
Errors in file D:\oracle\admin\orcl\udump\ORA00592.TRC:
ORA-00600: internal error code, arguments: [4000], [3], [], [], [], [], [], []

SMON: disabling cache recovery
Thu Feb 04 13:36:59 2010
ORA-704 signalled during: alter database open resetlogs

多次重启后，出现4194错误：

Thu Feb 04 21:24:41 2010
SMON: enabling cache recovery
SMON: enabling tx recovery
Thu Feb 04 21:24:42 2010
Completed: alter database open
Thu Feb 04 21:24:43 2010
Errors in file D:\oracle\admin\orcl\bdump\orclSMON.TRC:
ORA-00600: internal error code, arguments: [4194], [14], [4], [], [], [], [], []

Thu Feb 04 21:24:44 2010
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
Mem# 0 errs 0: D:\ORACLE\ORADATA\ORCL\REDO02.LOG
Thu Feb 04 21:24:44 2010
Errors in file D:\oracle\admin\orcl\bdump\orclSMON.TRC:
ORA-01595: error freeing extent (7) of rollback segment (2))
ORA-00600: internal error code, arguments: [4194], [14], [4], [], [], [], [], []

但是数据此时可以导出，4194错误出现在回滚段2上，当然也可以解决,这个都是大家所熟悉的了。

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2010/02/ora_600_4000_4194.html

DBA警示录：补丁升级需谨慎

eygle@eygle.com(eygle) — Tue, 02 Feb 2010 08:10:48 +0800

作者：eygle 发布在 eygle.com

前几天，在ITPUB上看到一则网友的经验分享，纪录了一次Patch应用过程的曲折。

在这样曲折的过程中，我们可以注意到，对于一个关键的操作，无论采取怎样认真、细致、繁琐的测试、验证与规划都是值得的。

我们在很多工作中，要求都非常严格，一般都要进行工作步骤列表，制定可执行的回退方案等，有时候大家也觉得繁琐，但是繁琐的结果是可控，在穷举了可能的异常之后，我们才能胸有成竹的进行变更。

转引一下网友的经验之路：

由于种种原因，需要给数据库打patch，并且把db_cache_size和shared_pool_size改小。
先在备库打patch，期间，有一个lib文件提示无法覆盖；去metalink搜，发现note 739963.1,在aix下，升级和打patch过程中，即使所有服务都停止了，也会出现无法覆盖lib文件。
需要用root，执行/usr/sbin/slibclean，然后在重新运行patch apply。

这个步骤不算有太大的问题，不过一般slibclean文件应该是熟悉的，在安装手册里是有明确记录的步骤。

修改参数，原来的db_cache_size=6G,shared_pool_size=4G,需要修改为4G和3G。
然后切换HA，再在主机继续打patch。
谁知道，在切换到备机后，修改过参数的数据库无法启动，直接报错：ora-00064 object is too large to allocate on this o/s.
看来问题是出在修改过的参数上。没办法，创建pfile，将参数修改过来吧......

这个步骤除了参数文件修改引起了一些不应该出现的麻烦，我们认为在备机应用完补丁之后，可以尝试一下在备机启动实例，确认没有问题再切换主机。在备机100%确认验证无误之前，主机的数据库应当不动，至少保证数据库在一台主机可以正常运行。

在发生问题的过程中，为了减少对业务影响，启动应急数据库和另外两台数据库。
应急数据库启动没问题，帐务数据库启动没问题；计费数据库启动失败，提示无法lock控制文件，查看vg状态，都正常，最后查lv的个数，主库26，bcv上有34......

很多经验表明，启用应急数据库是一件极其重大的决定，在没有100%的把握时，尽量不要采取这个措施。当然，如果应急只是作为只读环境，那要简单得多。

bcv问题处理完，暂时业务不用中断，继续打patch。
局方的人将数据库切换到备机，我在主机打patch，又提示文件无法覆盖；执行/usr/sbin/slibclean也不管用！
ps -ef|grep ora发现很多oracle进程存在，ps -ef | grep pmon，没看到有记录；刚开始怀疑是局方没有切换HA，但是登录到备库，发现数据库已经在备库启动。
HA切换脚本是，先停listener，然后再停数据库，umount盘阵。但是不知道为什么还有进程在备库存在。
确认应用都已切换到应急数据库，杀掉主库所有oracle进程。
ps -ef|grep $ORACLE_SID|grep -v ora_|grep LOCAL=NO|awk '{print $2}'|xargs kill
重新打patch，一切正常。

颇为曲折。

后来在bcv验证，数据库启动不了，主要是share pool改小引起；本来以为100%没有事情的事情，最后还是出事了！

墨菲定律，没有100%的安全，所以事前的完善规划是极为重要的。

在这次补丁应用过程中，如果在各个步骤的操作之后，加上一些测试验证步骤，就可以避免异常出现时的忙乱，也就可以多一份从容。

-The End-

相关文章|Related Articles

评论数量(3)|Add Comments

本文网址：http://www.eygle.com/archives/2010/02/dba.html

《深入浅出Oracle》一书的电子版下载

eygle@eygle.com(eygle) — Mon, 01 Feb 2010 08:10:23 +0800

作者：eygle 发布在 eygle.com

前一段时间，有朋友告诉我《深入浅出Oracle》一书的电子版可以在ITPUB下载，我看了一下，果然是完整的版本，效果还颇为不错。

朋友让我找出版社维权，我说不必了，这本书已经有了修订版的《深入解析Oracle》，而且已经出版了3年多，书的销售使命早已经完成了，那么现在，如果有更多的人可以通过电子版看到这本书，也未尝不是一种功德，所以，我同样上传一份在本站，供需要的读者下载。
深入浅出Oracle 下载

注意：这个电子版非我制作，如有PDF质量问题，我并不负责。

那么这个电子版来自何处呢？
我猜想是从出版社流出的，因为第一书中的插图都是彩色版的，显然并不是从纸介质扫描而来；第二，这个完全排印版本，我手中都是没有的，是出版社的最终稿。

如果有人知道确实的来源，我很有兴趣，完全是兴趣。
不过无论如何，如果这本书在以前或者以后，能够让你获得一点点有用的知识，那都是我愿意看到的。

-The End-

相关文章|Related Articles

评论数量(21)|Add Comments

本文网址：http://www.eygle.com/archives/2010/02/headfirst_oracle_download.html

三言两语 - 关于JOB Queue的文档摘要

eygle@eygle.com(eygle) — Sat, 30 Jan 2010 08:20:31 +0800

作者：eygle 发布在 eygle.com

关于JOB调度的问题，有朋友问到（虽然JOB在10g开始以及逐渐被Scheduler所取代），翻了一下文档，摘录一些语句，权作参考：
1.JOB 进程

Job queue processes are used for batch processing. They run user jobs. They can be viewed as a scheduler service that can be used to schedule jobs as PL/SQL statements or procedures on an Oracle instance. Given a start date and an interval, the job queue processes try to run the job at the next occurrence of the interval.

Job queue processes are managed dynamically.Dynamic job queue processes can run a large number of jobs concurrently at a given interval. The job queue processes run user jobs as they are assigned by the CJQ process. Here's what happens:

The coordinator process, named CJQ0, periodically selects jobs that need to be run from the system JOB$ table. New jobs selected are ordered by time.
The CJQ0 process dynamically spawns job queue slave processes (J000...J999) to run the jobs.
The job queue process runs one of the jobs that was selected by the CJQ process for execution. The processes run one job at a time.
After the process finishes execution of a single job, it polls for more jobs. If no jobs are scheduled for execution, then it enters a sleep state, from which it wakes up at periodic intervals and polls for more jobs. If the process does not find any new jobs, then it aborts after a preset interval.

The initialization parameter JOB_QUEUE_PROCESSES represents the maximum number of job queue processes that can concurrently run on an instance. However, clients should not assume that all job queue processes are available for job execution.

2.RAC环境中的JOB调度进程 （link）

Each RAC instance has its own job coordinator. The database monitoring checks that determine whether or not to start the job coordinator do take the service affinity of jobs into account. For example, if there is only one job scheduled in the near future and the job class to which this job belongs has service affinity for only two out of the four RAC instances, only the job coordinators for those two instances will be started.

3.JOB的实例调度 （link）

Because you can create jobs at the instance level, cluster level, or cluster database level, jobs can run on any available host in the cluster database.

You can administer Enterprise Manager jobs at both the database and instance levels. For example, you can create a job at the cluster database level and the job will run on any active instance of the target Oracle RAC database. Or you can create a job at the instance level and the job will only run on the specific instance for which you created it. In the event of a failure, recurring jobs can run on a surviving instance.

相关文章|Related Articles

评论数量(1)|Add Comments

本文网址：http://www.eygle.com/archives/2010/01/rac_job_queue.html

Office、AcitiveSync 以及我所浪费的时间

eygle@eygle.com(eygle) — Fri, 29 Jan 2010 14:43:32 +0800

作者：eygle 发布在 eygle.com

这几天被Office折磨了够呛，记录一下。

1.版本问题
以前卸载了Office 2007，不知怎么卸载的不彻底，所以死活无法再次安装Office 2007，Office 2003装上，但是其处理docx等2007格式文档又麻烦，头疼，就又装了Office 2010 Beta版。

终于可以赞一下微软，感觉Office 2010好用了很多，尤其是微软的拼音输入法2010版，这个版本装来了，我就把Google和Sogou输入法禁用了。

撞上2010,系统进程了增加了一个新的进程OSPPSVC.EXE一看目录结构，是用来进行软件保护的，估计将来类似正版检查等功能要依赖这个进程实现吧：

        E:\>tlist 256
   256 OSPPSVC.EXE
   CWD:     C:\WINDOWS\system32\
   CmdLine: "C:\Microsoft Shared\OfficeSoftwareProtectionPlatform\OSPPSVC.EXE"
   VirtualSize:    40100 KB   PeakVirtualSize:    43944 KB
   WorkingSetSize: 13044 KB   PeakWorkingSetSize: 17564 KB
   NumberOfThreads: 7
   1584 Win32StartAddr:0x01102644 LastErr:0x00000000 State:Waiting
    200 Win32StartAddr:0x77dc3539 LastErr:0x00000000 State:Waiting
   3100 Win32StartAddr:0x006d5184 LastErr:0x00000000 State:Waiting
   3060 Win32StartAddr:0x7c94797d LastErr:0x00000000 State:Waiting
   4044 Win32StartAddr:0x7c930250 LastErr:0x00000000 State:Waiting
   3992 Win32StartAddr:0x7c948c8f LastErr:0x00000000 State:Waiting
    568 Win32StartAddr:0x77e56c7d LastErr:0x000003f0 State:Waiting
                     0x01000000 OSPPSVC.EXE
5.1.2600.5755 shp 0x7c920000 ntdll.dll
5.1.2600.5781 shp 0x7c800000 kernel32.dll

2.OUTLOOK
结果用了新版的OUTLOOK，无法和手机的ActiveSync进行同步，一开始以为是ActiveSync的问题，把手机先删了，结果几百个联系人刷的一声不见了，同步时每次同步到100个联系人时就死掉，发现是微软的Bug，结果又装回Outlook 2003搞定，有人说OUTLOOK大于100联系人不能同步，我没有遇到过，可能是版本问题，ActiveSync 4.5和OUTLOOK 2003协调很好。

折腾这个过程经常出现activesync 同步 outlook 时的 85010014错误，别犹豫，基本是版本问题。

3.MAPI32.DLL / MSMAPI32.DLL
结果是，在安装了那么多微软的产品之后，其中的某些DLL链接库版本出现了问题，启动Outlook时提示类似：
无法启动 Microsoft Office Outlook。MAPI32.DLL 损坏或版本不对。可能是由于安装其他邮件软件造成的。请重新安装 Outlook。
显然重装是没用的，Google上有很多例子了，最后在Common File的共享目录下找到system\MSMAPI\2052 ，把里面的MSMAPI32.DLL 更名，再启动时，Office自动调用安装程序修复一下就成功启动了。

4.MSOCache的问题
MSOCache这个安装Office的Cache大约有1.5G，一般我装完Office毫不犹豫的就干掉了，现在我不了，我决定留着，经常在各种微软的软件安装中存在冲突，可能随时因为覆盖了文件要求修复，没有这Cache就要经常找光盘。

不折腾，No Z turn，再不折腾了，折腾得火冒三丈了！

-The End-

相关文章|Related Articles

评论数量(4)|Add Comments

本文网址：http://www.eygle.com/archives/2010/01/officeacitivesync.html

ORA-07445 cold_qerfxArrayMaxSize 的Bug

eygle@eygle.com(eygle) — Tue, 26 Jan 2010 10:28:40 +0800

作者：eygle 发布在 eygle.com

客户的10.2.0.2数据库遇到了这样一个问题：

Sat Jan 23 02:01:00 2010
Errors in file /CMP/saptrace/background/cmp_m000_26819.trc:
ORA-00081: address range [0x600000000009C450, 0x600000000009C454) is not readable
ORA-07445: exception encountered: core dump [$cold_qerfxArrayMaxSize()+7456] [SIGBUS] [Invalid address alignment] [0x00000002C] [] []

经过Metalink文档：386727.1 确认，这是一个Bug，仅见于HP-UX Itanium环境，在10.2.0.3中修正，一般不会带来严重影响。
在跟踪文件中记录了更为详尽的信息：

ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [$cold_qerfxArrayMaxSize()+7456] [SIGBUS] [Invalid address alignment] [0x00000002C] [] []
Current SQL statement for this session:
INSERT INTO wrh$_bg_event_summary
            (snap_id, dbid, instance_number, event_id, total_waits,
             total_timeouts, time_waited_micro)
   SELECT   /*+ ORDERED USE_NL(E) */
            :snap_id, :dbid, :instance_number, e.event_id,
            SUM (e.total_waits), SUM (e.total_timeouts),
            SUM (e.time_waited_micro)
       FROM v$session bgsids, v$session_event e
      WHERE bgsids.TYPE = 'BACKGROUND' AND bgsids.SID = e.SID
   GROUP BY e.event_id

不同的环境触发的SQL可能不同，但是通常ORA-07445和ORA-00081同时出现。
这是由于C编译器的问题导致的：

The problem is reported in <<bug:5382798>> and found to be an issue with the C compiler used on HP Itanium to compile the Oracle 10.2 code.

相应的Patch是： Patch:5442780

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2010/01/ora-07445_cold_qerfxarraymaxsize.html

使用RMAN验证备份的有效性

eygle@eygle.com(eygle) — Tue, 26 Jan 2010 08:01:37 +0800

作者：eygle 发布在 eygle.com

RMAN提供VALIDATE的命令，可以用于校验备份集的有效性，常用命令如下：
restore validate controlfile;
restore validate database;
验证命令会建议备份的存在性、完好性和可恢复性，帮助我们确认备份的有效与否。

比如验证控制文件和参数文件：

RMAN> restore validate controlfile;

Starting restore at 25-JAN-10
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=388 devtype=DISK

channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /opt/oracle/product/db10g/dbs/c-1341966532-20100125-01
channel ORA_DISK_1: restored backup piece 1
piece handle=/opt/oracle/product/db10g/dbs/c-1341966532-20100125-01 tag=TAG20100125T094817
channel ORA_DISK_1: validation complete, elapsed time: 00:00:02
Finished restore at 25-JAN-10

RMAN> restore validate spfile;

Starting restore at 25-JAN-10
using channel ORA_DISK_1

channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /opt/oracle/product/db10g/dbs/c-1341966532-20100116-00
channel ORA_DISK_1: restored backup piece 1
piece handle=/opt/oracle/product/db10g/dbs/c-1341966532-20100116-00 tag=TAG20100116T033113
channel ORA_DISK_1: validation complete, elapsed time: 00:00:02
Finished restore at 25-JAN-10

验证全备份一般会很慢，谨慎试验：

RMAN> restore validate database;

Starting restore at 25-JAN-10
using channel ORA_DISK_1

data file 22 will be created automatically during restore operation
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /data3/ordrbak/orderfullback_order_20100124_4691
channel ORA_DISK_1: restored backup piece 1
piece handle=/data3/ordrbak/orderfullback_order_20100124_4691 tag=order
channel ORA_DISK_1: validation complete, elapsed time: 00:02:36
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /data3/ordrbak/orderfullback_order_20100124_4692
channel ORA_DISK_1: restored backup piece 1
piece handle=/data3/ordrbak/orderfullback_order_20100124_4692 tag=order
channel ORA_DISK_1: validation complete, elapsed time: 00:01:45
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /data3/ordrbak/orderfullback_order_20100124_4693
channel ORA_DISK_1: restored backup piece 1
piece handle=/data3/ordrbak/orderfullback_order_20100124_4693 tag=order
channel ORA_DISK_1: validation complete, elapsed time: 00:00:26
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /data3/ordrbak/orderfullback_order_20100124_4694
channel ORA_DISK_1: restored backup piece 1
piece handle=/data3/ordrbak/orderfullback_order_20100124_4694 tag=order
channel ORA_DISK_1: validation complete, elapsed time: 00:00:56
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /data3/ordrbak/orderfullback_order_20100124_4695
channel ORA_DISK_1: restored backup piece 1
piece handle=/data3/ordrbak/orderfullback_order_20100124_4695 tag=order
channel ORA_DISK_1: validation complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /data3/ordrbak/orderfullback_order_20100124_4696
channel ORA_DISK_1: restored backup piece 1
piece handle=/data3/ordrbak/orderfullback_order_20100124_4696 tag=order
channel ORA_DISK_1: validation complete, elapsed time: 00:00:04
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /data3/ordrbak/orderfullback_order_20100124_4697
channel ORA_DISK_1: restored backup piece 1
piece handle=/data3/ordrbak/orderfullback_order_20100124_4697 tag=order
channel ORA_DISK_1: validation complete, elapsed time: 00:00:07
failover to previous backup

data file 22 will be created automatically during restore operation
Finished restore at 25-JAN-10

验证命令并不会真正执行恢复，所以可以减去异机测试等的麻烦。

-The End-

相关文章|Related Articles

评论数量(3)|Add Comments

本文网址：http://www.eygle.com/archives/2010/01/rman_validate_backup.html

《Oracle DBA手记》- 第二章PDF版本下载

eygle@eygle.com(eygle) — Mon, 25 Jan 2010 11:43:01 +0800

作者：eygle 发布在 eygle.com

此前已经发布了《Oracle DBA手记》的第一章PDF版本，现在发布第二章的PDF版本。

这一章是老杨（Yangtingkun）所著，目前的版本是我编辑整理后的章节，出版印刷的版式有所不同。老杨的勤奋与著作之丰近2年间无人能及，这本书非常幸运的是邀请到他一展所长。我非常期待老杨将来能够再出版独立著作，对自己进行总结。

好了，现在发布《Oracle DBA手记》- 第二章下载链接，希望大家支持。

-The End-

相关文章|Related Articles

评论数量(4)|Add Comments

本文网址：http://www.eygle.com/archives/2010/01/yangtingkun_oraclenotes.html

Oracle Life

Linux many lost ticks 和 NIC Copper Link Down

Redflag Linux安装Oracle 10gR2 RAC记事

ORA-00600 4000 及 4194 错误小记

DBA警示录：补丁升级需谨慎

《深入浅出Oracle》一书的电子版下载

三言两语 - 关于JOB Queue的文档摘要

Office、AcitiveSync 以及 我所浪费的时间

ORA-07445 cold_qerfxArrayMaxSize 的Bug

使用RMAN验证备份的有效性

《Oracle DBA手记》- 第二章PDF版本下载

Office、AcitiveSync 以及我所浪费的时间