Doug's Oracle Blog

The members of the Oak Table Network had long bemoaned the slightly tired look of the old oaktable.net website. James Morle put a lot of spare-time effort into running this for years now but it really needed some attention in terms of the content and presentation.

<joke>

But, as all discussions about the website seemed to take place over whisky, beer or wine ... nothing much seemed to happen!

</joke>

Actually, what happened was that a small team of volunteers got together and got to work, each with their own responsibilities. As far as I know, that team consisted of Kurt the Dude guy, Marco Gralike of Amis and James. Apologies if I've forgotten someone or over-emphasise Koert's role in doing the majority of the Drupal work, but the new site is a joy to behold, relative to the old one, and as it includes Twitter and blog feeds, I think it'll be a more useful daily resource.

Thanks, guys - great job! (Although I'm not suprised ....)

If anyone has any feedback, we're all ears.

Sigh ... these posts have become a bit of a mess.

There are so many different bits and pieces I want to illustrate and I've been trying to squeeze them in around normal work. Worse still, because I keep leaving them then coming back to them and re-running tests it's easy to lose track of where I was, despite using more or less the same test scripts each time (any new scripts tend to be sections of the main test script). I suspect my decision to only pull out the more interesting parts of the output has contributed to the difficulties too, but with around 18.5 thousand lines of output, I decided that was more or less essential.

It has got so bad that I noticed the other day that there were a couple of significant errors in the last post which are easy to miss when you're looking at detailed output and must be even less obvious if you're looking at it for the first time.

The fact no-one said much about these errors reinforces my argument with several bloggers that less people read and truly absorb the more technical stuff than they think. They just pick up the messages they need and take more on trust than you might imagine!

So what were the errors? Possibly more important, why did they appear? The mistakes are often as instructive as the successes.

Error 1

This is the tail-end of the subpartition stats at the end of part 5

SQL> select  table_name, subpartition_name, global_stats, last_analyzed, num_rows
  2  from dba_tab_subpartitions
  3  where table_name='TEST_TAB1'
  4  and table_owner='TESTUSER'
  5  order by 1, 2, 4 desc nulls last;

TABLE_NAME                     SUBPARTITION_NAME              GLO LAST_ANALYZED          NUM_ROWS
------------------------------ ------------------------------ --- -------------------- ----------
<<snipped>>                                              
 
TEST_TAB1                      P_20100209_GROT                NO  28-FEB-2010 21:41:47          3
TEST_TAB1                      P_20100209_HALO                NO  28-FEB-2010 21:41:49          3
TEST_TAB1                      P_20100209_JUNE                NO  28-FEB-2010 21:41:49          3
TEST_TAB1                      P_20100209_OTHERS              NO  28-FEB-2010 21:41:50          3

Compared to the supposedly same section produced at the start of part 6a :-

TABLE_NAME                     SUBPARTITION_NAME              GLO LAST_ANALYZED          NUM_ROWS           
------------------------------ ------------------------------ --- -------------------- ----------           
<<snipped>>                                              

TEST_TAB1                      P_20100209_GROT                YES 28-MAR-2010 15:38:32          3           
TEST_TAB1                      P_20100209_HALO                YES 28-MAR-2010 15:38:32          3           
TEST_TAB1                      P_20100209_JUNE                YES 28-MAR-2010 15:38:32          3           
TEST_TAB1                      P_20100209_OTHERS              YES 28-MAR-2010 15:38:33          3           

Spot the difference? Forget the timestamps for now, although I hope it's clear that :-

- The stats were gathered at different times
- I really need to get my blogging act together

Instead, notice that GLOBAL_STATS is set to NO in part 5 and YES in part 6a. How could that happen?

The first thing to note is that it's probably not as significant as it first appears because what does it mean for Subpartition stats to be Global when there are no underlying sub-components of a Subpartition? In fact I'd argue that all Subpartition stats are Global by implication but I may be missing something important. (Comments welcome ...)

Instead I'll focus on how you can manage to get the two different results. The output from part 5 was the result of gathering statistics on a load table (LOAD_TAB1) and then exchanging it with the relevant subpartition of TEST_TAB1 (as shown in part 5). When you do that, the GLOBAL_STATS flag will be set to NO.

If I take the alternate approach of exchanging LOAD_TAB1 with the subpartition of TEST_TAB1 and only then gathering statistics on the subpartition of TEST_TAB1 then GLOBAL_STATS will be YES for that subpartition. That's the most obvious reason I can think of for the discrepancy but I can't be certain because the log files that I took the output from are history now.

At some point when ripping parts of a master script to run in isolation for each blog post I've changed the stats gathering approach from gather-then-exchange to exchange-then-gather. The output shown in part 5 was correct so I've updated part 6a to reflect that and added a note.

Error 2

I think this one is worse, because it's down to me mixing up some pastes because the original results looked wrong when they were, in fact right. It's extremely rare for me to edit results and I regret doing it here. Whenever you start tampering with the evidence, you're asking for trouble!

When I'd been pasting in the final example output, showing that subpartition stats had been copied for the new P_20100210_GROT subpartition, I saw another example when the subpartition stats hadn't been copied, so I decided I was mistaken and fixed the post. But the original was correct so I've put it back the way it should be and added a further note.

If you weren't confused already, you have my permission to be utterly confused now

Summary

On a more serious note, let's recap what I'm trying to do here and what does and doesn't work.

I've added a new partition for the 20100210 reporting date and I tried to copy the partition and subpartition stats from the previous partition (P_20100209) to the new partition. I attempted a Partition-level copy

SQL> exec dbms_stats.copy_table_stats(ownname => 'TESTUSER', tabname => 'TEST_TAB1', 
                                      srcpartname => 'P_20100209', dstpartname => 'P_20100210');

PL/SQL procedure successfully completed.

in the expectation that DBMS_STATS would copy the partition stats as well as all of the subpartition stats from the P_20100209 partition. I'll repeat how the stats looked here ...

SQL> select  table_name, global_stats, last_analyzed, num_rows
  2  from dba_tables
  3  where table_name='TEST_TAB1'
  4  and owner='TESTUSER'
  5  order by 1, 2, 4 desc nulls last;

TABLE_NAME                     GLO LAST_ANALYZED          NUM_ROWS                                       
------------------------------ --- -------------------- ----------                                       
TEST_TAB1                      NO                                                                        

SQL>
SQL> select  table_name, partition_name, global_stats, last_analyzed, num_rows
  2  from dba_tab_partitions
  3  where table_name='TEST_TAB1'
  4  and table_owner='TESTUSER'
  5  order by 1, 2, 4 desc nulls last;

TABLE_NAME                     PARTITION_NAME                 GLO LAST_ANALYZED          NUM_ROWS        
------------------------------ ------------------------------ --- -------------------- ----------        
TEST_TAB1                      P_20100131                     NO                                         
TEST_TAB1                      P_20100201                     NO                                         
TEST_TAB1                      P_20100202                     NO                                         
TEST_TAB1                      P_20100203                     NO                                         
TEST_TAB1                      P_20100204                     NO                                         
TEST_TAB1                      P_20100205                     NO                                         
TEST_TAB1                      P_20100206                     NO                                         
TEST_TAB1                      P_20100207                     NO                                         
TEST_TAB1                      P_20100209                     NO  28-MAR-2010 15:38:38         12        
TEST_TAB1                      P_20100210                     NO                                         

10 rows selected.

SQL> select  table_name, subpartition_name, global_stats, last_analyzed, num_rows
  2  from dba_tab_subpartitions
  3  where table_name='TEST_TAB1'
  4  and table_owner='TESTUSER'
  5  order by 1, 2, 4 desc nulls last;

TABLE_NAME                     SUBPARTITION_NAME              GLO LAST_ANALYZED          NUM_ROWS        
------------------------------ ------------------------------ --- -------------------- ----------        
TEST_TAB1                      P_20100131_GROT                NO                                         
TEST_TAB1                      P_20100131_HALO                NO                                         

<<snipped>>

TEST_TAB1                      P_20100209_GROT                NO  28-MAR-2010 15:38:32          3        
TEST_TAB1                      P_20100209_HALO                NO  28-MAR-2010 15:38:32          3        
TEST_TAB1                      P_20100209_JUNE                NO  28-MAR-2010 15:38:32          3        
TEST_TAB1                      P_20100209_OTHERS              NO  28-MAR-2010 15:38:33          3        
TEST_TAB1                      P_20100210_GROT                NO  28-MAR-2010 15:38:33          3    
TEST_TAB1                      P_20100210_HALO                NO                                         
TEST_TAB1                      P_20100210_JUNE                NO                                         
TEST_TAB1                      P_20100210_OTHERS              NO                                         

40 rows selected.

So here's where we are

- No sign of partition statistics for P_20100210, despite the P_20100209 'source' partition having valid stats.
- The subpartition stats have been copied from P_20100209_GROT to P_20100210_GROT.
- The subpartition stats have not been copied for the other three P_20100210 partitions.

Weird, right? I've checked this over and over and I'm pretty sure I'm right, but decided to upload the entire script and output here in case others can spot some mistake I'm making.

Updated on 07/05/2010 - Yes, it is weird. It also happens to be nothing to do with DBMS_STATS.COPY_TABLE_STATS. This post explains why this really happened.

Getting back down to earth, though, this isn't the end of the world. It just means that for our particular stats collection strategy of loading data into load tables, exchanging them with subpartitions and then copying earlier stats, we just need to make sure we're working at the subpartition level all the time and that's what I'll look at next.

Finally, I'll re-emphasise that this is not the only strategy and it's fair to say it's flushing out some unusual effects that you might never see if you work primarily with Table and Partition-level stats!

[Phew. At last. The first draft of this was dated more than two weeks ago .... One of the problems with blogging about copying stats was the balance between explaining it and pointing out some of the problems I've encountered. So I've broken up this post, with a little explanation first ...]

Oracle have a lot of on-site consultants, designers and developers who are out working with customers on very large databases and they no doubt have their own internal systems too, so you shouldn't make the mistake of thinking they're unaware of the problems that people face in gathering accurate and timely statistics on large partitioned tables. I don't say that based on any inside knowledge but by

• Attending conferences, listening to presentations, reading White Papers and blog posts; and
• Because they are constantly introducing new features to try to address the issues.

Over the next few posts, I'll look at some of those new features, some of which appear more successful than others. First of all, copying statistics using DBMS_STATS.COPY_TABLE_STATS.

Copying stats is a variation of a technique I've seen used on a couple of Oracle Data Warehouse projects in the past where we decided that spending time and system resources gathering object statistics wasn't useful. Think about some of the problems you'll face when gathering stats on large partitioned objects that I've highlighted so far :-

• It takes time.
  
  
• It sucks system resources.
  
  
• As you change your strategy and the parameters to reduce the resource and time consumption, the stats are likely to be less accurate.

Then consider why we're gathering these stats in the first place :-

• To describe database objects and data to the optimiser by setting values in the data dictionary (e.g. Number of Rows, Number of Distinct Values, etc.)
  
  
• To help the optimiser identify the optimal execution plan

If we know the precise contents of specific objects at all times (unlikely, but bear with me), why bother trawling through the database examining the contents when we could just set the relevant values in the data dictionary manually? DBMS_STATS has several procedures that can help you achieve that, for example GET_COLUMN_STATS, SET_COLUMN_STATS, SET_TABLE_STATS etc.

We could set the stats for specific tables, indexes or partitions manually and then choose not to gather stats for those objects. As I said, you really need to know your data for this to work, although I would suggest that it's not as important that the stats are absolutely precise as that they are an accurate enough description of the data to lead to optimal plans.

There are a couple of cases where this might prove particularly useful.

• You add a new partition each month and so the partition starts out empty and fills up gradually over the course of the month. If you think about it, this is likely to lead to fluctuating execution plans as the contents of the partition change. That's what a cost-based optimiser does - calculates new plans based on changing data distribution - but it also implies plan instability and you might want to avoid that if possible. By setting stats manually you can 'pretend' that you start off with a full partition and have the optimiser evaluate plans based on that fixed assumption.
  
  
• You add new partitions very frequently and have very little time to gather statistics before users are likely to report against the data. It might prove useful to set some approximate synthetic stats quickly to get reasonable plans and then gather more detailed stats later when time allows.

The latter is similar to the situation we're faced with on the system I'm working on at the moment, so we were very keen to investigate copying stats as a means to reduce the stats gathering workload and improve the stats quality into the bargain.

COPY_TABLE_STATS when used on partitioned tables is designed to achieve a similar effect to setting stats manually at a similarly low cost but with a little more intelligence. For example, if we are adding a new partition for each new REPORTING_DATE on our example table, maybe it's reasonable to assume that the data volumes and distribution of values is similar to the previous REPORTING_DATE? If so, why not avoid setting fixed stats based on fixed assumptions about the contents of a partition, but copy the stats from a previous partition to the new partition?

Here is a very basic example of how this might look, based on my example table.

At the end of Part 5, the stats on TEST_TAB1 looked like this (column stats excluded to simplify things). Important Note - the bold text in this output has been edited to correct an earlier error in this post. See part 6b for explanation.

SQL> select  table_name, global_stats, last_analyzed, num_rows
  2  from dba_tables
  3  where table_name='TEST_TAB1'
  4  and owner='TESTUSER'
  5  order by 1, 2, 4 desc nulls last;

TABLE_NAME                     GLO LAST_ANALYZED          NUM_ROWS                                           
------------------------------ --- -------------------- ----------                                          
TEST_TAB1                      NO                                                                           

SQL> select  table_name, partition_name, global_stats, last_analyzed, num_rows
  2  from dba_tab_partitions
  3  where table_name='TEST_TAB1'
  4  and table_owner='TESTUSER'
  5  order by 1, 2, 4 desc nulls last;

TABLE_NAME                     PARTITION_NAME                 GLO LAST_ANALYZED          NUM_ROWS           
------------------------------ ------------------------------ --- -------------------- ----------           
TEST_TAB1                      P_20100131                     NO                                            
TEST_TAB1                      P_20100201                     NO                                            
TEST_TAB1                      P_20100202                     NO                                            
TEST_TAB1                      P_20100203                     NO                                            
TEST_TAB1                      P_20100204                     NO                                            
TEST_TAB1                      P_20100205                     NO                                            
TEST_TAB1                      P_20100206                     NO                                            
TEST_TAB1                      P_20100207                     NO                                            
TEST_TAB1                      P_20100209                     NO  28-MAR-2010 15:38:33         12           

9 rows selected.

SQL> select  table_name, subpartition_name, global_stats, last_analyzed, num_rows
  2  from dba_tab_subpartitions
  3  where table_name='TEST_TAB1'
  4  and table_owner='TESTUSER'
  5  order by 1, 2, 4 desc nulls last;

TABLE_NAME                     SUBPARTITION_NAME              GLO LAST_ANALYZED          NUM_ROWS           
------------------------------ ------------------------------ --- -------------------- ----------           
TEST_TAB1                      P_20100131_GROT                NO                                            
TEST_TAB1                      P_20100131_HALO                NO                                            
TEST_TAB1                      P_20100131_JUNE                NO                                            
TEST_TAB1                      P_20100131_OTHERS              NO                      

<<snipped>>                                              
 
TEST_TAB1                  P_20100209_GROT            NO  28-MAR-2010 15:38:32      3           
TEST_TAB1                  P_20100209_HALO            NO  28-MAR-2010 15:38:32      3           
TEST_TAB1                  P_20100209_JUNE            NO  28-MAR-2010 15:38:32      3           
TEST_TAB1                  P_20100209_OTHERS          NO  28-MAR-2010 15:38:33      3           

36 rows selected.

Next I'm going to add a new partition (and by implication, the related subpartitions) to contain rows with a REPORTING_DATE of 20100210, then empty LOAD_TAB1 and insert some appropriate rows into it.

SQL> ALTER TABLE TEST_TAB1
  2  ADD  PARTITION P_20100210 VALUES LESS THAN (20100211);

Table altered.

SQL> TRUNCATE TABLE LOAD_TAB1;

Table truncated.

SQL> INSERT INTO LOAD_TAB1 VALUES (20100210, 'GROT', 1000, 'P');

1 row created.

SQL> INSERT INTO LOAD_TAB1 VALUES (20100210, 'GROT', 30000, 'P');

1 row created.

SQL> INSERT INTO LOAD_TAB1 VALUES (20100210, 'GROT', 2000, 'P');

1 row created.

SQL> INSERT INTO LOAD_TAB1 VALUES (20100210, 'GROT', 10000, 'N');

1 row created.

SQL> INSERT INTO LOAD_TAB1 VALUES (20100210, 'GROT', 2400, 'P');

1 row created.

SQL> INSERT INTO LOAD_TAB1 VALUES (20100210, 'GROT', 500, 'P');

1 row created.

SQL> INSERT INTO LOAD_TAB1 VALUES (20100210, 'GROT', 1200, 'P');

1 row created.

SQL> INSERT INTO LOAD_TAB1 VALUES (20100210, 'GROT', 400, 'P');

1 row created.

SQL> INSERT INTO LOAD_TAB1 VALUES (20100210, 'GROT', 600, 'P');

1 row created.

SQL> INSERT INTO LOAD_TAB1 VALUES (20100210, 'GROT', 700, 'Z');

1 row created.

SQL> COMMIT;

Commit complete.

There are 10 rows that will be loaded into the new partition, all with a SOURCE_SYSTEM of GROT, so all will be added to that subpartition. Now I'll use partition exchange to move the data in LOAD_TAB1 into the P_20100210_GROT subpartition.

SQL> ALTER TABLE test_tab1 EXCHANGE SUBPARTITION P_20100210_GROT WITH TABLE load_tab1;

Table altered.

SQL> ALTER TABLE test_tab1 MODIFY SUBPARTITION  P_20100210_GROT REBUILD UNUSABLE LOCAL INDEXES;

Table altered.

Now to copy some stats. First I'll try copying the statistics from the previous partition (P_20100209) to the new partition. i.e. I am performing a Partition-level copy. Important Note - the bold text in this output has been edited to correct an earlier error in this post. See part 6b for explanation.

SQL> exec dbms_stats.copy_table_stats(ownname => 'TESTUSER', tabname => 'TEST_TAB1', srcpartname => 

'P_20100209', dstpartname => 'P_20100210');

PL/SQL procedure successfully completed.

Let's see what has been copied

SQL> select  table_name, global_stats, last_analyzed, num_rows
  2  from dba_tables
  3  where table_name='TEST_TAB1'
  4  and owner='TESTUSER'
  5  order by 1, 2, 4 desc nulls last;

TABLE_NAME                     GLO LAST_ANALYZED          NUM_ROWS                                       
------------------------------ --- -------------------- ----------                                       
TEST_TAB1                      NO                                                                        

SQL>
SQL> select  table_name, partition_name, global_stats, last_analyzed, num_rows
  2  from dba_tab_partitions
  3  where table_name='TEST_TAB1'
  4  and table_owner='TESTUSER'
  5  order by 1, 2, 4 desc nulls last;

TABLE_NAME                     PARTITION_NAME                 GLO LAST_ANALYZED          NUM_ROWS        
------------------------------ ------------------------------ --- -------------------- ----------        
TEST_TAB1                      P_20100131                     NO                                         
TEST_TAB1                      P_20100201                     NO                                         
TEST_TAB1                      P_20100202                     NO                                         
TEST_TAB1                      P_20100203                     NO                                         
TEST_TAB1                      P_20100204                     NO                                         
TEST_TAB1                      P_20100205                     NO                                         
TEST_TAB1                      P_20100206                     NO                                         
TEST_TAB1                      P_20100207                     NO                                         
TEST_TAB1                      P_20100209                     NO  28-MAR-2010 15:38:38         12        
TEST_TAB1                      P_20100210                     NO                                         

10 rows selected.

SQL> select  table_name, subpartition_name, global_stats, last_analyzed, num_rows
  2  from dba_tab_subpartitions
  3  where table_name='TEST_TAB1'
  4  and table_owner='TESTUSER'
  5  order by 1, 2, 4 desc nulls last;

TABLE_NAME                     SUBPARTITION_NAME              GLO LAST_ANALYZED          NUM_ROWS        
------------------------------ ------------------------------ --- -------------------- ----------        
TEST_TAB1                      P_20100131_GROT                NO                                         
TEST_TAB1                      P_20100131_HALO                NO                                         

<<snipped>>

TEST_TAB1                  P_20100209_GROT            NO  28-MAR-2010 15:38:32      3        
TEST_TAB1                  P_20100209_HALO            NO  28-MAR-2010 15:38:32      3        
TEST_TAB1                  P_20100209_JUNE            NO  28-MAR-2010 15:38:32      3        
TEST_TAB1                  P_20100209_OTHERS          NO  28-MAR-2010 15:38:33      3        
TEST_TAB1                  P_20100210_GROT            NO  28-MAR-2010 15:38:33      3    
TEST_TAB1                      P_20100210_HALO                NO                                         
TEST_TAB1                      P_20100210_JUNE                NO                                         
TEST_TAB1                      P_20100210_OTHERS              NO                                         

40 rows selected.

Mmmm, that's quite interesting. Although there were valid stats on all of the P_20100209 subpartitions, it looks like nothing was copied. It appears that in our situation, where we only gather stats on subpartitions and allow them to aggregate up to the partition and table levels, I need to copy the statistics subpartition-by-subpartition, which is what I'll start looking at in the next post.

Important Note - Please go on to read part 6b. An error on my part in the output I pasted above made it look like there no statistics copied at all. In fact, subpartition statistics for P_20100210_GROT were copied but it's still a confusing picture because I was using a Partition-level copy and yet there are no copied statistics for three of the subpartitions even though the source subpartitions had valid stats, nor for the partition itself.

Which means it's still true that the Partition-level copy will not serve our particular purposes, so next I'll try copying statistics at the individual subpartition level.

I've updated the date of this post so hopefully it will re-appear in aggregators for those who read it earlier.

The agenda for the Michigan Oak Table Symposium is online now and looking at it brings to mind a couple of pub discussions I've had lately with those who have never attended a conference and can't see the benefits as well as those who have thought about it and wondered what it's like. I reckon MOTS would be a great introduction to the best that conferences have to offer ...

Condensed technical learning format.

It's not a course.

Although I know that would be a big plus to many people I know who despair at spending 5 days out of the office for half a day's worth of new stuff they learn, I still think there's a place for courses, reading books and learning stuff properly rather than just trawling around Google or asking questions on Twitter and making it up as you go along. However, if you've already learnt some stuff properly, then a conference is a great way to pick up a few salient points that you might not come across otherwise and then dig around properly yourself when you get back home or to the office. The fact that this particular conference requires only two days of your time is a bonus (but I'll come back to that below ...)

