RE: How do I get column name that causing ORA-01438

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <panandrao@xxxxxxxxx>, <mgogala@xxxxxxxxxxx>
  • Date: Thu, 22 Feb 2007 06:19:01 -0500

clone the table (empty).

add default values (if missing) for all the not-NULLABLE columns.

grab the values clause in your favorite parser (perl, awk, sed, sqlplus, I
don't care),

generate individual inserts with the values at the correct point in the
comma list, one column per insert.

 

Automate the above in a wrapper if you lack a bullwhip and a certain idea
who the vacuous developer was who is allowing bad data to get that close to
your database, because you'll be using it again unless you take dramatic
corrective action (with extreme prejudice, I believe we used to say.)

 

No, really, violence is not the answer.

 

Now that said, this exact request to give column by column traceback with
the list of constraint violations has been around since at least 1992. (Oh,
and don't give up on the first bad column, thank you very much, or at least
let me tell you to continue parsing the values against column acceptability
for the whole row if I'm not in a hurry.) The request did *NOT* make the
priority cut for the VLDB because, after all, it was something you could
clean up yourself with a little semantic and value screening and things like
TRUNCATE, partitioning, IOTs, and 59 other things were more important.

 

Still, I think the request is a valid ease of use thingy, but I'd slot it
way after formulaic index preflation (still not done as they seem to think
the 90-10 split thing is good enough).

 

You can also probably pre-scrub data with the error logging stuff. Reference
T Kyte's paper on that one. I don't think it is possible to give a better
explanation than his correctly enthusiastic and thoroughly enjoyable talk on
the subject.

 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Anand Rao
Sent: Thursday, February 22, 2007 1:37 AM
To: mgogala@xxxxxxxxxxx
Cc: oracle-l
Subject: Re: How do I get column name that causing ORA-01438

 

hmmm ..its rather difficult even with the event setting. the trace file
doesn't explicitly show me the column name.

SQL> create table emp (col1 number(3)); 

Table created.

SQL> ALTER SESSION SET EVENTS='1438 TRACE NAME ERRORSTACK FOREVER, LEVEL
12';

Session altered.

SQL> insert into emp values (1111) ; 
insert into emp values (1111)
                        *
ERROR at line 1:
ORA-01438: value larger than specified precision allows for this column


SQL> ALTER SESSION SET EVENTS='1438 TRACE NAME ERRORSTACK OFF';

Session altered.

of course, for varchar2 columns, the error reported isn't ORA-1438 but
ORA-01401.

now, if you look at the trace file, you really need to search for the
keyword "COL1" (the column name i used) to be actually able to find
something. there is no clear message that shows that this column violated
the rule. 

<snip>

ksedmp: internal or fatal error
ORA-01438: value larger than specified precision allows for this column 
Current SQL statement for this session:
insert into emp values (1111)
----- Call Stack Trace -----

<snip>

In case an insert or update has more than 5,6 columns, it is a cumbersome
task to search for each column_name i suppose. 

guess the easiest is SQLPlus, where the ' * ' character points to the
column/value which violates the rule.

i know this event is the probably as far as we can go...or is there
something else? 

anand

On 22/02/07, Mladen Gogala < <mailto:mgogala@xxxxxxxxxxx>
mgogala@xxxxxxxxxxx> wrote:

Syed Jaffar Hussain wrote:
> Mladen,
> 
> Yes, I do set the event to trace the culprit. The problem is that when
> I enable this event, Oracle is taking around 6 second to return the
> error msg. on the sql prompt. And ours is a very high OLTP application 
> where around 500 tps take places.
> We have request Oracle for an enhancement. Because, when constraints
> violates, Oracle do gives the constrain name and details, likewise, I
> would like to have so and so column in the particular table is the 
> culprit.
>

Syed, it's you who should discover the problem and fix the SQL. It's
done once, in a sqlplus session
and then turned off. It's not intended for all users.

--
Mladen Gogala 
Sr. Oracle DBA
Video Monitoring Systems
1500 Broadway
New York City, NY 10036
Phone: (212) 329-5201
Email: mgogala@xxxxxxxxxxx




 

Other related posts: