Snapshotting Oracle Database
- Not about CPU contention because there’s no much to do here on single host
- It illustrates conceptually how database is cloned in various ways
- It discusses how to use different clone strategy for different scenarios
- When talking about snapshot, it means a database state in the past. The technologies
discussed here can all bring database to a point in time in the past
- clone of entire DB, one DB one instance.
- Traditional database backup and restore is used
- Traditional rman duplicate is used
- Dev1 is snapshot of prod, qa1 can be further snapshot of dev1, etc
- Pros: reused script. it works. Easy to maintain
- Cons: contention on memory and storage. Time consuming when DB is big
CloneDB, which saves storage
Rman duplicate or database restore.
Same as before, but putting to
Server with plenty of cheap storage
Same clone process as before
In this approach, DBs with existing clone method
co-exists with DBs done by CloneDB, which serves
-- have a same start point, then grow themselves individually
-- reduce storage contention on main host
-- can have many “snapshots” on cheap storage and build
them Up on main host with less cost
-- once base database is destroyed, all depending
cloneDBs will also be destroyed
-- not good for performance testing
Pluggable DB, which saves memory
-- One instance means less memory
-- Creation of new PDB can be easily
achieved as clone of existing PDB
When a certain state is reached, guaranteed restore point can be created, when it is required later, database can be rewound back to guaranteed
restore point quickly. Good thing in Oracle’s flashback database feature is you can rewind back to any guaranteed restore point without having to
concern rewinding back to earlier point would override later points. For example, rewinding back to GP2 and making some changes won’t hurt
the ability to later rewind back to GP3 or GP4.
Taking QA testing as an example, after major state has been achieved, under DBA’s help, guaranteed restore point is created as a snapshot of
that state. QA can continue their testing and create more restore points along the way.
When they have to fork out on same set of data or same state of database, they can create a restore point and then go to the first test condition,
it is GP2 in the illustration. Along the testing, GP3 and GP4 can be created. After one condition is tested, database can be rewound back to GP2
and QA can start testing on another condition based on exactly same set of data or state of database. In each of branched testing, restore points
can be created and database can be easily restored to any of them, even they are in different branches. For instance, while as branch 2, it can be
restored to GP3 or GP4 that are in branch 1, later it can be further restored to Gp5 or GP6 after being restored to GP3 or GP4.
One of benefit of this solution is that only one database and instance are required. One of drawback is it can be only in one of the state at a time,
you can not parallel checking and comparing data between different states. CloneDB is under consideration should you want to simultaneously
have environments starting from same point.
GP1 GP2 GP3 GP4
Rewind back to GP2
Having another path from GP2
Flashback database, a smart way to have “snapshots” of database
It saves both on Memory and Storage and it is easiest to setup and maintain