Networking / Interaction

It might not be obvious these days, but in the past I could think of nothing worse than 'Networking', believe me! Friends would tell you I can still do a neat disappearing act But whether it's conversations at work, online, or at conferences, if you never discuss anything with like-minded people, how will your knowledge grow? Even attending presentations and deciding they weren't very good is an interesting experience and, should that happen to you, it might inspire you to participate to make things better! One thing's sure in my mind ... I never thought I'd say this, but participating has had a positive effect on me I couldn't imagine.

The great thing about MOTS, like Hotsos and the Miracle events, is that with 300 attendees, you're guaranteed lots of interaction with smart attendees and presenters.

Community

This one is extremely important to me at the moment. Someone said to me recently they could understand how conferences might work better for me because I know 'the crowd' or something similar. I've blogged plenty of times in the past about my aversion to elitism (wish I could be bothered digging out some links!) and it worries me that people might not want to 'join in' because there's some exclusive club with a bouncer at the door. So, let's get this straight.

There probably is a crowd of people who attend conferences and know each other. There's an Oak Table Network, the Oracle ACEs, the UKOUG and Hotsos hard-core massive, etc, etc, etc. However, every single one of those groups is populated by people who turned up at a conference the first time by themselves, mostly pretended they were wall-paper (I'm sure there are exceptions ) and gradually got to know a few faces, picked their own mates and bumped into them again the next time and had fun. It's been one of the surprises of my life that I've made a bunch of new, proper friends by attending a couple of conferences.

