Oracle Life

使用errorstack跟踪ORA-01438错误

eygle@eygle.com(eygle) — Mon, 13 Jul 2009 12:02:30 +0800

©作者：eygle 发布在 eygle.com

客户系统出现如下ORA-01438错误，提示数据的精度超过允许值，是后台Job调度的任务：

Mon Jul 13 10:27:31 2009
Errors in file /admin/erpdb/bdump/erpdb1_j000_447020.trc:
ORA-12012: error on auto execute of job 22
ORA-01438: value larger than specified precision allowed for this column
ORA-06512: at "ERP.TIMRDU", line 13
ORA-06512: at line 1

跟踪文件中缺省的不会记录具体的SQL、绑定变量等信息，我们可以通过ErrorStack进行后台跟踪，获得更详细的信息，执行如下SQL：

alter system set events='1438 trace name errorstack forever,level 10';

然后可以手工执行以下存储过程，获得跟踪文件，再关闭跟踪：

alter system set events='1438 trace name errorstack off';

在Oracle 10g中，这样的操作会被记录到日志文件中：

Mon Jul 13 10:48:39 2009
OS Pid: 541528 executed alter system set events '1438 trace name Errorstack forever,level 10'
Mon Jul 13 10:56:06 2009
Errors in file /admin/erpdb/udump/erpdb1_ora_267056.trc:
ORA-01438: value larger than specified precision allowed for this column

Mon Jul 13 10:56:08 2009
Trace dumping is performing id=[cdmp_20090713105608]
Mon Jul 13 10:57:15 2009
OS Pid: 541528 executed alter system set events '1438 trace name Errorstack off'

接下来分析获得的跟踪文件，就可以获得SQL文本线索，找到根本问题。

ITPUB上有一则极为经典详细的分析： http://www.itpub.net/thread-956435-1-1.html

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/errorstack_ora_01438.html

断电故障导致 ASM DiskGroup 故障及恢复案例

eygle@eygle.com(eygle) — Thu, 09 Jul 2009 09:45:07 +0800

©作者：eygle 发布在 eygle.com

ASM在RAC环境中的使用已经极其广泛，但是往往由于对ASM的认识不够，很多时候在处理故障时会陷入谜团，前一段在客户环境中就遇到了一个ASM的棘手问题。

客户由于断电导致了存储故障，进而使得部分磁盘对主机不可见，某个磁盘组无法加载，此时客户尝试过重启启动数据库，就遇到了如下错误：

Thu Jun 25 05:00:11 2009
Errors in file /u01/app/oracle/admin/billing/udump/billing1_ora_8184.trc:
ORA-15062: ASM disk is globally closed
ORA-15025: could not open disk '/dev/rdsk/c12t0d2'
ORA-27041: unable to open file
HPUX-ia64 Error: 6: No such device or address
Additional information: 3
Thu Jun 25 05:00:29 2009
Errors in file /u01/app/oracle/admin/billing/udump/billing1_ora_8761.trc:
ORA-15062: ASM 磁盘已全局关闭
ORA-15025: 无法打开磁盘 '/dev/rdsk/c12t0d2'
ORA-27041: 无法打开文件
HPUX-ia64 Error: 6: No such device or address
Additional information: 3
Thu Jun 25 05:00:29 2009
Errors in file /u01/app/oracle/admin/billing/udump/billing1_ora_8759.trc:
ORA-15062: ASM disk is globally closed
ORA-15025: could not open disk '/dev/rdsk/c12t0d2'
ORA-27041: unable to open file
HPUX-ia64 Error: 6: No such device or address
Additional information: 3

注意在这个提示中，有一个重要提示：ORA-15062: ASM 磁盘已全局关闭。

也就是说，由于磁盘无法访问，ASM将磁盘在全局关闭，ASM磁盘组也不可用。

进一步的，如果强制打开数据库，Oracle会将该磁盘组的所有文件Offline离线处理，然后Open数据库：

Thu Jun 25 06:10:41 2009
KCF: write/open error block=0xce0db online=1
     file=148 +DG_DATA_03/billing/datafile/tbs_table_20.256.654268217
     error=15081 txt: ''
Automatic datafile offline due to write error on
file 148: +DG_DATA_03/billing/datafile/tbs_table_20.256.654268217
KCF: write/open error block=0x72b online=1
     file=21 +DG_DATA_03/billing/datafile/tbs_idx_20.265.654273237
     error=15078 txt: ''
Automatic datafile offline due to write error on
file 21: +DG_DATA_03/billing/datafile/tbs_idx_20.265.654273237
KCF: write/open error block=0x4c6e9 online=1
     file=50 +DG_DATA_03/billing/datafile/tbs_dailytable_20.270.656595577
     error=15078 txt: ''

这就造成了进一步的一个现象，在数据库看来，始终有一个磁盘组是Mounted的状态，数据库无法连接，也就无法访问其中的数据：

SQL> select name,state from v$asm_diskgroup_stat;
NAME                           STATE
------------------------------ -----------
DG_DATA_01                     CONNECTED
DG_DATA_02                     CONNECTED
DG_DATA_03                     MOUNTED

这其实很正常，Oracle不访问该DG中的磁盘，该磁盘就保持了MOUNTED状态，我们只要尝试访问该磁盘中的文件，该磁盘组就会显示为数据库连接的CONNECTED状态。

我们简单的通过RMAN的COPY命令就激活了该磁盘组的磁盘访问：

RMAN> copy datafile '+DG_DATA_03/billing/datafile/tbs_20.264.654269073' to '/backup/a.dbf';

对ASM的学习和认识，还要继续加深！

-The End-

相关文章|Related Articles

评论数量(2)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/asm_diskgroup_mounted_status.html

恩墨科技将举行Oracle性能优化与诊断案例培训

eygle@eygle.com(eygle) — Wed, 08 Jul 2009 09:00:04 +0800

©作者：eygle 发布在 eygle.com

课程说明：在经过较长时间的积累与总结之后，我们设计了"Oracle性能优化与诊断案例"培训课程，这个课程面向具有一定工作经验的Oracle数据库从业人员，希望能够以理论与实践相结合，将我们的经验更好的传达出来。

开课时间：预计于7月底或8月初，在北京开课，具体时间依据报名人数确定

课程周期：课程总计四天，计划选择周四、周五、周六、周日，连续四天进行。

培训讲师： 盖国强（ Eygle ），讲师介绍关于EYGLE

培训费用：每人5800元（开具培训发票）

报名方式：请发送报名邮件至 eygle@eygle.com 报名，或者通过MSN: eygle@hotmail.com 与我联络。

