..experience – 第 19 页

listener的内存泄漏

2009-04-07 6条评论

今天收到告警邮件，某省的数据库无法登录，在alertlog中有如下的报错：

Tue Mar 31 16:38:11 2009
Errors in file /oracle/app/oracle/admin/zjfs/bdump/zjfs_ora_22423.trc:
ORA-27102: out of memory
HPUX-ia64 Error: 12: Not enough space
Additional information: 103
Additional information: 524288

1

2

3

4

5

6

Tue Mar 31 16:38:11 2009

Errors in file /oracle/app/oracle/admin/zjfs/bdump/zjfs_ora_22423.trc:

ORA-27102: out of memory

HPUX-ia64 Error: 12: Not enough space

Additional information: 103

Additional information: 524288

登录数据库主机检查内存剩余量不到10%，用top检查：

System: zj-db01                                       Wed Apr  1 14:10:47 2009
Load averages: 0.12, 0.18, 0.28
387 processes: 362 sleeping, 25 running
Cpu states:
CPU   LOAD   USER   NICE    SYS   IDLE  BLOCK  SWAIT   INTR   SSYS
 0    0.21   8.4%   0.0%   7.0%  84.7%   0.0%   0.0%   0.0%   0.0%
 1    0.09   3.4%   0.0%   2.4%  94.2%   0.0%   0.0%   0.0%   0.0%
 2    0.11   3.4%   0.0%   0.0%  96.6%   0.0%   0.0%   0.0%   0.0%
 3    0.10   3.2%   0.0%   1.0%  95.8%   0.0%   0.0%   0.0%   0.0%
---   ----  -----  -----  -----  -----  -----  -----  -----  -----
avg   0.12   4.6%   0.0%   2.6%  92.8%   0.0%   0.0%   0.0%   0.0%

Memory: 4456068K (2521320K) real, 6115756K (3135960K) virtual, 391416K free  Page# 1/15

CPU TTY     PID USERNAME PRI NI   SIZE    RES STATE    TIME %WCPU  %CPU COMMAND
 0   ?     2307 oracle   178 20  3015M 24612K sleep 4383:34 15.11 15.08 oraclezjfs
 2   ?     2228 oracle   178 20  2986M  9624K sleep 3580:19  2.94  2.93 oraclezjfs
 1   ?     2309 oracle   178 20  2986M  5536K sleep  541:29  2.92  2.91 oraclezjfs
 1   ?     4400 oracle   154 20  1375M  1340M sleep 11224:04  2.04  2.04 tnslsnr  
 1   ?     2528 oracle   178 20  2986M  5612K sleep   15:05  1.32  1.32 oraclezjfs   
 1   ?     4380 oracle   178 20  3009M 35136K sleep  268:00  1.16  1.16 ora_lgwr_zjfs
 3   ?     4378 oracle   178 20  3009M 35152K sleep  244:54  0.74  0.74 ora_dbw0_zjfs
 1   ?       54 root     152 20  3312K  2944K run    136:01  0.45  0.45 vxfsd
 3   ?     1439 root     152 20   207M 84724K run    103:21  0.40  0.40 cimprovagt
 3   ?     1442 root     152 20 38312K  2820K run   2725:46  0.36  0.36 cimprovagt   
 3   ?    12064 oracle   178 20  2986M  5264K sleep    0:20  0.32  0.32 oraclezjfs   
 2   ?     1436 root     152 20 56792K 13976K run    180:41  0.23  0.23 cimserver 
 3 pts/ta 21448 oracle   168 20 10836K  1284K sleep    0:00  0.22  0.22 top
 2   ?     2381 oracle   178 20  2987M  5944K sleep  419:20  0.18  0.18 oraclezjfs
 1   ?       38 root     152 20   432K   384K run     60:21  0.16  0.16 schedcpu  
 2 pts/tc 21573 oracle   178 20 10964K  1412K run      0:00  0.27  0.15 top
 2   ?    21551 oracle   178 20  2986M  5260K sleep    0:00  0.16  0.14 oraclezjfs
 3   ?     1793 root     152 20   113M 17208K run      6:09  0.14  0.14 vxsvc
 0   ?       20 root     191 20   360K   320K run     33:43  0.13  0.13 ksyncer_daemon
 2   ?     1429 root     152 20 25516K  5536K run      4:42  0.12  0.12 rpcd
 1   ?     4297 root     -27 20 46772K 38548K run     31:58  0.12  0.12 cmcld
 2   ?    21518 oracle   178 20  2986M  5260K sleep    0:00  0.13  0.12 oraclezjfs
 2   ?     1228 root     154 20  7812K   848K sleep  126:00  0.10  0.10 sendmail:
 2   ?       39 root     191 20   288K   256K run    305:44  0.08  0.08 pagezerod
 2   ?     1589 root     152 20 25072K  3992K run      1:20  0.08  0.08 swagentd 
