How do I make people read my blog more frequently?
Informix database development
Hello Guest
  
  • Login
• Register…
• Start blog
  • Who, Where, When
• What can I do?
• What to Read?
  • Polls
• Avatars
• Interests
  • Cities and Countries
• Random blog
• Users search
  • Search
• Games
• Tests
• QAIX
  • Talxy Chat
• Horoscope
• Online
 
Зарегистрируйся!

QAIX > Informix database developmentGo to page: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | next »

  Recent blog posts: 
  They have birthday today: 
  Forums:   
  Discuss: 
  Recent forum topics: 
  Recent forum comments:
  Moderators:
Thursday, 8 May 2008
I want a String from Position N until End Matthias 05:20:15
 Hello - i need your brain...

Is there a function that select a column from pos a until max
(length of the column) ?

I need something like this:

select concat("new-string"­, substr(column_name,­10, max-length-of-col ))
from mytable;

- i have to change the fist n characters of a column.

and this:

select concat("new-string"­, substr(column_name,­10,100)) from table;

is not working because the column can be more than 100 characters long.


is there someone with a idea ?

Optionscomment 7 answers | Add comment
Thursday, 13 December 2007
Performance tuning: troubling long checkpoints and other issues Jim Kenedy 09:22:17
 Hello All,
Here's some quick history... Recently the number of users has
increased to over 500 sessions. All our users are now complaining of
poor performance. Our checkpoints are slow to complete (4 seconds and
up to 13 seconds during peak activity) and the CPU activity is
constantly over 95%. I've been tweaking LRU, CLEANERS, BUFFERS and
I'm now more perplexed than ever.

This is an OLTP system with about 5 batch jobs that are constantly run
during the day. No other processes other than these batch jobs are run
on the database server. The system is not swapping and memory used is
sitting at 95%. At one point, a number of years ago, I tried kaio but
on this SCO platform it actually performed worse; but perhaps I should
try it once again.

Informix Dynamic Server Version 7.31.UD8
SCO OpenServer 5.0.6
Dual Pentium III Xeon 1GHz, 4GB ram, 12 * 18GB hard drives arranged in
RAID 1 pairs (the first pair is dedicated to the O/S, the rest to
Informix)

Update statistics is run nightly using one of the very good IIUG 4GL
programs.
We only have one temp dbspace since we cannot allocate more because of
an application incompatibility (it uses table rowids).

I've exhausted input from a number of performance tuning books and
searches through this newsgroup.

Any help would be greatly appreciated...

Thanks,
Ron

-------------------­--------------------­-----------
# Root Dbspace Configuration
ROOTNAME rootdbs # Root dbspace name
ROOTPATH /dev/rdbs_root # Path for device containing root
dbspace
ROOTOFFSET 0 # Offset of root dbspace into device
(Kbytes)
ROOTSIZE 1024000 # 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 240000 # Physical log file size (Kbytes)

# Logical Log Configuration
LOGFILES 60 # Number of logical log files
LOGSIZE 1000 # Logical log size (Kbytes)

# Diagnostics
MSGPATH /u/informix7/online­.log # System message log file path
CONSOLE /u/informix7/online­.log # System console message path
ALARMPROGRAM /u/informix7/etc/lo­g_full.sh # Alarm program path
SYSALARMPROGRAM /u/informix7/etc/ev­idence.sh # System Alarm program
path
TBLSPACE_STATS 1

# System Archive Tape Device
TAPEDEV secondary:/dev/rStp­0 # Tape device path
TAPEBLK 64 # Tape block size (Kbytes)
TAPESIZE 50000000 # Maximum amount of data to put on tape
(Kbytes)

# Log Archive Tape Device
LTAPEDEV /u/informix7/db-log­s/logtape # Log tape device path
LTAPEBLK 64 # Log tape block size (Kbytes)
LTAPESIZE 25000000 # Max amount of data to put on log tape
(Kbytes)

# Optical
STAGEBLOB # Informix Dynamic Server/Optical
staging area

# System Configuration
SERVERNUM 0 # Unique id corresponding to a Dynamic
Server instance
DBSERVERNAME local_on # Name of default database server
DBSERVERALIASES primary # List of alternate dbservernames
NETTYPE ipcshm,2,50,CPU # Configure poll thread(s) for nettype
NETTYPE tlitcp,2,300,NET # Configure poll thread(s) for nettype
DEADLOCK_TIMEOUT 60 # Max time to wait of lock in
distributed env.
RESIDENT 1 # Forced residency flag (Yes = 1, No =
0)

MULTIPROCESSOR 1 # 0 for single-processor, 1 for
multi-processor
NUMCPUVPS 2 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps
to one

NOAGE 1 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 2 # Affinity number of processors

# Shared Memory Parameters
LOCKS 150000 # Maximum number of locks
# Jan 18-06...
#BUFFERS 700000 # Maximum number of shared buffers
BUFFERS 600000 # Maximum number of shared buffers
# END Jan 16-06
# Jan 19-06: Try to decrease maxlen in onstat -q ioq and have one
# aio io/s in onstat -g iov ~1
#NUMAIOVPS 16 # Number of IO vps
NUMAIOVPS 18 # Number of IO vps
# END Jan 19-06
PHYSBUFF 32 # Physical log buffer size (Kbytes)
LOGBUFF 32 # Logical log buffer size (Kbytes)
LOGSMAX 60 # Maximum number of logical log files
# Jan 19-06: set CLEANERS >= LRUS
#CLEANERS 32 # Number of buffer cleaner processes
CLEANERS 127 # Number of buffer cleaner processes
# END Jan 19-06
SHMBASE 0x10000000 # Shared memory base address
# Jan 18-06
#SHMVIRTSIZE 153600 # initial virtual shared memory
segment size
SHMVIRTSIZE 235520 # initial virtual shared memory segment
size
#SHMADD 8192 # Size of new shared memory segments
(Kbytes)
SHMADD 16384 # Size of new shared memory segments
(Kbytes)
# END Jan 18-06
SHMTOTAL 0 # Total shared memory (Kbytes).
0=>unlimited
CKPTINTVL 300 # Check point interval (in sec)
# Jan 19-06: Pump this up and avoid = 64, 96 to lower bufwaits
# and reduce the buffer turnover rate
# and potentially lower checkpoints
#LRUS 64 # Number of LRU queues
LRUS 127 # Number of LRU queues
# END Jan 19-06
LRU_MAX_DIRTY 2 # LRU percent dirty begin cleaning
limit
LRU_MIN_DIRTY 1 # 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 /u/informix7/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,additio­nal)
CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds)
CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR
queue (Kb
ytes)
CDR_LOGDELTA 30 # % of log space allowed in queue
memory
CDR_NUMCONNECT 16 # Expected connections per server
CDR_NIFRETRY 300 # Connection retry (seconds)
CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0
none, 9 ma
x)