设计目标：很多Oracle技术人员在经过了很多培训或长时间的自学之后，往往仍然会感到不能对所学知识融会贯通，在实践中很难游刃有余的解决现实问题，针对这些困扰，我们设计了这个课程。

课程主要目标有两个：

1. 通过对Oracle技术知识全面、深入、融合的讲解，帮助学员将所学知识融会贯通起来

2. 通过将理论与实践的诊断案例相结合，帮助学员构建系统的解决问题的思路与方法

通过培训，我们希望能够帮助学员更加深入的了解Oracle的知识体系，形成稳健的问题诊断与解决方法，从而切实提高大家的数据库应用与管理水平。

本课程的设计时间为4天，主要内容如下（也欢迎将感兴趣、关心的内容通过邮件向我们提交（发送邮件至：eygle@eygle.com ），我们将适当调整与完善授课内容）：

培训模块内容	培训提纲	学时
Oracle数据库学习与研究方法	◆ 如何开始及深入学习Oracle技术-Eygle的经验方法谈 ◆ 案例讲解循序渐进、深入浅出的学习方法 ◆ 深入解析Oracle的时间维度，以及时间分析法 ◆ JOB任务调度与Oracle的时间度量 ◆ DB Time与数据库性能的快速评估 ◆ DBA数据库管理守则 ◆ DBA最常见误操作案例分析 ◆ Oracle数据库故障诊断及分析方法 ◆ ORA-600 2662案例解析、模拟与实验 ◆ 100% IO使用的ERP系统之优化案例实践 ◆ 其他诊断案例与实践讲解	2学时
循序渐进探讨数据库的创建与迁移	◆ Oracle数据库的创建解析 ◆ 数据库创建脚本解析 ◆ 10046事件、sql_trace以及Oracle的等待事件 ◆ RMAN与数据库Clone ◆ Oracle的Auxiliary优化思想与借鉴 ◆ 字节序以及传输表空间技术 ◆ 深入解析字符集、自定义字符以及字符集相关故障处理 ◆ Truncate的本质、临时表的Truncate、以及相关恢复案例与实践 ◆ Oracle 10g Truncate 导致系统性能下降之案例分析 ◆ 其他诊断案例与实践讲解	2学时
深入解析Oracle数据库的启动、关闭与初始化	◆ Oracle的启动与内部初始化-Nomount/Mount/Open深入解析 ◆ 初始化参数、sql.bsq以及数据库的初始化 ◆ Nomout / Mount阶段ORA-600案例解析 ◆ 见微知著-从启动错误提示判断数据库故障 ◆ 控制文件、SCN与数据库的恢复控制 ◆ 防患未然-全面理解数据库的关闭与中止 ◆ Redo、控制文件在启动及运行过程的案例分析与实践 ◆ 其他诊断案例与实践讲解	2学时
Oracle的内存结构	◆ Oracle实例与数据库概览 ◆ Oracle的内存与进程结构 ◆ Buffer Cache等内存结构的优化与实践 ◆ 常见ERP软件Cache使用优化案例实践 ◆ 闩、锁，竞争与等待 ◆ 牵一发动全身-Oracle体系结构全面串联 ◆ Oracle10g、Oracle11g内存管理原理与变迁 ◆ Cache Buffer Chain与Library Cache等常见Latch优化案例 ◆其他诊断案例与实践讲解	3学时
Oracle的物理结构	◆ 控制文件、日志文件与数据库管理 ◆ 从DMT到LMT、从FLM到ASSM-Oracle存储技术的变迁 ◆ HWM管理与Oracle性能及实践案例分析 ◆ Oracle的UNDO管理技术与内部原理 ◆ SYSTEM、SYSAUX，从内部变革看Oracle优化思想 ◆ Oracle的分区技术及Oracle11g分区新特性 ◆ TB级数据库核心性能问题之数据表存储分析案例 ◆ 某金融系统亿级表之索引问题导致性能骤减之案例分析 ◆ HWM及空间回收问题导致某制造系统问题之案例分析 ◆其他诊断案例与实践讲解	3学时
Oracle的恢复体系结构	◆ Oracle的Redo与归档技术 ◆ 检查点与数据库恢复 ◆ Redo机制、内容与内部原理 ◆ Oracle DataGuard技术、手工DataGuard机制与实践演练 ◆ Oracle进程与恢复机制、并行恢复与Oracle恢复进度确认 ◆ 特殊情况下的恢复原理与实践 ◆ 4节点 RAC REDO优化实现10倍性能提升案例详解 ◆ 电信级TB海量 ASM数据库紧急恢复案例全过程分析 ◆ 其他诊断案例与实践讲解	3学时
Oracle SQL原理	◆ Oracle的共享池技术与原理 ◆ Oracle的共享池分区技术及诊断案例 ◆ ORA-04031错误分析及解决 ◆ Oracle的SQL解析与执行 ◆ 10053事件与SQL的解析 ◆ Oracle的优化器-RBO、CBO与Oracle10g的变迁 ◆ 某大型ERP系统SQL的执行计划分析与优化实践 ◆ 其他诊断案例与实践讲解	3学时
Oracle的优化方法	◆ Oracle的优化概念 ◆ Oracle优化方法论 ◆ Oracle等待事件分析法 ◆ 从Statspack到AWR、ADDM - Oracle优化思想的进化 ◆ 分析Statspack/AWR报告以快速定位Oracle数据库的性能瓶颈 ◆ 存储与系统规划设计优化 ◆ 64CPU/98G RAM TB级数据库全系统优化方案设计与实施精讲 ◆ 优化案例与客户实践讲解	6学时

顾问咨询与技术支持服务：除了培训之外，我们还为客户提供各类Oracle数据库相关的顾问咨询与技术支持服务。

很多企业在购买了Oracle软件之后，往往由于高昂的服务费用而放弃了购买官方服务，导致数据库系统得不到很好的技术支持与服务，针对这类情况，面向国内企业，我们全面推出了各种超值的技术服务，这些服务包括：

服务类型	服务描述
基本支持服务	基本支持服务面向小型企业用户，通过网络或电话向用户提供5x8（每周5天，工作日8小时）技术咨询、问题解答、后备支持服务，这些服务可以用快捷的通道、直接的沟通，帮助用户解决技术困惑或数据库问题。
银牌支持服务	银牌支持服务，在基本服务支持之外，还向客户提供一定人天的现场服务，帮助用户对数据库进行产品安装、补丁升级、健康检查及性能优化等服务，通过现场服务为用户解决各类紧急故障，帮助用户优化系统性能、提升服务品质等。
金牌支持服务	金牌支持服务向客户提供全面的技术支持服务，7x24不间断的后备支持，在客户需要时，不限时间与次数的提供现场服务，在数据库规划、升级、优化、灾难恢复、故障解决等全方位为用户提供专业服务。
专家顾问服务	除了按年提供的服务之外，我们还可以为用户提供单次、计天的专家顾问服务，服务内容包括以Oracle数据库为主的性能优化、升级迁移、灾难恢复等。

