This is how I would approach the problem.
- Do as was suggested and load the data without the index and find the
dups in the 8i version.
- If no dups are found in 8i, then the index build is running amok. Check
your logs for some sign of trouble.
- If dups are found in the 8i instance then look at your 9i database and
find the same rows. If the rows are there and not reporting the duplicates,
it's a database configuration difference (like the NLS conversation) or a
bug.
- If the duplicate rows are not in the 9i database then inspect your load
log and see why the rows weren't loaded.
On 7/4/07, Michael McMullen <ganstadba_at_hotmail.com> wrote:
>
> Hopefully this question won't devolve into a treatise on proper
> "troubleshooting". Troubleshooting is something I pride myself on. I knew
> I
> was taking a chance in posting a bare bones email and I paid the price. Oh
> well.
>
> But think of this. All rather puzzling.
> The export taken from an 8i database fails on import into the same (newly
> rebuilt 8i database) with primary key violation. This same export imports
> successfully into a 9i database on a different server. Same number of rows
> imported into the tables. There is no funny nls stuff. Primary key is two
> varchar columns, consisting of ipaddress and radius server name. So the
> dup
> on the 8i database doesn't show up on the 9i database.
> These are the types of oracle problems I find fascinating but since both
> the
> 8i server and database are desupported I'm really trying to push the
> client
> into upgrading and I am not going to spend alot of time troubleshooting
> it.
> Like I said, I was looking for a quick hit after spending days on
> recovery.
> Anyone guess what kind of mood I'm in?
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
--
Rumpi Gravenstein
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jul 04 2007 - 19:59:13 CDT
