Before the fun begins...I want to express my sincerest THANK YOU to Dave Edwards and the rest of the people at The Pythian Group. They are a great bunch of folks and a class act all the way.
It's Friday the 13th...the traditional day of bad luck.
On the dark side, after discussions of SQL Injection by Tom Kyte and Pete Finnigan. Alex Kornbrust finds we learn our bad habits from some pretty reputable names. Tim DiChiaria has collected some amusingly sad, but true, security bloopers. To steal and mangle a rather famous saying "The most secure database is the one that does not exist." Syed's database is not haunted, but the days of ordered data without an ORDER BY are coming to an end. However, Laurent's database might be! And Alex's surely is! Kevin Closson searches for a missing alert log.
On to some good luck!
Niall Litchfield takes a look backward and forward...Let's bookmark this one to revisit in 10 years (Hey, Dave...I'll volunteer for that Log Buffer.. #578 I think). In the same vein, let's take a look back at an old post that we should look at every month (at least) where Joel Spolsky talks about 7 Steps to Remarkable Customer Service (we're all in Customer Service!). Looking forward, Bob Beauchemin illustrates new Join and Merge functionality in SQLServer 2008. Sheeri Kritzer blogs...audio style about De-myth-tifying Indexes (De-myth-tifying...I'll definitely be stealing that phrase!)
Peter Scott notes that datatype conversions can cause performance degradation. Jay Pipes pipes in with answers to common MySQL tuning questions (sorry, Jay, but I just could not resist the pun). On a very low level note, Howard Rogers illustrates performance improvements from aligning disks in Windows. Sergey Petrunia traces storage engine activity in MySQL to identify performance issues.
In the PostgreSQL world, PGDay (which was a 2 day event...must be that pesky exchange rate thing) was this past weekend. Josh Berkus, Stefan Kaltenbrunner, On the heels of PGDay, the first PostgreSQL benchmark was announced.
MySQL v. SqlServer...a comparison. On the heels of comparison, Kristian Koehntopp writes about Replication Now and Then. Sheeri Kritzer lists the community's Top 5 wishes and Peter Zaitsev asks "What's Next?" Opensource goes right to the source with 3 very interesting interviews.
Of course, the really, really big news of the week, Oracle 11g! Coskan has some of the highlights, Marko Gralike has the XMLDB Top 10, Kevin Closson ponders Fast or Secure?, Jeremy Schneider examines Data Compression in 11g, Doug Burns (with the rather handsome Randy assisting) looks at Total Recall, Jurgen continues the discussion with PL/SQL 11g CONTINUE feature , Mark Rittman looks at some of the new BI products. Of course, the real question from Tim Hall is "When will 11g actually be released?"
As the final bit of bad luck, I'll remind everyone of the Power of the Technical Myth, an Interesting Marketing scheme, the results of nagging a certain newbie to update her blog
Sliante! Prost! Salut! Skål! Na Zdrowie! L'Chaim! Cheers!
Daniel Fink
Friday, July 13, 2007
Thursday, July 05, 2007
The Power of Myths
There was a recent question on oracle-l.
" I have received a question from a consultant developer – below. Can anyone answer?
I was once told that the CBO can only handle a certain number of tables in a query (16 iirc). Do you know what the CBO does when there are more? Try to optimize based on knowledge of the first 16 tables in the Where clause?"
This is not the first time I have seen this particular "myth" mentioned in one form or another. It is not that this particular myth is impossible to disprove (create a 17 table join and run a 10053 trace on it), it is that I have never been able to locate any Oracle documentation stating what the maximum number of tables in a join is per release per platform...or for all releases/platforms for that matter. So, I can't answer "If you reference page 42 of the SQL guide you will find that they say there is no limit to the number of tables you can join."
Is it possible that no one has ever said or written "The Oracle CBO cannot handle more than 16 tables in a join.". It is likely, especially with early versions of the CBO that someone said "The CBO has difficulties with joins of more than 16 tables and they should be avoided." or "Bug 42 indicates that if 17 tables are joined, the last one is not considered within the join permutations."
It is very easy to answer "Well, show me where you read this.", but that will never dissuade the questioner from believing the myth. Documentation, papers and presentations are not preserved forever. They are lost in the mists of time (or shall I say "myths of time") when they are no longer useful. Unfortunately, the knowledge they imparted (whether right, wrong, misunderstood or never even there in the first place) will remain in someone's memory.
That's the problem with some of these myths...the believer cannot prove the assertion, nor can the guru skeptic readily disprove the assertion. That is the power of the myth.
" I have received a question from a consultant developer – below. Can anyone answer?
I was once told that the CBO can only handle a certain number of tables in a query (16 iirc). Do you know what the CBO does when there are more? Try to optimize based on knowledge of the first 16 tables in the Where clause?"
This is not the first time I have seen this particular "myth" mentioned in one form or another. It is not that this particular myth is impossible to disprove (create a 17 table join and run a 10053 trace on it), it is that I have never been able to locate any Oracle documentation stating what the maximum number of tables in a join is per release per platform...or for all releases/platforms for that matter. So, I can't answer "If you reference page 42 of the SQL guide you will find that they say there is no limit to the number of tables you can join."
Is it possible that no one has ever said or written "The Oracle CBO cannot handle more than 16 tables in a join.". It is likely, especially with early versions of the CBO that someone said "The CBO has difficulties with joins of more than 16 tables and they should be avoided." or "Bug 42 indicates that if 17 tables are joined, the last one is not considered within the join permutations."
It is very easy to answer "Well, show me where you read this.", but that will never dissuade the questioner from believing the myth. Documentation, papers and presentations are not preserved forever. They are lost in the mists of time (or shall I say "myths of time") when they are no longer useful. Unfortunately, the knowledge they imparted (whether right, wrong, misunderstood or never even there in the first place) will remain in someone's memory.
That's the problem with some of these myths...the believer cannot prove the assertion, nor can the guru skeptic readily disprove the assertion. That is the power of the myth.
Subscribe to:
Posts (Atom)
Followers