-
We have Compaq ES40 machine with Digital Unix 4.0f
and recently we have migrated our Oracle database
from version 8.0.4 to 8.1.5. To upgrade we start
the instance with cold backup of 8.0.4 and upgrade
it to 8.1.5 through a script u0800040.sql. First time
while this script was running at the end we get the
message -
alter table system.repcat$_generated
add constraint repcat$_repgen_primary
ora-01041 internal error. hostdef
extension doesn't exist
We got this message for lot of system tables. But our
database start working fine and application tested
properly but when we try to drop an object of type 'TYPE'
then we got error message and WE ARE NOT ABLE TO DROP
A USER WHICH HAVE OBJECT AS TYPE 'TYPE'
eg. drop user scott cascade
we got the error
ora-00600 internal error code ,
arguments:[6002],[32],[6],[2],[0],[],[],[]
now we thought that there is some problem with our
oracle installation. So we reinstalled the oracle software , copied the 8.0.4 cold backup, ran the script
U0800040.sql (this time there was no ora 01041 error mentioned above) .the script ran successfully.
now when we try to drop any user which contain the object
type 'TYPE' we get the same error ora 600.
all remaining objects were dropped except object type 'TYPE'
this is the problem
this is very urgent
thanks
-
- Take a full cold backup / Clean
- Recover your database from server manager using :
Alter database recover;
-
Before doing such a large amount of work, do some research
into the cause of the problem....
I had a similar problem....
This looks like a bug with the o/s.
Call Oracle support and Digitial Support for confirmation...
The following is a blitz message from Digital regarding 3 identified
Operating System corruption issues with Digital UNIX.
The letter was sent out to Compaq/Digital Customers and references Digital
UNIX versions up to and including 4.0C. Customers running later versions
are advised to check with Compaq whether the problems described in this
note are still applicable, however Oracle would suggest customers run with the
latest Patch Kit installed regardless of Operating System version.
Questions regarding this note should be directed at Compaq support and not
to Oracle.
--
Dear DIGITAL Customer,
The DIGITAL UNIX(R) Engineering organization has recently developed solutions
for three problems that have the potential to affect systems running DIGITAL
UNIX Version 3.2C, 3.2DE-1, 3.2DE-2, 3.2F, 3.2G, 4.0, 4.0A, 4.0B, and 4.0C.
Detailed descriptions of these problems, and instructions on how to obtain
the available fixes or apply the workarounds, are included in this letter.
DIGITAL apologizes for any inconvenience these problems may have caused you.
Sincerely,
Digital Equipment Corporation
UNIX is a registered trademark in the United States and other countries,
licensed exclusively through X/Open Company, Ltd.
Copyright (c) Digital Equipment Corporation, 1997. All Rights Reserved.
Unpublished Rights Reserved Under The Copyright Laws Of The United States.
The "new-wire-method" Problem
Problem Description
The DIGITAL UNIX Engineering organization has recently discovered and
developed a workaround for a problem that has the potential to affect all
DIGITAL UNIX Version 4.0, 4.0A, 4.0B, and 4.0C systems.
A data corruption problem can occur when the parameter new-wire-method is
turned on. (The new-wire-method is an optimization in the kernel to reduce
wiring time.) Versions 4.0, 4.0A, 4.0B, and 4.0C ship with the default being
new-wire-method enabled.
Workaround
You can eliminate the problem by turning off the new-wire-method. Use the
following steps:
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 is now disabled.
DIGITAL UNIX Engineering strongly recommends that this workaround be
implemented on all systems running DIGITAL UNIX Versions 4.0, 4.0A, 4.0B, and
4.0C. Failure to do so could result in undetected data corruption.
Solution
DIGITAL UNIX Engineering is working at the highest priority on a solution
that will allow the use of new-wire-method. When a solution is available,
it will be incorporated in a patch kit to be made available through Digital
Equipment Corporation's normal support channels.
The "KZPSA Data Corruption in Sparse Files" Problem
Problem Description
Intermittent disk data corruption can occur under conditions of heavy I/O on
a SCSI device attached to a KZPSA SCSI Adapter.
Solution
The official fix for this problem will be incorporated in the next patch kit
release for the following versions: Version 3.2C, 3.2DE-1, 3.2DE-2, 3.2F,
3.2G, 4.0, 4.0A, and 4.0B.
The following official and pre-release patches are available for DIGITAL
UNIX:
Official Patch Kit Pre-Release Patch Kit
------------------------------------------------------
V3.2C: DUV32C Patch Kit-00002 official available
V3.2D-1 / E-1: DUV32DE1 Patch Kit-00001 official available
V3.2F: DUV32F Patch Kit-00002 DUV32FSS0000200028300-19970623.tar
V3.2G: DUV32G Patch Kit-00002 DUV32GSS0000200019100-19970623.tar
V4.0: DUV40 Patch Kit-00003 DUV40SS0000300024800-19970619.tar
V4.0A: DUV40A Patch Kit-00003 DUV40ASS0000300020700-19970619.tar
V4.0B: DUV40B Patch Kit-00004 official available
The patch kits may be obtained from your local Customer Support Center or
from the following publicly accessible web page:
http://www.service.digital.com/html/patch_public.html
DIGITAL UNIX Engineering strongly recommends that this patch be applied on
all systems containing a KZPSA and running DIGITAL UNIX Versions 3.2C,
3.2DE-1, 3.2DE-2, 3.2F, 3.2G, 4.0, 4.0A, and 4.0B. Failure to do so could
result in undetected data corruption.
The "AdvFS Data Corruption in Sparse Files" Problem
Problem Description
An AdvFS data corruption problem can occur if a write of less than 8k in size
is done and the offset of the write is beyond the current end of the file.
When this happens the file becomes "sparse," and if a later write
overlaps some or all of the first write, the overlapped portion will not be
accessible. AdvFS does not panic as a result of this problem, and the AdvFS
verify utility does not detect the problem. The data corruption can be
detected only by inspecting the user data.
Solution
The solution consists of fixes to AdvFS and to the verify utility to detect
the problem and to help in the recovery of the corrupted data.
The official fixes for this problem will be incorporated in the next patch kit
release for the following versions: Version 4.0, 4.0A, and 4.0B.
The following official and pre-release patches are available for DIGITAL
UNIX:
Official Patch Kit Pre-Release Patch Kit
------------------------------------------------------
V4.0: DUV40 Patch Kit-00003 DUV40SS0000300025000-19970619.tar
V4.0A: DUV40A Patch Kit-00003 DUV40ASS0000300021000-19970619.tar
V4.0B: DUV40B Patch Kit-00004 official available
V4.0C: DUV40C Patch Kit-00002 DUV40CSS0000200012000-19970619.tar
The patch kits may be obtained from your local Customer Support Center or
from the following publicly accessible web page:
http://www.service.digital.com/html/patch_public.html
DIGITAL UNIX Engineering strongly recommends that this patch be applied on
all systems using AdvFS and running DIGITAL UNIX Versions 4.0, 4.0A, and
4.0B. Failure to do so could result in undetected data corruption.