# Backup/Restore variables
BAR_ACT_LOG /u/informix7/bar_ac­t.log # ON-Bar Log file - not in
/tmp please
BAR_DEBUG_LOG /u/informix7/bar_db­ug.log
# ON-Bar Debug Log - not in /tmp please
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/on­bar. Change to
# ism_catalog -create_bootstrap -pool <new name>
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 0 # 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 O
S(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 1 # 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­ on

-------------------­--------------------­-----------
IBM Informix Dynamic Server Version 7.31.UD8 -- On-Line (Prim) --
Up 07:14:23 -- 1527808 Kbytes

Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
28338861 43035627 934277718 96.97 2014044 12510577 11428871 82.38

isamtot open start read write rewrite delete commit
rollbk
485287136 5433269 20156634 395955853 3811044 702170 376400 312198
426

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 13083.09 6945.83 86 173

bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
3461043 591 240729382 0 0 534 90232 1131751

ixda-RA idx-RA da-RA RA-pgsused lchwaits
5164804 173605 14163938 19493127 177765


ReadAhead Utilization (UR): 99.9527 %
Bufwaits Ratio(BR): 6.35468 %
Average Buffer Turnover Rate (BTR): 12.5388/HR

Stats reset 07:14:22 ago.

-------------------­--------------------­-----------
Segment Summary:
id key addr size ovhd class blkused blkfree
202 1381386241 10000000 1312817152 39768 R* 160061 195
203 1381386242 5e400000 243269632 4352 V 27719 1977
204 1381386243 6cc00000 4194304 704 M 311 201
205 1381386244 6d000000 4194304 704 M 309 203
Total: - - 1564475392 - - 188400 2576

(* segment locked in memory)

-------------------­--------------------­-----------
Fg Writes LRU Writes Chunk Writes
0 652682 630723

-------------------­--------------------­-----------
Dbspaces
address number flags fchunk nchunks flags owner name
5e45c150 1 1 1 1 N informix rootdbs
5e487f20 2 1 2 2 N informix logsdbs
5e493f30 3 2001 4 1 N T informix tempdbs
5ef44b18 4 1 5 1 N informix miscdbs
5ef44bd8 5 1 6 2 N informix ser1dbs
5ef44c98 6 1 8 3 N informix std1dbs
5ef44d58 7 1 10 3 N informix std2dbs
5ef44e18 8 1 12 3 N informix std3dbs
5ef44ed8 9 1 14 3 N informix std4dbs
5ef44f98 10 1 16 3 N informix std5dbs
5ef45058 11 1 18 3 N informix std6dbs
5ef45118 12 1 20 2 N informix std7dbs
5ef451d8 13 1 22 2 N informix std8dbs
13 active, 2047 maximum

Chunks
address chk/dbs offset size free bpages flags pathname
5e45c210 1 1 0 512000 389963 PO-
/dev/rdbs_root
5e492e30 2 2 0 1024000 23947 PO-
/dev/rdbs_logs_1
5e492f30 3 2 0 512000 11997 PO-
/dev/rdbs_logs_2
5e493030 4 3 0 512000 453380 PO-
/dev/rdbs_temp
5e493130 5 4 0 512000 457696 PO-
/dev/rdbs_misc
5e493230 6 5 0 1024000 110700 PO-
/dev/rdbs_ser1_1
5e493330 7 5 0 1024000 532469 PO-
/dev/rdbs_ser1_2
5e493430 8 6 0 1024000 228 PO-
/dev/rdbs_std1_1
5e493530 9 6 0 1024000 33980 PO-
/dev/rdbs_std1_2
5e493630 10 7 0 1024000 2 PO-
/dev/rdbs_std2_1
5e493730 11 7 0 1024000 192568 PO-
/dev/rdbs_std2_2
5e493830 12 8 0 1024000 22409 PO-
/dev/rdbs_std3_1
5e493930 13 8 0 1024000 55258 PO-
/dev/rdbs_std3_2
5e493a30 14 9 0 1024000 145473 PO-
/dev/rdbs_std4_1
5e493b30 15 9 0 1024000 36165 PO-
/dev/rdbs_std4_2
5e493c30 16 10 0 1024000 67826 PO-
/dev/rdbs_std5_1
5e493d30 17 10 0 1024000 28078 PO-
/dev/rdbs_std5_2
5e493e30 18 11 0 1024000 54 PO-
/dev/rdbs_std6_1
5ef44018 19 11 0 1024000 18787 PO-
/dev/rdbs_std6_2
5ef44118 20 12 0 1024000 17948 PO-
/dev/rdbs_std7_1
5ef44218 21 12 0 1024000 275227 PO-
/dev/rdbs_std7_2
5ef44318 22 13 0 1024000 435972 PO-
/dev/rdbs_std8_1
5ef44418 23 13 0 1024000 0 PO-
/dev/rdbs_std8_2
5ef44518 24 6 0 1024000 783893 PO-
/dev/rdbs_std1_3
5ef44618 25 7 0 1024000 1023997 PO-
/dev/rdbs_std2_3
5ef44718 26 8 0 1024000 802958 PO-
/dev/rdbs_std3_3
5ef44818 27 9 0 1024000 1023997 PO-
/dev/rdbs_std4_3
5ef44918 28 10 0 1024000 913533 PO-
/dev/rdbs_std5_3
5ef44a18 29 11 0 1024000 857653 PO-
/dev/rdbs_std6_3
29 active, 2047 maximum

-------------------­--------------------­-----------
Sar:
00:00:00 %usr %sys %wio %idle (-u)
08:00:02 11 3 4 83
08:20:01 14 6 44 36
08:40:00 25 9 51 15
09:00:04 29 12 49 11
09:20:01 30 14 45 11
09:40:00 35 17 32 16
10:00:04 24 18 33 25
10:20:01 50 26 22 3
10:40:00 39 24 30 7
11:00:05 33 20 31 15
11:20:01 34 19 32 15
11:40:00 44 25 26 5
12:00:04 37 24 30 8
12:20:00 26 18 48 7
12:40:00 35 19 34 12
13:00:04 38 23 32 7
13:20:00 50 30 16 4
13:40:00 52 24 22 2
14:00:03 63 34 2 1

-------------------­--------------------­-----------
AIO I/O vps:
class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup
errors
msc 0 i 4.6 123371 0 0 0 123053 1.0
0
aio 0 s 282.5 7554428 6156928 1357672 0 6764843 1.1
0
aio 1 i 153.9 4116383 3385321 701987 0 4450497 0.9
0
aio 2 s 83.4 2229827 1806420 411309 0 2431384 0.9
0
aio 3 i 46.5 1244465 1013423 225073 0 1297927 1.0
0
aio 4 i 28.5 761015 615322 142551 0 769406 1.0
0
aio 5 i 18.7 500875 395848 103281 0 499687 1.0
0
aio 6 i 13.1 350703 264049 85473 0 343267 1.0
0
aio 7 i 9.4 251367 177146 73490 0 243967 1.0
0
aio 8 i 6.7 179619 116167 62928 0 174696 1.0
0
aio 9 i 4.8 129113 72863 55880 0 125591 1.0
0
aio 10 i 3.6 97510 46817 50498 0 93095 1.0
0
aio 11 i 2.9 76595 30429 46053 0 71724 1.1
0
aio 12 i 2.3 61692 20557 41049 0 58064 1.1
0
aio 13 i 1.9 51396 13779 37544 0 47839 1.1
0
aio 14 i 1.6 43143 9470 33624 0 39522 1.1
0
aio 15 i 1.4 38578 7120 31419 0 33127 1.2
0
aio 16 i 1.2 32924 5427 27469 0 27174 1.2
0
aio 17 i 1.1 29137 4209 24900 0 20466 1.4
0
pio 0 i 1.1 29090 0 29090 0 29084 1.0
0
lio 0 i 12.9 343649 0 343649 0 343161 1.0
0

-------------------­--------------------­-----------
AIO I/O queues:
q name/id len maxlen totalops dskread dskwrite dskcopy
adt 0 0 0 0 0 0 0
msc 0 0 2 123463 0 0 0
aio 0 0 17 2293347 53399 2144598 0
pio 0 0 1 29116 0 29116 0
lio 0 0 1 343923 0 343923 0
gfd 3 0 4 4495 4199 296 0
gfd 4 0 2 39992 39992 0 0
gfd 5 0 1 1 1 0 0
gfd 6 0 476 1477481 436586 1040895 0
gfd 7 0 8 11600 11593 7 0
gfd 8 0 8 31031 31026 5 0
gfd 9 0 1 1 1 0 0
gfd 10 0 16 2438089 2430462 7627 0
gfd 11 0 652 2114460 1900772 213688 0
gfd 12 0 43 463897 459983 3914 0
gfd 13 0 133 270922 249039 21883 0
gfd 14 0 24 2140186 2129933 10253 0
gfd 15 0 169 4364015 4236755 127260 0
gfd 16 0 250 2178948 2079900 99048 0
gfd 17 0 18 488508 473094 15414 0
gfd 18 0 18 1915670 1902514 13156 0
gfd 19 0 24 1159433 1150469 8964 0
gfd 20 0 16 702189 700656 1533 0
gfd 21 0 18 636072 628427 7645 0
gfd 22 0 24 5622262 5611241 11021 0
gfd 23 0 24 2106650 2096195 10455 0
gfd 24 0 17 410803 402257 8546 0
gfd 25 0 8 800966 800966 0 0
gfd 26 0 39 839544 787077 52467 0
gfd 27 0 1 1 1 0 0
gfd 28 0 71 461593 433817 27776 0
gfd 29 0 1 1 1 0 0
gfd 30 0 16 3951 3903 48 0
gfd 31 0 16 90865 86742 4123 0

-------------------­--------------------­-----------
127 buffer LRU queue pairs priority levels
# f/m pair total % of length LOW MED_LOW MED_HIGH HIGH
0 f 4720 99.8% 4710 0 4582 117 11
1 m 0.2% 10 0 10 0 0
2 f 4717 99.7% 4704 0 4581 107 16
3 m 0.3% 13 0 13 0 0
4 f 4721 99.8% 4710 0 4584 111 15
5 m 0.2% 11 0 11 0 0
6 f 4723 99.8% 4713 0 4544 157 12
7 m 0.2% 10 0 10 0 0
8 f 4723 99.7% 4711 0 4583 110 18
9 m 0.3% 12 0 12 0 0
10 f 4720 99.9% 4714 0 4592 107 15
11 m 0.1% 6 0 6 0 0
12 f 4719 99.8% 4710 0 4585 111 14
13 m 0.2% 9 0 9 0 0
14 f 4721 99.7% 4708 0 4594 108 6
15 m 0.3% 13 0 13 0 0
16 f 4723 99.7% 4710 0 4590 111 9
17 m 0.3% 13 0 13 0 0
18 f 4724 99.6% 4706 0 4571 121 14
19 m 0.4% 18 0 18 0 0
20 f 4720 99.7% 4705 0 4586 107 12
21 m 0.3% 15 0 15 0 0
22 f 4720 99.8% 4709 0 4580 115 14
23 m 0.2% 11 0 11 0 0
24 f 4724 99.9% 4718 0 4603 109 6
25 m 0.1% 6 0 6 0 0
26 f 4721 99.8% 4710 0 4560 139 11
27 m 0.2% 11 0 11 0 0
28 f 4721 99.5% 4698 0 4585 104 9
29 m 0.5% 23 0 23 0 0
30 f 4722 99.9% 4715 0 4588 115 12
31 m 0.1% 7 0 7 0 0
32 f 4721 99.9% 4714 0 4599 103 12
33 m 0.1% 7 0 7 0 0
34 f 4722 99.8% 4711 0 4586 113 12
35 m 0.2% 11 0 11 0 0
36 f 4721 99.7% 4707 0 4578 119 10
37 m 0.3% 14 0 14 0 0
38 f 4720 99.8% 4710 0 4569 124 17
39 m 0.2% 10 0 10 0 0
40 f 4719 99.8% 4709 0 4589 112 8
41 m 0.2% 10 0 10 0 0
42 f 4720 99.8% 4709 0 4580 120 9
43 m 0.2% 11 0 11 0 0
44 f 4722 99.8% 4711 0 4589 110 12
45 m 0.2% 11 0 11 0 0
46 f 4720 99.8% 4710 0 4587 109 14
47 m 0.2% 10 0 10 0 0
48 f 4721 99.8% 4710 0 4588 114 8
49 m 0.2% 11 0 11 0 0
50 f 4722 99.7% 4709 0 4588 111 10
51 m 0.3% 13 0 13 0 0
52 f 4722 99.6% 4701 0 4534 151 16
53 m 0.4% 21 0 20 1 0
54 f 4721 99.8% 4713 0 4588 116 9
55 m 0.2% 8 0 8 0 0
56 f 4721 99.6% 4702 0 4568 128 6
57 m 0.4% 19 0 19 0 0
58 f 4723 99.6% 4706 0 4582 116 8
59 m 0.4% 17 0 17 0 0
60 f 4722 99.6% 4705 0 4584 113 8
61 m 0.4% 17 0 17 0 0
62 f 4722 99.8% 4712 0 4598 106 8
63 m 0.2% 10 0 10 0 0
64 f 4723 99.7% 4710 0 4584 116 10
65 m 0.3% 13 0 13 0 0
66 f 4723 99.9% 4716 0 4599 106 11
67 m 0.1% 7 0 7 0 0
68 f 4722 99.7% 4706 0 4572 121 13
69 m 0.3% 16 0 16 0 0
70 f 4720 99.6% 4703 0 4582 110 11
71 m 0.4% 17 0 17 0 0
72 f 4726 99.8% 4717 0 4586 117 14
73 m 0.2% 9 0 9 0 0
74 f 4720 99.9% 4713 0 4590 112 11
75 m 0.1% 7 0 7 0 0
76 f 4724 99.7% 4712 0 4589 107 16
77 m 0.3% 12 0 12 0 0
78 f 4724 99.8% 4714 0 4586 113 15
79 m 0.2% 10 0 10 0 0
80 f 4723 99.8% 4712 0 4588 117 7
81 m 0.2% 11 0 11 0 0
82 f 4721 99.8% 4710 0 4580 124 6
83 m 0.2% 11 0 11 0 0
84 f 4722 99.5% 4697 0 4587 106 4
85 m 0.5% 25 0 25 0 0
86 f 4722 99.7% 4707 0 4588 109 10
87 m 0.3% 15 0 15 0 0
88 f 4724 99.7% 4708 0 4586 116 6
89 m 0.3% 16 0 16 0 0
90 f 4721 99.8% 4710 0 4594 113 3
91 m 0.2% 11 0 11 0 0
92 f 4721 99.6% 4704 0 4583 115 6
93 m 0.4% 17 0 17 0 0
94 f 4725 99.7% 4712 0 4576 126 10
95 m 0.3% 13 0 13 0 0
96 f 4721 99.7% 4705 0 4578 117 10
97 m 0.3% 16 0 16 0 0
98 f 4722 99.7% 4710 0 4585 109 16
99 m 0.3% 12 0 12 0 0
100 f 4721 99.8% 4713 0 4597 106 10
101 m 0.2% 8 0 8 0 0
102 f 4718 99.7% 4706 0 4603 92 11
103 m 0.3% 12 0 12 0 0
104 f 4723 99.6% 4704 0 4594 98 12
105 m 0.4% 19 0 19 0 0
106 f 4721 99.7% 4707 0 4577 120 10
107 m 0.3% 14 0 14 0 0
108 f 4719 99.7% 4707 0 4579 120 8
109 m 0.3% 12 0 12 0 0
110 f 4723 99.7% 4710 0 4579 121 10
111 m 0.3% 13 0 13 0 0
112 f 4722 99.6% 4705 0 4575 118 12
113 m 0.4% 17 0 17 0 0
114 f 4722 99.8% 4712 0 4589 113 10
115 m 0.2% 10 0 10 0 0
116 f 4721 99.8% 4710 0 4583 120 7
117 m 0.2% 11 0 11 0 0
118 f 4721 99.7% 4709 0 4566 130 13
119 m 0.3% 12 0 12 0 0
120 f 4722 99.8% 4714 0 4590 111 13
121 m 0.2% 8 0 8 0 0
122 f 4722 99.7% 4708 0 4579 119 10
123 m 0.3% 14 0 14 0 0
124 f 4720 99.8% 4709 0 4581 113 15
125 m 0.2% 11 0 11 0 0
126 f 4721 99.7% 4709 0 4576 117 16
127 m 0.3% 12 0 12 0 0
128 f 4723 99.7% 4709 0 4579 120 10
129 m 0.3% 14 0 14 0 0
130 f 4720 99.6% 4700 0 4590 100 10
131 m 0.4% 20 0 19 1 0
132 f 4723 99.7% 4711 0 4594 104 13
133 m 0.3% 12 0 12 0 0
134 f 4722 99.8% 4712 0 4580 120 12
135 m 0.2% 10 0 10 0 0
136 f 4726 99.7% 4711 0 4579 118 14
137 m 0.3% 15 0 15 0 0
138 f 4723 99.8% 4712 0 4587 107 18
139 m 0.2% 11 0 11 0 0
140 f 4720 99.6% 4703 0 4572 117 14
141 m 0.4% 17 0 17 0 0
142 f 4722 99.7% 4709 0 4575 123 11
143 m 0.3% 13 0 13 0 0
144 f 4722 99.6% 4704 0 4568 124 12
145 m 0.4% 18 0 18 0 0
146 f 4725 99.7% 4711 0 4598 106 7
147 m 0.3% 14 0 14 0 0
148 f 4724 99.8% 4716 0 4577 127 12
149 m 0.2% 8 0 8 0 0
150 f 4718 99.7% 4705 0 4577 120 8
151 m 0.3% 13 0 13 0 0
152 f 4716 99.7% 4704 0 4575 118 11
153 m 0.3% 12 0 12 0 0
154 f 4720 99.8% 4710 0 4574 122 14
155 m 0.2% 10 0 10 0 0
156 f 4721 99.7% 4706 0 4579 117 10
157 m 0.3% 15 0 15 0 0
158 f 4723 99.7% 4711 0 4596 103 12
159 m 0.3% 12 0 12 0 0
160 f 4723 99.7% 4709 0 4585 115 9
161 m 0.3% 14 0 14 0 0
162 f 4722 99.7% 4709 0 4571 121 17
163 m 0.3% 13 0 13 0 0
164 f 4720 99.8% 4709 0 4589 111 9
165 m 0.2% 11 0 11 0 0
166 f 4723 99.6% 4706 0 4577 117 12
167 m 0.4% 17 0 16 1 0
168 f 4722 99.7% 4709 0 4564 132 13
169 m 0.3% 13 0 13 0 0
170 f 4723 99.7% 4710 0 4562 138 10
171 m 0.3% 13 0 13 0 0
172 f 4723 99.7% 4710 0 4585 114 11
173 m 0.3% 13 0 13 0 0
174 f 4722 99.8% 4711 0 4569 131 11
175 m 0.2% 11 0 11 0 0
176 f 4719 99.7% 4705 0 4580 111 14
177 m 0.3% 14 0 14 0 0
178 f 4721 99.8% 4713 0 4580 125 8
179 m 0.2% 8 0 8 0 0
180 f 4722 99.7% 4709 0 4578 120 11
181 m 0.3% 13 0 13 0 0
182 f 4723 99.8% 4715 0 4590 114 11
183 m 0.2% 8 0 8 0 0
184 f 4723 99.7% 4711 0 4595 102 14
185 m 0.3% 12 0 12 0 0
186 f 4723 99.7% 4708 0 4575 124 9
187 m 0.3% 15 0 15 0 0
188 f 4722 99.7% 4710 0 4576 124 10
189 m 0.3% 12 0 11 1 0
190 f 4721 99.8% 4710 0 4567 127 16
191 m 0.2% 11 0 11 0 0
192 f 4723 99.8% 4714 0 4588 115 11
193 m 0.2% 9 0 9 0 0
194 f 4722 99.7% 4708 0 4594 108 6
195 m 0.3% 14 0 14 0 0
196 f 4721 99.8% 4712 0 4585 115 12
197 m 0.2% 9 0 9 0 0
198 f 4723 99.7% 4711 0 4598 100 13
199 m 0.3% 12 0 12 0 0
200 f 4724 99.7% 4710 0 4569 123 18
201 m 0.3% 14 0 14 0 0
202 f 4721 99.7% 4706 0 4570 122 14
203 m 0.3% 15 0 15 0 0
204 f 4722 99.7% 4709 0 4592 105 12
205 m 0.3% 13 0 13 0 0
206 f 4723 99.8% 4715 0 4590 116 9
207 m 0.2% 8 0 8 0 0
208 f 4724 99.7% 4712 0 4569 133 10
209 m 0.3% 12 0 11 1 0
210 f 4721 99.7% 4707 0 4579 113 15
211 m 0.3% 14 0 14 0 0
212 f 4723 99.7% 4708 0 4597 105 6
213 m 0.3% 15 0 15 0 0
214 f 4723 99.8% 4714 0 4591 116 7
215 m 0.2% 9 0 9 0 0
216 f 4724 99.7% 4709 0 4570 127 12
217 m 0.3% 15 0 15 0 0
218 f 4723 99.5% 4701 0 4585 106 10
219 m 0.5% 22 1 21 0 0
220 f 4721 99.7% 4707 0 4588 107 12
221 m 0.3% 14 0 14 0 0
222 f 4722 99.7% 4708 0 4584 115 9
223 m 0.3% 14 0 14 0 0
224 F 4721 99.7% 4707 0 4596 102 9
225 m 0.3% 14 0 14 0 0
226 f 4724 99.6% 4707 0 4571 128 8
227 m 0.4% 17 0 17 0 0
228 f 4720 99.7% 4704 0 4584 111 9
229 m 0.3% 16 0 16 0 0
230 f 4720 99.6% 4700 0 4566 126 8
231 m 0.4% 20 0 20 0 0
232 f 4724 99.8% 4713 0 4611 88 14
233 m 0.2% 11 0 11 0 0
234 f 4722 99.7% 4709 0 4565 136 8
235 m 0.3% 13 0 13 0 0
236 f 4720 99.7% 4706 0 4588 106 12
237 m 0.3% 14 0 14 0 0
238 f 4722 99.7% 4707 0 4593 102 12
239 m 0.3% 15 0 15 0 0
240 f 4722 99.9% 4716 0 4589 119 8
241 m 0.1% 6 0 6 0 0
242 f 4724 99.7% 4710 0 4590 107 13
243 m 0.3% 14 0 14 0 0
244 f 4720 99.7% 4704 0 4598 100 6
245 m 0.3% 16 0 16 0 0
246 f 4716 99.8% 4707 0 4583 115 9
247 m 0.2% 9 0 9 0 0
248 f 4720 99.7% 4705 0 4563 128 14
249 m 0.3% 15 0 15 0 0
250 f 4724 99.7% 4710 0 4578 117 15
251 m 0.3% 14 0 14 0 0
252 f 4719 99.8% 4708 0 4567 132 9
253 m 0.2% 11 0 11 0 0
1625 dirty, 599656 queued, 600000 total, 1048576 hash buckets, 2048
buffer size
start clean at 2% (of pair total) dirty, or 94 buffs dirty, stop at 1%
0 priority downgrades, 0 priority upgrades

Optionscomment 5 answers | Add comment
Monday, 9 July 2007
rshd: 0826-813 Permission is denied Frank 10:46:47
 just running an input screen and doing some updating... got following
error msg:
rshd: 0826-813 Permission is denied
Any help/suggestion is greatly appreciated... Thank you.

Optionscomment 3 answer | Add comment
Saturday, 11 November 2006
fragmentation Dooku Maul 17:45:04
 
Hi: It wanted to know that type of fragmentation is but the optimal one:
1. Using line of commandos
2. Recreating totally the table
And it wanted to know as of of these two types of fragmentation he is but
the optimal one:

example1:
Begin work;
set lock mode to not wait;
lock table tabla_ejemplo1 in exclusive mode;
alter index idx_campo1 to cluster;
alter index idx_campo1 to not cluster;
commit work:

example2:
Begin work;
set lock mode to not wait;
lock table tabla_ejemplo2 in exclusive mode;
alter fragment on table tabla_ejemplo2 init fragment by round robin in
dbspacesA, dbspacesN;
-- index clustering will not be performed because above statement
-- will re-organize table's data as side effect
commit work;

thank you very much

___________________­____________________­____________________­______
Las mejores tiendas, los precios mas bajos, entregas en todo el mundo,
YupiMSN Compras: http://latam.msn.co­m/compras/

sending to informix-list
Optionscomment 8 answers | Add comment
Wednesday, 8 November 2006
last ddl date mozartny 18:29:34
 Is it possible to find out the last date/time that a database object has been modified (ie column added to a table).
OptionsAdd comment
Wednesday, 1 November 2006
Probably a dumb question but... Everett Mills 09:37:16
 Guys (particularly IBMers)-
Since Apple is porting its OS to Intel processors and since Mac
OS is really just a GUI sitting on top of UNIX... It shouldn't be much
of a stretch to take the Linux port of IDS and create a Mac port. Is
there a snowball's chance in Hades that IBM would do it? It would open
up a whole new server environment for a minimal investment.


--EEM
-----Original Message-----
From: Paul Watson [mailto:p­aul@oninit.com]
Sent: Monday, January 16, 2006 10:48 AM
To: informix-list@iiug.­org
Subject: Re: IDS cluster
Dirk Moolman wrote:
My company is talking about moving IDS on SUN, to IDS on Linux - and
also clustering the servers.
The only failover I know (on the Informix side), is ER and HDR. Is
clustering possible on Linux ?
(they mentioned having 2 DB servers and 2 application servers acting

as
failover etc. for each other)
Got a client running Suse Linux without a problem on HP hardware and
the HP clustering software
Paul Watson
Oninit Ltd
Tel : +44 1414161772
Cell : +44 7818 003457
___________________­____________________­________
Informix-list mailing list
Informix-list@iiug.­org

Optionscomment 6 answers | Add comment
Monday, 21 August 2006
DB stuck in Fast recovery mode Guest 11:57:39
 My db is stuck in fast recovery mode and giving no errors. How can i skip or bypass this to go into quiscent mode
OptionsAdd comment
Monday, 14 August 2006
Contiguous shared memory segment allocation failed at 0xd0000000 Yunyao Qu 01:17:44
 I was doing a mass update, delete ( big transaction) and found the info
in online log,

16:10:21 Maximum server connections 21
16:10:23 Requested shared memory segment size rounded from 8604KB to
8608KB
16:10:23 Contiguous shared memory segment allocation failed at 0xd0000000.
Allocation successful at 0x30000000.
Check SHMBASE is consistent with the value in
$INFORMIXDIR/etc/on­config.std.
If you are using the correct SHMBASE value in your ONCONFIG file, then
consider this message informational only.

16:10:23 Dynamically allocated new virtual shared memory segment (size
8608KB)
16:10:23 dynamically allocated 100000 locks
16:10:25 Requested shared memory segment size rounded from 8604KB to
8608KB
16:10:25 Contiguous shared memory segment allocation failed at 0xd0000000.
Allocation successful at 0xe0000000.
Check SHMBASE is consistent with the value in
$INFORMIXDIR/etc/on­config.std.
If you are using the correct SHMBASE value in your ONCONFIG file, then
consider this message informational only.


(1) why "Contiguous shared memory segment allocation failed at 0xd0000000.
Allocation successful at 0x30000000." ?

(2) whay "Check SHMBASE is consistent with the value in
$INFORMIXDIR/etc/on­config.std"? Since I used a different onconfig file:
onconfig.dev1

INFO in my onconfig:

informix@dolly $ more onconfig.dev1 | grep SHM
SHMBASE 0x40000000 # Shared memory base address
SHMVIRTSIZE 32768 # initial virtual shared memory segment
size
SHMADD 8192 # Size of new shared memory segments
(Kbytes)
EXTSHMADD 8192 # Size of new extension shared memory
segments (Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes).
0=>unlimited
# For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No.
DUMPSHMEM 1 # Dump a copy of shared memory

informix@dolly $ more onconfig.std | grep SHM
SHMBASE 0x30000000L # Shared memory base address
SHMVIRTSIZE 8192 # initial virtual shared memory segment
size
SHMADD 8192 # Size of new shared memory segments
(Kbytes)
EXTSHMADD 8192 # Size of new extension shared memory
segments (Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes).
0=>unlimited
# For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No.
DUMPSHMEM 1 # Dump a copy of shared memory


informix@dolly $ onstat -version
Program Name: onstat
Build Version: 10.00.UC4
Build Number: N204
Build Host: ibm6c1b
Build OS: AIX 5.2
Build Date: Fri Nov 18 23:37:26 CST 2005
GLS Version: glslib-4.00.UC7

Thank you for your time!
Frank

--
Yunyao "Frank" Qu
Computer Sciences Corporation(CSC)
NOAA/CLASS, (301)817-4696


Optionscomment 1 answer | Add comment
Sunday, 13 August 2006
Informix business grew by double digits in 2006 (Q1+Q2) Tambi Dude 07:11:16
 Looks like our dear ol Informix is alive and kicking well. Per IBM site,
license
revenue grew by double digits in 2006 (Q1+Q2).


http://www-03.ibm.c­om/developerworks/bl­ogs/page/gbowerman/2­0060802

"
The rise of Informix

The Q2 numbers are in and Informix Dynamic Server experienced another large
increase in revenue to build on the growth of Q1. As usual the details are
not released publicly but I am officially allowed to say, and I quote..


IDS license revenue grew by double digits in the first half of 2006 "






Optionscomment 83 answer | Add comment
Saturday, 12 August 2006
Informix in the press... Jean Georges Perrin 16:26:46
 Hi,

You all want to see Informix in the press, so help IIUG achieving this goal by
sending the following information to me:

Name of journalist,
e-mail,
name of newspaper.

Thanks

--
jgp

Optionscomment 2 answer | Add comment
Onpload error -- onpload exited abnormally during initialization Vratesh Chopra 12:16:55
 encounter stated initialization error while using onpload for Informix
9.4.

Sample scpirt i used was:

###################­####################­####################­#########
export testDB="testDB"

dbaccess <<EOF
drop database onpload
EOF

#dbaccess<<EOF
#create database $testDB with buffered log;
#EOF

dbaccess $testDB<<EOF
create table test_tab
(
a char(10),
b char (10)
);
EOF
test.unl

echo "1|2|" >> test.unl
echo "3|4|" >> test.unl

onpladm create job test_job -d test.unl -D $testDB -t test_tab -flN
test.log

onpladm run job test_job -fl

onpladm delete job test_job -fl -R

dbaccess $testDB<<EOF
select * from test_tab
EOF

dbaccess $testDB<<EOF
drop table test_tab
EOF

#dbaccess <<EOF
#drop database $testDB
#EOF

dbaccess <<EOF
drop database onpload
EOF
###################­####################­####################­######

Pls advice...
Cheers :)­
Vratesh

