July 7, 2009
dbms_system.ksdwrt:向告警日志文件写指定信息
作者:eygle
出处:http://blog.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-
Posted by eygle at 10:11 AM | Comments (3)
恩墨科技为某企业提供紧急数据恢复服务
作者:eygle
出处:http://blog.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一系列的ORA-07445错误表明数据库遇到了大麻烦，当尝试进行Recover的过程中，ORA-00607表明出现了数据块的不一致。
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] [] []
由于没有备份，恢复起来就比较麻烦，所以我仍然想说的是：备份重于一切。
由于数据块出现了损坏，其中的数据不可避免的遭到了损失，我们可以通过BBED等工具修复数据块，虽然可以骗过数据库，强制启动数据库，但是无法骗过自己，其中的数据难免遭到损失。
当然我们可以做的另外一件事是通过LOGMNR来解析日志，通过SQL_REDO来还原部分数据，找出受到影响的事务，恢复数据。
最终我们帮助用户成功的启动数据库，在业务生产到来之前恢复了服务。
-The End-
Posted by eygle at 8:21 AM | Comments (2)