Re: 8/8i weird problems

RE: 8.0.5.1.1 on NT4 SP5 -

ORA-600 errors are sometimes caused by block corruption. You can use the dbverify utility ("dbv80" or something) on theSYSTEM datafile to check for block corruption. This is where the definition for views and procedures are stored.

600s have the following structure:

    ORA-600: Internal Error [534] []

The "534" part is called argument 1. If you search on Oracle's Meatlink site for "ora 600 534", you may find a match that explains the ORA-600. If not, Oracle Support is the only way to resolve it.

In addition, there is an 8.0.5.2.2 patch out for NT. There may actually be a bug fix for this problem. You can read the release notes to find out if any bug fixes match it.

Steve Haynes wrote in message ...
>Hi All,
>
>Anyone seen any of these before?:
>
>RE: 8.0.5.1.1 on NT4 service pack 5:
>
>Problem 1:> Dropping an index makes views/procedures invalid.
>
>Problem 2> Selecting from one of those views causes ORA-600
>on the automatic recompilation. Manual recompilation (alter)
>also does this. Recreate from (the same source) script OK.
>This keeps happening, during overnight loads we drop/rebuild indexes,
>then views go invalid, other programs try to access those views
>and go pop on ORA-600.
>
>RE: 8.1.5.0.0 on sunOs 5.6
>Problem 1: Direct load a big (1.9GB) file into a partitioned
>table says it put x million rows in and actually did nothing.
>The row number stated as read also differs from the number
>stated as loaded into the partition. (It all goes into one
>partition as proved with conventional path load of the same
>file). Direct path = No errors, No bad file, Nothing loaded.
>It works ok on smaller files, not sure yet at what size it
>starts failing. Same load file is fine with conventional path.
>There are no indexes on the table (whilst testing this), and
>no other errors appear in alert/trace etc.
>This only started to happen after 3 partitions were loaded
>(also approx 1.9GB each) ok, trying to load any others gets
>this problem.
>Note: Setting ROWS=50000 helped, it did load most but threw
>a few away at the end. It throws a different number away
>(slightly) when ROWS=100000. The number reported as loaded
>is not correct in any case. They don't go into a different
>partition, again as proved with conventional load.
>
>I really need this....
>
>Steve
Received on Sat Jan 15 2000 - 09:32:49 CST