Last week I saw a very scary problem on a system I am doing some Unix
admin work on.

This is an alpha Tru64 5.1 1885 standalone (no cluster) machine, which
was running Oracle 8.1.7.0.0 with a large (mostly empty) database
totalling about 40Gb of space, with about 1Gb of actual data at
present.

The system was updated to Oracle 8.1.7.4.0, and due to previous
database corruptions it was decided to export the entire database to a
text file before the upgrade. Delete everything, perform the upgrade
then re-create empty tables from scratch, create static data files for
the larger tables and import the database.

All went well until it was time to create the 23Gb data file for the
largest table, at which point the console hung, not even the cursor
would flash, all disks were quiet, and the only thing you could do to
this system was ping it !

After a manual reset, the system booted normally, /var/adm/messages
had no entries before the reboot to indicate anything about the
problem (obvious really given the complete and total hang), no crash
file was generated (I didn't know to type crash at >>> prompt then,
and we cannot now use this system to repeat the test as it is back in
partial use).

This system was configured last year, and a 23Gb data file was created
then in exactly the same way without this problem, no Tru64 upgrades
have been done since this time, so the only difference I am aware of
is the Oracle version.

This problem was repeatable, we tried to create a 2Gb data file, this
hung the system, finally we tried a 1Gb data file which was
successful, so the workaround was to create 23 individual 1Gb data
files, the import was then performed and worked OK, the system is now
back up and running apparently without problems.

This problem has been raised with Oracle, who are dragging their
heels, but my real question is has anyone seen anything remotely like
this with Tru64 (ie console hang, entire system stopped and manual
reset required), as whilst I have seen kernel panics, reboots and
various other exciting things on other unix systems, I have never
witnessed a dead stop like this !! I am concerned we may have a Tru64
problem which we can patch for, and similar hangs could happen in
future unless action is taken.

Thanks for any advice/suggestions.

James.

System info is:

# uname -a
OSF1 hostname V5.1 1885 alpha

I don't know how to check patch levels, is their a Tru64 equivalent of
pkginfo ?

Use the dupatch command to track patch installed.

S.



On Thu, 03 Jul 2003 13:43:47 +0200, James Blackmore wrote:

Cannot find du_patch or dupatch on this system.

# /usr/sbin/sizer -v
Compaq Tru64 UNIX V5.1A (Rev. 1885); Wed Jan 9 13:46:01 GMT 2002


Filesystem is Advfs on a rack of compaq disks, I assume this is some
kind of raid unit, as all disk activity lights typically flash for any
file access, and this is supposed to be a high availability system.

This hang was reproducable on this Oracle data file creation, (file is
actually created a few seconds before hang, and creating large empty
files obviously causes no similar problem), so I am pressed to
understand how this can be a hardware issue.

I really need to find and fix the cause before it happens again.

James.

On 3 Jul 2003, James Blackmore wrote:

We had exactly the same problem with a new XP1000 - system would run fine
for 2-4 weeks and then suddenly hang. The reset button didn't work and no
crash dumps were created. I tried running syscheck fron a script more or
less continuously in the hope that error information would be captured but
no problem was ever found. As the machine was new, it was reported to
Compaq and various log files sent to them for analysis but no problem was
ever found. By then Compaq had become HP and then finally HP conceded taht
the CPU or the CPU daughterboard was faulty, sent out an engineer to
replace it and it's been fine ever since.

Andy