Date::Manip and /dev/null: cannot create

I've seen this problem before where Date::Manip couldn't find the Timezone

sh: /dev/null: cannot create
sh: /dev/null: cannot create
ERROR: Date::Manip unable to determine TimeZone.
Date::Manip::Date_TimeZone called at /usr/local/lib/perl5/site_perl/5.8.0/Date/Manip.pm line 629
Date::Manip::Date_Init() called at /usr/local/lib/perl5/site_perl/5.8.0/Date/Manip.pm line 747
Date::Manip::ParseDateString('today') called at /usr/local/lib/perl5/site_perl/5.8.0/Date/Manip.pm line 1683
Date::Manip::UnixDate('today') called at test.cgi line 10

I have previously solved it by manually settting the Timezone with $Date::Manip::TZ, but for some reason that wasn't working today.

After a bit of digging, turned out /dev/null had gone crazy

> ls -la /devices/pseudo/mm@0:null
crwxrwxr-x 1 jboss jboss 13, 2 Jan 30 11:06 /devices/pseudo/mm@0:null


Owned by JBOSS? Thats a bit strange.. Not sure yet how it got like that, but a quick

chown root:sys /devices/pseudo/mm@0:null
chmod o+w /devices/pseudo/mm@0:null

and everything was working correctly again.

Lesson of the day.. Don't trust Java, its obviously its fault :)

Tracing errors

One of the Java developers at my work was having issues with his application generating a "ORA-01401: inserted value too large for column", but we didn't know where, the stack trace from jdbc wasn't giving us anything useful. Previously this hasn't really been problem for me previously, as with perl if I came across something like this, I'd just drop a few quick print's to STDERR to find the errornous statement, however doing so in our Java applications would have taken a quite awhile to go through build cycles and then wait for the next deployment.

Luckily, the Java application has a dedicated user, so it was quite easy to use a login trigger to turn on tracing. The first thing we tried doing was use DBMS_SESSION.SET_SQL_TRACE(TRUE), which is something I had done before for tuning applications. However the volume of data generated made it difficult to find the errors, if they were even logged. After searching around, I found that traps can be set to trace given events, in this case ORA-1401 is what we wanted.

This is exactly what we were after, now we could limit the logging to just the user causing the problems and trap the actual SQL statement causing the problem.

create or replace trigger
logon_trig
AFTER LOGON ON DATABASE
BEGIN

IF USER = 'JAVA_APP' THEN
execute immediate 'alter session set events ''1401 trace name errorstack forever, level 1''';
END IF;

END;

After waiting awhile, the alert_log let me know that the application had thrown the error again.

Errors in file /db/admin/DEV/udump/dev_ora_12720.trc:
ORA-01401: inserted value too large for column

Checking the trace file gave me the SQL

*** SESSION ID:(81.1552) 2007-05-09 13:01:18.282
*** 2007-05-09 13:01:18.282
ksedmp: internal or fatal error
ORA-01401: inserted value too large for column
Current SQL statement for this session:
insert into test.xx values (:"SYS_B_0")
----- Call Stack Trace -----

but not the bind variables, which was a bit of problem, since we wanted to know what was actually too large.

Changing the trace level in the login trigger to level 8 added the bind variables into the trace, and quickly gave us our answer.

bind 0: dty=1 mxl=32(24) mal=00 scl=00 pre=00 oacflg=10 oacfl2=100 size=32 offset=0
 bfp=ffffffff7ca76558 bln=32 avl=24 flg=09
 value="this is my bind variable"

The ability to set traps for any "ORA-" error is something I will certainly be taking advantage of in the future.

Apexlib

I came across this APEX framework today, looks very interesting and does alot of things that APEX really should do "out of the box", will be interesting to see how much of this stuff ends up in APEX in the coming releases.

http://apexlib.sourceforge.net/

New Toy

I picked up a shiny new Macbook Pro last night. Very nice machine, now I just need to get used to the different key bindings!

Advent ahoy

It appears the Catalyst advent calendar got this inspiration from the Perl Advent Calendar. They are reviewing 1 Perl module per day leading up to Christmas. PerlCast has a new podcast up with Jerrad Pierce discussing the Calendar.

Catalyst Advent calander

This is a pretty neat idea, the guys of Catalyst are releasing a Advent calender to lead up to xmas, each day they will be releasing a new Catalyst tip, very interesting way to to promote your the framework. Check it out at http://www.catalystframework.org/calendar/ Unfortuntely I doubt I'll have the time to follow all the tips as they are released.

Introduction

I thought I might try this fancy new blogging thing all the kids are talking about, so for a first post I'll do something highly original and introduce myself.

I currently work for an ISP maintaining a legacy Perl billing system and Oracle database. The company is moving to Java for the billing system, which doesn't interest me in the slightest, so my efforts are going into repositioning myself as a DBA. I hope to be able to bring some interesting stories as I learn more about Oracle and database administration in general. Hopefully I will be able to bring some Perl and systems insights as well.