tag:blogger.com,1999:blog-70960528391167251352024-03-08T13:09:46.765+08:00forkboy's blogThoughts on Oracle, Perl, Java, Unix Systems and life.forkboyhttp://www.blogger.com/profile/01434271298002118455noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-7096052839116725135.post-75759850679373490512008-01-30T08:10:00.000+08:002008-01-30T08:16:37.098+08:00Date::Manip and /dev/null: cannot createI've seen this problem before where Date::Manip couldn't find the Timezone<br /><br /><span style="font-size:85%;"><span style="font-style: italic;">sh: /dev/null: cannot create</span><br /><span style="font-style: italic;">sh: /dev/null: cannot create</span><br /><span style="font-style: italic;">ERROR: Date::Manip unable to determine TimeZone.</span><br /><span style="font-style: italic;"> Date::Manip::Date_TimeZone called at /usr/local/lib/perl5/site_perl/5.8.0/Date/Manip.pm line 629</span><br /><span style="font-style: italic;"> Date::Manip::Date_Init() called at /usr/local/lib/perl5/site_perl/5.8.0/Date/Manip.pm line 747</span><br /><span style="font-style: italic;"> Date::Manip::ParseDateString('today') called at /usr/local/lib/perl5/site_perl/5.8.0/Date/Manip.pm line 1683</span><br /><span style="font-style: italic;"> Date::Manip::UnixDate('today') called at test.cgi line 10<br /></span><br /><span style="font-size:100%;">I have previously solved it by manually settting the Timezone with $Date::Manip::TZ, but for some reason that wasn't working today.</span><span style="font-style: italic;"><span style="font-style: italic;"><br /><br /></span></span><span style="font-size:100%;">After a bit of digging, turned out /dev/null had gone crazy</span><span style="font-style: italic;"><span style="font-style: italic;"><br /><br />> ls -la /devices/pseudo/mm@0:null <br />crwxrwxr-x 1 jboss jboss 13, 2 Jan 30 11:06 /devices/pseudo/mm@0:null<br /><br /><br /></span></span><span style="font-size:100%;">Owned by JBOSS? Thats a bit strange.. Not sure yet how it got like that, but a quick </span><span style="font-style: italic;"><span style="font-style: italic;"><br /><br />chown root:sys </span></span></span><span style="font-size:85%;"><span style="font-style: italic;"><span style="font-style: italic;">/devices/pseudo/mm@0:null<br />chmod o+w </span></span></span><span style="font-size:85%;"><span style="font-style: italic;"><span style="font-style: italic;">/devices/pseudo/mm@0:null<br /></span></span><span style="font-size:100%;"><br />and everything was working correctly again.<br /><br />Lesson of the day.. Don't trust Java, its obviously its fault :)</span><span style="font-style: italic;"><span style="font-style: italic;"><br /><br /></span></span></span>forkboyhttp://www.blogger.com/profile/01434271298002118455noreply@blogger.com1tag:blogger.com,1999:blog-7096052839116725135.post-67317695064397233722007-05-09T10:02:00.000+08:002007-05-10T07:57:32.719+08:00Tracing errorsOne 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.<br /><br />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 <span style="font-weight: bold;">ORA-1401</span> is what we wanted.<br /><br />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.<br /><br /><blockquote>create or replace trigger<br />logon_trig<br />AFTER LOGON ON DATABASE<br />BEGIN<br /><br /> IF USER = 'JAVA_APP' THEN<br /> execute immediate 'alter session set events ''1401 trace name errorstack forever, level 1''';<br /> END IF;<br /><br />END;<br /></blockquote><br />After waiting awhile, the alert_log let me know that the application had thrown the error again.<br /><br /><pre><blockquote>Errors in file /db/admin/DEV/udump/dev_ora_12720.trc:<br />ORA-01401: inserted value too large for column</blockquote></pre><br /><br />Checking the trace file gave me the SQL<br /><br /><pre><blockquote>*** SESSION ID:(81.1552) 2007-05-09 13:01:18.282<br />*** 2007-05-09 13:01:18.282<br />ksedmp: internal or fatal error<br />ORA-01401: inserted value too large for column<br />Current SQL statement for this session:<br />insert into test.xx values (:"SYS_B_0")<br />----- Call Stack Trace -----</blockquote></pre><br /><br />but not the bind variables, which was a bit of problem, since we wanted to know <span style="font-weight: bold;">what</span> was actually too large.<br /><br />Changing the trace level in the login trigger to level 8 added the bind variables into the trace, and quickly gave us our answer.<br /><br /><pre><blockquote>bind 0: dty=1 mxl=32(24) mal=00 scl=00 pre=00 oacflg=10 oacfl2=100 size=32 offset=0<br /> bfp=ffffffff7ca76558 bln=32 avl=24 flg=09<br /> value="this is my bind variable"</blockquote></pre><br /><br />The ability to set traps for any "ORA-" error is something I will certainly be taking advantage of in the future.forkboyhttp://www.blogger.com/profile/01434271298002118455noreply@blogger.com0tag:blogger.com,1999:blog-7096052839116725135.post-48690497223050789642007-01-30T10:04:00.000+08:002007-01-30T10:07:58.354+08:00ApexlibI 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.<br /><br /><a href=http://apexlib.sourceforge.net/>http://apexlib.sourceforge.net/</a>forkboyhttp://www.blogger.com/profile/01434271298002118455noreply@blogger.com0tag:blogger.com,1999:blog-7096052839116725135.post-26941196854529315422006-12-05T11:55:00.000+08:002006-12-05T11:56:16.206+08:00New ToyI picked up a shiny new Macbook Pro last night. Very nice machine, now I just need to get used to the different key bindings!forkboyhttp://www.blogger.com/profile/01434271298002118455noreply@blogger.com0tag:blogger.com,1999:blog-7096052839116725135.post-86162942530009763892006-12-04T08:40:00.000+08:002006-12-04T08:46:29.998+08:00Advent ahoyIt appears the Catalyst advent calendar got this inspiration from the <a href="http://www.perladvent.org/">Perl Advent Calendar</a>. They are reviewing 1 Perl module per day leading up to Christmas. <a href="http://www.perlcast.com/">PerlCast</a> has a new podcast up with Jerrad Pierce discussing the Calendar.forkboyhttp://www.blogger.com/profile/01434271298002118455noreply@blogger.com0tag:blogger.com,1999:blog-7096052839116725135.post-45757608830967564022006-12-01T10:03:00.000+08:002006-12-01T10:10:29.254+08:00Catalyst Advent calanderThis 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 <a href="http://www.catalystframework.org/calendar/">http://www.catalystframework.org/calendar/</a> Unfortuntely I doubt I'll have the time to follow all the tips as they are released.forkboyhttp://www.blogger.com/profile/01434271298002118455noreply@blogger.com0tag:blogger.com,1999:blog-7096052839116725135.post-27620759801321127792006-11-24T12:41:00.000+08:002006-11-24T12:52:44.377+08:00IntroductionI 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.<br /><br />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.forkboyhttp://www.blogger.com/profile/01434271298002118455noreply@blogger.com0