如果您需要Oracle数据库方面的相关技术服务，相信我们能够为您提供可靠的协助支持！

额外说明：

对于参加培训的学员，您将有机会可以得到以下附加的增值服务和机会：

1. 您将可以得到讲师的个人Oracle著作

2. 在时间和机会满足的条件下，您将可能得到和讲师或顾问亲临客户现场的观摩、学习机会

3. 您将可以得到1个月的免费数据库基本支持服务

期待我们的课程与服务能够提升您的技能，满足您的业务需要！

相关文章|Related Articles

评论数量(11)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/performance_tuning_db_diag.html

dbms_system.ksdwrt:向告警日志文件写指定信息

eygle@eygle.com(eygle) — Tue, 07 Jul 2009 10:11:31 +0800

©作者：eygle 发布在 eygle.com

有朋友提问：如何向Oracle的告警日志写入自己指定的信息！
其实Oracle的DBMS_SYSTEM包的KSDWRT过程就可以实现这个功能：

如在SQL*PLUS发出如下命令：

SQL> exec sys.dbms_system.ksdwrt(2, 'ORA-99999 :Just For testing');

PL/SQL procedure successfully completed.

此时在告警日志文件中就会记录如下一行信息：

Tue Jul 7 19:37:46 2009
ORA-99999 :Just For testing

DBMS_SYSTEM包的功能及其强大：

SQL> desc dbms_system
PROCEDURE DIST_TXN_SYNC
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
INST_NUM                       NUMBER                  IN
PROCEDURE GET_ENV
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
VAR                            VARCHAR2                IN
VAL                            VARCHAR2                OUT
PROCEDURE KCFRMS
PROCEDURE KSDDDT
PROCEDURE KSDFLS
PROCEDURE KSDIND
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
LVL                            BINARY_INTEGER          IN
PROCEDURE KSDWRT
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
DEST                           BINARY_INTEGER          IN
TST                            VARCHAR2                IN
PROCEDURE READ_EV
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
IEV                            BINARY_INTEGER          IN
OEV                            BINARY_INTEGER          OUT
PROCEDURE SET_BOOL_PARAM_IN_SESSION
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
SID                            NUMBER                  IN
SERIAL#                        NUMBER                  IN
PARNAM                         VARCHAR2                IN
BVAL                           BOOLEAN                 IN
PROCEDURE SET_EV
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
SI                             BINARY_INTEGER          IN
SE                             BINARY_INTEGER          IN
EV                             BINARY_INTEGER          IN
LE                             BINARY_INTEGER          IN
NM                             VARCHAR2                IN
PROCEDURE SET_INT_PARAM_IN_SESSION
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
SID                            NUMBER                  IN
SERIAL#                        NUMBER                  IN
PARNAM                         VARCHAR2                IN
INTVAL                         BINARY_INTEGER          IN
PROCEDURE SET_SQL_TRACE_IN_SESSION
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
SID                            NUMBER                  IN
SERIAL#                        NUMBER                  IN
SQL_TRACE                      BOOLEAN                 IN
PROCEDURE WAIT_FOR_EVENT
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
EVENT                          VARCHAR2                IN
EXTENDED_ID                    BINARY_INTEGER          IN
TIMEOUT                        BINARY_INTEGER          IN

KSDWRT共有两个输入参数，一个用来指定写出的目的地，一个用来指定消息文本：

PROCEDURE KSDWRT
Argument Name                  Type                    In/Out Default?
------------------------------ ----------------------- ------ --------
DEST                           BINARY_INTEGER          IN
TST                            VARCHAR2                IN

其中目的地参数有三个选项：

1 - Write to trace file.
2 - Write to alertlog.
3 - Write to both.

较为常见的，在通过触发器屏蔽某些危险操作后，我们可以用这个过程在告警日志中记录提示警告！

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/dbms_systemksdw.html

恩墨科技为某企业提供紧急数据恢复服务

eygle@eygle.com(eygle) — Tue, 07 Jul 2009 08:21:54 +0800

©作者：eygle 发布在 eygle.com

近日，恩墨科技接到某企业的求助请求，因为硬盘故障，导致数据库崩溃，请求协助恢复数据。

我们检查用户的数据库环境，发现虽然RAID 5的硬盘已经恢复，但是发现数据文件遭到了损坏，出现了坏块，在数据库的日志中，报出以下异常：

Fri Jul 3 15:58:16 2009
Started recovery at
Thread 1: logseq 10551, block 80880, scn 0.0
Recovery of Online Redo Log: Thread 1 Group 3 Seq 10551 Reading mem 0
Mem# 0 errs 0: /opt/oracle/oradata/erpdb/redo03.log
***
Corrupt block relative dba: 0x06428528 (file 125, block 165160)
Fractured block found during crash/instance recovery
Data in bad block -
type: 6 format: 2 rdba: 0x06428528
last change scn: 0x0000.8f325e2e seq: 0x1 flg: 0x06
consistency value in tail: 0x47a20601
check value in block header: 0x24c3, computed block checksum: 0x198f
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x06428528 (file 125, block 165160) found same corrupted data

进一步的恢复过程中，数据库出现如下错误：

Fri Jul 3 15:58:16 2009
Errors in file /opt/oracle/admin/erpdb/udump/erpdb_ora_4759.trc:
ORA-07445: exception encountered: core dump [ksmfrs()+227] [SIGSEGV] [unknown code] [0x000000000] [] []
Fri Jul 3 15:58:17 2009
Errors in file /opt/oracle/admin/erpdb/udump/erpdb_ora_4759.trc:
ORA-07445: exception encountered: core dump [ksmerr()+106] [SIGSEGV] [unknown code] [0x000000000] [] []
ORA-00607: Internal error occurred while making a change to a data block
ORA-00602: internal programming exception
ORA-07445: exception encountered: core dump [ksmfrs()+227] [SIGSEGV] [unknown code] [0x000000000] [] []

一系列的ORA-07445错误表明数据库遇到了大麻烦，当尝试进行Recover的过程中，ORA-00607表明出现了数据块的不一致。
由于没有备份，恢复起来就比较麻烦，所以我仍然想说的是：备份重于一切。

