Welcome to the 68th edition of Log Buffer, the weekly review of database blogs.
Thanks to Paul and everyone else who contributed comments and links to LB#67 (a.k.a., the Log Buffer of Love) when I was down with the common cold. My rhinoviral guest has not abandoned me just yet , but I’m grimly determined to complete this nonetheless.
Let’s start with some SQL Server bits. SQLBits to be precise. SSQA’s External Links & References blog have kindly posted an entertaining podcast from the recent SQLBits day at MS UK in Reading, England. Maybe you wouldn’t think that an opportunity for a lot of laughs. But you’d be wrong.
Several blogs looked into the details of SQL Server 2008, “Katmai”. Bob Beauchemin writes about spatial data, a niche or a tool for the masses. “I’ll have to admit it, when I first saw that SQL Server 2008 was adding spatial data support, I thought of it as a niche. The province of geographers, cartographers, and maybe a few others.” However, he continues, “I’ll bet every app has a field that contains address. And how about looking for the nearest salesperson for a potential customer? Or the nearest warehouse?”
Kimberly L. Tripp offers a comparison of data compression in SQL Server 2005 and 2008, the trade-offs involved, and some further links.
Jeff Smith of Jeff’s SQL Server Blog exposes the lesser-known CROSS APPLY. “I think the easiest way to think of CROSS APPLY is that it is like doing a CROSS JOIN with a correlated sub-query instead of a derived table. Let’s see if I can explain that…” And you’ll just have to read Jeff’s thorough piece for the rest.
Here’s a post by Alex Kuznetsov on when it is OK to use SELECT * in production code: “If you google up ‘never use SELECT * in production code’ you will get many many hits. Clearly in many cases using SELECT * makes your code vulnerable to changes in underlying table(s) and as such should be avoided. Yet I don’t think the common rule of thumb ‘never use SELECT * in production code’ should be used without thinking, I don’t think it should be blindly applied in all the situations.” SimonS SQL Server Stuff follows up on that with his opinion on SELECT * and a lot of comments.
On SSIS Junkie, Jamie Thomson asks, Why datetime2?. “In SQL Server 2008 a new datatype will be introduced that can support storing of date values from the year 0001 to 9999. This new datatype is called datetime2… Why on earth have they called this new one datetime2? Surely bigdatetime would be more consistent.” The answer in the first comment may surprise you, but there’s disagreement there, too.
Oracle’s new thing, 11g, got its share of blog coverage too. First, a couple releases: Oracle 11g for Windows as Dan Norris mentions. Pythian’s Marc Fielding reported the release of Oracle 11g for 64-bit Linux.
Also here on the Pythian Group Blog, Mark Brinsmead asks, Oracle Configuration Manager: Bane or Blessing? “Customers are now required to download and install something called Oracle Configuration Manager (OCM), which will gather their system/database configuration information automatically, and forward it to Oracle Support on their behalf… Based on a cursory look and on a few conversations around the office, I gained the impression the OCM is little more than a sophisticated piece of spyware. ‘Services’ like Windows Genuine Advantage spring to mind… Does OCM represent some sort of Orwellian conspiracy, or is it an incredible blessing, unsought and unexpected?” Please help Mark make up his mind, he won’t stop talking about this.
Mogens Norgard of We Do Not Use Blogs covers the inception of “MEEP”, the Miracle Extreme Education Program. “We’re legacy. No new folks entering our fields. We secretly wish our children don’t copy us. Universities are not teaching anything about databases anymore – they teach the fresh-faced, blue-eyed ones to create ‘database-agnostic’ applications. So we’ve decided to try and build some new database experts via MEEP.” It’s a sort of intense database basic-training, and a worthwhile initiative, I’d say.
On Igor’s Oracle Lab, Gary Myers writes: “There’s not much blogging about Teradata. I can’t even recall a mention in Pythian’s Log Buffer.” No longer, true, Gary! (Showed him!) The piece is “An Oracle coder in a Teradata world”, and it compares the two systems, particularly their implementations of SQL itself.
An piece on Jonathan Lewis’s Oracle Scratchpad discusses the performance of solid-state disc in Oracle. “Sometimes you think that SSD (solid state disk) is bound to speed up Oracle performance. But it’s surprising how wrong you can be – it’s not guaranteed to give you great performance.” This one has a lot of informed comments.
Are these Oracle DBAs also great fans of MySQL? That what a study conducted by IOUG (and sponsored by MySQL AB) suggests, as reported in Matt Asay’s The Open Road, which says they’re “going ga-ga over MySQL”. Matt writes: “(Lame) Express Editions can’t stop MySQL, PostgreSQL, and other open-source databases. Why? Because they only tackle one (albeit a prominent) factor in open-source database adoption: cost.”
The OpenForce.com also covered this story, including a couple charts from the report, for those of you who want the shorthand version.
Google are big fans at least, and that must be a powerful endorsement. And as reported in Slashdot, they are planning to return some of their custom code to MySQL.
In other MySQL news, Xaprb asks, how fast is MySQL replication, investigates, and provides answers: “Very fast, as it turns out… While writing the chapter on replication for the upcoming second edition of High Performance MySQL, I decided to do a little test and measure replication speed more accurately than I’ve seen others do before… Giuseppe Maxia … found events typically replicated within a half a millisecond.”
Sheeri Kritzer, the MySQL She-BA, has a quick question: does anyone have any ways they create an API for their stored routines (functions and procedures)? She also has some concerns about how “kill” behaves with MySQL processes.
Neil Conway, on his Avogato blog does likewise, with some links to related resources.
Merlin Moncure submits a handy tip for improving the psql shell with GNU’s “less” program.
Last, a little post from Don Seiler to remind DBAs everywhere of their importance, prompted by his inquisitive nephew.
That’s all, and thanks for waiting. Log Buffer always needs more editors, so please take a look at the Log Buffer homepage and the guidelines and send me a note. Please. I’m not going to beg, at least not in LB itself. I’ll beg via email.
Until next time!
One Response to “Log Buffer #68: A Carnival of the Vanities for DBAs”
Leave a Reply