Ensuring Data Protection Using Oracle Flashback Features - Introduction (Part 1)

Introduction

This article is the first part of my article series regarding data protection using Oracle Flashback Features. Ensuring Data Protection for Oracle Databases is one of the most important tasks every Oracle DBA is faced with. Without protecting the data, the DBA will never be able to ensure high level of SLA (Service Level Agreement) to the business. 

Data Protection is a wide term that refers to the protection from many different potential issues in Oracle Databases such as:

• Data Corruptions – Block corruption could be either physical or logical: 
• Physical Corruption (also called media corruption) - When the block has an invalid checksum, therefore it cannot even be recognized as an Oracle block. 
• Logical Corruption - When the block checksum is valid but its content is logically inconsistent; for example, when there is a missing index entry or a row piece. 
• Disaster Recovery – Ranges from large-scale natural disasters such as floods, earthquakes, and fires, to small/medium disasters like power outages and viruses. 
• Human Errors - A user operation that causes data to become unavailable (e.g. dropping/truncating a table, deleting rows) or logically wrong; for example, by modifying the contents of existing rows to wrong values. 

Data Protection Objectives

Every DBA should have a clear and tested recovery strategy in order to enforce the organization's Data Protection policy, which is usually defined by 2 important objectives, RPO and RTO: 

• RPO (Recovery Point Objective) - The maximum amount of data that a business can allow itself to lose; for example, if the RPO of a company is 5 hours, then the DBA must restore and recover the database to a point in time in the last 5 hours. In some companies, the RPO is 0, i.e. the business can’t afford any data loss. 
• RTO (Recovery Time Objective) - The maximum amount of downtime that a business can incur until the system is up and available again for the users. For example, if a database was crashed due to a physical corruption of a data file that belongs to SYSTEM tablespace, then assuming the RTO is 1 hour, the DBA must restore and recover the data file to ensure the database will be up and running within 1 hour since the crash occurred. 

Figure 1: the RPO and RTO data protection objectives

Oracle provides a set of tools and features that can be used by the DBA for protecting Oracle Databases from various scenarios:

• Data Corruptions - The most common way for detecting and recovering data corruptions is by using RMAN and user-managed backup/recovery methods.
• Disaster Recovery - There are various ways for ensuring server protection, e.g. RAC, RAC One Node and Failover Clusters. For ensuring storage-level protection Oracle provides ASM 2-way or 3-way mirroring, and for ensuring site protection Oracle provides replication solutions such as Oracle Data Guard and Oracle Golden Gate.
• Human Errors - There are various ways to handle human errors including using backups (either RMAN or user-managed backups); however, by using flashback features the DBA can recover from human errors in a much faster and simpler way.

Figure 2: Oracle High Availability and Disaster Recovery Solutions

This article will be focused on the last item - how to recover from various human errors scenarios, with the minimum RTO using Oracle Flashback features.

Summary

In the first part of the series I reviewed the basics of Oracle Data Protection. In the next part I will review the first Oracle Flashback feature which was introduced in Oracle 9i, named "Flashback Query" and we will see how this feature works "behind the scenes".