Pythian Group

It’s that time of the year again — Oracle OpenWorld time — and it’s my pleasure to announce our regular Oracle bloggers meetup again this year. We all know that Oracle community has grown this year so we expect to see folks from all the different technologies including MySQL, Java, Sun hardware folks in addition to the core Oracle database and apps crowd.

So… all of you Oracle bloggers attending Oracle Open World 2010…
… you are invited to attend this Oracle Bloggers Meetup during OOW 2010 — a chance to meet your online buddies face-to-face in relaxed and informal atmosphere.

When: Wed, 22-Sep-2010, 5:30pm

Where: Lower Dining Room, Jillian’s Billiards @ Metreon, 101 Fourth Street, San Francisco, CA 94103.
Read the rest of this entry . . .

Hello, and welcome to Log Buffer, a weekly blog about happenings in the database industry. Today is a celebration of the 200th edition of Log Buffer, and we’d like to give a special shout out to all of our guests hosts over the past 4 plus years. Their contributions have been invaluable in helping to grow Log Buffer into the community source of favorite database-related blog posts that it is today.

We’ve come a long way since our inaugural issue, Log Buffer #1, published July 14, 2006. This week enjoy mix of contributed links and the latest posts from past contributors.

Mart Rittman (Log Buffer #11) reminds everyone that OBIEE 11gR1 is available for download. His colleague, Venkatakrishnan J follows up with posts on a few new and important features including reporting on CLOBs – Lookups, map views – integration with Mapviewer, handling double columns – ID/description interoperability, lookup tables – sparse and dense lookups and vertical clustering.

Adam Machanic, of SQLblog.com and host of Log Buffer #21 is reflecting on 6 plus years of blogging in the database world, and wants to know who his readers are.

Lewis Cunningham (Log Buffer #32) notes that the call for abstracts is open for ODTUG/Kaleidoscope 2011. Submission deadline is October 26, 2010. He also talks about a problem with success and offers good advice to make sure you’re not getting “crusty”.

Coskan Gundgobar (Log Buffer #49) responds to a slow system waiting on library cache lock and credits Tanel Poder’s scripts as the solution.

Jeremy Schneider (Log Buffer #55) points out that DBCA is missing from the 11gR2 ASM/grid installation.

Hubert Depesz Lubaczewski (Log Buffer #57) writes about OMNIPITR – hot-backups on slave – they really work.

Edie Awad (Log Buffer #73) references 5 interesting posts in his Monday, August 16th roundup including working with long columns, and database performance for developers.

Robert Treat (Log Buffer #127) shares on his personal opinion on what people should do following the announcement that OpenSolaris is cancelled and is to be replaced with Solaris 11 Express.

Gary Myers (Log Buffer #181) has a little fun with passwords on Sydney Oracle Lab.

Kent Milligan suggests to process your DB2 for i indexes in parallel and thus improve the overall performance of your database server.

Steve Karam, the Oracle Alchemist reports strange behaviour with MEMORY_TARGET.

Chris Presley shares Paul White’s post on viewing another session’s temporary table.

While a few have fallen off the map, it’s nice to see many members of our database blogging community still going strong.

Welcome to Log Buffer. The weekly review of DBA industry news. Enjoy Log Buffer #199.

Remember if you find a link or interesting blog post that you think Log Buffer should mention, send a note to the editor at Log Buffer and be sure to include the link, and a short note outlining why you think that particular post would be of value to other DBAs, or what you learned from reading it.

And, for inquiries about hosting or editing a future edition of Log Buffer on your own blog, send your query to the Log Buffer coordinator. (Please include the words “Log Buffer” in the subject.)

Kicking off this week are posts recommended by Gwen Shapira who also took a few minutes to share her production advice for developers.
Read the rest of this entry . . .

Welcome to Log Buffer, a weekly review of the database industry. This week’s issue Log Buffer #198 is generously published by Sam DeFilippis, who manages Oracle Notes blogs, with latest postings on Oracle GoldenGate.

As always, if you’d like to host your own issue of Log Buffer, simply reach out to the Log Buffer coordinator.
Please enjoy Sam’s issue of Log Buffer #198.

If you’re attending Oracle OpenWorld 2010 in San Francisco, Sept. 19-23, 2010, be sure to stop by one of Pythian’s many sessions.

We’ll be all over the show, with experts Alex, and Marc speaking as listed below. Or, you might find Paul, Alex and others attending the bloggers meetup, participating in Oracle ACE/ACE Director activities, or at some of the User Group or OPN sessions on Sunday. Drop us a line on twitter @pythian while you’re at the show to connect with Pythian.
Read the rest of this entry . . .

Log Buffer #197 marks the middle of summer, and the fact that we’re a mere two weeks away from our 200th edition.

To begin this week’s reading, I’d like to highlight two Oracle blogs maintained by Sam J. DeFilippis: Oracle Notes, where he’s recently posted about troubleshooting GoldenGate and positioning a read of Extract/Replicat Trail file or Oracle redo log. Sam volunteered to host a future edition of Log Buffer (thanks, Sam!). You can too, by sending an email to the Log Buffer coordinator, we’re always looking for volunteer publishers.

Brad Hudson a points that PostgreSQL test servers have moved from Oracle to EnterpriseDB.
Read the rest of this entry . . .

Today marks my last day at Pythian. I have been at Pythian for almost three years. In those three years, Pythian’s already thriving MySQL practice has grown even more. I have worked with big and small clients alike, across many industries, managed a team of up to 4 DBAs, and learned a lot not just about MySQL, but what my goals are in general.

Though I am leaving, everything I said in the blog post I made when I announced I was coming to Pythian still holds true. Pythian is a challenging environment and one I would recommend to anyone who finds their current DBA environment boring that they should come to Pythian and experience what it is like to work here. I had lunch with Paul Vallee yesterday and we even discussed possible future collaborations (hence the title, a joke that I am “forking” off of Pythian).

So if it is so great, why am I leaving? It’s simple, really — Pythian is growing by leaps and bounds. I started when Pythian was about half the size it currently is. There is a lot of change happening within Pythian, and I believe it is very good change. However, I enjoyed the environment Pythian was when I started almost three years ago, and personally I am not ready to go with Pythian on the journey it is taking.

So where am I going next? For starters, I will take the month of August off paid work. I have an idea of where I might go for paid work in September, but you will have to watch Planet MySQL for the announcement. During August I will be doing some conference planning and organizing, for OpenSQLCamp in Boston in October first, and then for conferences in 2011. I will also be moving apartments, which is a big task. And I will be focusing on some personal goals, such as spending more time with my husband and becoming more active.

I am excited about having a month off, even though I have a lot to work on in that month.

At Kscope this year, I attended a half day in-depth session entitled Data Warehousing Performance Best Practices, given by Maria Colgan of Oracle. My impression, which was confirmed by folks in the Oracle world, is that she knows her way around the Oracle optimizer.

See part 1 for the introduction and talking about power and hardware. This part will go over the 2nd “P”, partitioning. Learning about Oracle’s partitioning has gotten me more interested in how MySQL’s partitioning works, and I do hope that MySQL partitioning will develop to the level that Oracle partitioning does, because Oracle’s partitioning looks very nice (then again, that’s why it costs so much I guess).
Read the rest of this entry . . .

At Kscope this year, I attended a half day in-depth session entitled Data Warehousing Performance Best Practices, given by Maria Colgan of Oracle. My impression, which was confirmed by folks in the Oracle world, is that she knows her way around the Oracle optimizer.

These are my notes from the session, which include comparisons of how Oracle works (which Maria gave) and how MySQL works (which I researched to figure out the difference, which is why this blog post took a month after the conference to write). Note that I am not an expert on data warehousing in either Oracle or MySQL, so these are more concepts to think about than hard-and-fast advice. In some places, I still have questions, and I am happy to have folks comment and contribute what they know.
Read the rest of this entry . . .

In October 2008, Baron posted How to Check MySQL Replication Integrity Continually. Here at Pythian we have developed a method based on that post, and added “verifying that masters and slaves are in sync” to our standard battery of tests.

We call it “Continual replication sync checking”. This article will explain how it works, how to test and make the procedure non-blocking, benchmarks from the real world, issues we encountered along the way, and finally Pythian’s procedure of setting up continual replication sync in a new environment.

At the 2010 MySQL User Conference & Expo, my co-worker Danil Zburivsky did a presentation about this, and you can get the slides in ODP (Open Office) format or watch the 46-minute video on YouTube.

How it works

On the master, mk-table-checksum is run. In order to make the checksum operation online, we use the modulo and offset features of mk-table-checksum to checksum only part of the data at a time. The checksum is run (from cron) on the master and replicates to the slave. The results are captured in a result table, and a separate process checks the result table and notifies us of any discrepancies.
Read the rest of this entry . . .