home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / oracle / 1562 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  4.9 KB

  1. Path: sparky!uunet!wupost!sdd.hp.com!swrinde!elroy.jpl.nasa.gov!ames!pacbell.com!pacbell!oracle!unrepliable!bounce
  2. From: kmallory@oracle.com (Kevin Mallory)
  3. Newsgroups: comp.databases.oracle
  4. Subject: Re: SQL*Net performance - why this way?
  5. Message-ID: <KMALLORY.92Sep11160050@hqsun4.oracle.com>
  6. Date: 12 Sep 92 00:00:50 GMT
  7. References: <1992Sep4.193604.1@cc.helsinki.fi>
  8.     <KMALLORY.92Sep9114249@hqsun4.oracle.com>
  9.     <1992Sep10.090230.1@cc.helsinki.fi>
  10. Sender: usenet@oracle.us.oracle.com (Oracle News Poster)
  11. Organization: Oracle Corp., Belmont CA
  12. Lines: 96
  13. In-Reply-To: jaakola@cc.helsinki.fi's message of 10 Sep 92 07:02:30 GMT
  14. Nntp-Posting-Host: hqsun4.us.oracle.com
  15. X-Disclaimer: This message was written by an unauthenticated user
  16.               at Oracle Corporation.  The opinions expressed are those
  17.               of the user and not necessarily those of Oracle.
  18.  
  19.  
  20. I posted the following abstract from the 3.0.16.10 SQL*Forms release notes
  21. which describe the changes to forms. These changes are not RDBMS
  22. version specific.
  23.  
  24.  
  25. SQL*Forms 3.0.16.10 Performance Enhancements
  26. ============================================
  27.  
  28. SQL Statement Execution
  29.  
  30.              SQL*Forms now uses a different interface to the RDBMS
  31.         that allows the bundling of bind variable addresses and WHERE
  32.         clause conditions. This substantially reduces the number of
  33.         client/server interactions required to execute some SQL
  34.         statements.
  35.  
  36.              The table below details the results of the measurement
  37.         of the number of packets exchanged between client and server,
  38.         for a number of different types of SQL statements.
  39.  
  40.              Note Statements 1 and 2 demonstrate NO improvement in
  41.         performance as there is only 1 bind variable and/or one WHERE
  42.         clause condition, and thus no bundling of RDBMS calls takes
  43.         place.
  44.   
  45.       SQL            Number of Packets Exchanged
  46.         Statement                                      Percent
  47.         Number         3.0.16.7          3.0.16.10     Improvement
  48.  
  49.           1                 14               14            0%
  50.           2                 10               10            0%
  51.           3                 28               14           50%
  52.           4                 40               14           65%
  53.  
  54.         SQL Statements:
  55.  
  56.         1) select dname into :dname frm drept where deptno = :deptno;
  57.  
  58.         2) select ename into :ename from emp;
  59.  
  60.         3) select empno, ename, job, mgr, hiredate, sal, comm, deptno
  61.            into  :empno, :ename, :job, :mgr, :hiredate, :sal, :comm, :deptno
  62.            from emp
  63.            where empno = :empno;
  64.  
  65.         4) select empno, ename, job, mgr, hiredate, sal, comm, deptno
  66.            into  :empno, :ename, :job, :mgr, :hiredate, :sal, :comm,
  67.      :deptno
  68.            from emp
  69.            where empno = :empno and ename= :ename and
  70.                  job= :job and MGR= :mgr and hiredate= :hiredate
  71.                  and SAL= :sal and deptno= :deptno;
  72.  
  73.        When Will SQL*Forms Use UPIALL?
  74.  
  75.              A significant amount of discussion has arisen about the
  76.         use of UPIALL in Oracle Tools.  This section describes the
  77.         results of our study of the performance of UPIALL vs. the
  78.         current methods being used.
  79.  
  80.             The execution of SQL statements is divided into a 5
  81.         distinct operations: parse, bind, define, execute, and fetch.
  82.         UPIALL is a programmatic interface designed to minimize the
  83.         number of client/server interactions by "bundling" groups of
  84.         these calls into one client/server interaction. That is,
  85.         rather  than one client server interaction for each
  86.         operation, it is possible to bundle them into two or even one
  87.         large client/server interaction, thus reducing the number of
  88.         packets exchanged between client and server.
  89.  
  90.              SQL*Forms development has studied in great depth the
  91.         performance of SQL statements in SQL*Forms V3.0.  After
  92.         careful study of the results we decided NOT to implement
  93.         UPIALL support in SQL*Forms for several reasons:
  94.  
  95.              1) Prior to RDBMS 6.0.32.4 there were bugs in the RDBMS
  96.              that precluded the use of UPIALL in SQL*Forms.
  97.  
  98.              2) A substantial performance improvement (reduction in
  99.              packets) is achieved by using the bundled bind varible
  100.              and where clause define RDBMS interface.
  101.  
  102.              3) The minimum performance improvement that UPIALL
  103.              provides over and above (2) above does not warrant a
  104.              strict RDBMS version requirement by SQL*Forms.
  105.  
  106.              4) RDBMS V7 provides changes to the UPI interface, which
  107.              further reduces client/server interaction which will
  108.              require no further changes in SQL*Forms code.
  109. --
  110. ---------------
  111. Kevin Mallory    Oracle Corporation - Redwood Shores, California
  112. SQL*Forms Development
  113. I don't speak for Oracle, nor they for me.
  114. Remember: If you can find someplace you laik better 'n' Tuna... **MOVE**!
  115.