{"id":788,"date":"2006-05-08T12:00:00","date_gmt":"2006-05-08T12:00:00","guid":{"rendered":"http:\/\/orcldoug.com\/blog\/?p=788"},"modified":"2006-05-08T12:00:00","modified_gmt":"2006-05-08T12:00:00","slug":"px-issues-continued","status":"publish","type":"post","link":"http:\/\/orcldoug.com\/blog\/2006\/05\/08\/px-issues-continued\/","title":{"rendered":"PX Issues Continued"},"content":{"rendered":"<p>One of the problems in working with Parallel Execution is that you tend to work on it in bursts, usually when a data warehouse is running into problems, and then don&#8217;t work on it for months. I&#8217;m in the middle of one of those bursts and there are a couple of related issues that I wanted to cover. (Postscript &#8211; this turned out to be a much longer blog than I planned &#8211; both in number of words and time spent!)<\/p>\n<p><span style=\"font-weight: bold\">Limiting Logical Reads in 9i and 10g<\/span><br \/>As I mentioned in <a href=\"http:\/\/oracledoug.blogspot.com\/2006\/05\/minor-parallel-execution-problem.html\">this previous blog<\/a>, we were hoping to use Resource Profiles on our 10.2 data warehouse instance to limit the resources that user queries can use while we have some significant batch jobs running. We were setting the LOGICAL_READS_PER_CALL resource limit but noticed that some user queries had run quite happily for 10 minutes or so, chewing up resources and slowing down the batch jobs. When we investigated, we noticed that those queries were using parallel execution slaves and realised that LOGICAL_READS_PER_CALL isn&#8217;t going to limit what the slaves do as they&#8217;re using direct path i\/o operations, which aren&#8217;t counted as logical reads. e.g. (On Oracle 10.2)<\/p>\n<pre>SQL&gt; connect \/ as sysdba<br\/>Connected.<br\/>SQL&gt; select resource_name, limit from dba_profiles;<br\/><br\/>RESOURCE_NAME                    LIMIT<br\/>-------------------------------- ----------------------------------------<br\/>COMPOSITE_LIMIT                  UNLIMITED<br\/>SESSIONS_PER_USER                UNLIMITED<br\/>CPU_PER_SESSION                  UNLIMITED<br\/>CPU_PER_CALL                     UNLIMITED<br\/>LOGICAL_READS_PER_SESSION        UNLIMITED<br\/>LOGICAL_READS_PER_CALL           10000<br\/>IDLE_TIME                        UNLIMITED<br\/>CONNECT_TIME                     UNLIMITED<br\/>PRIVATE_SGA                      UNLIMITED<br\/>FAILED_LOGIN_ATTEMPTS            10<br\/>PASSWORD_LIFE_TIME               UNLIMITED<br\/>PASSWORD_REUSE_TIME              UNLIMITED<br\/>PASSWORD_REUSE_MAX               UNLIMITED<br\/>PASSWORD_VERIFY_FUNCTION         NULL<br\/>PASSWORD_LOCK_TIME               UNLIMITED<br\/>PASSWORD_GRACE_TIME              UNLIMITED<br\/><br\/>16 rows selected.<br\/><br\/>SQL&gt; alter system set resource_limit=true;<br\/><br\/>System altered.<br\/><br\/>SQL&gt; connect testuser\/testuser<br\/>Connected.<br\/>SQL&gt; select table_name, blocks from user_tables where table_name = 'TEMP';<br\/><br\/>TABLE_NAME                         BLOCKS<br\/>------------------------------ ----------<br\/>TEMP                                15873<br\/><br\/>SQL&gt; select count(*) from temp;<br\/>select count(*) from temp<br\/>             *<br\/>ERROR at line 1:<br\/>ORA-02395: exceeded call limit on IO usage<br\/><br\/><br\/>SQL&gt; select \/*+ parallel(temp, 2) *\/ count(*) from temp;<br\/><br\/>COUNT(*)<br\/>----------<br\/>1000000<\/pre>\n<p>So far so good; logical, but awkward for us. While I was playing around, though, I noticed that if I set a limit for LOGICAL_READS_PER_SESSION then the parallel queries would be terminated. e.g.<\/p>\n<pre>SQL&gt; connect \/ as sysdba<br\/>Connected.<br\/>SQL&gt; alter profile default limit logical_reads_per_call unlimited;<br\/><br\/>Profile altered.<br\/><br\/>SQL&gt; alter profile default limit logical_reads_per_session 10000;<br\/><br\/>Profile altered.<br\/><br\/>SQL&gt; connect testuser\/testuser<br\/>Connected.<br\/>SQL&gt; select count(*) from temp;<br\/>select count(*) from temp<br\/>               *<br\/>ERROR at line 1:<br\/>ORA-02394: exceeded session  limit on IO usage, you are being logged off<br\/><br\/>SQL&gt; connect testuser\/testuser<br\/>Connected.<br\/>SQL&gt; select \/*+ parallel(temp, 2) *\/ count(*) from temp;<br\/>select \/*+ parallel(temp, 2) *\/ count(*) from temp<br\/>*<br\/>ERROR at line 1:<br\/>ORA-02394: exceeded session limit on IO usage, you are being logged off<\/pre>\n<p>So as far as 10.2 is concerned, blocks read by px slaves aren&#8217;t logical i\/o when counting the call usage, but they are when counting the session usage. As Jonathan Lewis said in a comment on the original blog<\/p>\n<p><span style=\"font-style: italic\">I think the reason for the contradictory aspect of this behaviour is that someone has fiddled with the code for &#8220;session logical reads&#8221; in 10g, and not done so properly.<\/p>\n<p>You will probably find that the statistic &#8220;session logical reads&#8221; (in your test) matches &#8220;consistent gets&#8221;; and that &#8220;consistent gets&#8221; is the sum of &#8220;consistent gets from cache&#8221; and &#8220;consistent gets direct&#8221;.<\/span><\/p>\n<p>So let&#8217;s check that then. I&#8217;m going to use <a href=\"http:\/\/asktom.oracle.com\/%7Etkyte\/runstats.html\">Tom Kyte&#8217;s runstats package<\/a> for this, something I confess I haven&#8217;t used much, but it does exactly what I&#8217;m looking for here.<\/p>\n<pre>SQL&gt; connect \/ as sysdba<br\/>Connected.<br\/>SQL&gt; alter system set resource_limit=false;<br\/><br\/>System altered.<br\/><br\/>SQL&gt; connect testuser\/testuser<br\/>Connected.<br\/>SQL&gt; exec runstats_pkg.rs_start;<br\/><br\/>PL\/SQL procedure successfully completed.<br\/><br\/>SQL&gt; select \/*+ parallel(temp, 2) *\/ count(*) from temp;<br\/><br\/>COUNT(*)<br\/>----------<br\/>1000000<br\/><br\/>SQL&gt; exec runstats_pkg.rs_stop;<br\/><br\/>PL\/SQL procedure successfully completed.<br\/><br\/>SQL&gt; select * from stats where name like '%session logical reads%';<br\/><br\/>NAME<br\/>-----------------------------------------------------------------------<br\/> VALUE<br\/>----------<br\/>STAT...session logical reads<br\/> 16085<br\/><br\/><br\/>SQL&gt; select * from stats where name like '%consistent gets%';<br\/><br\/>NAME<br\/>-----------------------------------------------------------------------<br\/> VALUE<br\/>----------<br\/>STAT...consistent gets<br\/> 16020<br\/><br\/>STAT...consistent gets from cache<br\/>   147<br\/><br\/>STAT...consistent gets - examination<br\/>     2<br\/><br\/>STAT...consistent gets direct<br\/> 15873<\/pre>\n<p>So it looks like Jonathan&#8217;s right (well, the numbers are close enough for my satisfaction). I wonder how the same job looks on 9.2?<\/p>\n<pre>[oracle@ISP4400 ~]$ sqlplus \"\/ as sysdba\"<br\/><br\/>SQL*Plus: Release 9.2.0.4.0 - Production on Mon May 8 23:39:29 2006<br\/><br\/>Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.<br\/><br\/><br\/>Connected to:<br\/>Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production<br\/>With the Partitioning, OLAP and Oracle Data Mining options<br\/>JServer Release 9.2.0.4.0 - Production<br\/><br\/>SQL&gt; connect \/ as sysdba<br\/>Connected.<br\/>SQL&gt; alter system set resource_limit=false;<br\/><br\/>System altered.<br\/><br\/>SQL&gt; connect testuser\/testuser<br\/>Connected.<br\/>SQL&gt; exec runstats_pkg.rs_start;<br\/><br\/>PL\/SQL procedure successfully completed.<br\/><br\/>SQL&gt; select \/*+ parallel(temp, 2) *\/ count(*) from temp;<br\/><br\/><br\/>COUNT(*)<br\/>----------<br\/>  999999<br\/><br\/>SQL&gt; SQL&gt; exec runstats_pkg.rs_stop;<br\/><br\/>PL\/SQL procedure successfully completed.<br\/><br\/>SQL&gt; select * from stats where name like '%session logical reads%';<br\/><br\/>NAME<br\/>-----------------------------------------------------------------------<br\/>   VALUE<br\/>----------<br\/>STAT...session logical reads<br\/>    1164<br\/><br\/><br\/>SQL&gt; select * from stats where name like '%consistent gets%';<br\/><br\/>NAME<br\/>-----------------------------------------------------------------------<br\/>   VALUE<br\/>----------<br\/>STAT...consistent gets<br\/>   16010<br\/><br\/>STAT...consistent gets - examination<br\/>       5<\/pre>\n<p>In the end, I realise this is all a little esoteric. For day to day use, it&#8217;s best to forget about using any of the LOGICAL_READS% limits if you&#8217;re using PX. It&#8217;s probably best to use Resource Manager in those cases.<\/p>\n<p><span style=\"font-weight: bold\">Disabling PX at the Session Level<\/span><br \/>So we can&#8217;t use LOGICAL_READS_PER_CALL to limit the workload of an individual call using Resource Profiles because the bulk of the i\/o workload takes place in the px slaves, which use direct path operations. One of the solutions we&#8217;ve considered is a login trigger that stops certain users using PX during the batch window. Something like this :-<\/p>\n<pre>CREATE OR REPLACE TRIGGER disable_px<br\/>AFTER LOGON ON DATABASE<br\/>DECLARE<br\/>vdb_resource_limit v$parameter.value%TYPE;<br\/>BEGIN<br\/><br\/>IF USER IN ('READ_ONLY', 'REPORTING', 'BURNSD') THEN<br\/>SELECT value INTO vdb_resource<br\/>FROM v$parameter<br\/>WHERE name = 'resource_limit';<br\/><br\/>IF vdb_resource = 'TRUE' THEN<br\/>EXECUTE IMMEDIATE 'ALTER SESSION DISABLE PARALLEL QUERY';<br\/>END IF;<br\/>END IF;<br\/>END;<br\/>\/<\/pre>\n<p>This should force user sessions to use serial execution and therefore have their resource usage capped by the Resource Profiles. One down-side to this approach is that this won&#8217;t stop an already-connected user from using PX but that&#8217;s not a problem in our case because the first stage of our batch process is to kick all of the users out. At that point, they can reconnect to run queries while the batch process proceeds, but at least we&#8217;re guaranteed that they&#8217;ll have to log in.<\/p>\n<p>I couldn&#8217;t get this trigger to prevent PX usage, despite faffing around with it for a while. Eventually I decided to just try the ALTER SESSION command manually. This is on 10.2, but I got similar results from 9.2<\/p>\n<pre>[oracle@ISP4400 ~]$ sqlplus testuser<br\/><br\/>SQL*Plus: Release 10.2.0.1.0 - Production on Mon May 8 19:12:37 2006<br\/><br\/>Copyright (c) 1982, 2005, Oracle.  All rights reserved.<br\/><br\/>Enter password:<br\/><br\/>Connected to:<br\/>Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production<br\/>With the Partitioning, OLAP and Data Mining options<br\/><br\/>SQL&gt; set autotrace on<br\/>SQL&gt; alter session disable parallel query;<br\/><br\/>Session altered.<br\/><br\/>SQL&gt; select \/*+ parallel(test_tab1, 2) *\/ count(*) from test_tab1;<br\/><br\/>COUNT(*)<br\/>----------<br\/>65536000<br\/><br\/><br\/>Execution Plan<br\/>----------------------------------------------------------<br\/>Plan hash value: 1614812727<br\/><br\/>--------------------------------------------------------------------------------<br\/>-------------------------<br\/><br\/>| Id  | Operation              | Name      | Rows  | Cost (%CPU)| Time     |<br\/>TQ  |IN-OUT| PQ Distrib |<br\/><br\/>--------------------------------------------------------------------------------<br\/>-------------------------<br\/><br\/>|   0 | SELECT STATEMENT       |           |     1 |   606K  (1)| 03:34:54 |<br\/>|      |            |<br\/><br\/>|   1 |  SORT AGGREGATE        |           |     1 |            |          |<br\/>|      |            |<br\/><br\/>|   2 |   PX COORDINATOR       |           |       |            |          |<br\/>|      |            |<br\/><br\/>|   3 |    PX SEND QC (RANDOM) | :TQ10000  |     1 |            |          |  Q1<br\/>,00 | P-&gt;S | QC (RAND)  |<br\/><br\/>|   4 |     SORT AGGREGATE     |           |     1 |            |          |  Q1<br\/>,00 | PCWP |            |<br\/><br\/>|   5 |      PX BLOCK ITERATOR |           |    65M|   606K  (1)| 03:34:54 |  Q1<br\/>,00 | PCWC |            |<br\/><br\/>|   6 |       TABLE ACCESS FULL| TEST_TAB1 |    65M|   606K  (1)| 03:34:54 |  Q1<br\/>,00 | PCWP |            |<br\/><br\/>--------------------------------------------------------------------------------<br\/>-------------------------<br\/><br\/><br\/><br\/>Statistics<br\/>----------------------------------------------------------<br\/>10  recursive calls<br\/>0  db block gets<br\/>1118936  consistent gets<br\/>1118207  physical reads<br\/>0  redo size<br\/>413  bytes sent via SQL*Net to client<br\/>385  bytes received via SQL*Net from client<br\/>2  SQL*Net roundtrips to\/from client<br\/>1  sorts (memory)<br\/>0  sorts (disk)<br\/>1  rows processed<br\/><br\/>SQL&gt;<\/pre>\n<p>So what&#8217;s going on there, then? I also checked the contents of v$px_process while the query was running.<\/p>\n<pre>SQL&gt; select * from v$px_process;<br\/><br\/>SERV STATUS           PID SPID                SID    SERIAL#<br\/>---- --------- ---------- ------------ ---------- ----------<br\/>P000 IN USE            10 28124                17         41<br\/>P001 IN USE            11 28126                12         90<\/pre>\n<p>You could argue that the hint explicitly over-rides the session level setting, but that&#8217;s not how the <a href=\"http:\/\/download-east.oracle.com\/docs\/cd\/B19306_01\/server.102\/b14231\/manproc.htm#sthref683\">documentation<\/a> read to me the first few times I read it.<span style=\"font-style: italic\"><\/p>\n<p><span style=\"font-style: italic\">&#8220;<\/span>You disable parallel SQL execution with an <\/span><code style=\"font-style: italic\">ALTER SESSION DISABLE PARALLEL DML|DDL|QUERY<\/code> statement. All subsequent DML (<code style=\"font-style: italic\">INSERT<\/code><span style=\"font-style: italic\">, <\/span><code style=\"font-style: italic\">UPDATE<\/code><span style=\"font-style: italic\">, <\/span><code style=\"font-style: italic\">DELETE<\/code><span style=\"font-style: italic\">), DDL (<\/span><code style=\"font-style: italic\">CREATE<\/code><span style=\"font-style: italic\">, <\/span><code style=\"font-style: italic\">ALTER<\/code><span style=\"font-style: italic\">), or query (<\/span><code style=\"font-style: italic\">SELECT<\/code><span style=\"font-style: italic\">) operations are executed serially after such a statement is issued. They will be executed serially regardless of any <\/span><code style=\"font-style: italic\">PARALLEL<\/code><span style=\"font-style: italic\"> clause associated with the statement or parallel attribute associated with the table or indexes involved.<span style=\"font-style: italic\">&#8220;<\/span><\/span><br \/>I suppose it doesn&#8217;t specifically say &#8216;hint&#8217; and &#8216;PARALLEL clause&#8217; means something different, but I think it&#8217;s pretty easy to misinterpret that. If my code <span style=\"font-style: italic\">isn&#8217;t<\/span> hinted, but uses the DEGREE setting on the table instead, the ALTER SESSION command <span style=\"font-style: italic\">does<\/span> prevent the query from running in parallel.<\/p>\n<pre>[oracle@ISP4400 ~]$ sqlplus testuser<br\/><br\/>SQL*Plus: Release 10.2.0.1.0 - Production on Mon May 8 20:56:37 2006<br\/><br\/>Copyright (c) 1982, 2005, Oracle.  All rights reserved.<br\/><br\/>Enter password:<br\/><br\/>Connected to:<br\/>Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production<br\/>With the Partitioning, OLAP and Data Mining options<br\/><br\/>SQL&gt; select table_name, degree from user_tables;<br\/><br\/>TABLE_NAME                     DEGREE<br\/>------------------------------ ------------------------------<br\/>TEST_TAB1                               8<br\/>TEST_TAB2                               1<br\/>DUDE                                    1<br\/>TEMP                                    1<br\/><br\/>SQL&gt; set autotrace on<br\/>SQL&gt; select count(*) from test_tab1;<br\/><br\/>COUNT(*)<br\/>----------<br\/>65536000<br\/><br\/><br\/>Execution Plan<br\/>----------------------------------------------------------<br\/>Plan hash value: 1614812727<br\/><br\/>--------------------------------------------------------------------------------<br\/>-------------------------<br\/><br\/>| Id  | Operation              | Name      | Rows  | Cost (%CPU)| Time     |<br\/>TQ  |IN-OUT| PQ Distrib |<br\/><br\/>--------------------------------------------------------------------------------<br\/>-------------------------<br\/><br\/>|   0 | SELECT STATEMENT       |           |     1 | 84269   (1)| 00:29:51 |<br\/>|      |            |<br\/><br\/>|   1 |  SORT AGGREGATE        |           |     1 |            |          |<br\/>|      |            |<br\/><br\/>|   2 |   PX COORDINATOR       |           |       |            |          |<br\/>|      |            |<br\/><br\/>|   3 |    PX SEND QC (RANDOM) | :TQ10000  |     1 |            |          |  Q1<br\/>,00 | P-&gt;S | QC (RAND)  |<br\/><br\/>|   4 |     SORT AGGREGATE     |           |     1 |            |          |  Q1<br\/>,00 | PCWP |            |<br\/><br\/>|   5 |      PX BLOCK ITERATOR |           |    65M| 84269   (1)| 00:29:51 |  Q1<br\/>,00 | PCWC |            |<br\/><br\/>|   6 |       TABLE ACCESS FULL| TEST_TAB1 |    65M| 84269   (1)| 00:29:51 |  Q1<br\/>,00 | PCWP |            |<br\/><br\/>--------------------------------------------------------------------------------<br\/>-------------------------<br\/><br\/><br\/><br\/>Statistics<br\/>----------------------------------------------------------<br\/>821  recursive calls<br\/>3  db block gets<br\/>1119199  consistent gets<br\/>1118211  physical reads<br\/>680  redo size<br\/>413  bytes sent via SQL*Net to client<br\/>385  bytes received via SQL*Net from client<br\/>2  SQL*Net roundtrips to\/from client<br\/>7  sorts (memory)<br\/>0  sorts (disk)<br\/>1  rows processed<br\/><br\/>SQL&gt; alter session disable parallel query;<br\/><br\/>Session altered.<br\/><br\/>SQL&gt; select count(*) from test_tab1<br\/>2  \/<br\/><br\/>COUNT(*)<br\/>----------<br\/>65536000<br\/><br\/><br\/>Execution Plan<br\/>----------------------------------------------------------<br\/>Plan hash value: 1745491793<br\/><br\/>------------------------------------------------------------------------<br\/>| Id  | Operation          | Name      | Rows  | Cost (%CPU)| Time     |<br\/>------------------------------------------------------------------------<br\/>|   0 | SELECT STATEMENT   |           |     1 |   607K  (1)| 03:35:14 |<br\/>|   1 |  SORT AGGREGATE    |           |     1 |            |          |<br\/>|   2 |   TABLE ACCESS FULL| TEST_TAB1 |    65M|   607K  (1)| 03:35:14 |<br\/>------------------------------------------------------------------------<br\/><br\/><br\/>Statistics<br\/>----------------------------------------------------------<br\/>1  recursive calls<br\/>0  db block gets<br\/>1118229  consistent gets<br\/>1118207  physical reads<br\/>0  redo size<br\/>413  bytes sent via SQL*Net to client<br\/>385  bytes received via SQL*Net from client<br\/>2  SQL*Net roundtrips to\/from client<br\/>0  sorts (memory)<br\/>0  sorts (disk)<br\/>1  rows processed<\/pre>\n<p>But, when I hint the code, it over-rides the session setting.<\/p>\n<pre> SQL&gt; select \/*+ parallel(test_tab1) *\/ count(*)<br\/>2  from test_tab1;<br\/>COUNT(*)<br\/>----------<br\/>65536000<br\/><br\/><br\/>Execution Plan<br\/>----------------------------------------------------------<br\/>Plan hash value: 1614812727<br\/><br\/>--------------------------------------------------------------------------------<br\/>-------------------------<br\/><br\/>| Id  | Operation              | Name      | Rows  | Cost (%CPU)| Time     |<br\/>TQ  |IN-OUT| PQ Distrib |<br\/><br\/>--------------------------------------------------------------------------------<br\/>-------------------------<br\/><br\/>|   0 | SELECT STATEMENT       |           |     1 |   606K  (1)| 03:34:54 |<br\/>|      |            |<br\/><br\/>|   1 |  SORT AGGREGATE        |           |     1 |            |          |<br\/>|      |            |<br\/><br\/>|   2 |   PX COORDINATOR       |           |       |            |          |<br\/>|      |            |<br\/><br\/>|   3 |    PX SEND QC (RANDOM) | :TQ10000  |     1 |            |          |  Q1<br\/>,00 | P-&gt;S | QC (RAND)  |<br\/><br\/>|   4 |     SORT AGGREGATE     |           |     1 |            |          |  Q1<br\/>,00 | PCWP |            |<br\/><br\/>|   5 |      PX BLOCK ITERATOR |           |    65M|   606K  (1)| 03:34:54 |  Q1<br\/>,00 | PCWC |            |<br\/><br\/>|   6 |       TABLE ACCESS FULL| TEST_TAB1 |    65M|   606K  (1)| 03:34:54 |  Q1<br\/>,00 | PCWP |            |<br\/><br\/>--------------------------------------------------------------------------------<br\/>-------------------------<br\/><br\/><br\/><br\/>Statistics<br\/>----------------------------------------------------------<br\/>61  recursive  calls<br\/>3  db block gets<br\/>1119092  consistent gets<br\/>1118207  physical reads<br\/>632  redo size<br\/>413  bytes sent via SQL*Net to client<br\/>385  bytes received via SQL*Net from client<br\/>2  SQL*Net roundtrips to\/from client<br\/>1  sorts (memory)<br\/>0  sorts (disk)<br\/>1  rows processed<\/pre>\n<p>I suppose it&#8217;s not <span style=\"font-style: italic\">that<\/span> big a deal, but I think it would be an easy mistake to think that using a login trigger could completely disable PX at the session level, but it appears that it won&#8217;t work if you have hinted code.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>One of the problems in working with Parallel Execution is that you tend to work on it in bursts, usually when a data warehouse is running into problems, and then don&#8217;t work on it for months. I&#8217;m in the middle of one of those bursts and there are a couple of related issues that I&hellip; <a class=\"more-link\" href=\"http:\/\/orcldoug.com\/blog\/2006\/05\/08\/px-issues-continued\/\">Continue reading <span class=\"screen-reader-text\">PX Issues Continued<\/span><\/a><\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-788","post","type-post","status-publish","format-standard","hentry","category-uncategorized","entry"],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":881,"url":"http:\/\/orcldoug.com\/blog\/2006\/01\/15\/peter-robson-on-the-temporal-database-seminar\/","url_meta":{"origin":788,"position":0},"title":"Peter Robson on the Temporal Database seminar","date":"January 15, 2006","format":false,"excerpt":"It's a bit of a blog frenzy today!On the 3rd November last year, immediately after the UKOUG conference, there was a seminar in Edinburgh to discuss temporal databases. (Mogens blogged about it here and I'd mentioned some of Rob Squire's work here.) I had planned to go initially but was\u2026","rel":"","context":"With 7 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1011,"url":"http:\/\/orcldoug.com\/blog\/2006\/07\/04\/whats-a-data-warehouse-dba\/","url_meta":{"origin":788,"position":1},"title":"What&#8217;s a &#8216;Data Warehouse DBA&#8217;?","date":"July 4, 2006","format":false,"excerpt":"I've seen that question asked often in forums and mail groups. It's easy to understand why there's so much confusion because, for most DBAs, if you've seen one database, you've seen them all. Or rather, you haven't seen any of them. What I mean is that every database that lands\u2026","rel":"","context":"With 14 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1159,"url":"http:\/\/orcldoug.com\/blog\/2006\/12\/11\/a-more-complex-statspack-example-summary\/","url_meta":{"origin":788,"position":2},"title":"A More Complex Statspack Example &#8211; Summary","date":"December 11, 2006","format":false,"excerpt":"Looking back at the three blogs (and hopefully the comments, where others have made some very useful contributions), it's all quite unsatisfactory, isn't it? We haven't solved the problem. All we've proved is that the tests aren't equivalent, although I think there's value in that negative result because I was\u2026","rel":"","context":"With 3 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1050,"url":"http:\/\/orcldoug.com\/blog\/2006\/08\/10\/historical-perspective-part-2\/","url_meta":{"origin":788,"position":3},"title":"Historical Perspective (Part 2)","date":"August 10, 2006","format":false,"excerpt":"Let's look at items 2 and 3 from the list in my previous blog1) You know you have a performance problem and can re-create it by running a specific part of the application, be it a user interaction or batch job.2) You have an intermittent but recurring performance problem which\u2026","rel":"","context":"Similar post","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1371,"url":"http:\/\/orcldoug.com\/blog\/2007\/12\/24\/the-reality-gap-4-its-never-the-san\/","url_meta":{"origin":788,"position":4},"title":"The Reality Gap (4) &#8211; It&#8217;s never the SAN","date":"December 24, 2007","format":false,"excerpt":"I've left one of my favourite topics for the penultimate episode of this mini-series. The more sites you work at and the more performance problems you work on, the more you begin to learn the one essential truth of modern system architecture. It's never the SAN. Here's a true story.\u2026","rel":"","context":"With 11 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1231,"url":"http:\/\/orcldoug.com\/blog\/2007\/03\/10\/how-can-i-tell-the-actual-dop-used-for-my-parallel-query\/","url_meta":{"origin":788,"position":5},"title":"How can I tell the actual DOP used for my Parallel Query?","date":"March 10, 2007","format":false,"excerpt":"At the end of my presentation this week, when I asked for questions, a lady from the middle of the hall piped up to ask something along the lines of.\"How can I tell the actual DOP used for my Parallel Query?\" (or words to that effect)It was in the context\u2026","rel":"","context":"With 3 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts\/788","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/comments?post=788"}],"version-history":[{"count":0,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts\/788\/revisions"}],"wp:attachment":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/media?parent=788"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/categories?post=788"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/tags?post=788"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}