{"id":1597,"date":"2014-05-02T12:00:00","date_gmt":"2014-05-02T12:00:00","guid":{"rendered":"http:\/\/orcldoug.com\/blog\/?p=1597"},"modified":"2014-05-02T12:00:00","modified_gmt":"2014-05-02T12:00:00","slug":"statistics-on-partitioned-tables-part-6c-copy_table_stats-bugs-and-patches","status":"publish","type":"post","link":"http:\/\/orcldoug.com\/blog\/2014\/05\/02\/statistics-on-partitioned-tables-part-6c-copy_table_stats-bugs-and-patches\/","title":{"rendered":"Statistics on Partitioned Tables – Part 6c – COPY_TABLE_STATS – Bugs and Patches"},"content":{"rendered":"

\nI wanted to talk about a few of the bugs and patches you need to be aware of if you plan to use DBMS_STATS.COPY_TABLE_STATS. Believe me, when entering the world of stats on (sub-)partitioned objects, you had better be prepared to spend a lot of time on My Oracle Support and a little time applying patches. It’s a complex picture but I’ll try to simplify it as much as possible here.<\/p>\n

10.2.0.3 or 10.2.0.4<\/strong> (or, late update … 10.2.0.5)<\/strong><\/p>\n

All of the posts so far have been based on the 10.2.0.4 patchset with additional one-off patches applied where necessary (more below). Although part of me can understand the resistance to applying new patchsets because of the additional testing, change management and outages required, I think it’s asking for trouble to be on older patchsets if you’re using newer features such as DBMS_STATS.COPY_TABLE_STATS. For example, as far as I’m aware COPY_TABLE_STATS is not truly supported in 10.2.0.3 but I’ve seen a number of people using it. <\/p>\n

These features are being worked on continuously, as you’ll see in the rest of this post, so I think you’ll want to apply the latest patches on top of the latest patchset where possible.<\/p>\n

So you should take my bitching about the new availability of 10.2.0.5<\/a> with a pinch of salt. In fact, I found myself quite excited that there might be some fixes for issues I’ve found. Back to 10.2.0.5 later …<\/p>\n

High\/Low Partition Key Values
<\/strong>
This is probably the best known of the stats copying bugs. Remember that at the end of part 6a<\/a>, COPY_TABLE_STATS had copied the statistics for the new P_20100211_GROT subpartition, using the P_20100209_GROT subpartition statistics as the source. Looking at a very small sample of the subpartition column statistics that have been copied :-<\/p>\n

*******************************\nSubpartition-Level Column Stats\n*******************************\nSQL> select\n\u00a0 2\u00a0\u00a0\u00a0\u00a0 a.column_name, a.subpartition_name,\n\u00a0 3\u00a0\u00a0\u00a0\u00a0 a.num_distinct,\n\u00a0 4\u00a0\u00a0\u00a0\u00a0 display_raw(a.low_value,b.data_type) as low_val,\n\u00a0 5\u00a0\u00a0\u00a0\u00a0 display_raw(a.high_value,b.data_type) as high_val,\n\u00a0 6\u00a0\u00a0\u00a0\u00a0 b.data_type\n\u00a0 7\u00a0 from\n\u00a0 8\u00a0\u00a0\u00a0\u00a0 dba_subpart_col_statistics a, dba_tab_cols b\n\u00a0 9\u00a0 where\n\u00a010\u00a0\u00a0\u00a0\u00a0 a.owner='TESTUSER' and\n\u00a011\u00a0\u00a0\u00a0\u00a0 a.table_name='TEST_TAB1' and\n\u00a012\u00a0\u00a0\u00a0\u00a0 a.table_name=b.table_name and\n\u00a013\u00a0\u00a0\u00a0\u00a0 a.column_name=b.column_name\n\u00a014\u00a0 order by 1, 2\n\u00a015\u00a0 \/\n\nCOLUMN_NAME\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 SUBPARTITION_NAME\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 NUM_DISTINCT LOW_VAL\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 HIGH_VAL\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \n-------------------------- ------------------------------ ------------ -------------------- --------------------\nDATA_TYPE\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \n--------------------\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \n<<snipped>>\n\nREPORTING_DATE\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 P_20100211_GROT\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1 20100209\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 20100209\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \nNUMBER\n\n<<snipped>>\n<\/pre>\n
Spot the deliberate mistake? You would think that DBMS_STATS would be smart enough to know that the partition key column high and low values are implicitly different for each new partition. I added a partition to cover reporting dates 20100210 and 20100211 :-<\/p>\n
SQL> ALTER TABLE TEST_TAB1\n\u00a0 2\u00a0 ADD\u00a0 PARTITION P_20100211 VALUES LESS THAN (20100212);\n<\/pre>\n
So I doubt that the high and low values for REPORTING_DATE are likely to be 20100209 😉<\/p>\n
It’s bug number 8318020 and is mentioned<\/a> in several places<\/a> on the net<\/a>. You can work around it by setting the column stats manually for the partition key, but you might as well just apply the correct one-off patch. Of course, once you start to apply that one-off patch, you will find a whole bunch of DBMS_STATS-related patches and I would lay good odds now that you’ll actually end up having to apply a Merge Label Request (MLR), encompassing a number of these patches. 8866627 is the particular one that I applied before most of these tests and that we use at work, which also solves the next issue.

Subpartition issues<\/strong><\/p>\n
I deliberately skipped over this one when I wrote part 6a<\/a> by ensuring I had 8866627 applied but it’s a nasty one, quite easy to miss and not referenced in too many places on the web, although I could find at least one useful thread<\/a>. <\/p>\n
If I repeat the partition-level stats copy from Part 6a without any patches applied to 10.2.0.4, this is the result.<\/p>\n
SQL> exec dbms_stats.copy_table_stats(ownname => 'TESTUSER', tabname => 'TEST_TAB1', \n                                      srcpartname => 'P_20100209', dstpartname => 'P_20100210');\nBEGIN dbms_stats.copy_table_stats(ownname => 'TESTUSER', tabname => 'TEST_TAB1', \n                                      srcpartname => 'P_20100209', dstpartname => 'P_20100210'); END;\n*\nERROR at line 1:\nORA-06533: Subscript beyond count\nORA-06512: at \"SYS.DBMS_STATS\", line 17408\nORA-06512: at line <\/pre>\n
As far as I’m aware and like many of the issues I’m raising, this would only be a problem when you have subpartitions as well as partitions. The important point is that I’ve never seen this bug since applying 8866627 and can’t recreate it on 10.2.0.5 either. <\/p>\n
ORA-03113 during aggregation<\/p>\n
<\/strong>Unfortunately, 8866627 doesn’t seem to fix the next issue and I can’t
\n find any references to it on the web either, but I’ve been able to recreate it on several databases with different patches applied, on different O\/S. First I’ll confirm the patches that 8866627 includes. <\/p>\n
Installed Top-level Products (2): \n\nOracle Database 10g\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.2.0.1.0\nOracle Database 10g Release 2 Patch Set 3\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.2.0.4.0\n\nThere are 2 products installed in this Oracle Home.\n\nInterim patches (1) :\n\nPatch\u00a0 8866627\u00a0\u00a0\u00a0\u00a0\u00a0 : applied on Fri Apr 23 13:04:42 BST 2010\n\u00a0\u00a0 Created on 6 Nov 2009, 05:38:04 hrs PST8PDT\n\u00a0\u00a0 Bugs fixed:\n\u00a0\u00a0\u00a0\u00a0 7475493, 7116357, 7463138, 6718212, 7441785, 6526370, 8318020\n<\/pre>\n
Now, having realised that copying the statistics at the partition level doesn’t work when I have only one subpartition populated with data because it doesn’t copy the statistics for the unpopulated partitions, I’ll try gathering the statistics on each subpartition one by one. You can try the same yourself using stats_6c.sql<\/a> (note that you will have to run stats_5_6a.sql<\/a> first<\/em> and that this script will generate a trace file) or see my results in stats_6c.txt<\/a>. The script just repopulates the load table, exchanges it with the GROT subpartition and then gathers stats on each of the subpartitions in turn. If this seems a little weird, it really isn’t because it’s perfectly feasible that we would have some empty subpartitions. <\/p>\n
The stats for each subpartition are copied successfully ….<\/p>\n
SQL> exec dbms_monitor.session_trace_enable;\n\nPL\/SQL procedure successfully completed.\n\nSQL> exec dbms_stats.copy_table_stats(ownname => 'TESTUSER', tabname => 'TEST_TAB1', \n                     srcpartname => 'P_20100209_GROT', dstpartname => 'P_20100211_GROT');\n\nPL\/SQL procedure successfully completed.\n\nSQL> exec dbms_stats.copy_table_stats(ownname => 'TESTUSER', tabname => 'TEST_TAB1', \n                     srcpartname => 'P_20100209_JUNE', dstpartname => 'P_20100211_JUNE');\n\nPL\/SQL procedure successfully completed.\n\nSQL> exec dbms_stats.copy_table_stats(ownname => 'TESTUSER', tabname => 'TEST_TAB1', \n                     srcpartname => 'P_20100209_HALO', dstpartname => 'P_20100211_HALO');\n\nPL\/SQL procedure successfully completed.<\/pre>\n
<\/p>\n
Until we get to the last subpartition. If you’ve been wading through the earlier posts, then you might be expecting Oracle to aggregate the subpartition stats to generate Aggregated Stats at the Partition level, now that all subpartitions have valid stats (which they should, as I’ve just copied them). Clearly some sort of aggregation process does<\/em> kick-in, because the session is disconnected at this point.<\/p>\n
SQL> alter session set \"_minimal_stats_aggregation\"=TRUE;\n\nSession altered.\n\nSQL> exec dbms_stats.copy_table_stats(ownname => 'TESTUSER', tabname => 'TEST_TAB1', \n                     srcpartname => 'P_20100209_OTHERS', dstpartname => 'P_20100211_OTHERS');\n\nSQL> show parameter user_dump_dest\nERROR:\nORA-03114: not connected to ORACLE \n<\/pre>\n
The reason I set _minimal_stats_aggregation to TRUE was to make sure that I was using the default value but setting it to FALSE leads to the same end result, as you’ll see from the test output posted earlier.<\/p>\n
Because this seemed such a weird error, I decided to trace the session and here’s a snippet of the resulting trace file that shows where the error occurs.<\/p>\n
PARSING IN CURSOR #44 len=38 dep=1 uid=0 oct=7 lid=0 tim=1242214568228618 hv=624276838 ad='a03acac0'\ndelete from ind_online$ where obj#= :1\n2END OF STMT\nPARSE #44:c=0,e=43,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1242214568228606\nEXEC #44:c=0,e=141,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=1242214568228961\nSTAT #44 id=1 cnt=0 pid=0 pos=1 obj=0 op='DELETE\u00a0 IND_ONLINE$ (cr=3 pr=0 pw=0 time=101 us)'\nSTAT #44 id=2 cnt=0 pid=1 pos=1 obj=731 op='TABLE ACCESS FULL IND_ONLINE$ (cr=3 pr=0 pw=0 time=66 us)'\nEXEC #7:c=0,e=42,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=1242214568229627\nFETCH #7:c=0,e=158,p=0,cr=12,cu=0,mis=0,r=1,dep=1,og=1,tim=1242214568229851\nEXEC #40:c=0,e=167,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=1242214568230144\nFETCH #40:c=0,e=851,p=0,cr=13,cu=0,mis=0,r=1,dep=1,og=1,tim=1242214568231118\nEXEC #38:c=0,e=43,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=1242214568231322\nFETCH #38:c=0,e=99,p=0,cr=12,cu=0,mis=0,r=1,dep=1,og=1,tim=1242214568231540\nException signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x0, \n                                PC: [0x1a1baf7, qospMinMaxPartCol()+3135]\n*** 2010-04-23 14:01:57.888\nksedmp: internal or fatal error\nORA-07445: exception encountered: core dump [qospMinMaxPartCol()+3135] \n                                  [SIGSEGV] [Address not mapped to object] [0x000000000] [] []\nCurrent SQL statement for this session:\nBEGIN dbms_stats.copy_table_stats(ownname => 'TESTUSER', tabname => 'TEST_TAB1', \n                      srcpartname => 'P_20100209_OTHERS', dstpartname => 'P_20100211_OTHERS'); END;\n----- PL\/SQL Call Stack -----\n\u00a0 object\u00a0\u00a0\u00a0\u00a0\u00a0 line\u00a0 object\n\u00a0 handle\u00a0\u00a0\u00a0 number\u00a0 name\n0xa0625b88\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 830\u00a0 package body SYS.DBMS_STATS\n0xa0625b88\u00a0\u00a0\u00a0\u00a0 18292\u00a0 package body SYS.DBMS_STATS\n0x97cbbe60\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1\u00a0 anonymous block \n----- Call Stack Trace -----\ncalling\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 entry\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 argument values in hex\u00a0\u00a0\u00a0\u00a0\u00a0 \nlocation\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 type\u00a0\u00a0\u00a0\u00a0 point\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 (? means dubious value)\n-------------------- -------- -------------------- ----------------------------\nksedst()+31\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 ksedst1()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 000000001 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2B3BC0FACD50 ? 2B3BC0FACDB0 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2B3BC0FACCF0 ? 000000000 ?\nksedmp()+610\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 ksedst()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 000000001 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2B3BC0FACD50 ? 2B3BC0FACDB0 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2B3BC0FACCF0 ? 000000000 ?\nssexhd()+629\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 ksedmp()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000003 ? 000000001 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2B3BC0FACD50 ? 2B3BC0FACDB0 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2B3BC0FACCF0 ? 000000000 ?\n__restore_rt()+0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 ssexhd()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 00000000B ? 2B3BC0FADD70 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2B3BC0FADC40 ? 2B3BC0FACDB0 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2B3BC0FACCF0 ? 000000000 ?\nqospMinMaxPartCol()\u00a0 signal\u00a0\u00a0 __restore_rt()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0068986E0 ? 000000000 ?\n+3135\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000001 ? 000000000 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 0000000C2 ?\nspefcmpa()+687\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 qospMinMaxPartCol()\u00a0 7FFF31FFEDA0 ? 2B3BC13AABB0 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 2B3BC13AAB70 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 2B3BC13AAB30 ?\nspefmccallstd()+218\u00a0 call\u00a0\u00a0\u00a0\u00a0 spefcmpa()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2B3BC13AAA90 ? 2B3BC13AAAE0 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2B3BC129E500 ? 2B3BC13AAB70 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 2B3BC13AAB30 ?\npextproc()+41\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 spefmccallstd()\u00a0\u00a0\u00a0\u00a0\u00a0 7FFF31FFEE00 ? 7FFF31FFEA80 ?\n<\/pre>\n
An ORA-07445 error in qospMinMaxPartCol. I tried to find some references to this but haven’t been successful so far so I’m not sure whether this is a new bug or not. I was hoping it would be fixed in 10.2.0.5 but it doesn’t appear so.<\/p>\n
Installed Top-level Products (3): \n\nOracle Database 10g\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.2.0.1.0\nOracle Database 10g Release 2 Patch Set 3\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.2.0.4.0\nOracle Database 10g Release 2 Patch Set 4\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.2.0.5.0\nThere are 3 products installed in this Oracle Home.\n\n\nThere are no Interim patches installed in this Oracle Home.\n<\/pre>\n
The test script leads to the same error. In fact, all of the example output was generate from 10.2.0.5, but I’ve recreated the same results on 10.2.0.4 many times now.<\/p>\n
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x0, \n                      PC: [0x1abfe92, qospMinMaxPartCol()+3210]\n*** 2010-05-02 13:56:33.603\nksedmp: internal or fatal error\nORA-07445: exception encountered: core dump [qospMinMaxPartCol()+3210] \n                     [SIGSEGV] [Address not mapped to object] [0x000000000] [] []\nCurrent SQL statement for this session:\nBEGIN dbms_stats.copy_table_stats(ownname => 'TESTUSER', tabname => 'TEST_TAB1', \n                     srcpartname => 'P_20100206_OTHERS', dstpartname => 'P_20100212_OTHERS'); END;\n----- PL\/SQL Call Stack -----\n\u00a0 object\u00a0\u00a0\u00a0\u00a0\u00a0 line\u00a0 object\n\u00a0 handle\u00a0\u00a0\u00a0 number\u00a0 name\n0xa07618e8\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 838\u00a0 package body SYS.DBMS_STATS\n0xa07618e8\u00a0\u00a0\u00a0\u00a0 19131\u00a0 package body SYS.DBMS_STATS\n0xa02394b8\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1\u00a0 anonymous block\n----- Call Stack Trace -----\ncalling\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 entry\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 argument values in hex\nlocation\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 type\u00a0\u00a0\u00a0\u00a0 point\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 (? means dubious value)\n-------------------- -------- -------------------- ----------------------------\nksedst()+31\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 ksedst1()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 000000001 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2BA713361D50 ? 2BA713361DB0 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2BA713361CF0 ? 000000000 ?\nksedmp()+610\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 ksedst()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 000000001 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2BA713361D50 ? 2BA713361DB0 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2BA713361CF0 ? 000000000 ?\nssexhd()+629\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 ksedmp()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000003 ? 000000001 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2BA713361D50 ? 2BA713361DB0 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2BA713361CF0 ? 000000000 ?\n__restore_rt()+0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 ssexhd()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 00000000B ? 2BA713362D70 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2BA713362C40 ? 2BA713361DB0 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2BA713361CF0 ? 000000000 ?\nqospMinMaxPartCol()\u00a0 signal\u00a0\u00a0 __restore_rt()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 006AE9A20 ? 000000000 ?\n+3210\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000001 ? 000000000 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 0000000C2 ?\nspefcmpa()+809\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 qospMinMaxPartCol()\u00a0 7FFFDBEA5280 ? 2BA71361F008 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 2BA71361EFC8 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 2BA71361EF88 ?\nspefmccallstd()+122\u00a0 call\u00a0\u00a0\u00a0\u00a0 spefcmpa()\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2BA71361EEE8 ? 2BA71361EF38 ?\n8\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2BA7135EE500 ? 2BA71361EFC8 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 2BA71361EF88 ?\npextproc()+41\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 call\u00a0\u00a0\u00a0\u00a0 spefmccallstd()\u00a0\u00a0\u00a0\u00a0\u00a0 7FFFDBEA52E0 ? 7FFFDBEA4F68 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 7FFFDBEA4D10 ? 7FFFDBEA4C78 ?\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 000000000 ? 2BA71361EF88 ?\n<\/pre>\n
There is a workaround, of course, which is to copy stats at the Partition-level after all of the Subpartitions have been populated and I’ve shown that at the end of the test script, but the problem with that is that we could have quite a long lag before the stats are copied, because it appears that copying up-front before the data appears (which would seem sensible) doesn’t work too well, based on part 6a.<\/p>\n
I’ve probably added to any confusion again, rather than reducing it, but I’ll leave you with two main messages<\/p>\n
1) You’re going to encounter some bugs because some of these features are new, so you need to work hard identifying them, applying the appropriate patches and, preferably, being on later releases in the first place.<\/p>\n
2) Things are probably much more straightforward if you stick to Table and Partition-level stats, but that’s not a luxury I have on my current system.<\/p>\n","protected":false},"excerpt":{"rendered":"
I wanted to talk about a few of the bugs and patches you need to be aware of if you plan to use DBMS_STATS.COPY_TABLE_STATS. Believe me, when entering the world of stats on (sub-)partitioned objects, you had better be prepared to spend a lot of time on My Oracle Support and a little time applying… Continue reading Statistics on Partitioned Tables – Part 6c – COPY_TABLE_STATS – Bugs and Patches<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1597","post","type-post","status-publish","format-standard","hentry","category-uncategorized","entry"],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":1601,"url":"http:\/\/orcldoug.com\/blog\/2010\/05\/01\/10-2-0-5\/","url_meta":{"origin":1597,"position":0},"title":"10.2.0.5","date":"May 1, 2010","format":false,"excerpt":"If I didn't laugh, I'd cry. Mid-way through a series of posts, the next one of which I plan to talk about some of the myriad bugs and related patches for DBMS_STATS in 10.2.0.4, I discovered via several blogs that the 10.2.0.5 patchset for Linux x86-64 has been released \ud83d\ude09","rel":"","context":"With 2 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1590,"url":"http:\/\/orcldoug.com\/blog\/2010\/03\/28\/statistics-on-partitioned-tables-contents\/","url_meta":{"origin":1597,"position":1},"title":"Statistics on Partitioned Tables – Contents","date":"March 28, 2010","format":false,"excerpt":"When Jonathan Lewis decided it was time to post a list of the Partition Stats posts on his blog and Noons suggested I made them easier to track down, I listened. So this post will link to the others and, at least in the short term, I've also included links\u2026","rel":"","context":"Similar post","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1562,"url":"http:\/\/orcldoug.com\/blog\/2010\/02\/17\/statistics-on-partitioned-tables-part-1\/","url_meta":{"origin":1597,"position":2},"title":"Statistics on Partitioned Tables – Part 1","date":"February 17, 2010","format":false,"excerpt":"If you've ever worked on large databases that use partitioned and subpartitioned tables, you'll be aware that there are significant challenges in maintaining up-to-date\/appropriate statistics. We've encountered a few problems at work recently and I decided it would be an idea to put together a series of posts covering the\u2026","rel":"","context":"With 11 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1385,"url":"http:\/\/orcldoug.com\/blog\/2008\/02\/24\/10-2-0-4\/","url_meta":{"origin":1597,"position":3},"title":"10.2.0.4","date":"February 24, 2008","format":false,"excerpt":"Via Laurent Schneider's blog, it looks like 10.2.0.4 is out.I've just had a quick look on Metalink and unfortunately (but unsurprisingly) it doesn't seem to be available for AIX just yet, just Linux, but it's one we've been waiting for for a while, so it's good to see the first\u2026","rel":"","context":"With 5 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1407,"url":"http:\/\/orcldoug.com\/blog\/2008\/04\/30\/oug-scotland-dba-sig\/","url_meta":{"origin":1597,"position":4},"title":"OUG Scotland DBA SIG","date":"April 30, 2008","format":false,"excerpt":"An enjoyable day, but it flew by. Having not had much sleep last night through worrying about the first time I was giving this particular presentation, I'm glad I was able to present in the second slot of the day because I knew I'd be flagging later on. The most\u2026","rel":"","context":"With 2 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1330,"url":"http:\/\/orcldoug.com\/blog\/2007\/10\/27\/the-reality-gap-1-software-maintenance\/","url_meta":{"origin":1597,"position":5},"title":"The Reality Gap (1) – Software Maintenance","date":"October 27, 2007","format":false,"excerpt":"It's so long now since the OUG Scotland Conference and I ended up leaving early because I wasn't feeling too good so I'm not going to attempt a review of the day. I asked a few others what they thought afterwards and the general view was that the day was\u2026","rel":"","context":"With 28 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts\/1597","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"}],"author":[{"embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/comments?post=1597"}],"version-history":[{"count":0,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts\/1597\/revisions"}],"wp:attachment":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/media?parent=1597"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/categories?post=1597"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/tags?post=1597"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}