It’s the 84th blog-tacular edition of Log Buffer, the weekly review of database blogs!
We begin with some Oracle security news. A tutorial of Oracle’s on defending against SQL injection attacks gets a good review on Pete Finnigan’s Oracle security weblog. Pete writes, “This is a superb tutoral, well written and positioned just right. . . . [It] starts by explaining what SQL Injection is with some good flash examples and how to avoid SQL Injection. It includes first order and second order attacks and also discusses reducing the attack surface, removing API’s, use of invoker rights, reducing arbitary inputs and more. . . . This is a good document and one of the best security documents I have seen from Oracle.”
Systems Engineering and RDBMS reports on Sequence Enhancement in Oracle 11g: “Starting with Oracle 11g, we can use sequences with straight variable assignment. Before 11g, we always have to use SELECT INTO clause to get sequence value in the variable.” Examples provided.
Christian Bilien demonstrates that the “log file sync” wait event is not always spent waiting for an I/O, it may be trying to get some CPU attention.
Cary Millsap has the first part of the tale of how OFA (Oracle Flexible Architecture) began. It comes from him, and it started like this: “So I created myself a standard.” Marco Gralike responds with his own story about OFA and other standards, such as SAME.
On Preferisco, Nigel Thomas rounds up some recent posts on schema version control and offers his own perspective. “Code control is a walk in the park compared to ‘schema control’. . . And ‘data control’ adds even more challenges.”
Nigel missed one post, though — Sheeri Cabral’s item on source controlling the database schema here on Pythian’s blog. Sheeri (a.k.a., the MySQL SheBA) also finally caves, and tells why Postgres is superior to MySQL. (While saying “Uncle!”, I assume.)
Reaching back a little into last week, MySQL AB’s (can I still call them that?) Jay Pipes had something to say about the sunny future the two prominent OSS DBMSs. Jay writes, “There were very few in the MySQL community who saw the [acquisition of MySQL by Sun] as a bad thing â€” most opinions seemed to show a keen upside to having the resources at Sun available to improve MySQL. There were, however, a number of folks in the PostgreSQL community who openly fretted about whether the move signaled the demise of PostgreSQL support at Sun. . . . Let me explain why I see the reverse being true.”
Kaj Arno, also of MySQL, has this revealing post about part of what Sun is taking on: MySQL culture, featuring a list of what MySQL employees believe that is — for example, “Little ‘red tape'”, and “FUN FUN FUN”. And the “no-@sshole rule”.
Frank Mash links to a Sun Microsystems study on MySQL and Solaris in his post, Scaling the third most active Social Network with MySQL/InnoDB/Solaris, which also serves as a preview of Frank’s presentation at the MySQL Conference 2008.
MCslp Coalface’s Martin Brown links to an older item of Frank’s and covers some detail about MySQL on OpenSolaris.
Johan Andersson, a high-availability consultant for MySQL, offers an expert look into the features of MYSQL Cluster.
On High Availability MySQL, Mark Callaghan delves into the use of ANALYZE TABLE on transient tables.
Moving to SQL Server blogs, MaasSql looks at why views are evil: “Synopsis: Views are evil, bad, buggy, temperamental, tortuous, and should be avoided.” It’s a little less black-and-white than that, of course.
Joseph Sack has put together an example of how SET options impact the Query Optimizer index choice.
Evidence at hand suggests that SSIS may cause insanity and/or addiction. Perhaps severe headaches too. First case in point. Musings of an SSIS Madman has part-two of a series on their SSIS performance framework. Maybe not so much for newbies: “This is a medium intensity post (you should not get a migraine, but I make no promises).”
Next, Jamie Thomson, the SSIS Junkie, reports on case-sensitivity in the SSIS Lookup component. He writes, “[Jorg Klein] correctly observes that: A lookup transformation uses full caching by default. This means that the first thing it does on execution, is loading all the lookup data in its cache. When this is done it works as expected, but with case sensitivity.” A couple workarounds are on offer, as is the beginnings of a write-in feature campaign.
Peter Eisentraut has a little postcard from the Prague PostgreSQL Developers’ Day 2008. He also writes that is was perhaps the first (PostgreSQL?) conference with its custom wine. Peter has a pic of a wine bottle with a little blue elephant on it. Excellent vintage, the 8.3!
That’s all. As always, your Log Buffer coordinator’s exhortation to get involved: submit your favourite blog items, or publish an edition yourself and make friends with a world of DB bloggers. Just send me an email to get started.
Until next time!
Leave a Reply