A week ago one of our air conditioning systems blew up and took the others out with it. Temperatures quickly rose and before long nagios spotted a machine had gone down. Nothing really bad had happened at this point but when we could not get the air conditioning back online we had to temporarily turn off some non essential systems to keep the heat down. Could we have spotted this earlier?
I originally bought a OCZ Vertex2 60Gb SSD for my new machine (over a year a go, possibly more). It usually runs at around 40-45Gb used in Windows depending on what I've got in my documents folder. I felt things were slowing down and after downloading smartmontools and gsmartcontrol I realised my SSD firmware was way out of date (v1.11) and 1.37 was available.
Mostly due to the thread in dbi-dev at DBD::ODBC fetch is returning string for integer (unfortunately some of it was off list) and further comments and rt at Changes in binding columns in DBD::ODBC and DiscardString with SQL_INTEGER not working properly I have made significant changes to the binding of columns in a result-set for DBD::ODBC.
I've never used the USB slot in my Foxsat HDR PVR but just recently I wanted to view some video (wmv files) created by Picassa on my television. The video was too big to put on the only handy USB stick I had but I had a 150Gb maxtor USB drive so I copied it on to that and plugged it in to the foxsat. Although the foxsat recognised a USB device was inserted it could not read it stating it needed to be ext3, FAT16 or FAT32.
Personally I find it rare for modules to fail tests but I'd still rather know something is possibly wrong than have it ignored (it is easier to deal with it at that point).
I devoted some time to try and reduce the massive DBD::Oracle rt list today. Some issues should be fixed now (see below) but in the mean time we have a number of stalled issues and some issues more than 1 year old and some more than 3 years old!
DBD::ODBC 1.36_2 is now on CPAN. I'm afraid this makes some incompatible changes with the last full release and for that I appologise. It seems I was just too ambitious defaulting the internal execute_for_fetch to on. I suspected some ODBC drivers would have bugs which prevented them from working but there are just too many actively used drivers for me to test them all and I hoped this would encourage fixes to them.
Yanick has just released a new development release of DBD::Oracle DBD-Oracle-1.43_00. As I mentioned in my blog a week or so ago, this release has a huge number of lines of code changed to remove the use of DBIS (see Changes to make DBIS more efficient and speeding up XS_DBI_dispatch()). This release removes the last few DBIS calls. As a result, if you are using a Perl built for threads (useithreads=define) this release is significantly faster than previous releases.
I've seen CPU usage nearly halved on fetches of large numbers of rows and I've had reports where people are doing lots of different selects for small numbers of rows of up to 10* quicker.
If you depend on DBD::Oracle you are strongly advised to try this version as this was over a 160K diff when I checked it in. If you notice anything broken please post an example to the dbi-users list.
A list of changes in this release is:
I have released DBD::ODBC 1.36-1 to cpan. With hindsight I was probably too ambitious releasing 1-35 with the default for execute_for_fetch enabled. This decision was based on a) my experience with writing bound arrays of parameters in the ODBC-ODBC Bridge b) I knew some drivers would have issues but I thought this might encourage fixes c) it is so much faster. As it turns out I am seeing issues currently with SQLite, Freetds, MS Access and even MS SQL Server.
Thanks to Dave Mitchell for finding this, see Changes to make DBIS more efficient and speeding up XS_DBI_dispatch(). If you are using a Perl built with thread support (useithreads=define) a number of DBDs use DBIS macros from DBI which are expensive in a threaded Perl and no longer neccessary. The threads referenced above have all the gory details.
This week I've attempted to remove all DBIS usage from DBD::Oracle and have managed in all but a couple of cases. If you upgrade to DBI 1.618 and get the latest DBD::Oracle from subversion trunk (see How to create a patch using Subversion you could see a pretty substantial speed up.