Current Information

Could you get this stuff via blogs? Yes, probably, but are you really taking the time to read all those posts, or are they tucked away to be read at a later date that never quite arrives? Anyone who has attended an external training event knows the value of getting away from the desk and the mail and the phone for a couple of days and just focussing on technical stuff. We are still working in a technical field, aren't we?

Oops! This turned into more of a rant than I planned So, what's my point?

The Early Registration rate is $450 which is £300 or 335 Euro. Let me see. How much do Oracle tend to charge for a 2-day course with yours truly? About 1500 Euro or something like that? (Tread carefully, Doug, you do want to work for Oracle University again! LOL) OK, you probably need to invest 3 days holiday on MOTS if you're travelling from outside the US and your employed won't spring for it but, why not give it a try? If you try it once and absolutely hate it, then fair enough, but I keep encouraging people to go to conferences, they go and then they have a great time and learn something too. They feel inspired again.

My point is ... just come along. It's 2 days of your life spent with a couple of hundred other people who are just like you. Actually, that's a lie. There might only be 6 people who are like you, but in that case, I bet you'd struggle to find even 6 somewhere else! LOL. Conferences are the real reason I know Kurt, Marco, Alex, Carol, Lisa, Graham, Jonathan ... (blah, blah, blah ... it could go on forever and I wish I hadn't started a list!)

Look - here's the registration link. Your call. I tried

Do you know what I'd really like next? I rarely beg for comments (which I find irritating) but to add weight to my possibly biased voice, if anyone who has attended a conference recently has found it better or worse than expected, maybe your voice would be more important than mine here?

P.S. At least it got me out of Part 6 of the Stats blogs (Although I know one or two people in the office who'll be looking for an apology, having been lead up the garden path on this one!)

P.P.S. Private message for Raj ... It's 2 days! It has a speaker list not dissimilar to Hotsos! You could fly on Wed night and still be back with your family on Friday night! We could have beer. I'm sure your employer would be amenable to this educational opportunity or I could create a fuss on your behalf! LOL

P.P.P.S. Yeah, I know ... Stats Part 6. Really, I know. It's coming ...

Thanks to Marco mentioning it on Twitter, I downloaded and installed 11gR2 for Windows from OTN this evening. The reason I had to switch to OEL on VMWare was because of the delay on the 11gR2 Windows release, but I'll give it a try and see which works best for me. Installation was certainly a breeze.