由于数据块出现了损坏，其中的数据不可避免的遭到了损失，我们可以通过BBED等工具修复数据块，虽然可以骗过数据库，强制启动数据库，但是无法骗过自己，其中的数据难免遭到损失。

当然我们可以做的另外一件事是通过LOGMNR来解析日志，通过SQL_REDO来还原部分数据，找出受到影响的事务，恢复数据。

最终我们帮助用户成功的启动数据库，在业务生产到来之前恢复了服务。

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/enmotech_xrecovery.html

DataGuard ORA-01111文件创建失败问题解决

eygle@eygle.com(eygle) — Mon, 06 Jul 2009 08:04:17 +0800

©作者：eygle 发布在 eygle.com

在DataGuard环境中，由于备库的路径、存储、空间等问题，可能会导致文件创建失败的问题。
在正常情况下，如果配置正确，文件是能够自动创建的，出错时可能的日志如下：

Sun Jul 5 23:28:23 2009
Media Recovery Log /opt/oracle/archivelog/1_47_689973859.dbf
Media Recovery Log /opt/oracle/archivelog/1_48_689973859.dbf
Media Recovery Log /opt/oracle/archivelog/1_49_689973859.dbf
WARNING: File being created with same name as in Primary
Existing file may be overwritten
File #5 added to control file as 'UNNAMED00005'.
Originally created as:
'/opt/oracle/oradata/mmstest/test01.dbf'
Recovery was unable to create the file as:
'/opt/oracle/oradata/mmstest/test01.dbf'
Errors with log /opt/oracle/archivelog/1_49_689973859.dbf

出现此种情况，进一步的告警日志可能会报出如下错误：

Sun Jul 5 23:28:28 2009
Errors in file /opt/oracle/admin/mmstest/bdump/mmstest_mrp0_32062.trc:
ORA-19502: write error on file "/opt/oracle/oradata/mmstest/test01.dbf", blockno 1024 (blocksize=8192)
ORA-27072: File I/O error
Linux Error: 9: Bad file descriptor
Additional information: 4
Additional information: 1024
Additional information: 397312
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Sun Jul 5 23:28:29 2009
Errors in file /opt/oracle/admin/mmstest/bdump/mmstest_mrp0_32062.trc:
ORA-19502: write error on file "/opt/oracle/oradata/mmstest/test01.dbf", blockno 1024 (blocksize=8192)
ORA-27072: File I/O error
Linux Error: 9: Bad file descriptor
Additional information: 4
Additional information: 1024
Additional information: 397312

以及尝试recover时可能再次出现：

Mon Jul 6 01:36:30 2009
Errors in file /opt/oracle/admin/mmstest/bdump/mmstest_mrp0_32589.trc:
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/opt/oracle/product/10.2.0/dbs/UNNAMED00005'
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/opt/oracle/product/10.2.0/dbs/UNNAMED00005'

出现这些错误时MRP进程会停止工作，恢复中断：

Mon Jul 6 01:36:30 2009
MRP0: Background Media Recovery process shutdown (mmstest)

在修正相关的问题之后，我们可以进行如下一系列的操作来恢复这些错误：

SQL> alter system set standby_file_management=manual;

System altered.

SQL> alter database create datafile
2 '/opt/oracle/product/10.2.0/dbs/UNNAMED00005' as '/opt/oracle/oradata/mmstest/test01.dbf';

Database altered.

SQL> alter system set standby_file_management=auto;

System altered.

SQL> recover managed standby database disconnect from session;
Media recovery complete.

此时备库的恢复得以继续：

Mon Jul 6 01:41:14 2009
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=MEMORY;
Mon Jul 6 01:42:13 2009
alter database create datafile
'/opt/oracle/product/10.2.0/dbs/UNNAMED00005' as '/opt/oracle/oradata/mmstest/test01.dbf'
Mon Jul 6 01:42:14 2009
Completed: alter database create datafile
'/opt/oracle/product/10.2.0/dbs/UNNAMED00005' as '/opt/oracle/oradata/mmstest/test01.dbf'
Mon Jul 6 01:42:26 2009
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=MEMORY;
Mon Jul 6 01:42:40 2009
ALTER DATABASE RECOVER managed standby database disconnect from session
Mon Jul 6 01:42:40 2009
Attempt to start background Managed Standby Recovery process (mmstest)
MRP0 started with pid=16, OS id=32607
Mon Jul 6 01:42:41 2009
MRP0: Background Managed Standby Recovery process started (mmstest)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 3 processes
Media Recovery Log /opt/oracle/archivelog/1_49_689973859.dbf
Mon Jul 6 01:42:47 2009
Completed: ALTER DATABASE RECOVER managed standby database disconnect from session
Mon Jul 6 01:43:02 2009
Media Recovery Log /opt/oracle/archivelog/1_50_689973859.dbf
Mon Jul 6 01:43:17 2009
Media Recovery Log /opt/oracle/archivelog/1_51_689973859.dbf
Mon Jul 6 01:43:32 2009
Media Recovery Log /opt/oracle/archivelog/1_52_689973859.dbf
Mon Jul 6 01:43:45 2009
Media Recovery Log /opt/oracle/archivelog/1_53_689973859.dbf

正常情况下的配置及文件创建，其提示应该类似如下过程：

Mon Jul 6 01:53:28 2009
WARNING: File being created with same name as in Primary
Existing file may be overwritten
Recovery created file /opt/oracle/oradata/mmstest/wztest02.dbf
Successfully added datafile 7 to media recovery
Datafile #7: '/opt/oracle/oradata/mmstest/wztest02.dbf'
Media Recovery Log /opt/oracle/archivelog/1_80_689973859.dbf

在这个测试环境中，是由于空间不足导致的文件创建失败。

注意，在以上步骤中，如果standby_file_management设置为AUTO时，执行create命令会遇到如下错误：

SQL> alter database rename
2 file '/opt/oracle/product/10.2.0/dbs/UNNAMED00005' to '/opt/oracle/oradata/mmstest/test01.dbf';

alter database rename
*
ERROR at line 1:
ORA-01511: error in renaming log/data files
ORA-01275: Operation RENAME is not allowed if standby file management is　automatic.

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/dataguard_ora_01111.html

Phpmyadmin:配置文件Wrong permissions

eygle@eygle.com(eygle) — Sun, 05 Jul 2009 18:54:10 +0800

©作者：eygle 发布在 eygle.com

许久没有用PHPMYADMIN，今天启动了发现访问不了，一行精确的错误提示：

Wrong permissions on configuration file, should not be world writable

