NOTE TO READER: This post is a post from guest blogger Chris Lawless, VP of Product Management at Dbvisit.
What Is a Standby Database?
I was recently asked that question on a call. I was taken back a bit because I thought surely ‘everybody knows that’. But it was a good reminder that we should not take ‘common knowledge’ for granted. Some people might be new to Oracle databases, others might know standby’s as a different term. I know that our Founder and Chairman, Arjen Visser, had a blog on this over five years ago. So I figured it is maybe time for a quick refresher.
So what is a standby database? A standby database is a duplicate copy of an operational database on another server. The standby database is being kept up to date by a replication mechanism that ensures each transaction that is applied to the operational or primary database is also applied to the standby database. In most cases, there is some lag between when the transaction is applied to the primary database and when it is applied to the standby database. The lag maybe 1 minute to 10 minutes depending on the type of replication and the amount of redo/archive logs that are applying the transactions.
That is a nice definition but let’s dig a bit deeper into this. First, let’s talk about how a standby database is different than a backup. All DBAs know (or they should know) that backing up databases is of the utmost importance. When Oracle developed RMAN, it made the backing up, and managing of those backups extremely easy. Backups are great for recovering certain items. However, they may not match an organization’s required RTO (Recovery Time Objective) and RPO (Recovery Point Objective). And what if you lose the whole server? A true disaster that affects your whole data center? You would have to make a duplicate system before you could apply your backups.
This is where a DR (Disaster Recovery) site comes into play. Having a standby database that is up to date and is a mirror image of your production database is the perfect solution to a disaster. Because the server and infrastructure are already in place and the standby database is already replicated, it is there waiting for you in the event of a failure. Rather than wait hours (days?) to restore the database you could be up and running in minutes.
So how do you set up a standby database?
There are three basic ways to send data from a production database to a standby database:
- Block replication
- Logical replication
- Physical replication
Block replication is when you have a software tool on the server copying all of the changed blocks and sending them over to the target server. There are several reasons why you may not want to do this. The cost of these tools is usually expensive. You are copying some of the data three times. You are copying the changed data blocks, the Oracle redo logs and the Oracle archive logs. That is three copies of the exact same data going across the network. Block replication is not really ‘database aware’, it knows nothing of the state of awareness of what is going on with the database. Another reason might be that you have network/bandwidth issues and some of the tools have distance limitations.
The second method of replication could be logical replication. This is where a tool (like Dbvisit Replicate) reads the Oracle online redo logs and extracts the SQL. That SQL is then sent over to the target and the SQL is applied. That generally will work. However, there are still issues regarding graceful switchover and failover, as the tools are often not tied into the database for ‘disaster recovery awareness’. They work but are not always suited to disaster recovery.
The last method is physical replication. This is whereby some method archive logs are copied from the source production database to the standby target database. Dbvisit Standby fully automates this process, taking the archive logs from the source and moving them efficiently across the network and applying them to the target standby database. With full functionality regarding failover and graceful switchovers, it is the smart choice for Oracle Standard Edition disaster recovery.
There are a host of other reasons that you might want to use a standby database. You can transform the target database and open it in READ ONLY mode. This would allow you to query that database and not have those queries hit the production database. You could investigate database bugs or server bugs on the standby database. You could run your backups on the standby database. This has two purposes. The first is that you can offload the processing from the production database. The second is that you can change the time of the backups to be during the work hours. If there are any issues, you have people at the ready to check on it as it is happening versus trying to find out problems after the fact.
With the huge growth of the cloud over the past few years, you can have a fully functioning standby database without having to buy hardware, with minimal cost, all on a cloud server that will give you peace of mind in the event of a disaster in your geographical area.
So whether you decide to put your standby database on-premises or in the cloud, standby databases are the way to go.