Pythian Group

Pythian is very excited to return to the much-awaited RMOUG 12 held in Denver, Colorado from February 14-16, 2012. Keep your eyes open for Alex Gorbachev, Marc Fielding, Don Seiler and Gwen Shapira in attendance. We have a fantastic line-up of speakers this year featuring a total of seven papers presented by Alex, Marc, Don and Gwen. If you have any feedback on our sessions, please send your comments directly to the speaker or to Vanessa Simmons, Pythian Director of Marketing. Please also follow this link to sign up to receive notice of future speaking engagements, webinars or Pythian news.

Be sure to stop by our booth (#3,6,7,10) to say hello to our friends from the OakTable Network, and enter our draw to win the new Amazon Kindle with software provided by Cary Millsap (MR-Trace, MR-Tools & Method-R Profiler) and a pack of digital e-book downloads courtesy of Apress. Also slated is the RAC Attack workshop, which was first offered at Oracle Open World and UKOUG, and is now in its second year at RMOUG. Pythian is co-sponsoring this event with Apress and it’s a fun and informative way to learn from our experts how and when to properly build a RAC environment.

Read the rest of this entry . . .

The 2012 edition of RMOUG Training Days in Denver less than a month away, running February 15 and 16 at the Colorado Convention Center in Denver. Although it’s only two days, there’s a lot of technical content there, and a refreshing reduction in marketing-oriented presentations from “product managers”. It’s not too late to register, and it’s a pretty nice excuse to get to the Rockies in ski season. I’ll be doing two presentations, and am polishing up whitepapers and presentations for the submission deadline tomorrow:

• Exadata I/O Resource Manager: Ideal Technology for Database Consolidation, Wednesday 1:15pm in room 4B
• Peering Through the Cloud: The Straight Goods on Oracle Exalogic, directly after, Wednesday 4pm in room 4C

They’re right after each other in the grid, but I do get a short break for the dedicated exhibit hall time and paid vendor presentations (yes there are still a few; they have to pay the bills somehow).
Read the rest of this entry . . .

Another December has started and you know what it means right? It’s the Christmas time? NO! It’s time for UKOUG Technology and e-Business Suite 2011 conference! There are not many things that can make a passionate Apps DBA more excited than that. UKOUG Tech & eBS conferences are the only ones in Europe that have such a rich content for Application DBAs and this year it will not be different. Read the rest of this entry . . .

My good friend (and personal hero) Cary Millsap is doing a series of one day classes around the world — Mastering Oracle Trace Data. One of them is conveniently scheduled in Birmingham Thursday next week right after the UKOUG Conference.
Read the rest of this entry . . .

Today I want to show what kind of IO performance we can get from Oracle Database Appliance (ODA). In this part, I will focus on hard disks. That’s right — those good old brown spinning disks.

I often use Oracle ORION tool to stress-test an IO subsystem and find it’s limits. It’s a very simple and handy tool and usually provide most of the IO simulation I need.

I usually benchmark for small random IOs and for large sequential reads. This gives me a good idea what I can expect from this IO subsystem for OLTP workloads as well as bulk data processing workloads including data warehousing, backups and batch activity. I usually don’t stress test mixed workload until I know what’s the profile of the application that I will run on this platform. In this particular case, I’m more after generic IO stress test and finding the limit.

Today, let’s talk about small random IOs which is the attribute of the OLTP workloads. I’m interested in single IO response time and IOs per second (IOPS).

When I stress test an IO subsystem I usually process average numbers but I always remember that averages are just that — averages. Because my artificial ORION workload is pretty randomly distributed and I use reasonably small intervals, the results have good confidence for me but in some cases I would want to dig further and collect some histograms of IO latencies. I haven’t done it for Oracle Database Appliance though and knowing what’s behind I expect response time to be quite consistent – there is no disk cache or something similar that skews response time.

I should note that I use term IO response time and IO latency interchangeable here in case you are using these terms differently. It might be a bad habit but that’s what I do.

Before I stress test an IO subsystem, I usually set some expectations. Let’s do the same here. ODA has 20 disks – 15K RPM SAS disks. My experience tells me that I should expect very good single IO latency (below 10ms) from these disks serving at least 100 IOPS each. I also expect that these disks will still provide reasonable response time if you crank up the workload to about 200 IOPS but this is where I would see much higher response times — getting into 20ms range. Now, I know that 15K RPM SAS disk can deliver even more IOPS each but then IO response time becomes generally unacceptable for OLTP systems. In fact, 10 ms target is what’s been a good rule of thumb in the last decade.
Read the rest of this entry . . .

I’m following up on a conference almost half a year later — try to bet that! Actually, this blog post was written more than 3 months ago and was sitting in my drafts waiting the moment I understand why I really wrote it. 3 months later… I still don’t know but I thought I should share it anyway. Maybe I could at least get some comments…

Pythian participates at dozens of database conferences every year. Usually, our participation comes down to sending speakers to present. Occasionally, we make a decision to join as exhibitors too. This is usually an exception (or so it’s been thus far) because our exhibition experience doesn’t always show any visible impact in the form of new revenue or generating real opportunities leading (with maybe couple small exceptions) to business. It means that when we think on whether we invest into an exhibition booth or in sending few more speakers to a conference, we are likely choosing the latter.

This year’s RMOUG Training Days was one of those exceptions — we thought that exhibition booth cost was very affordable and by getting a booth I could ensure that we have an OakTable Network booth too (which makes sense since we actually have few Oakies at Pythian). Traditionally, exhibitors setup raffle prizes. This is usually done to collect business cards in attempt to generate some marketing leads. While this is somewhat important (yeah — we do marketing too), I already mentioned that these leads haven’t really materialized into anything for us (well, maybe not yet) but we would still do it — get a simple prize and then add business cards to our database so that we can email a Pythian newsletter once in a blue moon or even reach out for sales if there is some indication that Pythian could help. I’d say nothing unusual.

It’s all good but the thought of doing just a boring raffle didn’t sit right with me. Read the rest of this entry . . .

Working with 100 talented database engineers is fun and there are lots going on — lots of exciting (and not so much) projects ongoing, huge amount of problems solved, mistakes made (and learned from), many unique (as well as routine) customer needs satisfied, many new (and old) methods applied, many good (and less so) tools used.

With this blog post I’d like to start sharing a series of posts which I wanted to call “Pythian Recommended Tools”. After some thought, I decided to remove “recommended” — while this is a blog for the company’s employees, we try to preserve the personal aspect of blogging so any recommendation on Pythian Blog should be considered personal. Strictly speaking, this blog must have covered bunch of tools in the past but this time I’ll emphasize the tools that I really like and see widely used at Pythian. OK. Introduction is over.

If you haven’t spent the last few years under the rock, you must know how Business Intelligence solutions revolutionize businesses and open up totally new possibilities. Now, imagine yourself as a business and your Oracle Database as the source of the raw trace data. What it means is that with the right tools, your business of performance analysis can be literally revolutionized. Following this analogy, Method R tools are basically an all-in-one ETL + BI solution for Oracle database trace data: Read the rest of this entry . . .

Or how to have an answer other than “I don’t know” when asked “How long does that take?”.

Recently while working on a client site I discovered that it takes 30-90 seconds to make an ssh connection to one of the servers. Connections between servers for this client typically take < 1 second, so the lengthy connection time was definitely out of order.

If you are familiar with debugging ssh connections you are probably familiar with the ‘-v’ option that directs ssh to output verbose comments stating which operation is currently taking place.  You can add up to three -v options on the command line, increasing the verbosity with each one.  An example follows: Read the rest of this entry . . .

Hotsos is a blast. Easily the best technical Oracle conference. The speakers are terrific, the topics are cutting edge and the audience is experienced, intelligent and engaged.

I’ve been to quiet a few conferences by now, and one of the things I noticed is that the best learning is rarely as organized as “I’ll go to this presentation about triggers and I’ll learn important things about triggers”. This works too, but often you learn more from chance comments, side conversations, something a presenter says that causes you to think more deeply about some topics.

I’m documenting the best lessons I’ve learned, so you can learn too and so I won’t forget them. Read the rest of this entry . . .

Greg Rahn of Oracle’s real-world performance group posted a technical review of an article I wrote last summer, entitled Making the Most of Oracle Exadata. I have a few comments on the technical concerns Greg raised.
Read the rest of this entry . . .