As the title of this blog post suggest we will be looking at how to use LVM snapshot to flashback our oracle database to point in time snap or to create a thin clone for what if analysis. I’am taking the oracle database as an example here but it can be any database supporting crash consistent snapshot.
Let’s start with the first use cases : Database flashback
Suppose that we have an oracle database and we want to do some risky operation. So here we have an oracle database started from a dedicated ext4 file system.
Before creating our snapshot let’s check if we have enough free space in our volume group as the snapshot will increases in size as the original volume changes.
Ok so we have some free space. Let’s now create our snapshot !
In this case i allocated only 200MB for storing changed blocks. One important point is that “A snapshot that is 100% full is lost completely, as a write to unchanged parts of the origin would be unable to succeed without corrupting the snapshot.” To try to avoid losing our snapshot we can enable automatic extension of a snapshot using the parameters “
snapshot_autoextend_threshold ” and “
snapshot_autoextend_percent” in “lvm.conf” .
Let’s modify some data in our source database :
The snapshot is now using 5% of it’s allocated space :
Let’s now restore our snapshot on the orginal volume using “lvconvert –mergesnaphot” :
That’s it our database is back to the initial state !
Time to look at the second use cases : Database thin clone
As of LVM2 the created snapshot is by default in Read/Write mode so we can open our database snapshot to do some testing :
So here i mounted my snapshot in a new volume “/app/oradata_clone” .We can see here that my initial disk size is about 6GB and i created a clone of a database of more that 4GB using COW in just a few seconds !
Just take the time to correctly rename all datafiles/log files/etc before starting your new clone !
Testing modification in the Source database :
Checking the Clone database :
That’s it 😀