Optionscomment 1 answer | Add comment
Checkpoint Question - need feedback Madison Pruet 12:14:07
 I've got a question for the user community.

Checkpoints are a real pain because there is a period of time in which
user threads are going to be blocked.

I've been playing around with an idea in which I think I could do
non-blocking checkpoints. The cost of doing this, however, would be
that there would probably need to be a significant increase in the size
of the physical log file.

I know that implementing the fractional LRU min/max has helped reduce
the impact of the checkpoint, but the fractional LRU min/max is not a
guarantee - since it is possible that the LRU page writers won't be able
to keep up with the current activity.

Also - this idea would eliminate fuzzy checkpoints, which is probably a
good thing since fuzzy checkpoints do impact the recovery time of the
server.

So - basic question --- Is the cost of the increased physical log file
(maybe 3-4 times larger in some cases) totally outweigh the benefit of
non-blocking checkpoints?
Optionscomment 15 answers | Add comment
Re: oncheck -cc hangs Guest 12:07:31
 
Floyd Wellershaus wrote:
Any idea why we can't get an oncheck -cc on our big database ?
We have 5 instances on this box, one of them is a terabyte, with about 80,000 tables.
Oncheck -cc runs perfectly on all of them except the big one. It seems to just hang there. After 2 days, it has given zero output, is still showin up in the ps -ef, and the onstat -u, but is gaining no time, as if it is just hung.
Thanks,
floyd