$ 
$

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

System: zj-db01 Wed Apr 1 14:10:47 2009

Load averages: 0.12, 0.18, 0.28

387 processes: 362 sleeping, 25 running

Cpu states:

CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS

0 0.21 8.4% 0.0% 7.0% 84.7% 0.0% 0.0% 0.0% 0.0%

1 0.09 3.4% 0.0% 2.4% 94.2% 0.0% 0.0% 0.0% 0.0%

2 0.11 3.4% 0.0% 0.0% 96.6% 0.0% 0.0% 0.0% 0.0%

3 0.10 3.2% 0.0% 1.0% 95.8% 0.0% 0.0% 0.0% 0.0%

--- ---- ----- ----- ----- ----- ----- ----- ----- -----

avg 0.12 4.6% 0.0% 2.6% 92.8% 0.0% 0.0% 0.0% 0.0%

Memory: 4456068K (2521320K) real, 6115756K (3135960K) virtual, 391416K free Page# 1/15

CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND

0 ? 2307 oracle 178 20 3015M 24612K sleep 4383:34 15.11 15.08 oraclezjfs

2 ? 2228 oracle 178 20 2986M 9624K sleep 3580:19 2.94 2.93 oraclezjfs

1 ? 2309 oracle 178 20 2986M 5536K sleep 541:29 2.92 2.91 oraclezjfs

1 ? 4400 oracle 154 20 1375M 1340M sleep 11224:04 2.04 2.04 tnslsnr

1 ? 2528 oracle 178 20 2986M 5612K sleep 15:05 1.32 1.32 oraclezjfs

1 ? 4380 oracle 178 20 3009M 35136K sleep 268:00 1.16 1.16 ora_lgwr_zjfs

3 ? 4378 oracle 178 20 3009M 35152K sleep 244:54 0.74 0.74 ora_dbw0_zjfs

1 ? 54 root 152 20 3312K 2944K run 136:01 0.45 0.45 vxfsd

3 ? 1439 root 152 20 207M 84724K run 103:21 0.40 0.40 cimprovagt

3 ? 1442 root 152 20 38312K 2820K run 2725:46 0.36 0.36 cimprovagt

3 ? 12064 oracle 178 20 2986M 5264K sleep 0:20 0.32 0.32 oraclezjfs

2 ? 1436 root 152 20 56792K 13976K run 180:41 0.23 0.23 cimserver

3 pts/ta 21448 oracle 168 20 10836K 1284K sleep 0:00 0.22 0.22 top

2 ? 2381 oracle 178 20 2987M 5944K sleep 419:20 0.18 0.18 oraclezjfs

1 ? 38 root 152 20 432K 384K run 60:21 0.16 0.16 schedcpu

2 pts/tc 21573 oracle 178 20 10964K 1412K run 0:00 0.27 0.15 top

2 ? 21551 oracle 178 20 2986M 5260K sleep 0:00 0.16 0.14 oraclezjfs

3 ? 1793 root 152 20 113M 17208K run 6:09 0.14 0.14 vxsvc

0 ? 20 root 191 20 360K 320K run 33:43 0.13 0.13 ksyncer_daemon

2 ? 1429 root 152 20 25516K 5536K run 4:42 0.12 0.12 rpcd

1 ? 4297 root -27 20 46772K 38548K run 31:58 0.12 0.12 cmcld

2 ? 21518 oracle 178 20 2986M 5260K sleep 0:00 0.13 0.12 oraclezjfs

2 ? 1228 root 154 20 7812K 848K sleep 126:00 0.10 0.10 sendmail:

2 ? 39 root 191 20 288K 256K run 305:44 0.08 0.08 pagezerod

2 ? 1589 root 152 20 25072K 3992K run 1:20 0.08 0.08 swagentd

$

发现listener占用的内存非常大 […]

..experience, Working case

安装数据库时报错无法写入

2009-03-23 没有评论

今天在安装数据库的时候，报错文件无法写入：一开始想，是在copy的时候报错，是不是安装介质的缘故，难道是ftp传输的时候有问题？由于之前是通过写ftp脚本挂后台跑，log中虽然没什么报错，但是以防万一，还是再传了一次。但是安装到27%，还是报错了，虽然不是报同样的一个文件write error， […]

..experience, Working case

rac的dp备份时候报错RMAN-20242

2009-03-09 一条评论

今天收到一个rac省的dp报错记录：

