>>读者群| 网站统计数据 | 热点排行 回复 | egoSurf | gqgai | eygle | 百度eygle |11g| ACE en cn

置顶:《Oracle DBA手记》及个人图书信息汇总

《Oracle DBA手记》终于出版了，虽然到达各大书店仍然需要一段时间，但是我还是先将关于这本书以及我的所有图书的相关信息整理出来，供读者们参考。

我的淘宝店地址: http://shop36913374.taobao.com/
如果大家不方便买书，可以在我的淘宝店订购，我可以负责给大家邮递。
我的个人信息讨论新闻组 Eygle Group,欢迎加入：
https://groups.google.com/group/eygle

谢谢大家的支持。

1.《Oracle DBA手记》一书相关信息

样章试读：
第一章 - 下载 | 第二章 - 下载

样章试读：
第一章连载 - 之一 | 第一章及第四章下载

Posted by eygle at 11:53 AM | Permalink | Comments (9) | Books (149)

February 6, 2010

Linux many lost ticks 和 NIC Copper Link Down

昨天装好的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-

Posted by eygle at 3:09 PM | Permalink | Comments (3) | Unix&Linux (59)

February 5, 2010

Redflag Linux安装Oracle 10gR2 RAC记事

今天帮助客户在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-

Posted by eygle at 10:29 PM | Permalink | Comments (7) | Advanced (73) | Oracle10g/11g (88)

February 4, 2010

ORA-00600 4000 及 4194 错误小记

刚刚帮朋友处理一则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-

Posted by eygle at 9:41 PM | Permalink | Comments (0) | Backup&Recovery (75) | Case (94)

February 2, 2010

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

前几天，在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-

Posted by eygle at 8:10 AM | Permalink | Comments (3) | Case (94) | FAQ (161)

February 1, 2010

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

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

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

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

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

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

-The End-

Posted by eygle at 8:10 AM | Permalink | Comments (24) | Books (149)