Which IDS version?

onstat -g ath ..what state are the oncheck threads in?

onstat -g stk on each thread. what does that give? does it change?

onstat -g tpf - do any values for the threads change?

select sid from sysrstcb where tid = <thread id>

onstat -g ses <sid> what does that give?

select * from syssesprof where sid = <sid> does that change?

onstat -s and onstat -g lmx.. any mutexes /latches begin held for > 5
minutes?

Is an archive running?

If nothing appears to be moving then contact IBM Tech Support.

NOTE: With that many tables consider increasing DS_ and DD_ onconfig
parameters to cache the table info.
They are documented in the IDS 10 docs and available (sometimes
undocumented) in all versions.

David.

OptionsAdd comment
onperf.....who uses it? Mark.Scranton@Gmail.Com 01:04:39
 Gang -

I'm just curious.....any "onperf" fans? I am onsite using it for query
analysis (the xtree part that is), and would hope we don't ever get rid
of it (although I know it has been discussed many times), and would
wonder if it should be enhanced.

Any thoughts?

Mark Scranton

Optionscomment 6 answers | Add comment
Re: query using cpu Guest 00:59:57
 
Floyd Wellershaus wrote:
Any idea why a query that does a join of a table on itself, doing a count and a group by, would cause the cpu usage to go drastically up, almost instantly ? Not pdq, just a query, on a non fragged table.