[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

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

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 […]

..experience, Working case

3小时的sql调优到3分钟。

2009-03-02 9条评论

今天接到这样一个问题，某省的报表系统的一个某个处理进程在前几天处理的速度突然变慢，而且从应用的log上还看到1555的报错：

[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

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参数。但是，之前的程序跑的还比较正常， […]

..experience, Working case

legato备份磨难记

2009-02-26 6条评论

华西某省进行数据库主机升级，将一台老机器升级到新机器上，在新机器上安装完数据库软件之后，把存储从老机器往新机器一挂，数据库算是迁移完成了。但是自从升级完成后，legato一直备份不成功。为了这个问题，和华西的dba王术成研究了好几天。第一天：发现备份执行完了，但任务状态不恢复正常，检查数据库主机 […]

..experience, Working case

用_minimum_giga_scn解决无法启动的数据库

2009-01-22 4条评论

今天遇到一个数据库无法启动，看到alertlog中主要是ora 600和[2662]的报错：

SQL> startup
ORACLE instance started.

Total System Global Area 1076850392 bytes
Fixed Size                   736984 bytes
Variable Size             536870912 bytes
Database Buffers          536870912 bytes
Redo Buffers                2371584 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced


SQL>

1

2

3

4

5

6

7

8

9

10

11

12

13

SQL> startup

ORACLE instance started.

Total System Global Area 1076850392 bytes

Fixed Size 736984 bytes

Variable Size 536870912 bytes

Database Buffers 536870912 bytes

Redo Buffers 2371584 bytes

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

SQL>

其中alertlog中报错：

Completed: ALTER DATABASE   MOUNT
Thu Jan 22 13:05:08 2009
ALTER DATABASE OPEN
Thu Jan 22 13:05:09 2009
Beginning crash recovery of 1 threads
Thu Jan 22 13:05:09 2009
Started first pass scan
Thu Jan 22 13:05:09 2009
Completed first pass scan
 0 redo blocks read, 0 data blocks need recovery
Thu Jan 22 13:05:09 2009
Started recovery at
 Thread 1: logseq 2, block 3, scn 0.43536037
Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0
  Mem# 0 errs 0: /oracle/oradata/ora9i/redo01.log
Thu Jan 22 13:05:09 2009
Ended recovery at
 Thread 1: logseq 2, block 3, scn 0.43556038
 0 data blocks read, 0 data blocks written, 0 redo blocks read
Crash recovery completed successfully
Thu Jan 22 13:05:10 2009
Thread 1 advanced to log sequence 3
Thread 1 opened at log sequence 3
  Current log# 2 seq# 3 mem# 0: /oracle/oradata/ora9i/redo02.log
Successful open of redo thread 1.
Thu Jan 22 13:05:10 2009
SMON: enabling cache recovery
Thu Jan 22 13:05:10 2009
Errors in file /oracle/admin/ora9i/udump/ora9i_ora_12968.trc:
ORA-00600: internal error code, arguments: [2662], [0], [43556042], [261], [2396789971], [4194729], [], []

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

Completed: ALTER DATABASE MOUNT

Thu Jan 22 13:05:08 2009

ALTER DATABASE OPEN

Thu Jan 22 13:05:09 2009

Beginning crash recovery of 1 threads

Thu Jan 22 13:05:09 2009

Started first pass scan

Thu Jan 22 13:05:09 2009

Completed first pass scan

0 redo blocks read, 0 data blocks need recovery

Thu Jan 22 13:05:09 2009

Started recovery at

Thread 1: logseq 2, block 3, scn 0.43536037

Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0

Mem# 0 errs 0: /oracle/oradata/ora9i/redo01.log

Thu Jan 22 13:05:09 2009

Ended recovery at

Thread 1: logseq 2, block 3, scn 0.43556038

0 data blocks read, 0 data blocks written, 0 redo blocks read

Crash recovery completed successfully

Thu Jan 22 13:05:10 2009

Thread 1 advanced to log sequence 3

Thread 1 opened at log sequence 3

Current log# 2 seq# 3 mem# 0: /oracle/oradata/ora9i/redo02.log

Successful open of redo thread 1.

Thu Jan 22 13:05:10 2009

SMON: enabling cache recovery

Thu Jan 22 13:05:10 2009

Errors in file /oracle/admin/ora9i/udump/ora9i_ora_12968.trc:

ORA-00600: internal error code, arguments: [2662], [0], [43556042], [261], [2396789971], [4194729], [], []

遇到ora-600和2662的问题，我们一般 […]

..experience, Working case

flashback_on被自动改回no

2009-01-21 没有评论

oracle对flashback log采用了自动管理的方式，并且不允许手工去删除flashback log。当flashback log写满时，会自动的覆盖掉最早的一个flashback日志。并且值得注意的是，如果手工删除了flashback log，数据库将自动把flashback设置成no！ […]

..experience, Working case

HP的查看打开文件数工具:crashinfo

2009-01-17 5条评论

一天，在一个业务高峰期，某省的一个数据库突然宕机了，根据alertlog中发现的报错：

Mon Jan 12 09:49:42 2009
ARC0: Evaluating archive   log 5 thread 1 sequence 142032
ARC0: Beginning to archive log 5 thread 1 sequence 142032
Creating archive destination LOG_ARCHIVE_DEST_1: '/oraarchlog/arch_1_142032.arc'
Mon Jan 12 09:49:56 2009
ARC0: Completed archiving  log 5 thread 1 sequence 142032
Mon Jan 12 09:57:57 2009
Errors in file /oracle/app/oracle/admin/orasid/bdump/orasid_lgwr_8267.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/dev/vg_ora3/rredo_256m_21'
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 2
ORA-00312: online log 1 thread 1: '/dev/vg_ora2/rredo_256m_11'
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 2
ORA-00312: online log 1 thread 1: '/dev/vg_ora1/rredo_256m_01'
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 2
Mon Jan 12 09:57:57 2009
Errors in file /oracle/app/oracle/admin/orasid/bdump/orasid_lgwr_8267.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/dev/vg_ora3/rredo_256m_21'
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 2
ORA-00312: online log 1 thread 1: '/dev/vg_ora2/rredo_256m_11'
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 2

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

Mon Jan 12 09:49:42 2009

ARC0: Evaluating archive log 5 thread 1 sequence 142032

ARC0: Beginning to archive log 5 thread 1 sequence 142032

Creating archive destination LOG_ARCHIVE_DEST_1: '/oraarchlog/arch_1_142032.arc'

Mon Jan 12 09:49:56 2009

ARC0: Completed archiving log 5 thread 1 sequence 142032

Mon Jan 12 09:57:57 2009

Errors in file /oracle/app/oracle/admin/orasid/bdump/orasid_lgwr_8267.trc:

ORA-00313: open failed for members of log group 1 of thread 1

ORA-00312: online log 1 thread 1: '/dev/vg_ora3/rredo_256m_21'

ORA-27041: unable to open file

HP-UX Error: 23: File table overflow

Additional information: 2

ORA-00312: online log 1 thread 1: '/dev/vg_ora2/rredo_256m_11'

ORA-27041: unable to open file

HP-UX Error: 23: File table overflow

Additional information: 2

ORA-00312: online log 1 thread 1: '/dev/vg_ora1/rredo_256m_01'

ORA-27041: unable to open file

HP-UX Error: 23: File table overflow

Additional information: 2

Mon Jan 12 09:57:57 2009

Errors in file /oracle/app/oracle/admin/orasid/bdump/orasid_lgwr_8267.trc:

ORA-00313: open failed for members of log group 1 of thread 1

ORA-00312: online log 1 thread 1: '/dev/vg_ora3/rredo_256m_21'

ORA-27041: unable to open file

HP-UX Error: 23: File table overflow

Additional information: 2

ORA-00312: online log 1 thread 1: '/dev/vg_ora2/rredo_256m_11'

ORA-27041: unable to open file

HP-UX Error: 23: File table overflow

Additional information: 2

看来是打开文件数太多，导致了此次数据库宕机。通过监控打开文件数发现，其实在前一天的时候，打开文件数已经到98%，在上午8点多的时候，打开文件数已 […]

..experience, Working case

裸设备的划分

2009-01-08 没有评论

在三少的blog上看到了这篇《spfile啥都没了》。在这边和大家分享一下裸设备的划分的经验。 1.vg的属性建议用root。因为vg的宿主如果是oracle，那么在create tablespace的时候，如果没有找对正确的lv，比如我的lv名字是\dev\vg_ora1\aaa，那么在creat […]

..experience, Working case

修改sys密码导致legato无法正常备份

2009-01-06 没有评论

今天接到说某省的legato备份无法执行，查看legato的monitor窗口，发现没有明显报错，直接就出备份fail了信息了。由于monitor中说“……Hostname(s) Unresolved,1 Failed,1 Succeeded(xj_db Failed)”，一开始是怀疑hostna […]

..experience, Working case

基于catalog库进行部分表空间的还原

2009-01-04 7条评论

应某省的局方要求，在双机热备的备机上，将主机数据库的system、undo、temp和某个应用的表空间DATA_STATIC进行还原。环境如下：（1）HA主机：xj_db01 （2）HA备机：xj_db02 （3）备份软件：LEGATO 且legato的备份脚本为： [crayon-662ea1 […]

..experience, Working case

公司招聘DBA

2008-12-26 8条评论

公司在招dba，哪位有兴趣的，可以发简历给我hejianmin[at]aspire-tech.com或者jimmyhe1981[at]gmail.com。公司名称：卓望，移动子公司，主要股东为中国移动、HP、沃达丰、美林证券地点：深圳南山区科技园人数：1人截至时间：2009年1月底前岗位职 […]