I'm looking for assistance with Online version 5.0.5. I need to know
if there is a way to detect problems at the system level of an Online
5 instance besides using tbcheck.

Informix version: Online version 5.0.5 UC1
OS: SCO Unix System 5 Ver. 3.2

The whole story:
One of my clients provides software and servers to a number of their
clients. Their application is running on Online 5.05.UC1 on SCO
boxes. Upgrading is not an option; they are locked into this version
due to regulatory constraints. The application database never exceeds
about 500 MB; they provide a process to remove old records as the
database grows so that their clients never have to be concerned with
adding disk space or other administration tasks.

The problem is this: They've run into an issue with several of their
biggest clients where informix tbtape archives stop working properly.
Rather than taking an hour as expected, the archive takes just 5-10
minutes, then when my client tries to restore their archive to his
server, the restore completes in just 5-10 minutes but doesn't really
restore anything and the database is "broken" (tbchecks against the
resulting database report errors). Tbtape reports no errors; the
normal archive started and completed messages appear in the online
log. No errors appear in the online log of the restored instance,
either.

I've had him run tbcheck -cr, -cc, and -ce on the originating
instance, and all come back with no errors. There are no tbcheck data
or index errors in the databases of the originating instances and the
application works without error. The only symptom (and problem) is
that an archive won't work.

Because the problem is apparently at the system level of the instance,
a workaround is to dbexport the data, reinitialize the instance, then
reload the data. This does correct the problem. However, it would be
preferable to have a way of recognizing that the problem exists
without having to rely on spotting a bad archive. In some cases,
tbstat -d and tbcheck -pe return negative page counts, which makes it
obvious. But in most cases there is nothing at all to indicate that
something is wrong.

So, back to my original question: Is there a way to detect that there
is something wrong at the instance level besides using tbcheck? Since
this is version 5, there is no sysmaster database to query.

Thank you in advance for any assistance you can give me,

Barrie Shaw
Xtivia, Inc.

On Jun 25, 4:27 pm, barries <barries... (AT) hotmail (DOT) com> wrote:
Tbtape in OL5.xx DID NOT WORK PROPERLY in any release prior to 5.07!
It would miss backing up pages when the server was busy. In addition,
IB you're running into something else that was also fixed at about the
same time. The page timestamps have wrapped past 2^31 and gone
negative. These older versions of tbtape did not properly handle the
condition and got confused.

Regulatory problems or not, your client is going to have to find a way
to start upgrading his clients to OL5.20+, there are MANY reasons to
do that.

Highlights:

- tbtape broken prior to 5.07, restores are unreliable unless then
engine is not being updated while the archive is being made!
- istar/inet (ie TCP connections) considerably slower in 5.05 and
earlier than in 5.07 and later (in 5.06 it was just broken altogether
- oops!)
- Y2K compliance added in 5.10 and later (though obviously that's not
an issue here)
- Very old pages not handled properly.

Art S. Kagel

Art S. Kagel wrote:
IIRC it was actually a bug in the SCO icc 'enhanced C compiler'

Advice from tech support at the time

'Take your DB offline every night and dd the chunks to tape by hand
until we can ship you a fix'

Our db was much too big to dbexport/import as disk was expensive then.

Took about 4 days as I recall...

--
Clive

On Jun 26, 11:34 am, Clive Eisen <c... (AT) serendipita (DOT) com> wrote:
You and I must have hit it at about the same time then. We'd been
doing test restores to the same test machine using the same disks over
and over so it always tbchecked out fine because any pages missing
from a particular archive were restored from the original test archive
or one of the previous restore tests. Sigh. One day tried to restore
to a different machine and there were holes in the data. literally
pages missing in the middle of an extent. Reported it and they said,
OH, yeah, that's a bug and we'll have a patch for your 5.07 release in
a few days. It's scheduled to be fixed in 5.08. Right 5.08, not
5.07! Darn I'm getting old.

Art S. Kagel

Hi,

I think under the circumstances the best option is to get
help from IBM Informix Tech Support. Since this is an
old version (10+ years) you will have to negotiate something
on a time+materials basis. Then they will be able to analyze
the problem and possibly advise how to fix it (permanently).

Hmm. I would like to see the "regulatory constraints" that force
e.g. a viable logistics business to still use trucks that are
10 years and older, preventing them from modernizing their
fleet of vehicles. Everybody sees that such regulation would
be quite stupid ... but with software? ;-)

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

IBM Deutschland GmbH
Chairman of the Supervisory Board: Hans Ulrich Märki
Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
Diemer
Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,
HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940

informix-list-bounces (AT) iiug (DOT) org wrote on 25.06.2007 22:27:50:

For the record, I am painfully aware of the bug in tbtape. I
encountered it as well about 10 years ago. After 3 straight days (and
nights) of unsuccessfully trying to restore my production database
using multiple level 0 archives and logical log tapes, it still had
holes in it. At about midnight on the third day, I was on the phone
with Tech Support (again), with all options exhausted.

"So", I asked, "you mean to tell me that there's nothing more I can do
and the integrity of my database is in question??"

"Yes", he replied, "and I'd hate to be in your shoes..".

Interestingly, because of all of my hard work in trying to restore the
data, I ended up with a bonus, a company cell phone, and some long-
needed assistance. If the restore had worked, no one would have
noticed and life would have gone as usual. Go figure..

Barrie

Interestingly enough, you got tech support to help you with Online 5.0?

Dude, Phil White introduced that product.

__________________________________________________ _______________
Get a preview of Live Earth, the hottest event this summer - only on MSN
http://liveearth.msn.com?source=msntaglineliveearthhm

Art S. Kagel wrote:
You and me both Art.

Almost exactly the same - test restore every night to alternate machine
- never noticed anything wrong until the alternate machine lost a disk
and I could no longer restore after replacing the disk.

--
Clive