It is doing multiple sequential scans of the table. All the table is
cached in the buffers hence no disk i/o hence cpu usage
flies up.

1. Query sysmaster:syssespro­f to find the session causing the problem
and watch its bufreads count flying up!

OR

2. onstat -g ses , get the thread id for the thread and check the
output from onstat -g tpf for the thread

!!

OptionsAdd comment
Friday, 11 August 2006
Ontape security when shipping tapes Kxk0912 20:51:59
 
We have a need to ship a level-0 ontape backup that will contain
sensitive data. How secure is the data when backed up using ontape?
Could a potential threat use a UNIX utility such as dd to read the
tape?

Thanks,
Kevin


--
kxk0912
-------------------­--------------------­--------------------­-------------
kxk0912's Profile: http://www.dbtalk.n­et/m636
View this thread: http://www.dbtalk.n­et/t324905

Optionscomment 7 answers | Add comment
Informix customer list Gm 19:55:14
 Hi Informix Group:

Can any one help me out in getting the list of
Informix customers with thier version info, OS,
Application info etc...

Thanks in advance
GMkris
Informix DBA



___________________­____________________­___________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.y­ahoo.com/
Optionscomment 10 answers | Add comment
fixed: dostats fails on indexkeyarray_out Dcp 19:21:11
 "Douglas Palmer" <dcp_news@nyed.usco­urts.gov> wrote in message
