Do you know why you should never name a database with any variation of “standby?” If not, you need to attend this session!

Oracle Data Guard streamlines and simplifies the effort of building and managing enterprise disaster recovery. Yet many—perhaps even most—of the Data Guard deployments I see are missing configurations or components vital to successful switchover and failover, use confusing or counterintuitive settings and conventions, and aren’t fully taking advantage of Data Guard features and capabilities. In this session, I’ll introduce the top ten “unwritten” Data Guard best practices that are the foundation of robust, reliable, and secure disaster recovery.

No technical requirements beyond a room, a projector, and a screen!

Why I’m uniquely qualified to present this session

I spent several years performing independent post-mortem analysis of business continuity system failures, including failed Data Guard switchover and failover events. It offered a unique glimpse into the underlying breakdowns that resulted in hours to days of downtime and often cost companies millions. Usually, the root cause was something that seemed innocent or trivial—like naming a database “PRODSTBY”—that, in the chaos of an event, created unnecessary confusion or left the environment vulnerable to subsequent mistakes that exacerbated the situation or extended the outage.

Not calling a database “standby” may sound like a strongly-held opinion, but I guarantee it’s not, and there’s a real, practical reason not to do this. In a Data Guard environment, databases are identified by their unique name. While the role (primary, standby) may change, the name doesn’t. Inserting a temporary or transient role into the permanent database name is confusing. When the role changes, the name doesn’t, and referencing the “standby” becomes ambiguous. Does it mean the database named “standby” or the database currently in the standby role?