Kbase 17956: DB startup crashes w/errs (2329) and (612) on Sequent Numa
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
12/1/1999 |
|
DB startup crashes w/errs (2329) and (612) on Sequent Numa
Customers running Progress Version 7.3C04 on a Sequent Numa platform
running the runtime Sequent 4.x Operating System, compatible with
Sequent PTX 4.x, may experience database integrity problems.
DURING CRASH RECOVERY YOU MAY SEE THE FOLLOWING PROGRESS ERRORS:
SYSTEM ERROR: Invalid block <block> for file <file-name>, max is
<max-block> (2329)
SYSTEM ERROR: Possible file truncation, <block-offset> too big for
database. (612)
Currently, the 7.3C04 Sequent release of Progress uses the DirectIO()
system call to write to the disk. What we have found with the Numa
Sequent 4.x runtime release, that the combination of the DirectIO()
to a EFS file system type will cause problems when extending a
Progress variable length file. With the EFS file system, there can
be a latency between actual and physical inode file size
representation and in memory inode file system. A request is
made to extend the .bi or .db variable length file, the database is
then shutdown closing the variable length files. When the database
is restarted, it first checks the master block for the last database
block and realizes that it does not match the actual size. Therefore,
runtime version of the Sequent 4.x system notes that the DirectIO()
has known bugs,caveats and is only recommended for UFS file system
types. This is not to say that Progress v7.3C04 is not compatible
with EFS file systems on the Sequent PTX 4.x Operating System.
Customers have been running successfully using EFS and is fully
supported. It is the difference in how the Sequent Numa Runtime
compatible version of PTX that no longer supports this functionality.
Please note that this problem is unrelelated to the NUMA-Q hardware,
or older Symmetry hardware platform. It is rather a result of a
problem with IBM NUMA-Q ptx/Unix EFS version 1.1.2 software. The fix for the issue is to have the customer request EFS version 1.1.3 or greater from the IBM NUMA-Q Customer Service Center at (800) 854-9969.
Customers' preliminary testing with Progress V8 on the Sequent
Numa runtime Operating System has shown that this issue does not
occur on either the UFS or EFS file system types. In V8, Progress
no longer makes use of the DirectIO() system call and is the reason
for the difference in behavior. PLEASE NOTE that PROGRESS has not
performed any testing on the Sequent Numa 4.x runtime Operating
System and does not make claim to support unique differences in
the behavior of the Operating System. PROGRESS highly recommends
you fully test your application and Disaster Recovery strategies
before deploying any Production Application.
OTHER WORKAROUNDS:
1. Move to Progress Version 8.
2. Move your databases to a UFS file system type.
3. Add fixed extents to your Multi-volume structure ruling out the
chance of ever growing the database or before image notes into
the variable length file.
05/18/98
lmc