news:ebgg17$hlk$1@c­oronis.nyed.circ2.dc­n...
Procedures:
indexkeyarray_out..­.Cannot Update statistics for procedure:
indexkeyarray_out. SQL=-674, ISAM=0.


A walk home and some distance gave the obvious answer -- get the updated
dostats from IIUG, make and install.

All better now.

Thank you, Art Kagel, for a great utility and for keeping it up.

--


Optionscomment 1 answer | Add comment
Index Levels Roy Mercer 18:39:23
 Query to find index levels.

set isolation to dirty read;
select tabname[1,18], idxname[1,18], levels
from sysindexes, systables
where sysindexes.tabid = systables.tabid
and levels > 2
order by 1 asc,3 desc

OptionsAdd comment
Question for the group.... Madison Pruet 16:17:27
 I'm kinda dumb about shared file usage and would like to have some idea
what folks are using. Appreciate any feedback/comments/e­tc...
Optionscomment 3 answer | Add comment
dostats fails on indexkeyarray_out Douglas Palmer 03:38:17
 We just moved to 9.40.UC8 from 9.40.UC5 and can no longer run dostats on any
database. It always bombs just as it starts to update the stored procedures
with this error:

Procedures:
indexkeyarray_out..­.Cannot Update statistics for procedure:
indexkeyarray_out. SQL=-674, ISAM=0.

