Failure of ordered select statements in Informix 4.10
Posted in 1998
Topics: Installation, Setup & Upgrades, SQL Development & Query Writing, Error Codes & Troubleshooting, Connectivity: ESQL/C, 4GL & Embedded SQL
Can anyone help me sort out this mystery? We have a pretty large database containing all of our student data. It comprises Informix-4GL, Informix-SQL and Informix-SE, version 4.10, running under Ultrix version 4.2. Last Monday, for no obvious reason, it started to have problems on select statements which contain an "order by" statement. This seems to be limited to statements which it expects to return a large number of rows (2 billion, according to "set explain" - is it reasonable for it to expect that many?). Smaller ordered selects are okay. Within 4GL programs, this sometimes seems to manifest itself in the form of problems with array limits, even though there aren't anywhere near enough records going into the array for that to happen. Even worse, it seems that some programs select a different number of rows each time they are run (sometimes every student on the system), without reporting any errors. When running a select via the isql interface, a large one (eg, of the 2 billion expected rows variety) will run nice and quickly without the "order by", but stick the sort on and it seems to hang. The cursor drops to the line with the select keyword, and stays there. No messages about "Running...". And, it doesn't even start to build the temporary table - all it does is the first step of copying the full SQL program to the temp directory. I have left a couple running overnight, but no joy. To add to my woes, when the system is in this state, the SQL menu system stops working and no one else can access the database. We have a test version of the database on a different partition of the disk, and we get the same problem there, so I assume that it's not a table problem. Interestingly, "set explain" also expects 2 billion rows when looking at test data, even though there are a significantly lower number of records. So far, I have attempted the following corrective action (in escalating order of panic): - run "update statistics" - rebuilt the indexes - checked virtual memory and swapping (no problems that I can see) - copied the engine directories to another disk partition and run it from there - reinstalled SQLEXEC from backup Has anyone ever had this problem, or does anybody have any suggestions as to what my next course of action should be? All ideas gratefully received. Paul McManus (P.McManus@richmond.ac.uk) Richmond, the American International University in London)