Re: Bug in 7.2.2 for Digital UNIX possibly others
In article <5kb487$lba@cssun.mathcs.emory.edu>, Colin McGrath
<cmm@trac3000.ueci.com> writes
>We were having 4GL compile time errors (assert fail) with a DEC Alpha
>running:
> O/S: Digital UNIX V4.0A
> OnLine DS: V7.22.FC2
> I4GL RDS: V6.04.UC1
> NETTYPE: onsoctcp (which seems to be getting changed in the onconfig
> file to "soctcp,,,")
>
>The compiles would fail and the system message log file would have errors like:
>16:10:57 Assert Failed: Page Check Error in rsread:bad data page
>16:10:57 Who: Session(74, dbadmin@tracdec27, 10065, 9439224)
> Thread(1778, sqlexec, 2008cd988, 1)
>16:10:57 Results: Possible inconsistencies in 'tracsy:"informix".systables'
>16:10:57 Action: Run 'oncheck -cD 1048992'
>16:10:57 See Also: /tmp/af.6f21b4f>
>Then we got the following email about the O/S alerting us to a possible
>problem; once we implemented the workaround, the compile time errors stopped
>completely.
>
Digital...Oh you mean DEC...I once installed Online 5.0 on a dec Alpha
running OFS/1. The release note mention that a special patch was done
by Dec at Informix's request!!. The notes said phone Dec and ask for
"The Database Patch"....
>} You may have already been notified by Digital about this potential
>} problem in Digital UNIX V4.0 and later versions of the OS. Digital UNIX
>} Engineering is investigating the exact cause of the problem; however,
>} until we fully understand the circumstances surrounding this, you should
>} follow the recommended workaround detailed below.
>}
>} All I know right now, is that under very heavy loads (with OPS and DRD)
>} this data corruption problem can occur. Even if you are not running
>} Oracle Parallel Server, we recommend you implement the workaround
>} because we don't fully know the cause of the problem. Systems running
>} Digital UNIX V3.2x are not affected by this problem.
>}
>} BLITZ TITLE: DIGITAL UNIX DATA CORRUPTION WITH SHARED MEMORY
>}
>}
>} DATE: 16 April 1997
>[snip]
>} During the course of prereleased hardware testing with Digital UNIX
>} Versions 4.0 and later, the Digital UNIX Engineering Group discovered
>} a user application data corruption that was not detected by the
>} operating system software.
>}
>} PROBLEM:
>}
>} A data corruption problem can occur when the parameter new-wire-method
>} is turned on. The new-wire-method parameter is only available in V4.0
>} and later releases. All versions V4.0 and later ship with the default
>} being new-wire-method enabled.
>}
>} RESOLUTION/WORKAROUND:
>}
>} The workaround for this problem is as follows:
>}
>} The problem can be eliminated by turning off the new-wire-method.
>}
>} 1) Become the root user.
>}
>} 2) Create a new file named /tmp/nwm and insert the following lines:
>}
>} vm:
>} new-wire-method=0
>}
>} 3) Execute the sysconfigdb command as follows:
>}
>} # /sbin/sysconfigdb -f /tmp/nwm -m vm
>}
>} 4) Reboot the system.
>}
>} The new-wire-method option is now disabled.
>}
>} Please note that turning off the new-wire-method should cause
>} little or no performance degradation.
>}
>} It is the Strong Recommendation of Digital UNIX Engineering that
>} this workaround be implemented on all systems running Digital UNIX
>} V4.0 and above. Failure to do so can result in undetected data
>} corruption.
>}
>} ADDITIONAL COMMENTS:
>}
>} Digital UNIX Engineering is working at the highest priority on a
>} solution that will not require the above workaround. When the
>} resultant fix is ready, an advisory blitz will announce its
>} availability.
>
--
David Williams