Re: unique constraint violation on 8i import but not on 9i
- From: "Rumpi Gravenstein" <rgravens@xxxxxxxxx>
- To: ganstadba@xxxxxxxxxxx
- Date: Wed, 4 Jul 2007 20:59:13 -0400
This is how I would approach the problem.
1) Do as was suggested and load the data without the index and find the
dups in the 8i version.
2) If no dups are found in 8i, then the index build is running amok. Check
your logs for some sign of trouble.
3) 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.
4) 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@xxxxxxxxxxx> 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?
--
//www.freelists.org/webpage/oracle-l
--
Rumpi Gravenstein
Other related posts:
