home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / oracle / 1575 < prev    next >
Encoding:
Internet Message Format  |  1992-09-13  |  3.3 KB
  1. Path: sparky!uunet!usc!rpi!batcomputer!munnari.oz.au!metro!usage!sserve!hhcs.gov.au!pihlab
  2. From: pihlab@hhcs.gov.au
  3. Newsgroups: comp.databases.oracle
  4. Subject: Re: Summary: Controlling "ad hoc" queries
  5. Message-ID: <1992Sep14.085503.368@hhcs.gov.au>
  6. Date: 14 Sep 92 08:55:03 +1000
  7. References: <laujakINNp5@news.bbn.com> <1992Sep11.014224.19879@usage.csd.unsw.OZ.AU>
  8. Organization: Aust. Dept. Health, Housing and Community Services
  9. Lines: 58
  10.  
  11. In article <1992Sep11.014224.19879@usage.csd.unsw.OZ.AU>, troy@cbme.unsw.EDU.AU (Troy Rollo) writes:
  12. > A number of solutions are being used. The simplest, for dealing with
  13. > overgrown queries, is both fascist and liberal limits being imposed
  14. > on the tool (We do this by means of a client/server system, and impose
  15. > the limits at the server, thus preventing wasted network traffic).
  16. > The liberal limit informs the user periodically that the current
  17. > query is really not at all simple and asks them if they really
  18. > want you to do it. The fascist limit states in not so many words that
  19. > the administrator thinks you are being unreasonable and you should
  20. > go back and try it again.
  21.  
  22. I assume that you take the user's query and run it through EXPLAIN, then you
  23. examine the results of EXPLAIN to determine how the script will perform, and
  24. then you notify the users of the performance of the query before actually doing
  25. the query.
  26.  
  27. This would be nice but adds a slower startup and you still don't know how many
  28. rows are going to be returned OR processed.
  29.  
  30. > These are both configurable limits based on number of bytes and/or rows.
  31. > Should the limit be enforced, the server informs the database via a
  32. > cancel message, and if the user is really desperate they can still use
  33. > whatever they did get back.
  34.  
  35. The problem with adhoc querries is more the fact that the user processes
  36. thousands of records usually with many repeated full table scans to pull off a
  37. report of 10 or less rows.
  38.  
  39. SQL*ReportWriter already allows you to put a restriction on the size of the
  40. returned report but doesn't factor in the amount of work done by the kernel to
  41. get weed out the required rows and get them into the right order before
  42. actually sending them to the user.
  43.  
  44. > The second issue I think you were asking about is the issue of
  45. > users not knowing the structure of the database and doing something
  46. > which returned meaningless results (by, for example, misspecifying
  47. > the joins). Without trying to get into an advertising blurb, our
  48. > approach is, said briefly, to have the tool do the joins itself,
  49. > thus eliminating the need for the user to do them. There are a
  50. > lot of subtleties in doing that, which I won't go into here.
  51.  
  52. Having the tool actually formulate the script from the requirements as
  53. specified by the user is a safe way of ensuring the indexes are used
  54. correctly.
  55.  
  56. Oracle are doing this (I hope) with their new end-user tools.
  57.  
  58. -- 
  59.  
  60. Bruce...        pihlab@hhcs.gov.au
  61.                  ^^
  62. *******************************************************************
  63. * Bruce Pihlamae  --  Database Administration                     *
  64. * Commonwealth Department of Health, Housing & Community Services *
  65. * Canberra, Australia                             (W) 06-289-7056 *
  66. *******************************************************************
  67. * These are my own thoughts and opinions, few that I have.        *
  68. *******************************************************************
  69.