Author: Shakir Sadikali

Hello folks, it’s great to be back from hiatus. This is the 183rd edition of Log Buffer (arguably the best edition of Log Buffer yet!), the weekly review of database blogs.

Of all the frustrating, partially-completed features Oracle has released, this is the most frustrating. Did I mention this frustrating feature is frustrating when you get bitten by it?What am I referring to? FLASHBACK QUERY on a table that lives in a database with a large UNDO_RETENTION specified with lots and lots of UNDO_TABLESPACE space. Why is this behaving this way? Silly me, I really should read Oracle docs more carefully.Here’s what they say at Managing Undo for Your Database…There you have it folks. Please don’t get bitten with this the way I did.

Welcome to the 89th edition of Log Buffer, the weekly review of database blogs.

No one has ever come out and formally asked me for a document that states “Best Practices to Scale Application X”. It is an unusual demand, since it’s something many of us at Pythian have implemented, but it’s been more of an ad hoc, iterative process — and rightly so, since architectures must be so organic, and so tailored to the application. What’s more, no one has ever brought us on board so early in the game that we have a hand in actually — gasp! — doing the design and data-model from the get-go. Woo hoo!

Have you ever heard the one about throwing hardware at a software problem? I have this nifty RAC system that supports some very public and very mission-critical apps, and one day (it was Sunday night) it starts choking. We’re getting enqueues. Slowly they start climbing. Ten nodes came to a crashing halt. I have now seen a ten-node RAC cluster come to crashing halt and completely lock up. Why, you ask? A simple SQL statement: DELETE FROM a WHERE b=c AND d=e;.

Last week, we discovered a bug related to the rollback of the Java DST patch for 9206 on Linux x86. If you’re in the unfortunate position of needing to roll this patch back, you won’t be able to. When you rollback, you need to restore both of these files, and then do a create or replace java system. Otherwise you risk hitting a dreaded ORA-03114 End of file on communication channel. Those of you familiar with DST patching will have seen this, but for those who haven’t, here are the scripts you need to check for a successful Java implementation:

I always get a chuckle well not always but often, when I read anything to do with Microsoft vs. “the flavour of the month”. In this case, it looks like the flavour of the month is Oracle. The articles simple imply that SQL Server is more secure than Oracle. They go on to count the number of vulnerabilities identified over the last few years. It’s scary stuff and I’m sure we’re all running out now to ask our architects and DBAs how quickly we can port over to SQL Server.

The client entrusted me with the migration of one of their mission critical apps running 8i on HPUX to — drum role please — 9i … on … IBM Mainframe running os390 (z/os). For this client, we were able to shave $600,000 (not just the Oracle license, but also the external costs of maintaining the environment) by migrating just one HPUX machine over to the mainframe with maybe 30 or more to go.

Over the last weekend I had the pleasure to do an 8i -> 10g, Solaris -> Linux migration. Talk about going in head–first. Now, whenever I run into a situation like this, we generally recommend a two–step process so that we can iron out bugs and be able to isolate causes. However, we were under serious time constraints, and we decided to just go with the following simple plan and move straight there.

In the last month, we have been hit with two clients’ large-scale failures. The first involved network issues; the second, disk failures. What happened?. We took one of the standbys and turned it into a primary. The other standby then automatically started recovering from the new primary! That was it. What a let down! No magical status updates, no little “dots” going across the screen. Just one line and 15 seconds. Oracle, get your act together! I even had to use bold text to make it stand out.