这是说权限出现了问题，而且是权限过高了。

Google了一下，发现解决也很简单：
phpmyadmin要运行在755权限下，运行chmod -R 755 /opt/phpmyadmin即可

看来phpmyadmin的安全意识还是很强的，这非常重要，没有安全守护的phpmyadmin是太危险了。

相关文章|Related Articles

评论数量(2)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/phpmyadmin_wrong_permissions.html

Granule 与 Redo Log Buffer (log_buffer) 的关系

eygle@eygle.com(eygle) — Thu, 02 Jul 2009 11:49:37 +0800

©作者：eygle 发布在 eygle.com

不少朋友一直记得以前的优化推荐：Redo Log Buffer不要高于3M。

而实际上大家也发现，从Oracle10g开始，Redo Log Buffer缺省的已经是大大超过了原来的想象。
从Oracle 9i引入了Granule的概念后，在Oracle10g中，Oracle的内存分配会为'Fixed SGA Size'和'Redo Buffers'共享整数倍个Granule。

看看不同SGA设置下的内存分配情况：

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> select * from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers','Granule Size');

NAME                                  BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size                      1267212 No
Redo Buffers                       15507456 No
Granule Size                       16777216 No

SQL> select sum(bytes)/1024/1024 from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers');

SUM(BYTES)/1024/1024
--------------------
            15.99757

在另外的系统中，供分配了2个Granule，每个4M：

SQL> select * from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers','Granule Size');

NAME                                  BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size                      1263320 No
Redo Buffers                        7122944 No
Granule Size                        4194304 No

SQL> select sum(bytes)/1024/1024 from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers');

SUM(BYTES)/1024/1024
--------------------
          7.99776459

摘录一部分Oracle文档中关于Granule的描述供参考：

With dynamic SGA, the unit of allocation is called a granule. Components, such as the buffer cache, the shared pool, the java pool, and the large pool, allocate and free SGA space in units of granules. Oracle tracks SGA memory use in integral numbers of granules, by SGA component. All information about a granule is stored in a corresponding granule entry. Oracle maintains the state of each granule in the granule entry and the granule type.
Granule size is determined by total SGA size. On most platforms, the size of a granule is 4 MB if the total SGA size is less than 128 MB, and it is 16 MB for larger SGAs. There may be some platform dependency, for example, on 32-bit Windows NT, the granule size is 8 MB for SGAs larger than 128 MB.
The granule size that is currently being used for SGA can be viewed in the view V$SGA_DYNAMIC_COMPONENTS. The same granule size is used for all dynamic components in the SGA.

Note:
If you specify a size for a component that is not a multiple of granule size, then Oracle rounds the specified size up to the nearest multiple. For example, if the granule size is 4 MB and you specify DB_CACHE_SIZE as 10 MB, you will actually be allocated 12 MB.

Oracle keeps information about the components and their granules in a scoreboard. For each component that owns granules, the scoreboard contains the number of granules allocated to the component, any pending operations against this component, the target size in granules, and the progress made toward the target size. The start time of the operation is also logged. Oracle maintains the initial number of granules and the maximum number of granules for each component.
For operations that modify the number of granules, Oracle logs the operation, the target size, and the start time to the appropriate SGA component in the scoreboard. Oracle updates the progress field until the operation is complete. When the operation is complete, Oracle replaces the current size with the target size and clears the target size field and the progress field. At the end of the operation, a database administrator can see how the number of granules was changed. Oracle updates the initialization parameter values to reflect the updated amount of SGA in use.
Oracle maintains a circular buffer of the last 100 operations made to the scoreboard. Fixed views show the state of the scoreboard and the current contents of last 100 operations to the scoreboard.
Allocating Granules at Startup
At startup, Oracle reads the values in the initialization parameter file, queries the operating system memory limits, and allocates virtual address space for the SGA. The initialization parameter SGA_MAX_SIZE specifies the maximum size of the SGA for the life of the instance in bytes. Its value is rounded up to the next granule size.
Adding Granules to Components
A database administrator grows a component's SGA use with ALTER SYSTEM statements to modify the initialization parameter values. Oracle takes the new size, rounds it up to the nearest multiple of 16MB, and adds or takes away granules to meet the target size. Oracle must have enough free granules to satisfy the request. If the current amount of SGA memory is less than SGA_MAX_SIZE, then Oracle can allocate more granules until the SGA size reaches SGA_MAX_SIZE.

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/granule_log_buffer.html

Oracle 10g LOGMNR挖掘日志很方便

eygle@eygle.com(eygle) — Wed, 01 Jul 2009 11:09:49 +0800

©作者：eygle 发布在 eygle.com

Oracle 10g可以使用LOGMNR在线分析和挖掘日志，使用当前在线的数据字典，非常方便。

首先执行一些DDL或DML操作：

SQL> connect eygle/eygle
Connected.

SQL> alter system switch logfile;

System altered.

SQL> create table eygle as select * from dba_users;

Table created.

SQL> set autotrace on
SQL> select count(*) from eygle;

COUNT(*)
----------
        19

Execution Plan
----------------------------------------------------------
Plan hash value: 3602634261

--------------------------------------------------------------------
| Id | Operation          | Name | Rows | Cost (%CPU)| Time     |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     1 |     3   (0)| 00:00:01 |
|   1 | SORT AGGREGATE    |       |     1 |            |          |
|   2 |   TABLE ACCESS FULL| EYGLE |    19 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement

Statistics
----------------------------------------------------------
          5 recursive calls
          0 db block gets
          7 consistent gets
          5 physical reads
          0 redo size
        411 bytes sent via SQL*Net to client
        400 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed

然后可以执行LOGMNR解析工作：

SQL> connect / as sysdba
Connected.
SQL> select * from v$log where status='CURRENT';

    GROUP#    THREAD# SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------
         2          1        100   52428800          1 NO CURRENT               12729697 01-JUL-09

SQL> SELECT MEMBER from v$logfile where group#=2;

MEMBER
------------------------------------------------------------------------------------------------------------------------
/opt/oracle/oradata/mmstest/redo02.log

SQL> exec dbms_logmnr.add_logfile('/opt/oracle/oradata/mmstest/redo02.log',dbms_logmnr.new);

PL/SQL procedure successfully completed.

SQL> exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);

PL/SQL procedure successfully completed.

SQL> select count(*) from v$logmnr_contents;

COUNT(*)
----------
       136
SQL> select sql_redo from v$logmnr_contents;

