home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / informix / 2404 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  2.9 KB
  1. Path: sparky!uunet!gossip.pyramid.com!pyramid!infmx!davek
  2. From: davek@informix.com (David Kosenko)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: Informix logs read-only queries? can't handle 'not-exists'?
  5. Message-ID: <1992Nov12.161943.21876@informix.com>
  6. Date: 12 Nov 92 16:19:43 GMT
  7. References: <1992Nov11.184142.4749@cs.wisc.edu>
  8. Sender: news@informix.com (Usenet News)
  9. Organization: Informix Software, Inc.
  10. Lines: 55
  11.  
  12. Ron Choi writes:
  13. >i'm running Online 5.0 and seemed to have discovered a bug (or bugs).
  14. >i ran the following query overnight:
  15. >
  16. >select count(*)
  17. >from relA
  18. >where (relA.x10A = 0 or relA.x10A = 5) and not exists (
  19. >    select relB.evenAcct
  20. >    from relB
  21. >    where (relB.x100B = 0 or relB.x100B = 49) and
  22. >    relB.evenAcct = relA.acct
  23. >    );
  24. >
  25. >and got hundreds of "Logical Log Files are Full -- Backup is Needed".
  26. >the worst thing is that this corrupted the database.  first of all, the above
  27. >query is read-only, so it should not create log records (unless informix
  28. >is doing something weird and supporting cascade aborts).  secondly, 
  29.  
  30. The reason log entries are being generated is that the sub-query is 
  31. generating a temporary table, and the creation of this temp table is being
  32. logged.  Because you are using a correlated sub-query (the where clause of the
  33. sub-query references a table in the dominant query), the subquery must be
  34. executed for every tuple in the dominant query.  If many rows are being
  35. examined by that dominant query, then many temp table are going to be
  36. generated for processing the sub-query.  These tables do not hang around, but
  37. the log entries will fill up the logs.
  38.  
  39. >the database had logging turned off (with 'tbtape -N databasename'), but 
  40. >it still logs anyway!  and a query sure shoudn't corrupt the database.  
  41.  
  42. The log records are still being written because OnLine logs all DDL 
  43. statements (whether logging is on or not) and the creation of even an
  44. implicit temp table is, at the rsam level, a DDL action.
  45.  
  46. I agree wholeheartedly that a query should not corrupt the database.  What
  47. exactly become corrupted and how?
  48.  
  49. >has anyone seen this before?  i can reproduce it; i ran this twice already 
  50. >with the same result.  and yes, i was the only person accessing the database 
  51. >that night.
  52.  
  53. I cannot say for sure if this is considered a "bug".  There are reasons
  54. why DDL statements are always logged (it is the only way that they can be
  55. "undone" in OnLine, in the event that the statement should fail for some
  56. reason), but it is not entirely clear that implicit temp tables should
  57. have log records written to the log on disk (believe me, there are many 
  58. complicated elements around this, relating to recovery issues).
  59.  
  60.  
  61. Dave
  62. -- 
  63. Disclaimer: These opinions are not those of Informix Software, Inc.
  64. **************************************************************************
  65. "I look back with some satisfaction on what an idiot I was when I was 25,
  66.  but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney
  67.