[精华] informix又当机.online.log贴于内,请各路大侠诊治?? |
|---|
|
| 来源 chinaunix.net 酷勤网整理 |
已是不止一次出现这种情况,这次当机时的用户数在89,以前几次没有多注意,但也在八十多,
相关信息如下:
online.log
09:02:50 Checkpoint Completed: duration was 0 seconds.
09:07:54 Checkpoint Completed: duration was 0 seconds.
09:13:03 Checkpoint Completed: duration was 2 seconds.
09:18:08 Checkpoint Completed: duration was 1 seconds.
09:23:14 Checkpoint Completed: duration was 0 seconds.
09:28:18 Checkpoint Completed: duration was 1 seconds.
09:30:19 listener-thread: err = -27001: oserr = 0: errstr = : Read error occurr
ed during connection attempt.
09:33:22 listener-thread: err = -27001: oserr = 0: errstr = : Read error occurr
ed during connection attempt.
onconfig
# Root Dbspace Configuration
ROOTNAME rootdbs # Root dbspace name
ROOTPATH /dev/rdbs # Path for device containing root dbspace
ROOTOFFSET 100 # Offset of root dbspace into device (Kbytes)
ROOTSIZE 500000 # Size of root dbspace (Kbytes)
# Disk Mirroring Configuration Parameters
MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH # Path for device containing mirrored root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
# Physical Log Configuration
PHYSDBS rootdbs # Location (dbspace) of physical log
PHYSFILE 50000 # Physical log file size (Kbytes)
# Logical Log Configuration
LOGFILES 7 # Number of logical log files
LOGSIZE 10000 # Logical log size (Kbytes)
# Diagnostics
MSGPATH /usr/informix/online.log # System message log file path
CONSOLE /dev/console # System console message path
ALARMPROGRAM /usr/informix/etc/log_full.sh # Alarm program path
SYSALARMPROGRAM /usr/informix/etc/evidence.sh # System Alarm program path
TBLSPACE_STATS 1
# System Archive Tape Device
TAPEDEV /dev/null # Tape device path
TAPEBLK 16 # Tape block size (Kbytes)
TAPESIZE 10240 # Maximum amount of data to put on tape (Kbytes)
# Log Archive Tape Device
LTAPEDEV /dev/null # Log tape device path
LTAPEBLK 16 # Log tape block size (Kbytes)
LTAPESIZE 10240 # Max amount of data to put on log tape (Kbytes)
# Optical
STAGEBLOB # Informix Dynamic Server/Optical staging area
# System Configuration
SERVERNUM 1 # Unique id corresponding to a Dynamic Server instance
DBSERVERNAME ldonline_tcp # Name of default database server
DBSERVERALIASES ldonline_shm # List of alternate dbservernames
NETTYPE tlitcp,1,200,NET # Configure poll thread(s) for nettype
NETTYPE ipcshm,1,200,CPU # Configure poll thread(s) for nettype
DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env.
RESIDENT 0 # Forced residency flag (Yes = 1, No = 0)
MULTIPROCESSOR 0 # 0 for single-processor, 1 for multi-processor
NUMCPUVPS 1 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one
NOAGE 0 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors
# Shared Memory Parameters
LOCKS 197712 # Maximum number of locks
BUFFERS 132100 # Maximum number of shared buffers
NUMAIOVPS 2 # Number of IO vps
PHYSBUFF 20000 # Physical log buffer size (Kbytes)
LOGBUFF 20000 # Logical log buffer size (Kbytes)
LOGSMAX 10 # Maximum number of logical log files
CLEANERS 1 # Number of buffer cleaner processes
SHMBASE 0x82000000 # Shared memory base address
SHMVIRTSIZE 8000 # initial virtual shared memory segment size
SHMADD 8192 # Size of new shared memory segments (Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>;unlimited
CKPTINTVL 300 # Check point interval (in sec)
LRUS 8 # Number of LRU queues
LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 50 # LRU percent dirty end cleaning limit
LTXHWM 50 # Long transaction high water mark percentage
LTXEHWM 60 # Long transaction high water mark (exclusive)
TXTIMEOUT 0x12c # Transaction timeout (in sec)
STACKSIZE 32 # Stack size (Kbytes)
# System Page Size
# BUFFSIZE - Dynamic Server no longer supports this configuration parameter.
# To determine the page size used by Dynamic Server on your platform
# see the last line of output from the command, 'onstat -b'.
# Recovery Variables
# OFF_RECVRY_THREADS:
# Number of parallel worker threads during fast recovery or an offline restore.
# ON_RECVRY_THREADS:
# Number of parallel worker threads during an online restore.
OFF_RECVRY_THREADS 10 # Default number of offline worker threads
ON_RECVRY_THREADS 1 # Default number of online worker threads
# Data Replication Variables
# DRAUTO: 0 manual, 1 retain type, 2 reverse type
DRAUTO 0 # DR automatic switchover
DRINTERVAL 30 # DR max time between DR buffer flushes (in sec)
DRTIMEOUT 30 # DR network timeout (in sec)
DRLOSTFOUND /usr/informix/etc/dr.lostfound # DR lost+found file path
# CDR Variables
CDR_LOGBUFFERS 2048 # size of log reading buffer pool (Kbytes)
CDR_EVALTHREADS 1,2 # evaluator threads (per-cpu-vp,additional)
CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds)
CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR queue (Kbytes)
# Backup/Restore variables
BAR_ACT_LOG /tmp/bar_act.log
BAR_MAX_BACKUP 0
BAR_RETRY 1
BAR_NB_XPORT_COUNT 10
BAR_XFER_BUF_SIZE 31
# Informix Storage Manager variables
ISM_DATA_POOL ISMData # If the data pool name is changed, be sure to
# update $INformIXDIR/bin/onbar. Change to
# ism_catalog -create_bootstrap -pool
ISM_LOG_POOL ISMLogs
# Read Ahead Variables
RA_PAGES # Number of pages to attempt to read ahead
RA_THRESHOLD # Number of pages left before next group
# DBSPACETEMP:
# Dynamic Server equivalent of DBTEMP for SE. This is the list of dbspaces
# that the Dynamic Server SQL Engine will use to create temp tables etc.
# If specified it must be a colon separated list of dbspaces that exist
# when the Dynamic Server system is brought online. If not specified, or if
# all dbspaces specified are invalid, various ad hoc queries will create
# temporary files in /tmp instead.
DBSPACETEMP tempdbs # Default temp dbspaces
# DUMP*:
# The following parameters control the type of diagnostics information which
# is preserved when an unanticipated error condition (assertion failure) occurs
# during Dynamic Server operations.
# For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No.
DUMPDIR /tmp # Preserve diagnostics in this directory
DUMPSHMEM 1 # Dump a copy of shared memory
DUMPGCORE 0 # Dump a core image using 'gcore'
DUMPCORE 0 # Dump a core image (Warning:this aborts Dynamic Server)
DUMPCNT 1 # Number of shared memory or gcore dumps for
# a single user's session
FILLFACTOR 90 # Fill factor for building indexes
# method for Dynamic Server to use when determining current time
USEOSTIME 0 # 0: use internal time(fast), 1: get time from OS(slow)
# Parallel Database Queries (pdq)
MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority
DS_MAX_QUERIES # Maximum number of decision support queries
DS_TOTAL_MEMORY # Decision support memory (Kbytes)
DS_MAX_SCANS 1048576 # Maximum number of decision support scans
DATASKIP off # List of dbspaces to skip
# OPTCOMPIND
# 0 =>; Nested loop joins will be preferred (where
# possible) over sortmerge joins and hash joins.
# 1 =>; If the transaction isolation mode is not
# "repeatable read", optimizer behaves as in (2)
# below. Otherwise it behaves as in (0) above.
# 2 =>; Use costs regardless of the transaction isolation
# mode. Nested loop joins are not necessarily
# preferred. Optimizer bases its decision purely
# on costs.
OPTCOMPIND 2 # To hint the optimizer
ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAIT
LBU_PRESERVE 0 # Preserve last log for log backup
OPCACHEMAX 0 # Maximum optical cache size (Kbytes)
# HETERO_COMMIT (Gateway participation in distributed transactions)
# 1 =>; Heterogeneous Commit is enabled
# 0 (or any other value) =>; Heterogeneous Commit is disabled
HETERO_COMMIT 0
# Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
OPT_GOAL -1
# Optimizer DIRECTIVES ON (1/Default) or OFF (0)
DIRECTIVES 1
# Status of restartable restore
RESTARTABLE_RESTORE off
netkey 回复于：2003-02-21 22:04:21
af文件怎么说的
muzx 回复于：2003-02-21 22:35:19
根据你的描述，你的系统负担比较重这是相对于你的系统配置而言。当然你给的信息太少，无法进一步判断。
至少你的用户一般保持在八、九十左右，你的log空间比较小，7*10M，是不是很快就会写满了。
另外你的系统将备份设备置空，难道你不作数据备份？
27001这种错误如果偶尔出现则仅仅是警告！但不至于导致宕机！
如果出现多了就要引起注意了。
我感觉你这里的配置有点太大了
NETTYPE tlitcp,1,[color=red]200[/color],NET # Configure poll thread(s) for nettype
NETTYPE ipcshm,1,[color=red]200[/color],CPU # Configure poll thread(s) for netty
不知你的最大用户连接数是多少？
lovqing 回复于：2003-02-22 08:57:39
我倒想問一下：
ROOTOFFSET [color=red]100 [/color]# Offset of root dbspace into device (Kbytes)
ROOTSIZE 500000 # Size of root dbspace (Kbytes)
你的rootdbs為什麼要設offset？？？？？
zzher 回复于：2003-02-22 10:54:45
to:muzx
你指的最大用户连接数是我的系统实际使用的最大数（95），还是可容纳的最大数（128）？我的备份只是把数据导成文件后传到另外的机器里
你还要哪些信息？我会贴出来！
to:netkey
你说的af文件我不懂，是指什么？
to:lovqing
ROOTOFFSET 100 # Offset of root dbspace into device (Kbytes)
这样子设有什么影响呢？
感谢各位，我昨天有把改了如下参数
DS_MAX_SCANS 1048576 改为 1058576
目前在昨天的当机用户数上暂时没有发生当机，请各高手再指点
join 回复于：2003-02-22 10:56:12
LOCKS 197712 # Maximum number of locks
BUFFERS 132100 # Maximum number of shared buffers
PHYSBUFF 20000 # Physical log buffer size (Kbytes)
LOGBUFF 20000 # Logical log buffer size (Kbytes)
在onmonitor里面看一下这几个参数计算的结果，是否需要加大内存，另外，楼上说的，加大log文件的大小，不过，你的备份设备是null，不加也就不加了，
不理解你的NETTYPE ipcshm,1,200,CPU # Configure poll thread(s) for netty，还有别的协议在用吗？
zzher 回复于：2003-02-22 11:10:54
没有别的协议，我现在用到的只有IP协议连接，那也只有一个用户使用这样的连接，其它都是直接通过TELNET进来的。
muzx 回复于：2003-02-22 12:02:00
如果你的连接数不会超过200的话，你的网络协议类型保留一个就已经足够了，建议修改如下：
NETTYPE tlitcp,1,[color=red]150[/color],NET # Configure poll thread(s) for nettype
[color=red]#[/color]NETTYPE ipcshm,1,200,CPU # Configure poll thread(s) for netty
所谓af文件，是指系统宕机时产生的快照，存放在/tmp下，文件名一般为af.???????形式。通过分析该文件，基本可以判定系统故障原因，不过次文件一般很大，不宜上贴。
[color=blue]to:lovqing
ROOTOFFSET 100 # Offset of root dbspace into device (Kbytes)
这样子设有什么影响呢？ [/color]
这样作很好，这是一个好习惯！
另外请帖以下
onstat -d
看看
zzher 回复于：2003-02-22 13:00:18
谢谢muzx
onstat -d
Informix Dynamic Server Version 7.30.UC2 -- On-Line -- Up 1 days 02:05:01 -- 4
58752 Kbytes
Dbspaces
address number flags fchunk nchunks flags owner name
9a04613c 1 1 1 1 N informix rootdbs
9a0465d8 2 2001 2 1 N T informix tempdbs
9a046694 3 1 3 1 N informix logdbs
9a046750 4 1 4 1 N informix workdbs
4 active, 2047 maximum
Chunks
address chk/dbs offset size free bpages flags pathname
9a0461f8 1 1 50 250000 198527 PO- /dev/rdbs
9a046344 2 2 250050 25000 24815 PO- /dev/rdbs
9a046420 3 3 275100 50000 2 PO- /dev/rdbs
9a0464fc 4 4 325150 550757 97874 PO- /dev/rdbs
4 active, 2047 maximum
muzx 回复于：2003-02-22 13:52:41
看样子你的硬盘空间很紧张?
这样规划dbs空间的方法不可取.因为他并没有真正解决物理设备竞争的问题,不能提高磁盘I/O效率.
最好的方法是将rootdbs/logdbs/tmpdbs分别置于不同的物理空间(不同的硬盘上),至少也应该各自有他的独立设备,这样做即便于维护,也可以保证系统高效运行.
从你的参数看,你的logdbs空间为100M,不是很大,但为什么还要留下30M空间不用呢?
建议:
1.有条件的话重新规划数据库空间分配策略,但必须以有足够得把握将数据成功还原为前提,否则,最好别动.
2.再增加3个逻辑日志
3.请平时多注意观察系统队列,缓冲,共享内存,cup,vps等资源使用情况.
孤独剑 回复于：2003-02-22 14:12:40
当机可能是由操作系统造成的,数据库本身无任何错误信息,查看共享内存等核心参数设置,查看系统日志,你用的好像是sco,sco不要用kaio,kaio有问题,适当减少一些系统资源的分配,操作系统打补丁.
muzx 回复于：2003-02-22 17:24:53
同意！
zzher 回复于：2003-02-22 21:55:47
多谢各位顶力相助,这个贴受益非浅,版主是不是考虑加为"精华区"!!
大梦 回复于：2003-02-22 23:43:52
置精了大家给点意见！
chuenhua 回复于：2003-02-24 09:40:51
我感觉你这里的配置有点问题 ：
NETTYPE tlitcp,[color=red]1,200,[/color]NET # Configure poll thread(s) for nettype
NETTYPE ipcshm,1,200,CPU # Configure poll thread(s) for netty
要改成10，20试试，
还有操作系统的核心参数中有个NOFILE你把它该大些。
zzher 回复于：2003-02-24 10:36:14
我这里有个问题可能我说的不够准确，对不起大家！就是我指的当机是指一些INFORMIX里的应用程序突然没法动（4GL）。但操作系统还是正常的，
ONSTAT - 也正常显示INFORMIX是ONLINE状态，
今天早上又发生一次，此种情况发生后，
onstat 的显示如下：
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
889876 1246384 176129993 99.49 112903 405720 2578916 95.62
isamtot open start read write rewrite delete commit rollbk
64936913 1041151 5433152 44140435 1939295 91578 6535 19 0
gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0
ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 2315.67 872.96 479 1696
bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
241601 0 45161056 0 0 50 4972 176729
ixda-RA idx-RA da-RA RA-pgsused lchwaits
132543 15790 637164 785458 10390
用如下命令
onmode -ky
oninit这样子重启INFORMIX没法启动INFORMIX，只有重新启操作系统才恢复状态，4GL程序重新可执行！
对于这种情况大侠们有何见解？
muzx 回复于：2003-02-24 10:45:08
引用：原帖由 "chuenhua" 发表：
ET # Configure poll thread(s) for nettype
NETTYPE ipcshm,1,200,CPU # Configure poll thread(s) for netty
要改成[color=blue]10，20[/color]试试，
还有操作系统的核心参数中有个NOFILE你把它该大些。
这种改法不可取，他只能加大cpu的负担，别无它用！
如果你们使用的是正版软件的话，最好请IBM的工程师给诊断一下！
chuenhua 回复于：2003-02-28 08:36:49
我的办法是实践得出来的，如果你的连接数很大的时候，10，20和1，200的结果是完全不同的。上面的用户发生数据库慢时，数据库的锁占有率一定很高，他还需要加大锁才行。关于oninit无法重起，我也遇到过，者和操作系统有关。
zoukunhong 回复于：2003-02-28 09:56:13
1。PHYBUFF和LOGBUFF可能太大，通常是16，32，128等，
2。NETTYPE中一个poll线索通常连接的用户数不要超过100。
3。OPTCOMPIND 改为0。
zzher 回复于：2003-02-28 15:00:51
引用：原帖由 "孤独剑"]当机可能是由操作系统造成的,数据库本身无任何错误信息,查看共享内存等核心参数设置,查看系统日志,你用的好像是sco,sco不要用kaio,kaio有问题,适当减少一些系统资源的分配,操作系统打补丁.
发表：
请问kaio到底是指什么东西？
muzx 回复于：2003-02-28 17:24:54
kaio是指核心异步IO！
如果你没有设置特意设置，那么你的系统就不会使用它！
如果你的dbs建立在熟文件上，就不要企图使用kaio。
zzher 回复于：2003-02-28 18:51:58
那我应该没有用到.我没特意设过,用的是裸设备.
muzx 回复于：2003-02-28 19:06:27
有没有用kaio可以用命令确认的
onstat -g glo
如果其中没有kaio，那肯定没有用到kaio。
rock1001 回复于：2003-03-14 08:41:02
[color=red]muzx ：[/color]
[color=blue]ROOTOFFSET 100 # Offset of root dbspace into device (Kbytes)
这样子设有什么影响呢？
这样作很好，这是一个好习惯！[/color]
[size=18]－－－－－为什么说是一个好习惯呢？设置偏移量有什么好处？？？？[/size] :?: :?:
muzx 回复于：2003-03-14 08:53:44
informix建议用户使用裸设备作为数据库空间，由于使用裸设备的缘故，informix建议用户在初始化数据库空间时最好给一个偏移量，避开设备的初始段，主要是为了避免覆盖os的设备管理信息或部分硬件的兼容性（这种情况虽然不多见，但确实存在，出于安全考虑）。
如果你使用的是熟设备，可以不必考虑这些因素，os已经替你考虑了。
semicolon 回复于：2003-03-14 12:35:51
看看
受益匪浅
bysysnet 回复于：2003-03-15 16:34:02
Read error occurred during connection attempt.
This error can occur on either the client or database server side.
When you encounter this error on the client side, it indicates that a network I/O error occurred when the client tried to connect to a database server. Probably the connection attempt timed out because the database server or the network was very busy, too many clients were attempting to connect to the database server simultaneously, or the database server was taken off-line during the connection attempt.
If you are using INFORMIX-OnLine Dynamic Server, verify that the database server is still on-line. If you are using the INFORMIX-SE database server, verify that the sqlexecd daemon for the database server is still running. Use the environment variables INFORMIXCONTIME and/or INFORMIXCONRETRY on the client side to increase the connection time and number of retry attempts.
When you encounter this error on the database server side, it is a warning that a network I/O error is detected while the database server is accepting a connection request from a client. This error usually occurs when the database server or the network is very busy or when too many clients are trying to connect to the database server at once. The database server might be taking so long to respond to a client that the client's connection request timed out before the connection is complete. Or possibly a client terminated its connection attempt before the connection is completely established.
If this error is seen only occasionally in the server message log, it is just a warning. No corrective action is required on the server side.
If this error occurs frequently on an INFORMIX-OnLine server that runs on a host with multiple processors, you might want to tune the database server by increasing the number of poll threads and/or listener threads.
bysysnet 回复于：2003-03-15 16:39:35
增加你的locks values,buffers values,你给出onstat -R,onstat -g seg
,onstat -l,onstat -m的结果.
muzx 回复于：2003-03-15 18:23:00
引用：原帖由 "zzher" 发表：
ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 2315.67 872.96 479 1696
从以上参数看，暂时没有必要增加locks,buffers,因为系统并没有这样的需求,也（你的系统已经运行了一天半来）没有出现这两个参数溢出的记录。
zzher 回复于：2003-03-31 17:32:13
问题还是没有解决，一些信息继续贴如下！
$onstat -R
Informix Dynamic Server Version 7.30.UC2 -- On-Line -- Up 00:39:13 -- 458752 K
bytes
8 buffer LRU queue pairs priority levels
# f/m pair total % of length LOW MED_LOW MED_HIGH HIGH
0 f 16510 99.8% 16474 2 16390 72 10
1 m 0.2% 36 0 36 0 0
2 f 16511 99.8% 16482 5 16413 54 10
3 m 0.2% 29 0 29 0 0
4 F 16507 99.8% 16478 6 16385 68 19
5 m 0.2% 29 0 29 0 0
6 f 16509 99.8% 16484 0 16388 83 13
7 m 0.2% 25 0 25 0 0
8 f 16509 99.8% 16480 0 16405 66 9
9 m 0.2% 29 0 29 0 0
10 f 16507 99.8% 16479 4 16405 63 7
11 m 0.2% 28 0 28 0 0
12 f 16509 99.9% 16489 13 16409 58 9
13 m 0.1% 20 0 20 0 0
14 f 16509 99.8% 16482 0 16397 76 9
15 m 0.2% 27 0 27 0 0
223 dirty, 132071 queued, 132100 total, 262144 hash buckets, 2048 buffer size
start clean at 60% (of pair total) dirty, or 9908 buffs dirty, stop at 50%
$onstat -g seg
Informix Dynamic Server Version 7.30.UC2 -- On-Line -- Up 00:40:25 -- 458752 K
bytes
Segment Summary:
id key addr size ovhd class blkused blkfree
1 1381451777 82000000 402653184 6996 R 48724 428
2 1381451778 9a000000 8388608 720 V 1017 7
3 1381451779 9a800000 20971520 912 V 2558 2
4 1381451780 9bc00000 4194304 656 M 260 252
5 1381451781 9c000000 20971520 912 V 1151 1409
6 1381451782 9d400000 8388608 720 V 1 1023
7 1381451783 9dc00000 8388608 720 V 66 958
Total: - - 473956352 - - 53777 4079
(* segment locked in memory)
$onstat -l
Informix Dynamic Server Version 7.30.UC2 -- On-Line -- Up 00:41:49 -- 458752 K
bytes
Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-1 13 10000 2522 8 315.25%
phybegin physize phypos phyused %used
10003f 25000 6554 13 0.05
Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-3 0 10000 2394 74 17 32.4 4.4
Subsystem numrecs Log Space used
OLDRSAM 2394 120636
address number flags uniqid begin size used %used
82ae5d20 1 U-B---- 1 1061e7 5000 5000 100.00%
82ae5d3c 2 U-B---- 2 10756f 5000 5000 100.00%
82ae5d58 3 U-B---- 3 1088f7 5000 5000 100.00%
82ae5d74 4 U-B---- 4 109c7f 5000 5000 100.00%
82ae5d90 5 U-B---- 5 10b007 5000 5000 100.00%
82ae5dac 6 U---C-L 6 300035 25000 2782 11.13%
82ae5dc8 7 F------ 0 3061dd 24945 0 0.00%
$ onstat -m
Informix Dynamic Server Version 7.30.UC2 -- On-Line -- Up 00:42:56 -- 458752 K
bytes
Message Log File: /usr/informix/online.log
16:44:40 dynamically allocated new shared memory segment (size 20553728)
16:44:41 dynamically allocated new shared memory segment (size 8388608)
16:44:41 dynamically allocated new shared memory segment (size 8388608)
16:44:45 Logical Recovery Complete.
0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks
16:44:45 Dataskip is now OFF for all dbspaces
16:44:45 On-Line Mode
16:44:45 Checkpoint Completed: duration was 0 seconds.
16:49:47 Checkpoint Completed: duration was 0 seconds.
16:54:51 Checkpoint Completed: duration was 1 seconds.
16:59:56 Checkpoint Completed: duration was 0 seconds.
17:05:01 Checkpoint Completed: duration was 2 seconds.
17:10:12 Checkpoint Completed: duration was 8 seconds.
17:15:15 Checkpoint Completed: duration was 0 seconds.
17:20:18 Checkpoint Completed: duration was 0 seconds.
17:25:21 Checkpoint Completed: duration was 0 seconds.
mywg 回复于：2003-03-31 18:22:48
大哥：
心情好的话，动动4GL的应用。我觉得应用是根本。只是调整DB不解决实际的问题
yjmsx 回复于：2003-04-12 12:23:29
PHYSBUFF 20000 # Physical log buffer size (Kbytes)
LOGBUFF 20000 # Logical log buffer size (Kbytes)
这两项为什么会这么大？
zzher 回复于：2003-04-17 09:54:38
请问这么大有何不妥？谢谢
yjmsx 回复于：2003-04-17 19:06:20
LOCKS 197712 # Maximum number of locks
BUFFERS 132100 # Maximum number of shared buffers
我感觉这两项再大些比PHYSBUFF和LOGBUFF 这么大要好吧，不知对不对
love4you 回复于：2003-04-17 21:59:25
说的对，逻辑日志缓冲区和物理日志缓冲区太大了很容易在数据库
异常宕机的时候造成日志丢失。数据库在FASTRECOVERY的时候失败，
数据丢失。
zzher 回复于：2003-05-09 13:33:17
在大梦版主的悉心帮助下，问题终于解决了，就是为INFORMXI分流（大梦语，我可想不出这个办法）,把一部份用户的informixserver设为informix服务的别名，就OK了！！
感谢大梦！！！
oldv 回复于：2003-07-23 14:56:52
弱弱得问问，tlitcp和ipcshm这两种协议对客户端的应用会有什么样的影响呢？
informix应该有用一种协议支持所有用户（也许是成百上千？）的办法？
hmxiong 回复于：2003-08-03 12:37:04
引用：原帖由 "zzher" 发表：
在大梦版主的悉心帮助下，问题终于解决了，就是为INFORMXI分流（大梦语，我可想不出这个办法）,把一部份用户的informixserver设为informix服务的别名，就OK了！！
感谢大梦！！！
请问如何设置分流？需要修改那些地方？
|
 |
原文链接：http://bbs.chinaunix.net/viewthread.php?tid=20781
转载请注明作者名及原文出处
|
|
|