SQL_REDO
------------------------------------------------------------------------------------------------------------------------
set transaction read write;
insert into "SYS"."OBJ$"("OBJ#","DATAOBJ#","OWNER#","NAME","NAMESPACE","SUBNAME","TYPE#","CTIME","MTIME","STIME","STATUS
","REMOTEOWNER","LINKNAME","FLAGS","OID$","SPARE1","SPARE2","SPARE3","SPARE4","SPARE5","SPARE6") values ('25847','25847'
,'31','EYGLE','1',NULL,'2',TO_DATE('01-JUL-09', 'DD-MON-RR'),TO_DATE('01-JUL-09', 'DD-MON-RR'),TO_DATE('01-JUL-09', 'DD-
MON-RR'),'1',NULL,NULL,'0',NULL,'6','1',NULL,NULL,NULL,NULL);

set transaction read write;
update "SYS"."CON$" set "CON#" = '10823' where "CON#" = '10822' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;

SQL_REDO
------------------------------------------------------------------------------------------------------------------------
update "SYS"."CON$" set "CON#" = '10824' where "CON#" = '10823' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10825' where "CON#" = '10824' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10826' where "CON#" = '10825' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;

set transaction read write;
update "SYS"."CON$" set "CON#" = '10827' where "CON#" = '10826' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10828' where "CON#" = '10827' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10829' where "CON#" = '10828' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
create table eygle as select * from dba_users;
set transaction read write;

Unsupported
update "SYS"."TSQ$" set "TS#" = '0', "GRANTOR#" = '43080', "BLOCKS" = '0', "MAXBLOCKS" = '0', "PRIV1" = '0', "PRIV2" = '
0' where "TS#" = '0' and "GRANTOR#" = '43072' and "BLOCKS" = '0' and "MAXBLOCKS" = '0' and "PRIV1" = '0' and "PRIV2" = '
0' and ROWID = 'AAAAAKAABAAAABbAAF';

commit;
set transaction read write;
SQL> exec dbms_logmnr.end_logmnr

PL/SQL procedure successfully completed.

很多时候拿LOGMNR来追踪一些误操作是很有效的方式，甚至在自己定制的数据同步中，LOGMNR也大有可为。

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/oracle10g_logmnr_easyuse.html

恩墨科技为ChinaCache提供紧急救援服务

eygle@eygle.com(eygle) — Tue, 30 Jun 2009 21:31:28 +0800

近日，恩墨科技为ChinaCahce提供了紧急数据库援助服务。

ChinaCache成立于1998年，是中国领先的专业CDN服务提供商，向客户提供全方位网络内容快速分布解决方案。作为2000年就获信产部许可的 CDN服务提供商，目前ChinaCache在全国100多个大中城市拥有近500个节点，覆盖中国电信、中国网通、中国移动、中国联通、中国铁通和中国教育科研网等各大运营商。2007年，ChinaCache北美公司的建立，使ChinaCache网络覆盖了北美及亚太地区。

ChinaCache与恩墨科技长期以来一直保持着良好的合作与联系，最近的一次意外断电事故，使得客户的数据库系统受到了影响，在经过了数小时的排查之后，客户请求我们介入协助寻求解决方案，在经过了全面的思考和一系列的尝试之后，我们成功的帮助用户恢复了数据库服务，使得TB级数据库能够再次提供服务。

感谢用户的信赖和支持，希望我们的服务能够继续为用户创造价值！

相关文章|Related Articles

评论数量(5)|Add Comments

本文网址：http://www.eygle.com/archives/2009/06/enmotech_chinacache.html

恩墨科技为中电财提供顾问咨询及容灾服务

eygle@eygle.com(eygle) — Mon, 29 Jun 2009 21:46:40 +0800

近日，恩墨科技为中国电力财务有限公司提供数据库容灾环境实施及顾问咨询工作。

近年来，国内越来越多的公司开始认识到数据安全的重要，以各种手段和方式开始实施数据库安全架构。在众多的可选方案中，Oracle的DataGuard技术以其成本低、可用性及安全性能够满足绝大多数需求成为了很多企业的首选。在下个月即将发布的Oracle Database 11gR2版本中，Oracle Active DataGuard技术将得到进一步增强，可以预计，这一新版的的卓越新特性将为Oracle带来更多的客户。

中国电力财务有限公司（以下简称中国电财）成立于1993年，是经中国银行业监督管理委员会批准的一家全国性非银行金融机构。中国电财注册资本金50亿元，由国家电网公司控股、各省（市、区）电力公司等50家电力企、事业单位共同参股组建。经银监会批准，中国电财拥有东北、西北、华中和华东等多家区域性分公司，注册资本金、资产规模、利润总额等多项指标在国内财务公司行业中均名列前茅，在电力和金融行业树立了良好的企业形象，当选为中国财务公司协会理事长单位。

客户的数据库采用Oracle Database 10g RAC架构，异地容灾以Oracle DataGuard技术为主体实现。

感谢用户及合作伙伴用友公司的信赖与支持，希望稳健架构的实施可以帮助用户实现数据安全和业务连续性的需要。

相关文章|Related Articles

评论数量(1)|Add Comments

本文网址：http://www.eygle.com/archives/2009/06/enmotech_zdc.html

恩墨科技成功签约北京资和信集团

eygle@eygle.com(eygle) — Fri, 26 Jun 2009 17:20:06 +0800

2009年6月，恩墨科技成功签约北京资和信集团，为该集团提供金牌数据库支持与咨询服务,这是恩墨科技成立以来签下的又一重要企业客户。

北京资和信集团是一家服务于金融与零售领域的大型集团公司，主要从事业务包括：卡业务、担保业务、资和信百货及其他业务。

资和信集团的主营卡业务，占据了北京购物卡市场的绝对领导地位。北京商业服务业通用积分卡（商通卡）由北京资和信担保集团旗下北京商服通网络科技有限公司管理，北京资和信通联科技有限公司提供技术服务。作为首家运营通用积分卡的公司，经过近十年的锤炼，商通卡无论是在便利性、安全性还是服务方面都得到客户与商户的广泛认可，无论从交易额、客户数量与层次、商户规模与数量上与其他同行业企业相比，都保持着较大的优势。客户方面，持卡人众多，并与许多大型知名团体客户建立了长期的服务关系；商户方面，行业涉及百货、超市、旅游、餐饮、医疗、健身、娱乐等众多领域。

资和信集团由于承载着大量消费卡的管理、消费记录、结算等重要业务，对于数据库的高可用性、稳定性及性能都有很高的要求。基于双方长期的合作、了解与信任，北京资和信集团选择了恩墨科技作为数据库服务提供商，为其提供全面的数据库技术支持与顾问咨询服务。

感谢客户长期以来的信赖与支持，我们将一如既往的加深理解与沟通，全力为客户提供高品质的数据库服务，保障和满足客户的业务需求。

相关文章|Related Articles

评论数量(6)|Add Comments

本文网址：http://www.eygle.com/archives/2009/06/enmotech_zihexin.html

IPC Send Timeout和ORA-29740 Instance Evicted

eygle@eygle.com(eygle) — Fri, 26 Jun 2009 16:40:20 +0800

IPC Send timeout 是 Oracle10g Rac中非常让人头痛的一个问题，在资源紧张、网络拥堵等情况下，就有可能发生IPC超时的问题，而RAC随后就会将问题节点驱逐，引发一轮重新配置。

可喜的是Metalink上针对10.2.0.3有了一个Patch可以修正，而且在10.2.0.4中彻底修正了该问题。
常见的错误提示是这样的：

Thu Nov 27 11:32:05 2008
IPC Send timeout detected. Receiver ospid 4001974
Thu Nov 27 11:33:08 2008
Trace dumping is performing id=[cdmp_20081127113236]
Thu Nov 27 11:34:37 2008
Errors in file /oracle/app/product/admin/srs/bdump/srs1_lms1_4001974.trc:
Thu Nov 27 11:34:38 2008
Errors in file /oracle/app/product/admin/srs/bdump/srs1_lmon_3977348.trc:
ORA-29740: evicted by member 1, group incarnation 32
Thu Nov 27 11:34:38 2008
LMON: terminating instance due to error 29740

这个BUG号是Bug 5190596 。

在我的印象里10.2.0.3的确常有这个问题，而10.2.0.4却很少看到。

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/06/ipc_send_timeout_instance_evicted.html

IBM 的 clverify 与 Oracle 的 cluvfy

eygle@eygle.com(eygle) — Fri, 26 Jun 2009 10:18:37 +0800

昨晚在客户Oracle数据库系统上应用一个Patch时，遇到了一幢惊心动魄的事情。

当我们刚刚应用完Patch之后，系统上就出现了一条广播消息，提示：

Broadcast message from root@p570 (tty) at 00:00:19 ...

clverify has detected cluster configuration errors on node p570. Detailed clverify output is available in standard clverify log on node p570.

提示说clverify检查到Cluster错误，因为应用的一个Patch和CRS有点关系，但是第一感觉是：难道CRS除了问题？
而且直接把clverify误判成了Oracle的Cluvfy，汗！
Oracle的cluvfy是用来验证Oracle集群的一致性的，我用cluvfy检查一下也没有发现问题

[oracle@dbrac1 oracle]$ cluvfy

USAGE:
cluvfy [ -help ]
cluvfy stage { -list | -help }
cluvfy stage {-pre|-post} [-verbose]
cluvfy comp { -list | -help }
cluvfy comp [-verbose]

再仔细看提示才发现此clverify不是cluvfy：
在HACMP 5.1中，包括集群校验程序(clverify)和新的集群通信后台(clcomdES)都需要/var文件系统下附加的空间。
要得到详细的消息和附加的调试信息，在每个节点的/var下需要满足：
Ø        20M仅一次，包括：
-          /var/HACMP/clcomd/clcomd.log 2M
-          /var/HACMP/clcomd/clcomddiag.log 18M
Ø        在/var/HACMP/odmcache目录下附加的（1M*集群中的节点数）空间。
Ø        4M每个节点集群的效验数据。
Ø        2M的集群效验log（clverify.log[0-9]）。
在集群的每个节点中，效验工具在需要/var下4M的空间，clverify可以在同一时间最多保持四份节点效验数据的拷贝(节点初始化和同步时)。
/var/HACMP/clverify/current//*包含当前执行的效验的日志。
/var/HACMP/clverify/pass//*包含最后通过的效验的日志。
/var/HACMP/clverify/pass。prev/ /*包含倒数第二次通过效验的日志。
/var/HACMP/clverify/fail//*包含最后一次失败的效验日志。
同时，/var/HACMP/clverify/clverify.log和它的拷贝消耗1-2M的磁盘空间。

再来检查HACMP的日志，发现的确是系统Cluster因为两台主机的时间不一致发出了一个警告，和数据库无关。

ERROR: The HACMP timestamp file for shared volume group: oraclevg is inconsistent
with the time stamp in the VGDA for the following nodes: p1 p2

重启数据库，一切是正常的。

这个故事说明，DBA不仅要心理素质好，眼神也要好！

-The End-

相关文章|Related Articles

评论数量(3)|Add Comments

本文网址：http://www.eygle.com/archives/2009/06/clverify_cluvfy.html

opatch的补丁号、下载及备忘

eygle@eygle.com(eygle) — Thu, 25 Jun 2009 22:13:38 +0800

OPatch是用来应用Oracle过渡性补丁的工具。

对于Oracle10.2.0.3版本来说，自带的OPatch版本过低，没有napply命令，在应用一些Patch Bundle时需要升级OPatch。
记录一下patch号及下载地址：
补10.2.0.3的Opatch，补丁号是 4898608：

-r--r--r-- 1 root other 1169856 Jun 22 00:15 p4898608_10201_GENERIC.zip
-r--r--r-- 1 root other 1169856 Jun 22 00:16 p4898608_10202_GENERIC.zip
-r--r--r-- 1 root other 1169856 Jun 22 00:17 p4898608_10203_GENERIC.zip
-r--r--r-- 1 root other 1169856 Jun 22 00:18 p4898608_10204_Generic.zip
-r--r--r-- 1 root other 1252699 Jun 22 00:13 p4898608_111000_GENERIC.zip

另外在Metalink上的所有OPatch版本的补丁号的编号是6880880，其文件有一大堆：

-r--r--r--   1 root     other      361632 Jun 19 12:39 p6880880_101000_AIX.zip
-r--r--r--   1 root     other    28287882 Jun 19 12:37 p6880880_101000_AIX64-5L.zip
-r--r--r--   1 root     other      361632 Jun 19 12:39 p6880880_101000_BS2000.zip
-r--r--r--   1 root     other    29861361 Jun 19 12:37 p6880880_101000_HP64.zip
-r--r--r--   1 root     other    35417093 Jun 19 12:37 p6880880_101000_HPUX-IA32.zip
-r--r--r--   1 root     other    35417093 Jun 19 12:37 p6880880_101000_HPUX-IA64.zip
-r--r--r--   1 root     other    29861361 Jun 22 09:38 p6880880_101000_HPUX11.zip
-r--r--r--   1 root     other    29265466 Jun 19 12:38 p6880880_101000_IBMPower.zip
-r--r--r--   1 root     other    26342584 Jun 19 12:38 p6880880_101000_LINUX.zip
-r--r--r--   1 root     other    31697049 Jun 19 12:37 p6880880_101000_Linux-IA64.zip
-r--r--r--   1 root     other    28740649 Jun 19 12:37 p6880880_101000_Linux-S390.zip
-r--r--r--   1 root     other    26342584 Jun 19 12:38 p6880880_101000_Linux-x86-64.zip
-r--r--r--   1 root     other    28740649 Jun 19 12:37 p6880880_101000_Linux-zSer.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_MSVista.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_MSWIN-x86-64.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_MSwin2000.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_MSwinXP.zip
-r--r--r--   1 root     other      361632 Jun 19 12:41 p6880880_101000_MSwinXP64.zip
-r--r--r--   1 root     other      361632 Jun 19 12:39 p6880880_101000_MVS.zip
-r--r--r--   1 root     other    27601676 Jun 19 12:38 p6880880_101000_SOLARIS.zip
-r--r--r--   1 root     other    27601676 Jun 19 12:38 p6880880_101000_SOLARIS64.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:39 p6880880_101000_Ser08-x86-64.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_Ser2003.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:39 p6880880_101000_Ser2008.zip
-r--r--r--   1 root     other      361632 Jun 19 12:41 p6880880_101000_Solaris86-64.zip
-r--r--r--   1 root     other      361632 Jun 22 09:27 p6880880_101000_Solarisx86.zip
-r--r--r--   1 root     other      361632 Jun 19 12:39 p6880880_101000_Tru64.zip
-r--r--r--   1 root     other    25049780 Jun 19 12:38 p6880880_101000_WINNT.zip
-r--r--r--   1 root     other      361632 Jun 19 12:41 p6880880_101000_WINNT64.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:45 p6880880_102000_AIX.zip
-r--r--r--   1 root     other    29096475 Jun 19 12:41 p6880880_102000_AIX64-5L.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:45 p6880880_102000_AIX64.zip
-r--r--r--   1 root     other     1170379 Jun 21 22:20 p6880880_102000_BS2000.zip
-r--r--r--   1 root     other    30670108 Jun 19 12:41 p6880880_102000_HP64.zip
-r--r--r--   1 root     other    36225840 Jun 19 12:41 p6880880_102000_HPUX-IA32.zip
-r--r--r--   1 root     other    36225840 Jun 19 12:41 p6880880_102000_HPUX-IA64.zip
-r--r--r--   1 root     other    30670108 Jun 22 09:41 p6880880_102000_HPUX11.zip
-r--r--r--   1 root     other    30074213 Jun 19 12:43 p6880880_102000_IBMPower.zip
-r--r--r--   1 root     other    27151331 Jun 19 12:44 p6880880_102000_LINUX.zip
-r--r--r--   1 root     other    32505796 Jun 19 12:43 p6880880_102000_Linux-IA64.zip
-r--r--r--   1 root     other    29549396 Jun 19 12:43 p6880880_102000_Linux-S390.zip
-r--r--r--   1 root     other    27151331 Jun 19 12:44 p6880880_102000_Linux-x86-64.zip
-r--r--r--   1 root     other    29549396 Jun 19 12:41 p6880880_102000_Linux-zSer.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_MSVista.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_MSWIN-x86-64.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:44 p6880880_102000_MSwin2000.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_MSwinXP.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:47 p6880880_102000_MSwinXP64.zip
-r--r--r--   1 root     other     1171143 Jun 19 12:41 p6880880_102000_MVS.zip
-r--r--r--   1 root     other    28410423 Jun 19 12:44 p6880880_102000_SOLARIS.zip
-r--r--r--   1 root     other    28410423 Jun 25 00:07 p6880880_102000_SOLARIS64.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_Ser08-x86-64.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_Ser2003.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:45 p6880880_102000_Ser2008.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:47 p6880880_102000_Solaris86-64.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:47 p6880880_102000_Solarisx86.zip
-r--r--r--   1 root     other     1170379 Jun 19 12:47 p6880880_102000_Tru64.zip
-r--r--r--   1 root     other    25858527 Jun 19 12:44 p6880880_102000_WINNT.zip
-r--r--r--   1 root     other     1170379 Jun 23 22:59 p6880880_102000_WINNT64.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_AIX.zip
-r--r--r--   1 root     other    29179318 Jun 19 12:47 p6880880_111000_AIX64-5L.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_AIX64.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_BS2000.zip
-r--r--r--   1 root     other    30752951 Jun 19 12:49 p6880880_111000_HP64.zip
-r--r--r--   1 root     other    36308683 Jun 19 12:47 p6880880_111000_HPUX-IA64.zip
-r--r--r--   1 root     other    30752951 Jun 22 09:43 p6880880_111000_HPUX11.zip
-r--r--r--   1 root     other    30157056 Jun 19 12:49 p6880880_111000_IBMPower.zip
-r--r--r--   1 root     other    29632239 Jun 19 12:49 p6880880_111000_LINUX-S390.zip
-r--r--r--   1 root     other    29632239 Jun 19 12:49 p6880880_111000_LINUX-zSer.zip
-r--r--r--   1 root     other    27234174 Jun 19 12:49 p6880880_111000_LINUX.zip
-r--r--r--   1 root     other    32588639 Jun 19 12:49 p6880880_111000_Linux-IA64.zip
-r--r--r--   1 root     other    27234174 Jun 19 12:49 p6880880_111000_Linux-x86-64.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:51 p6880880_111000_MSVista.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:53 p6880880_111000_MSWIN-x86-64.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:51 p6880880_111000_MSwin2000.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:51 p6880880_111000_MSwinXP.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_MSwinXP64.zip
-r--r--r--   1 root     other     1253929 Jun 19 12:49 p6880880_111000_MVS.zip
-r--r--r--   1 root     other    28493266 Jun 19 12:53 p6880880_111000_SOLARIS64.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_SOLARISx86.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:53 p6880880_111000_Ser2003.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:53 p6880880_111000_Ser2008.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_TRU64.zip
-r--r--r--   1 root     other    25941370 Jun 19 12:53 p6880880_111000_WINNT.zip
-r--r--r--   1 root     other     1253222 Jun 19 12:53 p6880880_111000_WINNT64.zip

记录一下备忘，这一周遇到了太多的Case，忙的晕头转向！

参考链接：

Kamus写的： http://www.dbform.com/html/2008/477.html

赵宇写的： http://space.itpub.net/175005/viewspace-420428

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/06/opatch_download_url_record.html