With apologies to Dr. Seuss.
Did I ever tell you the makers of RAC
had seven features and named each flashback?
Well they did, and it wasn’t a smart thing to do.
You see, when the customers wanted a clue
as to how to keep data from getting deleted
the RAC folks said “flashback” and customers heeded.
They turned on all seven of those flashback features
Each one was a slightly dissimilar creature.
Some used the UNDO, some used flashback files
Some just renamed tables to bin$ styles.
One was a place you keep things for recovering
Another was just for forensic discovering
With so many features called by the same name
when thinks broke no one knew just which one they should blame.
Before I joined Blue Gecko, I did independent remote DBA work, and called myself ORA-600 Consulting. Stemming from my hair-raising experiences in the trenches at Amazon in the late ’90s / early 2000s, I decided to specialize in emergency DBA work for companies in the midst of crises (I know, great idea for someone who wanted to get away from the Amazon craziness, right?).
One day in 2009, a company in Florida called my cell phone at 2AM. They described their problem as follows:
If you are a director, manager or project manager who works with DBAs, you probably have had the nagging suspicion at one time or another that a DBA’s assertions regarding his or her practices lack an empirical or scientific basis, or are simply deflections intended to pass the buck.
Manager: Mr. DBA, the application is really slow. Do you have any idea what’s wrong?
DBA: Oracle is very complex. It could be any of 100 different possible causes. I will begin checking each. Anyhow, what makes you think it is the database?
In our Remote DBA practice, we frequently perform comprehensive system reviews for our customers on their database services. Among the things we always check for are non-default settings for the database software. We want to validate that any non-default setting is set that way for a good reason, and that any setting that is default really should be that way.
In Oracle, this is easy. The
gv$parameter view has a column,
ISDEFAULT, that allows a simple SQL query to show which settings are set to non-default values.
It’s not so easy in SQL Server. There is a view, master.sys.configurations, but it doesn’t have a way to tell if the setting is default or modified or anything.
On Tuesday, Amazon announced availability of an Oracle version of their Relational Database Service (RDS). RDS is one of Amazon’s cloud services. You can think of it as ”database as a service.” Amazon provides a running database, storage, horsepower and a variety management tasks. And all you have to do is store you data in it. RDS has been available with a MySQL engine for some time, but the Oracle version of this service has been long anticipated.
As with Amazon’s other cloud services, you control and manage RDS services using a web application API. You can either write your own software to do this, or use Amazon’s command line API tools or Amazon’s web-based console.
Amazon EC2′s high-profile outage in the US East region has taught us a number of lessons. For many, the take-away has been a realization that cloud-based systems (like conventionally-hosted systems) can fail. Of course, we knew that, Amazon knew that, and serious companies who performed serious availability engineering before deploying to the cloud knew that. In cloud environments, as in conventionally-hosted environments, you must implement high-availability if you want high availability. You can’t just expect it to magically be highly-available because it is “in the cloud.” Thorough and thoughtful high-availability engineering made it possible for EC2-based Netflix to experience no service interruptions through this event.
Oracle’s pre-RMAN hot backup mode is the subject of one of the most pervasive and persistent misconceptions about Oracle.
During an Oracle tablespace hot backup, you (or your script) puts a tablespace into backup mode, then copies the datafiles to disk or tape, then takes the tablespace out of backup mode. These steps are widely understood by most DBAs.
Before launching into this, I must give due deference to Mogens Nørgaard’s landmark article, You Probably Don’t Need RAC (YPDNR), available here, but originally published Q3 2003 in IOUG Select Journal. Mogens showed that you can be a friend of Oracle without always agreeing with everything they do.