In this post, I am sharing one advice to all Database Administrator before starting of any type database maintenance task.
In this area, Database administrators have to understand two terminology 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 Down time is required.
The RTO & RPO help us to measure the system down time and if the system down time 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 down time 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 defined require RTO for 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 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 connection 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 connection, there are different approaches like, point your application to the secondary server and make production server free from maintenance task.
Later, after maintenance DBA has to recover backup data from the secondary server to the primary server.
If the system down time is very high, volume of data loss is also very high.
The DBA can measure RPO like, if bulk operation is running in the system, you can easily measure that how much data are inserted in a single minute and bases 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.