I looked online and only found one other person seeing this error from a few
years ago -- no solution. The stored procedure *does* exist and running this
command works fine:

update statistics for procedure indexkeyarray_out;

Thanks for any help.

--



OptionsAdd comment
OS Upgrade broke makefile Guest 02:51:06
 Hi all,
We had an OS upgrade from AIX 5.1 -> AIX 5.3 yesterday and now our 4GL
makefiles are dying. We cannot figure out what to fix though. Any
help would be appreciated!

(One note: make fails during the call to c4gl, but if I run c4gl at
command line, it works fine!)

Platform: IBM servers running AIX 5.3
Informix: Informix v 9.40C2, I4GL v. 7.32.UC2 (c4gl, isql same version)

Here is the error:
-------------------­--------------------­----
$ make
make all1
c4gl my_program.4gl -c -O
exec(): 0509-036 Cannot load program
/local_apps/informi­x/lib/tools/i4glc1 because of the following errors:
0509-150 Dependent module libifsql.so could not be loaded.
0509-022 Cannot load module libifsql.so.
0509-026 System error: A file or directory in the path name
does not exist.
make: 1254-004 The error code from the last command is 255.

Stop.
make: 1254-004 The error code from the last command is 2.

Stop.
-------------------­--------------------­----

Here are the relevevant portions of my environment:
$ set | grep INF
INFORMIXDIR=/local_­apps/informix
INFORMIXSERVER=adm_­dev
INFORMIXSQLHOSTS=/u­sr/remote/etc/sqlhos­ts
LD_LIBRARY_PATH=/lo­cal_apps/informix/li­b:/local_apps/inform­ix/lib/esql:/local_a­pps/informix/lib/too­ls:/usr/lib:/local_a­pps/cobol/coblib
LIBPATH=/local_apps­/informix/lib:/local­_apps/informix/lib/e­sql:/local_apps/info­rmix/lib/tools:/usr/­lib:/local_apps/cobo­l/coblib
PATH=/usr/bin:/etc:­/usr/sbin:/usr/ucb:/­usr/bin/X11:/sbin:/u­sr/java14/jre/bin:/u­sr/java14/bin:/usr/l­ocal/bin:/usr/remote­/bin:/local_apps/inf­ormix/bin:/local_app­s/informix/bin:/loca­l_apps/cobol/bin:/lo­cal_apps/cobol/drive­rs:/home/mhoffman/bi­n:.


