Jeremy, snapshot is just a set of pointers. Using snapshot will just
move the CPU usage from your DB server to your disk array, if you are
using SAN snapshot. Snapshot is NOT a copy. It's a set pointers which is
kept accurate to point in time by combining the pointers with COW. There
are two possibilities:
1. You are doing SAN snapshots and what is being snapped is a LUN. In
this case, reading the snapshot will use CPU of the SAN and, because
of optimized algorithms, will not have a profound impact on your system.
2. You are doing file system snapshots, which are done using the COW
method (copy-on-write). That is as bad as it can get. Each snapshot
will triple your IO rate. The explanation is simple: to write the
new data to your original location you must: 1) read the old data 2)
write the old data to the new location and 3) write the new data.
That means that for every write, you need to do 3 IO operations. If
this is on your DB system, I wish you a good luck.
A word of advice: test your ideas before putting them in practice.
People often confuse snapshots for copies. Let me repeat: snapshots are
NOT copies.
On 2/19/2016 11:10 AM, Sheehan, Jeremy wrote:
Hello Guru’s,
Has anyone used JFS2 Snapshots with Oracle in any capacity? We have an old process that uses a filesystem copy in combination with transportable tablespaces to move datafiles from one db to another. We are looking to eliminate the filesystem copy and replace it with JFS2 snapshots. This is being done to eliminate CPU resources and speed up the process (about an hour per tablespace grouping x 3/day x 3 tablespaces).
If you have used something in a similar manner, any gotchas to keep an eye out for? Any advice? Please let me know.
Thanks in advance!
Jeremy