<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Oracle RDB delayed SQL request in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229692#M27107</link>
    <description>Hi All,&lt;BR /&gt;&lt;BR /&gt;Not sure if subject theme is appropriate for this forum branch but since the issue runs on OpenVMS - I think I should start from here...&lt;BR /&gt;&lt;BR /&gt;Config: OpenVMS V8.3-1H1; Itanium rx4640, Oracle RDB 7.3. Database has one table (let it be T1) with over 13 million records.&lt;BR /&gt;&lt;BR /&gt;Would like to execute simple SQL statement with the output to the telnet window:&lt;BR /&gt;SELECT * FROM T1 WHERE FIELD &amp;lt; 2000;&lt;BR /&gt;It runs in two seconds, returns 1999 records, everything is ok. Make the threshold lower:&lt;BR /&gt;SELECT * FROM T1 WHERE FIELD &amp;lt; 1500;&lt;BR /&gt;It runs even faster, returns 1499 records, as expected. Now decrease the threshold to 1000:&lt;BR /&gt;SELECT * FROM T1 WHERE FIELD &amp;lt; 1000;&lt;BR /&gt;It starts running and suddenly got stuck at 511 records with blinking cursor... After 7-10 minutes (!) it wakes up and shows the rest for us to have 999 records as expected...&lt;BR /&gt;&lt;BR /&gt;That's kinda strange because both first and second requests show this 512 and etc records in less than a second. The issue is reproducing constantly. No deadlocks or timeouts; no one else is working at the system during the test. The same database being restored at the AlphaServer (the same OpenVMS and RDB versions) shows the same strange behavior.&lt;BR /&gt;&lt;BR /&gt;I suspect something wrong is with the database / table indexes / storage area... But unfortunately don't have much experience to understand what exactly. Could anyone give any hints on this issue? &lt;BR /&gt;&lt;BR /&gt;p.s. table structure is attached.&lt;BR /&gt;&lt;BR /&gt;</description>
    <pubDate>Thu, 11 Mar 2010 20:49:39 GMT</pubDate>
    <dc:creator>Dmitry V. Sinelnikov</dc:creator>
    <dc:date>2010-03-11T20:49:39Z</dc:date>
    <item>
      <title>Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229692#M27107</link>
      <description>Hi All,&lt;BR /&gt;&lt;BR /&gt;Not sure if subject theme is appropriate for this forum branch but since the issue runs on OpenVMS - I think I should start from here...&lt;BR /&gt;&lt;BR /&gt;Config: OpenVMS V8.3-1H1; Itanium rx4640, Oracle RDB 7.3. Database has one table (let it be T1) with over 13 million records.&lt;BR /&gt;&lt;BR /&gt;Would like to execute simple SQL statement with the output to the telnet window:&lt;BR /&gt;SELECT * FROM T1 WHERE FIELD &amp;lt; 2000;&lt;BR /&gt;It runs in two seconds, returns 1999 records, everything is ok. Make the threshold lower:&lt;BR /&gt;SELECT * FROM T1 WHERE FIELD &amp;lt; 1500;&lt;BR /&gt;It runs even faster, returns 1499 records, as expected. Now decrease the threshold to 1000:&lt;BR /&gt;SELECT * FROM T1 WHERE FIELD &amp;lt; 1000;&lt;BR /&gt;It starts running and suddenly got stuck at 511 records with blinking cursor... After 7-10 minutes (!) it wakes up and shows the rest for us to have 999 records as expected...&lt;BR /&gt;&lt;BR /&gt;That's kinda strange because both first and second requests show this 512 and etc records in less than a second. The issue is reproducing constantly. No deadlocks or timeouts; no one else is working at the system during the test. The same database being restored at the AlphaServer (the same OpenVMS and RDB versions) shows the same strange behavior.&lt;BR /&gt;&lt;BR /&gt;I suspect something wrong is with the database / table indexes / storage area... But unfortunately don't have much experience to understand what exactly. Could anyone give any hints on this issue? &lt;BR /&gt;&lt;BR /&gt;p.s. table structure is attached.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 11 Mar 2010 20:49:39 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229692#M27107</guid>
      <dc:creator>Dmitry V. Sinelnikov</dc:creator>
      <dc:date>2010-03-11T20:49:39Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229693#M27108</link>
      <description>Hi Dimitry,&lt;BR /&gt;&lt;BR /&gt;For two things to look at (if you haven't already): -&lt;BR /&gt;&lt;BR /&gt;1) Use $rmu/show statistics to display "stall messages" while it's running&lt;BR /&gt;&lt;BR /&gt;2) Turn on Optimizer output and see if the strategies change when the selection criteria changes &lt;BR /&gt;&lt;BR /&gt;Cheers Richard Maher&lt;BR /&gt;&lt;BR /&gt;PS. Also how long since anyone did and rmu/analyze on any of those indexes?</description>
      <pubDate>Thu, 11 Mar 2010 21:19:24 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229693#M27108</guid>
      <dc:creator>Richard J Maher</dc:creator>
      <dc:date>2010-03-11T21:19:24Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229694#M27109</link>
      <description>Dmitry,&lt;BR /&gt;&lt;BR /&gt;  Could you please post your SELECT query in terms of the table structure you've posted? What does FIELD correspond to?</description>
      <pubDate>Thu, 11 Mar 2010 23:33:20 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229694#M27109</guid>
      <dc:creator>John Gillings</dc:creator>
      <dc:date>2010-03-11T23:33:20Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229695#M27110</link>
      <description>In addition to Richard's suggestions, using rmu/show stats when running the query - look at the "Logical Area Information", " Logical Area Overview (Tables)" and see how many records of tables and indexes it is reading in each case.&lt;BR /&gt;&lt;BR /&gt;IS "FIELD" the first item in any of the indices ?&lt;BR /&gt;&lt;BR /&gt;If it is, then I would be thinking a call to Rdb support might be in order.&lt;BR /&gt;&lt;BR /&gt;cheers,&lt;BR /&gt;chris</description>
      <pubDate>Thu, 11 Mar 2010 23:35:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229695#M27110</guid>
      <dc:creator>Chris Barratt</dc:creator>
      <dc:date>2010-03-11T23:35:56Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229696#M27111</link>
      <description>Dimitry,&lt;BR /&gt;&lt;BR /&gt;can you post the result of:&lt;BR /&gt;set transaction 'read only';&lt;BR /&gt;set flags 'strat, detail(2),estim';&lt;BR /&gt;SELECT * FROM T1 WHERE FIELD &amp;lt; 2000;&lt;BR /&gt;SELECT * FROM T1 WHERE FIELD &amp;lt; 1500;&lt;BR /&gt;SELECT * FROM T1 WHERE FIELD &amp;lt; 1000;&lt;BR /&gt;&lt;BR /&gt;where field is the real column name.&lt;BR /&gt;&lt;BR /&gt;Jean-FranÃ§ois</description>
      <pubDate>Fri, 12 Mar 2010 06:01:28 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229696#M27111</guid>
      <dc:creator>Jean-François Piéronne</dc:creator>
      <dc:date>2010-03-12T06:01:28Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229697#M27112</link>
      <description>Looking at your indexes, I suggest you use&lt;BR /&gt;set flags 'strat, detail(2),estim,exec(10)'&lt;BR /&gt;&lt;BR /&gt;JF</description>
      <pubDate>Fri, 12 Mar 2010 08:51:10 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229697#M27112</guid>
      <dc:creator>Jean-François Piéronne</dc:creator>
      <dc:date>2010-03-12T08:51:10Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229698#M27113</link>
      <description>Hi all,&lt;BR /&gt;&lt;BR /&gt;Thanks for replies.&lt;BR /&gt;&lt;BR /&gt;The original request that slows dramatically is as follows:&lt;BR /&gt;SELECT * FROM NR_DOC_COMPLEX WHERE A_SYSID_DOC &amp;lt;1000 AND A_STAT_CHECK = 0;&lt;BR /&gt;The one that runs just fast:&lt;BR /&gt;SELECT * FROM NR_DOC_COMPLEX WHERE A_SYSID_DOC &amp;lt;2000 AND A_STAT_CHECK = 0;&lt;BR /&gt;&lt;BR /&gt;I ran both 'fast' and 'slow' SQL statements with the flags as Jean suggested. Telnet output is attached for both sessions. Slow point is at &lt;BR /&gt;&lt;BR /&gt;~E#0003.01(1) BgrNdx1 EofBuf   DBKeys=1024  Fetches=1+7  RecsOut=512&lt;BR /&gt;&lt;BR /&gt;record of output.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;p.s. Forgot to mention RDB version:&lt;BR /&gt;$ rmu /show version&lt;BR /&gt;Executing RMU for Oracle Rdb V7.2-310&lt;BR /&gt;</description>
      <pubDate>Fri, 12 Mar 2010 11:16:12 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229698#M27113</guid>
      <dc:creator>Dmitry V. Sinelnikov</dc:creator>
      <dc:date>2010-03-12T11:16:12Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229699#M27114</link>
      <description>Your request's strategy use 2 indices, XPK_NR_DOC_COMPLEX1 and SI_NR_DOC_COMPLEX_DATE.&lt;BR /&gt;&lt;BR /&gt;The interesting traces are&lt;BR /&gt;in the fast request:&lt;BR /&gt;~E#0003.01(1) BgrNdx1 EofBuf   DBKeys=1024  Fetches=1+7  RecsOut=512&lt;BR /&gt;~E#0003.01(1) BgrNdx2 EofBuf   DBKeys=1024  Fetches=4+433  RecsOut=512&lt;BR /&gt;...&lt;BR /&gt;~E#0003.01(1) Fin     TTbl     DBKeys=3998  Fetches=0+121  RecsOut=1999&lt;BR /&gt;&lt;BR /&gt;in the slow one:&lt;BR /&gt;~E#0003.01(1) BgrNdx1 EofBuf   DBKeys=1024  Fetches=1+7  RecsOut=512&lt;BR /&gt;~E#0003.01(1) BgrNdx2 EofData  DBKeys=999  Fetches=4+239808  RecsOut=512 #Bufs=126&lt;BR /&gt;~E#0003.01(1) FgrNdx  FFirst   DBKeys=512  Fetches=0+68  RecsOut=512`ABA&lt;BR /&gt;...&lt;BR /&gt;~E#0003.01(1) Fin     Buf      DBKeys=999  Fetches=0+65  RecsOut=999&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Rdb use for background index a buffer of 1024 dbkeys. If you overflowed this buffer it will switches to another index.&lt;BR /&gt;&lt;BR /&gt;In the fast one this buffer is quickly overflowed, so the scan of the second index is abandoned. But i the slow query Rdb can't  find 1025 records using the BgrNdx2 index, so the index is fully scan which give "4+239808" I/O.&lt;BR /&gt;&lt;BR /&gt;you can try to use the flags MAX_STABILITY for test, put a outline, or add an alternate index (A_STAT_CHECK, A_SYSID_DOC , ...)&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;JFP</description>
      <pubDate>Fri, 12 Mar 2010 11:42:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229699#M27114</guid>
      <dc:creator>Jean-François Piéronne</dc:creator>
      <dc:date>2010-03-12T11:42:42Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229700#M27115</link>
      <description>You can, also, read the excellent article form the Rdb journal:&lt;BR /&gt;&lt;A href="http://www.oracle.com/technology/products/rdb/pdf/rdb_journal/bitmapped_scan_1.pdf" target="_blank"&gt;http://www.oracle.com/technology/products/rdb/pdf/rdb_journal/bitmapped_scan_1.pdf&lt;/A&gt;</description>
      <pubDate>Fri, 12 Mar 2010 12:01:18 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229700#M27115</guid>
      <dc:creator>Jean-François Piéronne</dc:creator>
      <dc:date>2010-03-12T12:01:18Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229701#M27116</link>
      <description>Hi Dmitry,&lt;BR /&gt;&lt;BR /&gt;Or you could cross you fingers and stick in an ORDER BY A_SYSID_DOC, A_SYSID_ACC_ANALYT, A_SYSID_SYMBOL and see if it makes any diference?&lt;BR /&gt;&lt;BR /&gt;BTW to you really need all the columns "*"?&lt;BR /&gt;&lt;BR /&gt;Cheers Richard Maher&lt;BR /&gt;&lt;BR /&gt;PS. If that doesn't help then I try a derived table first before going the query-plan eg: -&lt;BR /&gt;&lt;BR /&gt;select * from&lt;BR /&gt;(select a,b,c order by where &amp;lt; 1000) as myTabl (x,x,z) where z = condition;&lt;BR /&gt;</description>
      <pubDate>Fri, 12 Mar 2010 12:07:05 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229701#M27116</guid>
      <dc:creator>Richard J Maher</dc:creator>
      <dc:date>2010-03-12T12:07:05Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229702#M27117</link>
      <description>Hi Dmitry,&lt;BR /&gt;&lt;BR /&gt;Just checking on this post and see you gave me 10 points. Can I take it that the ORDER BY convinced the optimizer to use the correct (optimum :-) index/strategy ?&lt;BR /&gt;&lt;BR /&gt;Performance any better over all ?&lt;BR /&gt;&lt;BR /&gt;Cheers Richard Maher</description>
      <pubDate>Mon, 15 Mar 2010 22:12:44 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229702#M27117</guid>
      <dc:creator>Richard J Maher</dc:creator>
      <dc:date>2010-03-15T22:12:44Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229703#M27118</link>
      <description>Hi Richard,&lt;BR /&gt;&lt;BR /&gt;Yes, you are correct, adding ORDER BY at the end of the statement eliminates this delay (ordering by all three columns).&lt;BR /&gt;&lt;BR /&gt;Also thanks to Jean-Francois, MAX_STABILITY flag resolves the issue as well.&lt;BR /&gt;&lt;BR /&gt;Two solutions, in fact... But working further with the customer we figured out that current database was corrupter for some reason. New instance of DB was provided and it didn't contain any issues like this.&lt;BR /&gt;&lt;BR /&gt;Anyway, thanks to everyone for input and discussion, I appreciate this.&lt;BR /&gt;Closing the thread since issue is resolved.&lt;BR /&gt;</description>
      <pubDate>Mon, 29 Mar 2010 12:00:55 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229703#M27118</guid>
      <dc:creator>Dmitry V. Sinelnikov</dc:creator>
      <dc:date>2010-03-29T12:00:55Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle RDB delayed SQL request</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229704#M27119</link>
      <description>See comment above.</description>
      <pubDate>Mon, 29 Mar 2010 12:01:31 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/oracle-rdb-delayed-sql-request/m-p/5229704#M27119</guid>
      <dc:creator>Dmitry V. Sinelnikov</dc:creator>
      <dc:date>2010-03-29T12:01:31Z</dc:date>
    </item>
  </channel>
</rss>

