In this post, I am sharing an advice for all Database Administrators on their database maintenance task.

In this area, Database administrators have to understand two terminologies one is Recovery Time Objective (RTO) and the second is Recovery Point Objective (RPO).

Whenever you are performing database administration task, you should analyse and suggest require RTO & RPO to concern client or organization.

Whenever DBAs are taking action on Disaster Recovery or Point in time Recovery, in these most of the situations Database Downtime is required.

The RTO & RPO help us to measure the system downtime and if the system downtime is required, what are the chances of data loss.

Without properly identifying RTO & RPO, DBAs are taking a huge risk to recover a Database from the disaster.

What is Recovery Time Objective (RTO)?

Recovery Time Objective means to measure the downtime of the system and also require to measure that how long system can be accessible again.

The DBA has to measure the desired downtime, including defined downtime and how much additional downtime is required to complete the maintenance task.

There are different approaches to define the RTO like, DBA can perform the same maintenance task on the replicate test environment and can be defined require RTO for the production database.

If DBAs are doing recovery of the large database, there is also some possibility of failure so DBA has to also calculate the time of failure for a maintenance task.

When you are determining an acceptable RTO, you should be focusing on individual applications rather than entire servers. The stopwatch starts on your RTO the instant an important application is no longer usable, and won’t stop until it can be used again as normal by all users who require it.

What is Recovery Point Objective (RPO)?

Recovery Point Objective means to measure the acceptable loss of data during the recovery operation.

Before making system down, DBAs have to monitor the load of application and make sure that there are no any running connections with the application.
DBAs have to also monitor the background job and services, which are accessing the application.

If the system has a large number of running connections, there are different approaches like point your application to the secondary server and make production server free for the maintenance task.

After the maintenance DBA has to recover backup data from the secondary server to the primary server.

If the system downtime is very high, the volume of data loss is also very high.
The DBA can measure RPO like if the bulk operation is running in the system, you can easily measure that how much data are inserted in a single minute and based on this DBA can calculate the possibility of data loss.

Once you’ve figured out how much data loss and downtime will cost or impact your business, you’re then able to formulate objectives for how to mitigate those costs—which is the exact role and nature of RTOs and RPOs.