I added the LD_LIBRARY_PATH as a first effort, but it had no effect!

All the library files exist (the *if* and *ix* and isql*) in the esql
subdirectory under informix/lib and seem to be hard-linked correctly.

Any idea what else needs to be done???

Thanks,
Michael Hoffman

Optionscomment 1 answer | Add comment
Columns in each table Mehl@Cyvest.Com 02:48:04
 Hello --

I am a newbie to Informix, and will start a contract tomorrow to write
Crystal Reports on an Informix db.

Can anyone suggest SQL code to obtain the following information from an
Informix database?:
Table, Column, DataType, Length, Description (?)

I use the following code in MS SQL Server
SELECT
SUBSTRING(table_nam­e,1,20) AS "Table",
SUBSTRING(column_na­me,1,30) AS "Column",
SUBSTRING(data_type­,1,13) AS "DataType",
ISNULL(character_ma­ximum_length, ' ') AS "Length",
STR(numeric_precisi­on) AS "Precision",
numeric_scale AS "Scale",
CONVERT(nvarchar(15­0), ISNULL(s.value, ' ')) AS Description
FROM
INFORMATION_SCHEMA.­COLUMNS i_s
LEFT OUTER JOIN
sysproperties s
ON
s.id = OBJECT_ID(i_s.TABLE­_SCHEMA+'.'+i_s.TABL­E_NAME)
AND s.smallid = i_s.ORDINAL_POSITIO­N
AND s.name = 'MS_Description'
WHERE
OBJECTPROPERTY(OBJE­CT_ID(i_s.TABLE_SCHE­MA+'.'+i_s.TABLE_NAM­E),
'IsMsShipped')=0 AND
table_schema = 'DBO' AND
table_name NOT LIKE 'sys%' AND
table_name NOT LIKE 'dtprop%'
ORDER BY table_name, ordinal_position

Can you also tell me in what Informix component to enter such SQL code?
In SQL Server, for example, I could enter it in Query Analyzer or
create a query in the Management Console.

Thanks for any help.

Larry Mehl

Optionscomment 3 answer | Add comment
Re: index width Jonathan Leffler 02:38:29
 On 8/9/06, Floyd Wellershaus <fwellers@yahoo.com­> wrote:
I'm reading that B-tree indexes don't perform well on wide columns,
specifically those above 32bytes.


That's funny. Where are you reading that? In IDS 10, we increased
the maximum index key size to about 3 KB on 16 KB pages.
I'm trying to find out the width of all our indexes. I can't come up with a
query to do this, any help ?
I know I have to join systables, syscolumns and sysindexes, and join on
sysindexes.part1 etc to syscolumns.colno and then get the collength.
I can pretty much get there with this, but it doesn't group them properly to
be able to add up the columns for a multi-column index.
select si.idxname,st.tabna­me,sc.colname,sc.col­length
from sysindexes si,systables st,syscolumns sc
where st.tabid>99 and st.tabname not matches '*[0-9]*'
and st.tabid=si.tabid
and si.tabid=sc.tabid
and (si.part1=sc.colno or si.part2=sc.colno or si.part3=sc.colno)
and st.tabname='proc_st­ats'
order by sc.collength desc


Apart from repeating for each of the 16 possible index parts, you need
to dcode the collength field for many types. For example, DECIMAL
columns are encoded with the scale and precision combined with shift
and OR operators. You need to extract the scale and precision from
the recorded values to determine that actual data space used by the
column. DATETIME and INTERVAL are more complex (and, while similar,
also subtly different from each other). And so on.


--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.­net, jleffler@us.ibm.com­
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org­/
Optionscomment 8 answers | Add comment
Short checkpoint durations Neil Truby 02:35:42
 One of customers wants to use SAN replication between remote sites for DR
purposes. As recently discussed, and explained at length and in detail by
Martin Fuerderer, this will have the effect of allowing the DR database to
its state at the last checkpoint.

Actually the customer wants minimal data use, but doesn't want to use HDR
for this. To do this we could set very short checkpoints - say every 60
seconds, or even less.

I wondered what experiences others have with checpoint intervals as low as
this?


Optionscomment 1 answer | Add comment

Add new topic:

How:  Register )
 
Login:   Password:   
Комментировать могут: Премодерация:
Topic:
  
 
Пожалуйста, относитесь к собеседникам уважительно, не используйте нецензурные слова, не злоупотребляйте заглавными буквами, не публикуйте рекламу и объявления о купле/продаже, а также материалы нарушающие сетевой этикет или УК РФ.


QAIX > Informix database developmentGo to page: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | next »

see also:
[JBoss Portal] - Help me ! How to get…
[JBoss jBPM] - about the…
[JBoss jBPM] - when i run jbpm3.1.1…
<