RE: is this a problem?
Posted in 2005
Topics: Installation, Setup & Upgrades, Storage & Space Management, Platform-Specific Issues, Versions, Editions & End-of-Life
Jonathan,
Sorry I didn't include the version and platform. We run IDS 9.40.HC3 on
an HP-UX 11i box, we upgraded from 7.31 on April 2 to 9.4. I run the
following oncheck's commands once a week on the production database
'cars'. We DON'T use ANSI mode.
oncheck -cD -q cars
oncheck -cI -q cars
oncheck -cR -q cars
oncheck -cc -q cars
oncheck -ce -q cars
oncheck -cr -q cars
The only one that has any errors is the oncheck -cc which I have posted
last week on (ERROR: informix.systabauth nextsize 664 !=
tblspace.nxtsize 64). I'm thinking we had these problems prior to
upgrading and 9.4 is just allowing us to see them.
cars:systables has the following:
tabname systabperm
owner informix
partnum 2102371
tabid 12742
rowsize 21
ncols 4
nindexes 2
nrows 4823
created 04/03/2005
version 835256337
tabtype T
locklevel R
npused 67
fextsize 114
nextsize 22
flags 0
site
dbname
type_xid 0
am_id 0
tabname gu_prereg_pay
owner informix
partnum 2102819
tabid 12915
rowsize 122
ncols 9
nindexes 3
nrows 9634
created 04/03/2005
version 850788387
tabtype T
locklevel R
npused 603
fextsize 1440
nextsize 288
flags 0
site
dbname
type_xid 0
am_id 0
If anyone has any ideas, let me know. As we don't have direct support
with IBM, we have to convince our 3rd party software vendor we have a
problem they can't handle to get to IBM support. Sounds like I need to
start that battle and get IBM support on this. This is the third
problem we have, the other is sysprocplan gets locked and stays locked
until the person that locked it get out of the database. All the known
causes of this we don't seem to have. Beginning to sound like at some
point the database systems tables got corrupted.
John
-----Original Message-----
From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org]
On Behalf Of Jonathan Leffler
Sent: Monday, April 25, 2005 11:20 PM
To: informix-list@iiug.org
Subject: Re: is this a problem?
jda wrote:
> I have two tables in sysmaster:systabnames that have two records each.
> I was thinking that there should only be one record per
> tabname/dbsname combo, I'm I thinking wrong? If I'm right how do I
> correct this? If, I'm wrong, what are the reasons for having two
> records?
>
> systabnames records for the two tables.
>
> partnum 2102365
> dbsname cars
> owner informix
> tabname systabperm
> collate en_US.819
>
> partnum 2102371
> dbsname cars
> owner informix
> tabname systabperm
> collate en_US.819
>
> partnum 2102819
> dbsname cars
> owner informix
> tabname gu_prereg_pay
> collate en_US.819
>
> partnum 2102821
> dbsname cars
> owner informix
> tabname gu_prereg_pay
> collate en_US.819
Various questions spring to mind - such as which version of IDS, running
on which platform... What does ON-Check have to say about the state of
the instance and the database?
The general answer to your question is "No, you should normally only
have one table of a given name in your database". There are exceptions;
if your database is MODE ANSI, it is possible to have the same table
name with two different owners. Question: is the owner listed in
systabnames the database owner or the table owner? It really only makes
sense for it to be the table owner - but the question should be asked.
Are you messing with DELIMIDENT at any time? If so, you can achieve
interesting results with trailing blanks.
If ON-Check doesn't identify anything wrong, have you tried connecting
to the database and seeing what is in systables in the cars database?
Depending what you find based on these investigations, there could be
numerous explanations, corresponding to numerous findings. However, you
should probably not simply continue using the database without
determining what is going on.
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.01 -- http://dbi.perl.org/
sending to informix-list
You have a table and index named the same. They both show up. Use some naming conventions for tables and indexes. uidx_tabname_colname for the index.