今天在安装数据库的时候,报错文件无法写入: 一开始想,是在copy的时候报错,是不是安装介质的缘故,难道是ftp传输的时候有问题?由于之前是通过写ftp脚本挂后台跑,log中虽然没什么报错,但是以防万一,还是再传了一次。 但是安装到27%,还是报错了,虽然不是报同样的一个文件write error, […]
用无线连接电信E8的机顶盒收看IPTV
前段时间,申请的电信的E8套餐,装上了4M的宽带和2M带宽的IPTV(电信称之为iTV),团购价为1860元1年。和1800元3M宽带相比,这个确实很实惠,除了总计6M的带宽外,还有300分钟的无线热点上网,其他还包含固话月租(20元)、来显(6元)、彩铃(5元)、铃音盒(3首/月),50元语音话费 […]
rac的dp备份时候报错RMAN-20242
今天收到一个rac省的dp报错记录:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 |
[Normal] From: BSM@fj-bak01 "" Time: 2009-3-9 9:10:11 The session "2009/03/09-1" will be restarted. [Normal] From: BSM@fj-bak01 "" Time: 2009-3-9 9:10:11 Restart backup specification found: "Oracle8 fjmisc2_arch". [Normal] From: BSM@fj-bak01 "fjmisc2_arch" Time: 2009-3-9 9:10:13 OB2BAR application on "fj_db02" successfully started. ob2rman.exe started with arguments: -backup -full Recovery Manager: Release 9.2.0.6.0 - 64bit Production Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved. RMAN> connected to target database: FJMISC (DBID=169290886) RMAN> connected to recovery catalog database RMAN> RMAN> run { 2> allocate channel 'dev_0' type 'sbt_tape' 3> parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=fjmisc2,OB2BARLIST=fjmisc2_arch,OB2BARHOSTNAME=fj_db02)'; 4> allocate channel 'dev_1' type 'sbt_tape' 5> parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=fjmisc2,OB2BARLIST=fjmisc2_arch,OB2BARHOSTNAME=fj_db02)'; 6> allocate channel 'dev_2' type 'sbt_tape' 7> parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=fjmisc2,OB2BARLIST=fjmisc2_arch,OB2BARHOSTNAME=fj_db02)'; 8> allocate channel 'dev_3' type 'sbt_tape' 9> parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=fjmisc2,OB2BARLIST=fjmisc2_arch,OB2BARHOSTNAME=fj_db02)'; 10> crosscheck archivelog from time 'sysdate-1' until time 'sysdate'; 11> backup 12> format 'fjmisc2_arch<fjmisc2_%s:%t:%p>.dbf' 13> archivelog like '/archlog2/fjmisc2%' 14> delete input; 15> } allocated channel: dev_0 channel dev_0: sid=251 devtype=SBT_TAPE channel dev_0: Data Protector A.05.50/330 allocated channel: dev_1 channel dev_1: sid=276 devtype=SBT_TAPE channel dev_1: Data Protector A.05.50/330 allocated channel: dev_2 channel dev_2: sid=204 devtype=SBT_TAPE channel dev_2: Data Protector A.05.50/330 allocated channel: dev_3 channel dev_3: sid=301 devtype=SBT_TAPE channel dev_3: Data Protector A.05.50/330 validation succeeded for archived log archive log filename=/archlog1/fjmisc1_1_21584.arc recid=38312 stamp=681012033 validation succeeded for archived log archive log filename=/archlog1/fjmisc1_1_21585.arc recid=38315 stamp=681032056 Crosschecked 2 objects Starting backup at 03/09/2009 [09:16:19] released channel: dev_0 released channel: dev_1 released channel: dev_2 released channel: dev_3 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 03/09/2009 09:16:19 RMAN-06004: ORACLE error from recovery catalog database: RMAN-20242: specification does not match any archive log in the recovery catalog RMAN> **end-of-file** RMAN> Recovery Manager complete. [Major] From: ob2rman.exe@FJ_DB02 "fjmisc2" Time: 03/09/09 09:16:19 |
看到这个log,一开始的感觉是手工删除arch过了,上数据库主机做了crosscheck,发现在db01上关于db02的arch都是expired的状态。通过bdf检查发现在db01上,只能看到a […]
HPUX中常用的getconf命令参数
常用的getconf命令参数,在此记录,补充一下自己的os知识:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
getconf MACHINE_SERIAL 获取主机设备序列号,这个序列号可用于HP的800报障。 getconf PAGE_SIZE 每个内存页的大小。用kmeminfo或者ps -lfp 看内存显示的结果是多少个内存页,要乘以这个每个内存页的大小才得到每个进程的占用内存。 getconf KERNEL_BITS 查看操作系统是32位还是64位,在安装oracle前必须弄清楚os版本,安装对应版本的oracle。 getconf MACHINE_MODEL 查看主机的具体型号。如rp8440,N4000-55 getconf HW_CPU_SUPP_BITS 硬件cpu支持多少位。如64位的cpu支持64位的os和32位的os。 |
3小时的sql调优到3分钟。
今天接到这样一个问题,某省的报表系统的一个某个处理进程在前几天处理的速度突然变慢,而且从应用的log上还看到1555的报错:
1 2 3 |
[2009-02-25 00:02:27] [200010000000006] [5]: 任务1执行失败!!! [2009-02-25 01:36:55] [200010000000007] [5]: servid(015027016400) not found in map_servid_servattr!!! [2009-02-25 03:24:55] [200010000600008] [0]: 从光标中fetch数据出错 ORA-01555: snapshot too old: rollback segment number 6 with name "_SYSSMU6$" too small |
当时第一个反应就是加大undo表空间大小和undo retention参数。但是,之前的程序跑的还比较正常, […]