home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / oracle / 1557 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  4.6 KB
  1. Path: sparky!uunet!munnari.oz.au!manuel!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: <1992Sep11.104127.364@hhcs.gov.au>
  6. Date: 11 Sep 92 10:41:27 +1000
  7. References: <lapscgINN8jg@news.bbn.com> <laujakINNp5@news.bbn.com>
  8. Organization: Aust. Dept. Health, Housing and Community Services
  9. Lines: 89
  10.  
  11. In article <laujakINNp5@news.bbn.com>, NBROOKS@BBN.COM (Nat Brooks) writes:
  12. > In article <lapscgINN8jg@news.bbn.com> Nat Brooks, NBROOKS@BBN.COM writes:
  13. >>Has anyone out there successfully installed and supported an end user
  14. >>query tool that was actually used by end users?
  15.  
  16. We have been using Easy*SQL, SQL*Plus, and FOCUS as end user tools for adhoc
  17. reporting.  We tried SQL*QMX but the users never liked it so its just
  18. stagnating.  Some users found Easy*SQL too simplistic and now have access to
  19. SQL*Plus.  The Dept. went through a review process some time ago and FOCUS was
  20. selected as THE end user reporting tool but the end users haven't picked it up
  21. fully yet.  I've seen demos of Oracle's new end user type tools (SQL*Browser
  22. etc) and they look nice but we haven't moved on them yet.
  23.  
  24. >> How did you prevent "monster" queries?
  25.  
  26. With Oracle6, you can't.  The best we could do was isolate them to their own
  27. disk drive(s) away from transaction based production applications (same machine
  28. though).
  29.  
  30. Oracle7 is supposed to allow you to set CPU and I/O limits per session/user so
  31. this should help enormously.  Oracle7 also has the cost based optimiser which
  32. should help the performance of end user querries.
  33.  
  34. >> How did you handle users formulating queries that returned misleading
  35. >> results?
  36.  
  37. We provide crystal balls so users can see into the future and determine if the
  38. results look ok.
  39.  
  40. Actually, there is no way of guaranteeing query correctness.  The users are
  41. warned about this and are effectively on their own.  If they want confirmation
  42. that a particular query is correct then they can approach the application
  43. developers for review but this hasn't happened to my knowledge.
  44.  
  45. >> How did you /will you handle changes in the database schema?
  46.  
  47. We don't allow adhoc querries on live production data.  Production data
  48. structures are geared (denormalised and indexed) for production activity and
  49. throughput.  We full normalise the production structures and place a full copy
  50. into the reporting database.  The reporting database has many many indexes
  51. which would slow down updates (which don't happen here) but are fine for
  52. reporting.
  53.  
  54. Regular copies are a real pain but Oracle7 has some nice features which should
  55. make this a lot easier.
  56.  
  57. > Are "user query tools" a dead end, due to inadequate protection against
  58. > "incorrect" queries?
  59.  
  60. At the moment YES.  The standard reply from the vendor is to run it on a bigger
  61. machine which of course requires more license spending and maintenance costs. 
  62. Keep screaming at the vendor long enough and they will eventually come up with
  63. something useful.
  64.  
  65. > If so, what are the alternatives (rapid development of query applications, 
  66. improved report writing tools...)?.  
  67.  
  68. When an application is built we try to identify the major reports that would be
  69. required.  Those that satisfy 90-99% of all inquiries.  The user is given the
  70. ability to modify the columns that are extracted and change range settings on
  71. the WHERE clauses but cannot add to the complexity of the query.  The base
  72. skeleton query is optimised by the application developers.
  73.  
  74. We have found this to work quite well.  If the user's job changes to start
  75. requiring additional reports regularly then they are factored into the
  76. maintenance/enhancement resources for that project.
  77.  
  78. > If not, how are they best used (only with heavy training for users, small
  79. > databases only, on extracted "reporting" databases...)?
  80.  
  81. If you have an end user adhoc reporting requirement then you MUST TRAIN them in
  82. using the tools efficiently.  You MUST MONITOR who is using the adhoc enquiry
  83. facilities and clobber anyone who is doing inefficent reporting.
  84.  
  85. > My intention here is to stimulate discussion.  Speculate away!
  86.  
  87. Is the above a good start?
  88.  
  89. -- 
  90.  
  91. Bruce...        pihlab@hhcs.gov.au
  92.                  ^^
  93. *******************************************************************
  94. * Bruce Pihlamae  --  Database Administration                     *
  95. * Commonwealth Department of Health, Housing & Community Services *
  96. * Canberra, Australia                             (W) 06-289-7056 *
  97. *******************************************************************
  98. * These are my own thoughts and opinions, few that I have.        *
  99. *******************************************************************
  100.