Pythian Group

If you have an extremely busy OLTP system with a physical standby ready for a manual role transition, and you want to run very heavy reporting queries without affecting the system, consider using a separate report database with downstream capture configuration. Yes, it is very easy to configure, and it will have no performance impact on the OLTP system whatsoever.

In this blog, I will show how to do this, and how to maintain the archivelog transportation during a manual switchover.

Below is the configuration of the three databases I have for testing:
Read the rest of this entry . . .

One of the customers (actually a prospect) here in Australia asked me about minimal Oracle licensing on a quarter rack database machine. This prompted a thought of using Oracle Standard Edition instead of full blown Enterprise Edition with bunch of options.

Before even going into possibility of using Oracle SE for the database machine, let’s see if we even want to.

Why Oracle Standard Edition?

If the environment is data warehouse then it’s extremely unlikely that Standard Edition will cut it. Lack of many feature make it non-feasible to use for data warehousing — no partitioning licensing, no parallel query, and dozens more.

Oracle Standard Edition might fit OLTP environments depending on the application design and data volumes. Since Database Machine is made to store large amounts of data, we assume that it makes financial sense to run databases that are quite large. Oracle SE lacks some critical features in order to successfully manage VLDB (Very Large Databases). It’s not impossible and depends a lot on the presence of outage windows, how active is the development life-cycle, availability requirements and etc.

Where Standard Edition seems to fit nicely is Read the rest of this entry . . .

Update, July 9, 2010: Pythian has now announced our range of services for Oracle Exadata, along with successful implementations and reference customers.

Now that I, apparently successfully, predicted OLTP Database Machine on Sun hardware, I had to wake up before 6AM in Sydney to tune into Larry’s joined with Sun Microsystems webcast (just to learn that he is late, by the way – 8 minutes so far…). As the follow up post’s comments show, people are interested in the role of SPARC platform in the new OLTP Oracle Database Machine (turns our there is no role for SPARC as of now).

Waiting… Waiting… ah here it comes — yachts, BMW (yeah love it as well) and Larry walks in — he starts by mentioning lo-o-o-ong partnership with Sun and announced –
“Oracle Exadata version 2 – hardware by Sun and software by Oracle.” Funny, I heard exactly the same sitting at the Oracle Open World last year but with HP. He then proceeds — “It is the *First* Database Machine that does OLTP. All the other machines, Teradata, Netezza, etc. are designed just for data warehousing.”

Interesting that Larry’s speech was very harsh on competition and where it comes to data warehousing, it’s Netezza and Teradata, while in hardware it’s IBM. I need to count how many times Larry said “better/cheaper/faster than IBM” during his announcement.
Read the rest of this entry . . .

As some of you probably already noticed, there was a thread on AskTom discussing the scalability tests I did back in 2007. You are welcome to read the entire thread, but in a nutshell, Tom Kyte claimed that my tests did not reflect how one would use the result cache in the real world.

What is “real world?”

Of course, the important question is whether I tested a feature in a way it was never designed to be used, or whether someone is just trying to make an excuse for poor scalability results by defining “real world” in a way that makes my tests inappropriate.

A new feature

What do you do, then, you first see a new feature? You read about it in the documentation, and then you test it in order to compare what you have read with what you have in reality.

What the documentation tells us

Open the Performance Tuning Guide and go to 7.3.1.4 Result Cache Concepts:

When these queries and functions are executed repeatedly, the results are retrieved directly from the cache memory. This results in a faster response time. The cached results stored become invalid when data in the dependent database objects is modified. The use of the result cache is a database-wide decision.

All it says is that you have to have repeatedly-executed functions and queries to get faster response time. It says nothing about what kind of queries or functions. It also suggests that the result cache should be used database-wide or shouldn’t be used at all (which is perfectly sound according to Jonathan Lewis’s Rules for Hinting).

Now skip up to 7.3.2.7 Use of Result Cache:

OLTP applications can benefit significantly from the use of the result cache. The benefits highly depend on the application. Consider the use of the PL/SQL function result cache and the SQL query result cache when evaluating whether your application can benefit from the result cache.

It clearly says that result cache is perfectly appropriate for OLTP applications. They leave a backdoor with the words, “depend on the application” but, yet again, they say nothing about what kind of OLTP applications.

Read the rest of this entry . . .

This article will discuss how to make many-to-many relationships in data warehousing easily queried by novice SQL users using point-and-click query tools.

This is a big problem with Oracle Discoverer-like tools where the metadata layer is basically a set of pre-joined tables from which the user simply clicks on columns and hits the run button. You can create custom complex queries that they can run, but then every query is custom, which defeats the purpose of the tool in the first place.

The design goal is to create a structure that is simple for the end user and which normally translates to something as flat as possible. This article will go through the different methods of implementing many-to-many relationships, and look at their effect on query complexity, especially for someone who use a tool that hides the SQL.

Read the rest of this entry . . .